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 TAA23327 for ; Thu, 31 Jan 2002 19:03:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 722AB912F5; Thu, 31 Jan 2002 19:03:13 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3FA75912F6; Thu, 31 Jan 2002 19:03: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 3FF88912F5 for ; Thu, 31 Jan 2002 19:03:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1CD895DDAB; Thu, 31 Jan 2002 19:03:12 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [66.35.212.41]) by segue.merit.edu (Postfix) with ESMTP id 81F615DD91 for ; Thu, 31 Jan 2002 19:03:11 -0500 (EST) Received: from khonsu.sw.nexsi.com (dynam34.sw.nexsi.com [172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id QAA10856; Thu, 31 Jan 2002 16:02:05 -0800 Date: Thu, 31 Jan 2002 16:02:06 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <158100801104.20020131160206@nexsi.com> To: Enke Chen Cc: "Rijsman, Bruno" , "'idr@merit.edu'" Subject: Re: questions about draft-ietf-idr-as4bytes-04 In-Reply-To: <20020131175506.B51BB15D3C1@popserv1.redback.com> References: <20020131175506.B51BB15D3C1@popserv1.redback.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Enke, Do you think it would be a good idea to include a couple of paras, one specifying the temporary (if it is indeed temporary) value for AS_TRANS and another explicitly saying that dynamic renegotiation is not an option? Also, I think Jeff and you agreed that in the para below you would need some text saying that the attribute should not be propagated further. "discard" may not be descriptive enough, I think. > The new attributes, NEW_AS_PATH and NEW_AGGREGATOR should not be > carried in the UPDATE messages between NEW BGP peers. A NEW BGP > speaker that receives the NEW_AS_PATH and NEW_AGGREGATOR path > attributes in an UPDATE message from a NEW BGP speaker should discard > these path attributes and continue processing the UPDATE message. Thanks, -- Alex Zinin Thursday, January 31, 2002, 9:55:06 AM, Enke Chen wrote: ... >> 1. What's the value of AS_TRANS? (I could not find it on the IANA web site) > It is 23456. ... >> >> 3. As currently specified the AS-PATH attribute can either contain 2-octet >> or 4-octet AS-numbers, depending on whether or not both sides are NEW BGP >> speakers. The UPDATE itself does not contain enough information to >> determine whether or not both sides are NEW or OLD BGP speakers: you have >> to look back at the history of capability negotiations for that session. >> In the case of dynamic capability negotiation you need the whole history >> of the session since the OPEN. This is not a problem for BGP >> implementations, but I imagine this makes life difficult when decoding >> a trace of captured packets. Would it be worthwhile to intoduce new >> segment types NEW-AS-SEQ, NEW-AS-SET, NEW-CONFED-SEQ, and NEW-CONFED-SET >> specifically for 4-octet AS numbers? > See the following text in Sect 6, : > It is noted that the dynamic capability update may not be feasible > and should be disallowed for some capabilities. One example is the > four-byte AS number capability [BGP-4BYTE-AS] as its dynamic update > could introduce ambiguity in parsing the UPDATE messages. > -- Enke Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA16564 for ; Thu, 31 Jan 2002 14:14:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B5143912DC; Thu, 31 Jan 2002 14:09:25 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A382912D7; Thu, 31 Jan 2002 14:09: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 5453B912DE for ; Thu, 31 Jan 2002 14:09:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 358265DE05; Thu, 31 Jan 2002 14:09:09 -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 EA70D5DDF8 for ; Thu, 31 Jan 2002 14:09:08 -0500 (EST) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 57739F2C40; Thu, 31 Jan 2002 11:09:08 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id D8D627E6C1; Thu, 31 Jan 2002 11:09:06 -0800 (PST) To: "Rijsman, Bruno" Cc: "'idr@merit.edu'" , enke@redback.com Subject: Re: questions about draft-ietf-idr-as4bytes-04 In-Reply-To: Message from "Rijsman, Bruno" of "Thu, 31 Jan 2002 13:13:58 EST." <49FF5C6DDBD8D311BBBD009027DE980C02E7E4AD@UNIWEST1> Date: Thu, 31 Jan 2002 11:09:06 -0800 From: Enke Chen Message-Id: <20020131190906.D8D627E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Rijsman: > Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02E7E4AD@UNIWEST1> > From: "Rijsman, Bruno" > To: 'Enke Chen' > Cc: "'idr@merit.edu'" > Subject: RE: questions about draft-ietf-idr-as4bytes-04 > Date: Thu, 31 Jan 2002 13:13:58 -0500 > MIME-Version: 1.0 > X-Mailer: Internet Mail Service (5.5.2653.19) > Content-Type: text/plain; > charset="iso-8859-1" > > Hi Enke, > > Thanks for the quick answers. > > On question 2, I was actually talking about a different situation: > > 1 NEW (AS 111111) > | > | > 2 NEW (AS 200) > | > | > 3 OLD (AS 300) > | > | > 4 NEW (AS 400) > > > In this situation router 4 *should* receive an UPDATE from router 3 > containing the following attributes: > > AS-PATH = 300 200 23456 > > NEW-AS-PATH = 200 111111 > > Note that router 3 passed the NEW-AS-PATH on as an unrecognized transitive > attribute. > > > But, let's say router 4 actually received the following attributes (due to a > bug in router 2): > > AS-PATH = 300 200 23456 > > NEW-AS-PATH = 200 100 > If you follow the procedures described in Sect. 4.2.3, Router-4 would re-construct the AS-PATH as: 300 200 100. That seems to be the most you can derive from the incomplete AS-PATH info due to the bug on Router-2. BTW, incomplete/truncated AS-PATH info occurs not-so-rarely in the pure 2byte-AS world. -- Enke > > Router 4 knows something is wrong, because the AS-PATH and the NEW-AS-PATH > are inconsistent (the originating AS 23456 in the AS-PATH cannot possibly > correspond to the originating AS 100 in the NEW-AS-PATH: one or the other > must be wrong). > > > What should router 4 do? > > > -- Bruno 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 NAA14711 for ; Thu, 31 Jan 2002 13:14:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D900E912CB; Thu, 31 Jan 2002 13:14:01 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96304912CC; Thu, 31 Jan 2002 13:14: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 5DBC0912CB for ; Thu, 31 Jan 2002 13:14:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3227A5DDF8; Thu, 31 Jan 2002 13:14:00 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailwest.unispherenetworks.com (unknown [65.194.140.130]) by segue.merit.edu (Postfix) with ESMTP id EFE515DD91 for ; Thu, 31 Jan 2002 13:13:59 -0500 (EST) Received: by UNIWEST1 with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 13:13:59 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02E7E4AD@UNIWEST1> From: "Rijsman, Bruno" To: "'Enke Chen'" Cc: "'idr@merit.edu'" Subject: RE: questions about draft-ietf-idr-as4bytes-04 Date: Thu, 31 Jan 2002 13:13:58 -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 Hi Enke, Thanks for the quick answers. On question 2, I was actually talking about a different situation: 1 NEW (AS 111111) | | 2 NEW (AS 200) | | 3 OLD (AS 300) | | 4 NEW (AS 400) In this situation router 4 *should* receive an UPDATE from router 3 containing the following attributes: AS-PATH = 300 200 23456 NEW-AS-PATH = 200 111111 Note that router 3 passed the NEW-AS-PATH on as an unrecognized transitive attribute. But, let's say router 4 actually received the following attributes (due to a bug in router 2): AS-PATH = 300 200 23456 NEW-AS-PATH = 200 100 Router 4 knows something is wrong, because the AS-PATH and the NEW-AS-PATH are inconsistent (the originating AS 23456 in the AS-PATH cannot possibly correspond to the originating AS 100 in the NEW-AS-PATH: one or the other must be wrong). What should router 4 do? -- Bruno 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 MAA14343 for ; Thu, 31 Jan 2002 12:55:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C5383912C7; Thu, 31 Jan 2002 12:55:09 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92AE7912C8; Thu, 31 Jan 2002 12:55:09 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A34AB912C7 for ; Thu, 31 Jan 2002 12:55:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 89B035DE05; Thu, 31 Jan 2002 12:55:08 -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 4F1555DDAB for ; Thu, 31 Jan 2002 12:55:08 -0500 (EST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 1489FF2C54; Thu, 31 Jan 2002 09:55:07 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id B51BB15D3C1; Thu, 31 Jan 2002 09:55:06 -0800 (PST) To: "Rijsman, Bruno" Cc: "'idr@merit.edu'" , enke@redback.com Subject: Re: questions about draft-ietf-idr-as4bytes-04 In-Reply-To: Message from "Rijsman, Bruno" of "Thu, 31 Jan 2002 11:52:07 EST." <49FF5C6DDBD8D311BBBD009027DE980C02E7E4AA@UNIWEST1> Date: Thu, 31 Jan 2002 09:55:06 -0800 From: Enke Chen Message-Id: <20020131175506.B51BB15D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Rijsman: > Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02E7E4AA@UNIWEST1> > From: "Rijsman, Bruno" > To: "'idr@merit.edu'" > Subject: questions about draft-ietf-idr-as4bytes-04 > Date: Thu, 31 Jan 2002 11:52:07 -0500 > MIME-Version: 1.0 > > I have some questions about draft-ietf-idr-as4bytes-04: > > 1. What's the value of AS_TRANS? (I could not find it on the IANA web site) It is 23456. > > 2. What should a BGP speaker do when it receives an AS-PATH and a > NEW-AS-PATH which are inconsistent (or an AGGREGATOR and NEW-AGGREGATOR > which are inconsistent)? Send a NOTIFICATION? If so, what error code? See the following text in Sec. 4.1: The new attributes, NEW_AS_PATH and NEW_AGGREGATOR should not be carried in the UPDATE messages between NEW BGP peers. A NEW BGP speaker that receives the NEW_AS_PATH and NEW_AGGREGATOR path attributes in an UPDATE message from a NEW BGP speaker should discard these path attributes and continue processing the UPDATE message. > > 3. As currently specified the AS-PATH attribute can either contain 2-octet > or 4-octet AS-numbers, depending on whether or not both sides are NEW BGP > speakers. The UPDATE itself does not contain enough information to > determine whether or not both sides are NEW or OLD BGP speakers: you have > to look back at the history of capability negotiations for that session. > In the case of dynamic capability negotiation you need the whole history > of the session since the OPEN. This is not a problem for BGP > implementations, but I imagine this makes life difficult when decoding > a trace of captured packets. Would it be worthwhile to intoduce new > segment types NEW-AS-SEQ, NEW-AS-SET, NEW-CONFED-SEQ, and NEW-CONFED-SET > specifically for 4-octet AS numbers? See the following text in Sect 6, : It is noted that the dynamic capability update may not be feasible and should be disallowed for some capabilities. One example is the four-byte AS number capability [BGP-4BYTE-AS] as its dynamic update could introduce ambiguity in parsing the UPDATE messages. -- Enke Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA12782 for ; Thu, 31 Jan 2002 11:52:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2837F912BD; Thu, 31 Jan 2002 11:52:10 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA0A2912C3; Thu, 31 Jan 2002 11:52:09 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AF4C3912BD for ; Thu, 31 Jan 2002 11:52:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8CCF85DE29; Thu, 31 Jan 2002 11:52:08 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailwest.unispherenetworks.com (unknown [65.194.140.130]) by segue.merit.edu (Postfix) with ESMTP id 542225DE05 for ; Thu, 31 Jan 2002 11:52:08 -0500 (EST) Received: by UNIWEST1 with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 11:52:08 -0500 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02E7E4AA@UNIWEST1> From: "Rijsman, Bruno" To: "'idr@merit.edu'" Subject: questions about draft-ietf-idr-as4bytes-04 Date: Thu, 31 Jan 2002 11:52:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk I have some questions about draft-ietf-idr-as4bytes-04: 1. What's the value of AS_TRANS? (I could not find it on the IANA web site) 2. What should a BGP speaker do when it receives an AS-PATH and a NEW-AS-PATH which are inconsistent (or an AGGREGATOR and NEW-AGGREGATOR which are inconsistent)? Send a NOTIFICATION? If so, what error code? 3. As currently specified the AS-PATH attribute can either contain 2-octet or 4-octet AS-numbers, depending on whether or not both sides are NEW BGP speakers. The UPDATE itself does not contain enough information to determine whether or not both sides are NEW or OLD BGP speakers: you have to look back at the history of capability negotiations for that session. In the case of dynamic capability negotiation you need the whole history of the session since the OPEN. This is not a problem for BGP implementations, but I imagine this makes life difficult when decoding a trace of captured packets. Would it be worthwhile to intoduce new segment types NEW-AS-SEQ, NEW-AS-SET, NEW-CONFED-SEQ, and NEW-CONFED-SET specifically for 4-octet AS numbers? 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 XAA23685 for ; Tue, 29 Jan 2002 23:05:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 41BAA9128A; Tue, 29 Jan 2002 23:04:57 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0943D9128B; Tue, 29 Jan 2002 23:04:56 -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 9C2679128A for ; Tue, 29 Jan 2002 23:04:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7CCF45DDE2; Tue, 29 Jan 2002 23:04:55 -0500 (EST) Delivered-To: idr@merit.edu Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by segue.merit.edu (Postfix) with ESMTP id EE8A75DDD6 for ; Tue, 29 Jan 2002 23:04:54 -0500 (EST) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 23:04:46 -0500 Message-ID: From: Sathya Perla To: idr@merit.edu Subject: RE: Collision detect [Re-Posting] Date: Tue, 29 Jan 2002 23:04:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idr@merit.edu Precedence: bulk Talking to unconfigured peers is orthogonal to the collision detection problem. When a router (that doesn't talk to unconfigured peers) sees that a connection has been initiated by a peer it doesn't recognize, it closes the connection right there. Note that a router that listens on the BGP_PORT can receive a connection from any peer and then check to see if the peer is known. It may receive and accept a connection from a configured peer just at the time it succeeds in initiating a connection to the same peer -- causing a double connection. So, I feel it'll help to have some text about resolving a collision both with the one/two FSM schemes. The catch is that the spec. assumes the usage of 2 FSMs as it requires a "FSM Cease" to close a transport connection. So, the 1-FSM scheme will have to remain a "hack" in a way, as it ignores the "FSM Cease".... -Sathya -----Original Message----- From: Eric Leisheng Ji [mailto:jileish@charlie.cns.iit.edu] On Tue, 29 Jan 2002, Jeffrey Haas wrote: > On Tue, Jan 29, 2002 at 12:41:16PM -0800, Alex Zinin wrote: > > BTW, when you receive an incoming transport connection > > from an unconfigured peer first time, I guess the peer > > lookup will fail, which means you don't have an outstanding > > transport connection, and hence no risk for collision, > > correct? > > Right. But if you initiate a connection and then the unconfigured peer > drops its transport session and quickly re-establishes it, you could. > That may happen if the unconfigured peer just drop the connection and wait for the initial peer to tcp-timeout. Can we deal it this way, whenever one incoming connection comes, the bgp instance will check the configured peer list. If no one match, bgp instance will EXPLICITLY close that connection. That way no collision is created, under the precondition that the multithread schedule doesnt interrupt and deal with new connection in this accept-close time interval. Though in real implementation, I think it's very rare for this to happen. Thanks, > > Alex. > > -- > Jeff Haas 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 VAA22378 for ; Tue, 29 Jan 2002 21:58:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B8AEC91288; Tue, 29 Jan 2002 21:58:12 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 907C591289; Tue, 29 Jan 2002 21:58:12 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 291CD91288 for ; Tue, 29 Jan 2002 21:58:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 09B1B5DDDF; Tue, 29 Jan 2002 21:58:11 -0500 (EST) Delivered-To: idr@merit.edu Received: from csl.cs.iit.edu (csl.csam.iit.edu [216.47.150.143]) by segue.merit.edu (Postfix) with ESMTP id 2D0135DDC8 for ; Tue, 29 Jan 2002 21:58:10 -0500 (EST) Received: from charlie.cns.iit.edu (charlie.cns.iit.edu [216.47.143.70]) by csl.cs.iit.edu (8.9.3/8.9.3) with ESMTP id WAA08290; Tue, 29 Jan 2002 22:17:17 -0600 Date: Tue, 29 Jan 2002 20:58:31 -0600 From: Eric Leisheng Ji To: Jeffrey Haas Cc: idr@merit.edu Subject: Re: Collision detect [Re-Posting] In-Reply-To: <20020129154607.F5769@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk On Tue, 29 Jan 2002, Jeffrey Haas wrote: > On Tue, Jan 29, 2002 at 12:41:16PM -0800, Alex Zinin wrote: > > BTW, when you receive an incoming transport connection > > from an unconfigured peer first time, I guess the peer > > lookup will fail, which means you don't have an outstanding > > transport connection, and hence no risk for collision, > > correct? > > Right. But if you initiate a connection and then the unconfigured peer > drops its transport session and quickly re-establishes it, you could. > That may happen if the unconfigured peer just drop the connection and wait for the initial peer to tcp-timeout. Can we deal it this way, whenever one incoming connection comes, the bgp instance will check the configured peer list. If no one match, bgp instance will EXPLICITLY close that connection. That way no collision is created, under the precondition that the multithread schedule doesnt interrupt and deal with new connection in this accept-close time interval. Though in real implementation, I think it's very rare for this to happen. Thanks, > > Alex. > > -- > Jeff Haas > NextHop Technologies > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA15129 for ; Tue, 29 Jan 2002 16:00:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ACABB91283; Tue, 29 Jan 2002 15:59:55 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A3C691284; Tue, 29 Jan 2002 15:59: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 84A2191283 for ; Tue, 29 Jan 2002 15:59:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D14F5DDD3; Tue, 29 Jan 2002 15:59:54 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [66.35.212.41]) by segue.merit.edu (Postfix) with ESMTP id C08BA5DD8C for ; Tue, 29 Jan 2002 15:59:53 -0500 (EST) Received: from khonsu.sw.nexsi.com (dynam34.sw.nexsi.com [172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id MAA15503; Tue, 29 Jan 2002 12:59:13 -0800 Date: Tue, 29 Jan 2002 12:59:12 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <1621314879306.20020129125912@nexsi.com> To: Jeffrey Haas Cc: idr@merit.edu Subject: Re: Collision detect [Re-Posting] In-Reply-To: <20020129154607.F5769@nexthop.com> References: <521076821136.20020126185129@nexsi.com> <20020128114223.A2629@nexthop.com> <1981247720417.20020128181952@nexsi.com> <20020129150240.E5769@nexthop.com> <1881313803779.20020129124116@nexsi.com> <20020129154607.F5769@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk >> BTW, when you receive an incoming transport connection >> from an unconfigured peer first time, I guess the peer >> lookup will fail, which means you don't have an outstanding >> transport connection, and hence no risk for collision, >> correct? > Right. But if you initiate a connection and then the unconfigured peer > drops its transport session and quickly re-establishes it, you could. I guess when you receive that second connection, you either have a peer structure for this guy already and hence deal with it as you would do with a configured peer, or you do not have the peer structure and hence there's no outstanding connection... What am I missing? Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA14803 for ; Tue, 29 Jan 2002 15:46:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3C52D91282; Tue, 29 Jan 2002 15:46:27 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA3F291283; Tue, 29 Jan 2002 15:46: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 9D8FD91282 for ; Tue, 29 Jan 2002 15:46:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 756445DDCC; Tue, 29 Jan 2002 15:46:25 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 305165DDC5 for ; Tue, 29 Jan 2002 15:46:25 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0TKk8371765; Tue, 29 Jan 2002 15:46:08 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0TKk7W06224; Tue, 29 Jan 2002 15:46:07 -0500 (EST) Date: Tue, 29 Jan 2002 15:46:07 -0500 From: Jeffrey Haas To: Alex Zinin Cc: idr@merit.edu Subject: Re: Collision detect [Re-Posting] Message-ID: <20020129154607.F5769@nexthop.com> References: <521076821136.20020126185129@nexsi.com> <20020128114223.A2629@nexthop.com> <1981247720417.20020128181952@nexsi.com> <20020129150240.E5769@nexthop.com> <1881313803779.20020129124116@nexsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1881313803779.20020129124116@nexsi.com>; from azinin@nexsi.com on Tue, Jan 29, 2002 at 12:41:16PM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Tue, Jan 29, 2002 at 12:41:16PM -0800, Alex Zinin wrote: > BTW, when you receive an incoming transport connection > from an unconfigured peer first time, I guess the peer > lookup will fail, which means you don't have an outstanding > transport connection, and hence no risk for collision, > correct? Right. But if you initiate a connection and then the unconfigured peer drops its transport session and quickly re-establishes it, you could. > Alex. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA14727 for ; Tue, 29 Jan 2002 15:42:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A586E9127F; Tue, 29 Jan 2002 15:42:12 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7348191282; Tue, 29 Jan 2002 15:42:12 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7B6BB9127F for ; Tue, 29 Jan 2002 15:42:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 599485DDCD; Tue, 29 Jan 2002 15:42:11 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [66.35.212.41]) by segue.merit.edu (Postfix) with ESMTP id F05505DDCC for ; Tue, 29 Jan 2002 15:42:10 -0500 (EST) Received: from khonsu.sw.nexsi.com (dynam34.sw.nexsi.com [172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id MAA15324; Tue, 29 Jan 2002 12:41:16 -0800 Date: Tue, 29 Jan 2002 12:41:16 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <1881313803779.20020129124116@nexsi.com> To: Jeffrey Haas Cc: idr@merit.edu Subject: Re: Collision detect [Re-Posting] In-Reply-To: <20020129150240.E5769@nexthop.com> References: <521076821136.20020126185129@nexsi.com> <20020128114223.A2629@nexthop.com> <1981247720417.20020128181952@nexsi.com> <20020129150240.E5769@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Jeff: > Do they support unconfigured peers? Those that I've worked with do not. BTW, when you receive an incoming transport connection from an unconfigured peer first time, I guess the peer lookup will fail, which means you don't have an outstanding transport connection, and hence no risk for collision, correct? > The FSM text, even in its more current form, seems to not deal with > unconfigured peers very well. Agreed. That's why I thought it was a good idea to have a section on processing incoming transport connections and introduced it in my version of FSM. Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA13450 for ; Tue, 29 Jan 2002 15:03:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 686F991213; Tue, 29 Jan 2002 15:03:14 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 365F49127F; Tue, 29 Jan 2002 15:03:14 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1BD2891213 for ; Tue, 29 Jan 2002 15:03:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id EB7D95DDCC; Tue, 29 Jan 2002 15:03:12 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id A6B655DD8C for ; Tue, 29 Jan 2002 15:03:12 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0TK2f370459; Tue, 29 Jan 2002 15:02:41 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0TK2eI06148; Tue, 29 Jan 2002 15:02:40 -0500 (EST) Date: Tue, 29 Jan 2002 15:02:40 -0500 From: Jeffrey Haas To: Alex Zinin Cc: idr@merit.edu Subject: Re: Collision detect [Re-Posting] Message-ID: <20020129150240.E5769@nexthop.com> References: <521076821136.20020126185129@nexsi.com> <20020128114223.A2629@nexthop.com> <1981247720417.20020128181952@nexsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1981247720417.20020128181952@nexsi.com>; from azinin@nexsi.com on Mon, Jan 28, 2002 at 06:19:52PM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Mon, Jan 28, 2002 at 06:19:52PM -0800, Alex Zinin wrote: > I thought we wanted the spec to be as close to reality > as possible and there seemed to be sufficient number > of people on the list saying they don't use the two-fsm > method... Do they support unconfigured peers? The FSM text, even in its more current form, seems to not deal with unconfigured peers very well. > Alex. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA29400 for ; Tue, 29 Jan 2002 04:59:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AA1A491255; Tue, 29 Jan 2002 04:59:30 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DBA491257; Tue, 29 Jan 2002 04:59: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 EA1C491255 for ; Tue, 29 Jan 2002 04:59:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id BA9CB5DE84; Tue, 29 Jan 2002 04:59:28 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailFA10.rediffmail.com (unknown [202.54.124.179]) by segue.merit.edu (Postfix) with SMTP id 659615DE7D for ; Tue, 29 Jan 2002 04:59:27 -0500 (EST) Received: (qmail 28742 invoked by uid 510); 29 Jan 2002 10:00:07 -0000 Date: 29 Jan 2002 10:00:07 -0000 Message-ID: <20020129100007.28741.qmail@mailFA10.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 29 Jan 2002 10:00:06 -0000 MIME-Version: 1.0 From: "Raghavendran Gururajan" Reply-To: "Raghavendran Gururajan" To: idr@merit.edu Subject: Reg. Extended Communities Attribute Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id EAA29400 Hi, The BGP communities rfc (1997) talks clearly about what is to be done for communities during aggregation. "If a range of routes is to be aggregated and the resultant aggregates attribute section does not carry the ATOMIC_AGGREGATE attribute, then the resulting aggregate should have a COMMUNITIES path attribute which contains all communities from all of the aggregated routes." But the Extended communities draft (draft-ietf-idr-bgp-ext-communities-02.txt) doesnot talk about aggregation. Should the Extended communities also be aggregated or should they be dropped during aggregation as they are transitive optional attribute ? Can anyone clarify. Thanks, Raghavendran. 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 VAA19814 for ; Mon, 28 Jan 2002 21:21:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0657291212; Mon, 28 Jan 2002 21:20:49 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C05379124D; Mon, 28 Jan 2002 21:20: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 BE2C091212 for ; Mon, 28 Jan 2002 21:20:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F9CD5DD96; Mon, 28 Jan 2002 21:20:47 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [66.35.212.41]) by segue.merit.edu (Postfix) with ESMTP id F3E895DD8C for ; Mon, 28 Jan 2002 21:20:46 -0500 (EST) Received: from khonsu.sw.nexsi.com (dynam34.sw.nexsi.com [172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id SAA10715; Mon, 28 Jan 2002 18:19:52 -0800 Date: Mon, 28 Jan 2002 18:19:52 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <1981247720417.20020128181952@nexsi.com> To: Jeffrey Haas Cc: idr@merit.edu Subject: Re: Collision detect [Re-Posting] In-Reply-To: <20020128114223.A2629@nexthop.com> References: <521076821136.20020126185129@nexsi.com> <20020128114223.A2629@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Jeff: > Although it doesn't necessarily require it, IMO, the two-fsm > model seems to more cleanly fit the current text. I thought we wanted the spec to be as close to reality as possible and there seemed to be sufficient number of people on the list saying they don't use the two-fsm method... Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA05936 for ; Mon, 28 Jan 2002 11:43:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7110491243; Mon, 28 Jan 2002 11:42:35 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 154FC91244; Mon, 28 Jan 2002 11:42: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 E2E6491242 for ; Mon, 28 Jan 2002 11:42:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id CA3A25DD9B; Mon, 28 Jan 2002 11:42:31 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 8210B5DDDC for ; Mon, 28 Jan 2002 11:42:31 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0SGgM323208 for ; Mon, 28 Jan 2002 11:42:22 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0SGgNq02659 for idr@merit.edu; Mon, 28 Jan 2002 11:42:23 -0500 (EST) Date: Mon, 28 Jan 2002 11:42:23 -0500 From: Jeffrey Haas To: idr@merit.edu Subject: Re: Collision detect [Re-Posting] Message-ID: <20020128114223.A2629@nexthop.com> References: <521076821136.20020126185129@nexsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jileish@charlie.cns.iit.edu on Sun, Jan 27, 2002 at 02:30:34PM -0600 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Gentles, Please trim your headers when replying. On Sun, Jan 27, 2002 at 02:30:34PM -0600, Eric Leisheng Ji wrote: > Yes, if the new spec can list both of them for > applicable considerations, that's more clear. > > Both schemes should work fine, but the two FSM > scheme may need more coding work than one FSM > scheme. It's not a big deal if only one can get > clear picture from rfc. In both the one and two-fsm model, you have to have access to the state of the fsm's running across all of your bgp instances that share common resources. This is mostly to know what state the "other" fsm (other connection) is in. Although it doesn't necessarily require it, IMO, the two-fsm model seems to more cleanly fit the current text. > --Eric Ji -- 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 BAA21300 for ; Mon, 28 Jan 2002 01:12:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DDEB091238; Mon, 28 Jan 2002 01:11:34 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9CC291239; Mon, 28 Jan 2002 01:11: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 ABB4A91238 for ; Mon, 28 Jan 2002 01:11:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D8265DDF7; Mon, 28 Jan 2002 01:11:33 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [66.35.212.41]) by segue.merit.edu (Postfix) with ESMTP id A2E6D5DDB9 for ; Mon, 28 Jan 2002 01:11:32 -0500 (EST) Received: from khonsu.sw.nexsi.com (cscovpn1.nexsi.com [172.16.213.1]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id WAA01876; Sun, 27 Jan 2002 22:10:27 -0800 Date: Sun, 27 Jan 2002 22:10:24 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <1431175155964.20020127221024@nexsi.com> To: Russ White Cc: Russ White , Sathya Perla , "'Kunihiro Ishiguro'" , Mathew Richardson , Subject: Re: Collision detect [Re-Posting] In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk > I would agree with this approcach. Do we need text? Yeah, let's wait to see what people say about this to make sure we have a consensus on the approach and then we would need the actual text... Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA15266 for ; Sun, 27 Jan 2002 20:49:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 04DC191231; Sun, 27 Jan 2002 20:48:43 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BEC9691232; Sun, 27 Jan 2002 20:48: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 5722C91231 for ; Sun, 27 Jan 2002 20:48:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 292D95DDEA; Sun, 27 Jan 2002 20:48:41 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id D81685DDE9 for ; Sun, 27 Jan 2002 20:48:40 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id UAA05265; Sun, 27 Jan 2002 20:47:47 -0500 (EST) Date: Sun, 27 Jan 2002 20:47:47 -0500 (EST) From: Russ White Reply-To: Russ White To: Alex Zinin Cc: Sathya Perla , "'Kunihiro Ishiguro'" , Mathew Richardson , idr@merit.edu Subject: Re: Collision detect [Re-Posting] In-Reply-To: <521076821136.20020126185129@nexsi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk I would agree with this approcach. Do we need text? :-) Russ On Sat, 26 Jan 2002, Alex Zinin wrote: > I had a similar idea as well, 'cause the new spec should > cover deployed implementations with collision detection > implemented both ways (unless the two-FSM way is completely > broken, which is not the case, I believe). > > However, I think we should provide sufficient information > in the spec for guys implementing it from scratch to figure > out what really should be done. Since both ways seem to > work fine together (anyone correct me if I'm wrong here), > it might work if we document both the algorithm from > the spec and the one-FSM algorithm (seems to be that we > already have at least three of four of its implementations) > as *possible* approaches. What do you think? > > -- > Alex Zinin > > Saturday, January 26, 2002, 5:02:16 AM, Russ White wrote: > > > > It actually (probably) doesn't matter what the majority is--the > > spec should (probably) be written in such a way to make it > > obvious that you are trying to prevent two connections, and leave > > out anything that implies whether this means you use two fsm's or > > one. > > > Cisco uses one fsm. > > > :-) > > > Russ > > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA08782 for ; Sun, 27 Jan 2002 15:31:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E0F849122B; Sun, 27 Jan 2002 15:30:36 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9EA929122C; Sun, 27 Jan 2002 15:30: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 5F9719122B for ; Sun, 27 Jan 2002 15:30:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 396195DDAA; Sun, 27 Jan 2002 15:30:35 -0500 (EST) Delivered-To: idr@merit.edu Received: from csl.cs.iit.edu (csl.csam.iit.edu [216.47.150.143]) by segue.merit.edu (Postfix) with ESMTP id C7CAD5DD9D for ; Sun, 27 Jan 2002 15:30:34 -0500 (EST) Received: from charlie.cns.iit.edu (charlie.cns.iit.edu [216.47.143.70]) by csl.cs.iit.edu (8.9.3/8.9.3) with ESMTP id PAA17964; Sun, 27 Jan 2002 15:49:23 -0600 Date: Sun, 27 Jan 2002 14:30:34 -0600 From: Eric Leisheng Ji To: Alex Zinin Cc: Russ White , Russ White , Sathya Perla , "'Kunihiro Ishiguro'" , Mathew Richardson , idr@merit.edu Subject: Re: Collision detect [Re-Posting] In-Reply-To: <521076821136.20020126185129@nexsi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Yes, if the new spec can list both of them for applicable considerations, that's more clear. Both schemes should work fine, but the two FSM scheme may need more coding work than one FSM scheme. It's not a big deal if only one can get clear picture from rfc. --Eric Ji On Sat, 26 Jan 2002, Alex Zinin wrote: > I had a similar idea as well, 'cause the new spec should > cover deployed implementations with collision detection > implemented both ways (unless the two-FSM way is completely > broken, which is not the case, I believe). > > However, I think we should provide sufficient information > in the spec for guys implementing it from scratch to figure > out what really should be done. Since both ways seem to > work fine together (anyone correct me if I'm wrong here), > it might work if we document both the algorithm from > the spec and the one-FSM algorithm (seems to be that we > already have at least three of four of its implementations) > as *possible* approaches. What do you think? > > -- > Alex Zinin > > Saturday, January 26, 2002, 5:02:16 AM, Russ White wrote: > > > > It actually (probably) doesn't matter what the majority is--the > > spec should (probably) be written in such a way to make it > > obvious that you are trying to prevent two connections, and leave > > out anything that implies whether this means you use two fsm's or > > one. > > > Cisco uses one fsm. > > > :-) > > > Russ > > 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 VAA17425 for ; Sat, 26 Jan 2002 21:52:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8E8F091216; Sat, 26 Jan 2002 21:52:18 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E9CD9121D; Sat, 26 Jan 2002 21:52: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 502FD91216 for ; Sat, 26 Jan 2002 21:52:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F1CB5DE1E; Sat, 26 Jan 2002 21:52:17 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [66.35.212.41]) by segue.merit.edu (Postfix) with ESMTP id 8694B5DD8F for ; Sat, 26 Jan 2002 21:52:16 -0500 (EST) Received: from khonsu.sw.nexsi.com (cscovpn3.nexsi.com [172.16.213.3]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id SAA15803; Sat, 26 Jan 2002 18:51:29 -0800 Date: Sat, 26 Jan 2002 18:51:29 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <521076821136.20020126185129@nexsi.com> To: Russ White Cc: Russ White , Sathya Perla , "'Kunihiro Ishiguro'" , Mathew Richardson , Subject: Re: Collision detect [Re-Posting] In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk I had a similar idea as well, 'cause the new spec should cover deployed implementations with collision detection implemented both ways (unless the two-FSM way is completely broken, which is not the case, I believe). However, I think we should provide sufficient information in the spec for guys implementing it from scratch to figure out what really should be done. Since both ways seem to work fine together (anyone correct me if I'm wrong here), it might work if we document both the algorithm from the spec and the one-FSM algorithm (seems to be that we already have at least three of four of its implementations) as *possible* approaches. What do you think? -- Alex Zinin Saturday, January 26, 2002, 5:02:16 AM, Russ White wrote: > It actually (probably) doesn't matter what the majority is--the > spec should (probably) be written in such a way to make it > obvious that you are trying to prevent two connections, and leave > out anything that implies whether this means you use two fsm's or > one. > Cisco uses one fsm. > :-) > Russ 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 IAA00872 for ; Sat, 26 Jan 2002 08:03:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2F00491210; Sat, 26 Jan 2002 08:03:05 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF1C1912AD; Sat, 26 Jan 2002 08:03: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 5ABE991210 for ; Sat, 26 Jan 2002 08:03:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2E5585DDA6; Sat, 26 Jan 2002 08:03:03 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id E79775DD8D for ; Sat, 26 Jan 2002 08:03:02 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA08419; Sat, 26 Jan 2002 08:02:16 -0500 (EST) Date: Sat, 26 Jan 2002 08:02:16 -0500 (EST) From: Russ White Reply-To: Russ White To: Alex Zinin Cc: Sathya Perla , "'Kunihiro Ishiguro'" , Mathew Richardson , idr@merit.edu Subject: Re: Collision detect [Re-Posting] In-Reply-To: <101967279434.20020125122542@nexsi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk It actually (probably) doesn't matter what the majority is--the spec should (probably) be written in such a way to make it obvious that you are trying to prevent two connections, and leave out anything that implies whether this means you use two fsm's or one. Cisco uses one fsm. :-) Russ On Fri, 25 Jan 2002, Alex Zinin wrote: > > Sathya, > > In fact, that was one of my concerns about the spec. > > Regardless of whether we stay with the two-FSMs based scheme > or move to two transport connections under one, I think > we should have a section on processing of incoming transport > connection (I actually have it in my version of the FSM I sent > to the list a while ago). > > From my knowledge, at least some major implementations do not > treat competing connections as different FSMs. Whether they > make the majority or not is something that we should probably > ask the WG chairs to check. > > -- > Alex Zinin > > Wednesday, January 23, 2002, 7:18:21 PM, Sathya Perla wrote: > > > > I think the fundamental problem with Collision Detection is that the spec > > assumes (without stating it explicitly) that there are two FSMs to deal with > > the possible two transport connections between a pair of peers. This is > > evident from the usage of "FSM Cease" to close a transport connection. > > > One could manage both the transport connections using the same FSM and after > > the collision detect algorithm is run the "unwanted" transport connection > > can be closed without requiring a "FSM Cease". > > > If this is not OK, the draft should explicitly state that a separate FSM has > > to be used for a second connection with the same peer. > > > -Sathya > > > > -----Original Message----- > > From: Kunihiro Ishiguro [mailto:kunihiro@zebra.org] > > Sent: Wednesday, January 23, 2002 7:36 AM > > To: Mathew Richardson > > Cc: idr@merit.edu > > Subject: Re: Collision detect > > > >>t0: BoxA initiates TCP connection to BoxB (we'll call this connection 1) > >>t0: BoxB initiates TCP connection to BoxA (we'll call this connection 2) > >>t1: BoxA accepts incoming connection from BoxB > >>t1: BoxB accepts incoming connection from BoxA > >>t2: BoxA sends an Open message on connection 1 > >>t2: BoxB sends an Open message on connection 2 > > > When BoxA accept incoming connection 2 from BoxB, BoxA lookup > > corresponding status and it is Connect for connection 1. Here we have > > a problem. If BoxA decides which connection should be closed at this > > moment, BoxB will do the same thing. Then both connection will be > > closed. OK, to avoid this situation collision detect should be done > > by Open message then take one of them based upon router-id. (In my > > very private opinion, if jitter is there this will not happen > > frequently). Until that time the both connections should be > > maintained. > > > BTW, here is my question, when BoxA sends an Open message to BoxB > > (t2). BoxA has two connections. Connection 1 is OpenSent status. > > Connection 2 will be Connect status. But where connection 2 status > > comes from? Is that generated based upon Connection 1 status? It is > > very ambiguous in RFC and draft description. Initially the peer has > > only one status. Some moment the peer has two connections and two > > independent status. Finally collision detect close one connection. > > The status related the connection also goes away. > > > When I implemented BGP this was the biggest obstacle to understand FSM > > and collision detect. Still description is not clear. Should we fix > > this also? > > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA18878 for ; Fri, 25 Jan 2002 22:26:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 96E50912A5; Fri, 25 Jan 2002 22:25:52 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64792912A6; Fri, 25 Jan 2002 22:25: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 68C20912A5 for ; Fri, 25 Jan 2002 22:25:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 45FE85DDCC; Fri, 25 Jan 2002 22:25:51 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [66.35.212.41]) by segue.merit.edu (Postfix) with ESMTP id 5B0B75DDC1 for ; Fri, 25 Jan 2002 22:25:46 -0500 (EST) Received: from khonsu.sw.nexsi.com (cscovpn1.nexsi.com [172.16.213.1]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id TAA13054; Fri, 25 Jan 2002 19:24:53 -0800 Date: Fri, 25 Jan 2002 19:24:50 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <54992427555.20020125192450@nexsi.com> To: Susan Hares Cc: randy Bush , fenner@research.att.com, idr@merit.edu Subject: Re: bgp4-17 Cease subcode In-Reply-To: <5.0.0.25.0.20020125174652.03627f78@mail.nexthop.com> References: <5.0.0.25.0.20020117124225.042f96e0@mail.nexthop.com> <5.0.0.25.0.20020117083423.0252ef28@mail.nexthop.com> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <20020115140711.GA23937@opentransit.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <5.0.0.25.0.20020117083423.0252ef28@mail.nexthop.com> <5.0.0.25.0.20020117124225.042f96e0@mail.nexthop.com> <5.0.0.25.0.20020125174652.03627f78@mail.nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Sue, Agreed, thanks! -- Alex Zinin Friday, January 25, 2002, 2:48:02 PM, Susan Hares wrote: > Alex: > Thanks for the comments on the draft. I think > I've got the fix for this in my current version. > I'm sending it off the list so we can talk. > 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 SAA13860 for ; Fri, 25 Jan 2002 18:13:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8A088912A4; Fri, 25 Jan 2002 18:12:48 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57A94912A5; Fri, 25 Jan 2002 18:12: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 0AB2C912A4 for ; Fri, 25 Jan 2002 18:12:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id D90AD5DDC1; Fri, 25 Jan 2002 18:12:46 -0500 (EST) Delivered-To: idr@merit.edu Received: from csl.cs.iit.edu (csl.csam.iit.edu [216.47.150.143]) by segue.merit.edu (Postfix) with ESMTP id B51B15DDB4 for ; Fri, 25 Jan 2002 18:12:46 -0500 (EST) Received: from charlie.cns.iit.edu (charlie.cns.iit.edu [216.47.143.70]) by csl.cs.iit.edu (8.9.3/8.9.3) with ESMTP id SAA27708; Fri, 25 Jan 2002 18:31:59 -0600 Date: Fri, 25 Jan 2002 17:13:15 -0600 From: Eric Leisheng Ji To: Alex Zinin Cc: Sathya Perla , "'Kunihiro Ishiguro'" , Mathew Richardson , idr@merit.edu Subject: Re: Collision detect [Re-Posting] In-Reply-To: <101967279434.20020125122542@nexsi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk I think Sathya's idea is applicable. In our implementation of BGP in company, we try to follow the RFC, but get a little lost there about the FSMs, for we use only one FSM and two connections. So we still follow the RFC, but under the situation of collision detection, the received Notification Packet are just ignored. So it's equal to no sending this. I didnt' get the previous emails on this question, but it seems to me a problem how do we indicate the peer state under the picture of one FSM and two connections? we should make sure the two connections dont race to set the FSM peer state. --Eric Ji On Fri, 25 Jan 2002, Alex Zinin wrote: > > Sathya, > > In fact, that was one of my concerns about the spec. > > Regardless of whether we stay with the two-FSMs based scheme > or move to two transport connections under one, I think > we should have a section on processing of incoming transport > connection (I actually have it in my version of the FSM I sent > to the list a while ago). > > From my knowledge, at least some major implementations do not > treat competing connections as different FSMs. Whether they > make the majority or not is something that we should probably > ask the WG chairs to check. > > -- > Alex Zinin > > Wednesday, January 23, 2002, 7:18:21 PM, Sathya Perla wrote: > > > > I think the fundamental problem with Collision Detection is that the spec > > assumes (without stating it explicitly) that there are two FSMs to deal with > > the possible two transport connections between a pair of peers. This is > > evident from the usage of "FSM Cease" to close a transport connection. > > > One could manage both the transport connections using the same FSM and after > > the collision detect algorithm is run the "unwanted" transport connection > > can be closed without requiring a "FSM Cease". > > > If this is not OK, the draft should explicitly state that a separate FSM has > > to be used for a second connection with the same peer. > > > -Sathya > > > > -----Original Message----- > > From: Kunihiro Ishiguro [mailto:kunihiro@zebra.org] > > Sent: Wednesday, January 23, 2002 7:36 AM > > To: Mathew Richardson > > Cc: idr@merit.edu > > Subject: Re: Collision detect > > > >>t0: BoxA initiates TCP connection to BoxB (we'll call this connection 1) > >>t0: BoxB initiates TCP connection to BoxA (we'll call this connection 2) > >>t1: BoxA accepts incoming connection from BoxB > >>t1: BoxB accepts incoming connection from BoxA > >>t2: BoxA sends an Open message on connection 1 > >>t2: BoxB sends an Open message on connection 2 > > > When BoxA accept incoming connection 2 from BoxB, BoxA lookup > > corresponding status and it is Connect for connection 1. Here we have > > a problem. If BoxA decides which connection should be closed at this > > moment, BoxB will do the same thing. Then both connection will be > > closed. OK, to avoid this situation collision detect should be done > > by Open message then take one of them based upon router-id. (In my > > very private opinion, if jitter is there this will not happen > > frequently). Until that time the both connections should be > > maintained. > > > BTW, here is my question, when BoxA sends an Open message to BoxB > > (t2). BoxA has two connections. Connection 1 is OpenSent status. > > Connection 2 will be Connect status. But where connection 2 status > > comes from? Is that generated based upon Connection 1 status? It is > > very ambiguous in RFC and draft description. Initially the peer has > > only one status. Some moment the peer has two connections and two > > independent status. Finally collision detect close one connection. > > The status related the connection also goes away. > > > When I implemented BGP this was the biggest obstacle to understand FSM > > and collision detect. Still description is not clear. Should we fix > > this also? > > 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 RAA13378 for ; Fri, 25 Jan 2002 17:51:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6F031912A2; Fri, 25 Jan 2002 17:51:13 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3EAAF912A4; Fri, 25 Jan 2002 17:51: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 F40BB912A2 for ; Fri, 25 Jan 2002 17:51:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA8225DE5A; Fri, 25 Jan 2002 17:51:11 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 94EEC5DDB4 for ; Fri, 25 Jan 2002 17:51:11 -0500 (EST) Received: from SKH.nexthop.com (snrc-roam1.Stanford.EDU [171.64.94.129]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0PMoc313681; Fri, 25 Jan 2002 17:50:39 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020125174652.03627f78@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 25 Jan 2002 17:48:02 -0500 To: Alex Zinin From: Susan Hares Subject: Re: bgp4-17 Cease subcode Cc: Susan Hares , randy Bush , fenner@research.att.com, idr@merit.edu In-Reply-To: <196272995176.20020117113403@nexsi.com> References: <5.0.0.25.0.20020117124225.042f96e0@mail.nexthop.com> <5.0.0.25.0.20020117083423.0252ef28@mail.nexthop.com> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <20020115140711.GA23937@opentransit.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <5.0.0.25.0.20020117083423.0252ef28@mail.nexthop.com> <5.0.0.25.0.20020117124225.042f96e0@mail.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Alex: Thanks for the comments on the draft. I think I've got the fix for this in my current version. I'm sending it off the list so we can talk. Sue At 11:34 AM 1/17/2002 -0800, Alex Zinin wrote: >Sue, > > > 1) Thanks for your note. > > > Glad you think the bgp exponential back off is good. > > > We should get operator input to answer questions in #3. > > I want to go with whatever the operator community has > > deployed for this draft. > >OK. > > > 2) State machine text clean up was more than > > the Idle Hold state > > > Just to let you know the FSM text was tighted up based on the > > word document with the diagram I sent out. There were other > > inconsistencies in the FSM that I fixed based on the states > > not being consistent with this diagram. > >I understand, I meant the text about exp. back-off specifically >should be all right. > > > I will generate the state machine table without > > the idle hold state to indicate those differences first. > > [Warning - this plus the 2 other state machines you > > sent me to review will take me a while. Warning -- day turnaround > > most likely] > >All right, thanks. I think I'll send my version out to the list >today to get the feeling of what people think. > > > 3)bgp exponential back-off > >[stuff for SPs ;) ] > > > 4) comparing all your input --- still processing > > > I am plugging through the 2 versions of state > > machine you sent. Did you send me a review > > of the diagram (word document) I'm attaching again. > > > I didn't find that even though you mentioned > > you had done it. Did I miss it? That would > > speed up this process since a 5 page form is quicker to > > review and glance over. > >Sue, I've briefly gone through several states in >the table and had some questions and bugs: > >Event 3 (IdleHold expired, value under ceiling): I think this > event should be ignored in Idle and higher > >Idle x 3: "FSM Error" is not an action, is it? > >Event 4: This event should be ignored in Idle and higher as well > >Connect x 7: There's no associated transport session yet, > the event should be ignored > >OpenSent x 8: Ignore here? > >Event 9: Should be Rcv TCP Connect & peer accepted > >Connect x 9: Why incoming connection resets the FSM here? > >OpenSent x 9: Ignore here? > >Event 10: Should be Rcv TCP Connect & peer rejected > >Connect x 10: Why incoming connection resets the FSM here? > >OpenSent x 10: Ignore here? > >Connect x 11: Hold timer is not running here, ignore? > >Idle x 12: Idle here? > >Connect x 12: Events from here down should be ignored? > >IdleHold x 22: Should it be ignored and stay in IdleHold? > >Idle x 23: Idle/Ignore here? > >And probably the major one: there's no event that causes >OpenSent->OpenConfirmed transition... Here I stopped. >You should probably take another look and see if the >table is generated correctly. > >Thanks. > >Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA12122 for ; Fri, 25 Jan 2002 16:51:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CCEE59121C; Fri, 25 Jan 2002 16:51:20 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98DC7912A0; Fri, 25 Jan 2002 16:51: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 722BA9121C for ; Fri, 25 Jan 2002 16:51:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4FFB05DE59; Fri, 25 Jan 2002 16:51:19 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 3792D5DDB4 for ; Fri, 25 Jan 2002 16:51:19 -0500 (EST) Received: from SKH.nexthop.com (snrc-roam1.Stanford.EDU [171.64.94.129]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0PLod311546; Fri, 25 Jan 2002 16:50:39 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020125165016.0349f128@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 25 Jan 2002 16:50:38 -0500 To: Alain Durand From: Susan Hares Subject: Re: IPv6 Router ID draft Cc: Francis Dupont , Jeffrey Haas , idr@merit.edu In-Reply-To: <3C51A847.9B5A34FA@eng.sun.com> References: <200201251830.g0PIUOg17209@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Did this get used in any KAME or other IP v6 trials? Sue At 10:47 AM 1/25/2002 -0800, Alain Durand wrote: >Francis Dupont wrote: > > > In your previous mail you wrote: > > > > For a BCP, doesn't it have to be well-deployed first? > > > > => this is a chicken and egg problem: if it is not published, > > then it is not yet known, then it can't be well-deployed. > > I have a proof of the first consequence by a mail in the zebra list: > > "I am IPv6 only, what may I put in the config for the router-ID?" > >I just checked what RFC2026 says on BCP: > >5. BEST CURRENT PRACTICE (BCP) RFCs > > The BCP subseries of the RFC series is designed to be a way to > standardize practices and the results of community deliberations. A > BCP document is subject to the same basic set of procedures as > standards track documents and thus is a vehicle by which the IETF > community can define and ratify the community's best current thinking > > on a statement of principle or on what is believed to be the best way > > to perform some operations or IETF process function. > >==> The key sentece here is "ratify the community's best current >thinking" > This indicates to me that BCP is the right approach. > > - Alain. 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 PAA10114 for ; Fri, 25 Jan 2002 15:27:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 24D5B9129E; Fri, 25 Jan 2002 15:26:58 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EAA899129F; Fri, 25 Jan 2002 15:26:57 -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 D687E9129E for ; Fri, 25 Jan 2002 15:26:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id BCADD5DE4C; Fri, 25 Jan 2002 15:26:56 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [66.35.212.41]) by segue.merit.edu (Postfix) with ESMTP id 95AF85DDB4 for ; Fri, 25 Jan 2002 15:26:50 -0500 (EST) Received: from khonsu.sw.nexsi.com (dynam34.sw.nexsi.com [172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id MAA10442; Fri, 25 Jan 2002 12:25:45 -0800 Date: Fri, 25 Jan 2002 12:25:42 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <101967279434.20020125122542@nexsi.com> To: Sathya Perla Cc: "'Kunihiro Ishiguro'" , Mathew Richardson , Subject: Re: Collision detect [Re-Posting] In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Sathya, In fact, that was one of my concerns about the spec. Regardless of whether we stay with the two-FSMs based scheme or move to two transport connections under one, I think we should have a section on processing of incoming transport connection (I actually have it in my version of the FSM I sent to the list a while ago). From my knowledge, at least some major implementations do not treat competing connections as different FSMs. Whether they make the majority or not is something that we should probably ask the WG chairs to check. -- Alex Zinin Wednesday, January 23, 2002, 7:18:21 PM, Sathya Perla wrote: > I think the fundamental problem with Collision Detection is that the spec > assumes (without stating it explicitly) that there are two FSMs to deal with > the possible two transport connections between a pair of peers. This is > evident from the usage of "FSM Cease" to close a transport connection. > One could manage both the transport connections using the same FSM and after > the collision detect algorithm is run the "unwanted" transport connection > can be closed without requiring a "FSM Cease". > If this is not OK, the draft should explicitly state that a separate FSM has > to be used for a second connection with the same peer. > -Sathya > -----Original Message----- > From: Kunihiro Ishiguro [mailto:kunihiro@zebra.org] > Sent: Wednesday, January 23, 2002 7:36 AM > To: Mathew Richardson > Cc: idr@merit.edu > Subject: Re: Collision detect >>t0: BoxA initiates TCP connection to BoxB (we'll call this connection 1) >>t0: BoxB initiates TCP connection to BoxA (we'll call this connection 2) >>t1: BoxA accepts incoming connection from BoxB >>t1: BoxB accepts incoming connection from BoxA >>t2: BoxA sends an Open message on connection 1 >>t2: BoxB sends an Open message on connection 2 > When BoxA accept incoming connection 2 from BoxB, BoxA lookup > corresponding status and it is Connect for connection 1. Here we have > a problem. If BoxA decides which connection should be closed at this > moment, BoxB will do the same thing. Then both connection will be > closed. OK, to avoid this situation collision detect should be done > by Open message then take one of them based upon router-id. (In my > very private opinion, if jitter is there this will not happen > frequently). Until that time the both connections should be > maintained. > BTW, here is my question, when BoxA sends an Open message to BoxB > (t2). BoxA has two connections. Connection 1 is OpenSent status. > Connection 2 will be Connect status. But where connection 2 status > comes from? Is that generated based upon Connection 1 status? It is > very ambiguous in RFC and draft description. Initially the peer has > only one status. Some moment the peer has two connections and two > independent status. Finally collision detect close one connection. > The status related the connection also goes away. > When I implemented BGP this was the biggest obstacle to understand FSM > and collision detect. Still description is not clear. Should we fix > this also? 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 OAA08455 for ; Fri, 25 Jan 2002 14:24:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D0A799129B; Fri, 25 Jan 2002 14:24:07 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A45EE9129C; Fri, 25 Jan 2002 14:24: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 77EE89129B for ; Fri, 25 Jan 2002 14:24:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 525E65DE47; Fri, 25 Jan 2002 14:24:06 -0500 (EST) Delivered-To: idr@merit.edu Received: from miata.procket.com (miata.procket.com [65.174.124.5]) by segue.merit.edu (Postfix) with ESMTP id B1CD75DDB4 for ; Fri, 25 Jan 2002 14:24:05 -0500 (EST) Received: from alpha-tli.procket.com (IDENT:root@alpha-tli.procket.com [10.2.3.1]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id g0PJNieR024465; Fri, 25 Jan 2002 11:23:44 -0800 (PST) Received: (from tli@localhost) by alpha-tli.procket.com (8.12.1/8.12.1) id g0PJNgpp011855; Fri, 25 Jan 2002 11:23:42 -0800 From: Tony Li MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15441.45246.749900.849675@alpha-tli.procket.com> Date: Fri, 25 Jan 2002 11:23:42 -0800 To: Alain Durand Cc: Francis Dupont , Jeffrey Haas , idr@merit.edu Subject: Re: IPv6 Router ID draft In-Reply-To: <3C51A847.9B5A34FA@eng.sun.com> References: <200201251830.g0PIUOg17209@givry.rennes.enst-bretagne.fr> <3C51A847.9B5A34FA@eng.sun.com> X-Mailer: VM 6.92 under Emacs 20.5.1 Sender: owner-idr@merit.edu Precedence: bulk It seems to me that it needs to be a 'practice' before it can reasonably be the 'best current' practice. Tony 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 NAA07300 for ; Fri, 25 Jan 2002 13:49:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9A5BF91201; Fri, 25 Jan 2002 13:48:38 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 644B09129B; Fri, 25 Jan 2002 13:48: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 2D49091201 for ; Fri, 25 Jan 2002 13:48:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0CAC15DE3A; Fri, 25 Jan 2002 13:48:37 -0500 (EST) Delivered-To: idr@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 63F325DDB4 for ; Fri, 25 Jan 2002 13:48:34 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04563; Fri, 25 Jan 2002 11:48:05 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id KAA02345; Fri, 25 Jan 2002 10:49:29 -0800 (PST) Received: from eng.sun.com (sappey.Eng.Sun.COM [129.146.85.69]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0PIm53f113633; Fri, 25 Jan 2002 10:48:05 -0800 (PST) Message-ID: <3C51A847.9B5A34FA@eng.sun.com> Date: Fri, 25 Jan 2002 10:47:35 -0800 From: Alain Durand X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont Cc: Jeffrey Haas , idr@merit.edu Subject: Re: IPv6 Router ID draft References: <200201251830.g0PIUOg17209@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Francis Dupont wrote: > In your previous mail you wrote: > > For a BCP, doesn't it have to be well-deployed first? > > => this is a chicken and egg problem: if it is not published, > then it is not yet known, then it can't be well-deployed. > I have a proof of the first consequence by a mail in the zebra list: > "I am IPv6 only, what may I put in the config for the router-ID?" I just checked what RFC2026 says on BCP: 5. BEST CURRENT PRACTICE (BCP) RFCs The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. A BCP document is subject to the same basic set of procedures as standards track documents and thus is a vehicle by which the IETF community can define and ratify the community's best current thinking on a statement of principle or on what is believed to be the best way to perform some operations or IETF process function. ==> The key sentece here is "ratify the community's best current thinking" This indicates to me that BCP is the right approach. - Alain. 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 KAA02398 for ; Fri, 25 Jan 2002 10:57:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 253BA91295; Fri, 25 Jan 2002 10:57:17 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DCD0A91296; Fri, 25 Jan 2002 10:57:16 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CECFA91295 for ; Fri, 25 Jan 2002 10:57:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id AFC7D5DE3C; Fri, 25 Jan 2002 10:57:05 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 69DC55DE3A for ; Fri, 25 Jan 2002 10:57:05 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0PFuX399726; Fri, 25 Jan 2002 10:56:33 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0PFuWn26900; Fri, 25 Jan 2002 10:56:32 -0500 (EST) Date: Fri, 25 Jan 2002 10:56:32 -0500 From: Jeffrey Haas To: Mareline Sheldon Cc: idr@merit.edu Subject: Re: Route Reflectors Message-ID: <20020125105632.H26734@nexthop.com> References: <20020125051502.6289.qmail@web20304.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: <20020125051502.6289.qmail@web20304.mail.yahoo.com>; from marelines@yahoo.com on Thu, Jan 24, 2002 at 09:15:02PM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk >From RFC 2796: : When a RR reflects a route, it must prepend the local CLUSTER_ID to : the CLUSTER_LIST. If the CLUSTER_LIST is empty, it must create a new : one. Using this attribute an RR can identify if the routing : information is looped back to the same cluster due to mis- : configuration. If the local CLUSTER_ID is found in the cluster-list, : the advertisement received should be ignored. In other words, it must always prepend the cluster_id when it reflects a route. On Thu, Jan 24, 2002 at 09:15:02PM -0800, Mareline Sheldon wrote: > Hi, > Whenever a RR reflects a route from its clients to a > non client, it must create a new cluster list adding > its own cluster ID if it is already not present. > > My doubt is that will RR add its cluster ID when it > receives a route from its EBGP peer and is now > advertising this route to its other non > clients/clients? > > Regards, > mareline s. -- 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 KAA02320 for ; Fri, 25 Jan 2002 10:53:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9A25F91292; Fri, 25 Jan 2002 10:53:24 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BD5C91295; Fri, 25 Jan 2002 10:53:24 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 10A9C91292 for ; Fri, 25 Jan 2002 10:53:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id DCE2D5DE43; Fri, 25 Jan 2002 10:53:22 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 95C9B5DE3C for ; Fri, 25 Jan 2002 10:53:22 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0PFr5399607; Fri, 25 Jan 2002 10:53:06 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0PFr4R26892; Fri, 25 Jan 2002 10:53:04 -0500 (EST) Date: Fri, 25 Jan 2002 10:53:04 -0500 From: Jeffrey Haas To: Alain Durand Cc: idr@merit.edu, francis.dupont@rennes.enst-bretagne.fr Subject: Re: IPv6 Router ID draft Message-ID: <20020125105304.G26734@nexthop.com> References: <3C45D218.B037BB42@eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C45D218.B037BB42@eng.sun.com>; from alain.durand@eng.sun.com on Wed, Jan 16, 2002 at 11:18:48AM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk For a BCP, doesn't it have to be well-deployed first? On Wed, Jan 16, 2002 at 11:18:48AM -0800, Alain Durand wrote: > I just published draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt > and I would like to request this working group to consider it as > a wg item candidate for BCP. > > - Alain. -- 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 AAA18245 for ; Fri, 25 Jan 2002 00:15:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1E0589128D; Fri, 25 Jan 2002 00:15:16 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D74A99128E; Fri, 25 Jan 2002 00:15:15 -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 8F1E69128D for ; Fri, 25 Jan 2002 00:15:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id C5D5F5DE31; Fri, 25 Jan 2002 00:15:09 -0500 (EST) Delivered-To: idr@merit.edu Received: from web20304.mail.yahoo.com (web20304.mail.yahoo.com [216.136.226.85]) by segue.merit.edu (Postfix) with SMTP id F174D5DE3A for ; Fri, 25 Jan 2002 00:15:08 -0500 (EST) Message-ID: <20020125051502.6289.qmail@web20304.mail.yahoo.com> Received: from [203.200.20.226] by web20304.mail.yahoo.com via HTTP; Thu, 24 Jan 2002 21:15:02 PST Date: Thu, 24 Jan 2002 21:15:02 -0800 (PST) From: Mareline Sheldon Subject: Route Reflectors To: idr@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hi, Whenever a RR reflects a route from its clients to a non client, it must create a new cluster list adding its own cluster ID if it is already not present. My doubt is that will RR add its cluster ID when it receives a route from its EBGP peer and is now advertising this route to its other non clients/clients? Regards, mareline s. __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.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 WAA12012 for ; Wed, 23 Jan 2002 22:19:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 55FE79126E; Wed, 23 Jan 2002 22:18:43 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25EA991281; Wed, 23 Jan 2002 22:18: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 DF1929126E for ; Wed, 23 Jan 2002 22:18:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id B27B85DD98; Wed, 23 Jan 2002 22:18:41 -0500 (EST) Delivered-To: idr@merit.edu Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by segue.merit.edu (Postfix) with ESMTP id 2F78F5DD92 for ; Wed, 23 Jan 2002 22:18:41 -0500 (EST) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jan 2002 22:18:40 -0500 Message-ID: From: Sathya Perla To: "'Kunihiro Ishiguro'" , Mathew Richardson Cc: idr@merit.edu Subject: RE: Collision detect [Re-Posting] Date: Wed, 23 Jan 2002 22:18:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idr@merit.edu Precedence: bulk I think the fundamental problem with Collision Detection is that the spec assumes (without stating it explicitly) that there are two FSMs to deal with the possible two transport connections between a pair of peers. This is evident from the usage of "FSM Cease" to close a transport connection. One could manage both the transport connections using the same FSM and after the collision detect algorithm is run the "unwanted" transport connection can be closed without requiring a "FSM Cease". If this is not OK, the draft should explicitly state that a separate FSM has to be used for a second connection with the same peer. -Sathya -----Original Message----- From: Kunihiro Ishiguro [mailto:kunihiro@zebra.org] Sent: Wednesday, January 23, 2002 7:36 AM To: Mathew Richardson Cc: idr@merit.edu Subject: Re: Collision detect >t0: BoxA initiates TCP connection to BoxB (we'll call this connection 1) >t0: BoxB initiates TCP connection to BoxA (we'll call this connection 2) >t1: BoxA accepts incoming connection from BoxB >t1: BoxB accepts incoming connection from BoxA >t2: BoxA sends an Open message on connection 1 >t2: BoxB sends an Open message on connection 2 When BoxA accept incoming connection 2 from BoxB, BoxA lookup corresponding status and it is Connect for connection 1. Here we have a problem. If BoxA decides which connection should be closed at this moment, BoxB will do the same thing. Then both connection will be closed. OK, to avoid this situation collision detect should be done by Open message then take one of them based upon router-id. (In my very private opinion, if jitter is there this will not happen frequently). Until that time the both connections should be maintained. BTW, here is my question, when BoxA sends an Open message to BoxB (t2). BoxA has two connections. Connection 1 is OpenSent status. Connection 2 will be Connect status. But where connection 2 status comes from? Is that generated based upon Connection 1 status? It is very ambiguous in RFC and draft description. Initially the peer has only one status. Some moment the peer has two connections and two independent status. Finally collision detect close one connection. The status related the connection also goes away. When I implemented BGP this was the biggest obstacle to understand FSM and collision detect. Still description is not clear. Should we fix this also? -- Kunihiro Ishiguro Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA00767 for ; Tue, 22 Jan 2002 22:04:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D9BDF9126C; Tue, 22 Jan 2002 22:04:23 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A57BE9126D; Tue, 22 Jan 2002 22:04: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 995489126C for ; Tue, 22 Jan 2002 22:04:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A41E5DE01; Tue, 22 Jan 2002 22:04:22 -0500 (EST) Delivered-To: idr@merit.edu Received: from titanium.zebra.org (unknown [209.11.132.18]) by segue.merit.edu (Postfix) with ESMTP id D77F25DDFD for ; Tue, 22 Jan 2002 22:04:21 -0500 (EST) Received: from titanium.zebra.org (IDENT:kunihiro@localhost [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id VAA00924; Tue, 22 Jan 2002 21:06:29 -0500 Date: Tue, 22 Jan 2002 18:06:29 -0800 Message-ID: From: Kunihiro Ishiguro To: Mathew Richardson Cc: idr@merit.edu Subject: Re: Collision detect In-Reply-To: <20020122201914.B18992@nexthop.com> References: User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.1 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk >t0: BoxA initiates TCP connection to BoxB (we'll call this connection 1) >t0: BoxB initiates TCP connection to BoxA (we'll call this connection 2) >t1: BoxA accepts incoming connection from BoxB >t1: BoxB accepts incoming connection from BoxA >t2: BoxA sends an Open message on connection 1 >t2: BoxB sends an Open message on connection 2 When BoxA accept incoming connection 2 from BoxB, BoxA lookup corresponding status and it is Connect for connection 1. Here we have a problem. If BoxA decides which connection should be closed at this moment, BoxB will do the same thing. Then both connection will be closed. OK, to avoid this situation collision detect should be done by Open message then take one of them based upon router-id. (In my very private opinion, if jitter is there this will not happen frequently). Until that time the both connections should be maintained. BTW, here is my question, when BoxA sends an Open message to BoxB (t2). BoxA has two connections. Connection 1 is OpenSent status. Connection 2 will be Connect status. But where connection 2 status comes from? Is that generated based upon Connection 1 status? It is very ambiguous in RFC and draft description. Initially the peer has only one status. Some moment the peer has two connections and two independent status. Finally collision detect close one connection. The status related the connection also goes away. When I implemented BGP this was the biggest obstacle to understand FSM and collision detect. Still description is not clear. Should we fix this also? -- Kunihiro Ishiguro Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA27217 for ; Tue, 22 Jan 2002 20:22:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A25AA9126A; Tue, 22 Jan 2002 20:22:17 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 702069126B; Tue, 22 Jan 2002 20:22: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 4FAAB9126A for ; Tue, 22 Jan 2002 20:22:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2FF235DDE8; Tue, 22 Jan 2002 20:22:16 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id DC5F65DD8D for ; Tue, 22 Jan 2002 20:22:15 -0500 (EST) Received: from paradigm.nexthop.com (mrichardson.nexthop.com [64.211.218.45]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0N1Lv389104 for ; Tue, 22 Jan 2002 20:21:57 -0500 (EST) (envelope-from mrr@nexthop.com) Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.0) id g0N1JEF06788 for idr@merit.edu; Tue, 22 Jan 2002 20:19:14 -0500 (EST) Date: Tue, 22 Jan 2002 20:19:14 -0500 From: Mathew Richardson To: idr@merit.edu Subject: Re: Collision detect Message-ID: <20020122201914.B18992@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from kunihiro@zebra.org on Tue, Jan 22, 2002 at 04:18:14PM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk > Kunihiro Ishiguro [Tue, Jan 22, 2002 at 04:18:14PM -0800]: >I have another point of question for BGP4 specification. When the >local system does not allow unconfigured peer to accept. I think the >local system does not need collision detect. > >I'm not sure when the local system connect operation is not atomic. >Any comments are welcome. t0: BoxA initiates TCP connection to BoxB (we'll call this connection 1) t0: BoxB initiates TCP connection to BoxA (we'll call this connection 2) t1: BoxA accepts incoming connection from BoxB t1: BoxB accepts incoming connection from BoxA t2: BoxA sends an Open message on connection 1 t2: BoxB sends an Open message on connection 2 ... etc ... 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 UAA26967 for ; Tue, 22 Jan 2002 20:16:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3E37891269; Tue, 22 Jan 2002 20:16:14 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 100AA9126A; Tue, 22 Jan 2002 20:16: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 545F091269 for ; Tue, 22 Jan 2002 20:16:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 270CE5DDE8; Tue, 22 Jan 2002 20:16:11 -0500 (EST) Delivered-To: idr@merit.edu Received: from titanium.zebra.org (unknown [209.11.132.18]) by segue.merit.edu (Postfix) with ESMTP id 95BE15DD8D for ; Tue, 22 Jan 2002 20:16:10 -0500 (EST) Received: from titanium.zebra.org (IDENT:kunihiro@localhost [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id TAA00688 for ; Tue, 22 Jan 2002 19:18:14 -0500 Date: Tue, 22 Jan 2002 16:18:14 -0800 Message-ID: From: Kunihiro Ishiguro To: idr@merit.edu Subject: Collision detect User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.1 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk I have another point of question for BGP4 specification. When the local system does not allow unconfigured peer to accept. I think the local system does not need collision detect. I'm not sure when the local system connect operation is not atomic. Any comments are welcome. -- Kunihiro Ishiguro Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA23304 for ; Tue, 22 Jan 2002 18:26:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DC79691267; Tue, 22 Jan 2002 18:26:22 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC3AF91268; Tue, 22 Jan 2002 18:26: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 83B2491267 for ; Tue, 22 Jan 2002 18:26:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6578C5DDE0; Tue, 22 Jan 2002 18:26:21 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 1C06E5DD8D for ; Tue, 22 Jan 2002 18:26:21 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0MNPf385705; Tue, 22 Jan 2002 18:25:42 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020121130542.01dcce38@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 22 Jan 2002 18:24:47 -0500 To: Kunihiro Ishiguro From: Susan Hares Subject: Re: Comments on FSM Cc: Alex Zinin , idr@merit.edu, Susan Hares In-Reply-To: References: <195204309992.20020116162916@nexsi.com> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <87advfjcqi.wl@vaio.zebra.org> <5.0.0.25.0.20020116181115.03ea46f8@mail.nexthop.com> <195204309992.20020116162916@nexsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Kunihiro: Thanks for the input. Sue At 04:54 PM 1/16/2002 -0800, Kunihiro Ishiguro wrote: >Thanks Alex. I've check bgp4-17 FSM. Below new items are added. > >Status : IdleHold >Timer : IdleHold timer >Variable: IdleHoldtimer > IdleHoldtimer ceiling mentioned as "local limit" > ConnectRetryCnt >Event : Manual start > Auto start >Flag : Keep Idle > >Instead of IdleHold timer we should explicitly mention about Start >timer. It is already implicitly used in RFC1771. It is almost same >as IdleHold timer but hopefully does not have impact on current >implementation. > >We don't need Keep Idle flag. Instead of that just stop Start timer. >This mechanism can be used not only exponential backoff but also >administratively shutdown or maximum prefix overflow. So let's keep >it simple. >In IdleHold state there is a description for local limit of >IdleHoldTimer. > > > Upon entering the Idle Hold state, if the IdleHoldTimer exceeds > > the local limit the "Keep Idle" flag is set. > >This should be clearly defined. For example StartTimer Ceiling. > >Difference between manual start and auto start is small. I'm not sure >separating Start event into Manual start event and Auto start event is >good idea or not. So my proposal is liek this. > >Status : No new status >Timer : Start timer >Variable: StartTimer > StartTimer Ceiling > Connect Retry Count > >(Possible addition >Event : Manual start > Auto start) > >IMHO, this topic needs more discussion and clarification. > > >Maybe the exponential backoff parts could be published as a separate draft > >instead of including it in the base specification? > >I agrree with Greg. A separate draft for exponential back off make >sense. I think even we have a separate draft for exponential back >off, previous draft bgp4-16 FSM description still work fine with that. >-- >Kunihiro Ishiguro Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA22569 for ; Tue, 22 Jan 2002 18:02:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BFCEB91266; Tue, 22 Jan 2002 18:01:43 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 836FF91267; Tue, 22 Jan 2002 18:01: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 4893491266 for ; Tue, 22 Jan 2002 18:01:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 178685DDE0; Tue, 22 Jan 2002 18:01:42 -0500 (EST) Delivered-To: idr@merit.edu Received: from omta01.mta.everyone.net (sitemail3.everyone.net [216.200.145.37]) by segue.merit.edu (Postfix) with ESMTP id 860A65DDA3 for ; Tue, 22 Jan 2002 18:01:41 -0500 (EST) Received: from sitemail.everyone.net (reports [216.200.145.62]) by omta01.mta.everyone.net (Postfix) with ESMTP id 1E27C1C448C; Tue, 22 Jan 2002 15:01:41 -0800 (PST) Received: by sitemail.everyone.net (Postfix, from userid 99) id E854C3ED3; Tue, 22 Jan 2002 15:01:21 -0800 (PST) Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Mailer: MIME-tools 5.41 (Entity 5.404) Date: Tue, 22 Jan 2002 15:01:21 -0800 (PST) From: Santosh B To: Alex Zinin , idr@merit.edu Subject: Re: More thoughts on FSM Reply-To: santoshb@linuxwaves.com X-Originating-Ip: [169.144.118.138] Message-Id: <20020122230121.E854C3ED3@sitemail.everyone.net> Sender: owner-idr@merit.edu Precedence: bulk This looks good. Here are some of my suggestions: 1. State events listed in tabular format will also give detailed view of the FSM. So there should be a FSM diagram and a table. 2. I'm not sure if the naming convention used ( ev and st prefexis ) are required. 3. I also would like to add some interaction diagrams: for example: Speaker1 Speaker2 | | | KEEPALIVE | +---------------------------->+ | | 4. I'm not sure if this is the right place but still want to put forward my suggestion. We do not have FSMs in Dampening RFC. We should add FSM in dampening draft as well ( and their relation to BGP states if any ) Thanks Santosh --- Alex Zinin wrote: >Folks, > > I mentioned multiple times that I'd like the FSM to > be represented in a more formal way. Below is what > I have in mind. It is just a scratch, by no means > complete. I'd like to know what people think about > the idea. If there's a common feeling that this > would be useful, I would invest more time in it... > >-- >Alex. > >1. Session attributes > > The following attributes required for FSM operation are associated > with each BGP session: > > State: > Indicates the current state of the BGP session FSM. > Possible FSM states are described in Section 3. > > Start timer: > A timer used for automatic generation of the evStart > event. > > ConnectRetry timer: > A timer used for periodic initialization of an outgoing > transport session when FSM is in stConnected and stActive > states. Expiration of this timer triggers generation of > the evConnectRetryExp FSM event. > > NOTE: The exact value of the ConnectRetry timer is a > local matter, but it should be sufficiently large > to allow TCP initialization. > > HoldTime: > Period of time negotiated between BGP peers and used to > detect unreachable speakers. If no UPDATE or KEEPALIVE > message has been received through a BGP session during > the HoldTime period, the remote peer is declared unreachable > and the session is reset. > > Hold timer: > A one shot timer initialized with HoldTime value and > indicating that no valid messages have been received > through the BGP session. Expiration of this timer > triggers generation of the evHoldTimerExp FSM event. > > NOTE: If the negotiated HoldTime value is zero, > the Hold timer is not started. > > KeepAlive timer: > A periodic timer used to send a KEEPALIVE message to > the remote BGP peer if no UPDATE message have been > sent to it within a period of time (the timer is reset > every time an UPDATE message is sent out). > > NOTE: If the negotiated HoldTime value is zero, the > KeepAlive timer is not started. > >2. Events: > > Timer-based events: > > evKeepAliveTimerExp: > A periodic event generated due to expiration of > the KeepAlive timer. This event is processed in > FSM states stOpenConfirmed and stEstablished and > triggers transmition of a KEEPALIVE message. > > evConnectRetryExp: > An event triggered by expiration of the ConnectRetry > timer. Processed in states stConnect and stActive, > this event leads to initiation of an outbound transport > session. > > evHoldTimerExp: > An event generated when the session's HoldTimer expires. > Processed in states stOpenConfirmed and higher, this > event indicates that no UPDATE or KEEPALIVE messages > have been received from the peer and the FSM needs to > be reset. > > > Message-processing related events: > > > evTransSucc: > An event indicating that the oubound transport session > initiated previously has been successfully established. > > evTransFail: > An event indicating that the oubound transport session > initiated previously could not be established. > > evTransDisc: > An event indicating that the transport session associated > with the FSM instance has been disconnected. > > evOpenMsgRcvd: > An event indicating that a valid OPEN message has been > received and no connection collision has been detected. > > evOpenMsgErr: > An event indicating that received OPEN messages is not > correct. > > evCollision: > An event generated when a connection collision has been > detected while processing an incoming OPEN message. > See section XXX for more information on collision detection. > > evNotifMsg: > An event triggered by reception of a NOTIFICATION message. > > evNotifMsgVerErr: > An event generated when a NOTIFICATION message with "Version > Error" code is received. > > evKeepAliveMsg: > An event generated when a KEEPALIVE message is received. > > evUpdateMsg: > An event indicating that an UPDATE message has been received > > evUpdateMsgErr: > An event indicating that received UPDATE message is not correct. > > > Administrative events: > > evStart: > An event initiated by an operator or the system in response > to Start timer expiration to initiate the BGP session > establishment procedure. This event affects only sessions > in the stIdle state and is ignored in others. > > If this event is generated automatically, then persistent BGP > errors may result in persistent flapping of a BGP session. > To avoid such a condition it is recommended that evStart events > are not generated immediately for a session that was previously > transitioned to stIdle due to an error. For a session that was > previously transitioned to stIdle due to an error, the time > between consecutive generation of evStart events, if such events > are generated automatically, should exponentially increase. The > value of the initial timer should be 60 seconds. The time should > be doubled for each consecutive retry. > > evStopManual: > An event initiated by an operator and indicating that the > BGP session should be administratively torn down. > > evStopAuto: > An event generated by the system to bring a BGP session down. > An example when this event can be generated is exceeding > the maximum number of prefixes allowed for a given peer. > > XXX: we could combine evStopManual and evStopAuto in one. > > >3. States > > A BGP speaker creates an instance of a BGP session FSM for each > configured peer. It may also be created dynamically when an incoming > transport connection is reported, there's no matching configured peer > and the speaker is configured to accept such connections. FSMs created > for configured peers are initially put in the Idle state. See section > XXX for more information on incoming transport connection processing. > > Each state is described below, including the list of processed > and ignored events. Also, a list of actions performed when > the FSM transitions to a specific state is provided (In-Actions). > For some states, a list of actions performed when transitioning > from the state is included (Out-Actions). > > stIdle: > > This is the initial state of the FSM. This state is also > used to keep BGP sessions in the inactive state when > necessary. An evStart event (manual or automatic) is necessary > to get the FSM out of the Idle state. > > Valid events : evStart > Ignored events : all others > Ivalid events : None > > In-Actions: > > 1. If transitioning from a higher state: > > o If the associated transport connection is open, > close it. > > o Stop all timers except for the Start timer > > o Release resources allocated for the session, > including invalidation of all routes possibly > received from the peer > > 2. Start the Start timer. See Section XXX for more info. > > stConnect: > In this state, BGP has initiated an outbound transport > connection and is waiting for it to be completed. > > Valid events : evConnectRetryExp, evTransSucc, > evTransFail, evStopManual, > evStopAuto > > Ignored events : evStart > Invalid events : all others > > In-Actions: > > 1. If necessary (e.g., previous state is Idle), > initialize resources for the BGP session > > 2. Start (or restart if already running) > the ConnectRetry timer. > > 3. Initiate a transport connection to the peer. > > 4. Listen (or continue listening) for a connection > that may be initiated by the peer > > stActive: > In this state BGP is not actively initiating an outbound > transport connection, but is trying to acquire a peer > by listening for and accepting an incoming one. > > Valid events : evConnectRetryExp, evTransSucc > evStopManual, evStopAuto > > Ignored events : evStart > > Invalid events : all others > > In-Actions: > > 1. If necessary, close the transport connection > > 2. Restart the ConnectRetry timer > > 3. Continue to listen for a connection that may be > initiated by the remote BGP peer > > stOpenSent: > In this state, the local system has sent out an OPEN > messages and awaits an OPEN message from the peer. > > Valid events : evOpenMsgRcvd, evNotifMsg, > evStopManual, evStopAuto > evHoldTimerExp > > Ignored events : evStart > > Invalid events : all others > > In-Actions: > > 1. Stop the ConnectRetry timer > > 2. Complete session initialization (don't know > what this really means spec-wise) > > 3. Send an OPEN message to the peer > > 4. Set Hold timer to a large value (see note below) > > 5. Stop listening for an incoming transort connection > > NOTE: A hold timer value of 4 minutes is suggested. > > > stOpenConfirm: > In this state, the local system has received an OPEN message > from the peer, confirmed its reception by sending out > a KEEPALIVE message, and awaits an incoming KEEPALIVE message > confirming that the remote peer received the OPEN message > sent before, or an icoming NOTIFICATION message reporting > a problem. > > Valid events : evKeepAliveTimerExp, evKeepAliveMsg > evCollision, evNotifMsg, > evStopManual, evStopAuto, > evHoldTimerExp > > Ignored events : evStart > > Invalid events : all others > > In-Actions: > > 1. Send a KEEPALIVE message > 2. Set the KeepAlive timer (see note below) > 3. Set the Hold timer according to the negotiated > value (see section 4.2 and note below) > > NOTE: If the negotiated Hold time value is zero, then the Hold > and KeepAlive timers are not started. If the value of > the Autonomous System field is the same as the local Autonomous > System number, then the connection is an "internal" connection; > otherwise, it is an "external" connection. (This will impact > UPDATE processing as described below.) > > stEstablished: > This is the most advanced state of the FSM. > In the Established state, BGP can exchange UPDATE, NOTFICATION, > and KEEPALIVE messages with its peer. > > Valid events : evKeepAliveTimerExp, evNotifMsg, > evKeepAliveMsg, evUpdateMsg, > evUpdateMsgErr, evStopManual, > evStopAuto, evHoldTimerExp > > Ignored events : evStart > > In-Actions: No standard actions > > >4. Incoming transport connection processing > > When an incoming connection is detected, the system > performs the following steps: > > o Look up an existing instance of the session FSM, > using the remote IP addresses as the key. > > o If the BGP session is not found: > > - If the system is configured to not allow BGP > connections with unconfigured peers, reject > the connection. > > - Otherwise, create a new instance of FSM, > set the FSM state to stActive (without performing > In-Actions for stActive) and generate evTransSucc > event. > > o Otherwise (the session is found), processing depends > on the state of the existing FSM: > > - If state is stIdle, reject the incoming connection > (No incoming connections are allowed in the stIdle > state.) > > - If state is stConnected, accept the incoming connection, > create a new instance of FSM, set the FSM state to > stActive (without performing In-Actions for stActive) > and generate evTransSucc event. > > /* I don't believe in this, but the spec treats > * competing connections as seperate BGP sessions > */ > > - If state is stActive, accept the incoming connection, > associate it with the existing session and generate > the evTransSucc FSM event. > > - Otherwise (the FSM state is none of the above), > reject the incoming connection. > > /* We could also generate an event here, but that > * would cause an FSM restart > */ > > While in stConnected, a BGP speaker can initiate an outbound > connection and accept an incoming one (this specification > treats these connections as separate BGP sessions). > See section XXX for more information on how the situation > of connection collision is handled. > >5. Event processing and state transitions > > FSM operation is described below as follows. All state transitions > are grouped by the initial FSM state. For each state, event > processing rules with associated actions are described. > > >State: stIdle >------------- > > Event : evStart > New State : stConnect > Actions : Standard stConnect In-Actions > > All other events are ignored. > > >State: stConnect >---------------- > > Event : evTransSucc > New State : stOpenSent > Actions : Standard stOpenSent In-Actions > > > Event : evTransFail > New State : stActive > Actions : Standard stActive In-Actions > > > Event : evConnectRetryExp > New State : stConnect > Actions : Standard stConnect In-Actions > > > Event : invalid events > New State : stIdle > Actions : Standard stIdle In-Actions. > > > All other events are ignored. > > >State: stActive >--------------- > > Event : evTransSucc > New State : stOpenSent > Actions : Standard stOpenSent In-Actions > > Event : evConnectRetryExp > New State : stConnect > Actions : Standard stConnect In-Actions > > Event : invalid events > New State : stIdle > Actions : Standard stIdle In-Actions > > All other events are ignored. > >State: stOpenSent >----------------- > > Event : evOpenMsgErr, evCollision > New State : stIdle > Actions : Standard stIdle In-Actions > > > Event : evOpenMsgRcvd > New State : stOpenConfirm > Actions : Standard stOpenConfirm In-Actions > > > Event : evTransDisc > New State : stActive > Actions : Standard stActive In-Actions > > > Event : evHoldTimerExp > New State : stIdle > Actions : > 1. Send a NOTIFICATION message with error code > "Hold Timer Expired" > 2. Standard stIdle In-Actions > > Event : evNotifMsgVerErr > New State : stIdle > Actions : Standard stIdle In-Actions > > > Event : evNotifMsg, and others > New State : stIdle > Actions : Standard stIdle In-Actions > > All other events are ignored. > > > >State: stOpenConfirmed >---------------------- > > Event : evKeepAliveMsg > New State : stEstablished > Actions : none > > Event : evHoldTimerExp > New State : stIdle > Actions : > 1. Send a NOTIFICATION message with the error > code "Hold Timer Expired" > 2. Standard stIdle In-Actions > > Event : evNotifMsg, evTransDisc > New State : stIdle > Actions : Standard stIdle In-Actions > > > Event : evStopAuto > New State : stIdle > Actions : > 1. Send a NOTIFICATION message with the error > code "Cease" > 2. Standard stIdle In-Actions > > > Event : evStopManual > New State : stIdle > Actions : > 1. Send a NOTIFICATION message with the error > code "Cease" > 2. Standard stIdle In-Actions > > > Event : invalid events > New State : stIdle > Actions : > 1. Send a NOTIFICATION message with the error > code "FSM Error" > 2. Standard stIdle In-Actions > > All other events are ignored. > >State: stEstablished >-------------------- > > Event : evKeepAliveMsg, evUpdateMsg > New State : stEstablished > Actions : > Restart the Hold timer, if the negotiated Hold Time > value is non-zero. > > Event : evNotifMsg, evTransDisc > New State : stIdle > Actions : Standard stIdle In-Actions > > > Event : evUpdateMsgErr > New State : stIdle > Actions : > 1. Send a NOTIFICATION message with the error > code "Update Error" > 2. Standard stIdle In-Actions > > > Event : evUpdateMsgErr > New State : stIdle > Actions : > 1. Send a NOTIFICATION message with the error > code "Hold Timer Expired" > 2. Standard stIdle In-Actions > > > Event : evKeepAliveTimerExp > New State : stEstablished > Actions : > 1. Send a KEEPALIVE message > 2. Restart the KeepAlive timer, unless the negotiated > Hold Time value is zero. > > > Event : evStopAuto > New State : stIdle > Actions : > 1. Send a NOTIFICATION message with the error > code "Cease" > 2. Standard stIdle In-Actions > 3. Deletes all routes (in stIdle In-Actions already) > > > Event : evStopManual > New State : stIdle > Actions : > 1. Send a NOTIFICATION message with the error > code "Cease" ??? (it was not in Sue's FSM) > 2. Standard stIdle In-Actions > > > Event : invalid events > New State : stIdle > Actions : > 1. Send a NOTIFICATION message with the error > code "FSM Error" > 2. Standard stIdle In-Actions > 3. Deletes all routes (in stIdle In-Actions already) > > All other events are ignored. > > >*Incomplete* state transition diagram below. >Only main state transitions are shown. > > > +---------+ > evStart | | > +--------| Idle | > | | | > | +---------+ > | > | > v > +---------+ evTransFail +---------+ > +->| |------------------->| | >evConnRtrExp | | Connect | | Active | > +--| |<-------------------| | > +---------+ evConnectRetryExp +---------+ > | | ^ > | evTransSucc | | > evTransSucc| | | evTransDisc > | +-------------+ | | > | | |<-----+ | > +------>| OpenSent | | > | |---------+ > +-------------+ > | > | evOpenMsgRcvd > v > +-------------+ > +->| | > evKeepAliveTimerExp | | OpenConfirm | > +--| | > +-------------+ > | > | evKeepAliveMsgRcvd > v > +-------------+ > evKeepAliveMsg +->| | > evUpdateMsg | | Established | > evKeepAliveTimerExp +--| | > +-------------+ _____________________________________________________________ Get your spam-free, Linux email now --> http://www.LinuxWaves.com Join Linux discussions --> http://Community.LinuxWaves.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 LAA14774 for ; Sat, 19 Jan 2002 11:47:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1542D91214; Sat, 19 Jan 2002 11:46:03 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D766B91333; Sat, 19 Jan 2002 11:46: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 9C52A91214 for ; Sat, 19 Jan 2002 11:46:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 79E875DDB0; Sat, 19 Jan 2002 11:46:01 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 60BE25DD90 for ; Sat, 19 Jan 2002 11:46:01 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0JGjq354428; Sat, 19 Jan 2002 11:45:52 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0JGjqV01419; Sat, 19 Jan 2002 11:45:52 -0500 (EST) Date: Sat, 19 Jan 2002 11:45:52 -0500 From: Jeffrey Haas To: Pedro Roque Marques Cc: Russ White , "Reddy, Sudhakar" , "'Manav Bhatia'" , idr@merit.edu Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt) Message-ID: <20020119114552.A1412@nexthop.com> References: <20020118092238.A29052@nexthop.com> <20020118103249.F20541@nexthop.com> <20020118151910.M20541@nexthop.com> <200201182137.g0ILbjr41679@roque-bsd.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201182137.g0ILbjr41679@roque-bsd.juniper.net>; from roque@juniper.net on Fri, Jan 18, 2002 at 01:37:45PM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Fri, Jan 18, 2002 at 01:37:45PM -0800, Pedro Roque Marques wrote: > If you consider that both link 1 and 2 have the same probability of > failure then there is 50% change that it is link 2 that flaps case in > which the first path selection change due to the tie break is helpful. Once and exactly once. You keep the most stable path. > If they have different probabilities of failure then bgp needs to be > informed of that through one of the several metric parameters... If both are failing, there is nothing we can do other than to negatively bias all routes at this ingress. > I still believe that having a deterministic path selection algorithm > (i.e. independent of temporal order of arrival) is a very significant > advantage in terms of being able to debug network/equipment. I don't think people who run redunant SONET loops would agree with you. > Pedro. -- 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 JAA09366 for ; Sat, 19 Jan 2002 09:01:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6647791332; Sat, 19 Jan 2002 09:00:35 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 33B1C91333; Sat, 19 Jan 2002 09:00: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 DF24491332 for ; Sat, 19 Jan 2002 09:00:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 42CA65DDB1; Sat, 19 Jan 2002 09:00:32 -0500 (EST) Delivered-To: idr@merit.edu Received: from utopia.opentransit.net (utopia.opentransit.net [193.251.151.78]) by segue.merit.edu (Postfix) with ESMTP id 9D3005DD90 for ; Sat, 19 Jan 2002 09:00:31 -0500 (EST) Received: from utopia.opentransit.net (localhost [127.0.0.1]) by utopia.opentransit.net (8.12.1/8.12.1/Debian -5) with ESMTP id g0JDxp77002083; Sat, 19 Jan 2002 14:59:51 +0100 Received: (from vgi@localhost) by utopia.opentransit.net (8.12.1/8.12.1/Debian -5) id g0JDxpAW002082; Sat, 19 Jan 2002 14:59:51 +0100 Date: Sat, 19 Jan 2002 14:59:51 +0100 From: Vincent Gillet To: Kunihiro Ishiguro Cc: idr@merit.edu Subject: Re: bgp4-17 Cease subcode Message-ID: <20020119135951.GB28803@opentransit.net> References: <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <20020115140711.GA23937@opentransit.net> <87advfjcqi.wl@vaio.zebra.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <87advfjcqi.wl@vaio.zebra.org> User-Agent: Mutt/1.3.24i Sender: owner-idr@merit.edu Precedence: bulk kunihiro@zebra.org disait : > >> I guess we are going to find this out as part of the implementation > >> report. And if it is not in (at least two) current implementations, > >> we'll take it out of the text. > > > >I implemented Cease subcode in zebra-0.92a but not exponential backoff. > >I checked that new subcode does not put other BGP stack in trouble > >(checked Cisco and Juniper). > > First of all, sorry for talking about specific implementation. In > Zebra implementation we've implemented Cease subcode. The code is in > CVS repository. I'll prepare a release version for that. Good. I guess your implementation is much better than my hack ;-) It was the very first time i looked at zebra source code !! > Exponential backoff is a good feature. I can't understand why it > require change to FSM. No feeling about FSM, but concerned to monitor this "good feature" ! Vincent 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 IAA09220 for ; Sat, 19 Jan 2002 08:56:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5DE1D91331; Sat, 19 Jan 2002 08:56:20 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F5C591332; Sat, 19 Jan 2002 08:56: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 F12F391331 for ; Sat, 19 Jan 2002 08:56:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id C71075DDB1; Sat, 19 Jan 2002 08:56:08 -0500 (EST) Delivered-To: idr@merit.edu Received: from utopia.opentransit.net (utopia.opentransit.net [193.251.151.78]) by segue.merit.edu (Postfix) with ESMTP id 637A25DD90 for ; Sat, 19 Jan 2002 08:56:08 -0500 (EST) Received: from utopia.opentransit.net (localhost [127.0.0.1]) by utopia.opentransit.net (8.12.1/8.12.1/Debian -5) with ESMTP id g0JDtA77002054; Sat, 19 Jan 2002 14:55:10 +0100 Received: (from vgi@localhost) by utopia.opentransit.net (8.12.1/8.12.1/Debian -5) id g0JDtAdl002053; Sat, 19 Jan 2002 14:55:10 +0100 Date: Sat, 19 Jan 2002 14:55:09 +0100 From: Vincent Gillet To: andrewl@exodus.net Cc: idr@merit.edu Subject: Re: bgp4-17 Cease subcode Message-ID: <20020119135509.GA28803@opentransit.net> References: <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <20020115140711.GA23937@opentransit.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <5.0.0.25.0.20020117083423.0252ef28@mail.nexthop.com> <32264605142.20020117091413@nexsi.com> <5.0.0.25.0.20020117124225.042f96e0@mail.nexthop.com> <20020117174630.J19424@demiurge.exodus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20020117174630.J19424@demiurge.exodus.net> User-Agent: Mutt/1.3.24i Sender: owner-idr@merit.edu Precedence: bulk andrewl@exodus.net disait : > > 3)bgp exponential back-off > > One operator's view: My operator view (France Telecom) matches Andrew needs. Backoff mechanism would be really helpfull for ops team. I think that every body agree on that. Big questions are : . new FSM state or NOT . CAN / SHOULD / RECOMMEND / MUST word should we use ... > As for the FSM, were we to have this feature we would demand a command from > the vendor that would indicate what the status of the backoff is. So when > we did a "sh ip bgp summ" we could see either that it was transitioned to > idle for x reason and it had y seconds/minutes/hours remaining. The Timers are not used to be shown in a "summary/terse" view but are welcome for dedicated peer view. I trust vendors to make timers it available via CLI. > proposal to call that state "IdleHold" is a sound one. Although if > it were called ("Idle - Hold Flag Set" or something that would be fine too.) > And yes, we would want both the state and the time remaining in the MIB. If IdleHold state is included in the draft, it will make it immediatly available via SNMP in existing Mibs. No need to have bgpmib-v2 implemented to know about this state. > Preferably, if the state were IdleHold, we would have a "try #, # of seconds > remaining, # of seconds in this retry interval. Eg: BackoffAttemptNumber: 5 > BackoffSecondsRemaining: 38 BackoffSecondsTotalThisAttempt: 960 This could be a work for bgpmib-v2. I do not have feeling about either we should include it in FSM and/or put a strong word for this feature. I do not have lot of expericence on draft nor implementation. I am much more experienced in operations and BGP monitoring via SNMP thus i would appreciate to be able to retriew this "Hold" state by an easy way (SNMP). Vincent. 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 GAA04036 for ; Sat, 19 Jan 2002 06:01:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C53CD91205; Sat, 19 Jan 2002 06:00:47 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9352691331; Sat, 19 Jan 2002 06:00: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 6873391205 for ; Sat, 19 Jan 2002 06:00:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4E8C95DDAC; Sat, 19 Jan 2002 06:00:46 -0500 (EST) Delivered-To: idr@merit.edu Received: from nova.explosive.net (ns.explosive.net [205.158.174.194]) by segue.merit.edu (Postfix) with ESMTP id 298755DD90 for ; Sat, 19 Jan 2002 06:00:40 -0500 (EST) Received: from localhost (edc@localhost) by nova.explosive.net (8.9.3/8.9.3) with ESMTP id DAA17254; Sat, 19 Jan 2002 03:04:01 -0800 (PST) Date: Sat, 19 Jan 2002 03:04:01 -0800 (PST) From: Edward Crabbe To: Tom Petch Cc: Yakov Rekhter , idr@merit.edu Subject: Re: bgp4-17 Section 9 In-Reply-To: <00c901c2bf33$2fbdcb40$0301a8c0@tom3> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk A few comments here: - This has been discussed a few times before on the list, but never brought to a head. See the archives: - Some prominent bgp implementations would not comply with the proposed changes (or offer the option of non-compliance *shrug*). For prevention of loops, it is sufficient that the bgp route under consideration have the same nh as the exact match route (from protocol with higher relative protocol preference) being installed in the routing table. Announcement without installation in routing table has been a neccesary and desired behavior at some large backbones I have worked at. On Sat, 18 Jan 2003, Tom Petch wrote: > For ensuring that advertised routes are present in the > Routing Table, > and not just in the Loc-RIB, how about > > 2. Introduction > .................. > To characterize the set of policy decisions that can be > enforced > using BGP, one must focus on the rule that a BGP speaker > advertises > to its peers (other BGP speakers which it communicates > with) in > neighboring ASs only those routes that it itself uses, > ---add-------------- > that is, are present in the BGP speaker's Routing Table. > ---------------- > This rule > reflects the "hop-by-hop" routing paradigm generally used > throughout > the current Internet. > ................................ > > 3.2 (no change needed) > > 9.1.2 (no change needed) > > 9.1.3 Phase 3: Route Dissemination > ...................... > All routes > ----change to------------- > that are present in both the Loc-RIB and the Routing Table > ------------------------------- > shall be processed into Adj-RIBs-Out > according to configured policy. > ........................ > > > 9.4 (no change needed) > > Tom Petch, Network Consultant > nwnetworks@dial.pipex.com > > -----Original Message----- > From: Yakov Rekhter > To: Tom Petch > Cc: idr@merit.edu > Date: 14 January 2002 20:15 > Subject: Re: bgp4-17 Section 9 > > > >> > >> 9.1.2 Route selection now allows for the best route in > >> Loc-RIB not to be placed in the Routing table; how does > this > >> impact on the principle (2 Introduction) that a BGP > Speaker > >> should only advertise routes it itself uses? Is it > enough > >> for the route to be in Loc-RIB and not in the Routing > Table? > >> > {paragraph omitted - covered in previous e-mail} > > > >Please propose the specific changes. > > > >Yakov. > > { plus an earlier reply from Alex to me} > > > Tom, > > > > > 9.1.2 Route selection now allows for the best route in > > > Loc-RIB not to be placed in the Routing table; how does > this > > > impact on the principle (2 Introduction) that a BGP > Speaker > > > should only advertise routes it itself uses? Is it > enough > > > for the route to be in Loc-RIB and not in the Routing > Table? > > > > The principle implies that the route is both in Loc-RIB > and > > in the routing table, i.e., it needs to be both selected > as > > the best and used by the router. > > However, we can only specify so much about the routing > table, > > as it is (strictly speaking) outside of the scope of the > BGP > > protocol and administrator do have the "filter" rope in > > their hands. Section 3.2 also talks about this. > > > 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 QAA07999 for ; Fri, 18 Jan 2002 16:39:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2798291328; Fri, 18 Jan 2002 16:38:26 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E708C9132A; Fri, 18 Jan 2002 16:38: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 AC9D391328 for ; Fri, 18 Jan 2002 16:38:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7BC245DDA2; Fri, 18 Jan 2002 16:38:24 -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 2AE3F5DD90 for ; Fri, 18 Jan 2002 16:38:24 -0500 (EST) Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0ILbj674470; Fri, 18 Jan 2002 13:37:45 -0800 (PST) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.1/8.9.3) id g0ILbjr41679; Fri, 18 Jan 2002 13:37:45 -0800 (PST) (envelope-from roque) Date: Fri, 18 Jan 2002 13:37:45 -0800 (PST) Message-Id: <200201182137.g0ILbjr41679@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jeffrey Haas Cc: Russ White , "Reddy, Sudhakar" , "'Manav Bhatia'" , idr@merit.edu Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt) In-Reply-To: <20020118151910.M20541@nexthop.com> References: <20020118092238.A29052@nexthop.com> <20020118103249.F20541@nexthop.com> <20020118151910.M20541@nexthop.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-idr@merit.edu Precedence: bulk Jeffrey Haas writes: > On Fri, Jan 18, 2002 at 10:47:11AM -0800, Pedro Roque Marques wrote: >> The conter argument is that reaching a deterministic state is worth >> that extra flap... > Not flap, singular, flaps plural. > Consider: +---+ : A : +---+ 1 2 +---+ : B : +---+ > Routers A and B are redundantly connected via networks 1 and 2. A > sends to B two routes that are equal preferable in the route > selection process (prior to the new step g). > Network 1 has a lower neighbor address than 2 and thus would be > chosen. > If network 1 flaps (bad circuit) then we unnecessarily flap the > reachability. Jeff, If you consider that both link 1 and 2 have the same probability of failure then there is 50% change that it is link 2 that flaps case in which the first path selection change due to the tie break is helpful. If they have different probabilities of failure then bgp needs to be informed of that through one of the several metric parameters... I still believe that having a deterministic path selection algorithm (i.e. independent of temporal order of arrival) is a very significant advantage in terms of being able to debug network/equipment. Pedro. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA07505 for ; Fri, 18 Jan 2002 16:24:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D112F91326; Fri, 18 Jan 2002 16:24:09 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C4ED91328; Fri, 18 Jan 2002 16:24:09 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7238291326 for ; Fri, 18 Jan 2002 16:24:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 461F95DDAA; Fri, 18 Jan 2002 16:24:08 -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 AC7245DD90 for ; Fri, 18 Jan 2002 16:24:07 -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 g0ILO7673855; Fri, 18 Jan 2002 13:24:07 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200201182124.g0ILO7673855@merlot.juniper.net> To: idr@merit.edu Cc: skh@nexthop.com, yakov@juniper.net Subject: rough consensus on SAFI=3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25535.1011389047.1@juniper.net> Date: Fri, 18 Jan 2002 13:24:07 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, We need to get WG rough consensus on whether to remove SAFI=3 from 2858bis. Folks who are in favor of removing SAFI=3 from 2858bis please send an e-mail to yakov@juniper.net saying "remove". Folks you are in favor of keeping SAFI=3 in 2858bis please send an e-mail to yakov@juniper.net saying "keep". The deadline for this is one week (Jan 25, 2002). Sue&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 QAA06635 for ; Fri, 18 Jan 2002 16:04:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ECA0B91321; Fri, 18 Jan 2002 16:03:29 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A345F91324; Fri, 18 Jan 2002 16:03:19 -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 7FE9391321 for ; Fri, 18 Jan 2002 16:02:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 50B275DD98; Fri, 18 Jan 2002 16:02:46 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [66.35.212.41]) by segue.merit.edu (Postfix) with ESMTP id BAB295DD92 for ; Fri, 18 Jan 2002 16:02:45 -0500 (EST) Received: from khonsu.sw.nexsi.com (dynam34.sw.nexsi.com [172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id NAA30372; Fri, 18 Jan 2002 13:01:50 -0800 Date: Fri, 18 Jan 2002 13:01:48 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <117364655587.20020118130148@nexsi.com> To: "Tom Petch" Cc: "Yakov Rekhter" , idr@merit.edu Subject: Re: bgp4-17 Section 9 In-Reply-To: <00c901c2bf33$2fbdcb40$0301a8c0@tom3> References: <00c901c2bf33$2fbdcb40$0301a8c0@tom3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Tom, Though definitely a sane idea, I'm afraid this will not match the existing implementations. -- Alex Zinin P.S. Fix the text wrapping thing, pls :) Saturday, January 18, 2003, 12:42:45 PM, Tom Petch wrote: > For ensuring that advertised routes are present in the > Routing Table, > and not just in the Loc-RIB, how about 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 QAA06601 for ; Fri, 18 Jan 2002 16:03:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C478491320; Fri, 18 Jan 2002 16:03:17 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D37BD91323; Fri, 18 Jan 2002 16:02: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 8934291320 for ; Fri, 18 Jan 2002 16:02:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4C2025DD98; Fri, 18 Jan 2002 16:02:20 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 05B255DD92 for ; Fri, 18 Jan 2002 16:02:20 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0IL27320186; Fri, 18 Jan 2002 16:02:07 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0IL26L29628; Fri, 18 Jan 2002 16:02:06 -0500 (EST) Date: Fri, 18 Jan 2002 16:02:06 -0500 From: Jeffrey Haas To: Tom Petch Cc: Yakov Rekhter , idr@merit.edu Subject: Re: bgp4-17 Section 9 Message-ID: <20020118160206.N20541@nexthop.com> References: <00c901c2bf33$2fbdcb40$0301a8c0@tom3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00c901c2bf33$2fbdcb40$0301a8c0@tom3>; from nwnetworks@dial.pipex.com on Sat, Jan 18, 2003 at 08:42:45PM -0000 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Sat, Jan 18, 2003 at 08:42:45PM -0000, Tom Petch wrote: > For ensuring that advertised routes are present in the > Routing Table, > and not just in the Loc-RIB, how about The binding you suggest is perhaps too strong for some implementors. The current wording was suggested to allow implementors who really wanted to have the routing table and the loc-rib to be potentially unsynchronized for a short period of time to do so. -- 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 PAA06116 for ; Fri, 18 Jan 2002 15:51:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EB39B9131E; Fri, 18 Jan 2002 15:50:53 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA9459131F; Fri, 18 Jan 2002 15:50: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 9065B9131E for ; Fri, 18 Jan 2002 15:50:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 750555DD91; Fri, 18 Jan 2002 15:50:51 -0500 (EST) Delivered-To: idr@merit.edu Received: from snowstorm.mail.pipex.net (snowstorm.mail.pipex.net [158.43.192.97]) by segue.merit.edu (Postfix) with SMTP id B69A85DD90 for ; Fri, 18 Jan 2002 15:50:50 -0500 (EST) Received: (qmail 1673 invoked from network); 18 Jan 2002 20:50:48 -0000 Received: from userbm54.uk.uudial.com (HELO tom3) (62.188.145.6) by smtp-6.dial.pipex.com with SMTP; 18 Jan 2002 20:50:48 -0000 Message-ID: <00c901c2bf33$2fbdcb40$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Yakov Rekhter" Cc: Subject: Re: bgp4-17 Section 9 Date: Sat, 18 Jan 2003 20:42:45 -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 For ensuring that advertised routes are present in the Routing Table, and not just in the Loc-RIB, how about 2. Introduction .................. To characterize the set of policy decisions that can be enforced using BGP, one must focus on the rule that a BGP speaker advertises to its peers (other BGP speakers which it communicates with) in neighboring ASs only those routes that it itself uses, ---add-------------- that is, are present in the BGP speaker's Routing Table. ---------------- This rule reflects the "hop-by-hop" routing paradigm generally used throughout the current Internet. ................................ 3.2 (no change needed) 9.1.2 (no change needed) 9.1.3 Phase 3: Route Dissemination ...................... All routes ----change to------------- that are present in both the Loc-RIB and the Routing Table ------------------------------- shall be processed into Adj-RIBs-Out according to configured policy. ........................ 9.4 (no change needed) Tom Petch, Network Consultant nwnetworks@dial.pipex.com -----Original Message----- From: Yakov Rekhter To: Tom Petch Cc: idr@merit.edu Date: 14 January 2002 20:15 Subject: Re: bgp4-17 Section 9 >> >> 9.1.2 Route selection now allows for the best route in >> Loc-RIB not to be placed in the Routing table; how does this >> impact on the principle (2 Introduction) that a BGP Speaker >> should only advertise routes it itself uses? Is it enough >> for the route to be in Loc-RIB and not in the Routing Table? >> {paragraph omitted - covered in previous e-mail} > >Please propose the specific changes. > >Yakov. { plus an earlier reply from Alex to me} > Tom, > > > 9.1.2 Route selection now allows for the best route in > > Loc-RIB not to be placed in the Routing table; how does this > > impact on the principle (2 Introduction) that a BGP Speaker > > should only advertise routes it itself uses? Is it enough > > for the route to be in Loc-RIB and not in the Routing Table? > > The principle implies that the route is both in Loc-RIB and > in the routing table, i.e., it needs to be both selected as > the best and used by the router. > However, we can only specify so much about the routing table, > as it is (strictly speaking) outside of the scope of the BGP > protocol and administrator do have the "filter" rope in > their hands. Section 3.2 also talks about this. > 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 PAA04981 for ; Fri, 18 Jan 2002 15:24:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C9AA191329; Fri, 18 Jan 2002 15:24:30 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DB5E91327; Fri, 18 Jan 2002 15:24:30 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1E28191326 for ; Fri, 18 Jan 2002 15:24:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF4B65DD99; Fri, 18 Jan 2002 15:24:26 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [66.35.212.41]) by segue.merit.edu (Postfix) with ESMTP id 6A03E5DD98 for ; Fri, 18 Jan 2002 15:24:26 -0500 (EST) Received: from khonsu.sw.nexsi.com (dynam34.sw.nexsi.com [172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id MAA30048; Fri, 18 Jan 2002 12:23:33 -0800 Date: Fri, 18 Jan 2002 12:23:30 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <145362358133.20020118122330@nexsi.com> To: Russ White Cc: Russ White , Susan Hares , randy Bush , Subject: Re: bgp4-17 Cease subcode In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk >> On the other hand, I think it would be equally good if the >> spec did not spell out the details and we had another >> document discussing the topic in detail... if we have such a >> commitment, of course ;-) > But I prefer this, even if there isn't a commitment for a doc > (yet). I'm fine with either approach. Let's see what Sue says. Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA04968 for ; Fri, 18 Jan 2002 15:24:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C91E59120A; Fri, 18 Jan 2002 15:19:31 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92EC19131E; Fri, 18 Jan 2002 15:19: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 A0A889120A for ; Fri, 18 Jan 2002 15:19:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7EDD05DD99; Fri, 18 Jan 2002 15:19:27 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 39B905DD91 for ; Fri, 18 Jan 2002 15:19:27 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0IKJA318830; Fri, 18 Jan 2002 15:19:10 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0IKJAE29560; Fri, 18 Jan 2002 15:19:10 -0500 (EST) Date: Fri, 18 Jan 2002 15:19:10 -0500 From: Jeffrey Haas To: Pedro Roque Marques Cc: Russ White , "Reddy, Sudhakar" , "'Manav Bhatia'" , idr@merit.edu Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt) Message-ID: <20020118151910.M20541@nexthop.com> References: <20020118092238.A29052@nexthop.com> <20020118103249.F20541@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from roque@juniper.net on Fri, Jan 18, 2002 at 10:47:11AM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Fri, Jan 18, 2002 at 10:47:11AM -0800, Pedro Roque Marques wrote: > The conter argument is that reaching a deterministic state is worth > that extra flap... Not flap, singular, flaps plural. Consider: +---+ : A : +---+ 1 2 +---+ : B : +---+ Routers A and B are redundantly connected via networks 1 and 2. A sends to B two routes that are equal preferable in the route selection process (prior to the new step g). Network 1 has a lower neighbor address than 2 and thus would be chosen. If network 1 flaps (bad circuit) then we unnecessarily flap the reachability. > Pedro. -- 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 KAA24358 for ; Fri, 18 Jan 2002 10:36:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8699291318; Fri, 18 Jan 2002 10:36:25 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4FE4491319; Fri, 18 Jan 2002 10:36: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 504F591318 for ; Fri, 18 Jan 2002 10:36:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2952F5DDA3; Fri, 18 Jan 2002 10:36:24 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id D4DC35DDB6 for ; Fri, 18 Jan 2002 10:36:23 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0IFa6309862; Fri, 18 Jan 2002 10:36:06 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0IFa5k29145; Fri, 18 Jan 2002 10:36:05 -0500 (EST) Date: Fri, 18 Jan 2002 10:36:05 -0500 From: Jeffrey Haas To: Alex Zinin Cc: Kunihiro Ishiguro , idr@merit.edu, Susan Hares Subject: Re: Comments on FSM Message-ID: <20020118103605.G20541@nexthop.com> References: <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <87advfjcqi.wl@vaio.zebra.org> <5.0.0.25.0.20020116181115.03ea46f8@mail.nexthop.com> <195204309992.20020116162916@nexsi.com> <145212436838.20020116184444@nexsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <145212436838.20020116184444@nexsi.com>; from azinin@nexsi.com on Wed, Jan 16, 2002 at 06:44:44PM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Wed, Jan 16, 2002 at 06:44:44PM -0800, Alex Zinin wrote: > No strong opinion on this. > If exponential back-off is optional and has been implemented > in some implementations, I think it can stay in the main spec. Implementation note: GateD currently uses a step function rather than fully exponential backoff, but we do backoff. > Alex. -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA24265 for ; Fri, 18 Jan 2002 10:34:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A41B491203; Fri, 18 Jan 2002 10:33:27 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 784F891318; Fri, 18 Jan 2002 10:33: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 71EF891203 for ; Fri, 18 Jan 2002 10:33:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 476515DDB6; Fri, 18 Jan 2002 10:33:26 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 012CA5DDA3 for ; Fri, 18 Jan 2002 10:33:25 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0IFWl309757; Fri, 18 Jan 2002 10:32:48 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0IFWn529137; Fri, 18 Jan 2002 10:32:49 -0500 (EST) Date: Fri, 18 Jan 2002 10:32:49 -0500 From: Jeffrey Haas To: Russ White Cc: "Reddy, Sudhakar" , "'Manav Bhatia'" , idr@merit.edu Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt) Message-ID: <20020118103249.F20541@nexthop.com> References: <20020118092238.A29052@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ruwhite@cisco.com on Fri, Jan 18, 2002 at 09:30:43AM -0500 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Fri, Jan 18, 2002 at 09:30:43AM -0500, Russ White wrote: > Not when you're announcing, but you've received the same route > from two peers which are otherwise 'identical' in metrics. Where the routes are non-identical, but equally preferable, selecting the candidate based on peering session address is potentially less preferable to selecting based on age. The more stable route would be more preferable to the route with the "better" peer address. I even seem to remember a certain $LARGE_ROUTER_VENDOR behaving that way once-upon-a-release. :-) > Russ -- 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 JAA22772 for ; Fri, 18 Jan 2002 09:52:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7D77291316; Fri, 18 Jan 2002 09:51:27 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48DA891317; Fri, 18 Jan 2002 09:51: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 4B47491316 for ; Fri, 18 Jan 2002 09:51:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 22F4D5DE30; Fri, 18 Jan 2002 09:51:26 -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 DFBA35DE2A for ; Fri, 18 Jan 2002 09:51:25 -0500 (EST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 143EE4BA214; Fri, 18 Jan 2002 06:51:25 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id 571FB15D3C1; Fri, 18 Jan 2002 06:51:20 -0800 (PST) To: Jeffrey Haas Cc: Russ White , "Reddy, Sudhakar" , enke@redback.com, "'Manav Bhatia'" , idr@merit.edu Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt) In-Reply-To: Message from Jeffrey Haas of "Fri, 18 Jan 2002 09:22:38 EST." <20020118092238.A29052@nexthop.com> Date: Fri, 18 Jan 2002 06:51:19 -0800 From: Enke Chen Message-Id: <20020118145120.571FB15D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Jeff, Just consider the case of parallel sessions (using different interfaces with different speeds) between two routers, the route selection algorithm would not terminate without Step g). EBGP parallel sessions are used widely in practice. -- Enke > Date: Fri, 18 Jan 2002 09:22:38 -0500 > From: Jeffrey Haas > To: Russ White > Cc: "Reddy, Sudhakar" , > "'Manav Bhatia'" , idr@merit.edu > Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt) > Message-ID: <20020118092238.A29052@nexthop.com> > References: > > On Fri, Jan 18, 2002 at 08:12:13AM -0500, Russ White wrote: > > Actually, this rule is designed to prevent the route flap when a > > new path, identical in all respects other than the peer it is > > learned from, is newly learned. The older route wins, which means > > the decision algorithm won't flip over to the newer route if the > > route from which it is learned has a lower rid. > > A different question is why you're announcing the route when > it is identical, but just from another peer and you've already > announced that reachability. > > Flapping the stuff on the wire just because you've changed the stuff > in your internal route instances is silly. > > IOW - g) wasn't necessary at all. g) even causes flaps where there > shouldn't need to be any. > > > Russ > > -- > 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 JAA22152 for ; Fri, 18 Jan 2002 09:32:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 93CC491314; Fri, 18 Jan 2002 09:31:29 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4274A91315; Fri, 18 Jan 2002 09:31: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 31DC591314 for ; Fri, 18 Jan 2002 09:31:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0AB875DE2B; Fri, 18 Jan 2002 09:31:22 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 166115DDA3 for ; Fri, 18 Jan 2002 09:31:21 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA06689; Fri, 18 Jan 2002 09:30:43 -0500 (EST) Date: Fri, 18 Jan 2002 09:30:43 -0500 (EST) From: Russ White Reply-To: Russ White To: Jeffrey Haas Cc: "Reddy, Sudhakar" , "'Manav Bhatia'" , idr@merit.edu Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt) In-Reply-To: <20020118092238.A29052@nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Not when you're announcing, but you've received the same route from two peers which are otherwise 'identical' in metrics. :-) Russ On Fri, 18 Jan 2002, Jeffrey Haas wrote: > On Fri, Jan 18, 2002 at 08:12:13AM -0500, Russ White wrote: > > Actually, this rule is designed to prevent the route flap when a > > new path, identical in all respects other than the peer it is > > learned from, is newly learned. The older route wins, which means > > the decision algorithm won't flip over to the newer route if the > > route from which it is learned has a lower rid. > > A different question is why you're announcing the route when > it is identical, but just from another peer and you've already > announced that reachability. > > Flapping the stuff on the wire just because you've changed the stuff > in your internal route instances is silly. > > IOW - g) wasn't necessary at all. g) even causes flaps where there > shouldn't need to be any. > > > Russ > > -- > Jeff Haas > NextHop Technologies > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA21905 for ; Fri, 18 Jan 2002 09:23:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8248A91313; Fri, 18 Jan 2002 09:22:56 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51ABE91314; Fri, 18 Jan 2002 09:22:56 -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 43EB591313 for ; Fri, 18 Jan 2002 09:22:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 13E8C5DE2A; Fri, 18 Jan 2002 09:22:55 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id C1A035DDA3 for ; Fri, 18 Jan 2002 09:22:54 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0IEMd307692; Fri, 18 Jan 2002 09:22:39 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0IEMcE29068; Fri, 18 Jan 2002 09:22:38 -0500 (EST) Date: Fri, 18 Jan 2002 09:22:38 -0500 From: Jeffrey Haas To: Russ White Cc: "Reddy, Sudhakar" , "'Manav Bhatia'" , idr@merit.edu Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt) Message-ID: <20020118092238.A29052@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ruwhite@cisco.com on Fri, Jan 18, 2002 at 08:12:13AM -0500 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Fri, Jan 18, 2002 at 08:12:13AM -0500, Russ White wrote: > Actually, this rule is designed to prevent the route flap when a > new path, identical in all respects other than the peer it is > learned from, is newly learned. The older route wins, which means > the decision algorithm won't flip over to the newer route if the > route from which it is learned has a lower rid. A different question is why you're announcing the route when it is identical, but just from another peer and you've already announced that reachability. Flapping the stuff on the wire just because you've changed the stuff in your internal route instances is silly. IOW - g) wasn't necessary at all. g) even causes flaps where there shouldn't need to be any. > Russ -- 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 IAA20284 for ; Fri, 18 Jan 2002 08:31:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 16FF291312; Fri, 18 Jan 2002 08:30:16 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9397C91313; Fri, 18 Jan 2002 08:30:15 -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 7769C91312 for ; Fri, 18 Jan 2002 08:30:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id C95D85DE08; Fri, 18 Jan 2002 08:30:10 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 2A8CB5DDA3 for ; Fri, 18 Jan 2002 08:30:10 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA29914; Fri, 18 Jan 2002 08:29:37 -0500 (EST) Date: Fri, 18 Jan 2002 08:29:37 -0500 (EST) From: Russ White Reply-To: Russ White To: "Reddy, Sudhakar" Cc: "'Manav Bhatia'" , idr@merit.edu Subject: RE: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk The older route still wins--you don't pay attention to the router id at all, since one of the two otherwise identical prefixes will always be older. :-) Russ On Fri, 18 Jan 2002, Reddy, Sudhakar wrote: > What happens if the older route which is identical in all respects other > than rid, is having higher rid than the newer route? > > Thanks, > Sudhakar > > -----Original Message----- > From: Russ White [mailto:ruwhite@cisco.com] > Sent: Friday, January 18, 2002 6:42 PM > To: Reddy, Sudhakar > Cc: 'Manav Bhatia'; idr@merit.edu > Subject: RE: A Question about Tie breaking rules > (draft-ietf-idr-bgp4-17.t xt) > > > > Actually, this rule is designed to prevent the route flap when a > new path, identical in all respects other than the peer it is > learned from, is newly learned. The older route wins, which means > the decision algorithm won't flip over to the newer route if the > route from which it is learned has a lower rid. > > :-) > > Russ > > On Fri, 18 Jan 2002, Reddy, Sudhakar wrote: > > > Hi Manav, > > I can understand that this rule will help to avoided routing loops, and > > ensures a consistent best path selection. But at the same time say if two > > paths are from external peers, this may create a route-flap.(since a newer > > path may displace on older one). > > > > Thanks, > > Sudhakar > > > > -----Original Message----- > > From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] > > Sent: Friday, January 18, 2002 2:23 PM > > To: Reddy, Sudhakar; idr@merit.edu > > Subject: Re: A Question about Tie breaking rules > > (draft-ietf-idr-bgp4-17.txt) > > > > > > Hi Reddy, > > This tie breaking rule is followed by a lot of BGP implementations in the > > Internet. This is generally kept as the last resort for tie breaking and > is > > followed in a lot of BGP implementations. CISCO also suggests this in its > > BGP Best Path Selection Algorithm. > > > > Infact even ZEBRA supports this! > > > > Regards, > > Manav > > > > ----- Original Message ----- > > From: "Reddy, Sudhakar" > > To: > > Cc: "Reddy, Sudhakar" > > Sent: Friday, January 18, 2002 2:10 PM > > Subject: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt) > > > > > > | Hi, > > | I have a question about BGP tie braking rules. In the BGP new draft > > | "draft-ietf-idr-bgp4-17.txt" section 9.1.2.2, the last tie breaking rule > > g) > > | is as follows: > > | "g) Prefer the route received from the lowest neighbor address." > > | > > | What is the relevance of this rule? Is this tie breaking rule > > | present in BGP implementations in the Internet? > > | > > | Thanks in advance, > > | Sudhakar > > | > ------------------------------------------------------------------------- > > --- > > | - > > | R. Sudhakar Reddy mailto:sudhakarr@netplane.com > > | > > | NetPlane Network Technologies (India) Pvt. Ltd. > > > | A Mindspeed Technologies Company > > > > | 189, Prashasan Nagar, Ph: +91-40-3553709 ~ 12 (Ext > > | 1127) > > | Road # 72, Jublee Hills, > > | Hyderabad - 500033 > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > _____________________________ > riw@cisco.com <>< Grace Alone > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA20229 for ; Fri, 18 Jan 2002 08:28:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0662C91311; Fri, 18 Jan 2002 08:28:26 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3DA791312; Fri, 18 Jan 2002 08:28: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 A5D9C91311 for ; Fri, 18 Jan 2002 08:28:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F6CB5DE2A; Fri, 18 Jan 2002 08:28:24 -0500 (EST) Delivered-To: idr@merit.edu Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by segue.merit.edu (Postfix) with ESMTP id 039685DE08 for ; Fri, 18 Jan 2002 08:28:24 -0500 (EST) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jan 2002 08:28:22 -0500 Message-ID: From: "Reddy, Sudhakar" To: "'Russ White'" , "Reddy, Sudhakar" Cc: "'Manav Bhatia'" , idr@merit.edu Subject: RE: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt) Date: Fri, 18 Jan 2002 08:28:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-idr@merit.edu Precedence: bulk What happens if the older route which is identical in all respects other than rid, is having higher rid than the newer route? Thanks, Sudhakar -----Original Message----- From: Russ White [mailto:ruwhite@cisco.com] Sent: Friday, January 18, 2002 6:42 PM To: Reddy, Sudhakar Cc: 'Manav Bhatia'; idr@merit.edu Subject: RE: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt) Actually, this rule is designed to prevent the route flap when a new path, identical in all respects other than the peer it is learned from, is newly learned. The older route wins, which means the decision algorithm won't flip over to the newer route if the route from which it is learned has a lower rid. :-) Russ On Fri, 18 Jan 2002, Reddy, Sudhakar wrote: > Hi Manav, > I can understand that this rule will help to avoided routing loops, and > ensures a consistent best path selection. But at the same time say if two > paths are from external peers, this may create a route-flap.(since a newer > path may displace on older one). > > Thanks, > Sudhakar > > -----Original Message----- > From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] > Sent: Friday, January 18, 2002 2:23 PM > To: Reddy, Sudhakar; idr@merit.edu > Subject: Re: A Question about Tie breaking rules > (draft-ietf-idr-bgp4-17.txt) > > > Hi Reddy, > This tie breaking rule is followed by a lot of BGP implementations in the > Internet. This is generally kept as the last resort for tie breaking and is > followed in a lot of BGP implementations. CISCO also suggests this in its > BGP Best Path Selection Algorithm. > > Infact even ZEBRA supports this! > > Regards, > Manav > > ----- Original Message ----- > From: "Reddy, Sudhakar" > To: > Cc: "Reddy, Sudhakar" > Sent: Friday, January 18, 2002 2:10 PM > Subject: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt) > > > | Hi, > | I have a question about BGP tie braking rules. In the BGP new draft > | "draft-ietf-idr-bgp4-17.txt" section 9.1.2.2, the last tie breaking rule > g) > | is as follows: > | "g) Prefer the route received from the lowest neighbor address." > | > | What is the relevance of this rule? Is this tie breaking rule > | present in BGP implementations in the Internet? > | > | Thanks in advance, > | Sudhakar > | ------------------------------------------------------------------------- > --- > | - > | R. Sudhakar Reddy mailto:sudhakarr@netplane.com > | > | NetPlane Network Technologies (India) Pvt. Ltd. > | A Mindspeed Technologies Company > > | 189, Prashasan Nagar, Ph: +91-40-3553709 ~ 12 (Ext > | 1127) > | Road # 72, Jublee Hills, > | Hyderabad - 500033 > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA19784 for ; Fri, 18 Jan 2002 08:13:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9FA1591310; Fri, 18 Jan 2002 08:12:47 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6EF4E91311; Fri, 18 Jan 2002 08:12: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 1215491310 for ; Fri, 18 Jan 2002 08:12:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id D97405DE2A; Fri, 18 Jan 2002 08:12:45 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 9C32C5DE17 for ; Fri, 18 Jan 2002 08:12:45 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA27836; Fri, 18 Jan 2002 08:12:13 -0500 (EST) Date: Fri, 18 Jan 2002 08:12:13 -0500 (EST) From: Russ White Reply-To: Russ White To: "Reddy, Sudhakar" Cc: "'Manav Bhatia'" , idr@merit.edu Subject: RE: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Actually, this rule is designed to prevent the route flap when a new path, identical in all respects other than the peer it is learned from, is newly learned. The older route wins, which means the decision algorithm won't flip over to the newer route if the route from which it is learned has a lower rid. :-) Russ On Fri, 18 Jan 2002, Reddy, Sudhakar wrote: > Hi Manav, > I can understand that this rule will help to avoided routing loops, and > ensures a consistent best path selection. But at the same time say if two > paths are from external peers, this may create a route-flap.(since a newer > path may displace on older one). > > Thanks, > Sudhakar > > -----Original Message----- > From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] > Sent: Friday, January 18, 2002 2:23 PM > To: Reddy, Sudhakar; idr@merit.edu > Subject: Re: A Question about Tie breaking rules > (draft-ietf-idr-bgp4-17.txt) > > > Hi Reddy, > This tie breaking rule is followed by a lot of BGP implementations in the > Internet. This is generally kept as the last resort for tie breaking and is > followed in a lot of BGP implementations. CISCO also suggests this in its > BGP Best Path Selection Algorithm. > > Infact even ZEBRA supports this! > > Regards, > Manav > > ----- Original Message ----- > From: "Reddy, Sudhakar" > To: > Cc: "Reddy, Sudhakar" > Sent: Friday, January 18, 2002 2:10 PM > Subject: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt) > > > | Hi, > | I have a question about BGP tie braking rules. In the BGP new draft > | "draft-ietf-idr-bgp4-17.txt" section 9.1.2.2, the last tie breaking rule > g) > | is as follows: > | "g) Prefer the route received from the lowest neighbor address." > | > | What is the relevance of this rule? Is this tie breaking rule > | present in BGP implementations in the Internet? > | > | Thanks in advance, > | Sudhakar > | ------------------------------------------------------------------------- > --- > | - > | R. Sudhakar Reddy mailto:sudhakarr@netplane.com > | > | NetPlane Network Technologies (India) Pvt. Ltd. > | A Mindspeed Technologies Company > > | 189, Prashasan Nagar, Ph: +91-40-3553709 ~ 12 (Ext > | 1127) > | Road # 72, Jublee Hills, > | Hyderabad - 500033 > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA19651 for ; Fri, 18 Jan 2002 08:10:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 942559130F; Fri, 18 Jan 2002 08:10:25 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6181C91310; Fri, 18 Jan 2002 08:10: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 F2A129130F for ; Fri, 18 Jan 2002 08:10:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id C3D3F5DE2A; Fri, 18 Jan 2002 08:10:23 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 573065DE17 for ; Fri, 18 Jan 2002 08:10:23 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA27535; Fri, 18 Jan 2002 08:10:08 -0500 (EST) Date: Fri, 18 Jan 2002 08:10:08 -0500 (EST) From: Russ White Reply-To: Russ White To: Kunihiro Ishiguro Cc: Susan Hares , Vincent Gillet , Yakov Rekhter , Jeffrey Haas , idr@merit.edu Subject: Re: bgp4-17 Cease subcode In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk > 8.1 Exponential Back-off. > > If a BGP speaker detects an error, it shuts down the connection and > changes its state to Idle. Getting out of the Idle state requires > generation of the Start event. If such an event is generated > automatically, then persistent BGP errors may result in persistent > flapping of the speaker. To avoid such a condition it is > recommended that Start events should not be generated immediately > for a peer that was previously transitioned to Idle due to an > error. For a peer that was previously transitioned to Idle due to > an error, the time between consecutive generation of Start events, > if such events are generated automatically, shall exponentially MAY rather than shall.... > increase. The value of the initial timer shall be 60 seconds. The ....increase. If exponential backoff is used, .... > time shall be doubled for each consecutive retry. Suggested value > for this timer is: > > 2**(consecutive retry count)*60 > > An implementation MAY impose a configurable upper bound on that > timer value. Once the upper bound is reached, the speaker shall > stop the timer then no longer automatically generate the Start > event for the peer. :-) Russ _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA18935 for ; Fri, 18 Jan 2002 07:50:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 05BBF9130E; Fri, 18 Jan 2002 07:49:47 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C844C9130F; Fri, 18 Jan 2002 07:49: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 A42C99130E for ; Fri, 18 Jan 2002 07:49:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7D2005DE2A; Fri, 18 Jan 2002 07:49:45 -0500 (EST) Delivered-To: idr@merit.edu Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by segue.merit.edu (Postfix) with SMTP id F16635DDA3 for ; Fri, 18 Jan 2002 07:49:44 -0500 (EST) Received: from leased-200-20-226.bng.vsnl.net.in (HELO Manav) (203.200.20.226) by smtp.mail.vip.sc5.yahoo.com with SMTP; 18 Jan 2002 12:49:43 -0000 Message-ID: <04d601c1a01e$fa3dc620$b4036c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "Reddy, Sudhakar" , References: Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt) Date: Fri, 18 Jan 2002 18:22:21 +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 Hi Sudhakar, There are some 13 tie breaking rules which help BGP decide the best path. After checking some 9 rules and even then IF there is a tie AND if the routers are not configured for "bgp best path compare router-id" AND if both the routes are external, the path that was received first is accepted (the oldest one). This step is done to minimize route-flap (as you suggested) , since the newer path wont displace the older one, even if it is the preferred route based on the rules which follow (its here that a route from a lower router ID is selected OR else minimum cluster length OR path coming from the lowest neighbor address) It is generally recommended that we apply the additional decision steps to IBGP paths only, in order to ensure a consistent best path decision within the network, and thereby avoiding loops. So the problem which you suggested should not arise. Hope it helps. Regards, Manav ----- Original Message ----- From: "Reddy, Sudhakar" To: "'Manav Bhatia'" ; Sent: Friday, January 18, 2002 3:29 PM Subject: RE: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt) | Hi Manav, | I can understand that this rule will help to avoided routing loops, and | ensures a consistent best path selection. But at the same time say if two | paths are from external peers, this may create a route-flap.(since a newer | path may displace on older one). | | Thanks, | Sudhakar | | -----Original Message----- | From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] | Sent: Friday, January 18, 2002 2:23 PM | To: Reddy, Sudhakar; idr@merit.edu | Subject: Re: A Question about Tie breaking rules | (draft-ietf-idr-bgp4-17.txt) | | | Hi Reddy, | This tie breaking rule is followed by a lot of BGP implementations in the | Internet. This is generally kept as the last resort for tie breaking and is | followed in a lot of BGP implementations. CISCO also suggests this in its | BGP Best Path Selection Algorithm. | | Infact even ZEBRA supports this! | | Regards, | Manav | | ----- Original Message ----- | From: "Reddy, Sudhakar" | To: | Cc: "Reddy, Sudhakar" | Sent: Friday, January 18, 2002 2:10 PM | Subject: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt) | | | | Hi, | | I have a question about BGP tie braking rules. In the BGP new draft | | "draft-ietf-idr-bgp4-17.txt" section 9.1.2.2, the last tie breaking rule | g) | | is as follows: | | "g) Prefer the route received from the lowest neighbor address." | | | | What is the relevance of this rule? Is this tie breaking rule | | present in BGP implementations in the Internet? | | | | Thanks in advance, | | Sudhakar | | ------------------------------------------------------------------------- | --- | | - | | R. Sudhakar Reddy mailto:sudhakarr@netplane.com | | | | NetPlane Network Technologies (India) Pvt. Ltd. | | A Mindspeed Technologies Company | | | 189, Prashasan Nagar, Ph: +91-40-3553709 ~ 12 (Ext | | 1127) | | Road # 72, Jublee Hills, | | Hyderabad - 500033 | | | _________________________________________________________ | Do You Yahoo!? | Get your free @yahoo.com address at http://mail.yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.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 HAA18507 for ; Fri, 18 Jan 2002 07:38:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A6ACF9130D; Fri, 18 Jan 2002 07:38:23 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63BBC9130E; Fri, 18 Jan 2002 07: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 0CF449130D for ; Fri, 18 Jan 2002 07:38:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id D37DF5DE08; Fri, 18 Jan 2002 07:38:21 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 97FF45DDA3 for ; Fri, 18 Jan 2002 07:38:21 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA24040; Fri, 18 Jan 2002 07:38:18 -0500 (EST) Date: Fri, 18 Jan 2002 07:38:18 -0500 (EST) From: Russ White Reply-To: Russ White To: Alex Zinin Cc: Susan Hares , randy Bush , idr@merit.edu Subject: Re: bgp4-17 Cease subcode In-Reply-To: <40302627945.20020117194800@nexsi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk > > My primary question at this point isn't over leaving in text > > about somehow controlling flapping sessions, but whether or not > > we should say that exponential backup is the right way to do > > this. There might be more interesting ways that crop up in the > > future, so we should leave this open for thought, I think. > > I thought about this as well, and it seemed to me that if > this feature was documented as optional, that would leave > enough flexibility for the implementers to either not use it > at all (this would also solve the question of whether the > current implementations that do not do so are RFC-compliant) > or come up with a different scheme that would solve the > problem in another way, and, at the same time, give some clue > on one way of doing this thing. This would work (as I said before).... > On the other hand, I think it would be equally good if the > spec did not spell out the details and we had another > document discussing the topic in detail... if we have such a > commitment, of course ;-) But I prefer this, even if there isn't a commitment for a doc (yet). :-) Russ _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA13824 for ; Fri, 18 Jan 2002 05:21:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 088869130C; Fri, 18 Jan 2002 05:21:02 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1EFA9130D; Fri, 18 Jan 2002 05:21: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 9FDA99130C for ; Fri, 18 Jan 2002 05:21:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7954F5DE17; Fri, 18 Jan 2002 05:21:00 -0500 (EST) Delivered-To: idr@merit.edu Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by segue.merit.edu (Postfix) with SMTP id E678D5DE2B for ; Fri, 18 Jan 2002 05:20:59 -0500 (EST) Received: from leased-200-20-226.bng.vsnl.net.in (HELO Manav) (203.200.20.226) by smtp.mail.vip.sc5.yahoo.com with SMTP; 18 Jan 2002 10:20:32 -0000 Message-ID: <042f01c1a00a$22c72c40$b4036c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "Reddy, Sudhakar" Cc: Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt) Date: Fri, 18 Jan 2002 15:53:08 +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 Hi Sudhakar, I am not able to think of a scenario when this shall create a route flap or when it shall help in avoiding routing loops? Can you please explain such a scenario to me? Regards, Manav ----- Original Message ----- From: "Reddy, Sudhakar" To: "'Manav Bhatia'" ; Sent: Friday, January 18, 2002 3:29 PM Subject: RE: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt) | Hi Manav, | I can understand that this rule will help to avoided routing loops, and | ensures a consistent best path selection. But at the same time say if two | paths are from external peers, this may create a route-flap.(since a newer | path may displace on older one). | | Thanks, | Sudhakar _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.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 FAA13108 for ; Fri, 18 Jan 2002 05:00:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 52A969130B; Fri, 18 Jan 2002 04:59:42 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 201BA9130C; Fri, 18 Jan 2002 04:59: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 0A23A9130B for ; Fri, 18 Jan 2002 04:59:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id DFEA35DE2B; Fri, 18 Jan 2002 04:59:40 -0500 (EST) Delivered-To: idr@merit.edu Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by segue.merit.edu (Postfix) with ESMTP id 4F2965DE17 for ; Fri, 18 Jan 2002 04:59:40 -0500 (EST) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jan 2002 04:59:38 -0500 Message-ID: From: "Reddy, Sudhakar" To: "'Manav Bhatia'" , idr@merit.edu Subject: RE: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.t xt) Date: Fri, 18 Jan 2002 04:59:35 -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 Hi Manav, I can understand that this rule will help to avoided routing loops, and ensures a consistent best path selection. But at the same time say if two paths are from external peers, this may create a route-flap.(since a newer path may displace on older one). Thanks, Sudhakar -----Original Message----- From: Manav Bhatia [mailto:mnvbhatia@yahoo.com] Sent: Friday, January 18, 2002 2:23 PM To: Reddy, Sudhakar; idr@merit.edu Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt) Hi Reddy, This tie breaking rule is followed by a lot of BGP implementations in the Internet. This is generally kept as the last resort for tie breaking and is followed in a lot of BGP implementations. CISCO also suggests this in its BGP Best Path Selection Algorithm. Infact even ZEBRA supports this! Regards, Manav ----- Original Message ----- From: "Reddy, Sudhakar" To: Cc: "Reddy, Sudhakar" Sent: Friday, January 18, 2002 2:10 PM Subject: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt) | Hi, | I have a question about BGP tie braking rules. In the BGP new draft | "draft-ietf-idr-bgp4-17.txt" section 9.1.2.2, the last tie breaking rule g) | is as follows: | "g) Prefer the route received from the lowest neighbor address." | | What is the relevance of this rule? Is this tie breaking rule | present in BGP implementations in the Internet? | | Thanks in advance, | Sudhakar | ------------------------------------------------------------------------- --- | - | R. Sudhakar Reddy mailto:sudhakarr@netplane.com | | NetPlane Network Technologies (India) Pvt. Ltd. | A Mindspeed Technologies Company | 189, Prashasan Nagar, Ph: +91-40-3553709 ~ 12 (Ext | 1127) | Road # 72, Jublee Hills, | Hyderabad - 500033 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.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 DAA11561 for ; Fri, 18 Jan 2002 03:50:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7E5E491309; Fri, 18 Jan 2002 03:50:18 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4BB279130A; Fri, 18 Jan 2002 03:50: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 31CE691309 for ; Fri, 18 Jan 2002 03:50:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 078635DE2A; Fri, 18 Jan 2002 03:50:17 -0500 (EST) Delivered-To: idr@merit.edu Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by segue.merit.edu (Postfix) with SMTP id 7D2035DE17 for ; Fri, 18 Jan 2002 03:50:16 -0500 (EST) Received: from leased-200-20-226.bng.vsnl.net.in (HELO Manav) (203.200.20.226) by smtp.mail.vip.sc5.yahoo.com with SMTP; 18 Jan 2002 08:50:14 -0000 Message-ID: <038b01c19ffd$85ef7690$b4036c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "Reddy, Sudhakar" , References: Subject: Re: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt) Date: Fri, 18 Jan 2002 14:22:50 +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 Hi Reddy, This tie breaking rule is followed by a lot of BGP implementations in the Internet. This is generally kept as the last resort for tie breaking and is followed in a lot of BGP implementations. CISCO also suggests this in its BGP Best Path Selection Algorithm. Infact even ZEBRA supports this! Regards, Manav ----- Original Message ----- From: "Reddy, Sudhakar" To: Cc: "Reddy, Sudhakar" Sent: Friday, January 18, 2002 2:10 PM Subject: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt) | Hi, | I have a question about BGP tie braking rules. In the BGP new draft | "draft-ietf-idr-bgp4-17.txt" section 9.1.2.2, the last tie breaking rule g) | is as follows: | "g) Prefer the route received from the lowest neighbor address." | | What is the relevance of this rule? Is this tie breaking rule | present in BGP implementations in the Internet? | | Thanks in advance, | Sudhakar | ------------------------------------------------------------------------- --- | - | R. Sudhakar Reddy mailto:sudhakarr@netplane.com | | NetPlane Network Technologies (India) Pvt. Ltd. | A Mindspeed Technologies Company | 189, Prashasan Nagar, Ph: +91-40-3553709 ~ 12 (Ext | 1127) | Road # 72, Jublee Hills, | Hyderabad - 500033 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.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 DAA11359 for ; Fri, 18 Jan 2002 03:41:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 46FD091307; Fri, 18 Jan 2002 03:40:57 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E56B91309; Fri, 18 Jan 2002 03:40:56 -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 CE0DC91307 for ; Fri, 18 Jan 2002 03:40:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id ACFD55DE2A; Fri, 18 Jan 2002 03:40:55 -0500 (EST) Delivered-To: idr@merit.edu Received: from xover.mindspeed.com (cnxt10002.conexant.com [198.62.10.2]) by segue.merit.edu (Postfix) with ESMTP id 312895DE17 for ; Fri, 18 Jan 2002 03:40:55 -0500 (EST) Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Jan 2002 03:40:45 -0500 Message-ID: From: "Reddy, Sudhakar" To: "'idr@merit.edu'" Cc: "Reddy, Sudhakar" Subject: A Question about Tie breaking rules (draft-ietf-idr-bgp4-17.txt) Date: Fri, 18 Jan 2002 03:40:42 -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 Hi, I have a question about BGP tie braking rules. In the BGP new draft "draft-ietf-idr-bgp4-17.txt" section 9.1.2.2, the last tie breaking rule g) is as follows: "g) Prefer the route received from the lowest neighbor address." What is the relevance of this rule? Is this tie breaking rule present in BGP implementations in the Internet? Thanks in advance, Sudhakar ---------------------------------------------------------------------------- - R. Sudhakar Reddy mailto:sudhakarr@netplane.com NetPlane Network Technologies (India) Pvt. Ltd. A Mindspeed Technologies Company 189, Prashasan Nagar, Ph: +91-40-3553709 ~ 12 (Ext 1127) Road # 72, Jublee Hills, Hyderabad - 500033 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 AAA06412 for ; Fri, 18 Jan 2002 00:52:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E07FC91306; Fri, 18 Jan 2002 00:51:42 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9DB291307; Fri, 18 Jan 2002 00:51: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 BA79391306 for ; Fri, 18 Jan 2002 00:51:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 932655DE19; Fri, 18 Jan 2002 00:51:41 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail.nexsi.com (unknown [66.35.212.41]) by segue.merit.edu (Postfix) with ESMTP id 33BEA5DDF4 for ; Fri, 18 Jan 2002 00:51:41 -0500 (EST) Received: from khonsu.sw.nexsi.com (cscovpn3.nexsi.com [172.16.213.3]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id VAA26514; Thu, 17 Jan 2002 21:50:22 -0800 Date: Thu, 17 Jan 2002 19:48:00 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <40302627945.20020117194800@nexsi.com> To: Russ White Cc: Russ White , Susan Hares , randy Bush , Subject: Re: bgp4-17 Cease subcode In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Russ: > My primary question at this point isn't over leaving in text > about somehow controlling flapping sessions, but whether or not > we should say that exponential backup is the right way to do > this. There might be more interesting ways that crop up in the > future, so we should leave this open for thought, I think. I thought about this as well, and it seemed to me that if this feature was documented as optional, that would leave enough flexibility for the implementers to either not use it at all (this would also solve the question of whether the current implementations that do not do so are RFC-compliant) or come up with a different scheme that would solve the problem in another way, and, at the same time, give some clue on one way of doing this thing. On the other hand, I think it would be equally good if the spec did not spell out the details and we had another document discussing the topic in detail... if we have such a commitment, of course ;-) Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA03385 for ; Thu, 17 Jan 2002 22:46:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0C14291303; Thu, 17 Jan 2002 22:45:29 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0723C91304; Thu, 17 Jan 2002 22:45: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 DB43B91303 for ; Thu, 17 Jan 2002 22:45:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id A82F15DDCD; Thu, 17 Jan 2002 22:45:25 -0500 (EST) Delivered-To: idr@merit.edu Received: from titanium.zebra.org (unknown [209.11.132.18]) by segue.merit.edu (Postfix) with ESMTP id 1CEC85DDB9 for ; Thu, 17 Jan 2002 22:45:25 -0500 (EST) Received: from titanium.zebra.org (IDENT:kunihiro@localhost [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id VAA01193; Thu, 17 Jan 2002 21:46:46 -0500 Date: Thu, 17 Jan 2002 18:46:46 -0800 Message-ID: From: Kunihiro Ishiguro To: Susan Hares Cc: Vincent Gillet , Yakov Rekhter , Jeffrey Haas , idr@merit.edu Subject: Re: bgp4-17 Cease subcode In-Reply-To: <5.0.0.25.0.20020116181115.03ea46f8@mail.nexthop.com> References: <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <87advfjcqi.wl@vaio.zebra.org> <5.0.0.25.0.20020116181115.03ea46f8@mail.nexthop.com> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.1 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk >Here's the state machine diagram and event plan that >matches the state machine. You could >look at the state machine diagram to easily walk through >the words. Thanks Sue. It's very helpful to understand the whole picture. Here is a draft of FSM section based upon bgp4-16 description and your FSM chart. I tried: o Create a new sub-section 8.1 for Exponential Back-off. o Do not add IdelHold status. o Use new bgp4-17 like action description format (I use bullet for each action). Any comments are welcome. --------------------------------------------------------------------------- 8. BGP Finite State machine. This section specifies BGP operation in terms of a Finite State Machine (FSM). Following is a brief summary and overview of BGP operations by state as determined by this FSM. Initially BGP is in the Idle state. Idle state: In this state BGP refuses all incoming BGP connections. No resources are allocated to the peer. In response to the Start event initiated by either system or operator (see Section 8.1) the local system: o Initializes all BGP resources. o Starts the ConnectRetry timer. o Initiates a transport connection to other BGP peer. o Changes its state to Connect. The exact value of the ConnectRetry timer is a local matter, but should be sufficiently large to allow TCP initialization. Any other event received in the Idle state is ignored. Connect state: In this state BGP is waiting for the transport protocol connection to be completed. If the transport protocol connection succeeds, the local system: o Clears the ConnectRetry timer. o Completes initialization. o Sends an OPEN message to its peer. o Changes its state to OpenSent. If the transport protocol connect fails (e.g., retransmission timeout), the local system: o Restarts the ConnectRetry timer. o Continues to listen for a connection that may be initiated by the remote BGP peer. o Changes its state to Active state. In response to the ConnectRetry timer expired event, the local system: o Restarts the ConnectRetry timer. o Initiates a transport connection to other BGP peer. o Continues to listen for a connection that may be initiated by the remote BGP peer. o Stays in the Connect state. The Start event is ignored in the Connect state. In response to any other event (initiated by either system or operator), the local system releases all BGP resources associated with this connection and changes its state to Idle. Active state: In this state BGP is trying to acquire a peer by listening for and accepting a transport protocol connection. If the transport protocol connection succeeds, the local system: o Clears the ConnectRetry timer. o Completes initialization. o Sends an OPEN message to its peer. o Sets its Hold Timer to a large value. o Changes its state to OpenSent. A Hold Timer value of 4 minutes is suggested. In response to the ConnectRetry timer expired event, the local system: o Restarts the ConnectRetry timer. o Initiates a transport connection to the other BGP peer. o Continues to listen for a connection that may be initiated by the remote BGP peer. o Changes its state to Connect. If the local system does not allow BGP connections with unconfigured peers, then the local system: o Rejects connections from IP addresses that are not configured peers. o Remains in the Active state. The Start event is ignored in the Active state. In response to any other event (initiated by either system or operator), the local system releases all BGP resources associated with this connection and changes its state to Idle. OpenSent state: In this state BGP waits for an OPEN message from its peer. When an OPEN message is received, all fields are checked for correctness. If the BGP message header checking or OPEN message checking detects an error (see Section 6.2), or a connection collision (see Section 6.8) the local system sends a NOTIFICATION message and changes its state to Idle. If there are no errors in the OPEN message, the local system: o Sends a KEEPALIVE message. o Sets a KeepAlive timer. o Sets a Hold timer according to the negotiated Hold time value (see section 4.2). o Changes its state to OpenConfirm. If the negotiated Hold time value is zero, then the Hold timer and KeepAlive timers are not started. If the value of the Autonomous System field is the same as the local Autonomous System number, then the connection is an "internal" connection; otherwise, it is an "external" connection. (This will impact UPDATE processing as described below.) If a disconnect notification is received from the underlying transport protocol, the local system: o Closes the BGP connection. o Restarts the ConnectRetry timer. o Continue listening for connection that may be initiated by the remote BGP peer. o Changes its state to Active. If the Hold Timer expires, the local system: o Sends NOTIFICATION message with error code Hold Timer Expired. o Changes its state to Idle. In response to the Stop event (initiated by either system or operator) the local system: o Sends NOTIFICATION message with Error Code Cease. o Changes its state to Idle. The Start event is ignored in the OpenSent state. In response to any other event the local system: o Sends NOTIFICATION message with Error Code Finite State Machine Error o Changes its state to Idle. Whenever BGP changes its state from OpenSent to Idle, it closes the BGP (and transport-level) connection and releases all resources associated with that connection. OpenConfirm state: In this state BGP waits for a KEEPALIVE or NOTIFICATION message. If the local system receives a KEEPALIVE message, the local system: o Changes its state to Established. If the Hold Timer expires before a KEEPALIVE message is received, the local system: o Sends NOTIFICATION message with error code Hold Timer Expired. o Changes its state to Idle. If the local system receives a NOTIFICATION message, the local system: o Changes its state to Idle. If the KeepAlive timer expires, the local system: o Sends a KEEPALIVE message. o Restarts its KeepAlive timer. If a disconnect notification is received from the underlying transport protocol, the local system: o Changes its state to Idle. In response to the Stop event (initiated by either system or operator) the local system: o Sends NOTIFICATION message with Error Code Cease. o Changes its state to Idle. The Start event is ignored in the OpenConfirm state. In response to any other event the local system: o Sends NOTIFICATION message with Error Code Finite State Machine Error. o Changes its state to Idle. Whenever BGP changes its state from OpenConfirm to Idle, it closes the BGP (and transport-level) connection and releases all resources associated with that connection. Established state: In the Established state BGP can exchange UPDATE, NOTIFICATION, and KEEPALIVE messages with its peer. If the local system receives an UPDATE or KEEPALIVE message, the local system: o Restarts its Hold Timer, if the negotiated Hold Time value is non-zero. If the local system receives a NOTIFICATION message, the local system: o Changes its state to Idle. If the local system receives an UPDATE message and the UPDATE message error handling procedure (see Section 6.3) detects an error, the local system: o Sends a NOTIFICATION message. o Changes its state to Idle. If a disconnect notification is received from the underlying transport protocol, the local system: o Changes its state to Idle. If the Hold Timer expires, the local system: o Sends a NOTIFICATION message with Error Code Hold Timer Expired. o Changes its state to Idle. If the KeepAlive timer expires, the local system: o Sends a KEEPALIVE message. o Restarts its KeepAlive timer. if the negotiated Hold time value is non-zero. Each time the local system sends a KEEPALIVE or UPDATE message, it restarts its KeepAlive timer, if the negotiated Hold Time value is non-zero. In response to the Stop event (initiated by either system or operator), the local system sends a NOTIFICATION message with Error Code Cease and changes its state to Idle. The Start event is ignored in the Established state. In response to any other event, the local system: o Sends NOTIFICATION message with Error Code Finite State Machine Error. o Changes its state to Idle. Whenever BGP changes its state from Established to Idle, it closes the BGP (and transport-level) connection, releases all resources associated with that connection, and deletes all routes derived from that connection. 8.1 Exponential Back-off. If a BGP speaker detects an error, it shuts down the connection and changes its state to Idle. Getting out of the Idle state requires generation of the Start event. If such an event is generated automatically, then persistent BGP errors may result in persistent flapping of the speaker. To avoid such a condition it is recommended that Start events should not be generated immediately for a peer that was previously transitioned to Idle due to an error. For a peer that was previously transitioned to Idle due to an error, the time between consecutive generation of Start events, if such events are generated automatically, shall exponentially increase. The value of the initial timer shall be 60 seconds. The time shall be doubled for each consecutive retry. Suggested value for this timer is: 2**(consecutive retry count)*60 An implementation MAY impose a configurable upper bound on that timer value. Once the upper bound is reached, the speaker shall stop the timer then no longer automatically generate the Start event for the peer. 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 WAA02755 for ; Thu, 17 Jan 2002 22:21:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DE87791302; Thu, 17 Jan 2002 22:21:34 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADDAD91303; Thu, 17 Jan 2002 22:21: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 1B47F91302 for ; Thu, 17 Jan 2002 22:21:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id A28CB5DE08; Thu, 17 Jan 2002 22:21:27 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 67DE55DDB9 for ; Thu, 17 Jan 2002 22:21:27 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA22960; Thu, 17 Jan 2002 22:21:23 -0500 (EST) Date: Thu, 17 Jan 2002 22:21:23 -0500 (EST) From: Russ White Reply-To: Russ White To: Alex Zinin Cc: Susan Hares , randy Bush , idr@merit.edu Subject: Re: bgp4-17 Cease subcode In-Reply-To: <32264605142.20020117091413@nexsi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Alex: My primary question at this point isn't over leaving in text about somehow controlling flapping sessions, but whether or not we should say that exponential backup is the right way to do this. There might be more interesting ways that crop up in the future, so we should leave this open for thought, I think. :-) Russ On Thu, 17 Jan 2002, Alex Zinin wrote: > > Sue, > > To clarify my position: I think that recommendation for an > exponential back-off is a good thing and solves a real > problem. However, I think that the IdleHold state should not > be in the FSM because: > > 1) It seems to be redundant. See (*) below. > 2) It introduces changes to the base FSM to account for > a feature of an optional nature. People who didn't > implement it would be put in a non-compliant position, > people who won't implement it will have to take things > out of the FSM. > 3) I am under impression (though I might be wrong) that > it does not match the majority of deployed implementations > that do not have this state and hence would ago against the > objective of this spec review round. > --- > *) When it comes to FSMs, one almost always can achieve the same > results by either using an existing state with flags or by adding > another state. It is often hard to decide which approach to follow. > One simple test I find useful is to see how different periodic > activities, packet and event processing are for the two states. > If there is a considerable difference, separate states are most > probably a good idea. In our case, the two states are practically > the same---we don't do anything on a periodic basis (no messages, > no outbound connections), we do not accept incoming connections, > we ignore all events but Start. The difference is essentially in > the reason we get to either state, which affects the name of > the state and when the Start event is generated. IMHO it does not > justify a new state, but that's my personal opinion :) I think > the original text from -12 (maybe revised a bit) should be good > enough... > > -- > Alex Zinin > > Thursday, January 17, 2002, 5:51:35 AM, Susan Hares wrote: > > > > Alex and Randy: > > > Let's go back to first principles here on the FSM? > > > 1st) The original text is below from draft-12. > > > This explanation gives "flag" that has implications > > for the full state machine. The definition of > > state machines that Alex proposes, is all inputs > > and all actions are determined by state machine in > > clear text. > > > 2nd) Is the bug real? > > > The text was fixing a " persistent bgp flapping" > > bug. According to the text there is a > > state within a state with fairly vague > > descriptions. > > > The second question belongs to Randy, since he wears 2 hats (Operations > > and Routing temp AD), was this a real problem? Has it gone away? > > > 1) At least one routing vendor doesn't implement it [cisco] > > and I know this vendor is utilized in BGP peering sessions > > in the network. > > > 2) What was the operational concern this text implies? > > > If there is no operational issue and no operational usage, > > return to the original FSM text and out the comments on > > "hold down." > > > So, Randy and all other operators - Is the problem it describes real? > > Does anyone need it? Let's answer that question first. > > > > > > Sue Hares > > > ---------------------- > > > > If a BGP speaker detects an error, it shuts down the connection > > and changes its state to Idle. Getting out of the Idle state > > requires generation of the Start event. If such an event is > > generated automatically, then persistent BGP errors may result > > in persistent flapping of the speaker. To avoid such a > > condition it is recommended that Start events should not be > > generated immediately for a peer that was previously > > transitioned to Idle due to an error. For a peer that was > > previously transitioned to Idle due to an error, the time > > > > > Expiration Date July 2001 [Page 31] > > > > > > > RFC DRAFT January 2001 > > > > between consecutive generation of Start events, if such events > > are generated automatically, shall exponentially increase. The > > value of the initial timer shall be 60 seconds. The time shall > > be doubled for each consecutive retry. > > > Any other event received in the Idle state is ignored. > > > > > At 11:10 AM 1/16/2002 -0800, you wrote: > > >>Sue, > >> > >> Introduction of the IdleHold does change the FSM, > >> and I thought we wanted the spec to reflect the current > >> running code as much as possible. > >> > >> I agree with Russ and Ishi---the new state does not > >> seem to be necessary, instead it could be as easy > >> as holding the session in Idle and giving clue on > >> how to make the delay exponential. I don't think > >> there's an interoperability issue if people decide > >> to keep the session in Idle using different internal > >> mechanisms. > >> > >> Regards, > >> > >>-- > >>Alex Zinin > >> > >>Wednesday, January 16, 2002, 6:04:36 AM, Susan Hares wrote: > >> > >> > Kunihiro: > >> > >> > We are not changing the FSM so I would be surprised if the change > >> > was anything but modest. Usually specifications with "no big" deal get > >> > interpreted differently. Inter-operable code means you tie down the > >> details. > >> > >> > The comment was on the clarity of the specification. > >> > >> > If you have a specific comment on the text of the state machine, > >> > can you propose the concerns you have as a revision to the text. > >> > >> > Sue > >> > >> > PS -- I just love last call on a draft... It's when > >> > everyone finally reads a new section ;-)... > >> > >> > >> > At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote: > >> >> >> > Is the expoential backoff in the FSM in current implementations? > >> >> >> > >> >> >> I guess we are going to find this out as part of the implementation > >> >> >> report. And if it is not in (at least two) current implementations, > >> >> >> we'll take it out of the text. > >> >> > > >> >> >I implemented Cease subcode in zebra-0.92a but not exponential backoff. > >> >> >I checked that new subcode does not put other BGP stack in trouble > >> >> >(checked Cisco and Juniper). > >> >> > >> >>First of all, sorry for talking about specific implementation. In > >> >>Zebra implementation we've implemented Cease subcode. The code is in > >> >>CVS repository. I'll prepare a release version for that. > >> >> > >> >>And also we've implemented exponetial backoff. It is done without > >> >>introducing new FSM status. It is not a big deal. Just check a flag > >> >>in a few functions. > >> > >> > >> >>Exponential backoff is a good feature. I can't understand why it > >> >>require change to FSM. > > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA29822 for ; Thu, 17 Jan 2002 20:49:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ECCC491301; Thu, 17 Jan 2002 20:49:19 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA27591302; Thu, 17 Jan 2002 20:49:19 -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 D0ECE91301 for ; Thu, 17 Jan 2002 20:49:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id A46905DE04; Thu, 17 Jan 2002 20:49:18 -0500 (EST) Delivered-To: idr@merit.edu Received: from demiurge.exodus.net (unknown [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 28BD05DDB9 for ; Thu, 17 Jan 2002 20:49:18 -0500 (EST) Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id RAA12068; Thu, 17 Jan 2002 17:46:30 -0800 (PST) Date: Thu, 17 Jan 2002 17:46:30 -0800 From: andrewl@exodus.net To: Susan Hares Cc: Alex Zinin , randy Bush , fenner@research.att.com, idr@merit.edu Subject: Re: bgp4-17 Cease subcode Message-ID: <20020117174630.J19424@demiurge.exodus.net> References: <5.0.0.25.0.20020117083423.0252ef28@mail.nexthop.com> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <20020115140711.GA23937@opentransit.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <5.0.0.25.0.20020117083423.0252ef28@mail.nexthop.com> <32264605142.20020117091413@nexsi.com> <5.0.0.25.0.20020117124225.042f96e0@mail.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.0.25.0.20020117124225.042f96e0@mail.nexthop.com>; from skh@nexthop.com on Thu, Jan 17, 2002 at 01:28:40PM -0500 Sender: owner-idr@merit.edu Precedence: bulk > 3)bgp exponential back-off One operator's view: The vendor we use for our peering and backbone boxes doesn't implement this feature. However, we would like it. What usually happens when we have a flapping BGP session, due to say, a bad circuit, is someone is forced to come in and shut it down manually, then bring it back up at some point when the circuit is stable again. With exponential backoff the lengths of the retrys would rapidly get to the point where human intervention to shut the session down manually would not be required. And the box would still try to bring up the session occasionally, eliminating the "Oops, I forgot to bring that back up" problem. As for the FSM, were we to have this feature we would demand a command from the vendor that would indicate what the status of the backoff is. So when we did a "sh ip bgp summ" we could see either that it was transitioned to idle for x reason and it had y seconds/minutes/hours remaining. The proposal to call that state "IdleHold" is a sound one. Although if it were called ("Idle - Hold Flag Set" or something that would be fine too.) And yes, we would want both the state and the time remaining in the MIB. Preferably, if the state were IdleHold, we would have a "try #, # of seconds remaining, # of seconds in this retry interval. Eg: BackoffAttemptNumber: 5 BackoffSecondsRemaining: 38 BackoffSecondsTotalThisAttempt: 960 And being the generally knob-happy types we operators are :), a max-backoff value or the like would be good as an enhancement. 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 UAA29672 for ; Thu, 17 Jan 2002 20:46:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B7AF591300; Thu, 17 Jan 2002 20:45:22 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8926891301; Thu, 17 Jan 2002 20:45: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 9993591300 for ; Thu, 17 Jan 2002 20:45:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4EE0E5DE04; Thu, 17 Jan 2002 20:45:18 -0500 (EST) Delivered-To: idr@merit.edu Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id 9ED825DDB9 for ; Thu, 17 Jan 2002 20:45:17 -0500 (EST) Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id 9E1743F6A for ; Thu, 17 Jan 2002 17:47:48 -0800 (PST) Received: from khonsu.sw.nexsi.com ([172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id RAA25335 for ; Thu, 17 Jan 2002 17:44:11 -0800 Date: Thu, 17 Jan 2002 17:44:11 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <9295199534.20020117174411@nexsi.com> To: idr@merit.edu Subject: More thoughts on FSM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Folks, I mentioned multiple times that I'd like the FSM to be represented in a more formal way. Below is what I have in mind. It is just a scratch, by no means complete. I'd like to know what people think about the idea. If there's a common feeling that this would be useful, I would invest more time in it... -- Alex. 1. Session attributes The following attributes required for FSM operation are associated with each BGP session: State: Indicates the current state of the BGP session FSM. Possible FSM states are described in Section 3. Start timer: A timer used for automatic generation of the evStart event. ConnectRetry timer: A timer used for periodic initialization of an outgoing transport session when FSM is in stConnected and stActive states. Expiration of this timer triggers generation of the evConnectRetryExp FSM event. NOTE: The exact value of the ConnectRetry timer is a local matter, but it should be sufficiently large to allow TCP initialization. HoldTime: Period of time negotiated between BGP peers and used to detect unreachable speakers. If no UPDATE or KEEPALIVE message has been received through a BGP session during the HoldTime period, the remote peer is declared unreachable and the session is reset. Hold timer: A one shot timer initialized with HoldTime value and indicating that no valid messages have been received through the BGP session. Expiration of this timer triggers generation of the evHoldTimerExp FSM event. NOTE: If the negotiated HoldTime value is zero, the Hold timer is not started. KeepAlive timer: A periodic timer used to send a KEEPALIVE message to the remote BGP peer if no UPDATE message have been sent to it within a period of time (the timer is reset every time an UPDATE message is sent out). NOTE: If the negotiated HoldTime value is zero, the KeepAlive timer is not started. 2. Events: Timer-based events: evKeepAliveTimerExp: A periodic event generated due to expiration of the KeepAlive timer. This event is processed in FSM states stOpenConfirmed and stEstablished and triggers transmition of a KEEPALIVE message. evConnectRetryExp: An event triggered by expiration of the ConnectRetry timer. Processed in states stConnect and stActive, this event leads to initiation of an outbound transport session. evHoldTimerExp: An event generated when the session's HoldTimer expires. Processed in states stOpenConfirmed and higher, this event indicates that no UPDATE or KEEPALIVE messages have been received from the peer and the FSM needs to be reset. Message-processing related events: evTransSucc: An event indicating that the oubound transport session initiated previously has been successfully established. evTransFail: An event indicating that the oubound transport session initiated previously could not be established. evTransDisc: An event indicating that the transport session associated with the FSM instance has been disconnected. evOpenMsgRcvd: An event indicating that a valid OPEN message has been received and no connection collision has been detected. evOpenMsgErr: An event indicating that received OPEN messages is not correct. evCollision: An event generated when a connection collision has been detected while processing an incoming OPEN message. See section XXX for more information on collision detection. evNotifMsg: An event triggered by reception of a NOTIFICATION message. evNotifMsgVerErr: An event generated when a NOTIFICATION message with "Version Error" code is received. evKeepAliveMsg: An event generated when a KEEPALIVE message is received. evUpdateMsg: An event indicating that an UPDATE message has been received evUpdateMsgErr: An event indicating that received UPDATE message is not correct. Administrative events: evStart: An event initiated by an operator or the system in response to Start timer expiration to initiate the BGP session establishment procedure. This event affects only sessions in the stIdle state and is ignored in others. If this event is generated automatically, then persistent BGP errors may result in persistent flapping of a BGP session. To avoid such a condition it is recommended that evStart events are not generated immediately for a session that was previously transitioned to stIdle due to an error. For a session that was previously transitioned to stIdle due to an error, the time between consecutive generation of evStart events, if such events are generated automatically, should exponentially increase. The value of the initial timer should be 60 seconds. The time should be doubled for each consecutive retry. evStopManual: An event initiated by an operator and indicating that the BGP session should be administratively torn down. evStopAuto: An event generated by the system to bring a BGP session down. An example when this event can be generated is exceeding the maximum number of prefixes allowed for a given peer. XXX: we could combine evStopManual and evStopAuto in one. 3. States A BGP speaker creates an instance of a BGP session FSM for each configured peer. It may also be created dynamically when an incoming transport connection is reported, there's no matching configured peer and the speaker is configured to accept such connections. FSMs created for configured peers are initially put in the Idle state. See section XXX for more information on incoming transport connection processing. Each state is described below, including the list of processed and ignored events. Also, a list of actions performed when the FSM transitions to a specific state is provided (In-Actions). For some states, a list of actions performed when transitioning from the state is included (Out-Actions). stIdle: This is the initial state of the FSM. This state is also used to keep BGP sessions in the inactive state when necessary. An evStart event (manual or automatic) is necessary to get the FSM out of the Idle state. Valid events : evStart Ignored events : all others Ivalid events : None In-Actions: 1. If transitioning from a higher state: o If the associated transport connection is open, close it. o Stop all timers except for the Start timer o Release resources allocated for the session, including invalidation of all routes possibly received from the peer 2. Start the Start timer. See Section XXX for more info. stConnect: In this state, BGP has initiated an outbound transport connection and is waiting for it to be completed. Valid events : evConnectRetryExp, evTransSucc, evTransFail, evStopManual, evStopAuto Ignored events : evStart Invalid events : all others In-Actions: 1. If necessary (e.g., previous state is Idle), initialize resources for the BGP session 2. Start (or restart if already running) the ConnectRetry timer. 3. Initiate a transport connection to the peer. 4. Listen (or continue listening) for a connection that may be initiated by the peer stActive: In this state BGP is not actively initiating an outbound transport connection, but is trying to acquire a peer by listening for and accepting an incoming one. Valid events : evConnectRetryExp, evTransSucc evStopManual, evStopAuto Ignored events : evStart Invalid events : all others In-Actions: 1. If necessary, close the transport connection 2. Restart the ConnectRetry timer 3. Continue to listen for a connection that may be initiated by the remote BGP peer stOpenSent: In this state, the local system has sent out an OPEN messages and awaits an OPEN message from the peer. Valid events : evOpenMsgRcvd, evNotifMsg, evStopManual, evStopAuto evHoldTimerExp Ignored events : evStart Invalid events : all others In-Actions: 1. Stop the ConnectRetry timer 2. Complete session initialization (don't know what this really means spec-wise) 3. Send an OPEN message to the peer 4. Set Hold timer to a large value (see note below) 5. Stop listening for an incoming transort connection NOTE: A hold timer value of 4 minutes is suggested. stOpenConfirm: In this state, the local system has received an OPEN message from the peer, confirmed its reception by sending out a KEEPALIVE message, and awaits an incoming KEEPALIVE message confirming that the remote peer received the OPEN message sent before, or an icoming NOTIFICATION message reporting a problem. Valid events : evKeepAliveTimerExp, evKeepAliveMsg evCollision, evNotifMsg, evStopManual, evStopAuto, evHoldTimerExp Ignored events : evStart Invalid events : all others In-Actions: 1. Send a KEEPALIVE message 2. Set the KeepAlive timer (see note below) 3. Set the Hold timer according to the negotiated value (see section 4.2 and note below) NOTE: If the negotiated Hold time value is zero, then the Hold and KeepAlive timers are not started. If the value of the Autonomous System field is the same as the local Autonomous System number, then the connection is an "internal" connection; otherwise, it is an "external" connection. (This will impact UPDATE processing as described below.) stEstablished: This is the most advanced state of the FSM. In the Established state, BGP can exchange UPDATE, NOTFICATION, and KEEPALIVE messages with its peer. Valid events : evKeepAliveTimerExp, evNotifMsg, evKeepAliveMsg, evUpdateMsg, evUpdateMsgErr, evStopManual, evStopAuto, evHoldTimerExp Ignored events : evStart In-Actions: No standard actions 4. Incoming transport connection processing When an incoming connection is detected, the system performs the following steps: o Look up an existing instance of the session FSM, using the remote IP addresses as the key. o If the BGP session is not found: - If the system is configured to not allow BGP connections with unconfigured peers, reject the connection. - Otherwise, create a new instance of FSM, set the FSM state to stActive (without performing In-Actions for stActive) and generate evTransSucc event. o Otherwise (the session is found), processing depends on the state of the existing FSM: - If state is stIdle, reject the incoming connection (No incoming connections are allowed in the stIdle state.) - If state is stConnected, accept the incoming connection, create a new instance of FSM, set the FSM state to stActive (without performing In-Actions for stActive) and generate evTransSucc event. /* I don't believe in this, but the spec treats * competing connections as seperate BGP sessions */ - If state is stActive, accept the incoming connection, associate it with the existing session and generate the evTransSucc FSM event. - Otherwise (the FSM state is none of the above), reject the incoming connection. /* We could also generate an event here, but that * would cause an FSM restart */ While in stConnected, a BGP speaker can initiate an outbound connection and accept an incoming one (this specification treats these connections as separate BGP sessions). See section XXX for more information on how the situation of connection collision is handled. 5. Event processing and state transitions FSM operation is described below as follows. All state transitions are grouped by the initial FSM state. For each state, event processing rules with associated actions are described. State: stIdle ------------- Event : evStart New State : stConnect Actions : Standard stConnect In-Actions All other events are ignored. State: stConnect ---------------- Event : evTransSucc New State : stOpenSent Actions : Standard stOpenSent In-Actions Event : evTransFail New State : stActive Actions : Standard stActive In-Actions Event : evConnectRetryExp New State : stConnect Actions : Standard stConnect In-Actions Event : invalid events New State : stIdle Actions : Standard stIdle In-Actions. All other events are ignored. State: stActive --------------- Event : evTransSucc New State : stOpenSent Actions : Standard stOpenSent In-Actions Event : evConnectRetryExp New State : stConnect Actions : Standard stConnect In-Actions Event : invalid events New State : stIdle Actions : Standard stIdle In-Actions All other events are ignored. State: stOpenSent ----------------- Event : evOpenMsgErr, evCollision New State : stIdle Actions : Standard stIdle In-Actions Event : evOpenMsgRcvd New State : stOpenConfirm Actions : Standard stOpenConfirm In-Actions Event : evTransDisc New State : stActive Actions : Standard stActive In-Actions Event : evHoldTimerExp New State : stIdle Actions : 1. Send a NOTIFICATION message with error code "Hold Timer Expired" 2. Standard stIdle In-Actions Event : evNotifMsgVerErr New State : stIdle Actions : Standard stIdle In-Actions Event : evNotifMsg, and others New State : stIdle Actions : Standard stIdle In-Actions All other events are ignored. State: stOpenConfirmed ---------------------- Event : evKeepAliveMsg New State : stEstablished Actions : none Event : evHoldTimerExp New State : stIdle Actions : 1. Send a NOTIFICATION message with the error code "Hold Timer Expired" 2. Standard stIdle In-Actions Event : evNotifMsg, evTransDisc New State : stIdle Actions : Standard stIdle In-Actions Event : evStopAuto New State : stIdle Actions : 1. Send a NOTIFICATION message with the error code "Cease" 2. Standard stIdle In-Actions Event : evStopManual New State : stIdle Actions : 1. Send a NOTIFICATION message with the error code "Cease" 2. Standard stIdle In-Actions Event : invalid events New State : stIdle Actions : 1. Send a NOTIFICATION message with the error code "FSM Error" 2. Standard stIdle In-Actions All other events are ignored. State: stEstablished -------------------- Event : evKeepAliveMsg, evUpdateMsg New State : stEstablished Actions : Restart the Hold timer, if the negotiated Hold Time value is non-zero. Event : evNotifMsg, evTransDisc New State : stIdle Actions : Standard stIdle In-Actions Event : evUpdateMsgErr New State : stIdle Actions : 1. Send a NOTIFICATION message with the error code "Update Error" 2. Standard stIdle In-Actions Event : evUpdateMsgErr New State : stIdle Actions : 1. Send a NOTIFICATION message with the error code "Hold Timer Expired" 2. Standard stIdle In-Actions Event : evKeepAliveTimerExp New State : stEstablished Actions : 1. Send a KEEPALIVE message 2. Restart the KeepAlive timer, unless the negotiated Hold Time value is zero. Event : evStopAuto New State : stIdle Actions : 1. Send a NOTIFICATION message with the error code "Cease" 2. Standard stIdle In-Actions 3. Deletes all routes (in stIdle In-Actions already) Event : evStopManual New State : stIdle Actions : 1. Send a NOTIFICATION message with the error code "Cease" ??? (it was not in Sue's FSM) 2. Standard stIdle In-Actions Event : invalid events New State : stIdle Actions : 1. Send a NOTIFICATION message with the error code "FSM Error" 2. Standard stIdle In-Actions 3. Deletes all routes (in stIdle In-Actions already) All other events are ignored. *Incomplete* state transition diagram below. Only main state transitions are shown. +---------+ evStart | | +--------| Idle | | | | | +---------+ | | v +---------+ evTransFail +---------+ +->| |------------------->| | evConnRtrExp | | Connect | | Active | +--| |<-------------------| | +---------+ evConnectRetryExp +---------+ | | ^ | evTransSucc | | evTransSucc| | | evTransDisc | +-------------+ | | | | |<-----+ | +------>| OpenSent | | | |---------+ +-------------+ | | evOpenMsgRcvd v +-------------+ +->| | evKeepAliveTimerExp | | OpenConfirm | +--| | +-------------+ | | evKeepAliveMsgRcvd v +-------------+ evKeepAliveMsg +->| | evUpdateMsg | | Established | evKeepAliveTimerExp +--| | +-------------+ 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 SAA26662 for ; Thu, 17 Jan 2002 18:42:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B7FAA912FE; Thu, 17 Jan 2002 18:42:14 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B771912FF; Thu, 17 Jan 2002 18:42:14 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 613EC912FE for ; Thu, 17 Jan 2002 18:42:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 648535DDB9; Thu, 17 Jan 2002 18:42:12 -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 E41625DDCD for ; Thu, 17 Jan 2002 18:42:11 -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 SAA28911 for ; Thu, 17 Jan 2002 18:42:03 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA03460 for ; Thu, 17 Jan 2002 18:42:05 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 17 Jan 2002 18:42:04 -0500 Message-ID: <39469E08BD83D411A3D900204840EC55576F1F@vie-msgusr-01.dc.fore.com> From: "Xie, Feng" To: "'idr@merit.edu'" Subject: A Question about MinASOriginationInterval Date: Thu, 17 Jan 2002 18:42:03 -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 Hi, I have a question about MinASOriginationInterval. In the BGP specification (RFC1771), section 9.2.3.2, there is a statement as follows: "The parameter MinASOriginationInterval determines the minimum amount of time that must elapse between successive advertisements of UPDATE messages that report changes within the advertising BGP speaker's own autonomous systems." My question is that whether there is an easy way to figure out whether a route update is for some change in my own AS or not. Suppose P1 and P2 are IBGP peers in AS#1. P1 receives an EBGP route and exports it to P2. For P1, the route is outside of AS#1, i.e., it is an EBGP route. However, for P2, the route is an IBGP route. How can P2 figure out whether the route is inside or outside of AS#1? Or maybe P2 can check its routing table. If it finds an IGP route for the same prefix, then the route is inside AS#2. If the route is owned by BGP, then it is from outside of AS#1. Feng Xie This e-mail and any attachments are confidential. If you are not the intended recipient, please notify us immediately by reply e-mail and then delete this message from your system. Do not copy this e-mail or any attachment, use the contents for any purposes, or disclose the contents to any other person: to do so could be a breach of confidence. 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 OAA19937 for ; Thu, 17 Jan 2002 14:36:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 318EE912E8; Thu, 17 Jan 2002 14:35:09 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF2E1912E9; Thu, 17 Jan 2002 14:35: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 267F5912E8 for ; Thu, 17 Jan 2002 14:35:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0265B5DDF5; Thu, 17 Jan 2002 14:35:07 -0500 (EST) Delivered-To: idr@merit.edu Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id C4C8F5DDF0 for ; Thu, 17 Jan 2002 14:35:06 -0500 (EST) Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id 6F4433F72; Thu, 17 Jan 2002 11:37:46 -0800 (PST) Received: from khonsu.sw.nexsi.com ([172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id LAA20225; Thu, 17 Jan 2002 11:34:05 -0800 Date: Thu, 17 Jan 2002 11:34:03 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <196272995176.20020117113403@nexsi.com> To: Susan Hares Cc: randy Bush , fenner@research.att.com, idr@merit.edu Subject: Re: bgp4-17 Cease subcode In-Reply-To: <5.0.0.25.0.20020117124225.042f96e0@mail.nexthop.com> References: <5.0.0.25.0.20020117083423.0252ef28@mail.nexthop.com> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <20020115140711.GA23937@opentransit.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <5.0.0.25.0.20020117083423.0252ef28@mail.nexthop.com> <5.0.0.25.0.20020117124225.042f96e0@mail.nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Sue, > 1) Thanks for your note. > Glad you think the bgp exponential back off is good. > We should get operator input to answer questions in #3. > I want to go with whatever the operator community has > deployed for this draft. OK. > 2) State machine text clean up was more than > the Idle Hold state > Just to let you know the FSM text was tighted up based on the > word document with the diagram I sent out. There were other > inconsistencies in the FSM that I fixed based on the states > not being consistent with this diagram. I understand, I meant the text about exp. back-off specifically should be all right. > I will generate the state machine table without > the idle hold state to indicate those differences first. > [Warning - this plus the 2 other state machines you > sent me to review will take me a while. Warning -- day turnaround > most likely] All right, thanks. I think I'll send my version out to the list today to get the feeling of what people think. > 3)bgp exponential back-off [stuff for SPs ;) ] > 4) comparing all your input --- still processing > I am plugging through the 2 versions of state > machine you sent. Did you send me a review > of the diagram (word document) I'm attaching again. > I didn't find that even though you mentioned > you had done it. Did I miss it? That would > speed up this process since a 5 page form is quicker to > review and glance over. Sue, I've briefly gone through several states in the table and had some questions and bugs: Event 3 (IdleHold expired, value under ceiling): I think this event should be ignored in Idle and higher Idle x 3: "FSM Error" is not an action, is it? Event 4: This event should be ignored in Idle and higher as well Connect x 7: There's no associated transport session yet, the event should be ignored OpenSent x 8: Ignore here? Event 9: Should be Rcv TCP Connect & peer accepted Connect x 9: Why incoming connection resets the FSM here? OpenSent x 9: Ignore here? Event 10: Should be Rcv TCP Connect & peer rejected Connect x 10: Why incoming connection resets the FSM here? OpenSent x 10: Ignore here? Connect x 11: Hold timer is not running here, ignore? Idle x 12: Idle here? Connect x 12: Events from here down should be ignored? IdleHold x 22: Should it be ignored and stay in IdleHold? Idle x 23: Idle/Ignore here? And probably the major one: there's no event that causes OpenSent->OpenConfirmed transition... Here I stopped. You should probably take another look and see if the table is generated correctly. Thanks. Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA18263 for ; Thu, 17 Jan 2002 13:29:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0E390912E6; Thu, 17 Jan 2002 13:29:24 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B55F7912E7; Thu, 17 Jan 2002 13:29: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 66964912E6 for ; Thu, 17 Jan 2002 13:29:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 214935DDE6; Thu, 17 Jan 2002 13:29:22 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id BBBBC5DDE2 for ; Thu, 17 Jan 2002 13:29:21 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0HISh373599; Thu, 17 Jan 2002 13:28:43 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020117124225.042f96e0@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 17 Jan 2002 13:28:40 -0500 To: Alex Zinin From: Susan Hares Subject: Re: bgp4-17 Cease subcode Cc: randy Bush , fenner@research.att.com, idr@merit.edu In-Reply-To: <32264605142.20020117091413@nexsi.com> References: <5.0.0.25.0.20020117083423.0252ef28@mail.nexthop.com> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <20020115140711.GA23937@opentransit.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <5.0.0.25.0.20020117083423.0252ef28@mail.nexthop.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_37894649==_" X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk --=====================_37894649==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Alex: 1) Thanks for your note. Glad you think the bgp exponential back off is good. We should get operator input to answer questions in #3. I want to go with whatever the operator community has deployed for this draft. 2) State machine text clean up was more than the Idle Hold state Just to let you know the FSM text was tighted up based on the word document with the diagram I sent out. There were other inconsistencies in the FSM that I fixed based on the states not being consistent with this diagram. I will generate the state machine table without the idle hold state to indicate those differences first. [Warning - this plus the 2 other state machines you sent me to review will take me a while. Warning -- day turnaround most likely] 3)bgp exponential back-off I would still like to hear from operators what was the problem and what this is being used for. If it is a serious problem, and people need it we can get feedback on: a) Do operators use the flapping bgp speaker upon automatic configuration on any router in their network? If so, why? b) If they utilize this feature, how do they detect that the back-off is going on? If they do want to detect it, what do they want to know? How critical is it? - if it is critical to know about, then something that can be queried in a standard manner is useful in the mib. The specific state may be useful. - if the ISPs don't use it, we'll pull the feature. - if it is important, but they don't want to have a state to manage it then we can recombine the states. When the IESG calls (protocol monitors that they are), we can point to the market request on this issue. anyone who can ask ISPs to query this? 4) comparing all your input --- still processing I am plugging through the 2 versions of state machine you sent. Did you send me a review of the diagram (word document) I'm attaching again. I didn't find that even though you mentioned you had done it. Did I miss it? That would speed up this process since a 5 page form is quicker to review and glance over. Sue At 09:14 AM 1/17/2002 -0800, you wrote: >Sue, > > To clarify my position: I think that recommendation for an > exponential back-off is a good thing and solves a real > problem. However, I think that the IdleHold state should not > be in the FSM because: > > 1) It seems to be redundant. See (*) below. > 2) It introduces changes to the base FSM to account for > a feature of an optional nature. People who didn't > implement it would be put in a non-compliant position, > people who won't implement it will have to take things > out of the FSM. > 3) I am under impression (though I might be wrong) that > it does not match the majority of deployed implementations > that do not have this state and hence would ago against the > objective of this spec review round. > --- > *) When it comes to FSMs, one almost always can achieve the same > results by either using an existing state with flags or by adding > another state. It is often hard to decide which approach to follow. > One simple test I find useful is to see how different periodic > activities, packet and event processing are for the two states. > If there is a considerable difference, separate states are most > probably a good idea. In our case, the two states are practically > the same---we don't do anything on a periodic basis (no messages, > no outbound connections), we do not accept incoming connections, > we ignore all events but Start. The difference is essentially in > the reason we get to either state, which affects the name of > the state and when the Start event is generated. IMHO it does not > justify a new state, but that's my personal opinion :) I think > the original text from -12 (maybe revised a bit) should be good > enough... > >-- >Alex Zinin > >Thursday, January 17, 2002, 5:51:35 AM, Susan Hares wrote: > > > > Alex and Randy: > > > Let's go back to first principles here on the FSM? > > > 1st) The original text is below from draft-12. > > > This explanation gives "flag" that has implications > > for the full state machine. The definition of > > state machines that Alex proposes, is all inputs > > and all actions are determined by state machine in > > clear text. > > > 2nd) Is the bug real? > > > The text was fixing a " persistent bgp flapping" > > bug. According to the text there is a > > state within a state with fairly vague > > descriptions. > > > The second question belongs to Randy, since he wears 2 hats (Operations > > and Routing temp AD), was this a real problem? Has it gone away? > > > 1) At least one routing vendor doesn't implement it [cisco] > > and I know this vendor is utilized in BGP peering sessions > > in the network. > > > 2) What was the operational concern this text implies? > > > If there is no operational issue and no operational usage, > > return to the original FSM text and out the comments on > > "hold down." > > > So, Randy and all other operators - Is the problem it describes real? > > Does anyone need it? Let's answer that question first. > > > > > > Sue Hares > > > ---------------------- > > > > If a BGP speaker detects an error, it shuts down the connection > > and changes its state to Idle. Getting out of the Idle state > > requires generation of the Start event. If such an event is > > generated automatically, then persistent BGP errors may result > > in persistent flapping of the speaker. To avoid such a > > condition it is recommended that Start events should not be > > generated immediately for a peer that was previously > > transitioned to Idle due to an error. For a peer that was > > previously transitioned to Idle due to an error, the time > > > > > Expiration Date July 2001 [Page 31] > > > > > > > RFC DRAFT January 2001 > > > > between consecutive generation of Start events, if such events > > are generated automatically, shall exponentially increase. The > > value of the initial timer shall be 60 seconds. The time shall > > be doubled for each consecutive retry. > > > Any other event received in the Idle state is ignored. > > > > > At 11:10 AM 1/16/2002 -0800, you wrote: > > >>Sue, > >> > >> Introduction of the IdleHold does change the FSM, > >> and I thought we wanted the spec to reflect the current > >> running code as much as possible. > >> > >> I agree with Russ and Ishi---the new state does not > >> seem to be necessary, instead it could be as easy > >> as holding the session in Idle and giving clue on > >> how to make the delay exponential. I don't think > >> there's an interoperability issue if people decide > >> to keep the session in Idle using different internal > >> mechanisms. > >> > >> Regards, > >> > >>-- > >>Alex Zinin > >> > >>Wednesday, January 16, 2002, 6:04:36 AM, Susan Hares wrote: > >> > >> > Kunihiro: > >> > >> > We are not changing the FSM so I would be surprised if the change > >> > was anything but modest. Usually specifications with "no big" deal get > >> > interpreted differently. Inter-operable code means you tie down the > >> details. > >> > >> > The comment was on the clarity of the specification. > >> > >> > If you have a specific comment on the text of the state machine, > >> > can you propose the concerns you have as a revision to the text. > >> > >> > Sue > >> > >> > PS -- I just love last call on a draft... It's when > >> > everyone finally reads a new section ;-)... > >> > >> > >> > At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote: > >> >> >> > Is the expoential backoff in the FSM in current implementations? > >> >> >> > >> >> >> I guess we are going to find this out as part of the implementation > >> >> >> report. And if it is not in (at least two) current implementations, > >> >> >> we'll take it out of the text. > >> >> > > >> >> >I implemented Cease subcode in zebra-0.92a but not exponential > backoff. > >> >> >I checked that new subcode does not put other BGP stack in trouble > >> >> >(checked Cisco and Juniper). > >> >> > >> >>First of all, sorry for talking about specific implementation. In > >> >>Zebra implementation we've implemented Cease subcode. The code is in > >> >>CVS repository. I'll prepare a release version for that. > >> >> > >> >>And also we've implemented exponetial backoff. It is done without > >> >>introducing new FSM status. It is not a big deal. Just check a flag > >> >>in a few functions. > >> > >> > >> >>Exponential backoff is a good feature. I can't understand why it > >> >>require change to FSM. --=====================_37894649==_ Content-Type: application/msword; name="statemt.doc"; x-mac-type="42494E41"; x-mac-creator="4D535744" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="statemt.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAgAAAAAAAAAAA EAAAggAAAAEAAAD+////AAAAAH4AAAB/AAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAWyAJBAAA8BK/AAAAAAAAEAAAAAAABAAAVhwAAA4AYmpiauIA4gAAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIo4AAIBqAQCAagEAVhgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAN4AAAAAAAAA3gAAAN4A AAAAAAAA3gAAAAAAAADeAAAAAAAAAN4AAAAAAAAA3gAAABQAAAAAAAAAAAAAAPIAAAAAAAAA3ikA AAAAAADeKQAAAAAAAN4pAAAAAAAA3ikAAAwAAADqKQAArAEAAPIAAAAAAAAAl0cAADIBAACiKwAA AAAAAKIrAAAAAAAAoisAAAAAAACiKwAAAAAAAKIrAAAAAAAAoisAAAAAAACiKwAAAAAAAKIrAAAA AAAAFkcAAAIAAAAYRwAAAAAAABhHAAAAAAAAGEcAAAAAAAAYRwAAAAAAABhHAAAAAAAAGEcAACQA AADJSAAAIAIAAOlKAABYAAAAPEcAABUAAAAAAAAAAAAAAAAAAAAAAAAA3gAAAAAAAACiKwAAAAAA AAAAAAAAAAAAAAAAAAAAAACiKwAAAAAAAKIrAAAAAAAAoisAAAAAAACiKwAAAAAAADxHAAAAAAAA 3DAAAAAAAADeAAAAAAAAAN4AAAAAAAAAoisAAAAAAAAAAAAAAAAAAKIrAAAAAAAAUUcAABYAAADc MAAAAAAAANwwAAAAAAAA3DAAAAAAAACiKwAAEgEAAN4AAAAAAAAAoisAAAAAAADeAAAAAAAAAKIr AAAAAAAAFkcAAAAAAAAAAAAAAAAAANwwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAoisAAAAAAAAWRwAAAAAAANwwAAAWBwAA3DAAAAAAAADyNwAA VgAAAK4+AABAAAAA3gAAAAAAAADeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcj8AAAAAAACiKwAAAAAAAJYrAAAMAAAAIHP9ln+f wQHyAAAA7CgAAN4pAAAAAAAAtCwAAD4CAADuPgAADAAAAAAAAAAAAAAAcj8AAKQHAABnRwAAMAAA AJdHAAAAAAAA+j4AAHgAAABBSwAAAAAAAPIuAADqAQAAQUsAAAAAAAByPwAAAAAAANwwAAAAAAAA 8gAAAAAAAADyAAAAAAAAAN4AAAAAAAAA3gAAAAAAAADeAAAAAAAAAN4AAAAAAAAAAgDZAAAAQkdQ IFN0YXRlIG1hY2hpbmUgaW4gdGFibGUgZm9ybWF0Og0NVGhlIHRhYmxlIGJlbG93IGhhcyBFdmVu dHMgYnkgU3RhdGVzLiAgSW4gZWFjaCBlbnRyeSBvZiB0aGUgdGFibGUsIHRoZSBmaXJzdCBlbnRy eSBpbiB0aGUgYm94IGlzIHRoZSBuZXcgc3RhdGUuICBUaGUgc2Vjb25kIGVudHJ5IGlzIHRoZSBz ZXQgb2YgYWN0aW9ucy4gICBFYWNoIGFjdGlvbiBpcyBlaXRoZXIgc3BlY2lmaWVkIChzdWNoIGFz IElnbm9yZSkgb3IgaXQgZ2l2ZW4gYSBMZXR0ZXIgKHN1Y2ggYXMgQikgd2hpY2ggaXMgZGVzY3Jp YmVkIGF0IHRoZSBlbmQgb2YgdGhlIHRhYmxlLg0NRm9yIGV4YW1wbGUsICBJZiBhbiBBdXRvbWF0 aWMgc3RhcnQgZXZlbnQgb2NjdXJzIGluIHRoZSBJZGxlIHN0YXRlLCB0aGUgbG9jYWwgc3lzdGVt IHBlcmZvcm1zIHRoZSBhY3Rpb25zIGxpc3RlZCB1bmRlciCTQZQgYW5kIGdvZXMgdG8gdGhlIENv bm5lY3Qgc3RhdGUuICAgVGhlIGFjdGlvbnMgdW5kZXIgdGhlIGxldHRlciBBIGFyZTogDQ1BY3Rp b24gQQ1pbml0aWFsaXplIGFsbCBCR1AgcmVzb3VyY2VzDXN0YXJ0IENvbm5lY3QgcmV0cnkgdGlt ZXINaW5pdGlhdGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gdG8gQkdQIHBlZXINbGlzdGVuIGZvciBj b25uZWN0aW9uIHNldC11cCBieSByZW1vdGUgQkdQIHBlZXINDQ0NB1N0YXRlIChOZXcgc3RhdGUv YWN0aW9uKQcHRXZlbnQHSWRsZSBIb2xkB0lkbGUHQ29ubmVjdAdPcGVuIHNlbnQHQWN0aXZlB09w ZW4gDUNvbmZpcm0HRXN0YWJsaXNoZWQHBzEHTWFudWFsDVN0YXJ0B0Nvbm5lY3QgLyBCB0Nvbm5l Y3QNL0IHQ29ubmVjdC8NSWdub3JlB09wZW4NU2VudC8NSWdub3JlB0FjdGl2ZS8NSWdub3JlB09w ZW4gDUNvbmZpcm0vDUlnbm9yZQdFc3RhYmxpc2hlZC8NSWdub3JlBwcyB0F1dG8gDVN0YXJ0B0lk bGUgSG9sZC8NSWdub3JlB0Nvbm5lY3QvIEEHQ29ubmVjdC8NSWdub3JlB09wZW4NU2VudC8NSWdu b3JlB0FjdGl2ZS8NSWdub3JlB09wZW4NQ29uZmlybS8NSWdub3JlB0VzdGFibGlzaGVkLw1JZ25v cmUHBzMHSWRsZSANW0hvbGQgdGltZXINRXhwaXJlZCBhbmQgdmFsdWUgdW5kZXIgY2VpbGluZwdJ ZGxlLw1BB0lkbGUvDUZTTSBlcnJvcgdJZGxlIEhvbGQvDUQgB0lkbGUgSG9sZCAvIEUgDShGU00g ZXJyb3IpB0lkbGUgSG9sZCAvDUQgIChGU00gZXJyb3IpDQdJZGxlIEhvbGQgLyBFIA0oRlNNIGVy cm9yKQdJZGxlIEhvbGQgLw1FIA0oRlNNIGVycm9yKQcHNAdJZGxlIEhvbGQgdGltZXIgJiB0aW1l ciBvdmVyIGNlaWxpbmcHSWRsZSBIb2xkIC8NSWdub3JlB0lkbGUgLw1JZ25vcmUHSWRsZSBIb2xk IC8gRCAHSWRsZSBIb2xkIC8gRSANKEZTTSBlcnJvcikHSWRsZSBIb2xkIC8gDUQgDShGU00gZXJy b3IpB0lkbGUgSG9sZCAvDUUgDShGU00gZXJyb3IpB0lkbGUgSG9sZCAvDUUgDShGU00gZXJyb3Ip Bwc1B1RDUA1Db25uZWN0IA1zdWNjZWVkcw0oc2VudCBUQ1ApB0lkbGUgSG9sZC8NSWdub3JlB0lk bGUvDUlnbm9yZQdPcGVuIHNlbnQgLyBGIAdJZGxlIEhvbGQvIEUgKEZTTSBlcnJvcikHT3BlbiBz ZW50IC8gDUYHSWRsZSBIb2xkIC8gRSAgKEZTTSBlcnJvcikgDQdJZGxlIEhvbGQgLw0gRSAoRlNN IEVycm9yKQ0HBzYHVENQIGNvbm5lY3QgZmFpbGVkB0lkbGUgSG9sZC8NSWdub3JlB0lkbGUvDUln bm9yZQdBY3RpdmUgLw1HDQdJZGxlIEhvbGQgLyBFIA0oRlNNIGVycm9yKQdJZGxlIGhvbGQNIC8g RA0HSWRsZSBIb2xkIC8gRQ0oRlNNIGVycm9yKQdJZGxlIEhvbGQgLyAgRSAoRlNNIGVycm9yKQcH NwdUQ1AgZGlzIJZjb25uZWN0B0lkbGUgSG9sZC8NSWdub3JlB0lkbGUvIElnbm9yZQdJZGxlIEhv bGQgLyBEIAdBY3RpdmUgLyBPIGFjdGlvbnMHSWRsZSBIb2xkIA0vIEQHSWRsZSBIb2xkIC8gDUQH SWRsZSBIb2xkIC8gRAcHOAdDb25uZWN0DVJldHJ5IHRpbWVyIGV4cGlyZXMHSWRsZSBIb2xkDS8g SWdub3JlB0lkbGUvIElnbm9yZQdDb25uZWN0IC8gSCAHSWRsZSBIb2xkICAvIEUNKEZTTSBlcnJv cikHQ29ubmVjdCAvIEgHSWRsZSBIb2xkIC8gRSAoRlNNIGVycm9yKQdJZGxlIEhvbGQgLyBFIChG U00gZXJyb3IpBwc5B1JjdiBUQ1AgQ29ubmVjdCAmIHVuY29uZmlndXJlZA1QZWVycyBPSwdJZGxl IEhvbGQvDUlnbm9yZQdJZGxlIC8NSWdub3JlB0lkbGUgSG9sZCAvICBEIAdJZGxlIEhvbGQgLyBF IA0oRlNNIEVycm9yKQdPcGVuIFNlbnQgLw1LB0lkbGUgSG9sZCAvIEUgKEZTTSBlcnJvcikHSWRs ZSBIb2xkIC8gRA0HBzEwB1JjdiBUQ1AgY29ubmVjdA0mIHVuY29uZmlnDXBlZXJzIG5vdCANT0sH SWRsZSBob2xkLw1JZ25vcmUNB0lkbGUgLw1JZ25vcmUHSWRsZSBIb2xkIC8gRCAHSWRsZSBIb2xk IC8gRQdBY3RpdmUgLyBMIAdJZGxlIEhvbGQgLyBFIChGU00gZXJyb3IpB0lkbGUgSG9sZCAvIEQN BwcxMQdIb2xkIFRpbWVyIGV4cGlyZXMHSWRsZSBIb2xkLyANSWdub3JlB0lkbGUgLw1JZ25vcmUH SWRsZSBIb2xkLw1EB0lkbGUgSG9sZA0vIE0gKEhvbGQgdGltZXIgZXhwaXJlZCkNB0lkbGUgSG9s ZCAvIA1EDSAoRlNNIGVycm9yKQdJZGxlIEhvbGQgLyAgTSAoaG9sZCB0aW1lciBleHBpcmVkKQdJ ZGxlIEhvbGQgLyANUiAgKGhvbGQgdGltZXIgZXhwaXJlZCkgDQcHMTIHT3BlbiByZWN2IHdpdGgg Z29vZCBmb3JtYXQgYW5kIGhlYWRlcgdJZGxlIEhvbGQgLw1JZ25vcmUHSWRsZSBIb2xkIC8gDUln bm9yZQdJZGxlIEhvbGQgLyAgRCAoRlNNIGVycm9yKQdJZGxlIEhvbGQgLyAgTgdJZGxlIEhvbGQg LyANRCANKGZzbSBlcnJvcikHSWRsZSBIb2xkIA0vIEUNKEZTTSBlcnJvcikHSWRsZSBIb2xkIC8g DUUgDShGU00gRXJyb3IpBwcxMwdIZWFkZXIgZXJyb3IHSWRsZSBIb2xkLw1JZ25vcmUHSWRsZSAv IElnbm9yZQdJZGxlIEhvbGQgLyBEIAdJZGxlIEhvbGQgLyBJB0lkbGUgSG9sZCAvIA1EIA0oRlNN IGVycm9yKQdJZGxlIEhvbGQgLyBFDShGU00gRXJyb3IpB0lkbGUgb2xkIC8gRQ0NKEZTTSBFcnJv cikHBzE0B09wZW4gbXNnIGVycm9yB0lkbGUgSG9sZC8gSWdub3JlB0lkbGUgLyBJZ25vcmUHSWRs ZSBIb2xkIC8gRAdJZGxlIEhvbGQgLyBKB0lkbGUgSG9sZCAvIA1EDShGU00gZXJyb3IpB0lkbGUg SG9sZCAvIEUNKEZTTSBFcnJvcikHSWRsZSBIb2xkIC8gIEUgKEZTTSBlcnJvcikHBzE1B05vdGlm aWNhdGlvbiB3aXRoIHZlcnNpb24gZXJyb3IHSWRsZSBIb2xkLw1JZ25vcmUHSWRsZS8gSWdub3Jl DQdJZGxlIEhvbGQgLyBEB0lkbGUgLyBDB0lkbGUgSG9sZC8gRA0oRlNNIGVycm9yKQdJZGxlIEhv bGQgLw1EB0lkbGUgSG9sZCAvIA1EBwcxNgdPcGVuIGNvbGxpc2lvbiBkZXRlY3RlZCAmIGR1bXAg dGhpcyBzZXNzaW9uB0lkbGUgSG9sZC8NSWdub3JlB0lkbGUgLyBJZ25vcmUHSWRsZSBIb2xkICAv IEQgIAdJZGxlIGhvbGQgLyBTB0lkbGUgSG9sZCAvIA1EDShGU00gZXJyb3IpB0lkbGUgSG9sZCAv ICBFIChGU00gRXJyb3IpB0lkbGUgSG9sZCAvDUUgKEZTTSBFcnJvcikHBzE3B0tlZXAtDWFsaXZl DVRpbWVyIGV4cGlyZXMHSWRsZSBIb2xkLw1JZ25vcmUHSWRsZSAvIElnbm9yZQdJZGxlIEhvbGQg LyBEIA0oRlNNIEVycm9yKSAHSWRsZSBIb2xkIC8gRQ0oRlNNIGVycm9yKQdJZGxlIEhvbGQgLyBE DShGU00gZXJyb3IpDQdPcGVuIENvbmZpcm0vIFEHRXN0YWJsaXNoZWQvIA1RBwcxOAdLZWVwLWFs aXZlIG1lc3NhZ2UgB0lkbGUgSG9sZC8gSWdub3JlB0lkbGUgLyBJZ25vcmUHSWRsZSBIb2xkIC8g IEQHSWRsZSBIb2xkIC8gRSAoRlNNIGVycm9yKQdJZGxlIEhvbGQgLyANRCAHRXN0YWJsaXNoZWQN UAdFc3RhYmxpc2hlZC8gDVAHBzE5B1VwZGF0ZSBtZXNzYWdlB0lkbGUgSG9sZCAvIElnbm9yZQdJ ZGxlIC8gDUlnbm9yZQdJZGxlIEhvbGQgLyBEB0lkbGUgSG9sZCAvRSAoRlNNIGVycm9yKQdJZGxl IEhvbGQgLyBEB0lkbGUgSG9sZCAvIEUgKEZTTSBlcnJvcikHRXN0YWJsaXNoZWQgLyBQcm9jZXNz IFVwZGF0ZQcHMjAHIE5vdGlmaS1jYXRpb24NUmVjZWl2ZWQHSWRsZSBIb2xkLw1JZ25vcmUHSWRs ZSAvDUlnbm9yZQdJZGxlIEhvbGQgLyBEB0lkbGUgSG9sZCAvIEQgDQdJZGxlIEhvbGQgLyBEB0lk bGUgSG9sZCAvIA1EB0lkbGUgSG9sZCAvIGQHBzIxB1VwZGF0ZSBtZXNzYWdlIGVycm9yB0lkbGUg SG9sZC8gSWdub3JlB0lkbGUvIElnbm9yZQdJZGxlIEhvbGQgLyBEB0lkbGUgSG9sZCAvIEUHSWRs ZSBIb2xkIC8gRAdJZGxlIEhvbGQgLyBFB0lkbGUgSG9sZCAvDVUHBzIyB01hbnVhbCBzdG9wB0lk bGUgLw1DB0lkbGUvDUMHSWRsZS8NQwdJZGxlLw1DB0lkbGUgLyANQwdJZGxlIC8gYwdJZGxlIC8g YwcHMjMHQXV0byBzdG9wB0lkbGUgSG9sZC8NSWdub3JlB0lkbGUgSG9sZC8NB0lkbGUgSG9sZC8N RAdJZGxlIEhvbGQgLyAgUwdJZGxlIEhvbGQgLyBEB0lkbGUgSG9sZCAvIFMHSWRsZSBIb2xkIC8g Uw0HBw0MDUFjdGlvbnMNDUFjdGlvbiBBDWluaXRpYWxpemUgYWxsIEJHUCByZXNvdXJjZXMNc3Rh cnQgQ29ubmVjdCByZXRyeSB0aW1lcg1pbml0aWF0ZSB0cmFuc3BvcnQgY29ubmVjdGlvbiB0byBC R1AgcGVlcg1saXN0ZW4gZm9yIGNvbm5lY3Rpb24gc2V0LXVwIGJ5IHJlbW90ZSBCR1AgcGVlcg0N QWN0aW9uIEINQ29ubmVjdFJldHJ5Q250IHNldCB0byAwDUFjdGlvbiBBDUFjdGlvbiBDDXJlbGVh c2UgYWxsIEJHUCByZXNvdXJjZXMNQ29ubmVjdFJldHJ5Q250IHNldCB0byAwDWNvbm5lY3QgcmV0 cnkgdGltZXIgPSAwIA1BY3Rpb24gIEQNSURMRSBob2xkIHRpbWUgPSAyKiooY29ubmVjdFJldHJ5 Q250KSo2MA1Db25uZWN0UmV0cnlDbnQgPSsxDWNvbm5lY3QgcmV0cnkgdGltZXIgPSAwDURlbGV0 ZSBCR1AgcmVzb3VyY2VzDURyb3AgVENQIGNvbm5lY3Rpb24NQWN0aW9uIEUNU2VuZCBOb3RpZmlj YXRpb24gKEZTTSBFcnJvcikNQWN0aW9uIEQNQWN0aW9uIEYNY2xlYXIgQ29ubmVjdFJldHJ5IHRp bWVyDWNvbXBsZXRlIEJHUCBpbml0aWFsaXphdGlvbg1zZW5kIE9wZW4gbWVzc2FnZQ1Ib2xkIHRp bWVyID0gTGFyZ2UgdmFsdWUgKDQgbWludXRlcw1BY3Rpb24gRw1yZXN0YXJ0IENvbm5lY3RSZXRy eSB0aW1lcg1saXN0ZW4gZm9yIEJHUCBwZWVyIGNvbm5lY3Rpb24NQWN0aW9uIEgNcmVzdGFydCBD b25uZWN0UmV0cnkgdGltZXINc3RhcnQgVENQIGNvbm5lY3Rpb24NbGlzdGVuIGZvciBUQ1AgY29u bmVjdGlvbg1BY3Rpb24gSQ1TZW5kIE5vdGlmaWNhdGlvbiB3aXRoIEJHUCBIZWFkZXIgRXJyb3IN QWN0aW9uIEQNQWN0aW9uICBKDVNlbmQgTm90aWZpY2F0aW9uIHdpdGggT3BlbiBtZXNzYWdlIGVy cm9yDUFjdGlvbiBEDUFjdGlvbiBLDUlQIGFkZHJlc3MgdW5jb25maWd1cmVkIHR1cm5zIGludG8g dGVtcG9yYXJ5IHBlZXIgZW50cnkNQWN0aW9uIEYNQWN0aW9uIEwNcmVqZWN0IFRDUCBjb25uZWN0 aW9uDUFjdGlvbiBNDVNlbmQgTm90aWZpY2F0aW9uIHdpdGggSG9sZCBUaW1lciBFeHBpcmVkDUFj dGlvbiBEDUFjdGlvbiBODVNlbmQgS0VFUEFMSVZFIG1lc3NhZ2UNSWYgbmVnb3RpYXRlZCBIb2xk IHRpbWUgdmFsdWUgaXMgbm9uLCB6ZXJvIA1zZXQgS2VlcGFsaXZlIHRpbWVyDUhvbGQgdGltZXIg cmVzZXQgdG8gbmVnb3RpYXRlZCBIb2xkIHRpbWUgdmFsdWUgKHNlY3Rpb24gNC4yKQ1pZiBuZWdv dGlhdGVkIEhvbGQgdGltZSB2YWx1ZSBpcyB6ZXJvLA1yZXNldCBLZWVwYWxpdmUgdGltZXINcmVz ZXQgSG9sZCB0aW1lcg1JZiB2YWx1ZSBvZiBBdXRvbm9tb3VzIFN5c3RlbSBmaWVsZCBpcyB0aGUg c2FtZSBhcyB0aGUgbG9jYWwgQXV0b25vbW91cyBzeXN0ZW0gbnVtYmVyLCBzZXQgdGhlIGNvbm5l Y3Rpb24gaXMgYW4gaW50ZXJuYWwgY29ubmVjdGlvbjsgb3RoZXJ3aXNlIGl0IGlzIJNlbnRlcm5h bJQuICAoVGhpcyBpbXBhY3RzIFVwZGF0ZSBwcm9jZXNzaW5nKQ1BY3Rpb24gTw1DbG9zZSBCR1Ag Y29ubmVjdGlvbg1yZXN0YXJ0IENvbm5lY3RSZXRyeSBUaW1lcg1jb250aW51ZSBsaXN0ZW5pbmcg Zm9yIEJHUCBjb25uZWN0aW9uDUFjdGlvbiBQDVJlc3RhcnQgSG9sZCB0aW1lcg1BY3Rpb24gUQ1T ZW5kIEtlZXBhbGl2ZSBtZXNzYWdlDXJlc3RhcnQgS0VFUEFMSVZFIHRpbWVyDUFjdGlvbiBSDVNl bmQgbm90aWZpY2F0aW9uIHdpdGggSG9sZCB0aW1lciBleHBpcmVkDUFjdGlvbiBUDUFjdGlvbiBT DVNlbmQgTm90aWZpY2F0aW9uIHdpdGggQ2Vhc2UNQWN0aW9uIFQNQWN0aW9uIFQNQWN0aW9uIEQN RGVsZXRlIHJvdXRlcw1BY3Rpb24gVQ1TZW5kIG5vdGlmaWNhdGlvbiB3aXRoIFVwZGF0ZSBlcnJv ciANQWN0aW9uIFQNDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAABgAAmgYAAJ0GAAC3 BgAAuAYAAAAHAAABBwAAPA8AAEoPAADbDwAA6A8AAFYcAAAA/QD9AP0A/fT99P0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAEDUIgTYIgUNKFABcCIFdCIEABENKFAAMAAQAACMEAAAkBAAAPQUAAD4F AAD/BQAAAAYAAAkGAAAmBgAAQAYAAGoGAACaBgAAmwYAAJwGAACdBgAAngYAALcGAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAA AAAAAAAAAAAA8wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BgAAFiQBSWYBAAAABQAACiYBC0YDAAUAAAomAAtGAwAAAQAAABAABAAAVhwAAP0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAAEBAbcGAAC4BgAAvgYAAMgGAADNBgAA 1QYAAN8GAADmBgAA7AYAAPQGAAAABwAAkiQBAAAAAAAAAAAAAIwAAAAAAAAAAAAAAACMAAAAAAAA AAAAAAAAjAAAAAAAAAAAAAAAAIwAAAAAAAAAAAAAAACMAAAAAAAAAAAAAAAAjAAAAAAAAAAAAAAA AIwAAAAAAAAAAAAAAACMAAAAAAAAAAAAAAAAjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAAbAAAFiQBFyQBSWYB AAAAApZsAAM0AQQ0AQXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWMAAClP9UBiwiAAbABgAA AAAAAAAAAAAAAAAAAAAABtgbAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/ BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzW CAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQoDbABh9gMAAAAKAAcAAAEHAAADBwAAIAgCAAAAAAAA AAAAABoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAADeAAAWJAEXJAFJZgEA AAAClmwAAzQBBDQBBdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNa0AAiU/1QGUwqmDZ8ROxWd GOUcLCIABsAGAAAAAAAAAAAAAAAAAAAAAAAG/wMAAAAAAAAAAAAAAAAAAAAAAAZTAwAAAAAAAAAA AAAAAAAAAAAABvkDAAAAAAAAAAAAAAAAAAAAAAAGnAMAAAAAAAAAAAAAAAAAAAAAAAZiAwAAAAAA AAAAAAAAAAAAAAAABkgEAAAAAAAAAAAAAAAAAAAAAAAGRwUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1iAAAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvWIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/HNYgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d1iAAAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2AwAAAAIDBwAACgcAABAHAAAcBwAAJAcAACcH AAAwBwAANwcAADwHAABCBwAASQcAAFEHAABYBwAAXgcAAGcHAABuBwAAewcAAIIHAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAAEYIHAACDBwAAEBgCAAAAAAAAAAAAAAAA AAAAAAAAAAAAAO4AABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI 1soACZT/aAFUBlMKpg2fETsVnRjlHCwiAAbUAQAAAAAAAAAAAAAAAAAAAAAABuwEAAAAAAAAAAAA AAAAAAAAAAAG/wMAAAAAAAAAAAAAAAAAAAAAAAZTAwAAAAAAAAAAAAAAAAAAAAAABvkDAAAAAAAA AAAAAAAAAAAAAAAGnAMAAAAAAAAAAAAAAAAAAAAAAAZiAwAAAAAAAAAAAAAAAAAAAAAABkgEAAAA AAAAAAAAAAAAAAAAAAAGRwUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8b1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1iQA AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d1iQAAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP801gYAAQoDbABh9gMAAAABgwcAAIUHAACLBwAAkQcAAJwHAACjBwAA rgcAALcHAAC+BwAAwwcAAMkHAADQBwAA2AcAAN8HAADkBwAA7QcAAPQHAAABCAAACAgAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAABIICAAACQgAABAgAwAAAAAAAAAAAAAAAAAA AAAAAAAAAADuAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNbK AAmU/2gBVAZTCqYNnxE7FZ0Y5RwsIgAG1AEAAAAAAAAAAAAAAAAAAAAAAAbsBAAAAAAAAAAAAAAA AAAAAAAABv8DAAAAAAAAAAAAAAAAAAAAAAAGUwMAAAAAAAAAAAAAAAAAAAAAAAb5AwAAAAAAAAAA AAAAAAAAAAAABpwDAAAAAAAAAAAAAAAAAAAAAAAGYgMAAAAAAAAAAAAAAAAAAAAAAAZIBAAAAAAA AAAAAAAAAAAAAAAABkcFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/G9YkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HNYkAAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYkAAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAAAQkIAAALCAAAEQgAAB0IAAA9CAAAQwgAAEUI AABLCAAAVQgAAGAIAABjCAAAcggAAH4IAACKCAAAmQgAAJoIAACpCAAAtQgAAMEIAADECAAA0AgA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAAU0AgAANEIAAAQFAMAAAAAAAAAAAAAAAAAAAAA AAAAAAAA7gAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWygAJ lP9oAVQGUwqmDZ8ROxWdGOUcLCIABtQBAAAAAAAAAAAAAAAAAAAAAAAG7AQAAAAAAAAAAAAAAAAA AAAAAAb/AwAAAAAAAAAAAAAAAAAAAAAABlMDAAAAAAAAAAAAAAAAAAAAAAAG+QMAAAAAAAAAAAAA AAAAAAAAAAacAwAAAAAAAAAAAAAAAAAAAAAABmIDAAAAAAAAAAAAAAAAAAAAAAAGSAQAAAAAAAAA AAAAAAAAAAAAAAZHBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/xvWJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xzWJAAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3WJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2AwAAAAHRCAAA0wgAAPgIAAAECQAACwkAABIJAAAZCQAA KAkAADcJAABDCQAAUAkAAFMJAABfCQAAawkAAG4JAAB6CQAAhgkAAIkJAACVCQAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAAEpUJAACWCQAAEMwCAAAAAAAAAAAAAAAAAAAAAAAA AAAAAO4AABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1soACZT/ aAFUBlMKpg2fETsVnRjlHCwiAAbUAQAAAAAAAAAAAAAAAAAAAAAABuwEAAAAAAAAAAAAAAAAAAAA AAAG/wMAAAAAAAAAAAAAAAAAAAAAAAZTAwAAAAAAAAAAAAAAAAAAAAAABvkDAAAAAAAAAAAAAAAA AAAAAAAGnAMAAAAAAAAAAAAAAAAAAAAAAAZiAwAAAAAAAAAAAAAAAAAAAAAABkgEAAAAAAAAAAAA AAAAAAAAAAAGRwUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8b1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1iQAAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP801gYAAQoDbABh9gMAAAABlgkAAJgJAACcCQAApQkAAK4JAAC5CQAAxAkAAMsJ AADRCQAA2AkAAOcJAAAACgAADQoAAA8KAAArCgAALAoAADgKAABHCgAASAoAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAABJICgAASQoAABCEAgAAAAAAAAAAAAAAAAAAAAAAAAAA AADuAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNbKAAmU/2gB VAZTCqYNnxE7FZ0Y5RwsIgAG1AEAAAAAAAAAAAAAAAAAAAAAAAbsBAAAAAAAAAAAAAAAAAAAAAAA Bv8DAAAAAAAAAAAAAAAAAAAAAAAGUwMAAAAAAAAAAAAAAAAAAAAAAAb5AwAAAAAAAAAAAAAAAAAA AAAABpwDAAAAAAAAAAAAAAAAAAAAAAAGYgMAAAAAAAAAAAAAAAAAAAAAAAZIBAAAAAAAAAAAAAAA AAAAAAAABkcFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/G9YkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HNYkAAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAAAUkKAABLCgAAXgoAAGkKAABwCgAAdgoAAH0KAACGCgAA iAoAAIkKAACYCgAApAoAAK4KAACzCgAAtAoAAMIKAADOCgAA6QoAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAYAABYkAUlmAQAAAAAR6QoAAOoKAAAQBAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 7gAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWygAJlP9oAVQG UwqmDZ8ROxWdGOUcLCIABtQBAAAAAAAAAAAAAAAAAAAAAAAG7AQAAAAAAAAAAAAAAAAAAAAAAAb/ AwAAAAAAAAAAAAAAAAAAAAAABlMDAAAAAAAAAAAAAAAAAAAAAAAG+QMAAAAAAAAAAAAAAAAAAAAA AAacAwAAAAAAAAAAAAAAAAAAAAAABmIDAAAAAAAAAAAAAAAAAAAAAAAGSAQAAAAAAAAAAAAAAAAA AAAAAAZHBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/xvWJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xzWJAAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3WJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/zTWBgABCgNsAGH2AwAAAAHqCgAA7AoAAP0KAAAICwAADwsAABwLAAArCwAAPgsAAEkL AABNCwAAWgsAAFwLAABqCwAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAGAAAWJAFJZgEAAAAADGoLAABrCwAAEJwCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO4A ABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1soACZT/aAFUBlMK pg2fETsVnRjlHCwiAAbUAQAAAAAAAAAAAAAAAAAAAAAABuwEAAAAAAAAAAAAAAAAAAAAAAAG/wMA AAAAAAAAAAAAAAAAAAAAAAZTAwAAAAAAAAAAAAAAAAAAAAAABvkDAAAAAAAAAAAAAAAAAAAAAAAG nAMAAAAAAAAAAAAAAAAAAAAAAAZiAwAAAAAAAAAAAAAAAAAAAAAABkgEAAAAAAAAAAAAAAAAAAAA AAAGRwUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAFPYBAAAa1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8b1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1iQAAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP801gYAAQoDbABh9gMAAAABawsAAG0LAAB1CwAAiQsAAJMLAACcCwAAqQsAALYLAADFCwAA 0QsAAN0LAAD3CwAAEQwAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAABgAAFiQBSWYBAAAAAAwRDAAAEgwAABC0AgAAAAAAAAAAAAAAAAAAAAAAAAAAAADuAAAW JAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNbKAAmU/2gBVAZTCqYN nxE7FZ0Y5RwsIgAG1AEAAAAAAAAAAAAAAAAAAAAAAAbsBAAAAAAAAAAAAAAAAAAAAAAABv8DAAAA AAAAAAAAAAAAAAAAAAAGUwMAAAAAAAAAAAAAAAAAAAAAAAb5AwAAAAAAAAAAAAAAAAAAAAAABpwD AAAAAAAAAAAAAAAAAAAAAAAGYgMAAAAAAAAAAAAAAAAAAAAAAAZIBAAAAAAAAAAAAAAAAAAAAAAA BkcFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAABT2AQAAGtYkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ G9YkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HNYkAAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/NNYGAAEKA2wAYfYDAAAAARIMAAAUDAAAMwwAADwMAABHDAAATgwAAFUMAABcDAAAbAwAAHsM AACHDAAAkwwAAJUMAACvDAAAvQwAAL4MAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAYAABYkAUlmAQAAAAAPvgwAAL8MAAAQgAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7gAAFiQB FyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWygAJlP9oAVQGUwqmDZ8R OxWdGOUcLCIABtQBAAAAAAAAAAAAAAAAAAAAAAAG7AQAAAAAAAAAAAAAAAAAAAAAAAb/AwAAAAAA AAAAAAAAAAAAAAAABlMDAAAAAAAAAAAAAAAAAAAAAAAG+QMAAAAAAAAAAAAAAAAAAAAAAAacAwAA AAAAAAAAAAAAAAAAAAAABmIDAAAAAAAAAAAAAAAAAAAAAAAGSAQAAAAAAAAAAAAAAAAAAAAAAAZH BQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAU9gEAABrWJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvW JAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xzWJAAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/x3WJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /zTWBgABCgNsAGH2AwAAAAG/DAAAwgwAANIMAADdDAAA6AwAAOsMAAD2DAAA/QwAAP4MAAAFDQAA DA0AABsNAAApDQAANQ0AAE8NAABdDQAAXg0AAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAGAAAWJAFJZgEAAAAAEF4NAABfDQAAEEADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO4AABYkARck AUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1soACZT/aAFUBlMKpg2fETsV nRjlHCwiAAbUAQAAAAAAAAAAAAAAAAAAAAAABuwEAAAAAAAAAAAAAAAAAAAAAAAG/wMAAAAAAAAA AAAAAAAAAAAAAAZTAwAAAAAAAAAAAAAAAAAAAAAABvkDAAAAAAAAAAAAAAAAAAAAAAAGnAMAAAAA AAAAAAAAAAAAAAAAAAZiAwAAAAAAAAAAAAAAAAAAAAAABkgEAAAAAAAAAAAAAAAAAAAAAAAGRwUA AAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAFPYBAAAa1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8b1iQA AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1iQAAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8d1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP80 1gYAAQoDbABh9gMAAAABXw0AAGINAAB1DQAAgQ0AAIgNAACPDQAAlg0AAKENAACjDQAArQ0AAMYN AADHDQAA1A0AANYNAADjDQAABw4AABQOAAAtDgAALg4AAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BgAAFiQBSWYBAAAAABIuDgAALw4AABA4AwAAAAAAAAAAAAAAAAAAAAAAAAAAAADuAAAWJAEXJAFJ ZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNbKAAmU/2gBVAZTCqYNnxE7FZ0Y 5RwsIgAG1AEAAAAAAAAAAAAAAAAAAAAAAAbsBAAAAAAAAAAAAAAAAAAAAAAABv8DAAAAAAAAAAAA AAAAAAAAAAAGUwMAAAAAAAAAAAAAAAAAAAAAAAb5AwAAAAAAAAAAAAAAAAAAAAAABpwDAAAAAAAA AAAAAAAAAAAAAAAGYgMAAAAAAAAAAAAAAAAAAAAAAAZIBAAAAAAAAAAAAAAAAAAAAAAABkcFAAAA AAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAABT2AQAAGtYkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YkAAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HNYkAAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/HdYkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/NNYG AAEKA2wAYfYDAAAAAS8OAAAyDgAAWA4AAGQOAABrDgAAeA4AAH8OAACaDgAAqQ4AALYOAAC5DgAA xQ4AANAOAADUDgAA4A4AAO0OAADwDgAA/A4AAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYA ABYkAUlmAQAAAAAR/A4AAP0OAAAPeAIAAAAAAAAAAAAAAAAAAAAAAAAA8AAAFiQBFyQBSWYBAAAA ApZsAAM0AQXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWygAJlP9oAVQGUwqmDZ8ROxWdGOUc LCIABtQBAAAAAAAAAAAAAAAAAAAAAAAG7AQAAAAAAAAAAAAAAAAAAAAAAAb/AwAAAAAAAAAAAAAA AAAAAAAABlMDAAAAAAAAAAAAAAAAAAAAAAAG+QMAAAAAAAAAAAAAAAAAAAAAAAacAwAAAAAAAAAA AAAAAAAAAAAABmIDAAAAAAAAAAAAAAAAAAAAAAAGSAQAAAAAAAAAAAAAAAAAAAAAAAZHBQAAAAAA AAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAU9gEAABrWJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvWJAAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xzWJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/x3WJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/zTWBgAB CgNsAGH2AwAAAAH9DgAAAA8AAA0PAAAYDwAAHw8AAC0PAAA8DwAASg8AAFcPAABaDwAAZg8AAHQP AACADwAAjQ8AAI4PAACaDwAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAW JAFJZgEAAAAAD5oPAACbDwAAEHwCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO4AABYkARckAUlmAQAA AAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1soACZT/aAFUBlMKpg2fETsVnRjlHCwi AAbUAQAAAAAAAAAAAAAAAAAAAAAABuwEAAAAAAAAAAAAAAAAAAAAAAAG/wMAAAAAAAAAAAAAAAAA AAAAAAZTAwAAAAAAAAAAAAAAAAAAAAAABvkDAAAAAAAAAAAAAAAAAAAAAAAGnAMAAAAAAAAAAAAA AAAAAAAAAAZiAwAAAAAAAAAAAAAAAAAAAAAABkgEAAAAAAAAAAAAAAAAAAAAAAAGRwUAAAAAAAAA AAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAFPYBAAAa1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8b1iQAAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8d1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP801gYAAQoD bABh9gMAAAABmw8AAJ4PAACtDwAAvw8AAM0PAADbDwAA6Q8AAPYPAAD4DwAABBAAABIQAAAeEAAA ORAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQB SWYBAAAAAAw5EAAAOhAAAA9EAgAAAAAAAAAAAAAAAAAAAAAAAADwAAAWJAEXJAFJZgEAAAAClmwA AzQBBdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNbKAAmU/2gBVAZTCqYNnxE7FZ0Y5RwsIgAG 1AEAAAAAAAAAAAAAAAAAAAAAAAbsBAAAAAAAAAAAAAAAAAAAAAAABv8DAAAAAAAAAAAAAAAAAAAA AAAGUwMAAAAAAAAAAAAAAAAAAAAAAAb5AwAAAAAAAAAAAAAAAAAAAAAABpwDAAAAAAAAAAAAAAAA AAAAAAAGYgMAAAAAAAAAAAAAAAAAAAAAAAZIBAAAAAAAAAAAAAAAAAAAAAAABkcFAAAAAAAAAAAA AAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA ABT2AQAAGtYkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YkAAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HNYkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/HdYkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wA YfYDAAAAAToQAAA9EAAAXRAAAGgQAABvEAAAfBAAAH0QAACLEAAAlBAAAKEQAACtEAAAuRAAALsQ AADIEAAAyhAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlm AQAAAAAOyhAAAMsQAAAQ/AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7gAAFiQBFyQBSWYBAAAAApZs AAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWygAJlP9oAVQGUwqmDZ8ROxWdGOUcLCIABtQB AAAAAAAAAAAAAAAAAAAAAAAG7AQAAAAAAAAAAAAAAAAAAAAAAAb/AwAAAAAAAAAAAAAAAAAAAAAA BlMDAAAAAAAAAAAAAAAAAAAAAAAG+QMAAAAAAAAAAAAAAAAAAAAAAAacAwAAAAAAAAAAAAAAAAAA AAAABmIDAAAAAAAAAAAAAAAAAAAAAAAGSAQAAAAAAAAAAAAAAAAAAAAAAAZHBQAAAAAAAAAAAAAA AAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU 9gEAABrWJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvWJAAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xzWJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/x3WJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2 AwAAAAHLEAAAzhAAAPoQAAAFEQAADBEAABoRAAArEQAAOREAAEYRAABIEQAAVBEAAG8RAAB7EQAA iREAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEA AAAADYkRAACKEQAAELwCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO4AABYkARckAUlmAQAAAAKWbAAF 1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1soACZT/aAFUBlMKpg2fETsVnRjlHCwiAAbUAQAA AAAAAAAAAAAAAAAAAAAABuwEAAAAAAAAAAAAAAAAAAAAAAAG/wMAAAAAAAAAAAAAAAAAAAAAAAZT AwAAAAAAAAAAAAAAAAAAAAAABvkDAAAAAAAAAAAAAAAAAAAAAAAGnAMAAAAAAAAAAAAAAAAAAAAA AAZiAwAAAAAAAAAAAAAAAAAAAAAABkgEAAAAAAAAAAAAAAAAAAAAAAAGRwUAAAAAAAAAAAAAAAAA AAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYB AAAa1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8b1iQAAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8d1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP801gYAAQoDbABh9gMA AAABihEAAI0RAACTEQAAmREAAKcRAACyEQAAuREAAMcRAADWEQAA4xEAAPERAAD9EQAACxIAABcS AAAYEgAAKBIAADYSAAA4EgAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAA ABE4EgAAORIAABA8AgAAAAAAAAAAAAAAAAAAAAAAAAAAAADuAAAWJAEXJAFJZgEAAAAClmwABdYY BAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNbKAAmU/2gBVAZTCqYNnxE7FZ0Y5RwsIgAG1AEAAAAA AAAAAAAAAAAAAAAAAAbsBAAAAAAAAAAAAAAAAAAAAAAABv8DAAAAAAAAAAAAAAAAAAAAAAAGUwMA AAAAAAAAAAAAAAAAAAAAAAb5AwAAAAAAAAAAAAAAAAAAAAAABpwDAAAAAAAAAAAAAAAAAAAAAAAG YgMAAAAAAAAAAAAAAAAAAAAAAAZIBAAAAAAAAAAAAAAAAAAAAAAABkcFAAAAAAAAAAAAAAAAAAAA ABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAA GtYkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YkAAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/HNYkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/HdYkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAA ATkSAAA8EgAAUBIAAGISAABwEgAAfxIAAJkSAACmEgAAqRIAALUSAAC3EgAAxRIAAMcSAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAAM xxIAAMgSAAAQhAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7gAAFiQBFyQBSWYBAAAAApZsAAXWGAQB AAAEAQAABAEAAAQBAAAEAQAABAEAAAjWygAJlP9oAVQGUwqmDZ8ROxWdGOUcLCIABtQBAAAAAAAA AAAAAAAAAAAAAAAG7AQAAAAAAAAAAAAAAAAAAAAAAAb/AwAAAAAAAAAAAAAAAAAAAAAABlMDAAAA AAAAAAAAAAAAAAAAAAAG+QMAAAAAAAAAAAAAAAAAAAAAAAacAwAAAAAAAAAAAAAAAAAAAAAABmID AAAAAAAAAAAAAAAAAAAAAAAGSAQAAAAAAAAAAAAAAAAAAAAAAAZHBQAAAAAAAAAAAAAAAAAAAAAT 1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrW JAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvWJAAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/xzWJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /x3WJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2AwAAAAHI EgAAyxIAANoSAADtEgAA9RIAAPwSAAAKEwAAIxMAADETAABLEwAAaBMAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAACmgT AABpEwAAEBQCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO4AABYkARckAUlmAQAAAAKWbAAF1hgEAQAA BAEAAAQBAAAEAQAABAEAAAQBAAAI1soACZT/aAFUBlMKpg2fETsVnRjlHCwiAAbUAQAAAAAAAAAA AAAAAAAAAAAABuwEAAAAAAAAAAAAAAAAAAAAAAAG/wMAAAAAAAAAAAAAAAAAAAAAAAZTAwAAAAAA AAAAAAAAAAAAAAAABvkDAAAAAAAAAAAAAAAAAAAAAAAGnAMAAAAAAAAAAAAAAAAAAAAAAAZiAwAA AAAAAAAAAAAAAAAAAAAABkgEAAAAAAAAAAAAAAAAAAAAAAAGRwUAAAAAAAAAAAAAAAAAAAAAE9Yw AAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1iQA AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8b1iQAAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8c1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d 1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP801gYAAQoDbABh9gMAAAABaRMA AGwTAAB7EwAAhBMAAI8TAACWEwAAnRMAAKQTAACyEwAAwRMAAMITAADQEwAA3RMAAN8TAADtEwAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAAA7tEwAA 7hMAABD4AQAAAAAAAAAAAAAAAAAAAAAAAAAAAADuAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQB AAAEAQAABAEAAAQBAAAEAQAACNbKAAmU/2gBVAZTCqYNnxE7FZ0Y5RwsIgAG1AEAAAAAAAAAAAAA AAAAAAAAAAbsBAAAAAAAAAAAAAAAAAAAAAAABv8DAAAAAAAAAAAAAAAAAAAAAAAGUwMAAAAAAAAA AAAAAAAAAAAAAAb5AwAAAAAAAAAAAAAAAAAAAAAABpwDAAAAAAAAAAAAAAAAAAAAAAAGYgMAAAAA AAAAAAAAAAAAAAAAAAZIBAAAAAAAAAAAAAAAAAAAAAAABkcFAAAAAAAAAAAAAAAAAAAAABPWMAAA AP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYkAAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YkAAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/HNYkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYk AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAAAe4TAADx EwAABhQAABgUAAAlFAAAMxQAAEEUAABPFAAAXRQAAGkUAABrFAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAAKaxQAAGwU AAAQNAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7gAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAA BAEAAAQBAAAEAQAABAEAAAjWygAJlP9oAVQGUwqmDZ8ROxWdGOUcLCIABtQBAAAAAAAAAAAAAAAA AAAAAAAG7AQAAAAAAAAAAAAAAAAAAAAAAAb/AwAAAAAAAAAAAAAAAAAAAAAABlMDAAAAAAAAAAAA AAAAAAAAAAAG+QMAAAAAAAAAAAAAAAAAAAAAAAacAwAAAAAAAAAAAAAAAAAAAAAABmIDAAAAAAAA AAAAAAAAAAAAAAAGSAQAAAAAAAAAAAAAAAAAAAAAAAZHBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/ BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWJAAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvWJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/xzWJAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3WJAAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2AwAAAAFsFAAAbxQA AHsUAACCFAAAhBQAAIoUAACMFAAAkhQAAJQUAACaFAAAnBQAAKQUAACmFAAArxQAALgUAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAADrgUAAC5FAAA EMwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAO4AABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQB AAAEAQAABAEAAAQBAAAI1soACZT/aAFUBlMKpg2fETsVnRjlHCwiAAbUAQAAAAAAAAAAAAAAAAAA AAAABuwEAAAAAAAAAAAAAAAAAAAAAAAG/wMAAAAAAAAAAAAAAAAAAAAAAAZTAwAAAAAAAAAAAAAA AAAAAAAABvkDAAAAAAAAAAAAAAAAAAAAAAAGnAMAAAAAAAAAAAAAAAAAAAAAAAZiAwAAAAAAAAAA AAAAAAAAAAAABkgEAAAAAAAAAAAAAAAAAAAAAAAGRwUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQB AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1iQAAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8b1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8c1iQAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d1iQAAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP801gYAAQoDbABh9gMAAAABuRQAALwUAADG FAAA0RQAANgUAADjFAAA5BQAAO8UAADxFAAAABUAAA4VAAAcFQAAKhUAACsVAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAAA0rFQAALBUAABAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAADuAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAA BAEAAAQBAAAEAQAACNbKAAmU/2gBVAZTCqYNnxE7FZ0Y5RwsIgAG1AEAAAAAAAAAAAAAAAAAAAAA AAbsBAAAAAAAAAAAAAAAAAAAAAAABv8DAAAAAAAAAAAAAAAAAAAAAAAGUwMAAAAAAAAAAAAAAAAA AAAAAAb5AwAAAAAAAAAAAAAAAAAAAAAABpwDAAAAAAAAAAAAAAAAAAAAAAAGYgMAAAAAAAAAAAAA AAAAAAAAAAZIBAAAAAAAAAAAAAAAAAAAAAAABkcFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAA AAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYkAAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/HNYkAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYkAAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAAASwVAAAtFQAALxUA ADcVAAA4FQAAQRUAAF4VAAB4FQAAohUAANIVAADTFQAA3BUAAPUVAAD+FQAABxYAACEWAAA6FgAA UxYAAF0WAACGFgAAmhYAALIWAADHFgAA2xYAAOQWAAACFwAACxcAABQXAAAtFwAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAADz AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAPgAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPgAAAAAAAAAAAAA AADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA8wAA AAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAA AAAAAAD4AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA 8wAAAAAAAAAAAAAAAAAAAAAAAAUAAAomAQtGAwAFAAAKJgALRgMAAAEAAAAcLRcAAEkXAABbFwAA fxcAAIgXAACjFwAAwhcAAMsXAADmFwAA+xcAABUYAAAeGAAARhgAAE8YAABZGAAAgxgAAIwYAACV GAAAzRgAANYYAADfGAAA9RgAAP4YAAAoGQAAMRkAADoZAABRGQAAfRkAAJEZAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA9QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA9QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADw AAAAAAAAAAAAAAAABQAACiYCC0YDAAUAAAomAAtGAwAFAAAKJgELRgMAAByRGQAAzhkAAPUZAAAL GgAAHBoAAN8aAADoGgAA/RoAABgbAAA+GwAARxsAAFobAABjGwAAehsAAJIbAACbGwAAxRsAAM4b AADXGwAA9BsAAP0bAAAGHAAADxwAAB0cAAAmHAAASxwAAFQcAABVHAAA+gAAAAAAAAAAAAAAAPUA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADwAAAAAAAA AAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAA APUAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADwAAAA AAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA9QAAAAAAAAAA AAAAAPUAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADw AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAAAAAAAAAA BQAAD4TQAl6E0AIFAAAKJgALRgMABQAACiYBC0YDAAUAAAomAgtGAwAAG1UcAABWHAAA+QAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAPhNACXoTQAgABIAAxkGgBH7DQLyCw4D0h sAgHIrAIByOQoAUkkKAFJbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUABAACgABAGkADwADAAAA AAAAAAAAOAAAQPH/AgA4AAwABgBOAG8AcgBtAGEAbAAAAAIAAAAYAENKGABfSAEEYUoYAG1ICQRz SAkEdEgJBAAAAAAAAAAAAAAAAAAAAAAAADwAQUDy/6EAPAAMABYARABlAGYAYQB1AGwAdAAgAFAA YQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAAAAAAAAAAAA0AEIAAQDyADQADAAJAEIAbwBk AHkAIABUAGUAeAB0AAAAAgAPAA0AQioGQ0oUAHBo/wAAAAAAAAAAVhgAAAsAAI4AAAUA/////wAA AAAjAAAAJAAAAD0BAAA+AQAA/wEAAAACAAAJAgAAJgIAAEACAABqAgAAmgIAAJsCAACcAgAAnQIA AJ4CAAC3AgAAuAIAAL4CAADIAgAAzQIAANUCAADfAgAA5gIAAOwCAAD0AgAAAAMAAAEDAAADAwAA CgMAABADAAAcAwAAJAMAACcDAAAwAwAANwMAADwDAABCAwAASQMAAFEDAABYAwAAXgMAAGcDAABu AwAAewMAAIIDAACDAwAAhQMAAIsDAACRAwAAnAMAAKMDAACuAwAAtwMAAL4DAADDAwAAyQMAANAD AADYAwAA3wMAAOQDAADtAwAA9AMAAAEEAAAIBAAACQQAAAsEAAAdBAAAPQQAAEMEAABFBAAASwQA AFUEAABgBAAAYwQAAHIEAAB+BAAAigQAAJkEAACaBAAAqQQAALUEAADBBAAAxAQAANAEAADRBAAA 0wQAAPgEAAAEBQAACwUAABIFAAAZBQAAKAUAADcFAABDBQAAUAUAAFMFAABfBQAAawUAAG4FAAB6 BQAAhgUAAIkFAACVBQAAlgUAAJgFAACcBQAApQUAAK4FAAC5BQAAxAUAAMsFAADRBQAA2AUAAOcF AAAABgAADQYAAA8GAAArBgAALAYAADgGAABHBgAASAYAAEkGAABLBgAAXgYAAGkGAABwBgAAdgYA AH0GAACGBgAAiAYAAIkGAACYBgAApAYAAK4GAACzBgAAtAYAAMIGAADOBgAA6QYAAOoGAADsBgAA /QYAAAgHAAAPBwAAHAcAACsHAAA+BwAASQcAAE0HAABaBwAAXAcAAGoHAABrBwAAbQcAAHUHAACJ BwAAkwcAAJwHAACpBwAAtgcAAMUHAADRBwAA3QcAAPcHAAARCAAAEggAABQIAAAzCAAAPAgAAEcI AABOCAAAVQgAAFwIAABsCAAAewgAAIcIAACTCAAAlQgAAK8IAAC9CAAAvggAAL8IAADCCAAA0ggA AN0IAADoCAAA6wgAAPYIAAD9CAAA/ggAAAUJAAAMCQAAGwkAACkJAAA1CQAATwkAAF0JAABeCQAA XwkAAGIJAAB1CQAAgQkAAIgJAACPCQAAlgkAAKEJAACjCQAArQkAAMYJAADHCQAA1AkAANYJAADj CQAABwoAABQKAAAtCgAALgoAAC8KAAAyCgAAWAoAAGQKAABrCgAAeAoAAH8KAACaCgAAqQoAALYK AAC5CgAAxQoAANAKAADUCgAA4AoAAO0KAADwCgAA/AoAAP0KAAAACwAADQsAABgLAAAfCwAALQsA ADwLAABKCwAAVwsAAFoLAABmCwAAdAsAAIALAACNCwAAjgsAAJoLAACbCwAAngsAAK0LAAC/CwAA zQsAANsLAADpCwAA9gsAAPgLAAAEDAAAEgwAAB4MAAA5DAAAOgwAAD0MAABdDAAAaAwAAG8MAAB8 DAAAfQwAAIsMAACUDAAAoQwAAK0MAAC5DAAAuwwAAMgMAADKDAAAywwAAM4MAAD6DAAABQ0AAAwN AAAaDQAAKw0AADkNAABGDQAASA0AAFQNAABvDQAAew0AAIkNAACKDQAAjQ0AAJMNAACZDQAApw0A ALINAAC5DQAAxw0AANYNAADjDQAA8Q0AAP0NAAALDgAAFw4AABgOAAAoDgAANg4AADgOAAA5DgAA PA4AAFAOAABiDgAAcA4AAH8OAACZDgAApg4AAKkOAAC1DgAAtw4AAMUOAADHDgAAyA4AAMsOAADa DgAA7Q4AAPUOAAD8DgAACg8AACMPAAAxDwAASw8AAGgPAABpDwAAbA8AAHsPAACEDwAAjw8AAJYP AACdDwAApA8AALIPAADBDwAAwg8AANAPAADdDwAA3w8AAO0PAADuDwAA8Q8AAAYQAAAYEAAAJRAA ADMQAABBEAAATxAAAF0QAABpEAAAaxAAAGwQAABvEAAAexAAAIIQAACEEAAAihAAAIwQAACSEAAA lBAAAJoQAACcEAAApBAAAKYQAACvEAAAuBAAALkQAAC8EAAAxhAAANEQAADYEAAA4xAAAOQQAADv EAAA8RAAAAARAAAOEQAAHBEAACoRAAArEQAALBEAAC0RAAAvEQAANxEAADgRAABBEQAAXhEAAHgR AACiEQAA0hEAANMRAADcEQAA9REAAP4RAAAHEgAAIRIAADoSAABTEgAAXRIAAIYSAACaEgAAshIA AMcSAADbEgAA5BIAAAITAAALEwAAFBMAAC0TAABJEwAAWxMAAH8TAACIEwAAoxMAAMITAADLEwAA 5hMAAPsTAAAVFAAAHhQAAEYUAABPFAAAWRQAAIMUAACMFAAAlRQAAM0UAADWFAAA3xQAAPUUAAD+ FAAAKBUAADEVAAA6FQAAURUAAH0VAACRFQAAzhUAAPUVAAALFgAAHBYAAN8WAADoFgAA/RYAABgX AAA+FwAARxcAAFoXAABjFwAAehcAAJIXAACbFwAAxRcAAM4XAADXFwAA9BcAAP0XAAAGGAAADxgA AB0YAAAmGAAASxgAAFQYAABVGAAAWBgAAJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAyAAMAAAAAAAAACAAAAAgJgBAyAAMAAAAAAAAgAAAAAAgJgB AyAAMAEAAAAAAgAAAAAAgJgBAyAAMAIAAAAAAgAAAAAAgJgBAyAAMAMAAAAAAgAAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkA AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkA AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkA AAAAMAAAAAAAAACAAAAAgKsAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkA AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkA AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkA AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkA AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA AAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA AAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkA AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA AAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkA AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA AAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAA MAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAA AAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAA AACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACA AAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAA gKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkA AAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgKkAAAAAMAAAAAAAAACAAAAAgJkAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAyAAMAEAAAAAAACAAAAAgJgBAyAAMAAAAAD6 EAAAAAAAgJgBAyAAMAEAAAD6EAAAAAAAgJgBAyAAMAIAAAD6EAAAAAAAgJgBAyAAMAMAAAD6EAAA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAyAAMAIAAAAAAACAAAAAgJgBAyAAMAAAAACVEQAAAAAA gJgBAyAAMAEAAACVEQAAAAAAgJgAAyAAMAMAAAAAAACAAAAAgJgBAyAAMAAAAADAEQAAAAAAgJgB AyAAMAEAAADAEQAAAAAAgJgBAyAAMAIAAADAEQAAAAAAgJgAAyAAMAQAAAAAAACAAAAAgJgBAyAA MAAAAAAVEgAAAAAAgJgBAyAAMAEAAAAVEgAAAAAAgJgBAyAAMAIAAAAVEgAAAAAAgJgBAyAAMAMA AAAVEgAAAAAAgJgBAyAAMAQAAAAVEgAAAAAAgJgAAyAAMAUAAAAAAACAAAAAgJgBAyAAMAAAAACd EgAAAAAAgJgBAyAAMAEAAACdEgAAAAAAgJgAAyAAMAYAAAAAAACAAAAAgJgBAyAAMAAAAADNEgAA AAAAgJgBAyAAMAEAAADNEgAAAAAAgJgBAyAAMAIAAADNEgAAAAAAgJgBAyAAMAMAAADNEgAAAAAA gJgAAyAAMAcAAAAAAACAAAAAgJgBAyAAMAAAAABBEwAAAAAAgJgBAyAAMAEAAABBEwAAAAAAgJgA AyAAMAgAAAAAAACAAAAAgJgBAyAAMAAAAACEEwAAAAAAgJgBAyAAMAEAAACEEwAAAAAAgJgBAyAA MAIAAACEEwAAAAAAgJgAAyAAMAkAAAAAAACAAAAAgJgBAyAAMAAAAADXEwAAAAAAgJgBAyAAMAEA AADXEwAAAAAAgJgAAyAAMAoAAAAAAACAAAAAgJgBAyAAMAAAAAARFAAAAAAAgJgBAyAAMAEAAAAR FAAAAAAAgJgAAyAAMAsAAAAAAACAAAAAgJgBAyAAMAAAAABOFAAAAAAAgJgBAyAAMAEAAABOFAAA AAAAgJgAAyAAMAwAAAAAAACAAAAAgJgBAyAAMAAAAACYFAAAAAAAgJgAAyAAMA0AAAAAAACAAAAA gJgBAyAAMAAAAAC3FAAAAAAAgJgBAyAAMAEAAAC3FAAAAAAAgJgAAyAAMA4AAAAAAACAAAAAgJgB AyAAMAAAAADzFAAAAAAAgJgBAyAAMAEAAADzFAAAAAAAgJgCAyAAMAAAAAATFQAAAAAAgJgCAyAA MAEAAAATFQAAAAAAgJgBAyAAMAIAAADzFAAAAAAAgJgCAyAAMAAAAACQFQAAAAAAgJgCAyAAMAEA AACQFQAAAAAAgJgBAyAAMAMAAADzFAAAAAAAgJgAAyAAMA8AAAAAAACAAAAAgJgBAyAAMAAAAACh FgAAAAAAgJgBAyAAMAEAAAChFgAAAAAAgJgBAyAAMAIAAAChFgAAAAAAgJgAAyAAMBAAAAAAAACA AAAAgJgBAyAAMAAAAAAAFwAAAAAAgJgAAyAAMBEAAAAAAACAAAAAgJgBAyAAMAAAAAAcFwAAAAAA gJgBAyAAMAEAAAAcFwAAAAAAgJgAAyAAMBIAAAAAAACAAAAAgJgBAyAAMAAAAABUFwAAAAAAgJgB AyAAMAEAAABUFwAAAAAAgJgAAyAAMBMAAAAAAACAAAAAgJgBAyAAMAAAAACQFwAAAAAAgJgBAyAA MAEAAACQFwAAAAAAgJgAAyAAMBQAAAAAAACAAAAAgJgBAyAAMAAAAAC/FwAAAAAAgJgBAyAAMAEA AAC/FwAAAAAAgJgAAyAAMBUAAAAAAACAAAAAgJgBAyAAMAAAAADfFwAAAAAAgJgBAyAAMAEAAADf FwAAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJoAAAAAMAAAAAAAAACAAAAAgAAEAABWHAAAEAAAAAAE AAC3BgAAAAcAAAMHAACCBwAAgwcAAAgIAAAJCAAA0AgAANEIAACVCQAAlgkAAEgKAABJCgAA6QoA AOoKAABqCwAAawsAABEMAAASDAAAvgwAAL8MAABeDQAAXw0AAC4OAAAvDgAA/A4AAP0OAACaDwAA mw8AADkQAAA6EAAAyhAAAMsQAACJEQAAihEAADgSAAA5EgAAxxIAAMgSAABoEwAAaRMAAO0TAADu EwAAaxQAAGwUAAC4FAAAuRQAACsVAAAsFQAALRcAAJEZAABVHAAAVhwAABEAAAATAAAAFAAAABUA AAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAA ACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAA MgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABA AAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAAAAQAAFYcAAASAAAAAAAAAPAGAADzBgAAFAgAABcI AAAmCAAAMggAAMIIAADFCAAA1AgAANwIAAA3CgAAOwoAALoKAAC9CgAAowsAAKYLAABtDwAAeg8A ANwRAADrEQAAIRIAADASAAByEgAAgRIAAIYSAACVEgAAGhMAACYTAACQEwAAnBMAANMTAADfEwAA oBQAAKwUAACBFQAAihUAAPsVAAAEFgAAshYAALoWAAAFFwAAERcAAGgXAABxFwAAWBgAAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAAAAAAPAQAAIwEAAEkBAABOAQAACQIAABMCAAAm AgAAKwIAAEACAABIAgAAagIAAHACAAClBQAArQUAAK8FAACzBQAA2AYAANwGAABmCAAAaggAANQI AADcCAAA3QgAAOIIAADtCQAA8QkAAIkKAACNCgAApAoAAKgKAAC6CgAAvQoAACgMAAAsDAAAJw0A ACoNAABeDQAAYg0AAJMNAACYDQAAeg4AAH4OAAD7EAAA/xAAAEERAABLEQAAXhEAAGMRAAB4EQAA gBEAAKIRAACoEQAABxIAAA4SAAA6EgAAQRIAAFMSAABcEgAAmhIAAKESAAAUEwAAGRMAAC0TAAA1 EwAASRMAAE0TAACIEwAAjxMAAKMTAACpEwAAyxMAANITAADmEwAA6xMAAPsTAAABFAAATxQAAFgU AADfFAAA5RQAAH0VAACAFQAAzhUAANAVAAD1FQAA+hUAAAsWAAAQFgAA/RYAAAQXAAAYFwAAIBcA AHoXAACBFwAAWBgAAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAAAAAAnQIAAAEDAAADAwAAgwMAAIUDAAAJ BAAACwQAABAEAAASBAAA0QQAANMEAACWBQAAmAUAAA0GAAAOBgAASQYAAEsGAADqBgAA7AYAAGsH AABtBwAAEggAABQIAAC/CAAAwggAAF8JAABiCQAALwoAADIKAAD9CgAAAAsAAEgLAABJCwAAmwsA AJ4LAADlCwAA6AsAADoMAAA9DAAAywwAAM4MAACKDQAAjQ0AADkOAAA8DgAAyA4AAMsOAABpDwAA bA8AAO4PAABvEAAAkhAAAJMQAAC5EAAAvBAAAO8QAADwEAAA/hAAAP8QAAAMEQAADREAAOMSAAAK EwAAFBMAAH4TAAAeFAAAThQAAFkUAACLFAAA1BQAANUUAAAnFQAAMBUAAEcXAABZFwAAYxcAAJEX AAAGGAAAVBgAAFUYAABYGAAABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA BAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAE AAMABAADAAcA//8UAAAACQBTAHUAZQAgAEgAYQByAGUAcwBIAEMAOgBcAEQAbwBjAHUAbQBlAG4A dABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABzAGsAaABcAE0AeQAgAEQAbwBjAHUAbQBl AG4AdABzAFwAdQBcAGkAZQB0AGYAXABpAGQAcgAtAGQAcgBhAGYAdABzAFwAcwB0AGEAdABlAG0A dAAuAGQAbwBjAAkAUwB1AGUAIABIAGEAcgBlAHMASABDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAg AGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwAcwBrAGgAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQA cwBcAHUAXABpAGUAdABmAFwAaQBkAHIALQBkAHIAYQBmAHQAcwBcAHMAdABhAHQAZQBtAHQALgBk AG8AYwAJAFMAdQBlACAASABhAHIAZQBzAEgAQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4A ZAAgAFMAZQB0AHQAaQBuAGcAcwBcAHMAawBoAFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXAB1 AFwAaQBlAHQAZgBcAGkAZAByAC0AZAByAGEAZgB0AHMAXABzAHQAYQB0AGUAbQB0AC4AZABvAGMA CQBTAHUAZQAgAEgAYQByAGUAcwBeAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABT AGUAdAB0AGkAbgBnAHMAXABzAGsAaABcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEA XABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAg AHMAYQB2AGUAIABvAGYAIABzAHQAYQB0AGUAbQB0AC4AYQBzAGQACQBTAHUAZQAgAEgAYQByAGUA cwBjAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABz AGsAaAAuAEMATwBSAFAAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEAdABhAFwATQBpAGMA cgBvAHMAbwBmAHQAXABXAG8AcgBkAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBl ACAAbwBmACAAcwB0AGEAdABlAG0AdAAuAGEAcwBkAAkAUwB1AGUAIABIAGEAcgBlAHMATQBDADoA XABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwAcwBrAGgALgBD AE8AUgBQAFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXAB1AFwAaQBlAHQAZgBcAGkAZAByAC0A ZAByAGEAZgB0AHMAXABzAHQAYQB0AGUAbQB0AC4AZABvAGMACQBTAHUAZQAgAEgAYQByAGUAcwBN AEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABzAGsA aAAuAEMATwBSAFAAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAHUAXABpAGUAdABmAFwAaQBk AHIALQBkAHIAYQBmAHQAcwBcAHMAdABhAHQAZQBtAHQALgBkAG8AYwAJAFMAdQBlACAASABhAHIA ZQBzAE0AQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBc AHMAawBoAC4AQwBPAFIAUABcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAdQBcAGkAZQB0AGYA XABpAGQAcgAtAGQAcgBhAGYAdABzAFwAcwB0AGEAdABlAG0AdAAuAGQAbwBjAAkAUwB1AGUAIABI AGEAcgBlAHMATQBDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4A ZwBzAFwAcwBrAGgALgBDAE8AUgBQAFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXAB1AFwAaQBl AHQAZgBcAGkAZAByAC0AZAByAGEAZgB0AHMAXABzAHQAYQB0AGUAbQB0AC4AZABvAGMACQBTAHUA ZQAgAEgAYQByAGUAcwBNAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0 AGkAbgBnAHMAXABzAGsAaAAuAEMATwBSAFAAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAHUA XABpAGUAdABmAFwAaQBkAHIALQBkAHIAYQBmAHQAcwBcAHMAdABhAHQAZQBtAHQALgBkAG8AYwAD ADV5thKs+dRo/w//D/8P/w//D/8P/w//D/8PEABlUOkgqnwq9P8P/w//D/8P/w//D/8P/w//DxAA Ak+RexIyQnb/D/8P/w//D/8P/w//D/8P/w8QAAEAAAAXEAAAAAAAAAAAAABoAQAAAAAAAAsYAAAP hGgBEYSY/hXGBQABaAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAABABAAAAAAAAAAAAaAEA AAAAAAAAGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+AgABAC4AAQAAABcQAAAAAAAAAAAAAGgB AAAAAAAACxgAAA+ECAcRhJj+FcYFAAEIBwZehAgHYISY/k9KAwBRSgMAbygAAQCn8AEAAAAXkAAA AAAAAAAAAABoAQAAAAAAAAsYAAAPhNgJEYSY/hXGBQAB2AkGXoTYCWCEmP5PSgEAUUoBAG8oAAEA t/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SoDBGEmP4VxgUAAagMBl6EqAxghJj+T0oE AFFKBABvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EeA8RhJj+FcYFAAF4DwZe hHgPYISY/k9KAwBRSgMAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhEgSEYSY /hXGBQABSBIGXoRIEmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAL GAAAD4QYFRGEmP4VxgUAARgVBl6EGBVghJj+T0oEAFFKBABvKAABAG8AAQAAABeQAAAAAAAAAAAA AGgBAAAAAAAACxgAAA+E6BcRhJj+FcYFAAHoFwZehOgXYISY/k9KAwBRSgMAbygAAQCn8AEAAAAA EAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP4CAAAALgABAAAA BBABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+AgABAC4AAQAA AAKSAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM/wIAAgAuAAEA AAAAkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP4CAAMALgAB AAAABJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+AgAEAC4A AQAAAAKSAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+E4BARhEz/FcYFAAHgEAZehOAQYIRM/wIABQAu AAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP4CAAYA LgABAAAABJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+AgAH AC4AAQAAAAKSAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM/wIA CAAuAAEAAAAAEAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP4C AAAALgABAAAABJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+ AgABAC4AAQAAAAKSAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EcAgRhEz/FcYFAAFwCAZehHAIYIRM /wIAAgAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CE mP4CAAMALgABAAAABJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5g hJj+AgAEAC4AAQAAAAKSAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+E4BARhEz/FcYFAAHgEAZehOAQ YIRM/wIABQAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhLATEYSY/hXGBQABsBMGXoSw E2CEmP4CAAYALgABAAAABJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SAFhGEmP4VxgUAAYAWBl6E gBZghJj+AgAHAC4AAQAAAAKSAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EUBkRhEz/FcYFAAFQGQZe hFAZYIRM/wIACAAuAAMAAAACT5F7AAAAAAAAAAAAAAAAZVDpIAAAAAAAAAAAAAAAADV5thIAAAAA AAAAAAAAAAD//////////////////wMAAAAAAAAAAAD//wMAAAASAAEACQQPAAkEBQAJBAEACQQD AAkEBQAJBAEACQQDAAkEBQAJBBIADwAJBBkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkE EgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQAAAAAnQIAAJ4CAAC3AgAAuAIA AL4CAADIAgAAzQIAANUCAADfAgAA5gIAAPQCAAAAAwAAAQMAAAMDAAAQAwAAHAMAACcDAAA3AwAA SQMAAFgDAABuAwAAggMAAIMDAACFAwAAkQMAAKMDAACuAwAAvgMAANADAADfAwAA9AMAAAgEAAAJ BAAACwQAAD0EAABFBAAAVQQAAGMEAAB+BAAAmgQAALUEAADQBAAA0QQAANMEAAD4BAAACwUAABkF AAAoBQAAQwUAAF8FAAB6BQAAlQUAAJYFAACYBQAAuQUAAMsFAADYBQAA5wUAAAAGAAAPBgAALAYA AEgGAABJBgAASwYAAF4GAABwBgAAfQYAAIkGAACkBgAAtAYAAM4GAADpBgAA6gYAAOwGAAD9BgAA DwcAABwHAAArBwAAPgcAAE0HAABcBwAAagcAAGsHAABtBwAAiQcAAJwHAACpBwAAtgcAANEHAADd BwAA9wcAABEIAAASCAAAFAgAADwIAABOCAAAXAgAAGwIAACHCAAAlQgAAK8IAAC+CAAAvwgAAMII AADrCAAA/ggAAAwJAAAbCQAAKQkAADUJAABPCQAAXgkAAF8JAABiCQAAdQkAAIgJAACWCQAAowkA AMcJAADjCQAABwoAAC4KAAAvCgAAMgoAAFgKAABrCgAAfwoAAJoKAACpCgAAxQoAAOAKAAD8CgAA /QoAAAALAAANCwAAHwsAAC0LAAA8CwAASgsAAGYLAACACwAAmgsAAJsLAACeCwAArQsAAL8LAADN CwAA2wsAAOkLAAAEDAAAHgwAADkMAAA6DAAAPQwAAF0MAABvDAAAfQwAAIsMAACUDAAArQwAALsM AADKDAAAywwAAM4MAAD6DAAADA0AABoNAAArDQAAOQ0AAFQNAABvDQAAiQ0AAIoNAACNDQAApw0A ALkNAADHDQAA4w0AAP0NAAAYDgAAKA4AADgOAAA5DgAAPA4AAFAOAABiDgAAcA4AAH8OAACZDgAA qQ4AALcOAADHDgAAyA4AAMsOAADaDgAA7Q4AAPwOAAAKDwAAIw8AADEPAABLDwAAaA8AAGkPAABs DwAAhA8AAJYPAACkDwAAsg8AAMIPAADQDwAA3w8AAO0PAADuDwAA8Q8AAAYQAAAYEAAAJRAAADMQ AABBEAAATxAAAF0QAABrEAAAbBAAAG8QAAB7EAAAhBAAAIwQAACUEAAAnBAAAKYQAACvEAAAuBAA ALkQAAC8EAAAxhAAANgQAADkEAAA8RAAAAARAAAOEQAAHBEAACsRAAAsEQAAWBgAAAAAAAAIAAAA AgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAAC AQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIB AAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEA AAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAA AgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAACe AQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIB AAACAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEA AAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAA AgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAAC AQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIB AAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAACAQAAAgEA AAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAA ngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEAAAIBAAAC AQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIB AAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAJ4BAAACAQAAAgEA AAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAACeAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAA AgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAJYBAAD/ QA2AAQDeBAAA3gQAAMCjEAkEAAQA3gQAAAAAAADeBAAAlP9UBgIQAAAAAAAAAFYYAACwAAAIAEAA AP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAA AAD//wAAAgD//wAAAAAFAAAARxaQAQAAAgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/AQAAAAAA AFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQ AAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBId6ACAAAACACAAA AAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAADsGkAECAAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAA AAAAgAAAAABXAGkAbgBnAGQAaQBuAGcAcwAAAD81kAEAAAIHAwkCAgUCBASHegAgAAAAgAgAAAAA AAAA/wEAAAAAAABDAG8AdQByAGkAZQByACAATgBlAHcAAAAiAAQAcQiIGADw0AIAAGgBAAAAAGst WyYzi2GGZjtbZkEANwEAAIUDAAARFAAAAQAKAAAABAADECoAAAAAAAAAAAAAAAEAAQAAAAEAAAAA AAAAIQMA8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAegBbQAtACBgTIwAAAQABkAZAAA ABkAAACkGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmgIAAAAA AAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAEMoNRAPAQAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA//8SAAAAAAAAAAUARQB2AGUAbgB0AAAAAAAAAAkAUwB1AGUAIABIAGEAcgBlAHMA CQBTAHUAZQAgAEgAYQByAGUAcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAiAEAABIA AAABAAAAmAAAAAIAAACgAAAAAwAAALAAAAAEAAAAvAAAAAUAAADQAAAABgAAANwAAAAHAAAA6AAA AAgAAAD8AAAACQAAABABAAASAAAAHAEAAAoAAAA4AQAACwAAAEQBAAAMAAAAUAEAAA0AAABcAQAA DgAAAGgBAAAPAAAAcAEAABAAAAB4AQAAEwAAAIABAAACAAAA5AQAAB4AAAAGAAAARXZlbnQAZgAe AAAAAQAAAAB2ZW4eAAAACgAAAFN1ZSBIYXJlcwAgAB4AAAABAAAAAHVlIB4AAAABAAAAAHVlIB4A AAALAAAATm9ybWFsLmRvdAAAHgAAAAoAAABTdWUgSGFyZXMAAAAeAAAAAwAAADY1ACAeAAAAEwAA AE1pY3Jvc29mdCBXb3JkIDkuMAAAQAAAAAAKOnIrAAAAQAAAAAD0d1O7Z8EBQAAAAAASmL9sZsEB QAAAAABa8oV/n8EBAwAAAAEAAAADAAAAhQMAAAMAAAARFAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAF AAIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAAAQBAAAMAAAAAQAAAGgA AAAPAAAAcAAAAAUAAACUAAAABgAAAJwAAAARAAAApAAAABcAAACsAAAACwAAALQAAAAQAAAAvAAA ABMAAADEAAAAFgAAAMwAAAANAAAA1AAAAAwAAADmAAAAAgAAAOQEAAAeAAAAGwAAAE5leHRIb3Ag VGVjaG5vbG9naWVzLCBJbmMuAAADAAAAKgAAAAMAAAAKAAAAAwAAAKQYAAADAAAAMhEJAAsAAAAA AAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAGAAAARXZlbnQADBAAAAIAAAAeAAAA BgAAAFRpdGxlAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAE AAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIA AAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAA ACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAA LwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9 AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAP7///9JAAAASgAAAEsA AABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAA AFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAAZQAAAGYAAABnAAAA aAAAAGkAAABqAAAAawAAAGwAAABtAAAA/v///28AAABwAAAAcQAAAHIAAABzAAAAdAAAAHUAAAD+ ////dwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAAAP7////9/////f///4EAAAD+/////v////7/ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////UgBvAG8AdAAgAEUAbgB0 AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH///// /////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAsFMol3+fwQGDAAAAgAAAAAAAAAAx AFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAADgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AEgAAABBSwAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBBQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACKOAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEA dABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAABAAAAP////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABuAAAAABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4A dABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf////// /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHYAAAAAEAAAAAAAAAEA QwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAASAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAGoAAAAAAAAATwBiAGoAZQBjAHQAUABvAG8AbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABYAAQD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAALBT KJd/n8EBsFMol3+fwQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AQD+/wMKAAD/////BgkCAAAA AADAAAAAAAAARhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABX b3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --=====================_37894649==_ Content-Type: text/plain; charset="us-ascii"; format=flowed --=====================_37894649==_-- 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 MAA15921 for ; Thu, 17 Jan 2002 12:16:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3E418912E5; Thu, 17 Jan 2002 12:15:10 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D36AA912E6; Thu, 17 Jan 2002 12:15:09 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC6C6912E5 for ; Thu, 17 Jan 2002 12:15:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 17FBC5DDDD; Thu, 17 Jan 2002 12:15:07 -0500 (EST) Delivered-To: idr@merit.edu Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id A7E405DDDA for ; Thu, 17 Jan 2002 12:15:06 -0500 (EST) Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id CEDB13F67; Thu, 17 Jan 2002 09:17:54 -0800 (PST) Received: from khonsu.sw.nexsi.com (cscovpn6.nexsi.com [172.16.213.6]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id JAA17644; Thu, 17 Jan 2002 09:14:17 -0800 Date: Thu, 17 Jan 2002 09:14:13 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <32264605142.20020117091413@nexsi.com> To: Susan Hares Cc: randy Bush , idr@merit.edu Subject: Re: bgp4-17 Cease subcode In-Reply-To: <5.0.0.25.0.20020117083423.0252ef28@mail.nexthop.com> References: <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <20020115140711.GA23937@opentransit.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <5.0.0.25.0.20020117083423.0252ef28@mail.nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Sue, To clarify my position: I think that recommendation for an exponential back-off is a good thing and solves a real problem. However, I think that the IdleHold state should not be in the FSM because: 1) It seems to be redundant. See (*) below. 2) It introduces changes to the base FSM to account for a feature of an optional nature. People who didn't implement it would be put in a non-compliant position, people who won't implement it will have to take things out of the FSM. 3) I am under impression (though I might be wrong) that it does not match the majority of deployed implementations that do not have this state and hence would ago against the objective of this spec review round. --- *) When it comes to FSMs, one almost always can achieve the same results by either using an existing state with flags or by adding another state. It is often hard to decide which approach to follow. One simple test I find useful is to see how different periodic activities, packet and event processing are for the two states. If there is a considerable difference, separate states are most probably a good idea. In our case, the two states are practically the same---we don't do anything on a periodic basis (no messages, no outbound connections), we do not accept incoming connections, we ignore all events but Start. The difference is essentially in the reason we get to either state, which affects the name of the state and when the Start event is generated. IMHO it does not justify a new state, but that's my personal opinion :) I think the original text from -12 (maybe revised a bit) should be good enough... -- Alex Zinin Thursday, January 17, 2002, 5:51:35 AM, Susan Hares wrote: > Alex and Randy: > Let's go back to first principles here on the FSM? > 1st) The original text is below from draft-12. > This explanation gives "flag" that has implications > for the full state machine. The definition of > state machines that Alex proposes, is all inputs > and all actions are determined by state machine in > clear text. > 2nd) Is the bug real? > The text was fixing a " persistent bgp flapping" > bug. According to the text there is a > state within a state with fairly vague > descriptions. > The second question belongs to Randy, since he wears 2 hats (Operations > and Routing temp AD), was this a real problem? Has it gone away? > 1) At least one routing vendor doesn't implement it [cisco] > and I know this vendor is utilized in BGP peering sessions > in the network. > 2) What was the operational concern this text implies? > If there is no operational issue and no operational usage, > return to the original FSM text and out the comments on > "hold down." > So, Randy and all other operators - Is the problem it describes real? > Does anyone need it? Let's answer that question first. > Sue Hares > ---------------------- > If a BGP speaker detects an error, it shuts down the connection > and changes its state to Idle. Getting out of the Idle state > requires generation of the Start event. If such an event is > generated automatically, then persistent BGP errors may result > in persistent flapping of the speaker. To avoid such a > condition it is recommended that Start events should not be > generated immediately for a peer that was previously > transitioned to Idle due to an error. For a peer that was > previously transitioned to Idle due to an error, the time > Expiration Date July 2001 [Page 31] > RFC DRAFT January 2001 > between consecutive generation of Start events, if such events > are generated automatically, shall exponentially increase. The > value of the initial timer shall be 60 seconds. The time shall > be doubled for each consecutive retry. > Any other event received in the Idle state is ignored. > At 11:10 AM 1/16/2002 -0800, you wrote: >>Sue, >> >> Introduction of the IdleHold does change the FSM, >> and I thought we wanted the spec to reflect the current >> running code as much as possible. >> >> I agree with Russ and Ishi---the new state does not >> seem to be necessary, instead it could be as easy >> as holding the session in Idle and giving clue on >> how to make the delay exponential. I don't think >> there's an interoperability issue if people decide >> to keep the session in Idle using different internal >> mechanisms. >> >> Regards, >> >>-- >>Alex Zinin >> >>Wednesday, January 16, 2002, 6:04:36 AM, Susan Hares wrote: >> >> > Kunihiro: >> >> > We are not changing the FSM so I would be surprised if the change >> > was anything but modest. Usually specifications with "no big" deal get >> > interpreted differently. Inter-operable code means you tie down the >> details. >> >> > The comment was on the clarity of the specification. >> >> > If you have a specific comment on the text of the state machine, >> > can you propose the concerns you have as a revision to the text. >> >> > Sue >> >> > PS -- I just love last call on a draft... It's when >> > everyone finally reads a new section ;-)... >> >> >> > At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote: >> >> >> > Is the expoential backoff in the FSM in current implementations? >> >> >> >> >> >> I guess we are going to find this out as part of the implementation >> >> >> report. And if it is not in (at least two) current implementations, >> >> >> we'll take it out of the text. >> >> > >> >> >I implemented Cease subcode in zebra-0.92a but not exponential backoff. >> >> >I checked that new subcode does not put other BGP stack in trouble >> >> >(checked Cisco and Juniper). >> >> >> >>First of all, sorry for talking about specific implementation. In >> >>Zebra implementation we've implemented Cease subcode. The code is in >> >>CVS repository. I'll prepare a release version for that. >> >> >> >>And also we've implemented exponetial backoff. It is done without >> >>introducing new FSM status. It is not a big deal. Just check a flag >> >>in a few functions. >> >> >> >>Exponential backoff is a good feature. I can't understand why it >> >>require change to FSM. 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 KAA12650 for ; Thu, 17 Jan 2002 10:27:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 51E26912E1; Thu, 17 Jan 2002 10:27:38 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D411912E2; Thu, 17 Jan 2002 10:27: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 EF4C5912E1 for ; Thu, 17 Jan 2002 10:27:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id BD99A5DDDA; Thu, 17 Jan 2002 10:27:36 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id A6A3C5DD9E for ; Thu, 17 Jan 2002 10:27:36 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0HFRD368104; Thu, 17 Jan 2002 10:27:13 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020117090856.025073e8@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 17 Jan 2002 10:27:12 -0500 To: ghankins@riverstonenet.com From: Susan Hares Subject: Re: bgp4-17 Cease subcode Cc: idr@merit.edu In-Reply-To: <20020116190851.C6038@riverstonenet.com> References: <114185201786.20020116111047@nexsi.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <20020115140711.GA23937@opentransit.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <114185201786.20020116111047@nexsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Greg: The real question is: 1) Was persistent BGP peer flapping a problem? 2) Do ISPs need to track why their peers are flapping? 3) How is it really used? If the feature is: - not needed - stay with 1st state machine - if needed, we'll find out why it is needed. Sue At 07:08 PM 1/16/2002 -0500, Greg Hankins wrote: >On Wed, Jan 16, 2002 at 11:10:47AM -0800, Alex Zinin wrote: > > Introduction of the IdleHold does change the FSM, > > and I thought we wanted the spec to reflect the current > > running code as much as possible. > >Agreed. Changing the FSM at this point doesn't seem like it is worth the >impact that this change would have on existing implementations, given that >there are other implementation-dependant ways of doing the same thing. > >A change in the FSM would make every BGP implementation and every piece of >documentation written on BGP outdated. I'm not saying that this shouldn't >be done if, there is a valid technical reason. > >Maybe the exponential backoff parts could be published as a separate draft >instead of including it in the base specification? > >Greg > >-- >Greg Hankins | Riverstone Networks, Inc. >Corporate Systems Engineering | 5200 Great America Parkway >http://www.riverstonenet.com/ | Santa Clara, CA 95054 >+1 404 434 0355 | +1 408 878 6500 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 KAA11618 for ; Thu, 17 Jan 2002 10:04:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A6D15912DF; Thu, 17 Jan 2002 10:04:06 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7236A912E1; Thu, 17 Jan 2002 10:04: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 1B43A912DF for ; Thu, 17 Jan 2002 10:04:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id F016A5DDCC; Thu, 17 Jan 2002 10:04:04 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id B30465DD9E for ; Thu, 17 Jan 2002 10:04:04 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA27363; Thu, 17 Jan 2002 10:04:03 -0500 (EST) Date: Thu, 17 Jan 2002 10:04:03 -0500 (EST) From: Russ White Reply-To: Russ White To: Susan Hares Cc: idr@merit.edu Subject: Re: Fwd: IPv6 Router ID draft In-Reply-To: <5.0.0.25.0.20020117095538.045501d0@mail.nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk You'd have to ask, wouldn't you? :-) We can't do ipv6 only as far as I know at this point, so ipv4 has to be configured/etc. Perhaps an informational would be better than an bcp, since there doesn't seem to be a good number of implementations of ipv6 only speakers (?), so while the issue is interesting and useful, there isn't any 'best practice' at this point? Russ On Thu, 17 Jan 2002, Susan Hares wrote: > Russ: > > Thank you for your vote on this matter. Can you tell > what your implementations does for Router-ID for IP v6 networks? > > Sue Hares > > > At 09:11 AM 1/17/2002 -0500, Russ White wrote: > > >I don't see any reason not to make it a working group BCP > >doc.... > > > >Russ > > > >On Thu, 17 Jan 2002, Susan Hares wrote: > > > > > > > > In Dec 13th IETF meeting (IETF 52), this draft was > > > presented as a BCP draft for IP v6. Should this > > > draft be a working group draft? A discussion period > > > for this will last for 2 weeks, and close on 1/31/02. > > > > > > The Minutes and presentations are available at: > > > > > > http://www.nexthop.com/standards/ietf_proceedings/01dec/idrwg-01dec.shtml > > > > > > > > > Please make your comments on this becoming a working group > > > draft destined to be a Best Common Practice document. > > > > > > > > > Sue Hares > > > > > > -------------------------- > > > > > > >I just published draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt > > > >and I would like to request this working group to consider it as > > > >a wg item candidate for BCP. > > > > > > > > - Alain. > > > > > > > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > > > >directories. > > > > > > > > > > > > Title : BGP4 router ID for IPv6 only routers > > > > Author(s) : F. Dupont, A. Durand > > > > Filename : > > > >draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt > > > > Pages : 3 > > > > Date : 15-Jan-02 > > > > > > > >BGP4 [1] uses a 32 bit field to identify router (the so called > > > >'router-IDs'). In IPv4 domain, an IPv4 address of the router > > > >is typically used in this field. > > > >In an IPv6 routing domain, routers may very well not have any IPv4 > > > >Addresses. This document provides a simple way to form a globally > > > >Unique ID in such a case. > > > > > > > >A URL for this Internet-Draft is: > > > >http://www.ietf.org/internet-drafts/draft-dupont-durand-idr-ipv6-bgp-ro > > uterid-01.txt > > > > > > > > > >_____________________________ > >riw@cisco.com <>< Grace Alone > > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA11453 for ; Thu, 17 Jan 2002 09:57:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2CF67912DC; Thu, 17 Jan 2002 09:57:24 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE800912DD; Thu, 17 Jan 2002 09:57: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 CC609912DC for ; Thu, 17 Jan 2002 09:57:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9DF2D5DDCC; Thu, 17 Jan 2002 09:57:22 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 8648C5DD9E for ; Thu, 17 Jan 2002 09:57:22 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0HEv3367071; Thu, 17 Jan 2002 09:57:04 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020117095538.045501d0@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 17 Jan 2002 09:57:01 -0500 To: Russ White From: Susan Hares Subject: Re: Fwd: IPv6 Router ID draft Cc: Susan Hares , idr@merit.edu In-Reply-To: References: <5.0.0.25.0.20020116180150.040177c0@mail.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Russ: Thank you for your vote on this matter. Can you tell what your implementations does for Router-ID for IP v6 networks? Sue Hares At 09:11 AM 1/17/2002 -0500, Russ White wrote: >I don't see any reason not to make it a working group BCP >doc.... > >Russ > >On Thu, 17 Jan 2002, Susan Hares wrote: > > > > > In Dec 13th IETF meeting (IETF 52), this draft was > > presented as a BCP draft for IP v6. Should this > > draft be a working group draft? A discussion period > > for this will last for 2 weeks, and close on 1/31/02. > > > > The Minutes and presentations are available at: > > > > http://www.nexthop.com/standards/ietf_proceedings/01dec/idrwg-01dec.shtml > > > > > > Please make your comments on this becoming a working group > > draft destined to be a Best Common Practice document. > > > > > > Sue Hares > > > > -------------------------- > > > > >I just published draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt > > >and I would like to request this working group to consider it as > > >a wg item candidate for BCP. > > > > > > - Alain. > > > > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > > >directories. > > > > > > > > > Title : BGP4 router ID for IPv6 only routers > > > Author(s) : F. Dupont, A. Durand > > > Filename : > > >draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt > > > Pages : 3 > > > Date : 15-Jan-02 > > > > > >BGP4 [1] uses a 32 bit field to identify router (the so called > > >'router-IDs'). In IPv4 domain, an IPv4 address of the router > > >is typically used in this field. > > >In an IPv6 routing domain, routers may very well not have any IPv4 > > >Addresses. This document provides a simple way to form a globally > > >Unique ID in such a case. > > > > > >A URL for this Internet-Draft is: > > >http://www.ietf.org/internet-drafts/draft-dupont-durand-idr-ipv6-bgp-ro > uterid-01.txt > > > > > >_____________________________ >riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA11255 for ; Thu, 17 Jan 2002 09:49:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2055E912E0; Thu, 17 Jan 2002 09:48:41 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B9E3912DD; Thu, 17 Jan 2002 09:48: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 CE1DF912DF for ; Thu, 17 Jan 2002 09:48:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id A061E5DDC3; Thu, 17 Jan 2002 09:48:35 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 891BC5DD9E for ; Thu, 17 Jan 2002 09:48:35 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0HEmG366830; Thu, 17 Jan 2002 09:48:16 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0HEmHY20573; Thu, 17 Jan 2002 09:48:17 -0500 (EST) Date: Thu, 17 Jan 2002 09:48:16 -0500 From: Jeffrey Haas To: Manav Bhatia Cc: idr@merit.edu Subject: Re: Maximum Prefix Limit Message-ID: <20020117094816.A20541@nexthop.com> References: <03b001c19e4e$aa86e750$b4036c6b@Manav> <20020116103528.A18433@nexthop.com> <059c01c19f14$91b1de80$b4036c6b@Manav> <20020117082940.A20374@nexthop.com> <014501c19f5c$5c8481c0$b4036c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <014501c19f5c$5c8481c0$b4036c6b@Manav>; from mnvbhatia@yahoo.com on Thu, Jan 17, 2002 at 07:09:15PM +0530 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Thu, Jan 17, 2002 at 07:09:15PM +0530, Manav Bhatia wrote: > Does it mean that the next time the session comes up there is no > ipv4/multicast capability supported? Once again, this is implementation > specific and we could work both ways. Exactly. But the MIB just needs to provide the appropriate ability to cover both situations. Just to postulate a vendor-specific for-example, Cisco scopes many of their commands under an address-family scope. If prefix limits were setable from the scope rather than globally (don't know if they are, don't feel like diving throught the TAC to figure it out), then the MIB needs to support it. Even if they don't now, they may in the future. > The session comes up after idle timer > hoping that the sys admin would have looked into the matter OR we dont > support ipv4/multicast (or which ever SAFI limit exceeded). Vendor dependant. Allowing a router to be used for transport of some AFI/SAFI which is stable may be reasonable while yet protecting the rest of the network from an "unstable" variation. > 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 JAA10405 for ; Thu, 17 Jan 2002 09:12:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C3E25912D7; Thu, 17 Jan 2002 09:11:36 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B400912D9; Thu, 17 Jan 2002 09:11: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 1FFCB912D7 for ; Thu, 17 Jan 2002 09:11:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id EB6675DDDD; Thu, 17 Jan 2002 09:11:34 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 7F64E5DDDA for ; Thu, 17 Jan 2002 09:11:34 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA21313; Thu, 17 Jan 2002 09:11:33 -0500 (EST) Date: Thu, 17 Jan 2002 09:11:33 -0500 (EST) From: Russ White Reply-To: Russ White To: Susan Hares Cc: idr@merit.edu Subject: Re: Fwd: IPv6 Router ID draft In-Reply-To: <5.0.0.25.0.20020116180150.040177c0@mail.nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk I don't see any reason not to make it a working group BCP doc.... Russ On Thu, 17 Jan 2002, Susan Hares wrote: > > In Dec 13th IETF meeting (IETF 52), this draft was > presented as a BCP draft for IP v6. Should this > draft be a working group draft? A discussion period > for this will last for 2 weeks, and close on 1/31/02. > > The Minutes and presentations are available at: > > http://www.nexthop.com/standards/ietf_proceedings/01dec/idrwg-01dec.shtml > > > Please make your comments on this becoming a working group > draft destined to be a Best Common Practice document. > > > Sue Hares > > -------------------------- > > >I just published draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt > >and I would like to request this working group to consider it as > >a wg item candidate for BCP. > > > > - Alain. > > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : BGP4 router ID for IPv6 only routers > > Author(s) : F. Dupont, A. Durand > > Filename : > >draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt > > Pages : 3 > > Date : 15-Jan-02 > > > >BGP4 [1] uses a 32 bit field to identify router (the so called > >'router-IDs'). In IPv4 domain, an IPv4 address of the router > >is typically used in this field. > >In an IPv6 routing domain, routers may very well not have any IPv4 > >Addresses. This document provides a simple way to form a globally > >Unique ID in such a case. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt > > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA10226 for ; Thu, 17 Jan 2002 09:06:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 476B3912D6; Thu, 17 Jan 2002 09:06:02 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10E04912D7; Thu, 17 Jan 2002 09:06: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 E8DC1912D6 for ; Thu, 17 Jan 2002 09:06:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id C9CAD5DDDA; Thu, 17 Jan 2002 09:06:00 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id B2DCC5DD9E for ; Thu, 17 Jan 2002 09:06:00 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0HE5i365494 for ; Thu, 17 Jan 2002 09:05:44 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020116180150.040177c0@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 17 Jan 2002 09:05:43 -0500 To: idr@merit.edu From: Susan Hares Subject: Fwd: IPv6 Router ID draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk In Dec 13th IETF meeting (IETF 52), this draft was presented as a BCP draft for IP v6. Should this draft be a working group draft? A discussion period for this will last for 2 weeks, and close on 1/31/02. The Minutes and presentations are available at: http://www.nexthop.com/standards/ietf_proceedings/01dec/idrwg-01dec.shtml Please make your comments on this becoming a working group draft destined to be a Best Common Practice document. Sue Hares -------------------------- >I just published draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt >and I would like to request this working group to consider it as >a wg item candidate for BCP. > > - Alain. > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : BGP4 router ID for IPv6 only routers > Author(s) : F. Dupont, A. Durand > Filename : >draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt > Pages : 3 > Date : 15-Jan-02 > >BGP4 [1] uses a 32 bit field to identify router (the so called >'router-IDs'). In IPv4 domain, an IPv4 address of the router >is typically used in this field. >In an IPv6 routing domain, routers may very well not have any IPv4 >Addresses. This document provides a simple way to form a globally >Unique ID in such a case. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt 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 JAA10130 for ; Thu, 17 Jan 2002 09:03:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 41D28912D5; Thu, 17 Jan 2002 09:03:06 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D458912D6; Thu, 17 Jan 2002 09:03:05 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C8E88912D5 for ; Thu, 17 Jan 2002 09:03:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id ABF095DDDA; Thu, 17 Jan 2002 09:03:04 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 91B1D5DD9E for ; Thu, 17 Jan 2002 09:03:04 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0HE2b365387; Thu, 17 Jan 2002 09:02:37 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020117085203.0448ce08@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 17 Jan 2002 09:02:36 -0500 To: Alex Zinin From: Susan Hares Subject: Re: bgp4-17 Cease subcode Cc: Susan Hares , Kunihiro Ishiguro , Vincent Gillet , Yakov Rekhter , Jeffrey Haas , In-Reply-To: <114185201786.20020116111047@nexsi.com> References: <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <20020115140711.GA23937@opentransit.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Alex: I think we need to query the people who operate the network about the problem this text was trying to solve. If the problem is still important, the problem will guide us in determining how this should be solved. The problem definition that the specification hints at is: a) automatic restarts of bgp sessions were being enabled on certain routers, b) the repeated OPENs were causing problems, c) People wanted to "recommend" (a strong word, but not as strong as must), it must have been important. If it is important, then is it important that all routers back off in the same way. The earlier specification wording would suggest that to be true. If not, it is not an inter-operability issue. If it is important, then it is important to know when your routers are in "back-off" state to operate the network. At this time, I'd like to hear from anyone who uses this function or had this problem. Sue At 11:10 AM 1/16/2002 -0800, Alex Zinin wrote: >Sue, > > Introduction of the IdleHold does change the FSM, > and I thought we wanted the spec to reflect the current > running code as much as possible. > > I agree with Russ and Ishi---the new state does not > seem to be necessary, instead it could be as easy > as holding the session in Idle and giving clue on > how to make the delay exponential. I don't think > there's an interoperability issue if people decide > to keep the session in Idle using different internal > mechanisms. > Regards, > >-- >Alex Zinin > >Wednesday, January 16, 2002, 6:04:36 AM, Susan Hares wrote: > > > Kunihiro: > > > We are not changing the FSM so I would be surprised if the change > > was anything but modest. Usually specifications with "no big" deal get > > interpreted differently. Inter-operable code means you tie down the > details. > > > The comment was on the clarity of the specification. > > > If you have a specific comment on the text of the state machine, > > can you propose the concerns you have as a revision to the text. > > > Sue > > > PS -- I just love last call on a draft... It's when > > everyone finally reads a new section ;-)... > > > > At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote: > >> >> > Is the expoential backoff in the FSM in current implementations? > >> >> > >> >> I guess we are going to find this out as part of the implementation > >> >> report. And if it is not in (at least two) current implementations, > >> >> we'll take it out of the text. > >> > > >> >I implemented Cease subcode in zebra-0.92a but not exponential backoff. > >> >I checked that new subcode does not put other BGP stack in trouble > >> >(checked Cisco and Juniper). > >> > >>First of all, sorry for talking about specific implementation. In > >>Zebra implementation we've implemented Cease subcode. The code is in > >>CVS repository. I'll prepare a release version for that. > >> > >>And also we've implemented exponetial backoff. It is done without > >>introducing new FSM status. It is not a big deal. Just check a flag > >>in a few functions. > > > >>Exponential backoff is a good feature. I can't understand why it > >>require change to FSM. 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 IAA09851 for ; Thu, 17 Jan 2002 08:52:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EAF34912D3; Thu, 17 Jan 2002 08:51:47 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B23A5912D4; Thu, 17 Jan 2002 08:51: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 8C10C912D3 for ; Thu, 17 Jan 2002 08:51:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6043D5DDDA; Thu, 17 Jan 2002 08:51:46 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 45BFF5DD9E for ; Thu, 17 Jan 2002 08:51:46 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0HDpb365074; Thu, 17 Jan 2002 08:51:37 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020117083423.0252ef28@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 17 Jan 2002 08:51:35 -0500 To: Alex Zinin , randy Bush From: Susan Hares Subject: Re: bgp4-17 Cease subcode Cc: idr@merit.edu In-Reply-To: <114185201786.20020116111047@nexsi.com> References: <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <20020115140711.GA23937@opentransit.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Alex and Randy: Let's go back to first principles here on the FSM? 1st) The original text is below from draft-12. This explanation gives "flag" that has implications for the full state machine. The definition of state machines that Alex proposes, is all inputs and all actions are determined by state machine in clear text. 2nd) Is the bug real? The text was fixing a " persistent bgp flapping" bug. According to the text there is a state within a state with fairly vague descriptions. The second question belongs to Randy, since he wears 2 hats (Operations and Routing temp AD), was this a real problem? Has it gone away? 1) At least one routing vendor doesn't implement it [cisco] and I know this vendor is utilized in BGP peering sessions in the network. 2) What was the operational concern this text implies? If there is no operational issue and no operational usage, return to the original FSM text and out the comments on "hold down." So, Randy and all other operators - Is the problem it describes real? Does anyone need it? Let's answer that question first. Sue Hares ---------------------- If a BGP speaker detects an error, it shuts down the connection and changes its state to Idle. Getting out of the Idle state requires generation of the Start event. If such an event is generated automatically, then persistent BGP errors may result in persistent flapping of the speaker. To avoid such a condition it is recommended that Start events should not be generated immediately for a peer that was previously transitioned to Idle due to an error. For a peer that was previously transitioned to Idle due to an error, the time Expiration Date July 2001 [Page 31] RFC DRAFT January 2001 between consecutive generation of Start events, if such events are generated automatically, shall exponentially increase. The value of the initial timer shall be 60 seconds. The time shall be doubled for each consecutive retry. Any other event received in the Idle state is ignored. At 11:10 AM 1/16/2002 -0800, you wrote: >Sue, > > Introduction of the IdleHold does change the FSM, > and I thought we wanted the spec to reflect the current > running code as much as possible. > > I agree with Russ and Ishi---the new state does not > seem to be necessary, instead it could be as easy > as holding the session in Idle and giving clue on > how to make the delay exponential. I don't think > there's an interoperability issue if people decide > to keep the session in Idle using different internal > mechanisms. > > Regards, > >-- >Alex Zinin > >Wednesday, January 16, 2002, 6:04:36 AM, Susan Hares wrote: > > > Kunihiro: > > > We are not changing the FSM so I would be surprised if the change > > was anything but modest. Usually specifications with "no big" deal get > > interpreted differently. Inter-operable code means you tie down the > details. > > > The comment was on the clarity of the specification. > > > If you have a specific comment on the text of the state machine, > > can you propose the concerns you have as a revision to the text. > > > Sue > > > PS -- I just love last call on a draft... It's when > > everyone finally reads a new section ;-)... > > > > At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote: > >> >> > Is the expoential backoff in the FSM in current implementations? > >> >> > >> >> I guess we are going to find this out as part of the implementation > >> >> report. And if it is not in (at least two) current implementations, > >> >> we'll take it out of the text. > >> > > >> >I implemented Cease subcode in zebra-0.92a but not exponential backoff. > >> >I checked that new subcode does not put other BGP stack in trouble > >> >(checked Cisco and Juniper). > >> > >>First of all, sorry for talking about specific implementation. In > >>Zebra implementation we've implemented Cease subcode. The code is in > >>CVS repository. I'll prepare a release version for that. > >> > >>And also we've implemented exponetial backoff. It is done without > >>introducing new FSM status. It is not a big deal. Just check a flag > >>in a few functions. > > > >>Exponential backoff is a good feature. I can't understand why it > >>require change to FSM. Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA09562 for ; Thu, 17 Jan 2002 08:38:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 71048912D1; Thu, 17 Jan 2002 08:34:49 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A2D1912D2; Thu, 17 Jan 2002 08:34: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 D6239912D1 for ; Thu, 17 Jan 2002 08:34:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id BD6C95DDDA; Thu, 17 Jan 2002 08:34:46 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 79F785DD9E for ; Thu, 17 Jan 2002 08:34:46 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0HDYF364556; Thu, 17 Jan 2002 08:34:15 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0HDYBc20394; Thu, 17 Jan 2002 08:34:11 -0500 (EST) Date: Thu, 17 Jan 2002 08:34:11 -0500 From: Jeffrey Haas To: claus.bauer@tellabs.com Cc: idr@merit.edu Subject: Re: graceful restart Message-ID: <20020117083411.B20374@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from claus.bauer@tellabs.com on Wed, Jan 16, 2002 at 07:17:08PM -0600 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Wed, Jan 16, 2002 at 07:17:08PM -0600, claus.bauer@tellabs.com wrote: > a question on draft-ietf-idr-restart-01.txt. Why were exactly 12 bits > chosen for the "Restart time in seconds"? What failures are supposed to > be repaired within 2^12 seconds ? How shall one proceed with failures > that need more time to be repaired ? If you need more than 60 minutes to restart your peering session something is horribly wrong anyway. ANd I'd seriously hope that the stale routes don't stay stale that long... > Claus -- 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 IAA09557 for ; Thu, 17 Jan 2002 08:38:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 320EA912D2; Thu, 17 Jan 2002 08:36:41 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3585912D7; Thu, 17 Jan 2002 08:36: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 8A098912D2 for ; Thu, 17 Jan 2002 08:36:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6AF105DDDA; Thu, 17 Jan 2002 08:36:36 -0500 (EST) Delivered-To: idr@merit.edu Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by segue.merit.edu (Postfix) with SMTP id E15085DD9E for ; Thu, 17 Jan 2002 08:36:35 -0500 (EST) Received: from leased-200-20-226.bng.vsnl.net.in (HELO Manav) (203.200.20.226) by smtp.mail.vip.sc5.yahoo.com with SMTP; 17 Jan 2002 13:36:34 -0000 Message-ID: <014501c19f5c$5c8481c0$b4036c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "Jeffrey Haas" Cc: References: <03b001c19e4e$aa86e750$b4036c6b@Manav> <20020116103528.A18433@nexthop.com> <059c01c19f14$91b1de80$b4036c6b@Manav> <20020117082940.A20374@nexthop.com> Subject: Re: Maximum Prefix Limit Date: Thu, 17 Jan 2002 19:09:15 +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 | > The session in any case will be torn even if the threshold for a single | > SAFI crosses. Does it make much sense in saying that," i will accept x SAFI | > 1 routes, y SAFI 2 routes, etc"? | | No, but it may make sense to say "I'll accept X ipv4/unicast routes, but | if I get > Y ipv4/multicast routes, drop the peer session, potentially | removing the ipv4/multicast capability". Does it mean that the next time the session comes up there is no ipv4/multicast capability supported? Once again, this is implementation specific and we could work both ways. The session comes up after idle timer hoping that the sys admin would have looked into the matter OR we dont support ipv4/multicast (or which ever SAFI limit exceeded). Regards, Manav _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.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 IAA09337 for ; Thu, 17 Jan 2002 08:31:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 651069123F; Thu, 17 Jan 2002 08:30:19 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B351912D0; Thu, 17 Jan 2002 08:30:19 -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 7BB7D9123F for ; Thu, 17 Jan 2002 08:30:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 755715DDDA; Thu, 17 Jan 2002 08:30:12 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 06F4D5DD9E for ; Thu, 17 Jan 2002 08:30:12 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0HDTd364401; Thu, 17 Jan 2002 08:29:39 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0HDTeJ20380; Thu, 17 Jan 2002 08:29:40 -0500 (EST) Date: Thu, 17 Jan 2002 08:29:40 -0500 From: Jeffrey Haas To: Manav Bhatia Cc: idr@merit.edu Subject: Re: Maximum Prefix Limit Message-ID: <20020117082940.A20374@nexthop.com> References: <03b001c19e4e$aa86e750$b4036c6b@Manav> <20020116103528.A18433@nexthop.com> <059c01c19f14$91b1de80$b4036c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <059c01c19f14$91b1de80$b4036c6b@Manav>; from mnvbhatia@yahoo.com on Thu, Jan 17, 2002 at 10:35:23AM +0530 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Thu, Jan 17, 2002 at 10:35:23AM +0530, Manav Bhatia wrote: > Does it really make sense to have seperate counters for each SAFI? The MIB needs to allow for implementations tomake that choice. A per AFI/SAFI counter may be reasonable. A per AFI counter is also reasonable. > The session in any case will be torn even if the threshold for a single > SAFI crosses. Does it make much sense in saying that," i will accept x SAFI > 1 routes, y SAFI 2 routes, etc"? No, but it may make sense to say "I'll accept X ipv4/unicast routes, but if I get > Y ipv4/multicast routes, drop the peer session, potentially removing the ipv4/multicast capability". > 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 AAA27823 for ; Thu, 17 Jan 2002 00:04:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2ECCE912CC; Thu, 17 Jan 2002 00:04:06 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC5ED912CD; Thu, 17 Jan 2002 00:04:05 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3D2C6912CC for ; Thu, 17 Jan 2002 00:03:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 09B185DDCE; Thu, 17 Jan 2002 00:03:24 -0500 (EST) Delivered-To: idr@merit.edu Received: from smtp018.mail.yahoo.com (unknown [216.136.174.115]) by segue.merit.edu (Postfix) with SMTP id 708275DDA8 for ; Thu, 17 Jan 2002 00:03:23 -0500 (EST) Received: from leased-200-20-226.bng.vsnl.net.in (HELO firewall) (203.200.20.226) by smtp.mail.vip.sc5.yahoo.com with SMTP; 17 Jan 2002 05:02:42 -0000 Message-ID: <059c01c19f14$91b1de80$b4036c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "Jeffrey Haas" Cc: References: <03b001c19e4e$aa86e750$b4036c6b@Manav> <20020116103528.A18433@nexthop.com> Subject: Re: Maximum Prefix Limit Date: Thu, 17 Jan 2002 10:35:23 +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 | > - Should there be counters for individual SAFI or should there be a | > consolidated one for the entire AFI? | | Those of us working on the v2MIB would like to hear opinions on this! Does it really make sense to have seperate counters for each SAFI? The session in any case will be torn even if the threshold for a single SAFI crosses. Does it make much sense in saying that," i will accept x SAFI 1 routes, y SAFI 2 routes, etc"? Rather than this there should be a single max limit for each AFI family which when violated should tear down the BGP session. Regards, Manav _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.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 WAA25032 for ; Wed, 16 Jan 2002 22:01:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 882F9912C8; Wed, 16 Jan 2002 22:00:54 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 539DC912C9; Wed, 16 Jan 2002 22:00:54 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D2DE0912C8 for ; Wed, 16 Jan 2002 22:00:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id AF9DA5DDD6; Wed, 16 Jan 2002 22:00:51 -0500 (EST) Delivered-To: idr@merit.edu Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by segue.merit.edu (Postfix) with ESMTP id CD2AD5DDD3 for ; Wed, 16 Jan 2002 22:00:50 -0500 (EST) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id TAA29117; Wed, 16 Jan 2002 19:00:45 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 19:00:45 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01A9905B@avalon.pluris.com> From: Vivek Menezes To: "'Enke Chen'" , Vivek Menezes Cc: "'claus.bauer@tellabs.com'" , idr@merit.edu Subject: RE: graceful restart Date: Wed, 16 Jan 2002 19:00:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk yeah I guess milliseconds makes no sense especially considering that the keepalive timers are in seconds. Do you think adding in my suggestion on the restart bit makes sense though. Vivek. > -----Original Message----- > From: Enke Chen [mailto:enke@redback.com] > Sent: Wednesday, January 16, 2002 5:43 PM > To: Vivek Menezes > Cc: 'claus.bauer@tellabs.com'; idr@merit.edu > Subject: Re: graceful restart > > > > Message-ID: > <17C81AD1F1FED411991E006008F6D1CA01A9905A@avalon.pluris.com> > > From: Vivek Menezes > > To: "'claus.bauer@tellabs.com'" , > > idr@merit.edu > > Subject: RE: graceful restart > > Date: Wed, 16 Jan 2002 17:27:14 -0800 > > MIME-Version: 1.0 > > > > I think 28 bits makes more sense. Its better that the time were in > > milliseconds. In the future > > routers might be able to restart in milliseconds :-) > > Does millisecond make sense considering all other timers in > the BGP spec > are in seconds and even minutes? -- Enke > > > I sent this message a while ago. I havent heard from the authors. > > > > in the Restart Flags section in section 5 of the restart > draft it would be > > better if we added > > > > " when the receiving system has not restarted and it > receives the restart > > flag with the bit not set it should not wait for the > end-of-rib marker > > from the speaker before advertising routing information to > the speaker" or > > equivalently > > "if a system doesnt restart it should ignore the restart > flag for the > > purposes of advertising routes" > > > > I think its better if we made it clear. > > > > Also the restart time in seconds could be changed to a 28 > bit time in > > milliseconds. > > > > Vivek. > > > > > -----Original Message----- > > > From: claus.bauer@tellabs.com [mailto:claus.bauer@tellabs.com] > > > Sent: Wednesday, January 16, 2002 5:17 PM > > > To: idr@merit.edu > > > Subject: graceful restart > > > > > > > > > Hi > > > > > > a question on draft-ietf-idr-restart-01.txt. Why were > > > exactly 12 bits > > > chosen for the "Restart time in seconds"? What failures are > > > supposed to > > > be repaired within 2^12 seconds ? How shall one proceed > with failures > > > that need more time to be repaired ? > > > > > > Claus > > > > > > > > > > > > > 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 VAA24820 for ; Wed, 16 Jan 2002 21:55:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8DEB5912C6; Wed, 16 Jan 2002 21:55:04 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5745C912C7; Wed, 16 Jan 2002 21: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 70125912C6 for ; Wed, 16 Jan 2002 21:55:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 573665DDB7; Wed, 16 Jan 2002 21:55:03 -0500 (EST) Delivered-To: idr@merit.edu Received: from roam.psg.com (unknown [147.28.4.2]) by segue.merit.edu (Postfix) with ESMTP id C78C65DD8E for ; Wed, 16 Jan 2002 21:55:02 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16R2hZ-00066N-00; Wed, 16 Jan 2002 18:54:53 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin , idr@merit.edu Subject: Re: bgp4-17 Cease subcode References: <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <114185201786.20020116111047@nexsi.com> Message-Id: Date: Wed, 16 Jan 2002 18:54:53 -0800 Sender: owner-idr@merit.edu Precedence: bulk > if the introduction of idlehold makes life clearer for implementors, yet > it changes the fsm but not in incompatible ways (i.e. old would interop > with new and wire looks the same, as jeff asserts. maybe sufficient > sushi could convince an area director not to ding the progress status of > the document. it looks to be a real change. my bad. typed on airplane and did not check fsa. randy 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 VAA24785 for ; Wed, 16 Jan 2002 21:54:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 291BE912C5; Wed, 16 Jan 2002 21:53:22 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F0CB9912C6; Wed, 16 Jan 2002 21:53:21 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 092D6912C5 for ; Wed, 16 Jan 2002 21:53:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id E1B365DDB7; Wed, 16 Jan 2002 21:53:20 -0500 (EST) Delivered-To: idr@merit.edu Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id B6D045DD8E for ; Wed, 16 Jan 2002 21:53:20 -0500 (EST) Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id B6F5D3F70; Wed, 16 Jan 2002 18:56:08 -0800 (PST) Received: from khonsu.sw.nexsi.com ([172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id SAA13422; Wed, 16 Jan 2002 18:52:26 -0800 Date: Wed, 16 Jan 2002 18:52:26 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <86212899232.20020116185226@nexsi.com> To: Randy Bush Cc: idr@merit.edu Subject: Re: bgp4-17 Cease subcode In-Reply-To: References: <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <114185201786.20020116111047@nexsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Randy, > if the introduction of idlehold makes life clearer for implementors, This is what I'm not sure about... Controlling [existing] Start event generation that lets the FSM out of the [existing] Idle state seems easier than introducing, documenting, coding, and checking of a new one... Alex. > yet > it changes the fsm but not in incompatible ways (i.e. old would interop > with new and wire looks the same, as jeff asserts. maybe sufficient > sushi could convince an area director not to ding the progress status of > the document. > randy 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 VAA24655 for ; Wed, 16 Jan 2002 21:46:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B1078912C4; Wed, 16 Jan 2002 21:45:35 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 82838912C5; Wed, 16 Jan 2002 21:45: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 78C36912C4 for ; Wed, 16 Jan 2002 21:45:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4BDF25DDB9; Wed, 16 Jan 2002 21:45:34 -0500 (EST) Delivered-To: idr@merit.edu Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id 1B7835DD8E for ; Wed, 16 Jan 2002 21:45:34 -0500 (EST) Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id 316FA3F6D; Wed, 16 Jan 2002 18:48:21 -0800 (PST) Received: from khonsu.sw.nexsi.com ([172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id SAA13301; Wed, 16 Jan 2002 18:44:44 -0800 Date: Wed, 16 Jan 2002 18:44:44 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <145212436838.20020116184444@nexsi.com> To: Kunihiro Ishiguro Cc: idr@merit.edu, Susan Hares Subject: Re: Comments on FSM In-Reply-To: References: <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <87advfjcqi.wl@vaio.zebra.org> <5.0.0.25.0.20020116181115.03ea46f8@mail.nexthop.com> <195204309992.20020116162916@nexsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Kunihiro, > Instead of IdleHold timer we should explicitly mention about Start > timer. It is already implicitly used in RFC1771. It is almost same > as IdleHold timer but hopefully does not have impact on current > implementation. Or just say that implementations may use internal mechanisms to generate the Start event and encourage people to implement exponential holddown. > We don't need Keep Idle flag. Instead of that just stop Start timer. > This mechanism can be used not only exponential backoff but also > administratively shutdown or maximum prefix overflow. So let's keep > it simple. Agreed. > In IdleHold state there is a description for local limit of > IdleHoldTimer. >> Upon entering the Idle Hold state, if the IdleHoldTimer exceeds >> the local limit the "Keep Idle" flag is set. > This should be clearly defined. For example StartTimer Ceiling. Not sure if we even need this. See above. > Difference between manual start and auto start is small. I'm not sure > separating Start event into Manual start event and Auto start event is > good idea or not. Yes, looks like it is the same event for FSM. If so, it should be one event with two ways of generation. > So my proposal is liek this. > Status : No new status > Timer : Start timer > Variable: StartTimer > StartTimer Ceiling > Connect Retry Count > (Possible addition > Event : Manual start > Auto start) > IMHO, this topic needs more discussion and clarification. >>Maybe the exponential backoff parts could be published as a separate draft >>instead of including it in the base specification? > I agrree with Greg. A separate draft for exponential back off make > sense. I think even we have a separate draft for exponential back > off, previous draft bgp4-16 FSM description still work fine with that. No strong opinion on this. If exponential back-off is optional and has been implemented in some implementations, I think it can stay in the main spec. Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA24619 for ; Wed, 16 Jan 2002 21:44:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9B9F591246; Wed, 16 Jan 2002 21:43:37 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 675CB912C4; Wed, 16 Jan 2002 21:43: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 7BB7591246 for ; Wed, 16 Jan 2002 21:43:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 03BB95DDA3; Wed, 16 Jan 2002 21:43:36 -0500 (EST) Delivered-To: idr@merit.edu Received: from roam.psg.com (unknown [147.28.4.2]) by segue.merit.edu (Postfix) with ESMTP id 5B4935DD8E for ; Wed, 16 Jan 2002 21:43:35 -0500 (EST) Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 16R19U-0005pQ-00; Wed, 16 Jan 2002 17:15:36 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: idr@merit.edu Subject: Re: bgp4-17 Cease subcode References: <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <114185201786.20020116111047@nexsi.com> Message-Id: Date: Wed, 16 Jan 2002 17:15:36 -0800 Sender: owner-idr@merit.edu Precedence: bulk > Introduction of the IdleHold does change the FSM, > and I thought we wanted the spec to reflect the current > running code as much as possible. > > I agree with Russ and Ishi---the new state does not > seem to be necessary, instead it could be as easy > as holding the session in Idle and giving clue on > how to make the delay exponential. I don't think > there's an interoperability issue if people decide > to keep the session in Idle using different internal > mechanisms. if the introduction of idlehold makes life clearer for implementors, yet it changes the fsm but not in incompatible ways (i.e. old would interop with new and wire looks the same, as jeff asserts. maybe sufficient sushi could convince an area director not to ding the progress status of the document. randy 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 UAA23295 for ; Wed, 16 Jan 2002 20:52:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B77E991245; Wed, 16 Jan 2002 20:52:30 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 833D1912C4; Wed, 16 Jan 2002 20:52: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 6AE6D91245 for ; Wed, 16 Jan 2002 20:52:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 457CD5DDB7; Wed, 16 Jan 2002 20:52:29 -0500 (EST) Delivered-To: idr@merit.edu Received: from titanium.zebra.org (unknown [209.11.132.18]) by segue.merit.edu (Postfix) with ESMTP id E32255DDA1 for ; Wed, 16 Jan 2002 20:52:28 -0500 (EST) Received: from titanium.zebra.org (IDENT:kunihiro@localhost [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id TAA00993; Wed, 16 Jan 2002 19:54:30 -0500 Date: Wed, 16 Jan 2002 16:54:30 -0800 Message-ID: From: Kunihiro Ishiguro To: Alex Zinin Cc: idr@merit.edu, Susan Hares Subject: Re: Comments on FSM In-Reply-To: <195204309992.20020116162916@nexsi.com> References: <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <87advfjcqi.wl@vaio.zebra.org> <5.0.0.25.0.20020116181115.03ea46f8@mail.nexthop.com> <195204309992.20020116162916@nexsi.com> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.1 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Thanks Alex. I've check bgp4-17 FSM. Below new items are added. Status : IdleHold Timer : IdleHold timer Variable: IdleHoldtimer IdleHoldtimer ceiling mentioned as "local limit" ConnectRetryCnt Event : Manual start Auto start Flag : Keep Idle Instead of IdleHold timer we should explicitly mention about Start timer. It is already implicitly used in RFC1771. It is almost same as IdleHold timer but hopefully does not have impact on current implementation. We don't need Keep Idle flag. Instead of that just stop Start timer. This mechanism can be used not only exponential backoff but also administratively shutdown or maximum prefix overflow. So let's keep it simple. In IdleHold state there is a description for local limit of IdleHoldTimer. > Upon entering the Idle Hold state, if the IdleHoldTimer exceeds > the local limit the "Keep Idle" flag is set. This should be clearly defined. For example StartTimer Ceiling. Difference between manual start and auto start is small. I'm not sure separating Start event into Manual start event and Auto start event is good idea or not. So my proposal is liek this. Status : No new status Timer : Start timer Variable: StartTimer StartTimer Ceiling Connect Retry Count (Possible addition Event : Manual start Auto start) IMHO, this topic needs more discussion and clarification. >Maybe the exponential backoff parts could be published as a separate draft >instead of including it in the base specification? I agrree with Greg. A separate draft for exponential back off make sense. I think even we have a separate draft for exponential back off, previous draft bgp4-16 FSM description still work fine with that. -- Kunihiro Ishiguro Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA23150 for ; Wed, 16 Jan 2002 20:44:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 959FA912C3; Wed, 16 Jan 2002 20:43:27 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F150912C4; Wed, 16 Jan 2002 20:43: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 5B4E5912C3 for ; Wed, 16 Jan 2002 20:43:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 378F85DDB7; Wed, 16 Jan 2002 20:43:26 -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 F09975DDA1 for ; Wed, 16 Jan 2002 20:43:25 -0500 (EST) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 705651DCC62; Wed, 16 Jan 2002 17:43:25 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 2F7A07E6C1; Wed, 16 Jan 2002 17:43:25 -0800 (PST) To: Vivek Menezes Cc: "'claus.bauer@tellabs.com'" , idr@merit.edu Subject: Re: graceful restart In-Reply-To: Message from Vivek Menezes of "Wed, 16 Jan 2002 17:27:14 PST." <17C81AD1F1FED411991E006008F6D1CA01A9905A@avalon.pluris.com> Date: Wed, 16 Jan 2002 17:43:24 -0800 From: Enke Chen Message-Id: <20020117014325.2F7A07E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk > Message-ID: <17C81AD1F1FED411991E006008F6D1CA01A9905A@avalon.pluris.com> > From: Vivek Menezes > To: "'claus.bauer@tellabs.com'" , > idr@merit.edu > Subject: RE: graceful restart > Date: Wed, 16 Jan 2002 17:27:14 -0800 > MIME-Version: 1.0 > > I think 28 bits makes more sense. Its better that the time were in > milliseconds. In the future > routers might be able to restart in milliseconds :-) Does millisecond make sense considering all other timers in the BGP spec are in seconds and even minutes? -- Enke > I sent this message a while ago. I havent heard from the authors. > > in the Restart Flags section in section 5 of the restart draft it would be > better if we added > > " when the receiving system has not restarted and it receives the restart > flag with the bit not set it should not wait for the end-of-rib marker > from the speaker before advertising routing information to the speaker" or > equivalently > "if a system doesnt restart it should ignore the restart flag for the > purposes of advertising routes" > > I think its better if we made it clear. > > Also the restart time in seconds could be changed to a 28 bit time in > milliseconds. > > Vivek. > > > -----Original Message----- > > From: claus.bauer@tellabs.com [mailto:claus.bauer@tellabs.com] > > Sent: Wednesday, January 16, 2002 5:17 PM > > To: idr@merit.edu > > Subject: graceful restart > > > > > > Hi > > > > a question on draft-ietf-idr-restart-01.txt. Why were > > exactly 12 bits > > chosen for the "Restart time in seconds"? What failures are > > supposed to > > be repaired within 2^12 seconds ? How shall one proceed with failures > > that need more time to be repaired ? > > > > Claus > > > > > > > > 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 UAA22773 for ; Wed, 16 Jan 2002 20:27:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 59451912C2; Wed, 16 Jan 2002 20:27:26 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22A00912C3; Wed, 16 Jan 2002 20:27: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 E055B912C2 for ; Wed, 16 Jan 2002 20:27:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id C07B25DDA1; Wed, 16 Jan 2002 20:27:24 -0500 (EST) Delivered-To: idr@merit.edu Received: from yarilo.pluris.com (yarilo.pluris.com [208.227.9.200]) by segue.merit.edu (Postfix) with ESMTP id 0CD9B5DD8E for ; Wed, 16 Jan 2002 20:27:24 -0500 (EST) Received: from avalon.pluris.com (avalon.pluris.com [172.16.50.49]) by yarilo.pluris.com (8.9.2/8.9.1) with ESMTP id RAA08098; Wed, 16 Jan 2002 17:27:15 -0800 (PST) Received: by avalon.pluris.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Jan 2002 17:27:15 -0800 Message-ID: <17C81AD1F1FED411991E006008F6D1CA01A9905A@avalon.pluris.com> From: Vivek Menezes To: "'claus.bauer@tellabs.com'" , idr@merit.edu Subject: RE: graceful restart Date: Wed, 16 Jan 2002 17:27:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-idr@merit.edu Precedence: bulk I think 28 bits makes more sense. Its better that the time were in milliseconds. In the future routers might be able to restart in milliseconds :-) I sent this message a while ago. I havent heard from the authors. in the Restart Flags section in section 5 of the restart draft it would be better if we added " when the receiving system has not restarted and it receives the restart flag with the bit not set it should not wait for the end-of-rib marker from the speaker before advertising routing information to the speaker" or equivalently "if a system doesnt restart it should ignore the restart flag for the purposes of advertising routes" I think its better if we made it clear. Also the restart time in seconds could be changed to a 28 bit time in milliseconds. Vivek. > -----Original Message----- > From: claus.bauer@tellabs.com [mailto:claus.bauer@tellabs.com] > Sent: Wednesday, January 16, 2002 5:17 PM > To: idr@merit.edu > Subject: graceful restart > > > Hi > > a question on draft-ietf-idr-restart-01.txt. Why were > exactly 12 bits > chosen for the "Restart time in seconds"? What failures are > supposed to > be repaired within 2^12 seconds ? How shall one proceed with failures > that need more time to be repaired ? > > Claus > > > > 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 UAA22394 for ; Wed, 16 Jan 2002 20:17:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ADFF0912C1; Wed, 16 Jan 2002 20:17:10 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7344A912C2; Wed, 16 Jan 2002 20:17: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 2B8DC912C1 for ; Wed, 16 Jan 2002 20:17:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 047AB5DDA1; Wed, 16 Jan 2002 20:17:09 -0500 (EST) Delivered-To: idr@merit.edu Received: from mx4.tellabs.com (mx4.tellabs.com [204.68.180.54]) by segue.merit.edu (Postfix) with ESMTP id D36985DD8E for ; Wed, 16 Jan 2002 20:17:08 -0500 (EST) Received: from mailw02.hq.tellabs.com (mailw02.bb.tellabs.com [138.111.51.101]) by mx4.tellabs.com (Mirapoint) with ESMTP id ACD16494; Wed, 16 Jan 2002 19:17:06 -0600 (CST) Received: from localhost (root@localhost) by mailw02.hq.tellabs.com with ESMTP (8.8.6 (PHNE_17190)/8.7.1) id TAA20082 for ; Wed, 16 Jan 2002 19:17:08 -0600 (CST) X-OpenMail-Hops: 1 Date: Wed, 16 Jan 2002 19:17:08 -0600 Message-Id: Subject: graceful restart MIME-Version: 1.0 From: claus.bauer@tellabs.com To: idr@merit.edu Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline ;Creation-Date="Wed, 16 Jan 2002 19:17:08 -0600" Sender: owner-idr@merit.edu Precedence: bulk Hi a question on draft-ietf-idr-restart-01.txt. Why were exactly 12 bits chosen for the "Restart time in seconds"? What failures are supposed to be repaired within 2^12 seconds ? How shall one proceed with failures that need more time to be repaired ? Claus 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 TAA21285 for ; Wed, 16 Jan 2002 19:35:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 16AC6912A5; Wed, 16 Jan 2002 19:35:08 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA781912C1; Wed, 16 Jan 2002 19:35: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 E6D17912A5 for ; Wed, 16 Jan 2002 19:35:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id CAA365DD9E; Wed, 16 Jan 2002 19:35:06 -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 90A055DD90 for ; Wed, 16 Jan 2002 19:35:06 -0500 (EST) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 2B8811531CB; Wed, 16 Jan 2002 16:35:06 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 00C1A7E6C1; Wed, 16 Jan 2002 16:35:06 -0800 (PST) To: yakov@juniper.net, skh@nexthop.com Cc: enke@redback.com, idr@merit.edu Subject: draft-chen-bgp-identifier-01.txt Date: Wed, 16 Jan 2002 16:35:05 -0800 From: Enke Chen Message-Id: <20020117003506.00C1A7E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Yakov and Sue: I would like to request this draft be accepted as an IDR WG document. Thank you in advance for your consideration. -- Enke ------- Forwarded Message Message-Id: <200201141539.KAA04412@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-chen-bgp-identifier-01.txt Date: Mon, 14 Jan 2002 10:39:16 -0500 Sender: nsyracus@cnri.reston.va.us - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : AS-wide Unique BGP Identifier for BGP-4 Author(s) : E. Chen, J. Yuan Filename : draft-chen-bgp-identifier-01.txt Pages : 4 Date : 11-Jan-02 To deal with situations where the current requirements for the BGP Identifier are not met, this document relaxes the definition of the BGP Identifier to be a 4-octet unsigned, non-zero integer, and relaxes the 'uniqueness' requirement so that only AS-wide uniqueness of the BGP Identifiers is required. These revisions to the base BGP specification does not introduce any backward compatibility issue. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-bgp-identifier-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-chen-bgp-identifier-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 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 TAA21219 for ; Wed, 16 Jan 2002 19:31:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 992ED912BE; Wed, 16 Jan 2002 19:30:10 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1FEFC912C2; Wed, 16 Jan 2002 19:30:09 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E2B5E912BE for ; Wed, 16 Jan 2002 19:30:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id E4C0A5DDA1; Wed, 16 Jan 2002 19:30:06 -0500 (EST) Delivered-To: idr@merit.edu Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id 0C95F5DDC6 for ; Wed, 16 Jan 2002 19:30:05 -0500 (EST) Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id A76F33F71; Wed, 16 Jan 2002 16:32:53 -0800 (PST) Received: from khonsu.sw.nexsi.com ([172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id QAA11382; Wed, 16 Jan 2002 16:29:16 -0800 Date: Wed, 16 Jan 2002 16:29:16 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <195204309992.20020116162916@nexsi.com> To: idr@merit.edu Cc: Susan Hares Subject: Comments on FSM In-Reply-To: <5.0.0.25.0.20020116181115.03ea46f8@mail.nexthop.com> References: <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <87advfjcqi.wl@vaio.zebra.org> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <5.0.0.25.0.20020116181115.03ea46f8@mail.nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-idr@merit.edu Precedence: bulk Sue, Some comments on the FSM text below. I constrained myself to mostly editorial changes, as I'd prefer to see the FSM description in a different form (the one I'm working on). Also, I think that the connection collision related issue brought by Dennis is still not addressed. Frankly, I'm not sure how well this can be addressed if the spec continues to treat competing transport connections for the same peer as separate BGP sessions and FSMs... Thanks, -- Alex Zinin General notes: - there should be a separate section describing all session attributes (such as timers and flags) involved in FSM operation. - there should be a separate subsection where all events would be formally defined and named. Defined names should then be used in the text. - there should be a section specifically describing processing of incoming transport connections - I think IdleHold should go. (stet'ed the text for now) - Processing of manual Stop in Established lacked a NOTIFICATION message. - Thorough check of FSM text correctness is hard because events are not documented and one would need to parse the text and formalize the description to do so, i.e., pretty much what I'm doing with the other representation. - I think we need a state transition diagram (not table) in the text for better visualization (I'm going to have one). This won't be possible without proper event documentation. - NOTIFICATION codes and subcodes need verification. (some changes are in the text.) - Sessions "killed" due to connection collision should not go to Idle, but be destroyed. (Not addressed in the text below.) Below is corrected text of the section . You'll be able to do a "diff -u" or something against the original one to see line-by-line changes. 8. BGP Finite State machine. This section specifies BGP operation in terms of a Finite State Machine (FSM) of a peering session. Following is a brief summary and overview of BGP operations by state as determined by this FSM. /* a "brief summary" of FSM? There should be a complete one */ An instance of an FSM is created by a BGP speaker for each configured peer. It may also be created dynamically when an incoming transport connection is reported, there's no matching configured peer and the speaker is configured to accept such connections. FSMs created for configured peers are initially put in the Idle state. See section XXX for more information on incoming transport connection processing. Each FSM state with corresponding event processing rules is described below. Idle state: This is the initial state of the FSM. This state is also used to keep BGP sessions in the inactive state when necessary. In this state BGP refuses all incoming BGP connections from the peer. No resources are allocated to the session. /* Here, I assume that the IdleHold will be removed and * Idle be used for session hold down */ A manual start event is a start event initiated by an operator to initiate BGP session establishment. An automatic start event is a start event generated by the system. /* The above should go to the event description section */ In response to a Start event (manual or automatic), the following steps are performed: - Allocate resources for the session, - Start the ConnectRetry timer (see note below), - Initiate an outbound transport connection to the peer, - Start listening for a connection that may be initiated by the peer, - Transition to Connect. NOTE: The exact value of the ConnectRetry timer is a local matter, but it should be sufficiently large to allow TCP initialization. Any other event received in the IDLE state, is ignored. /* I have a problem with this. Until all events are properly * documented, saying "any other event" is inappropriate. */ Expiration Date July 2002 [Page 33] RFC DRAFT January 2002 IdleHold state: /* I think this state should go and Idle be used for the same * purpose with local mechanisms used to control how long * the session stays there... I'm skipping this state... */ The IdleHold state keeps the system in "Idle" mode until a certain time period has passed or an operator intervenes to manually restart the connection. This "IdleHold timeout" prevents persistent flapping of a BGP peering session. Upon entering the Idle Hold state, if the IdleHoldTimer exceeds the local limit the "Keep Idle" flag is set. Upon receiving a Manual start, the local system: - clears the IdleHoldtimer, - clears "keep Idle" flag - initializes all BGP resources, - starts the ConnectRetry timer, - initiates a transport connection to the other BGP peer, - listens for a connection that may be initiated by the remote BGPPeer, and - changes its state to connect. Upon receiving a IdleHoldtimer expired event, the local system checks to see that the Keep Idle flag is set. If the Keep Idle flag is set, the system stays in the "Idle Hold" state. If the Keep Idle flag is not set, the local system: - clears the IdleHoldtimer, - and transitions the state to Idle. Getting out of the IdleHoldstate requires either operator intervention via a manual start or the IdleHoldtimer to expire with the "Keep Idle" flag to be clear. Any other event received in the IdleHold state is ignored. Connect State: In this state, BGP has initiated an outbound transport connection and is waiting it to be completed. Expiration Date July 2002 [Page 34] RFC DRAFT January 2002 If the transport connection succeeds, the following steps are performed: - Clear the ConnectRetry timer, - Complete initialization /* What does this really mean spec-wise? Just remove ? */ - Send an Open message to the peer, - Set Hold timer to a large value (see note below) - Transition to OpenSent. /* Stop listening to the incoming connection here ? */ NOTE: A hold timer value of 4 minutes is suggested. If the transport protocol connection fails (e.g., retransmission timeout), the following steps are performed: - Restart the ConnectRetry timer, - Continue to listen for a connection that may be initiated by the peer, /* Remove this and specify when I should stop * listening? */ - Transition to Active state. In response to the ConnectRetry timer expired event, the local system performs the following steps: - Restart the ConnectRetry timer, - Initiate an outbound transport connection to the peer, - Continue to listen for a connection that may be initiated by the remote BGP peer, and /* Remove this and specify when I should stop * listening? */ - Stay in Connect state. The start event (manual or automatic) is ignored in the Connect state. In response to any other event (initiated by the system or operator), the following steps are executed: /* Again, the same comment about "any other event"...*/ - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60 - Increment ConnectRetryCnt by 1, - Stop the ConnectRetry timer, Expiration Date July 2002 [Page 35] RFC DRAFT January 2002 - Drop the transport connection, - Release resources allocated for the session, - Transition to IdleHoldstate /* Idle */ Active State: In this state BGP is not actively initiating an outbound transport connection, but is trying to acquire a peer by listening for and accepting an incoming one. If the local system does not allow BGP connections with unconfigured peers, then the local system rejects connections from IP addresses that are not configured peers, and remains in the Active state. If the transport connection succeeds, the following steps are performed: - Stop the ConnectRetry timer, - Complete the initialization, /* Remove this ?*/ - Send the Open message to the peer, - Set the Hold timer to a large value (see note below) - Transition to the OpenSent state. /* Stop listening here? */ NOTE: A Hold timer value of 4 minutes is suggested. In response the ConnectRetry timer expired event, the local system performs the following: - Restart the ConnectRetry timer, - Initiate an outbound transport connection to the peer, - Continue to listen for connection that may be initiated by the peer, /* Remove this ?*/ - Transition to Connect. The start events (initiated by the system or operator) are ignored in the Active state. Expiration Date July 2002 [Page 36] RFC DRAFT January 2002 In response to any other event (initiated by the system or operator), the following steps are taken: - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60 - Increment ConnectRetryCnt by 1, - Stop the ConnectRetry timer - Drops the transport connection, - Releases resources allocated for the session - Transition to IdleHold state. /* Idle */ /* Stop listening here ?*/ OpenSent: In this state, the local system has sent out an OPEN message and awaits an OPEN message from the peer. When an OPEN message is received, all fields are checked for correctness. If the BGP message header checking or OPEN message check detects an error (see Section 6.2), or a connection collision (see Section 6.8) the following steps are performed: - Send a NOTIFICATION message /* Need code here */ - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60 - Increment ConnectRetryCnt by 1, - Stop the ConnectRetry timer - Drop the transport connection, - Release resources allocated for the session, - Transition to the IdleHold state. /* Idle */ If there are no errors in the OPEN message, the local system does the following steps: - Send a KEEPALIVE message, - Start the KeepAlive timer (see note below) - Start the Hold timer according to the negotiated value (see section 4.2 and note below), - Transition to OpenConfirm. Expiration Date July 2002 [Page 37] RFC DRAFT January 2002 NOTE: If the negotiated Hold time value is zero, then the HoldTime timer and KeepAlive timers are not started. If the value of the Autonomous System field is the same as the local Autonomous System number, then the connection is an "internal" connection; otherwise, it is an "external" connection. (This will impact UPDATE processing as described below.) /* Does this above para really belong to the FSM description? * I think not. Move to OPEN message section? */ If a disconnect signal is received from the underlying transport protocol, the following steps are done: - Close the transport connection, - Restart the ConnectRetry timer, - Listen for a connection that may be initiated by the remote peer, - Transition to the Active state. If the HoldTimer expires: - Send a NOTIFICATION message with error code "Hold Timer Expired", - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60 - Increment ConnectRetryCnt by 1, - Stop the ConnectRetry timer, - Drop the transport connection, - Release resources allocated for the session - Transition to IdleHold state. The Start event (manual and automatic) is ignored in the OpenSent state. If a NOTIFICATION message is received with the "Unsupported Version Number" code, the following steps are peformed: - Close the transport connection - Release resources allocated for the session, - Reset ConnectRetryCnt - Stop the ConnectRetry timer, Expiration Date July 2002 [Page 38] RFC DRAFT January 2002 - Transition to Idle state. If any other NOTIFICATION is received, the following steps are executed: - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60 - Increment ConnectRetryCnt by 1, - Stop the ConnectRetry timer, - Drop the transport connection, - Release resources allocated for the session - Transition to IdleHold state. /* Idle */ In response to any other event, the local system performs the following steps: - Send the NOTFICATION message with Error Code "Finite State Machine Error", - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60 - Increment ConnectRetryCnt by 1, - Stop the ConnectRetry timer - Drop the transport connection, - Release resources allocated for the session - Transition to IdleHold state. /* Idle */ OpenConfirm state In this state, the local system has received an OPEN message from the peer, confirmed its reception by sending out a KEEPALIVE message, and awaits an incoming KEEPALIVE message confirming that the remote peer received the OPEN message sent before, or an incoming NOTIFICATION message reporting a problem. If the local system receives a KEEPALIVE message, the FSM transitions to Established state. Upon expiration of the HoldTimer: - Send the NOTIFICATION message with the error code "Hold Timer Expired", - Set IdleHoldTimer to 2**(ConnectRetryCnt)*60 Expiration Date July 2002 [Page 39] RFC DRAFT January 2002 - Increment ConnectRetryCnt by 1, - Stop the ConnectRetry timer, - Drop the transport connection, - Releases resources allocated for the session - Transition to IdleHold state. /* Idle */ If the local system receives a NOTIFICATION message or receives a disconnect signal from the underlying transport protocol, the following steps are done: - Set IdleHold Timer to 2**(ConnectRetryCnt)*60 - Increment ConnectRetryCnt by 1, - Stop the ConnectRetry timer, - Drop the transport connection, - Release resources allocated for the session, - Transition to IdleHold state. /* Idle */ In response to the automatic Stop event: - Send the NOTIFICATION message with "Cease" error code, - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60 - Increment ConnectRetryCnt by 1, - Stop the ConnectRetry timer, - Drop the transport connection, - Release resources allocated for the session, - Transition to IdleHold state. /* Idle */ In response to a manual Stop event: - Send the NOTIFICATION message with "Cease" error code, Expiration Date July 2002 [Page 40] RFC DRAFT January 2002 - Release resources allocated for the session, - Reset ConnectRetryCnt - Stop the ConnectRetry timer, - Transition to Idle state. The Start event is ignored in the OpenConfirm state. In response to any other event: - Send a NOTIFICATION with a code of "Finite State Machine Error", - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60 - Increment ConnectRetryCnt by 1, - Stop the ConnectRetry timer, - Drop the transport connection, - Release resources allocated for the session, - Transition to IdleHold state. /* Idle */ Established State: This is the most advanced state of the FSM. In the Established state the peers can exchange UPDATE, NOTFICATION, and KEEPALIVE messages. On reception of an UPDATE or KEEPALIVE message: - Restarts the Hold timer, if the negotiated HoldTime value is non-zero, - Stay in Established state. If the local system receives a NOTIFICATION message or a disconnect signal from the underlying transport protocol: - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60, - Increment ConnectRetryCnt by 1, - Stop the ConnectRetry timer, - Drop the transport connection, - Release resources allocated for the session, Expiration Date July 2002 [Page 41] RFC DRAFT January 2002 - Transition to IdleHoldstate. /* Idle */ If the local system receives an UPDATE message, and the Update message error handling procedure (see Section 6.3) detects an error, the following steps are performed: - Send a NOTIFICATION message with "Update Message Error" error code, - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60 - Increment ConnectRetryCnt by 1, - Stop the ConnectRetry timer, - Drop the transport connection, - Release resources allocated for the session, - Transition to IdleHold state. /* Idle */ On expiration of the Hold timer: - Send a NOTIFICATION message with error code "Hold Timer Expired", - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60 - Increment ConnectRetryCnt by 1, - Stop the ConnectRetry timer, - Drop the transport connection, - Release resources allocated for the session, - Transition to IdleHold state. /* Idle */ On expiration of the KeepAlive timer: - Send a KEEPALIVE message, - Restart the KeepAlive timer, unless the negotiated Hold Time value is zero. NOTE: The KeepAlive timer is also restarted each time a KEEPALIVE or UPDATE message is sent it restarts, unless the negotiated Hold Time value is zero. In response to an automatic Stop event: Expiration Date July 2002 [Page 42] RFC DRAFT January 2002 - Send a NOTIFICATION with "Cease" error code, - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60 - Increment ConnectRetryCnt by 1, - Stop the ConnectRetry timer, - Drop the transport connection, - Release resources allocated for the session, including invalidation of all routes possibly received from the peer - Transition to IdleHold state. /* Idle */ NOTE: An example of when an automatic Stop event can be generated is exceeding the maximum number of prefixes allowed to be received from a given peer. In response to a manual Stop event: - Send a NOTIFICATION with "Cease" error code, - Reset ConnectRetryCnt - Stop the ConnectRetry timer, - Drop the transport connection, - Release resources allocated for the session, including invalidation of all routes possibly received from the peer - Transition to Idle state. /* Idle */ The Start event is ignored in the Established state. In response to any other event, the local system: - Send a NOTIFICATION with "Finite State Machine Error" error code, - Set IdleHoldtimer to 2**(ConnectRetryCnt)*60 - Increment ConnectRetryCnt by 1, - Stop the ConnectRetry timer, - Drop the transport connection, - Release resources allocated for the session, including invalidation of all routes possibly received from the peer - Transition to IdleHold state. /* Idle */ Expiration Date July 2002 [Page 43] RFC DRAFT January 2002 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 TAA21017 for ; Wed, 16 Jan 2002 19:24:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6677C912B3; Wed, 16 Jan 2002 19:24:17 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E173912BD; Wed, 16 Jan 2002 19:24: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 1BEF4912B3 for ; Wed, 16 Jan 2002 19:24:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id D9DE65DDA7; Wed, 16 Jan 2002 19:24:15 -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 9EA485DDA1 for ; Wed, 16 Jan 2002 19:24:15 -0500 (EST) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id D51AF1531C1; Wed, 16 Jan 2002 16:24:14 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 18E6B7E6C1; Wed, 16 Jan 2002 16:24:13 -0800 (PST) To: Alex Zinin Cc: Susan Hares , Kunihiro Ishiguro , Vincent Gillet , Yakov Rekhter , Jeffrey Haas , idr@merit.edu Subject: Re: bgp4-17 Cease subcode In-Reply-To: Message from Alex Zinin of "Wed, 16 Jan 2002 11:10:47 PST." <114185201786.20020116111047@nexsi.com> Date: Wed, 16 Jan 2002 16:24:13 -0800 From: Enke Chen Message-Id: <20020117002414.18E6B7E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Yes, please do not introduce the IdleHold State at this stage of the BGP deployment. -- Enke > Date: Wed, 16 Jan 2002 11:10:47 -0800 > From: Alex Zinin > X-Mailer: The Bat! (v1.51) Personal > Reply-To: Alex Zinin > Organization: Nexsi Systems > X-Priority: 3 (Normal) > Message-ID: <114185201786.20020116111047@nexsi.com> > To: Susan Hares > Cc: Kunihiro Ishiguro , > Vincent Gillet , Yakov Rekhter , > Jeffrey Haas , > Subject: Re: bgp4-17 Cease subcode > > Sue, > > Introduction of the IdleHold does change the FSM, > and I thought we wanted the spec to reflect the current > running code as much as possible. > > I agree with Russ and Ishi---the new state does not > seem to be necessary, instead it could be as easy > as holding the session in Idle and giving clue on > how to make the delay exponential. I don't think > there's an interoperability issue if people decide > to keep the session in Idle using different internal > mechanisms. > > Regards, > > -- > Alex Zinin > > Wednesday, January 16, 2002, 6:04:36 AM, Susan Hares wrote: > > > Kunihiro: > > > We are not changing the FSM so I would be surprised if the change > > was anything but modest. Usually specifications with "no big" deal get > > interpreted differently. Inter-operable code means you tie down the details. > > > The comment was on the clarity of the specification. > > > If you have a specific comment on the text of the state machine, > > can you propose the concerns you have as a revision to the text. > > > Sue > > > PS -- I just love last call on a draft... It's when > > everyone finally reads a new section ;-)... > > > > At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote: > >> >> > Is the expoential backoff in the FSM in current implementations? > >> >> > >> >> I guess we are going to find this out as part of the implementation > >> >> report. And if it is not in (at least two) current implementations, > >> >> we'll take it out of the text. > >> > > >> >I implemented Cease subcode in zebra-0.92a but not exponential backoff. > >> >I checked that new subcode does not put other BGP stack in trouble > >> >(checked Cisco and Juniper). > >> > >>First of all, sorry for talking about specific implementation. In > >>Zebra implementation we've implemented Cease subcode. The code is in > >>CVS repository. I'll prepare a release version for that. > >> > >>And also we've implemented exponetial backoff. It is done without > >>introducing new FSM status. It is not a big deal. Just check a flag > >>in a few functions. > > > >>Exponential backoff is a good feature. I can't understand why it > >>require change to FSM. > > 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 TAA20568 for ; Wed, 16 Jan 2002 19:09:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 305B7912A0; Wed, 16 Jan 2002 19:08:56 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F00F7912A2; Wed, 16 Jan 2002 19:08: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 E8241912A0 for ; Wed, 16 Jan 2002 19:08:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id BB89F5DDA8; Wed, 16 Jan 2002 19:08:54 -0500 (EST) Delivered-To: idr@merit.edu Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by segue.merit.edu (Postfix) with ESMTP id 26C2C5DD90 for ; Wed, 16 Jan 2002 19:08:54 -0500 (EST) Received: from doom.twoguys.org by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id QAA08836; Wed, 16 Jan 2002 16:08:53 -0800 (PST) Received: (from ghankins@localhost) by doom.twoguys.org (8.11.6/8.11.2) id g0H08pw06635 for idr@merit.edu; Wed, 16 Jan 2002 19:08:51 -0500 Date: Wed, 16 Jan 2002 19:08:51 -0500 From: Greg Hankins To: idr@merit.edu Subject: Re: bgp4-17 Cease subcode Message-ID: <20020116190851.C6038@riverstonenet.com> Reply-To: ghankins@riverstonenet.com References: <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <20020115140711.GA23937@opentransit.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <114185201786.20020116111047@nexsi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <114185201786.20020116111047@nexsi.com>; from azinin@nexsi.com on Wed, Jan 16, 2002 at 11:10:47AM -0800 X-Mailer: Mutt 1.2.5.1i Sender: owner-idr@merit.edu Precedence: bulk On Wed, Jan 16, 2002 at 11:10:47AM -0800, Alex Zinin wrote: > Introduction of the IdleHold does change the FSM, > and I thought we wanted the spec to reflect the current > running code as much as possible. Agreed. Changing the FSM at this point doesn't seem like it is worth the impact that this change would have on existing implementations, given that there are other implementation-dependant ways of doing the same thing. A change in the FSM would make every BGP implementation and every piece of documentation written on BGP outdated. I'm not saying that this shouldn't be done if, there is a valid technical reason. Maybe the exponential backoff parts could be published as a separate draft instead of including it in the base specification? Greg -- Greg Hankins | Riverstone Networks, Inc. Corporate Systems Engineering | 5200 Great America Parkway http://www.riverstonenet.com/ | Santa Clara, CA 95054 +1 404 434 0355 | +1 408 878 6500 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 SAA19459 for ; Wed, 16 Jan 2002 18:14:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 29BD891299; Wed, 16 Jan 2002 18:13:40 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB4339129A; Wed, 16 Jan 2002 18:13: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 8E4B891299 for ; Wed, 16 Jan 2002 18:13:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2E5F25DDA7; Wed, 16 Jan 2002 18:13:38 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 60B015DDA3 for ; Wed, 16 Jan 2002 18:13:37 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0GNCw342007; Wed, 16 Jan 2002 18:12:58 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020116181115.03ea46f8@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 16 Jan 2002 18:12:57 -0500 To: Kunihiro Ishiguro From: Susan Hares Subject: Re: bgp4-17 Cease subcode Cc: Susan Hares , Vincent Gillet , Yakov Rekhter , Jeffrey Haas , idr@merit.edu In-Reply-To: References: <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <87advfjcqi.wl@vaio.zebra.org> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_4999358==_" X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk --=====================_4999358==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Kunihiro: Here's the state machine diagram and event plan that matches the state machine. You could look at the state machine diagram to easily walk through the words. Sue At 01:33 PM 1/16/2002 -0800, Kunihiro Ishiguro wrote: > >If you have a specific comment on the text of the state machine, > >can you propose the concerns you have as a revision to the text. > >OK. Let me do some updates. > > >PS -- I just love last call on a draft... It's when > > everyone finally reads a new section ;-)... > >Exactly... And engineers suddenly realize how important it is ;-). >-- >Kunihiro Ishiguro --=====================_4999358==_ Content-Type: application/msword; name="statemt.doc"; x-mac-type="42494E41"; x-mac-creator="4D535744" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="statemt.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAfAAAAAAAAAAA EAAAfgAAAAEAAAD+////AAAAAHsAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAWyAJBAAA8BK/AAAAAAAAEAAAAAAABAAAGBwAAA4AYmpiauIA4gAAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIowAAIBqAQCAagEAGBgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAN4AAAAAAAAA3gAAAN4A AAAAAAAA3gAAAAAAAADeAAAAAAAAAN4AAAAAAAAA3gAAABQAAAAAAAAAAAAAAPIAAAAAAAAA5CcA AAAAAADkJwAAAAAAAOQnAAAAAAAA5CcAAAwAAADwJwAApAEAAPIAAAAAAAAAmUMAADIBAACgKQAA AAAAAKApAAAAAAAAoCkAAAAAAACgKQAAAAAAAKApAAAAAAAAoCkAAAAAAACgKQAAAAAAAKApAAAA AAAAGEMAAAIAAAAaQwAAAAAAABpDAAAAAAAAGkMAAAAAAAAaQwAAAAAAABpDAAAAAAAAGkMAACQA AADLRAAAIAIAAOtGAABYAAAAPkMAABUAAAAAAAAAAAAAAAAAAAAAAAAA3gAAAAAAAACgKQAAAAAA AAAAAAAAAAAAAAAAAAAAAACgKQAAAAAAAKApAAAAAAAAoCkAAAAAAACgKQAAAAAAAD5DAAAAAAAA 0i0AAAAAAADeAAAAAAAAAN4AAAAAAAAAoCkAAAAAAAAAAAAAAAAAAKApAAAAAAAAU0MAABYAAADS LQAAAAAAANItAAAAAAAA0i0AAAAAAACgKQAAEgEAAN4AAAAAAAAAoCkAAAAAAADeAAAAAAAAAKAp AAAAAAAAGEMAAAAAAAAAAAAAAAAAANItAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAoCkAAAAAAAAYQwAAAAAAANItAADaBgAA0i0AAAAAAACsNAAA VgAAAGg7AABAAAAA3gAAAAAAAADeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALDwAAAAAAACgKQAAAAAAAJQpAAAMAAAAgMOh2cVn wQHyAAAA8iYAAOQnAAAAAAAAsioAAD4CAACoOwAADAAAAAAAAAAAAAAALDwAAOwGAABpQwAAMAAA AJlDAAAAAAAAtDsAAHgAAABDRwAAAAAAAPAsAADiAAAAQ0cAAAAAAAAsPAAAAAAAANItAAAAAAAA 8gAAAAAAAADyAAAAAAAAAN4AAAAAAAAA3gAAAAAAAADeAAAAAAAAAN4AAAAAAAAAAgDZAAAAQkdQ IFN0YXRlIG1hY2hpbmUgaW4gdGFibGUgZm9ybWF0Og0NVGhlIHRhYmxlIGJlbG93IGhhcyBFdmVu dHMgYnkgU3RhdGVzLiAgSW4gZWFjaCBlbnRyeSBvZiB0aGUgdGFibGUsIHRoZSBmaXJzdCBlbnRy eSBpbiB0aGUgYm94IGlzIHRoZSBuZXcgc3RhdGUuICBUaGUgc2Vjb25kIGVudHJ5IGlzIHRoZSBz ZXQgb2YgYWN0aW9ucy4gICBFYWNoIGFjdGlvbiBpcyBlaXRoZXIgc3BlY2lmaWVkIChzdWNoIGFz IElnbm9yZSkgb3IgaXQgZ2l2ZW4gYSBMZXR0ZXIgKHN1Y2ggYXMgQikgd2hpY2ggaXMgZGVzY3Jp YmVkIGF0IHRoZSBlbmQgb2YgdGhlIHRhYmxlLg0NRm9yIGV4YW1wbGUsICBJZiBhbiBBdXRvbWF0 aWMgc3RhcnQgZXZlbnQgb2NjdXJzIGluIHRoZSBJZGxlIHN0YXRlLCB0aGUgbG9jYWwgc3lzdGVt IHBlcmZvcm1zIHRoZSBhY3Rpb25zIGxpc3RlZCB1bmRlciCTQZQgYW5kIGdvZXMgdG8gdGhlIENv bm5lY3Qgc3RhdGUuICAgVGhlIGFjdGlvbnMgdW5kZXIgdGhlIGxldHRlciBBIGFyZTogDQ1BY3Rp b24gQQ1pbml0aWFsaXplIGFsbCBCR1AgcmVzb3VyY2VzDXN0YXJ0IENvbm5lY3QgcmV0cnkgdGlt ZXINaW5pdGlhdGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gdG8gQkdQIHBlZXINbGlzdGVuIGZvciBj b25uZWN0aW9uIHNldC11cCBieSByZW1vdGUgQkdQIHBlZXINDQ0NB1N0YXRlIChOZXcgc3RhdGUv YWN0aW9uKQcHRXZlbnQHSWRsZSBIb2xkB0lkbGUHQ29ubmVjdAdPcGVuIHNlbnQHQWN0aXZlB09w ZW4gDUNvbmZpcm0HRXN0YWJsaXNoZWQHB01hbnVhbA1TdGFydAdDb25uZWN0IC8gQgdDb25uZWN0 DS9CB0Nvbm5lY3QvDUlnbm9yZQdPcGVuDVNlbnQvDUlnbm9yZQdBY3RpdmUvDUlnbm9yZQdPcGVu IA1Db25maXJtLw1JZ25vcmUHRXN0YWJsaXNoZWQvDUlnbm9yZQcHQXV0byANU3RhcnQHSWRsZSBI b2xkLw1JZ25vcmUHQ29ubmVjdC8gQQdDb25uZWN0Lw1JZ25vcmUHT3Blbg1TZW50Lw1JZ25vcmUH QWN0aXZlLw1JZ25vcmUHT3Blbg1Db25maXJtLw1JZ25vcmUHRXN0YWJsaXNoZWQvDUlnbm9yZQcH SWRsZSBIb2xkIHRpbWVyDUV4cGlyZWQgYW5kIHZhbHVlIHVuZGVyIGNlaWxpbmcHSWRsZS8NQQdJ ZGxlLw1GU00gZXJyb3IHSWRsZSBIb2xkLw1EIAdJZGxlIEhvbGQgLyBFIA0oRlNNIGVycm9yKQdJ ZGxlIEhvbGQgLw1EICAoRlNNIGVycm9yKQ0HSWRsZSBIb2xkIC8gRSANKEZTTSBlcnJvcikHSWRs ZSBIb2xkIC8NRSANKEZTTSBlcnJvcikHB0lkbGUgSG9sZCB0aW1lciAmIHRpbWVyIG92ZXIgY2Vp bGluZwdJZGxlIEhvbGQgLw1JZ25vcmUHSWRsZSAvDUlnbm9yZQdJZGxlIEhvbGQgLyBEIAdJZGxl IEhvbGQgLyBFIA0oRlNNIGVycm9yKQdJZGxlIEhvbGQgLyANRCANKEZTTSBlcnJvcikHSWRsZSBI b2xkIC8NRSANKEZTTSBlcnJvcikHSWRsZSBIb2xkIC8NRSANKEZTTSBlcnJvcikHB1RDUA1Db25u ZWN0IA1zdWNjZWVkcw0oc2VudCBUQ1ApB0lkbGUgSG9sZC8NSWdub3JlB0lkbGUvDUlnbm9yZQdP cGVuIHNlbnQgLyBGIAdJZGxlIEhvbGQvIEUgKEZTTSBlcnJvcikHT3BlbiBzZW50IC8gDUYHSWRs ZSBIb2xkIC8gRSAgKEZTTSBlcnJvcikgDQdJZGxlIEhvbGQgLw0gRSAoRlNNIEVycm9yKQ0HB1RD UCBjb25uZWN0IGZhaWxlZAdJZGxlIEhvbGQvDUlnbm9yZQdJZGxlLw1JZ25vcmUHQWN0aXZlIC8N Rw0HSWRsZSBIb2xkIC8gRSANKEZTTSBlcnJvcikHSWRsZSBob2xkDSAvIEQNB0lkbGUgSG9sZCAv IEUNKEZTTSBlcnJvcikHSWRsZSBIb2xkIC8gIEUgKEZTTSBlcnJvcikHB1RDUCBkaXMglmNvbm5l Y3QHSWRsZSBIb2xkLw1JZ25vcmUHSWRsZS8gSWdub3JlB0lkbGUgSG9sZCAvIEQgB0FjdGl2ZSAv IE8gYWN0aW9ucwdJZGxlIEhvbGQgDS8gRAdJZGxlIEhvbGQgLyANRAdJZGxlIEhvbGQgLyBEBwdD b25uZWN0DVJldHJ5IHRpbWVyIGV4cGlyZXMHSWRsZSBIb2xkDS8gSWdub3JlB0lkbGUvIElnbm9y ZQdDb25uZWN0IC8gSCAHSWRsZSBIb2xkICAvIEUNKEZTTSBlcnJvcikHQ29ubmVjdCAvIEgHSWRs ZSBIb2xkIC8gRSAoRlNNIGVycm9yKQdJZGxlIEhvbGQgLyBFIChGU00gZXJyb3IpBwdSY3YgVENQ IENvbm5lY3QgJiB1bmNvbmZpZ3VyZWQNUGVlcnMgT0sHSWRsZSBIb2xkLw1JZ25vcmUHSWRsZSAv DUlnbm9yZQdJZGxlIEhvbGQgLyAgRCAHSWRsZSBIb2xkIC8gRSANKEZTTSBFcnJvcikHT3BlbiBT ZW50IC8NSwdJZGxlIEhvbGQgLyBFIChGU00gZXJyb3IpB0lkbGUgSG9sZCAvIEQNBwdSY3YgVENQ IGNvbm5lY3QNJiB1bmNvbmZpZw1wZWVycyBub3QgDU9LB0lkbGUgaG9sZC8NSWdub3JlDQdJZGxl IC8NSWdub3JlB0lkbGUgSG9sZCAvIEQgB0lkbGUgSG9sZCAvIEUHQWN0aXZlIC8gTCAHSWRsZSBI b2xkIC8gRSAoRlNNIGVycm9yKQdJZGxlIEhvbGQgLyBEDQcHSG9sZCBUaW1lciBleHBpcmVzB0lk bGUgSG9sZC8gDUlnbm9yZQdJZGxlIC8NSWdub3JlB0lkbGUgSG9sZC8NRAdJZGxlIEhvbGQNLyBN IChIb2xkIHRpbWVyIGV4cGlyZWQpDQdJZGxlIEhvbGQgLyANRA0gKEZTTSBlcnJvcikHSWRsZSBI b2xkIC8gIE0gKGhvbGQgdGltZXIgZXhwaXJlZCkHSWRsZSBIb2xkIC8gDVIgIChob2xkIHRpbWVy IGV4cGlyZWQpIA0HB09wZW4gcmVjdiB3aXRoIGdvb2QgZm9ybWF0IGFuZCBoZWFkZXIHSWRsZSBI b2xkIC8NSWdub3JlB0lkbGUgSG9sZCAvIA1JZ25vcmUHSWRsZSBIb2xkIC8gIEQgKEZTTSBlcnJv cikHSWRsZSBIb2xkIC8gIE4HSWRsZSBIb2xkIC8gDUQgDShmc20gZXJyb3IpB0lkbGUgSG9sZCAN LyBFDShGU00gZXJyb3IpB0lkbGUgSG9sZCAvIA1FIA0oRlNNIEVycm9yKQcHSGVhZGVyIGVycm9y B0lkbGUgSG9sZC8NSWdub3JlB0lkbGUgLyBJZ25vcmUHSWRsZSBIb2xkIC8gRCAHSWRsZSBIb2xk IC8gSQdJZGxlIEhvbGQgLyANRCANKEZTTSBlcnJvcikHSWRsZSBIb2xkIC8gRQ0oRlNNIEVycm9y KQdJZGxlIG9sZCAvIEUNDShGU00gRXJyb3IpBwdPcGVuIG1zZyBlcnJvcgdJZGxlIEhvbGQvIEln bm9yZQdJZGxlIC8gSWdub3JlB0lkbGUgSG9sZCAvIEQHSWRsZSBIb2xkIC8gSgdJZGxlIEhvbGQg LyANRA0oRlNNIGVycm9yKQdJZGxlIEhvbGQgLyBFDShGU00gRXJyb3IpB0lkbGUgSG9sZCAvICBF IChGU00gZXJyb3IpBwdOb3RpZmljYXRpb24gd2l0aCB2ZXJzaW9uIGVycm9yB0lkbGUgSG9sZC8N SWdub3JlB0lkbGUvIElnbm9yZQ0HSWRsZSBIb2xkIC8gRAdJZGxlIC8gQwdJZGxlIEhvbGQvIEQN KEZTTSBlcnJvcikHSWRsZSBIb2xkIC8NRAdJZGxlIEhvbGQgLyANRAcHT3BlbiBjb2xsaXNpb24g ZGV0ZWN0ZWQgJiBkdW1wIHRoaXMgc2Vzc2lvbgdJZGxlIEhvbGQvDUlnbm9yZQdJZGxlIC8gSWdu b3JlB0lkbGUgSG9sZCAgLyBEICAHSWRsZSBob2xkIC8gUwdJZGxlIEhvbGQgLyANRA0oRlNNIGVy cm9yKQdJZGxlIEhvbGQgLyAgRSAoRlNNIEVycm9yKQdJZGxlIEhvbGQgLw1FIChGU00gRXJyb3Ip BwdLZWVwLQ1hbGl2ZQ1UaW1lciBleHBpcmVzB0lkbGUgSG9sZC8NSWdub3JlB0lkbGUgLyBJZ25v cmUHSWRsZSBIb2xkIC8gRCANKEZTTSBFcnJvcikgB0lkbGUgSG9sZCAvIEUNKEZTTSBlcnJvcikH SWRsZSBIb2xkIC8gRA0oRlNNIGVycm9yKQ0HT3BlbiBDb25maXJtLyBRB0VzdGFibGlzaGVkLyAN UQcHS2VlcC1hbGl2ZSBtZXNzYWdlIAdJZGxlIEhvbGQvIElnbm9yZQdJZGxlIC8gSWdub3JlB0lk bGUgSG9sZCAvICBEB0lkbGUgSG9sZCAvIEUgKEZTTSBlcnJvcikHSWRsZSBIb2xkIC8gDUQgB0Vz dGFibGlzaGVkDVAHRXN0YWJsaXNoZWQvIA1QBwdVcGRhdGUgbWVzc2FnZQdJZGxlIEhvbGQgLyBJ Z25vcmUHSWRsZSAvIA1JZ25vcmUHSWRsZSBIb2xkIC8gRAdJZGxlIEhvbGQgL0UgKEZTTSBlcnJv cikHSWRsZSBIb2xkIC8gRAdJZGxlIEhvbGQgLyBFIChGU00gZXJyb3IpB0VzdGFibGlzaGVkIC8g UHJvY2VzcyBVcGRhdGUHByBOb3RpZmktY2F0aW9uDVJlY2VpdmVkB0lkbGUgSG9sZC8NSWdub3Jl B0lkbGUgLw1JZ25vcmUHSWRsZSBIb2xkIC8gRAdJZGxlIEhvbGQgLyBEIA0HSWRsZSBIb2xkIC8g RAdJZGxlIEhvbGQgLyANRAdJZGxlIEhvbGQgLyBkBwdVcGRhdGUgbWVzc2FnZSBlcnJvcgdJZGxl IEhvbGQvIElnbm9yZQdJZGxlLyBJZ25vcmUHSWRsZSBIb2xkIC8gRAdJZGxlIEhvbGQgLyBFB0lk bGUgSG9sZCAvIEQHSWRsZSBIb2xkIC8gRQdJZGxlIEhvbGQgLw1VBwdNYW51YWwgc3RvcAdJZGxl IC8NQwdJZGxlLw1DB0lkbGUvDUMHSWRsZS8NQwdJZGxlIC8gDUMHSWRsZSAvIGMHSWRsZSAvIGMH B0F1dG8gc3RvcAdJZGxlIEhvbGQvDUlnbm9yZQdJZGxlIEhvbGQvDQdJZGxlIEhvbGQvDUQHSWRs ZSBIb2xkIC8gIFMHSWRsZSBIb2xkIC8gRAdJZGxlIEhvbGQgLyBTB0lkbGUgSG9sZCAvIFMNBwcN DA1BY3Rpb25zDQ1BY3Rpb24gQQ1pbml0aWFsaXplIGFsbCBCR1AgcmVzb3VyY2VzDXN0YXJ0IENv bm5lY3QgcmV0cnkgdGltZXINaW5pdGlhdGUgdHJhbnNwb3J0IGNvbm5lY3Rpb24gdG8gQkdQIHBl ZXINbGlzdGVuIGZvciBjb25uZWN0aW9uIHNldC11cCBieSByZW1vdGUgQkdQIHBlZXINDUFjdGlv biBCDUNvbm5lY3RSZXRyeUNudCBzZXQgdG8gMA1BY3Rpb24gQQ1BY3Rpb24gQw1yZWxlYXNlIGFs bCBCR1AgcmVzb3VyY2VzDUNvbm5lY3RSZXRyeUNudCBzZXQgdG8gMA1jb25uZWN0IHJldHJ5IHRp bWVyID0gMCANQWN0aW9uICBEDUlETEUgaG9sZCB0aW1lID0gMioqKGNvbm5lY3RSZXRyeUNudCkq NjANQ29ubmVjdFJldHJ5Q250ID0rMQ1jb25uZWN0IHJldHJ5IHRpbWVyID0gMA1EZWxldGUgQkdQ IHJlc291cmNlcw1Ecm9wIFRDUCBjb25uZWN0aW9uDUFjdGlvbiBFDVNlbmQgTm90aWZpY2F0aW9u IChGU00gRXJyb3IpDUFjdGlvbiBEDUFjdGlvbiBGDWNsZWFyIENvbm5lY3RSZXRyeSB0aW1lcg1j b21wbGV0ZSBCR1AgaW5pdGlhbGl6YXRpb24Nc2VuZCBPcGVuIG1lc3NhZ2UNSG9sZCB0aW1lciA9 IExhcmdlIHZhbHVlICg0IG1pbnV0ZXMNQWN0aW9uIEcNcmVzdGFydCBDb25uZWN0UmV0cnkgdGlt ZXINbGlzdGVuIGZvciBCR1AgcGVlciBjb25uZWN0aW9uDUFjdGlvbiBIDXJlc3RhcnQgQ29ubmVj dFJldHJ5IHRpbWVyDXN0YXJ0IFRDUCBjb25uZWN0aW9uDWxpc3RlbiBmb3IgVENQIGNvbm5lY3Rp b24NQWN0aW9uIEkNU2VuZCBOb3RpZmljYXRpb24gd2l0aCBCR1AgSGVhZGVyIEVycm9yDUFjdGlv biBEDUFjdGlvbiAgSg1TZW5kIE5vdGlmaWNhdGlvbiB3aXRoIE9wZW4gbWVzc2FnZSBlcnJvcg1B Y3Rpb24gRA1BY3Rpb24gSw1JUCBhZGRyZXNzIHVuY29uZmlndXJlZCB0dXJucyBpbnRvIHRlbXBv cmFyeSBwZWVyIGVudHJ5DUFjdGlvbiBGDUFjdGlvbiBMDXJlamVjdCBUQ1AgY29ubmVjdGlvbg1B Y3Rpb24gTQ1TZW5kIE5vdGlmaWNhdGlvbiB3aXRoIEhvbGQgVGltZXIgRXhwaXJlZA1BY3Rpb24g RA1BY3Rpb24gTg1TZW5kIEtFRVBBTElWRSBtZXNzYWdlDUlmIG5lZ290aWF0ZWQgSG9sZCB0aW1l IHZhbHVlIGlzIG5vbiwgemVybyANc2V0IEtlZXBhbGl2ZSB0aW1lcg1Ib2xkIHRpbWVyIHJlc2V0 IHRvIG5lZ290aWF0ZWQgSG9sZCB0aW1lIHZhbHVlIChzZWN0aW9uIDQuMikNaWYgbmVnb3RpYXRl ZCBIb2xkIHRpbWUgdmFsdWUgaXMgemVybywNcmVzZXQgS2VlcGFsaXZlIHRpbWVyDXJlc2V0IEhv bGQgdGltZXINSWYgdmFsdWUgb2YgQXV0b25vbW91cyBTeXN0ZW0gZmllbGQgaXMgdGhlIHNhbWUg YXMgdGhlIGxvY2FsIEF1dG9ub21vdXMgc3lzdGVtIG51bWJlciwgc2V0IHRoZSBjb25uZWN0aW9u IGlzIGFuIGludGVybmFsIGNvbm5lY3Rpb247IG90aGVyd2lzZSBpdCBpcyCTZW50ZXJuYWyULiAg KFRoaXMgaW1wYWN0cyBVcGRhdGUgcHJvY2Vzc2luZykNQWN0aW9uIE8NQ2xvc2UgQkdQIGNvbm5l Y3Rpb24NcmVzdGFydCBDb25uZWN0UmV0cnkgVGltZXINY29udGludWUgbGlzdGVuaW5nIGZvciBC R1AgY29ubmVjdGlvbg1BY3Rpb24gUA1SZXN0YXJ0IEhvbGQgdGltZXINQWN0aW9uIFENU2VuZCBL ZWVwYWxpdmUgbWVzc2FnZQ1yZXN0YXJ0IEtFRVBBTElWRSB0aW1lcg1BY3Rpb24gUg1TZW5kIG5v dGlmaWNhdGlvbiB3aXRoIEhvbGQgdGltZXIgZXhwaXJlZA1BY3Rpb24gVA1BY3Rpb24gUw1TZW5k IE5vdGlmaWNhdGlvbiB3aXRoIENlYXNlDUFjdGlvbiBUDUFjdGlvbiBUDUFjdGlvbiBEDURlbGV0 ZSByb3V0ZXMNQWN0aW9uIFUNU2VuZCBub3RpZmljYXRpb24gd2l0aCBVcGRhdGUgZXJyb3IgDUFj dGlvbiBUDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAABgAAmgYAAJ0GAAC3 BgAAuAYAAAAHAAABBwAAHA8AACoPAAC4DwAAxQ8AABgcAAAA/QD9AP0A/fT99P0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAEDUIgTYIgUNKFABcCIFdCIEABENKFAAMAAQAACMEAAAkBAAAPQUAAD4F AAD/BQAAAAYAAAkGAAAmBgAAQAYAAGoGAACaBgAAmwYAAJwGAACdBgAAngYAALcGAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAA AAAAAAAAAAAA8wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BgAAFiQBSWYBAAAABQAACiYBC0YDAAUAAAomAAtGAwAAAQAAABAABAAAGBwAAP0AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQEAAEBAbcGAAC4BgAAvgYAAMgGAADNBgAA 1QYAAN8GAADmBgAA7AYAAPQGAAAABwAAkiQBAAAAAAAAAAAAAIwAAAAAAAAAAAAAAACMAAAAAAAA AAAAAAAAjAAAAAAAAAAAAAAAAIwAAAAAAAAAAAAAAACMAAAAAAAAAAAAAAAAjAAAAAAAAAAAAAAA AIwAAAAAAAAAAAAAAACMAAAAAAAAAAAAAAAAjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAAbAAAFiQBFyQBSWYB AAAAApZsAAM0AQQ0AQXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWMAAClP+EA1ggAAbwAwAA AAAAAAAAAAAAAAAAAAAABtQcAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/ BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzW CAAAAP8AAAD/HdYIAAAA/wAAAP801gYAAQoDbABh9gMAAAAKAAcAAAEHAAAIBwAAIAACAAAAAAAA AAAAABoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAADeAAAWJAEXJAFJZgEA AAAClmwAAzQBBDQBBdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNa0AAiU/4QDCAeMCsQOlxIr FrgaWCAABvADAAAAAAAAAAAAAAAAAAAAAAAGhAMAAAAAAAAAAAAAAAAAAAAAAAaEAwAAAAAAAAAA AAAAAAAAAAAABjgEAAAAAAAAAAAAAAAAAAAAAAAG0wMAAAAAAAAAAAAAAAAAAAAAAAaUAwAAAAAA AAAAAAAAAAAAAAAABo0EAAAAAAAAAAAAAAAAAAAAAAAGoAUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1iAAAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvWIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/HNYgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d1iAAAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2AwAAAAIIBwAADgcAABoHAAAiBwAAJQcAAC4H AAA1BwAAOgcAAEAHAABHBwAATwcAAFYHAABcBwAAZQcAAGwHAAB5BwAAgAcAAPkAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAAEIAHAACBBwAAhwcAAI0HAAAjEAIAAAAA AAAAAAAAHQAAAAAAAAAAAAAAAB0AAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAA2wAAFiQBFyQB SWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWtAAIlP+EAwgHjArEDpcSKxa4 GlggAAbwAwAAAAAAAAAAAAAAAAAAAAAABoQDAAAAAAAAAAAAAAAAAAAAAAAGhAMAAAAAAAAAAAAA AAAAAAAAAAY4BAAAAAAAAAAAAAAAAAAAAAAABtMDAAAAAAAAAAAAAAAAAAAAAAAGlAMAAAAAAAAA AAAAAAAAAAAAAAaNBAAAAAAAAAAAAAAAAAAAAAAABqAFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYgAAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8b1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/xzWIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYgAAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP801gYAAQoDbABh9gMAAAADjQcAAJgHAACfBwAAqgcAALMHAAC6BwAA vwcAAMUHAADMBwAA1AcAANsHAADgBwAA6QcAAPAHAAD9BwAABAgAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAAA8ECAAABQgAABUIAAA1CAAAIxADAAAAAAAA AAAAAB0AAAAAAAAAAAAAAAAdAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAANsAABYkARckAUlm AQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1rQACJT/hAMIB4wKxA6XEisWuBpY IAAG8AMAAAAAAAAAAAAAAAAAAAAAAAaEAwAAAAAAAAAAAAAAAAAAAAAABoQDAAAAAAAAAAAAAAAA AAAAAAAGOAQAAAAAAAAAAAAAAAAAAAAAAAbTAwAAAAAAAAAAAAAAAAAAAAAABpQDAAAAAAAAAAAA AAAAAAAAAAAGjQQAAAAAAAAAAAAAAAAAAAAAAAagBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWIAAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8c1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3WIAAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAAAzUIAAA7CAAAPQgAAEMIAABNCAAAWAgAAFsI AABqCAAAdggAAIIIAACRCAAAkggAAKEIAACtCAAAuQgAALwIAADICAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAAQyAgAAMkIAADuCAAA+ggAACMMAwAAAAAAAAAA AAAdAAAAAAAAAAAAAAAAHQAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAADbAAAWJAEXJAFJZgEA AAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNa0AAiU/4QDCAeMCsQOlxIrFrgaWCAA BvADAAAAAAAAAAAAAAAAAAAAAAAGhAMAAAAAAAAAAAAAAAAAAAAAAAaEAwAAAAAAAAAAAAAAAAAA AAAABjgEAAAAAAAAAAAAAAAAAAAAAAAG0wMAAAAAAAAAAAAAAAAAAAAAAAaUAwAAAAAAAAAAAAAA AAAAAAAABo0EAAAAAAAAAAAAAAAAAAAAAAAGoAUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1iAAAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvWIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ HNYgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d1iAAAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2AwAAAAP6CAAAAQkAAAgJAAAPCQAAHgkAAC0JAAA5CQAA RgkAAEkJAABVCQAAYQkAAGQJAABwCQAAfAkAAH8JAACLCQAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAAD4sJAACMCQAAkAkAAJkJAAAjxAIAAAAAAAAAAAAA HQAAAAAAAAAAAAAAAB0AAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAA2wAAFiQBFyQBSWYBAAAA ApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWtAAIlP+EAwgHjArEDpcSKxa4GlggAAbw AwAAAAAAAAAAAAAAAAAAAAAABoQDAAAAAAAAAAAAAAAAAAAAAAAGhAMAAAAAAAAAAAAAAAAAAAAA AAY4BAAAAAAAAAAAAAAAAAAAAAAABtMDAAAAAAAAAAAAAAAAAAAAAAAGlAMAAAAAAAAAAAAAAAAA AAAAAAaNBAAAAAAAAAAAAAAAAAAAAAAABqAFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYgAAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/wAAAP8b1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xzW IAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYgAAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP801gYAAQoDbABh9gMAAAADmQkAAKIJAACtCQAAuAkAAL8JAADFCQAAzAkAANsJ AAD0CQAAAQoAAAMKAAAfCgAAIAoAACwKAAA7CgAAPAoAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAA AAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAAA88CgAAPQoAAFAKAABbCgAAI3wCAAAAAAAAAAAAAB0A AAAAAAAAAAAAAAAdAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAANsAABYkARckAUlmAQAAAAKW bAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1rQACJT/hAMIB4wKxA6XEisWuBpYIAAG8AMA AAAAAAAAAAAAAAAAAAAAAAaEAwAAAAAAAAAAAAAAAAAAAAAABoQDAAAAAAAAAAAAAAAAAAAAAAAG OAQAAAAAAAAAAAAAAAAAAAAAAAbTAwAAAAAAAAAAAAAAAAAAAAAABpQDAAAAAAAAAAAAAAAAAAAA AAAGjQQAAAAAAAAAAAAAAAAAAAAAAAagBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWIAAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8AAAD/G9YgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1iAA AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3WIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAAA1sKAABiCgAAaAoAAG8KAAB4CgAAegoAAHsKAACKCgAA lgoAAKAKAAClCgAApgoAALQKAADACgAA2woAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAYAABYkAUlmAQAAAAAO2woAANwKAADtCgAA+AoAACP8AQAAAAAAAAAAAAAdAAAA AAAAAAAAAAAAHQAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAADbAAAWJAEXJAFJZgEAAAAClmwA BdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNa0AAiU/4QDCAeMCsQOlxIrFrgaWCAABvADAAAA AAAAAAAAAAAAAAAAAAAGhAMAAAAAAAAAAAAAAAAAAAAAAAaEAwAAAAAAAAAAAAAAAAAAAAAABjgE AAAAAAAAAAAAAAAAAAAAAAAG0wMAAAAAAAAAAAAAAAAAAAAAAAaUAwAAAAAAAAAAAAAAAAAAAAAA Bo0EAAAAAAAAAAAAAAAAAAAAAAAGoAUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1iAAAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/AAAA/xvWIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HNYgAAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/zTWBgABCgNsAGH2AwAAAAP4CgAA/woAAAwLAAAbCwAALgsAADkLAAA9CwAASgsAAEwL AABaCwAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAGAAAWJAFJZgEAAAAACVoLAABbCwAAYwsAAHcLAAAjlAIAAAAAAAAAAAAAHQAAAAAA AAAAAAAAAB0AAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAA2wAAFiQBFyQBSWYBAAAAApZsAAXW GAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWtAAIlP+EAwgHjArEDpcSKxa4GlggAAbwAwAAAAAA AAAAAAAAAAAAAAAABoQDAAAAAAAAAAAAAAAAAAAAAAAGhAMAAAAAAAAAAAAAAAAAAAAAAAY4BAAA AAAAAAAAAAAAAAAAAAAABtMDAAAAAAAAAAAAAAAAAAAAAAAGlAMAAAAAAAAAAAAAAAAAAAAAAAaN BAAAAAAAAAAAAAAAAAAAAAAABqAFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYgAAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/wAAAP8b1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xzWIAAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP801gYAAQoDbABh9gMAAAADdwsAAIELAACKCwAAlwsAAKQLAACzCwAAvwsAAMsLAADlCwAA /wsAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAABgAAFiQBSWYBAAAAAAn/CwAAAAwAAB8MAAAoDAAAI6wCAAAAAAAAAAAAAB0AAAAAAAAA AAAAAAAdAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAANsAABYkARckAUlmAQAAAAKWbAAF1hgE AQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1rQACJT/hAMIB4wKxA6XEisWuBpYIAAG8AMAAAAAAAAA AAAAAAAAAAAAAAaEAwAAAAAAAAAAAAAAAAAAAAAABoQDAAAAAAAAAAAAAAAAAAAAAAAGOAQAAAAA AAAAAAAAAAAAAAAAAAbTAwAAAAAAAAAAAAAAAAAAAAAABpQDAAAAAAAAAAAAAAAAAAAAAAAGjQQA AAAAAAAAAAAAAAAAAAAAAAagBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWIAAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8AAAD/G9YgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1iAAAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3WIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/NNYGAAEKA2wAYfYDAAAAAygMAAAzDAAAOgwAAEEMAABIDAAAWAwAAGcMAABzDAAAfwwAAIEM AACbDAAAqQwAAKoMAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAYAABYkAUlmAQAAAAAMqgwAAKsMAAC7DAAAxgwAACN0AgAAAAAAAAAAAAAdAAAAAAAAAAAA AAAAHQAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAADbAAAWJAEXJAFJZgEAAAAClmwABdYYBAEA AAQBAAAEAQAABAEAAAQBAAAEAQAACNa0AAiU/4QDCAeMCsQOlxIrFrgaWCAABvADAAAAAAAAAAAA AAAAAAAAAAAGhAMAAAAAAAAAAAAAAAAAAAAAAAaEAwAAAAAAAAAAAAAAAAAAAAAABjgEAAAAAAAA AAAAAAAAAAAAAAAG0wMAAAAAAAAAAAAAAAAAAAAAAAaUAwAAAAAAAAAAAAAAAAAAAAAABo0EAAAA AAAAAAAAAAAAAAAAAAAGoAUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/AAAA/xvWIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HNYgAAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /zTWBgABCgNsAGH2AwAAAAPGDAAA0QwAANQMAADfDAAA5gwAAOcMAADuDAAA9QwAAAQNAAASDQAA Hg0AADgNAABGDQAARw0AAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAGAAAWJAFJZgEAAAAADUcNAABIDQAAWw0AAGcNAAAjNAMAAAAAAAAAAAAAHQAAAAAAAAAAAAAA AB0AAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAA2wAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAE AQAABAEAAAQBAAAEAQAABAEAAAjWtAAIlP+EAwgHjArEDpcSKxa4GlggAAbwAwAAAAAAAAAAAAAA AAAAAAAABoQDAAAAAAAAAAAAAAAAAAAAAAAGhAMAAAAAAAAAAAAAAAAAAAAAAAY4BAAAAAAAAAAA AAAAAAAAAAAABtMDAAAAAAAAAAAAAAAAAAAAAAAGlAMAAAAAAAAAAAAAAAAAAAAAAAaNBAAAAAAA AAAAAAAAAAAAAAAABqAFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/wAAAP8b1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xzWIAAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP80 1gYAAQoDbABh9gMAAAADZw0AAG4NAAB1DQAAfA0AAIcNAACJDQAAkw0AAKwNAACtDQAAug0AALwN AADJDQAA7Q0AAPoNAAATDgAAFA4AAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BgAAFiQBSWYBAAAAAA8UDgAAFQ4AADsOAABHDgAAIywDAAAAAAAAAAAAAB0AAAAAAAAAAAAAAAAd AAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAANsAABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEA AAQBAAAEAQAABAEAAAQBAAAI1rQACJT/hAMIB4wKxA6XEisWuBpYIAAG8AMAAAAAAAAAAAAAAAAA AAAAAAaEAwAAAAAAAAAAAAAAAAAAAAAABoQDAAAAAAAAAAAAAAAAAAAAAAAGOAQAAAAAAAAAAAAA AAAAAAAAAAbTAwAAAAAAAAAAAAAAAAAAAAAABpQDAAAAAAAAAAAAAAAAAAAAAAAGjQQAAAAAAAAA AAAAAAAAAAAAAAagBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8AAAD/G9YgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1iAAAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/x3WIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/NNYG AAEKA2wAYfYDAAAAA0cOAABODgAAWw4AAGIOAAB9DgAAjA4AAJkOAACcDgAAqA4AALMOAAC3DgAA ww4AANAOAADTDgAA3w4AAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYA ABYkAUlmAQAAAAAO3w4AAOAOAADtDgAA+A4AACJsAgAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAHAAA AAAAAAAAAAAAAAAGAAAWJAFJZgEAAADdAAAWJAEXJAFJZgEAAAAClmwAAzQBBdYYBAEAAAQBAAAE AQAABAEAAAQBAAAEAQAACNa0AAiU/4QDCAeMCsQOlxIrFrgaWCAABvADAAAAAAAAAAAAAAAAAAAA AAAGhAMAAAAAAAAAAAAAAAAAAAAAAAaEAwAAAAAAAAAAAAAAAAAAAAAABjgEAAAAAAAAAAAAAAAA AAAAAAAG0wMAAAAAAAAAAAAAAAAAAAAAAAaUAwAAAAAAAAAAAAAAAAAAAAAABo0EAAAAAAAAAAAA AAAAAAAAAAAGoAUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ AAAA/xvWIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HNYgAAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8d1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/zTWBgAB CgNsAGH2AwAAAAP4DgAA/w4AAA0PAAAcDwAAKg8AADcPAAA6DwAARg8AAFQPAABgDwAAbQ8AAG4P AAB6DwAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAW JAFJZgEAAAAADHoPAAB7DwAAig8AAJwPAAAjcAIAAAAAAAAAAAAAHQAAAAAAAAAAAAAAAB0AAAAA AAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAA2wAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEA AAQBAAAEAQAABAEAAAjWtAAIlP+EAwgHjArEDpcSKxa4GlggAAbwAwAAAAAAAAAAAAAAAAAAAAAA BoQDAAAAAAAAAAAAAAAAAAAAAAAGhAMAAAAAAAAAAAAAAAAAAAAAAAY4BAAAAAAAAAAAAAAAAAAA AAAABtMDAAAAAAAAAAAAAAAAAAAAAAAGlAMAAAAAAAAAAAAAAAAAAAAAAAaNBAAAAAAAAAAAAAAA AAAAAAAABqAFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAGtYgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAA AP8b1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xzWIAAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/HdYgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP801gYAAQoD bABh9gMAAAADnA8AAKoPAAC4DwAAxg8AANMPAADVDwAA4Q8AAO8PAAD7DwAAFhAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQB SWYBAAAAAAkWEAAAFxAAADcQAABCEAAAIjgCAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAcAAAAAAAA AAAAAAAAAAYAABYkAUlmAQAAAN0AABYkARckAUlmAQAAAAKWbAADNAEF1hgEAQAABAEAAAQBAAAE AQAABAEAAAQBAAAI1rQACJT/hAMIB4wKxA6XEisWuBpYIAAG8AMAAAAAAAAAAAAAAAAAAAAAAAaE AwAAAAAAAAAAAAAAAAAAAAAABoQDAAAAAAAAAAAAAAAAAAAAAAAGOAQAAAAAAAAAAAAAAAAAAAAA AAbTAwAAAAAAAAAAAAAAAAAAAAAABpQDAAAAAAAAAAAAAAAAAAAAAAAGjQQAAAAAAAAAAAAAAAAA AAAAAAagBQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAU9gEAABrWIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/ G9YgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1iAAAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/x3WIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wA YfYDAAAAA0IQAABJEAAAVhAAAFcQAABlEAAAbhAAAHsQAACHEAAAkxAAAJUQAACiEAAApBAAAPkA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlm AQAAAAALpBAAAKUQAADREAAA3BAAACPwAgAAAAAAAAAAAAAdAAAAAAAAAAAAAAAAHQAAAAAAAAAA AAAAAAAAAAYAABYkAUlmAQAAAADbAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEA AAQBAAAEAQAACNa0AAiU/4QDCAeMCsQOlxIrFrgaWCAABvADAAAAAAAAAAAAAAAAAAAAAAAGhAMA AAAAAAAAAAAAAAAAAAAAAAaEAwAAAAAAAAAAAAAAAAAAAAAABjgEAAAAAAAAAAAAAAAAAAAAAAAG 0wMAAAAAAAAAAAAAAAAAAAAAAAaUAwAAAAAAAAAAAAAAAAAAAAAABo0EAAAAAAAAAAAAAAAAAAAA AAAGoAUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAFPYBAAAa1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvW IAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HNYgAAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8d1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2 AwAAAAPcEAAA4xAAAPEQAAACEQAAEBEAAB0RAAAfEQAAKxEAAEYRAABSEQAAYBEAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEA AAAACmARAABhEQAAZxEAAG0RAAAjsAIAAAAAAAAAAAAAHQAAAAAAAAAAAAAAAB0AAAAAAAAAAAAA AAAAAAAGAAAWJAFJZgEAAAAA2wAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAE AQAABAEAAAjWtAAIlP+EAwgHjArEDpcSKxa4GlggAAbwAwAAAAAAAAAAAAAAAAAAAAAABoQDAAAA AAAAAAAAAAAAAAAAAAAGhAMAAAAAAAAAAAAAAAAAAAAAAAY4BAAAAAAAAAAAAAAAAAAAAAAABtMD AAAAAAAAAAAAAAAAAAAAAAAGlAMAAAAAAAAAAAAAAAAAAAAAAAaNBAAAAAAAAAAAAAAAAAAAAAAA BqAFAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAABT2AQAAGtYgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8b1iAA AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xzWIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/HdYgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP801gYAAQoDbABh9gMA AAADbREAAHsRAACGEQAAjREAAJsRAACqEQAAtxEAAMURAADREQAA3xEAAOsRAADsEQAA/BEAAAoS AAAMEgAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAA AA4MEgAADRIAACESAAAzEgAAIzACAAAAAAAAAAAAAB0AAAAAAAAAAAAAAAAdAAAAAAAAAAAAAAAA AAAABgAAFiQBSWYBAAAAANsAABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEA AAQBAAAI1rQACJT/hAMIB4wKxA6XEisWuBpYIAAG8AMAAAAAAAAAAAAAAAAAAAAAAAaEAwAAAAAA AAAAAAAAAAAAAAAABoQDAAAAAAAAAAAAAAAAAAAAAAAGOAQAAAAAAAAAAAAAAAAAAAAAAAbTAwAA AAAAAAAAAAAAAAAAAAAABpQDAAAAAAAAAAAAAAAAAAAAAAAGjQQAAAAAAAAAAAAAAAAAAAAAAAag BQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAU9gEAABrWIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YgAAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/AAAA/x3WIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAA AzMSAABBEgAAUBIAAGoSAAB3EgAAehIAAIYSAACIEgAAlhIAAJgSAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAAJ mBIAAJkSAACoEgAAuxIAACN4AgAAAAAAAAAAAAAdAAAAAAAAAAAAAAAAHQAAAAAAAAAAAAAAAAAA AAYAABYkAUlmAQAAAADbAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAE AQAACNa0AAiU/4QDCAeMCsQOlxIrFrgaWCAABvADAAAAAAAAAAAAAAAAAAAAAAAGhAMAAAAAAAAA AAAAAAAAAAAAAAaEAwAAAAAAAAAAAAAAAAAAAAAABjgEAAAAAAAAAAAAAAAAAAAAAAAG0wMAAAAA AAAAAAAAAAAAAAAAAAaUAwAAAAAAAAAAAAAAAAAAAAAABo0EAAAAAAAAAAAAAAAAAAAAAAAGoAUA AAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAFPYBAAAa1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvWIAAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HNYgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /wAAAP8d1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2AwAAAAO7 EgAAwxIAAMoSAADYEgAA8RIAAP8SAAAZEwAANhMAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAABzYT AAA3EwAARhMAAE8TAAAjCAIAAAAAAAAAAAAAHQAAAAAAAAAAAAAAAB0AAAAAAAAAAAAAAAAAAAAG AAAWJAFJZgEAAAAA2wAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEA AAjWtAAIlP+EAwgHjArEDpcSKxa4GlggAAbwAwAAAAAAAAAAAAAAAAAAAAAABoQDAAAAAAAAAAAA AAAAAAAAAAAGhAMAAAAAAAAAAAAAAAAAAAAAAAY4BAAAAAAAAAAAAAAAAAAAAAAABtMDAAAAAAAA AAAAAAAAAAAAAAAGlAMAAAAAAAAAAAAAAAAAAAAAAAaNBAAAAAAAAAAAAAAAAAAAAAAABqAFAAAA AAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAABT2AQAAGtYgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8b1iAAAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xzWIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8A AAD/HdYgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP801gYAAQoDbABh9gMAAAADTxMA AFoTAABhEwAAaBMAAG8TAAB9EwAAjBMAAI0TAACbEwAAqBMAAKoTAAC4EwAA+QAAAAAAAAAAAAAA APkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAAAu4EwAA uRMAAM4TAADgEwAAI+wBAAAAAAAAAAAAAB0AAAAAAAAAAAAAAAAdAAAAAAAAAAAAAAAAAAAABgAA FiQBSWYBAAAAANsAABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI 1rQACJT/hAMIB4wKxA6XEisWuBpYIAAG8AMAAAAAAAAAAAAAAAAAAAAAAAaEAwAAAAAAAAAAAAAA AAAAAAAABoQDAAAAAAAAAAAAAAAAAAAAAAAGOAQAAAAAAAAAAAAAAAAAAAAAAAbTAwAAAAAAAAAA AAAAAAAAAAAABpQDAAAAAAAAAAAAAAAAAAAAAAAGjQQAAAAAAAAAAAAAAAAAAAAAAAagBQAAAAAA AAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAU9gEAABrWIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YgAAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8c1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA /x3WIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAAA+ATAADt EwAA+xMAAAkUAAAXFAAAJRQAADEUAAAzFAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAAAHMxQAADQU AABAFAAARxQAACMoAQAAAAAAAAAAAAAdAAAAAAAAAAAAAAAAHQAAAAAAAAAAAAAAAAAAAAYAABYk AUlmAQAAAADbAAAWJAEXJAFJZgEAAAAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNa0 AAiU/4QDCAeMCsQOlxIrFrgaWCAABvADAAAAAAAAAAAAAAAAAAAAAAAGhAMAAAAAAAAAAAAAAAAA AAAAAAaEAwAAAAAAAAAAAAAAAAAAAAAABjgEAAAAAAAAAAAAAAAAAAAAAAAG0wMAAAAAAAAAAAAA AAAAAAAAAAaUAwAAAAAAAAAAAAAAAAAAAAAABo0EAAAAAAAAAAAAAAAAAAAAAAAGoAUAAAAAAAAA AAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAFPYBAAAa1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/xvWIAAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8AAAD/HNYgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8d 1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2AwAAAANHFAAASRQA AE8UAABRFAAAVxQAAFkUAABfFAAAYRQAAGkUAABrFAAAdBQAAH0UAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA +QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAWJAFJZgEAAAAAC30UAAB+FAAA iBQAAJMUAAAjwAEAAAAAAAAAAAAAHQAAAAAAAAAAAAAAAB0AAAAAAAAAAAAAAAAAAAAGAAAWJAFJ ZgEAAAAA2wAAFiQBFyQBSWYBAAAAApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWtAAI lP+EAwgHjArEDpcSKxa4GlggAAbwAwAAAAAAAAAAAAAAAAAAAAAABoQDAAAAAAAAAAAAAAAAAAAA AAAGhAMAAAAAAAAAAAAAAAAAAAAAAAY4BAAAAAAAAAAAAAAAAAAAAAAABtMDAAAAAAAAAAAAAAAA AAAAAAAGlAMAAAAAAAAAAAAAAAAAAAAAAAaNBAAAAAAAAAAAAAAAAAAAAAAABqAFAAAAAAAAAAAA AAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA ABT2AQAAGtYgAAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8b1iAAAAD/AAAA/wAAAP8A AAD/AAAA/wAAAP8AAAD/AAAA/xzWIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/HdYg AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP801gYAAQoDbABh9gMAAAADkxQAAJoUAACl FAAAphQAALEUAACzFAAAwhQAANAUAADeFAAA7BQAAO0UAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAAArtFAAA7hQAAO8U AADxFAAAIwAAAAAAAAAAAAAAACEAAAAAAAAAAAAAAAAhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AQAAANsAABYkARckAUlmAQAAAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1rQACJT/ hAMIB4wKxA6XEisWuBpYIAAG8AMAAAAAAAAAAAAAAAAAAAAAAAaEAwAAAAAAAAAAAAAAAAAAAAAA BoQDAAAAAAAAAAAAAAAAAAAAAAAGOAQAAAAAAAAAAAAAAAAAAAAAAAbTAwAAAAAAAAAAAAAAAAAA AAAABpQDAAAAAAAAAAAAAAAAAAAAAAAGjQQAAAAAAAAAAAAAAAAAAAAAAAagBQAAAAAAAAAAAAAA AAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU 9gEAABrWIAAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/G9YgAAAA/wAAAP8AAAD/AAAA /wAAAP8AAAD/AAAA/wAAAP8c1iAAAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/AAAA/x3WIAAA AP8AAAD/AAAA/wAAAP8AAAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDAAAAA/EUAAD5FAAA+hQA AAMVAAAgFQAAOhUAAGQVAACUFQAAlRUAAJ4VAAC3FQAAwBUAAMkVAADjFQAA/BUAABUWAAAfFgAA SBYAAFwWAAB0FgAAiRYAAJ0WAACmFgAAxBYAAM0WAADWFgAA7xYAAAsXAAAdFwAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADz AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA8wAAAAAA AAAAAAAAAPMAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAA AADzAAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8wAA AAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPMAAAAAAAAA AAAAAADzAAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA 8wAAAAAAAAAAAAAAAAAAAAAAAAUAAAomAQtGAwAFAAAKJgALRgMAAAEAAAAcHRcAAEEXAABKFwAA ZRcAAIQXAACNFwAAqBcAAL0XAADXFwAA4BcAAAgYAAARGAAAGxgAAEUYAABOGAAAVxgAAI8YAACY GAAAoRgAALcYAADAGAAA6hgAAPMYAAD8GAAAExkAAD8ZAABTGQAAkBkAALcZAAD6AAAAAAAAAAAA AAAA9QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APUAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA9QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAABQAACiYCC0YDAAUAAAomAAtGAwAFAAAKJgELRgMAABy3GQAAzRkAAN4ZAACh GgAAqhoAAL8aAADaGgAAABsAAAkbAAAcGwAAJRsAADwbAABUGwAAXRsAAIcbAACQGwAAmRsAALYb AAC/GwAAyBsAANEbAADfGwAA6BsAAA0cAAAWHAAAFxwAABgcAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPUAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA AAD1AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA9QAA AAAAAAAAAAAAAPUAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAA AAAAAADwAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA 9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAA AAAAAAAAAADqAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BQAAD4TQAl6E0AIFAAAKJgALRgMABQAACiYBC0YDAAUAAAomAgtGAwAAGiAAMZBoAR+w0C8gsOA9 IbAIByKwCAcjkKAFJJCgBSWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAQAAoAAQBpAA8AAwAA AAAAAAAAADgAAEDx/wIAOAAMAAYATgBvAHIAbQBhAGwAAAACAAAAGABDShgAX0gBBGFKGABtSAkE c0gJBHRICQQAAAAAAAAAAAAAAAAAAAAAAAA8AEFA8v+hADwADAAWAEQAZQBmAGEAdQBsAHQAIABQ AGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAANABCAAEA8gA0AAwACQBCAG8A ZAB5ACAAVABlAHgAdAAAAAIADwANAEIqBkNKFABwaP8AAAAAAAAAABgYAAAUAACMAAAAAP////8A AAAAIwAAACQAAAA9AQAAPgEAAP8BAAAAAgAACQIAACYCAABAAgAAagIAAJoCAACbAgAAnAIAAJ0C AACeAgAAtwIAALgCAAC+AgAAyAIAAM0CAADVAgAA3wIAAOYCAADsAgAA9AIAAAADAAABAwAACAMA AA4DAAAaAwAAIgMAACUDAAAuAwAANQMAADoDAABAAwAARwMAAE8DAABWAwAAXAMAAGUDAABsAwAA eQMAAIADAACBAwAAhwMAAI0DAACYAwAAnwMAAKoDAACzAwAAugMAAL8DAADFAwAAzAMAANQDAADb AwAA4AMAAOkDAADwAwAA/QMAAAQEAAAFBAAAFQQAADUEAAA7BAAAPQQAAEMEAABNBAAAWAQAAFsE AABqBAAAdgQAAIIEAACRBAAAkgQAAKEEAACtBAAAuQQAALwEAADIBAAAyQQAAO4EAAD6BAAAAQUA AAgFAAAPBQAAHgUAAC0FAAA5BQAARgUAAEkFAABVBQAAYQUAAGQFAABwBQAAfAUAAH8FAACLBQAA jAUAAJAFAACZBQAAogUAAK0FAAC4BQAAvwUAAMUFAADMBQAA2wUAAPQFAAABBgAAAwYAAB8GAAAg BgAALAYAADsGAAA8BgAAPQYAAFAGAABbBgAAYgYAAGgGAABvBgAAeAYAAHoGAAB7BgAAigYAAJYG AACgBgAApQYAAKYGAAC0BgAAwAYAANsGAADcBgAA7QYAAPgGAAD/BgAADAcAABsHAAAuBwAAOQcA AD0HAABKBwAATAcAAFoHAABbBwAAYwcAAHcHAACBBwAAigcAAJcHAACkBwAAswcAAL8HAADLBwAA 5QcAAP8HAAAACAAAHwgAACgIAAAzCAAAOggAAEEIAABICAAAWAgAAGcIAABzCAAAfwgAAIEIAACb CAAAqQgAAKoIAACrCAAAuwgAAMYIAADRCAAA1AgAAN8IAADmCAAA5wgAAO4IAAD1CAAABAkAABIJ AAAeCQAAOAkAAEYJAABHCQAASAkAAFsJAABnCQAAbgkAAHUJAAB8CQAAhwkAAIkJAACTCQAArAkA AK0JAAC6CQAAvAkAAMkJAADtCQAA+gkAABMKAAAUCgAAFQoAADsKAABHCgAATgoAAFsKAABiCgAA fQoAAIwKAACZCgAAnAoAAKgKAACzCgAAtwoAAMMKAADQCgAA0woAAN8KAADgCgAA7QoAAPgKAAD/ CgAADQsAABwLAAAqCwAANwsAADoLAABGCwAAVAsAAGALAABtCwAAbgsAAHoLAAB7CwAAigsAAJwL AACqCwAAuAsAAMYLAADTCwAA1QsAAOELAADvCwAA+wsAABYMAAAXDAAANwwAAEIMAABJDAAAVgwA AFcMAABlDAAAbgwAAHsMAACHDAAAkwwAAJUMAACiDAAApAwAAKUMAADRDAAA3AwAAOMMAADxDAAA Ag0AABANAAAdDQAAHw0AACsNAABGDQAAUg0AAGANAABhDQAAZw0AAG0NAAB7DQAAhg0AAI0NAACb DQAAqg0AALcNAADFDQAA0Q0AAN8NAADrDQAA7A0AAPwNAAAKDgAADA4AAA0OAAAhDgAAMw4AAEEO AABQDgAAag4AAHcOAAB6DgAAhg4AAIgOAACWDgAAmA4AAJkOAACoDgAAuw4AAMMOAADKDgAA2A4A APEOAAD/DgAAGQ8AADYPAAA3DwAARg8AAE8PAABaDwAAYQ8AAGgPAABvDwAAfQ8AAIwPAACNDwAA mw8AAKgPAACqDwAAuA8AALkPAADODwAA4A8AAO0PAAD7DwAACRAAABcQAAAlEAAAMRAAADMQAAA0 EAAAQBAAAEcQAABJEAAATxAAAFEQAABXEAAAWRAAAF8QAABhEAAAaRAAAGsQAAB0EAAAfRAAAH4Q AACIEAAAkxAAAJoQAAClEAAAphAAALEQAACzEAAAwhAAANAQAADeEAAA7BAAAO0QAADuEAAA7xAA APEQAAD5EAAA+hAAAAMRAAAgEQAAOhEAAGQRAACUEQAAlREAAJ4RAAC3EQAAwBEAAMkRAADjEQAA /BEAABUSAAAfEgAASBIAAFwSAAB0EgAAiRIAAJ0SAACmEgAAxBIAAM0SAADWEgAA7xIAAAsTAAAd EwAAQRMAAEoTAABlEwAAhBMAAI0TAACoEwAAvRMAANcTAADgEwAACBQAABEUAAAbFAAARRQAAE4U AABXFAAAjxQAAJgUAAChFAAAtxQAAMAUAADqFAAA8xQAAPwUAAATFQAAPxUAAFMVAACQFQAAtxUA AM0VAADeFQAAoRYAAKoWAAC/FgAA2hYAAAAXAAAJFwAAHBcAACUXAAA8FwAAVBcAAF0XAACHFwAA kBcAAJkXAAC2FwAAvxcAAMgXAADRFwAA3xcAAOgXAAANGAAAFhgAABcYAAAaGAAAmAAAAAAwAAAA AAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAA AIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAADIAAwAAAAAAAAAIAA AACAmAEDIAAwAAAAAAACAAAAAACAmAEDIAAwAQAAAAACAAAAAACAmAEDIAAwAgAAAAACAAAAAACA mAEDIAAwAwAAAAACAAAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAmQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAmQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAmQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAmQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAmQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAmQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAAAAAwAAAAAAAAAIAAAACAqQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA mQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAmQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACA qQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAmQAA AAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAw AAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAA AAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAA AIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAAAACAqQAAAAAwAAAAAAAAAIAA AACAmQAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACA mAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAADIAAwAAAAAAAAAIAAAACAmAED IAAwAAAAAF4QAAAAAACAmAEDIAAwAQAAAF4QAAAAAACAmAEDIAAwAgAAAF4QAAAAAACAmAEDIAAw AwAAAF4QAAAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAADIAAwAQAAAAAAAIAAAACAmAEDIAAwAAAA APkQAAAAAACAmAEDIAAwAQAAAPkQAAAAAACAmAADIAAwAgAAAAAAAIAAAACAmAEDIAAwAAAAACQR AAAAAACAmAEDIAAwAQAAACQRAAAAAACAmAEDIAAwAgAAACQRAAAAAACAmAADIAAwAwAAAAAAAIAA AACAmAEDIAAwAAAAAHkRAAAAAACAmAEDIAAwAQAAAHkRAAAAAACAmAEDIAAwAgAAAHkRAAAAAACA mAEDIAAwAwAAAHkRAAAAAACAmAEDIAAwBAAAAHkRAAAAAACAmAADIAAwBAAAAAAAAIAAAACAmAED IAAwAAAAAAESAAAAAACAmAEDIAAwAQAAAAESAAAAAACAmAADIAAwBQAAAAAAAIAAAACAmAEDIAAw AAAAADESAAAAAACAmAEDIAAwAQAAADESAAAAAACAmAEDIAAwAgAAADESAAAAAACAmAEDIAAwAwAA ADESAAAAAACAmAADIAAwBgAAAAAAAIAAAACAmAEDIAAwAAAAAKUSAAAAAACAmAEDIAAwAQAAAKUS AAAAAACAmAADIAAwBwAAAAAAAIAAAACAmAEDIAAwAAAAAOgSAAAAAACAmAEDIAAwAQAAAOgSAAAA AACAmAEDIAAwAgAAAOgSAAAAAACAmAADIAAwCAAAAAAAAIAAAACAmAEDIAAwAAAAADsTAAAAAACA mAEDIAAwAQAAADsTAAAAAACAmAADIAAwCQAAAAAAAIAAAACAmAEDIAAwAAAAAHUTAAAAAACAmAED IAAwAQAAAHUTAAAAAACAmAADIAAwCgAAAAAAAIAAAACAmAEDIAAwAAAAALITAAAAAACAmAEDIAAw AQAAALITAAAAAACAmAADIAAwCwAAAAAAAIAAAACAmAEDIAAwAAAAAPwTAAAAAACAmAADIAAwDAAA AAAAAIAAAACAmAEDIAAwAAAAABsUAAAAAACAmAEDIAAwAQAAABsUAAAAAACAmAADIAAwDQAAAAAA AIAAAACAmAEDIAAwAAAAAFcUAAAAAACAmAEDIAAwAQAAAFcUAAAAAACAmAIDIAAwAAAAAHYSAAAA AACAmAIDIAAwAQAAAHYSAAAAAACAmAEDIAAwAgAAAFYSAAAAAACAmAIDIAAwAAAAAPMSAAAAAACA mAIDIAAwAQAAAPMSAAAAAACAmAEDIAAwAwAAAFYSAAAAAACAmAADIAAwDgAAAAAAAIAAAACAmAED IAAwAAAAAAQUAAAAAACAmAEDIAAwAQAAAAQUAAAAAACAmAEDIAAwAgAAAAQUAAAAAACAmAADIAAw DwAAAAAAAIAAAACAmAEDIAAwAAAAAGMUAAAAAACAmAADIAAwEAAAAAAAAIAAAACAmAEDIAAwAAAA AH8UAAAAAACAmAEDIAAwAQAAAH8UAAAAAACAmAADIAAwEQAAAAAAAIAAAACAmAEDIAAwAAAAALcU AAAAAACAmAEDIAAwAQAAALcUAAAAAACAmAADIAAwEgAAAAAAAIAAAACAmAEDIAAwAAAAAPMUAAAA AACAmAEDIAAwAQAAAPMUAAAAAACAmAADIAAwEwAAAAAAAIAAAACAmAEDIAAwAAAAACIVAAAAAACA mAEDIAAwAQAAACIVAAAAAACAmAADIAAwFAAAAAAAAIAAAACAmAEDIAAwAAAAAEIVAAAAAACAmAED IAAwAQAAAEIVAAAAAACAmAAAAAAwAAAAAAAAAIAAAACAmAAAAAAwAAAAAAAAAIAAAACAAAQAABgc AAAQAAAAAAQAALcGAAAABwAACAcAAIAHAACNBwAABAgAADUIAADICAAA+ggAAIsJAACZCQAAPAoA AFsKAADbCgAA+AoAAFoLAAB3CwAA/wsAACgMAACqDAAAxgwAAEcNAABnDQAAFA4AAEcOAADfDgAA +A4AAHoPAACcDwAAFhAAAEIQAACkEAAA3BAAAGARAABtEQAADBIAADMSAACYEgAAuxIAADYTAABP EwAAuBMAAOATAAAzFAAARxQAAH0UAACTFAAA7RQAAPEUAAAdFwAAtxkAABgcAAARAAAAEwAAABQA AAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAA ACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAA MQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/ AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAAAAQAABgcAAASAAAAAAAAAOAGAADjBgAAAAgAAAMI AAASCAAAHggAAKsIAACuCAAAvQgAAMUIAAAaCgAAHgoAAJ0KAACgCgAAgAsAAIMLAAA4DwAARQ8A AJ4RAACtEQAA4xEAAPIRAAA0EgAAQxIAAEgSAABXEgAA3BIAAOgSAABSEwAAXhMAAJUTAAChEwAA YhQAAG4UAABDFQAATBUAAL0VAADGFQAAdBYAAHwWAADHFgAA0xYAACoXAAAzFwAAGhgAAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAAAAAAPAQAAIwEAAEkBAABOAQAACQIAABMCAAAm AgAAKwIAAEACAABIAgAAagIAAHACAACZBQAAoQUAAKMFAACnBQAAygYAAM4GAABSCAAAVggAAL0I AADFCAAAxggAAMsIAADTCQAA1wkAAGwKAABwCgAAhwoAAIsKAACdCgAAoAoAAAUMAAAJDAAA/gwA AAENAAA1DQAAOQ0AAGcNAABsDQAASw4AAE8OAAC9EAAAwRAAAAMRAAANEQAAIBEAACURAAA6EQAA QhEAAGQRAABqEQAAyREAANARAAD8EQAAAxIAABUSAAAeEgAAXBIAAGMSAADWEgAA2xIAAO8SAAD3 EgAACxMAAA8TAABKEwAAURMAAGUTAABrEwAAjRMAAJQTAACoEwAArRMAAL0TAADDEwAAERQAABoU AAChFAAApxQAAD8VAABCFQAAkBUAAJIVAAC3FQAAvBUAAM0VAADSFQAAvxYAAMYWAADaFgAA4hYA ADwXAABDFwAAGhgAAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAAAAAAnQIAAAEGAAACBgAAKAsAACkLAADC CwAAxQsAALkPAAA0EAAAVxAAAFgQAACxEAAAshAAAMAQAADBEAAAzhAAAM8QAAClEgAAzBIAANYS AABAEwAA4BMAABAUAAAbFAAATRQAAJYUAACXFAAA6RQAAPIUAAAJFwAAGxcAACUXAABTFwAAyBcA ABYYAAAXGAAAGhgAAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA BAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAcA//8UAAAACQBTAHUAZQAgAEgAYQByAGUAcwBI AEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBnAHMAXABzAGsA aABcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAdQBcAGkAZQB0AGYAXABpAGQAcgAtAGQAcgBh AGYAdABzAFwAcwB0AGEAdABlAG0AdAAuAGQAbwBjAAkAUwB1AGUAIABIAGEAcgBlAHMAXgBDADoA XABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwAcwBrAGgAXABB AHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEAdABhAFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAG8A cgBkAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAAcwB0AGEAdABl AG0AdAAuAGEAcwBkAAkAUwB1AGUAIABIAGEAcgBlAHMASABDADoAXABEAG8AYwB1AG0AZQBuAHQA cwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwAcwBrAGgAXABNAHkAIABEAG8AYwB1AG0AZQBu AHQAcwBcAHUAXABpAGUAdABmAFwAaQBkAHIALQBkAHIAYQBmAHQAcwBcAHMAdABhAHQAZQBtAHQA LgBkAG8AYwAJAFMAdQBlACAASABhAHIAZQBzAEgAQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABh AG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAHMAawBoAFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMA XAB1AFwAaQBlAHQAZgBcAGkAZAByAC0AZAByAGEAZgB0AHMAXABzAHQAYQB0AGUAbQB0AC4AZABv AGMACQBTAHUAZQAgAEgAYQByAGUAcwBIAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQA IABTAGUAdAB0AGkAbgBnAHMAXABzAGsAaABcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAdQBc AGkAZQB0AGYAXABpAGQAcgAtAGQAcgBhAGYAdABzAFwAcwB0AGEAdABlAG0AdAAuAGQAbwBjAAkA UwB1AGUAIABIAGEAcgBlAHMASABDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBl AHQAdABpAG4AZwBzAFwAcwBrAGgAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAHUAXABpAGUA dABmAFwAaQBkAHIALQBkAHIAYQBmAHQAcwBcAHMAdABhAHQAZQBtAHQALgBkAG8AYwAJAFMAdQBl ACAASABhAHIAZQBzAEgAQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQA aQBuAGcAcwBcAHMAawBoAFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXAB1AFwAaQBlAHQAZgBc AGkAZAByAC0AZAByAGEAZgB0AHMAXABzAHQAYQB0AGUAbQB0AC4AZABvAGMACQBTAHUAZQAgAEgA YQByAGUAcwBIAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUAdAB0AGkAbgBn AHMAXABzAGsAaABcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAdQBcAGkAZQB0AGYAXABpAGQA cgAtAGQAcgBhAGYAdABzAFwAcwB0AGEAdABlAG0AdAAuAGQAbwBjAAkAUwB1AGUAIABIAGEAcgBl AHMASABDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwA cwBrAGgAXABNAHkAIABEAG8AYwB1AG0AZQBuAHQAcwBcAHUAXABpAGUAdABmAFwAaQBkAHIALQBk AHIAYQBmAHQAcwBcAHMAdABhAHQAZQBtAHQALgBkAG8AYwAJAFMAdQBlACAASABhAHIAZQBzAF4A QwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABhAG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAHMAawBo AFwAQQBwAHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwA VwBvAHIAZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAHMAdABh AHQAZQBtAHQALgBhAHMAZAADADV5thKs+dRo/w//D/8P/w//D/8P/w//D/8PEABlUOkgqnwq9P8P /w//D/8P/w//D/8P/w//DxAAAk+RexIyQnb/D/8P/w//D/8P/w//D/8P/w8QAAEAAAAXEAAAAAAA AAAAAABoAQAAAAAAAAsYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEAt/AB AAAAABABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+AgABAC4A AQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+ECAcRhJj+FcYFAAEIBwZehAgHYISY/k9KAwBR SgMAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhNgJEYSY/hXGBQAB2AkGXoTY CWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SoDBGEmP4V xgUAAagMBl6EqAxghJj+T0oEAFFKBABvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgA AA+EeA8RhJj+FcYFAAF4DwZehHgPYISY/k9KAwBRSgMAbygAAQCn8AEAAAAXkAAAAAAAAAAAAABo AQAAAAAAAAsYAAAPhEgSEYSY/hXGBQABSBIGXoRIEmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF5AA AAAAAAAAAAAAaAEAAAAAAAALGAAAD4QYFRGEmP4VxgUAARgVBl6EGBVghJj+T0oEAFFKBABvKAAB AG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E6BcRhJj+FcYFAAHoFwZehOgXYISY/k9K AwBRSgMAbygAAQCn8AEAAAAAEAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhNACEYSY/hXGBQAB0AIG XoTQAmCEmP4CAAAALgABAAAABBABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SgBRGEmP4VxgUAAaAF Bl6EoAVghJj+AgABAC4AAQAAAAKSAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EcAgRhEz/FcYFAAFw CAZehHAIYIRM/wIAAgAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhEALEYSY/hXGBQAB QAsGXoRAC2CEmP4CAAMALgABAAAABJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4QQDhGEmP4VxgUA ARAOBl6EEA5ghJj+AgAEAC4AAQAAAAKSAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+E4BARhEz/FcYF AAHgEAZehOAQYIRM/wIABQAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhLATEYSY/hXG BQABsBMGXoSwE2CEmP4CAAYALgABAAAABJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SAFhGEmP4V xgUAAYAWBl6EgBZghJj+AgAHAC4AAQAAAAKSAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EUBkRhEz/ FcYFAAFQGQZehFAZYIRM/wIACAAuAAEAAAAAEAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhNACEYSY /hXGBQAB0AIGXoTQAmCEmP4CAAAALgABAAAABJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SgBRGE mP4VxgUAAaAFBl6EoAVghJj+AgABAC4AAQAAAAKSAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EcAgR hEz/FcYFAAFwCAZehHAIYIRM/wIAAgAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhEAL EYSY/hXGBQABQAsGXoRAC2CEmP4CAAMALgABAAAABJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4QQ DhGEmP4VxgUAARAOBl6EEA5ghJj+AgAEAC4AAQAAAAKSAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+E 4BARhEz/FcYFAAHgEAZehOAQYIRM/wIABQAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAP hLATEYSY/hXGBQABsBMGXoSwE2CEmP4CAAYALgABAAAABJABAAAAAAAAAAAAaAEAAAAAAAAAGAAA D4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+AgAHAC4AAQAAAAKSAQAAAAAAAAAAAGgBAAAAAAAAABgA AA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM/wIACAAuAAMAAAACT5F7AAAAAAAAAAAAAAAAZVDpIAAA AAAAAAAAAAAAADV5thIAAAAAAAAAAAAAAAD//////////////////wMAAAAAAAAAAAD//wMAAAAS AAEACQQPAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIADwAJBBkACQQbAAkEDwAJBBkA CQQbAAkEDwAJBBkACQQbAAkEEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQA AAAAnQIAAJ4CAAC3AgAAuAIAAL4CAADIAgAAzQIAANUCAADfAgAA5gIAAPQCAAAAAwAAAQMAAA4D AAAaAwAAJQMAADUDAABHAwAAVgMAAGwDAACAAwAAgQMAAI0DAACfAwAAqgMAALoDAADMAwAA2wMA APADAAAEBAAABQQAADUEAAA9BAAATQQAAFsEAAB2BAAAkgQAAK0EAADIBAAAyQQAAO4EAAABBQAA DwUAAB4FAAA5BQAAVQUAAHAFAACLBQAAjAUAAK0FAAC/BQAAzAUAANsFAAD0BQAAAwYAACAGAAA8 BgAAPQYAAFAGAABiBgAAbwYAAHsGAACWBgAApgYAAMAGAADbBgAA3AYAAO0GAAD/BgAADAcAABsH AAAuBwAAPQcAAEwHAABaBwAAWwcAAHcHAACKBwAAlwcAAKQHAAC/BwAAywcAAOUHAAD/BwAAAAgA ACgIAAA6CAAASAgAAFgIAABzCAAAgQgAAJsIAACqCAAAqwgAANQIAADnCAAA9QgAAAQJAAASCQAA HgkAADgJAABHCQAASAkAAFsJAABuCQAAfAkAAIkJAACtCQAAyQkAAO0JAAAUCgAAFQoAADsKAABO CgAAYgoAAH0KAACMCgAAqAoAAMMKAADfCgAA4AoAAO0KAAD/CgAADQsAABwLAAAqCwAARgsAAGAL AAB6CwAAewsAAIoLAACcCwAAqgsAALgLAADGCwAA4QsAAPsLAAAWDAAAFwwAADcMAABJDAAAVwwA AGUMAABuDAAAhwwAAJUMAACkDAAApQwAANEMAADjDAAA8QwAAAINAAAQDQAAKw0AAEYNAABgDQAA YQ0AAHsNAACNDQAAmw0AALcNAADRDQAA7A0AAPwNAAAMDgAADQ4AACEOAAAzDgAAQQ4AAFAOAABq DgAAeg4AAIgOAACYDgAAmQ4AAKgOAAC7DgAAyg4AANgOAADxDgAA/w4AABkPAAA2DwAANw8AAE8P AABhDwAAbw8AAH0PAACNDwAAmw8AAKoPAAC4DwAAuQ8AAM4PAADgDwAA7Q8AAPsPAAAJEAAAFxAA ACUQAAAzEAAANBAAAEAQAABJEAAAURAAAFkQAABhEAAAaxAAAHQQAAB9EAAAfhAAAIgQAACaEAAA phAAALMQAADCEAAA0BAAAN4QAADtEAAA7hAAABoYAAAAAAAACAAAAAIBAAACAQAAngEAAAIBAAAC AQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIB AAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEA AAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAA ngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAAC AQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIB AAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEA AAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAA AgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAAC AQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIB AAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEA AAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAA AgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAAC AQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIB AAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEA AAIBAAACAQAAAgEAAAIBAAACAQAAngEAAAIBAAACAQAAAgEAAAIBAAACAQAAAgEAAAIBAAACAQAA lgEAAP9AA4ABAP8BAAD/AQAAqFq2AgEAAQD/AQAAAAAAAP8BAAAAAAAAAhAAAAAAAAAAGBgAAEAB AAgAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAAAAD//wEAAAAAAP//AAAC AP//AAAAAP//AAACAP//AAAAAAUAAABHFpABAAACAgYDBQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8B AAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAA AAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEh3oAIAAA AIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAOwaQAQIABQAAAAAAAAAAAAAAAAAAAAAQAAAA AAAAAAAAAACAAAAAAFcAaQBuAGcAZABpAG4AZwBzAAAAPzWQAQAAAgcDCQICBQIEBId6ACAAAACA CAAAAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAACIABABxCIgYAPDQAgAAaAEA AAAAay1bJrU7W2ZmO1tmPAAjAQAAfAMAAN4TAAABAAoAAAAEAAMQKgAAAAAAAAAAAAAAAQABAAAA AQAAAAAAAAAhAwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIB6AFtAC0AIGBMjAAABAA GQBkAAAAGQAAAGUYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACa AgAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAQyg1EA8BAACAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD//xIAAAAAAAAABQBFAHYAZQBuAHQAAAAAAAAACQBTAHUAZQAgAEgAYQBy AGUAcwAJAFMAdQBlACAASABhAHIAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAiAEA ABIAAAABAAAAmAAAAAIAAACgAAAAAwAAALAAAAAEAAAAvAAAAAUAAADQAAAABgAAANwAAAAHAAAA 6AAAAAgAAAD8AAAACQAAABABAAASAAAAHAEAAAoAAAA4AQAACwAAAEQBAAAMAAAAUAEAAA0AAABc AQAADgAAAGgBAAAPAAAAcAEAABAAAAB4AQAAEwAAAIABAAACAAAA5AQAAB4AAAAGAAAARXZlbnQA ZgAeAAAAAQAAAAB2ZW4eAAAACgAAAFN1ZSBIYXJlcwAgAB4AAAABAAAAAHVlIB4AAAABAAAAAHVl IB4AAAALAAAATm9ybWFsLmRvdAAAHgAAAAoAAABTdWUgSGFyZXMAAAAeAAAAAwAAADYwACAeAAAA EwAAAE1pY3Jvc29mdCBXb3JkIDkuMAAAQAAAAACS+KYoAAAAQAAAAAD0d1O7Z8EBQAAAAAASmL9s ZsEBQAAAAAB2rc3FZ8EBAwAAAAEAAAADAAAAfAMAAAMAAADeEwAAAwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/ AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAAAQBAAAMAAAAAQAA AGgAAAAPAAAAcAAAAAUAAACUAAAABgAAAJwAAAARAAAApAAAABcAAACsAAAACwAAALQAAAAQAAAA vAAAABMAAADEAAAAFgAAAMwAAAANAAAA1AAAAAwAAADmAAAAAgAAAOQEAAAeAAAAGwAAAE5leHRI b3AgVGVjaG5vbG9naWVzLCBJbmMuAAADAAAAKgAAAAMAAAAKAAAAAwAAAGUYAAADAAAAMhEJAAsA AAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAGAAAARXZlbnQADBAAAAIAAAAe AAAABgAAAFRpdGxlAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMA AAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAA ABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAA IAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAu AAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwA AAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAA/v///0gAAABJAAAASgAA AEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAA WQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAAZQAAAGYAAABn AAAAaAAAAGkAAABqAAAA/v///2wAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAAD+////dAAAAHUA AAB2AAAAdwAAAHgAAAB5AAAAegAAAP7////9////fQAAAP7////+/////v///1IAbwBvAHQAIABF AG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB //////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAACC0u9nFZ8EBfwAAAIAAAAAA AAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA4AAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABHAAAAQ0cAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQUAAAD//////////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAijAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAawAAAAAQAAAAAAAABQBEAG8AYwB1AG0A ZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH/ //////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABzAAAAABAAAAAA AAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAgtLvZxWfBASC0u9nFZ8EBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA/v////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////wEA/v8DCgAA/////wYJ AgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQ AAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --=====================_4999358==_ Content-Type: text/plain; charset="us-ascii"; format=flowed --=====================_4999358==_-- 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 RAA18285 for ; Wed, 16 Jan 2002 17:32:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 47DEA91293; Wed, 16 Jan 2002 17:31:33 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21C9991294; Wed, 16 Jan 2002 17:31:33 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DED6191293 for ; Wed, 16 Jan 2002 17:31:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id A49095DD97; Wed, 16 Jan 2002 17:31:24 -0500 (EST) Delivered-To: idr@merit.edu Received: from titanium.zebra.org (unknown [209.11.132.18]) by segue.merit.edu (Postfix) with ESMTP id 223C45DD90 for ; Wed, 16 Jan 2002 17:31:24 -0500 (EST) Received: from titanium.zebra.org (IDENT:kunihiro@localhost [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id QAA02976; Wed, 16 Jan 2002 16:33:09 -0500 Date: Wed, 16 Jan 2002 13:33:09 -0800 Message-ID: From: Kunihiro Ishiguro To: Susan Hares Cc: Vincent Gillet , Yakov Rekhter , Jeffrey Haas , idr@merit.edu Subject: Re: bgp4-17 Cease subcode In-Reply-To: <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> References: <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <87advfjcqi.wl@vaio.zebra.org> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.1 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk >If you have a specific comment on the text of the state machine, >can you propose the concerns you have as a revision to the text. OK. Let me do some updates. >PS -- I just love last call on a draft... It's when > everyone finally reads a new section ;-)... Exactly... And engineers suddenly realize how important it is ;-). -- Kunihiro Ishiguro Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA17883 for ; Wed, 16 Jan 2002 17:17:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 67BEE91291; Wed, 16 Jan 2002 17:16:59 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 354EA91292; Wed, 16 Jan 2002 17:16: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 2543F91291 for ; Wed, 16 Jan 2002 17:16:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 06DE15DD95; Wed, 16 Jan 2002 17:16:58 -0500 (EST) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id D5ECF5DD90 for ; Wed, 16 Jan 2002 17:16:57 -0500 (EST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id F0CD7CAB7A; Wed, 16 Jan 2002 14:16:56 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id 9294015D3C1; Wed, 16 Jan 2002 14:16:56 -0800 (PST) To: Jeffrey Haas Cc: Manav Bhatia , idr@merit.edu Subject: Re: Maximum Prefix Limit In-Reply-To: Message from Jeffrey Haas of "Wed, 16 Jan 2002 10:35:29 EST." <20020116103528.A18433@nexthop.com> Date: Wed, 16 Jan 2002 14:16:56 -0800 From: Enke Chen Message-Id: <20020116221656.9294015D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Jeff: > Date: Wed, 16 Jan 2002 10:35:29 -0500 > From: Jeffrey Haas > To: Manav Bhatia > Cc: idr@merit.edu > Subject: Re: Maximum Prefix Limit > Message-ID: <20020116103528.A18433@nexthop.com> > References: <03b001c19e4e$aa86e750$b4036c6b@Manav> [snip] > Enke, > > MPBGP's NLRI sends AFI,SAFI as a 3 octet field. The capability > advertisement version sends it as 4 octets with the third octet > being "reserved". Please note that the Graceful Restart draft also uses 3 bytes. > > Did we want to reserve the space in the notification data for > the "reserved" portion or just stick to what we have in the NLRI? The extra byte is not needed. -- Enke > > > 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 OAA12721 for ; Wed, 16 Jan 2002 14:19:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AA5DC9128C; Wed, 16 Jan 2002 14:19:24 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75E689128F; Wed, 16 Jan 2002 14:19:24 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F5299128C for ; Wed, 16 Jan 2002 14:19:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 22A8B5DDD9; Wed, 16 Jan 2002 14:19:23 -0500 (EST) Delivered-To: idr@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 90C295DDCA for ; Wed, 16 Jan 2002 14:19:22 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26961; Wed, 16 Jan 2002 11:19:20 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.130]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id LAA06901; Wed, 16 Jan 2002 11:20:32 -0800 (PST) Received: from eng.sun.com (sappey.Eng.Sun.COM [129.146.85.69]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0GJJHqS506424; Wed, 16 Jan 2002 11:19:17 -0800 (PST) Message-ID: <3C45D218.B037BB42@eng.sun.com> Date: Wed, 16 Jan 2002 11:18:48 -0800 From: Alain Durand X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: idr@merit.edu Cc: francis.dupont@rennes.enst-bretagne.fr Subject: IPv6 Router ID draft Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk I just published draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt and I would like to request this working group to consider it as a wg item candidate for BCP. - Alain. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : BGP4 router ID for IPv6 only routers Author(s) : F. Dupont, A. Durand Filename : draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt Pages : 3 Date : 15-Jan-02 BGP4 [1] uses a 32 bit field to identify router (the so called 'router-IDs'). In IPv4 domain, an IPv4 address of the router is typically used in this field. In an IPv6 routing domain, routers may very well not have any IPv4 Addresses. This document provides a simple way to form a globally Unique ID in such a case. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt 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 OAA12579 for ; Wed, 16 Jan 2002 14:12:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 70CF49128E; Wed, 16 Jan 2002 14:11:43 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 407EA9128F; Wed, 16 Jan 2002 14:11: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 4AC859128E for ; Wed, 16 Jan 2002 14:11:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1D7CF5DDD9; Wed, 16 Jan 2002 14:11:42 -0500 (EST) Delivered-To: idr@merit.edu Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id DEABB5DDCA for ; Wed, 16 Jan 2002 14:11:41 -0500 (EST) Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id 2FF0C3F6C; Wed, 16 Jan 2002 11:14:29 -0800 (PST) Received: from khonsu.sw.nexsi.com (cscovpn3.nexsi.com [172.16.213.3]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id LAA07487; Wed, 16 Jan 2002 11:10:51 -0800 Date: Wed, 16 Jan 2002 11:10:47 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <114185201786.20020116111047@nexsi.com> To: Susan Hares Cc: Kunihiro Ishiguro , Vincent Gillet , Yakov Rekhter , Jeffrey Haas , Subject: Re: bgp4-17 Cease subcode In-Reply-To: <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> References: <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <20020115140711.GA23937@opentransit.net> <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Sue, Introduction of the IdleHold does change the FSM, and I thought we wanted the spec to reflect the current running code as much as possible. I agree with Russ and Ishi---the new state does not seem to be necessary, instead it could be as easy as holding the session in Idle and giving clue on how to make the delay exponential. I don't think there's an interoperability issue if people decide to keep the session in Idle using different internal mechanisms. Regards, -- Alex Zinin Wednesday, January 16, 2002, 6:04:36 AM, Susan Hares wrote: > Kunihiro: > We are not changing the FSM so I would be surprised if the change > was anything but modest. Usually specifications with "no big" deal get > interpreted differently. Inter-operable code means you tie down the details. > The comment was on the clarity of the specification. > If you have a specific comment on the text of the state machine, > can you propose the concerns you have as a revision to the text. > Sue > PS -- I just love last call on a draft... It's when > everyone finally reads a new section ;-)... > At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote: >> >> > Is the expoential backoff in the FSM in current implementations? >> >> >> >> I guess we are going to find this out as part of the implementation >> >> report. And if it is not in (at least two) current implementations, >> >> we'll take it out of the text. >> > >> >I implemented Cease subcode in zebra-0.92a but not exponential backoff. >> >I checked that new subcode does not put other BGP stack in trouble >> >(checked Cisco and Juniper). >> >>First of all, sorry for talking about specific implementation. In >>Zebra implementation we've implemented Cease subcode. The code is in >>CVS repository. I'll prepare a release version for that. >> >>And also we've implemented exponetial backoff. It is done without >>introducing new FSM status. It is not a big deal. Just check a flag >>in a few functions. >>Exponential backoff is a good feature. I can't understand why it >>require change to FSM. 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 KAA06665 for ; Wed, 16 Jan 2002 10:38:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 59C94912BC; Wed, 16 Jan 2002 10:37:39 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29682912BD; Wed, 16 Jan 2002 10:37: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 E77D2912BC for ; Wed, 16 Jan 2002 10:37:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id CC3D15DDFE; Wed, 16 Jan 2002 10:37:36 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 829105DDFA for ; Wed, 16 Jan 2002 10:37:36 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0GFbR328199; Wed, 16 Jan 2002 10:37:27 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0GFbQJ18479; Wed, 16 Jan 2002 10:37:26 -0500 (EST) Date: Wed, 16 Jan 2002 10:37:26 -0500 From: Jeffrey Haas To: Vincent Gillet Cc: idr@merit.edu Subject: Re: Maximum Prefix Limit Message-ID: <20020116103726.B18433@nexthop.com> References: <03b001c19e4e$aa86e750$b4036c6b@Manav> <20020116153127.GE1786@opentransit.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020116153127.GE1786@opentransit.net>; from vgi@zoreil.com on Wed, Jan 16, 2002 at 04:31:27PM +0100 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Wed, Jan 16, 2002 at 04:31:27PM +0100, Vincent Gillet wrote: > bgpPeerLastError OID is nice to know from remote peer. Present in the new MIB. > We may need a "bgpPeerSentLastError" to know the exact reason we ceased > BGP session. Good suggestion. This goes in the new MIB. > Vincent. -- 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 KAA06570 for ; Wed, 16 Jan 2002 10:36:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3A80691223; Wed, 16 Jan 2002 10:36:04 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 12965912BB; Wed, 16 Jan 2002 10:36:03 -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 B3E4191223 for ; Wed, 16 Jan 2002 10:36:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9A8375DDFA; Wed, 16 Jan 2002 10:36:01 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 543155DDA5 for ; Wed, 16 Jan 2002 10:36:01 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0GFZU328130; Wed, 16 Jan 2002 10:35:30 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0GFZTF18471; Wed, 16 Jan 2002 10:35:29 -0500 (EST) Date: Wed, 16 Jan 2002 10:35:29 -0500 From: Jeffrey Haas To: Manav Bhatia Cc: idr@merit.edu Subject: Re: Maximum Prefix Limit Message-ID: <20020116103528.A18433@nexthop.com> References: <03b001c19e4e$aa86e750$b4036c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <03b001c19e4e$aa86e750$b4036c6b@Manav>; from mnvbhatia@yahoo.com on Wed, Jan 16, 2002 at 10:58:43AM +0530 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Wed, Jan 16, 2002 at 10:58:43AM +0530, Manav Bhatia wrote: > - Should there be counters for individual SAFI or should there be a > consolidated one for the entire AFI? Those of us working on the v2MIB would like to hear opinions on this! > We must have a mechanism wherein we can inform admin guys in the network > leaking routes causing an overflow for us. This issue was brought up some > time back in the list but i saw no apparent conclusion to the whole > discussion ;-) > > Is there any intention of introducing a new cease sub-code in the > NOTIFICATION message which will inform both the parties of the reason why > the session was brought down! SNMP traps are certainly appropriate here. The NOTIFICATION subcode has already been discussed. One thing that I'm noting: Enke, MPBGP's NLRI sends AFI,SAFI as a 3 octet field. The capability advertisement version sends it as 4 octets with the third octet being "reserved". Did we want to reserve the space in the notification data for the "reserved" portion or just stick to what we have in the NLRI? > 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 KAA06347 for ; Wed, 16 Jan 2002 10:33:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6EE89912BA; Wed, 16 Jan 2002 10:32:11 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C0A4912BB; Wed, 16 Jan 2002 10:32: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 4D046912BA for ; Wed, 16 Jan 2002 10:32:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id ECD855DE12; Wed, 16 Jan 2002 10:32:05 -0500 (EST) Delivered-To: idr@merit.edu Received: from utopia.opentransit.net (utopia.opentransit.net [193.251.151.78]) by segue.merit.edu (Postfix) with ESMTP id 052165DDA5 for ; Wed, 16 Jan 2002 10:32:04 -0500 (EST) Received: from utopia.opentransit.net (localhost [127.0.0.1]) by utopia.opentransit.net (8.12.1/8.12.1/Debian -5) with ESMTP id g0GFVR77002357; Wed, 16 Jan 2002 16:31:27 +0100 Received: (from vgi@localhost) by utopia.opentransit.net (8.12.1/8.12.1/Debian -5) id g0GFVRmQ002356; Wed, 16 Jan 2002 16:31:27 +0100 Date: Wed, 16 Jan 2002 16:31:27 +0100 From: Vincent Gillet To: Manav Bhatia Cc: idr@merit.edu Subject: Re: Maximum Prefix Limit Message-ID: <20020116153127.GE1786@opentransit.net> References: <03b001c19e4e$aa86e750$b4036c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <03b001c19e4e$aa86e750$b4036c6b@Manav> User-Agent: Mutt/1.3.24i Sender: owner-idr@merit.edu Precedence: bulk mnvbhatia@yahoo.com disait : > Hi, > > - Should the BGP session be restarted after some configured Idle Timer > expiration? As Enke stated, this is important question for implementation. Vendors are having different behaviour today but are also adding feature to their BGP stack to let user select the behaviour they want. (on Hold, retry timers, ....). Vendors are aware of this question. > Is there any intention of introducing a new cease sub-code in the > NOTIFICATION message which will inform both the parties of the reason why > the session was brought down! Cease sub-code would be available via SNMP with existing BGP MIB. It would inform that remote BGP closed for that reason, but there is no way to know via existing MIB that your box received too many prefixes and closed BGP. bgpPeerLastError OID is nice to know from remote peer. We may need a "bgpPeerSentLastError" to know the exact reason we ceased BGP session. This is a talk we need to run for bgp4-mibv2 draft. Vincent. 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 KAA05065 for ; Wed, 16 Jan 2002 10:07:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3A194912B8; Wed, 16 Jan 2002 10:07:20 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 03B85912B9; Wed, 16 Jan 2002 10:07:19 -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 D3619912B8 for ; Wed, 16 Jan 2002 10:07:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id BA96C5DDFE; Wed, 16 Jan 2002 10:07:18 -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 184945DDC1 for ; Wed, 16 Jan 2002 10:07:18 -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 g0GF6w006475; Wed, 16 Jan 2002 10:06:58 -0500 (EST) Received: from 192.168.0.185 by tenornet.com; WED, 16 Jan 2002 10:03:46 -0700 Received: by newman.tenornet.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Jan 2002 10:03:45 -0500 Message-ID: <6B190B34070BD411ACA000B0D0214E560165B682@newman.tenornet.com> From: "Tsillas, Jim" To: "'Xie, Feng'" , "'idr@merit.edu'" Cc: "'fxie@fore.com'" Subject: RE: BGP Route Refresh & Soft-Reconfiguration Date: Wed, 16 Jan 2002 10:03:41 -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 Feng, Much of this is implementation dependent and can be done differently but I'll take a stab at it. Note that when routes pass import policy they become part of the BGP route selection process (RIB-in) and should be stored even if they are not the best route. The reason is that the best route may be withdrawn or modified such that a new best route will be selected from the candidates. If you don't store the non-best you will not be able to select a new best. Using route-refresh to get your non-best would require a refresh from all peers whenever a route is withdrawn or changed: do you really want to do this? To answer question 2, in order for soft-reconfiguration (on input policy) to work, you need to keep the routes which are excluded due to policy. Also, if the routes are modified by import policy, you also need to keep the original attributes. If you don't keep this information you can't guarrantee that soft-reconfiguration will work. Route-refresh allows you to discard this extra information since you can now rely on your peer to resubmit the routes (which will get the new input policy applied to them as they are received). The advantage of using route-refresh depends on how much routing information is excluded or modified due to input policy. It could be significant and could consume alot of resources. You could let you user decide through configuration whether soft-reconfiguration will use saved routing information or route-refresh. -----Original Message----- From: Xie, Feng [mailto:Feng.Xie@marconi.com] Sent: Wednesday, January 16, 2002 9:53 AM To: 'idr@merit.edu' Cc: 'fxie@fore.com' Subject: BGP Route Refresh & Soft-Reconfiguration Hi, I have two questions with respect to BGP Route Refresh (RFC2918). 1. Suppose Route Refresh Capability is negotiated between two BGP peers, P1 and P2. P2 has some BGP import policies to block some routes from P1 and accept others. With Route Refresh, should P2 store the routes from P1 which are accepted by P1 import policies even if they may not be selected by the decision process on P2? Or should P2 only store the routes from P1 which are selected by the decision process on P2 and discard all others? If we only store the best routes, once the best routes are withdrawn, we have to contact all peers to reselect the best routes since I don't keep the non-best routes. Is this understanding correct? 2. What is the advantages of Route Refresh over Soft-Reconfiguration? Let me reuse my previous example. My understanding is that in Soft-Reconfiguration P2 stores all routes from P1 even if some of them or all of them are blocked by the import policies but in Route Refresh P2 only stores those routes which are accepted by its import policies. If this is ture, then Route Refresh does not buy you too much if there is no blocked route since in both Route Refresh and Soft-Reconfiguration, at least one copy of a route from P1 will be stored on P2. Feng Xie 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 JAA04677 for ; Wed, 16 Jan 2002 09:54:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4DE06912B5; Wed, 16 Jan 2002 09:53:30 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 177D0912B6; Wed, 16 Jan 2002 09:53: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 BC9A9912B5 for ; Wed, 16 Jan 2002 09:53:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id A18345DDFB; Wed, 16 Jan 2002 09:53:28 -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 242CB5DDCA for ; Wed, 16 Jan 2002 09:53:28 -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 JAA20519 for ; Wed, 16 Jan 2002 09:53:16 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA09735 for ; Wed, 16 Jan 2002 09:53:16 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Jan 2002 09:53:13 -0500 Message-ID: <39469E08BD83D411A3D900204840EC55576F13@vie-msgusr-01.dc.fore.com> From: "Xie, Feng" To: "'idr@merit.edu'" Cc: "'fxie@fore.com'" Subject: BGP Route Refresh & Soft-Reconfiguration Date: Wed, 16 Jan 2002 09:53: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 Hi, I have two questions with respect to BGP Route Refresh (RFC2918). 1. Suppose Route Refresh Capability is negotiated between two BGP peers, P1 and P2. P2 has some BGP import policies to block some routes from P1 and accept others. With Route Refresh, should P2 store the routes from P1 which are accepted by P1 import policies even if they may not be selected by the decision process on P2? Or should P2 only store the routes from P1 which are selected by the decision process on P2 and discard all others? If we only store the best routes, once the best routes are withdrawn, we have to contact all peers to reselect the best routes since I don't keep the non-best routes. Is this understanding correct? 2. What is the advantages of Route Refresh over Soft-Reconfiguration? Let me reuse my previous example. My understanding is that in Soft-Reconfiguration P2 stores all routes from P1 even if some of them or all of them are blocked by the import policies but in Route Refresh P2 only stores those routes which are accepted by its import policies. If this is ture, then Route Refresh does not buy you too much if there is no blocked route since in both Route Refresh and Soft-Reconfiguration, at least one copy of a route from P1 will be stored on P2. Feng Xie 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 JAA03572 for ; Wed, 16 Jan 2002 09:05:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7C18391283; Wed, 16 Jan 2002 09:05:22 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F7D291284; Wed, 16 Jan 2002 09:05: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 0AF2091283 for ; Wed, 16 Jan 2002 09:05:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id D67035DDDD; Wed, 16 Jan 2002 09:05:20 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id BB9C75DDCA for ; Wed, 16 Jan 2002 09:05:20 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0GE4b325353; Wed, 16 Jan 2002 09:04:37 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020116090028.039d2fa8@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 16 Jan 2002 09:04:36 -0500 To: Kunihiro Ishiguro From: Susan Hares Subject: Re: bgp4-17 Cease subcode Cc: Vincent Gillet , Yakov Rekhter , Jeffrey Haas , idr@merit.edu In-Reply-To: <87advfjcqi.wl@vaio.zebra.org> References: <20020115140711.GA23937@opentransit.net> <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <20020115140711.GA23937@opentransit.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Kunihiro: We are not changing the FSM so I would be surprised if the change was anything but modest. Usually specifications with "no big" deal get interpreted differently. Inter-operable code means you tie down the details. The comment was on the clarity of the specification. If you have a specific comment on the text of the state machine, can you propose the concerns you have as a revision to the text. Sue PS -- I just love last call on a draft... It's when everyone finally reads a new section ;-)... At 05:39 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote: > >> > Is the expoential backoff in the FSM in current implementations? > >> > >> I guess we are going to find this out as part of the implementation > >> report. And if it is not in (at least two) current implementations, > >> we'll take it out of the text. > > > >I implemented Cease subcode in zebra-0.92a but not exponential backoff. > >I checked that new subcode does not put other BGP stack in trouble > >(checked Cisco and Juniper). > >First of all, sorry for talking about specific implementation. In >Zebra implementation we've implemented Cease subcode. The code is in >CVS repository. I'll prepare a release version for that. > >And also we've implemented exponetial backoff. It is done without >introducing new FSM status. It is not a big deal. Just check a flag >in a few functions. >Exponential backoff is a good feature. I can't understand why it >require change to FSM. 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 IAA03354 for ; Wed, 16 Jan 2002 08:57:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5A09991282; Wed, 16 Jan 2002 08:57:05 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25AA5912B4; Wed, 16 Jan 2002 08:57:05 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E942E91282 for ; Wed, 16 Jan 2002 08:57:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id C43635DE19; Wed, 16 Jan 2002 08:57:03 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id A82495DE17 for ; Wed, 16 Jan 2002 08:57:03 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0GDuP325106; Wed, 16 Jan 2002 08:56:25 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020116085531.039c5a48@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 16 Jan 2002 08:56:24 -0500 To: Russ White From: Susan Hares Subject: Re: editorial fixes Cc: Susan Hares , Yakov Rekhter , idr@merit.edu In-Reply-To: References: <5.0.0.25.0.20020115191918.029259a8@mail.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Russ: Alex and are discussing his text. next day or two is a good comment. Sue At 10:27 PM 1/15/2002 -0500, Russ White wrote: >I think Alex is suggesting alternate text altogether--we should >see it in the next day or two. > >Russ > >On Tue, 15 Jan 2002, Susan Hares wrote: > > > > > Yakov: > > > > The FSM revision I posted as gotten approval from Russ. > > We are awaiting Alex's review of the text. That should > > go on your list if Alex approves. > > > > Sue > > > > At 03:11 PM 1/15/2002 -0800, Yakov Rekhter wrote: > > >Folks, > > > > > >In the absence of any objections I will incorporate the > > >changes suggested below. > > > > > >Yakov. > > >------- Forwarded Message > > > > > >Date: Wed, 15 Jan 2003 18:28:48 +0000 > > >From: "Tom Petch" > > >To: "Yakov Rekhter" > > >cc: > > >Subject: Re: bgp4-17 Section 9 > > > > > >Combining NEXT_HOP resolution into one place (5.1.3) I > > >suggest > > > > > > > > >Revised 9.1.2 para 7 > > > > > >The local speaker MUST determine the immediate next-hop > > >address from the NEXT_HOP attribute of the selected route > > >(see section 5.1.3). > > >If either the immediate next hop or the IGP cost to the > > >NEXT_HOP (where the NEXT_HOP is resolved through an IGP > > >route) changes, Phase 2: Route Selection should be performed > > >again. > > > > > >- ---------------------------- > > > > > >Revised 5.1.3 > > > > > > The NEXT_HOP attribute is used by the BGP speaker to > > >determine the > > > actual outbound interface and immediate next-hop address > > >that should > > > be used to forward transit packets to the associated > > >destinations. > > > > > > The immediate next-hop address is determined by > > >performing a > > > recursive route lookup operation for the IP address in > > >the NEXT_HOP > > > attribute using the contents of the Routing Table, > > >- -----------revised text follows ------------ > > >selecting one entry if multiple entries of equal cost exist. > > >The Routing Table entry which resolves the NEXT_HOP > > >attribute will always specify the outbound interface. > > >If the entry also specifies the next-hop address, this > > >address should be used as the immediate next-hop address for > > >packet forwarding. > > >If the entry specifies an attached subnet (and does not > > >specify a next-hop address), then the address in the > > >NEXT_HOP attribute should be used as the immediate next-hop > > >address. > > >- ------------end of revision---------- > > > > > >I (still) believe 'resolving route' is not at all clear, > > >hence my use of the form > > >'The Routing Table entry which resolves the NEXT_HOP > > >attribute ...' > > >But I am less hung up on whether we mention entry or use > > >path or drop 'Routing Table'. > > >I take the point about there being a limit as to how much > > >we can say about routing tables; I tend to regard RFC1812 as > > >the sine qua none. > > > > > > > > > > > >Tom Petch, Network Consultant > > >nwnetworks@dial.pipex.com > > > > > >- -----Original Message----- > > >From: Yakov Rekhter > > >To: Tom Petch > > >Cc: idr@merit.edu > > >Date: 14 January 2002 20:15 > > >Subject: Re: bgp4-17 Section 9 > > > > > > > > > >> > > > >> 9.1.2 Route selection now allows for the best route in > > > >> Loc-RIB not to be placed in the Routing table; how does > > >this > > > >> impact on the principle (2 Introduction) that a BGP > > >Speaker > > > >> should only advertise routes it itself uses? Is it > > >enough > > > >> for the route to be in Loc-RIB and not in the Routing > > >Table? > > > >> > > > >> I believe the paragraph on immediate next hop should > > > >> cross-reference the one in 5.1.3; and the latter allows > > > >> route lookup to resolve to a subnet and not an immediate > > > >> next hop address, a possibility 9.1.2 appears not to > > >cater > > > >> for. > > > >> > > > >> Perhaps the information on immediate next hop in 5.1.3 > > >and 9 > > > >> should be combined in one place; 5.1.3 would be my > > > >> preference. > > > > > > > >Please propose the specific changes. > > > > > > > >Yakov. > > > > > > > > > > > >------- End of Forwarded Message > > > > > >_____________________________ >riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA22047 for ; Wed, 16 Jan 2002 00:58:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 99FE39127A; Wed, 16 Jan 2002 00:57:43 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63B46912B1; Wed, 16 Jan 2002 00:57: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 3D21A9127A for ; Wed, 16 Jan 2002 00:57:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1DDF65DDD8; Wed, 16 Jan 2002 00:57:42 -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 A6CB85DDD7 for ; Wed, 16 Jan 2002 00:57:41 -0500 (EST) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 461451DCC6A; Tue, 15 Jan 2002 21:57:41 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id E11A27E6C1; Tue, 15 Jan 2002 21:57:40 -0800 (PST) To: "Manav Bhatia" Cc: idr@merit.edu Subject: Re: Maximum Prefix Limit In-Reply-To: Message from "Manav Bhatia" of "Wed, 16 Jan 2002 11:22:14 +0530." <03f701c19e51$f2d4daa0$b4036c6b@Manav> Date: Tue, 15 Jan 2002 21:57:40 -0800 From: Enke Chen Message-Id: <20020116055740.E11A27E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Manav, > Message-ID: <03f701c19e51$f2d4daa0$b4036c6b@Manav> > Reply-To: "Manav Bhatia" > From: "Manav Bhatia" > To: "Enke Chen" > Cc: > References: <20020116053731.DC01615D3C1@popserv1.redback.com> > Subject: Re: Maximum Prefix Limit > Date: Wed, 16 Jan 2002 11:22:14 +0530 > > Thanks Enke! > > One more thing - Should we restart the session after the Idle timer expires > or should the session be freezed until a BGP Restart is given? That is an implementation decision you need to make. -- Enke > > ----- Original Message ----- > From: "Enke Chen" > To: "Manav Bhatia" > Cc: > Sent: Wednesday, January 16, 2002 11:07 AM > Subject: Re: Maximum Prefix Limit > > > | Hi, Manav: > | Regarding the CEASE subcode, please see the following draft: > | > | draft-ietf-idr-cease-subcode-00.txt > | > | -- Enke > | > | > Message-ID: <03b001c19e4e$aa86e750$b4036c6b@Manav> > | > Reply-To: "Manav Bhatia" > | > From: "Manav Bhatia" > | > To: > | > Subject: Maximum Prefix Limit > | > Date: Wed, 16 Jan 2002 10:58:43 +0530 > | > MIME-Version: 1.0 > | > > | > Hi, > | > > | > I am working on BGP implementation of the "maximum prefix limit" > feature > | > which is like a protection mechanism against route leaking. A warning > flag > | > will be raised once the number of prefixes start exceeding some > percentage > | > for the user to do something about it. If nothing happens and the limit > | > reaches a configured threshold then the BGP session will be torn down. > | > > | > - In the current draft there is no mechanism for the other end to know > of > | > the reason why the session went down in the first place. IF this is > | > achieved then the admin at the other end can take some actions to > alleviate > | > the situation. > | > > | > - Should the BGP session be restarted after some configured Idle Timer > | > expiration? > | > > | > This can result in consistent route flappings which is highly > undesirable. > | > > | > - Should the BGP session be freezed until a manual Restart is given? > | > > | > - Should there be counters for individual SAFI or should there be a > | > consolidated one for the entire AFI? > | > > | > We must have a mechanism wherein we can inform admin guys in the > network > | > leaking routes causing an overflow for us. This issue was brought up > some > | > time back in the list but i saw no apparent conclusion to the whole > | > discussion ;-) > | > > | > Is there any intention of introducing a new cease sub-code in the > | > NOTIFICATION message which will inform both the parties of the reason > why > | > the session was brought down! > | > > | > Regards, > | > Manav > | > > | > > | > > | > ---- > | > "When you are courting a nice girl an hour seems like a second. When > you > | > sit on a red-hot cinder a second seems like an hour. That's > relativity." > | > > | > -Albert Einstein, on relativity > | > > | > > | > > | > > | > _________________________________________________________ > | > Do You Yahoo!? > | > Get your free @yahoo.com address at http://mail.yahoo.com > | > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.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 AAA21854 for ; Wed, 16 Jan 2002 00:50:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 55617912B0; Wed, 16 Jan 2002 00:49:51 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27100912B1; Wed, 16 Jan 2002 00:49: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 12F36912B0 for ; Wed, 16 Jan 2002 00:49:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id DB41E5DDCD; Wed, 16 Jan 2002 00:49:49 -0500 (EST) Delivered-To: idr@merit.edu Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by segue.merit.edu (Postfix) with SMTP id 8E0655DDC1 for ; Wed, 16 Jan 2002 00:49:49 -0500 (EST) Received: from leased-200-20-226.bng.vsnl.net.in (HELO firewall) (203.200.20.226) by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Jan 2002 05:49:48 -0000 Message-ID: <03f701c19e51$f2d4daa0$b4036c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "Enke Chen" Cc: References: <20020116053731.DC01615D3C1@popserv1.redback.com> Subject: Re: Maximum Prefix Limit Date: Wed, 16 Jan 2002 11:22:14 +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 Enke! One more thing - Should we restart the session after the Idle timer expires or should the session be freezed until a BGP Restart is given? ----- Original Message ----- From: "Enke Chen" To: "Manav Bhatia" Cc: Sent: Wednesday, January 16, 2002 11:07 AM Subject: Re: Maximum Prefix Limit | Hi, Manav: | Regarding the CEASE subcode, please see the following draft: | | draft-ietf-idr-cease-subcode-00.txt | | -- Enke | | > Message-ID: <03b001c19e4e$aa86e750$b4036c6b@Manav> | > Reply-To: "Manav Bhatia" | > From: "Manav Bhatia" | > To: | > Subject: Maximum Prefix Limit | > Date: Wed, 16 Jan 2002 10:58:43 +0530 | > MIME-Version: 1.0 | > | > Hi, | > | > I am working on BGP implementation of the "maximum prefix limit" feature | > which is like a protection mechanism against route leaking. A warning flag | > will be raised once the number of prefixes start exceeding some percentage | > for the user to do something about it. If nothing happens and the limit | > reaches a configured threshold then the BGP session will be torn down. | > | > - In the current draft there is no mechanism for the other end to know of | > the reason why the session went down in the first place. IF this is | > achieved then the admin at the other end can take some actions to alleviate | > the situation. | > | > - Should the BGP session be restarted after some configured Idle Timer | > expiration? | > | > This can result in consistent route flappings which is highly undesirable. | > | > - Should the BGP session be freezed until a manual Restart is given? | > | > - Should there be counters for individual SAFI or should there be a | > consolidated one for the entire AFI? | > | > We must have a mechanism wherein we can inform admin guys in the network | > leaking routes causing an overflow for us. This issue was brought up some | > time back in the list but i saw no apparent conclusion to the whole | > discussion ;-) | > | > Is there any intention of introducing a new cease sub-code in the | > NOTIFICATION message which will inform both the parties of the reason why | > the session was brought down! | > | > Regards, | > Manav | > | > | > | > ---- | > "When you are courting a nice girl an hour seems like a second. When you | > sit on a red-hot cinder a second seems like an hour. That's relativity." | > | > -Albert Einstein, on relativity | > | > | > | > | > _________________________________________________________ | > Do You Yahoo!? | > Get your free @yahoo.com address at http://mail.yahoo.com | > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.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 AAA21624 for ; Wed, 16 Jan 2002 00:38:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 120DC912AF; Wed, 16 Jan 2002 00:37:36 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D9E80912B0; Wed, 16 Jan 2002 00:37: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 EC5DC912AF for ; Wed, 16 Jan 2002 00:37:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id CA2A35DDC1; Wed, 16 Jan 2002 00:37:34 -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 5FC445DDA0 for ; Wed, 16 Jan 2002 00:37:34 -0500 (EST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id C66AB1DCC62; Tue, 15 Jan 2002 21:37:33 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id DC01615D3C1; Tue, 15 Jan 2002 21:37:31 -0800 (PST) To: "Manav Bhatia" Cc: idr@merit.edu Subject: Re: Maximum Prefix Limit In-Reply-To: Message from "Manav Bhatia" of "Wed, 16 Jan 2002 10:58:43 +0530." <03b001c19e4e$aa86e750$b4036c6b@Manav> Date: Tue, 15 Jan 2002 21:37:30 -0800 From: Enke Chen Message-Id: <20020116053731.DC01615D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Manav: Regarding the CEASE subcode, please see the following draft: draft-ietf-idr-cease-subcode-00.txt -- Enke > Message-ID: <03b001c19e4e$aa86e750$b4036c6b@Manav> > Reply-To: "Manav Bhatia" > From: "Manav Bhatia" > To: > Subject: Maximum Prefix Limit > Date: Wed, 16 Jan 2002 10:58:43 +0530 > MIME-Version: 1.0 > > Hi, > > I am working on BGP implementation of the "maximum prefix limit" feature > which is like a protection mechanism against route leaking. A warning flag > will be raised once the number of prefixes start exceeding some percentage > for the user to do something about it. If nothing happens and the limit > reaches a configured threshold then the BGP session will be torn down. > > - In the current draft there is no mechanism for the other end to know of > the reason why the session went down in the first place. IF this is > achieved then the admin at the other end can take some actions to alleviate > the situation. > > - Should the BGP session be restarted after some configured Idle Timer > expiration? > > This can result in consistent route flappings which is highly undesirable. > > - Should the BGP session be freezed until a manual Restart is given? > > - Should there be counters for individual SAFI or should there be a > consolidated one for the entire AFI? > > We must have a mechanism wherein we can inform admin guys in the network > leaking routes causing an overflow for us. This issue was brought up some > time back in the list but i saw no apparent conclusion to the whole > discussion ;-) > > Is there any intention of introducing a new cease sub-code in the > NOTIFICATION message which will inform both the parties of the reason why > the session was brought down! > > Regards, > Manav > > > > ---- > "When you are courting a nice girl an hour seems like a second. When you > sit on a red-hot cinder a second seems like an hour. That's relativity." > > -Albert Einstein, on relativity > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.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 AAA21365 for ; Wed, 16 Jan 2002 00:27:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8F42C912AE; Wed, 16 Jan 2002 00:26:21 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CEAB912AF; Wed, 16 Jan 2002 00:26:21 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 40A43912AE for ; Wed, 16 Jan 2002 00:26:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 163D45DDCD; Wed, 16 Jan 2002 00:26:20 -0500 (EST) Delivered-To: idr@merit.edu Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id 8945F5DDA0 for ; Wed, 16 Jan 2002 00:26:19 -0500 (EST) Received: from leased-200-20-226.bng.vsnl.net.in (HELO firewall) (203.200.20.226) by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Jan 2002 05:26:18 -0000 Message-ID: <03b001c19e4e$aa86e750$b4036c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: Subject: Maximum Prefix Limit Date: Wed, 16 Jan 2002 10:58:43 +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 Hi, I am working on BGP implementation of the "maximum prefix limit" feature which is like a protection mechanism against route leaking. A warning flag will be raised once the number of prefixes start exceeding some percentage for the user to do something about it. If nothing happens and the limit reaches a configured threshold then the BGP session will be torn down. - In the current draft there is no mechanism for the other end to know of the reason why the session went down in the first place. IF this is achieved then the admin at the other end can take some actions to alleviate the situation. - Should the BGP session be restarted after some configured Idle Timer expiration? This can result in consistent route flappings which is highly undesirable. - Should the BGP session be freezed until a manual Restart is given? - Should there be counters for individual SAFI or should there be a consolidated one for the entire AFI? We must have a mechanism wherein we can inform admin guys in the network leaking routes causing an overflow for us. This issue was brought up some time back in the list but i saw no apparent conclusion to the whole discussion ;-) Is there any intention of introducing a new cease sub-code in the NOTIFICATION message which will inform both the parties of the reason why the session was brought down! Regards, Manav ---- "When you are courting a nice girl an hour seems like a second. When you sit on a red-hot cinder a second seems like an hour. That's relativity." -Albert Einstein, on relativity _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.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 WAA18532 for ; Tue, 15 Jan 2002 22:28:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3A7DC91271; Tue, 15 Jan 2002 22:27:41 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 063AE91272; Tue, 15 Jan 2002 22:27: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 622B191271 for ; Tue, 15 Jan 2002 22:27:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 33F775DDA7; Tue, 15 Jan 2002 22:27:39 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id ED55B5DDA0 for ; Tue, 15 Jan 2002 22:27:38 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA26538; Tue, 15 Jan 2002 22:27:37 -0500 (EST) Date: Tue, 15 Jan 2002 22:27:37 -0500 (EST) From: Russ White Reply-To: Russ White To: Susan Hares Cc: Yakov Rekhter , idr@merit.edu Subject: Re: editorial fixes In-Reply-To: <5.0.0.25.0.20020115191918.029259a8@mail.nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk I think Alex is suggesting alternate text altogether--we should see it in the next day or two. Russ On Tue, 15 Jan 2002, Susan Hares wrote: > > Yakov: > > The FSM revision I posted as gotten approval from Russ. > We are awaiting Alex's review of the text. That should > go on your list if Alex approves. > > Sue > > At 03:11 PM 1/15/2002 -0800, Yakov Rekhter wrote: > >Folks, > > > >In the absence of any objections I will incorporate the > >changes suggested below. > > > >Yakov. > >------- Forwarded Message > > > >Date: Wed, 15 Jan 2003 18:28:48 +0000 > >From: "Tom Petch" > >To: "Yakov Rekhter" > >cc: > >Subject: Re: bgp4-17 Section 9 > > > >Combining NEXT_HOP resolution into one place (5.1.3) I > >suggest > > > > > >Revised 9.1.2 para 7 > > > >The local speaker MUST determine the immediate next-hop > >address from the NEXT_HOP attribute of the selected route > >(see section 5.1.3). > >If either the immediate next hop or the IGP cost to the > >NEXT_HOP (where the NEXT_HOP is resolved through an IGP > >route) changes, Phase 2: Route Selection should be performed > >again. > > > >- ---------------------------- > > > >Revised 5.1.3 > > > > The NEXT_HOP attribute is used by the BGP speaker to > >determine the > > actual outbound interface and immediate next-hop address > >that should > > be used to forward transit packets to the associated > >destinations. > > > > The immediate next-hop address is determined by > >performing a > > recursive route lookup operation for the IP address in > >the NEXT_HOP > > attribute using the contents of the Routing Table, > >- -----------revised text follows ------------ > >selecting one entry if multiple entries of equal cost exist. > >The Routing Table entry which resolves the NEXT_HOP > >attribute will always specify the outbound interface. > >If the entry also specifies the next-hop address, this > >address should be used as the immediate next-hop address for > >packet forwarding. > >If the entry specifies an attached subnet (and does not > >specify a next-hop address), then the address in the > >NEXT_HOP attribute should be used as the immediate next-hop > >address. > >- ------------end of revision---------- > > > >I (still) believe 'resolving route' is not at all clear, > >hence my use of the form > >'The Routing Table entry which resolves the NEXT_HOP > >attribute ...' > >But I am less hung up on whether we mention entry or use > >path or drop 'Routing Table'. > >I take the point about there being a limit as to how much > >we can say about routing tables; I tend to regard RFC1812 as > >the sine qua none. > > > > > > > >Tom Petch, Network Consultant > >nwnetworks@dial.pipex.com > > > >- -----Original Message----- > >From: Yakov Rekhter > >To: Tom Petch > >Cc: idr@merit.edu > >Date: 14 January 2002 20:15 > >Subject: Re: bgp4-17 Section 9 > > > > > > >> > > >> 9.1.2 Route selection now allows for the best route in > > >> Loc-RIB not to be placed in the Routing table; how does > >this > > >> impact on the principle (2 Introduction) that a BGP > >Speaker > > >> should only advertise routes it itself uses? Is it > >enough > > >> for the route to be in Loc-RIB and not in the Routing > >Table? > > >> > > >> I believe the paragraph on immediate next hop should > > >> cross-reference the one in 5.1.3; and the latter allows > > >> route lookup to resolve to a subnet and not an immediate > > >> next hop address, a possibility 9.1.2 appears not to > >cater > > >> for. > > >> > > >> Perhaps the information on immediate next hop in 5.1.3 > >and 9 > > >> should be combined in one place; 5.1.3 would be my > > >> preference. > > > > > >Please propose the specific changes. > > > > > >Yakov. > > > > > > > >------- End of Forwarded Message > > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA14921 for ; Tue, 15 Jan 2002 20:05:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BEED491270; Tue, 15 Jan 2002 20:05:19 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92CAD912AB; Tue, 15 Jan 2002 20:05:19 -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 828BD91270 for ; Tue, 15 Jan 2002 20:05:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4E2E25DDAD; Tue, 15 Jan 2002 20:05:18 -0500 (EST) Delivered-To: idr@merit.edu Received: from vaio.zebra.org (unknown [209.11.132.18]) by segue.merit.edu (Postfix) with ESMTP id 06EF45DDA0 for ; Tue, 15 Jan 2002 20:05:18 -0500 (EST) Received: from localhost (vaio.zebra.org) [127.0.0.1] (kunihiro) by vaio.zebra.org with esmtp (Exim 3.12 #1 (Debian)) id 16QfAj-00005X-00; Tue, 15 Jan 2002 17:47:25 -0800 Date: Tue, 15 Jan 2002 17:47:25 -0800 Message-ID: <876663jccy.wl@vaio.zebra.org> From: Kunihiro Ishiguro To: Susan Hares Cc: idr@merit.edu, Jeffrey Haas , Dave Thaler , Enke Chen Subject: Re: IDR WG Last Call - Who has SAFI 3? In-Reply-To: <5.0.0.25.0.20020115194458.02864ab0@mail.nexthop.com> References: <20020115161222.B16527@nexthop.com> <2E33960095B58E40A4D3345AB9F65EC1047CE682@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> <5.0.0.25.0.20020115194458.02864ab0@mail.nexthop.com> User-Agent: Wanderlust/2.4.0 (Rio) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.0.99 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk >2 implementations: > >a) Zebra - put SAFI 3 in and took it out >b) GateD - has SAFI 3 support Just a small comment. Zebra - accept SAFI 3 do not announce SAFI 3 -- Kunihiro Ishiguro Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA14699 for ; Tue, 15 Jan 2002 19:57:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C88BA912AA; Tue, 15 Jan 2002 19:57:14 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A3B7912AB; Tue, 15 Jan 2002 19:57:14 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9450A912AA for ; Tue, 15 Jan 2002 19:57:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 33F535DDCE; Tue, 15 Jan 2002 19:57:13 -0500 (EST) Delivered-To: idr@merit.edu Received: from vaio.zebra.org (unknown [209.11.132.18]) by segue.merit.edu (Postfix) with ESMTP id 79DB05DDCB for ; Tue, 15 Jan 2002 19:57:12 -0500 (EST) Received: from localhost (vaio.zebra.org) [127.0.0.1] (kunihiro) by vaio.zebra.org with esmtp (Exim 3.12 #1 (Debian)) id 16Qf2r-00004h-00; Tue, 15 Jan 2002 17:39:17 -0800 Date: Tue, 15 Jan 2002 17:39:17 -0800 Message-ID: <87advfjcqi.wl@vaio.zebra.org> From: Kunihiro Ishiguro To: Vincent Gillet Cc: Yakov Rekhter , Jeffrey Haas , idr@merit.edu Subject: Re: bgp4-17 Cease subcode In-Reply-To: <20020115140711.GA23937@opentransit.net> References: <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> <20020115140711.GA23937@opentransit.net> User-Agent: Wanderlust/2.4.0 (Rio) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.0.99 (i686-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk >> > Is the expoential backoff in the FSM in current implementations? >> >> I guess we are going to find this out as part of the implementation >> report. And if it is not in (at least two) current implementations, >> we'll take it out of the text. > >I implemented Cease subcode in zebra-0.92a but not exponential backoff. >I checked that new subcode does not put other BGP stack in trouble >(checked Cisco and Juniper). First of all, sorry for talking about specific implementation. In Zebra implementation we've implemented Cease subcode. The code is in CVS repository. I'll prepare a release version for that. And also we've implemented exponetial backoff. It is done without introducing new FSM status. It is not a big deal. Just check a flag in a few functions. Exponential backoff is a good feature. I can't understand why it require change to FSM. -- Kunihiro Ishiguro Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA14593 for ; Tue, 15 Jan 2002 19:51:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4FE389126F; Tue, 15 Jan 2002 19:51:19 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DB10912AA; Tue, 15 Jan 2002 19:51:19 -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 EF4FF9126F for ; Tue, 15 Jan 2002 19:51:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id CA8285DDAC; Tue, 15 Jan 2002 19:51:17 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id B12585DDA0 for ; Tue, 15 Jan 2002 19:51:17 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0G0on305030; Tue, 15 Jan 2002 19:50:49 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020115194458.02864ab0@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 15 Jan 2002 19:50:48 -0500 To: Kunihiro Ishiguro , idr@merit.edu From: Susan Hares Subject: Re: IDR WG Last Call - Who has SAFI 3? Cc: Jeffrey Haas , Dave Thaler , Enke Chen In-Reply-To: References: <20020115161222.B16527@nexthop.com> <2E33960095B58E40A4D3345AB9F65EC1047CE682@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Kunihiro and working group: OK - just to confirm: 2 implementations: a) Zebra - put SAFI 3 in and took it out b) GateD - has SAFI 3 support Can any other implementor of SAFI please chime in now or send me a note privately indicating that you have done it. Also, any deployment using SAFI 3 should chime in with the usage. Please send it now as we are trying to finish the last call on MPBGP. Sue At 03:21 PM 1/15/2002 -0800, Kunihiro Ishiguro wrote: > >While I agree that its nice in theory, you have the added difficulty > >of having to maintain additional state for things such as WRD > >and potentially awkward queue mechanisms for outgoing routes. > >As such, you actually implement at least as much, if not more, > >infrastructure to deal with the additional overhead of having > >a SAFI that covers the unicast+multicast case. > > > >Additionally, policy is now a real pain - and very ambiguous in > >the current spec. If you say "accept unicast and multicast routes", > >does that mean accept only SAFI 3 or SAFI's 1, 2 and 3? > > > >As Sue has mentioned, treating them as bits works fine for these > >three SAFI's. But I'd rather not have to. > >I agree with this. > > >I'm not going to argue very hard for removing SAFI 3 - we already > >implement it. But there are complications that don't seem to be > >accounted for with regards to its supposed information overhead reduction. > >Yes. I also implemented SAFI 3. But I've changed implementation to >not to use it. I know there was some implementation which support >SAFI 3. But IMHO some of those implementation already changed their >implementation to not to send SAFI 3. We've learned it is not good >way to send differenct SAFI route with one NLRI. >-- >Kunihiro Ishiguro Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA13935 for ; Tue, 15 Jan 2002 19:24:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC0EE912A9; Tue, 15 Jan 2002 19:23:59 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB70B912AA; Tue, 15 Jan 2002 19:23: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 6EB72912A9 for ; Tue, 15 Jan 2002 19:23:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 41EA95DDD1; Tue, 15 Jan 2002 19:23:58 -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 4F3B55DDAD for ; Tue, 15 Jan 2002 19:23:56 -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 g0G0Nm618734; Tue, 15 Jan 2002 16:23:48 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200201160023.g0G0Nm618734@merlot.juniper.net> To: Russ White Cc: Anoop Ghanwani , Babu Prabesh , idr@merit.edu Subject: Re: ATOMIC AGGREGATE (section 9.1.4 of bgp 4-17) In-Reply-To: Your message of "Tue, 15 Jan 2002 18:45:00 EST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <35297.1011140628.1@juniper.net> Date: Tue, 15 Jan 2002 16:23:48 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Russ, > Agreed.... > > :-) > > Russ > > On Tue, 15 Jan 2002, Anoop Ghanwani wrote: > > > > > I think what the text is trying to say is that > > it is not possible to deaggregate a route once it > > has been aggregated. If so, it would make sense > > to modify the text in 9.1.4 to say just that. the text in 9.1.4 seems to be quite clear on this topic: A route that carries ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the NLRI of this route can not be made more specific. Yakov. > > > > If that's not what the text is saying, then please > > correct me. > > > > -Anoop > > > > > -----Original Message----- > > > From: Russ White [mailto:ruwhite@cisco.com] > > > Sent: Tuesday, January 15, 2002 5:02 AM > > > To: Babu Prabesh > > > Cc: idr@merit.edu > > > Subject: Re: ATOMIC AGGREGATE (section 9.1.4 of bgp 4-17) > > > > > > > > > > > > Nope--those woul dbe two seperate routes, with their own as > > > paths, so it won't matter if you send both of them. Presumably, > > > rtrb knows about the /16 locally, which is why it has the static, > > > so no looping should occur. > > > > > > I'm not certain how you would de-aggregate in this way.... > > > > > > :-) > > > > > > Russ > > > > > > On Mon, 14 Jan 2002, Babu Prabesh wrote: > > > > > > > Section 9.1.4: overlapping routes states: > > > > > > > > "If a BGP speaker chooses to aggregate, then it MUST add > > > > ATOMIC_AGGREGATE attribute > > > > to the route. A route that carries ATOMIC_AGGREGATE > > > attribute can not be > > > > de-aggregated. > > > > That is, the NLRI of this route can not be made more specific. > > > > Forwarding along such a > > > > route does not guarantee that IP packets will actually > > > traverse only ASs > > > > listed in the > > > > AS_PATH attribute of the route". > > > > > > > > I was unsure of what de-aggregation means. > > > > Consider an example > > > > > > > > bgp bgp > > > > RTRA---------RTRB----------RTRC > > > > > > > > RTRA sends 5/8 with ATOMIC_AGGREGATE set to RTRB. > > > > RTRB has a 5/16 route (via static). > > > > > > > > Is the draft indicating that RTRB should only > > > > advertise 5/8 to RTRC and not advertise 5/16. > > > > > > > > Thanks > > > > Babu > > > > > > > > > > > ############################################################## > > > ############## > > > > ########################## This email communication may > > > contain CONFIDENTIAL > > > > INFORMATION and is intended only for the use of the > > > intended recipients > > > > identified above. If you are not the intended recipient of this > > > > communication, you must not use, disclose, distribute, copy > > > or print this > > > > email. If you have received this communication in error, > > > please immediately > > > > notify the sender by reply email, delete the communication > > > and destroy all > > > > copies. > > > > > > > ############################################################## > > > ############## > > > > ########################## > > > > > > > > > > _____________________________ > > > riw@cisco.com <>< Grace Alone > > > > > > > _____________________________ > riw@cisco.com <>< Grace Alone > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA13889 for ; Tue, 15 Jan 2002 19:21:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5302C912A8; Tue, 15 Jan 2002 19:21:08 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBA49912A9; Tue, 15 Jan 2002 19:21:05 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D802912A8 for ; Tue, 15 Jan 2002 19:20:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 684885DDCA; Tue, 15 Jan 2002 19:20:39 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 1D7175DDAD for ; Tue, 15 Jan 2002 19:20:39 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0G0KI304212; Tue, 15 Jan 2002 19:20:18 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020115191918.029259a8@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 15 Jan 2002 19:20:17 -0500 To: Yakov Rekhter From: Susan Hares Subject: Re: editorial fixes Cc: idr@merit.edu In-Reply-To: <200201152311.g0FNBT614783@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Yakov: The FSM revision I posted as gotten approval from Russ. We are awaiting Alex's review of the text. That should go on your list if Alex approves. Sue At 03:11 PM 1/15/2002 -0800, Yakov Rekhter wrote: >Folks, > >In the absence of any objections I will incorporate the >changes suggested below. > >Yakov. >------- Forwarded Message > >Date: Wed, 15 Jan 2003 18:28:48 +0000 >From: "Tom Petch" >To: "Yakov Rekhter" >cc: >Subject: Re: bgp4-17 Section 9 > >Combining NEXT_HOP resolution into one place (5.1.3) I >suggest > > >Revised 9.1.2 para 7 > >The local speaker MUST determine the immediate next-hop >address from the NEXT_HOP attribute of the selected route >(see section 5.1.3). >If either the immediate next hop or the IGP cost to the >NEXT_HOP (where the NEXT_HOP is resolved through an IGP >route) changes, Phase 2: Route Selection should be performed >again. > >- ---------------------------- > >Revised 5.1.3 > > The NEXT_HOP attribute is used by the BGP speaker to >determine the > actual outbound interface and immediate next-hop address >that should > be used to forward transit packets to the associated >destinations. > > The immediate next-hop address is determined by >performing a > recursive route lookup operation for the IP address in >the NEXT_HOP > attribute using the contents of the Routing Table, >- -----------revised text follows ------------ >selecting one entry if multiple entries of equal cost exist. >The Routing Table entry which resolves the NEXT_HOP >attribute will always specify the outbound interface. >If the entry also specifies the next-hop address, this >address should be used as the immediate next-hop address for >packet forwarding. >If the entry specifies an attached subnet (and does not >specify a next-hop address), then the address in the >NEXT_HOP attribute should be used as the immediate next-hop >address. >- ------------end of revision---------- > >I (still) believe 'resolving route' is not at all clear, >hence my use of the form >'The Routing Table entry which resolves the NEXT_HOP >attribute ...' >But I am less hung up on whether we mention entry or use >path or drop 'Routing Table'. >I take the point about there being a limit as to how much >we can say about routing tables; I tend to regard RFC1812 as >the sine qua none. > > > >Tom Petch, Network Consultant >nwnetworks@dial.pipex.com > >- -----Original Message----- >From: Yakov Rekhter >To: Tom Petch >Cc: idr@merit.edu >Date: 14 January 2002 20:15 >Subject: Re: bgp4-17 Section 9 > > > >> > >> 9.1.2 Route selection now allows for the best route in > >> Loc-RIB not to be placed in the Routing table; how does >this > >> impact on the principle (2 Introduction) that a BGP >Speaker > >> should only advertise routes it itself uses? Is it >enough > >> for the route to be in Loc-RIB and not in the Routing >Table? > >> > >> I believe the paragraph on immediate next hop should > >> cross-reference the one in 5.1.3; and the latter allows > >> route lookup to resolve to a subnet and not an immediate > >> next hop address, a possibility 9.1.2 appears not to >cater > >> for. > >> > >> Perhaps the information on immediate next hop in 5.1.3 >and 9 > >> should be combined in one place; 5.1.3 would be my > >> preference. > > > >Please propose the specific changes. > > > >Yakov. > > > >------- End of Forwarded Message 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 TAA13813 for ; Tue, 15 Jan 2002 19:20:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5FE3C912A6; Tue, 15 Jan 2002 19:19:39 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14398912A8; Tue, 15 Jan 2002 19:19: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 C00EB912A6 for ; Tue, 15 Jan 2002 19:19:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9CC8E5DDCA; Tue, 15 Jan 2002 19:19:34 -0500 (EST) Delivered-To: idr@merit.edu Received: from titanium.zebra.org (unknown [209.11.132.18]) by segue.merit.edu (Postfix) with ESMTP id 13ADF5DDAD for ; Tue, 15 Jan 2002 19:19:34 -0500 (EST) Received: from titanium.zebra.org (IDENT:kunihiro@localhost [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id SAA01375; Tue, 15 Jan 2002 18:21:32 -0500 Date: Tue, 15 Jan 2002 15:21:32 -0800 Message-ID: From: Kunihiro Ishiguro To: Jeffrey Haas Cc: Dave Thaler , Enke Chen , idr@merit.edu Subject: Re: IDR WG Last Call In-Reply-To: <20020115161222.B16527@nexthop.com> References: <2E33960095B58E40A4D3345AB9F65EC1047CE682@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.1 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk >While I agree that its nice in theory, you have the added difficulty >of having to maintain additional state for things such as WRD >and potentially awkward queue mechanisms for outgoing routes. >As such, you actually implement at least as much, if not more, >infrastructure to deal with the additional overhead of having >a SAFI that covers the unicast+multicast case. > >Additionally, policy is now a real pain - and very ambiguous in >the current spec. If you say "accept unicast and multicast routes", >does that mean accept only SAFI 3 or SAFI's 1, 2 and 3? > >As Sue has mentioned, treating them as bits works fine for these >three SAFI's. But I'd rather not have to. I agree with this. >I'm not going to argue very hard for removing SAFI 3 - we already >implement it. But there are complications that don't seem to be >accounted for with regards to its supposed information overhead reduction. Yes. I also implemented SAFI 3. But I've changed implementation to not to use it. I know there was some implementation which support SAFI 3. But IMHO some of those implementation already changed their implementation to not to send SAFI 3. We've learned it is not good way to send differenct SAFI route with one NLRI. -- Kunihiro Ishiguro Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA13006 for ; Tue, 15 Jan 2002 18:45:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 98427912A3; Tue, 15 Jan 2002 18:45:07 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B6A7912A4; Tue, 15 Jan 2002 18:45: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 A9396912A3 for ; Tue, 15 Jan 2002 18:45:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id DBA3E5DDAC; Tue, 15 Jan 2002 18:45:03 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id E6B9A5DDA0 for ; Tue, 15 Jan 2002 18:45:02 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA01719; Tue, 15 Jan 2002 18:45:00 -0500 (EST) Date: Tue, 15 Jan 2002 18:45:00 -0500 (EST) From: Russ White Reply-To: Russ White To: Anoop Ghanwani Cc: Babu Prabesh , idr@merit.edu Subject: RE: ATOMIC AGGREGATE (section 9.1.4 of bgp 4-17) In-Reply-To: <58BE468BAC66D511AFE6000347251A2DED44C9@morpheus.lanterncom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Agreed.... :-) Russ On Tue, 15 Jan 2002, Anoop Ghanwani wrote: > > I think what the text is trying to say is that > it is not possible to deaggregate a route once it > has been aggregated. If so, it would make sense > to modify the text in 9.1.4 to say just that. > > If that's not what the text is saying, then please > correct me. > > -Anoop > > > -----Original Message----- > > From: Russ White [mailto:ruwhite@cisco.com] > > Sent: Tuesday, January 15, 2002 5:02 AM > > To: Babu Prabesh > > Cc: idr@merit.edu > > Subject: Re: ATOMIC AGGREGATE (section 9.1.4 of bgp 4-17) > > > > > > > > Nope--those woul dbe two seperate routes, with their own as > > paths, so it won't matter if you send both of them. Presumably, > > rtrb knows about the /16 locally, which is why it has the static, > > so no looping should occur. > > > > I'm not certain how you would de-aggregate in this way.... > > > > :-) > > > > Russ > > > > On Mon, 14 Jan 2002, Babu Prabesh wrote: > > > > > Section 9.1.4: overlapping routes states: > > > > > > "If a BGP speaker chooses to aggregate, then it MUST add > > > ATOMIC_AGGREGATE attribute > > > to the route. A route that carries ATOMIC_AGGREGATE > > attribute can not be > > > de-aggregated. > > > That is, the NLRI of this route can not be made more specific. > > > Forwarding along such a > > > route does not guarantee that IP packets will actually > > traverse only ASs > > > listed in the > > > AS_PATH attribute of the route". > > > > > > I was unsure of what de-aggregation means. > > > Consider an example > > > > > > bgp bgp > > > RTRA---------RTRB----------RTRC > > > > > > RTRA sends 5/8 with ATOMIC_AGGREGATE set to RTRB. > > > RTRB has a 5/16 route (via static). > > > > > > Is the draft indicating that RTRB should only > > > advertise 5/8 to RTRC and not advertise 5/16. > > > > > > Thanks > > > Babu > > > > > > > > ############################################################## > > ############## > > > ########################## This email communication may > > contain CONFIDENTIAL > > > INFORMATION and is intended only for the use of the > > intended recipients > > > identified above. If you are not the intended recipient of this > > > communication, you must not use, disclose, distribute, copy > > or print this > > > email. If you have received this communication in error, > > please immediately > > > notify the sender by reply email, delete the communication > > and destroy all > > > copies. > > > > > ############################################################## > > ############## > > > ########################## > > > > > > > _____________________________ > > riw@cisco.com <>< Grace Alone > > > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA12399 for ; Tue, 15 Jan 2002 18:18:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 52322912A1; Tue, 15 Jan 2002 18:17:25 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 726E0912A3; Tue, 15 Jan 2002 18:17: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 ADAC6912A1 for ; Tue, 15 Jan 2002 18:17:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B1805DDAD; Tue, 15 Jan 2002 18:17:21 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 413D15DDA0 for ; Tue, 15 Jan 2002 18:17:21 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0FNGw302361; Tue, 15 Jan 2002 18:16:59 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020115175015.029288f0@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 15 Jan 2002 18:16:57 -0500 To: Enke Chen From: Susan Hares Subject: Re: IDR WG Last Call Cc: idr@merit.edu In-Reply-To: <20020115214125.47805979C1@popserv2.redback.com> References: <5.0.0.25.0.20020115163041.02879998@mail.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Sending as well as receiving on the implementations that I know about. Ask Dave Thaler and Dory about deployments. Sue At 01:41 PM 1/15/2002 -0800, you wrote: >Sue, > > > Date: Tue, 15 Jan 2002 16:32:23 -0500 > > To: Russ White > > From: Susan Hares > > Subject: Re: IDR WG Last Call > > Cc: Enke Chen , Susan Hares , > > Jeffrey Haas , idr@merit.edu > > In-Reply-To: > .com> > > > > I know of at least 2 implementations that do 1,2,3 and > >Do we know if "SAFI 3" is used in sending? That would not work without >the receiver supporting it. > >If "SAFI 3" is not used in sending, it seems that it would be safe to >remove it from the spec.. > >-- Enke > > > I know of at least 2 implementations that do not (1,2 only). > > > > Sigh.. Yakov is drafting a change to text to try > > to address all of these concerns. I'll await > > his note. > > > > sue > > > > At 03:02 PM 1/15/2002 -0500, Russ White wrote: > > > > >Correct--SAFI 3.... There aren't any implementations that I've > > >seen, and it does complicate matters a bit more than needed. > > > > > >Russ > > > > > >On Tue, 15 Jan 2002, Enke Chen wrote: > > > > > > > Sue, > > > > > > > > > Date: Tue, 15 Jan 2002 14:49:14 -0500 > > > > > To: Russ White > > > > > From: Susan Hares > > > > > Subject: Re: IDR WG Last Call > > > > > Cc: Enke Chen , Jeffrey Haas , > > > > > idr@merit.edu > > > > > In-Reply-To: > > > > > .com> > > > > > References: <20020115174716.CC5A815D3C1@popserv1.redback.com> > > > > > Mime-Version: 1.0 > > > > > Content-Type: text/plain; charset="us-ascii"; format=flowed > > > > > X-NextHop-MailScanner: Found to be clean > > > > > > > > > > Russ: > > > > > > > > > > We had that vote 1 month ago. The overwhelming > > > > > majority was to keep it in. We are not re-opening > > > > > that issue having closed it on the mail list already. > > > > > > > > The issue then was the "BGP State Machine". Russ was talking abut > "SAFI 3" > > > > in his message if I am not mistaken. > > > > > > > > -- Enke > > > > > > > > > > > > > > > > > > > Sue > > > > > > > > > > At 01:03 PM 1/15/2002 -0500, Russ White wrote: > > > > > > > > > > >I think it's probably a good idea to get rid of this out of the > > > > > >spec--it would make things cleaner. > > > > > > > > > > > >Russ > > > > > > > > > > > >On Tue, 15 Jan 2002, Enke Chen wrote: > > > > > > > > > > > > > Jeff, > > > > > > > > > > > > > > > Date: Mon, 14 Jan 2002 23:21:28 -0500 > > > > > > > > From: Jeffrey Haas > > > > > > > > To: Enke Chen > > > > > > > > Cc: idr@merit.edu > > > > > > > > Subject: Re: IDR WG Last Call > > > > > > > > Message-ID: <20020114232128.B14701@nexthop.com> > > > > > > > > > > > > > > > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote: > > > > > > > > > It seems that the "SAFI 3" certainly makes the issue at hand > > > much more > > > > > > > > > complicated. > > > > > > > > > > > > > > > > IMO, SAFI 3 was probably not a very good idea. Dealing > with it can > > > > > > > > be a real pain in the implementation. :-) > > > > > > > > > > > > > > So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem > > > to add > > > > > > > much value, but has caused a lot of confusion and complexity. I > > > am not > > > > > > > aware of any depolyment either. > > > > > > > > > > > > > > > > > > > > > > > > As Yakov and Sue pointed out, it is a good idea to discourage > > > > > > > > > having one prefix in multiple fields of an update > message. How > > > > > > about the > > > > > > > > > following text: > > > > > > > > > > > > > > > > > > An UPDATE message should not include the same address > > > prefix in > > > > > > more than > > > > > > > > > one of the following fields: WITHDRAWN ROUTES field, > Network > > > > > > Reachability > > > > > > > > > Information fields, MP_REACH_NLRI field, and > MP_UNREACH_NLRI > > > > > > field. The > > > > > > > > > processing of an UPDATE message in this form is > un-defined. > > > > > > > > > > > > > > > > I think that "undefined" is overkill. I would suggest the > > > following > > > > > > instead: > > > > > > > > > > > > > > > > An UPDATE message should not include the same address prefix in > > > > > > > > more than one of the following fields: WITHDRAWN ROUTES, > Network > > > > > > > > Layer Reachability Information, MP_REACH_NLRI and > MP_UNREACH_NLRI. > > > > > > > > An implementation that receives a packet in this form should > > > process > > > > > > > > the Update as if it had processed it in the following order: > > > > > > > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer > > > > > > > > Reachability Information. > > > > > > > > > > > > > > > > The wording could probably use some tightening. > > > > > > > > > > > > > > > > The intended result is that reachability rules over > unreachability. > > > > > > > > > > > > > > If we want to define the behavior, I would like to suggest > > > sticking to > > > > > > > the order in the message. That probably would reflect the > sender's > > > > > > > intention more closely, and make the processing simpler. > > > > > > > > > > > > > > -- Enke > > > > > > > > > > > > > > > > > > > > > > > > > >_____________________________ > > > > > >riw@cisco.com <>< Grace Alone > > > > > > > > > > > > > > > > > > > >_____________________________ > > >riw@cisco.com <>< Grace Alone > > > > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA12276 for ; Tue, 15 Jan 2002 18:11:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 97F799129B; Tue, 15 Jan 2002 18:11:31 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 69A72912A1; Tue, 15 Jan 2002 18:11: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 24D789129B for ; Tue, 15 Jan 2002 18:11:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id E45375DDAD; Tue, 15 Jan 2002 18:11:29 -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 603095DDA0 for ; Tue, 15 Jan 2002 18:11:29 -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 g0FNBT614783 for ; Tue, 15 Jan 2002 15:11:29 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200201152311.g0FNBT614783@merlot.juniper.net> To: idr@merit.edu Subject: editorial fixes MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15896.1011136288.1@juniper.net> Date: Tue, 15 Jan 2002 15:11:29 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, In the absence of any objections I will incorporate the changes suggested below. Yakov. ------- Forwarded Message Date: Wed, 15 Jan 2003 18:28:48 +0000 From: "Tom Petch" To: "Yakov Rekhter" cc: Subject: Re: bgp4-17 Section 9 Combining NEXT_HOP resolution into one place (5.1.3) I suggest Revised 9.1.2 para 7 The local speaker MUST determine the immediate next-hop address from the NEXT_HOP attribute of the selected route (see section 5.1.3). If either the immediate next hop or the IGP cost to the NEXT_HOP (where the NEXT_HOP is resolved through an IGP route) changes, Phase 2: Route Selection should be performed again. - ---------------------------- Revised 5.1.3 The NEXT_HOP attribute is used by the BGP speaker to determine the actual outbound interface and immediate next-hop address that should be used to forward transit packets to the associated destinations. The immediate next-hop address is determined by performing a recursive route lookup operation for the IP address in the NEXT_HOP attribute using the contents of the Routing Table, - -----------revised text follows ------------ selecting one entry if multiple entries of equal cost exist. The Routing Table entry which resolves the NEXT_HOP attribute will always specify the outbound interface. If the entry also specifies the next-hop address, this address should be used as the immediate next-hop address for packet forwarding. If the entry specifies an attached subnet (and does not specify a next-hop address), then the address in the NEXT_HOP attribute should be used as the immediate next-hop address. - ------------end of revision---------- I (still) believe 'resolving route' is not at all clear, hence my use of the form 'The Routing Table entry which resolves the NEXT_HOP attribute ...' But I am less hung up on whether we mention entry or use path or drop 'Routing Table'. I take the point about there being a limit as to how much we can say about routing tables; I tend to regard RFC1812 as the sine qua none. Tom Petch, Network Consultant nwnetworks@dial.pipex.com - -----Original Message----- From: Yakov Rekhter To: Tom Petch Cc: idr@merit.edu Date: 14 January 2002 20:15 Subject: Re: bgp4-17 Section 9 >> >> 9.1.2 Route selection now allows for the best route in >> Loc-RIB not to be placed in the Routing table; how does this >> impact on the principle (2 Introduction) that a BGP Speaker >> should only advertise routes it itself uses? Is it enough >> for the route to be in Loc-RIB and not in the Routing Table? >> >> I believe the paragraph on immediate next hop should >> cross-reference the one in 5.1.3; and the latter allows >> route lookup to resolve to a subnet and not an immediate >> next hop address, a possibility 9.1.2 appears not to cater >> for. >> >> Perhaps the information on immediate next hop in 5.1.3 and 9 >> should be combined in one place; 5.1.3 would be my >> preference. > >Please propose the specific changes. > >Yakov. ------- End of Forwarded Message 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 RAA10559 for ; Tue, 15 Jan 2002 17:02:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4DB7491279; Tue, 15 Jan 2002 17:00:54 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21A319127C; Tue, 15 Jan 2002 17:00:54 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 25AC991279 for ; Tue, 15 Jan 2002 17:00:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id F17025DDB0; Tue, 15 Jan 2002 17:00:52 -0500 (EST) Delivered-To: idr@merit.edu Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id BEE615DDA5 for ; Tue, 15 Jan 2002 17:00:52 -0500 (EST) Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id 90BF93F6C; Tue, 15 Jan 2002 14:03:39 -0800 (PST) Received: from khonsu.sw.nexsi.com ([172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id OAA14243; Tue, 15 Jan 2002 14:00:03 -0800 Date: Tue, 15 Jan 2002 14:00:01 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <85108959926.20020115140001@nexsi.com> To: Susan Hares Cc: Russ White , Eric Gray , Inter-Domain Routing Mailing List Subject: Re: bgp4-17 Cease subcode In-Reply-To: <5.0.0.25.0.20020115155854.04a7cd68@mail.nexthop.com> References: <5.0.0.25.0.20020115144930.04a32a00@mail.nexthop.com> <5.0.0.25.0.20020115155854.04a7cd68@mail.nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Sue: > Now to the text: > Fix to problem 1 - FSM does not require you to implemented > the hold off. Does this mean IdleHold is removed? > How about replacing this following text at the IDLE State: > IDLE > ============= > From this text: > >A manual start event is a start event initiated > >by an operator. An automatic start event is > >a start event generated by the system. > The text can be: a manual event is intended to be > a start event generated by "manual" intervention. If the > presistent flapping suppression option is not set, > all start events will be manual start events. The last sentence is too much, I guess. Can we say that automatic Start event is generated by the system to initiate the BGP connection procedure and that it is recommended that persistent flapping is accounted for and/or the text you give below? FSM-wise, not describing the behavior when transitioning from every state is not a problem if we specify actions performed when FSM reaches a specific state (Idle in our case). I'm working on such a version, will send out soon. > How about re-adding this section at the bottom > of the state machine? > Manual versus Automatic start in the FSM > If a BGP speaker detects an error, it shuts down the > connection and changes its state to Idle-hold. Getting out Shouldn't this be "Idle"? BTW, regarding the collision detection, shouldn't the session that lost the tie-breaker be destroyed rather than being put in Idle/IdleHold? Alex. > of the Idle state requires generation of the Start event. > Such a start event can either be manual or automatic. > If this start event is generated automatically, then > persistent BGP errors may result in persistent flapping > of the speaker. To avoid such a condition it is > recommended that the Start events should not be generated > immediately for a peer that was previously transitioned > to Idle due to an error. For a peer that was previously > transitioned to Idle due to an error, the time between > consecutive generation of Start events, if such events are > generated automatically, shall exponentially increase. The > value of the initial timer shall be 60 seconds. The time shall > be doubled for each consecutive retry.The formula for this > expotential backoff is expressed in the formula: > IDLE hold time = 2**(connectRetryCnt)*60 > ---------------- > What do you think? > Sue Hares Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA10175 for ; Tue, 15 Jan 2002 16:48:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B03AC9127B; Tue, 15 Jan 2002 16:48:06 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 862BD91279; Tue, 15 Jan 2002 16:48: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 219B6912A8 for ; Tue, 15 Jan 2002 16:48:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id BF7185DDCB; Tue, 15 Jan 2002 16:48:02 -0500 (EST) Delivered-To: idr@merit.edu Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id 60F9C5DDCA for ; Tue, 15 Jan 2002 16:48:02 -0500 (EST) Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id DFFC73F62; Tue, 15 Jan 2002 13:50:48 -0800 (PST) Received: from khonsu.sw.nexsi.com ([172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id NAA14097; Tue, 15 Jan 2002 13:47:08 -0800 Date: Tue, 15 Jan 2002 13:47:05 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <127108184541.20020115134705@nexsi.com> To: Susan Hares Cc: Russ White , Eric Gray , Russ White , Inter-Domain Routing Mailing List Subject: Re: bgp4-17 Cease subcode In-Reply-To: <5.0.0.25.0.20020115144930.04a32a00@mail.nexthop.com> References: <5.0.0.25.0.20020115144930.04a32a00@mail.nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Sue: > Alex: > I know you have been active on the mailing list. > And you didn't read it before the last call on the FSM. Well, I skimmed :) > And this question was asked on the list because I > wondered about it. > ;-)... --- I guess not even great people are > perfect. > OK, now I've got 2 more against (4 total). And 15-20 votes > for it inside the draft. > I'm sure your vote is a bit more specific. :-)... > Is the issue you want to pull exponential out of the draft? > This is a change to the BGP specification. This draft > is about corrections not changes in functionality. When I was writing the message below, I was hesitating between leaving the FSM the way it is in -17 and saying any functionally equivalent implementation is all right, and removing the new state and encouraging people to "play" with the Idle state. I inclined towards the second because the new state in the spec would probably still raise the issue of whether current implementations comply ("Hey, I never saw "IdleHold" when I did "sho ip bgp", you guys are not RFC compliant!!!", blah, blah...) > What do we do? See my reply to your other message. Alex. > Sue Hares > At 10:30 AM 1/15/2002 -0800, Alex Zinin wrote: >>Russ, Eric, >> >> I tend to agree here... >> I'm currently reviewing the FSM and the impression I'm >> getting is that we can go without the IdleHold state >> and say that implementations may/should use some local mechanisms >> to hold BGP sessions in the *Idle* state to avoid excessive >> session flapping. I think this will be simpler and will >> match current implementations better... >> >>-- >>Alex Zinin >> Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA09981 for ; Tue, 15 Jan 2002 16:42:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F391691276; Tue, 15 Jan 2002 16:41:29 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD4C091277; Tue, 15 Jan 2002 16:41: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 B93B191276 for ; Tue, 15 Jan 2002 16:41:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 628F95DDB0; Tue, 15 Jan 2002 16:41: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 D85735DDAC for ; Tue, 15 Jan 2002 16:41:26 -0500 (EST) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 602F71DCC62; Tue, 15 Jan 2002 13:41:26 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv2.redback.com (Postfix) with ESMTP id 47805979C1; Tue, 15 Jan 2002 13:41:24 -0800 (PST) To: Susan Hares Cc: Russ White , Jeffrey Haas , idr@merit.edu, enke@redback.com Subject: Re: IDR WG Last Call In-Reply-To: Message from Susan Hares of "Tue, 15 Jan 2002 16:32:23 EST." <5.0.0.25.0.20020115163041.02879998@mail.nexthop.com> Date: Tue, 15 Jan 2002 13:41:24 -0800 From: Enke Chen Message-Id: <20020115214125.47805979C1@popserv2.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Sue, > Date: Tue, 15 Jan 2002 16:32:23 -0500 > To: Russ White > From: Susan Hares > Subject: Re: IDR WG Last Call > Cc: Enke Chen , Susan Hares , > Jeffrey Haas , idr@merit.edu > In-Reply-To: .com> > > I know of at least 2 implementations that do 1,2,3 and Do we know if "SAFI 3" is used in sending? That would not work without the receiver supporting it. If "SAFI 3" is not used in sending, it seems that it would be safe to remove it from the spec.. -- Enke > I know of at least 2 implementations that do not (1,2 only). > > Sigh.. Yakov is drafting a change to text to try > to address all of these concerns. I'll await > his note. > > sue > > At 03:02 PM 1/15/2002 -0500, Russ White wrote: > > >Correct--SAFI 3.... There aren't any implementations that I've > >seen, and it does complicate matters a bit more than needed. > > > >Russ > > > >On Tue, 15 Jan 2002, Enke Chen wrote: > > > > > Sue, > > > > > > > Date: Tue, 15 Jan 2002 14:49:14 -0500 > > > > To: Russ White > > > > From: Susan Hares > > > > Subject: Re: IDR WG Last Call > > > > Cc: Enke Chen , Jeffrey Haas , > > > > idr@merit.edu > > > > In-Reply-To: > > > .com> > > > > References: <20020115174716.CC5A815D3C1@popserv1.redback.com> > > > > Mime-Version: 1.0 > > > > Content-Type: text/plain; charset="us-ascii"; format=flowed > > > > X-NextHop-MailScanner: Found to be clean > > > > > > > > Russ: > > > > > > > > We had that vote 1 month ago. The overwhelming > > > > majority was to keep it in. We are not re-opening > > > > that issue having closed it on the mail list already. > > > > > > The issue then was the "BGP State Machine". Russ was talking abut "SAFI 3" > > > in his message if I am not mistaken. > > > > > > -- Enke > > > > > > > > > > > > > > > Sue > > > > > > > > At 01:03 PM 1/15/2002 -0500, Russ White wrote: > > > > > > > > >I think it's probably a good idea to get rid of this out of the > > > > >spec--it would make things cleaner. > > > > > > > > > >Russ > > > > > > > > > >On Tue, 15 Jan 2002, Enke Chen wrote: > > > > > > > > > > > Jeff, > > > > > > > > > > > > > Date: Mon, 14 Jan 2002 23:21:28 -0500 > > > > > > > From: Jeffrey Haas > > > > > > > To: Enke Chen > > > > > > > Cc: idr@merit.edu > > > > > > > Subject: Re: IDR WG Last Call > > > > > > > Message-ID: <20020114232128.B14701@nexthop.com> > > > > > > > > > > > > > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote: > > > > > > > > It seems that the "SAFI 3" certainly makes the issue at hand > > much more > > > > > > > > complicated. > > > > > > > > > > > > > > IMO, SAFI 3 was probably not a very good idea. Dealing with it can > > > > > > > be a real pain in the implementation. :-) > > > > > > > > > > > > So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem > > to add > > > > > > much value, but has caused a lot of confusion and complexity. I > > am not > > > > > > aware of any depolyment either. > > > > > > > > > > > > > > > > > > > > > As Yakov and Sue pointed out, it is a good idea to discourage > > > > > > > > having one prefix in multiple fields of an update message. How > > > > > about the > > > > > > > > following text: > > > > > > > > > > > > > > > > An UPDATE message should not include the same address > > prefix in > > > > > more than > > > > > > > > one of the following fields: WITHDRAWN ROUTES field, Network > > > > > Reachability > > > > > > > > Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI > > > > > field. The > > > > > > > > processing of an UPDATE message in this form is un-defined. > > > > > > > > > > > > > > I think that "undefined" is overkill. I would suggest the > > following > > > > > instead: > > > > > > > > > > > > > > An UPDATE message should not include the same address prefix in > > > > > > > more than one of the following fields: WITHDRAWN ROUTES, Network > > > > > > > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI. > > > > > > > An implementation that receives a packet in this form should > > process > > > > > > > the Update as if it had processed it in the following order: > > > > > > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer > > > > > > > Reachability Information. > > > > > > > > > > > > > > The wording could probably use some tightening. > > > > > > > > > > > > > > The intended result is that reachability rules over unreachability. > > > > > > > > > > > > If we want to define the behavior, I would like to suggest > > sticking to > > > > > > the order in the message. That probably would reflect the sender's > > > > > > intention more closely, and make the processing simpler. > > > > > > > > > > > > -- Enke > > > > > > > > > > > > > > > > > > > > > >_____________________________ > > > > >riw@cisco.com <>< Grace Alone > > > > > > > > > > > > > > >_____________________________ > >riw@cisco.com <>< Grace Alone > > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA09806 for ; Tue, 15 Jan 2002 16:35:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B604B91278; Tue, 15 Jan 2002 16:35:10 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 87E9391279; Tue, 15 Jan 2002 16:35: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 EBE5591278 for ; Tue, 15 Jan 2002 16:35:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id CF7F85DDCA; Tue, 15 Jan 2002 16:35:08 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 8C0655DDB0 for ; Tue, 15 Jan 2002 16:35:08 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA16995; Tue, 15 Jan 2002 16:35:05 -0500 (EST) Date: Tue, 15 Jan 2002 16:35:05 -0500 (EST) From: Russ White Reply-To: Russ White To: Susan Hares Cc: Alex Zinin , Eric Gray , Inter-Domain Routing Mailing List Subject: Re: bgp4-17 Cease subcode In-Reply-To: <5.0.0.25.0.20020115155854.04a7cd68@mail.nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Yes, this sounds reasonable. :-) Russ On Tue, 15 Jan 2002, Susan Hares wrote: > > Russ: > > Can I change my mind on opening the FSM conversation? > Two people asking the same question encouraged me to do this. > Thanks for the input. (keep those email terminals smokin' with > the input ;-)).... > > How about a 3rd option --- Let's go back to the problem set > and fix the text from there. > > Problem 1 - persistent flapping (bad thing), recommended > fix: IDLE hold timer > > Problem 2 - FSM text doesn't specify how this features > works from all states. Result: > inter-operability between implementations is > problematic. [another bad thing] > > If people are deploying BGP without the recommended (but > not required) IDLE hold timer for persistent flapping, > then this specification should allow it. [filter of what is deployed] > > > Option 3 - fix both with background text that says: > 1) recommended to have IDLE Hold timer, and > 2) Not required. > > Now to the text: > > Fix to problem 1 - FSM does not require you to implemented > the hold off. > > How about replacing this following text at the IDLE State: > > IDLE > ============= > > From this text: > >A manual start event is a start event initiated > >by an operator. An automatic start event is > >a start event generated by the system. > > The text can be: a manual event is intended to be > a start event generated by "manual" intervention. If the > presistent flapping suppression option is not set, > all start events will be manual start events. > > How about re-adding this section at the bottom > of the state machine? > > > Manual versus Automatic start in the FSM > > If a BGP speaker detects an error, it shuts down the > connection and changes its state to Idle-hold. Getting out > of the Idle state requires generation of the Start event. > Such a start event can either be manual or automatic. > > If this start event is generated automatically, then > persistent BGP errors may result in persistent flapping > of the speaker. To avoid such a condition it is > recommended that the Start events should not be generated > immediately for a peer that was previously transitioned > to Idle due to an error. For a peer that was previously > transitioned to Idle due to an error, the time between > consecutive generation of Start events, if such events are > generated automatically, shall exponentially increase. The > value of the initial timer shall be 60 seconds. The time shall > be doubled for each consecutive retry.The formula for this > expotential backoff is expressed in the formula: > > IDLE hold time = 2**(connectRetryCnt)*60 > > > ---------------- > > What do you think? > > > Sue Hares > > > > At 03:01 PM 1/15/2002 -0500, Russ White wrote: > > >So, then it sounds like the way we should approach this (the > >idlehold state in the fsm) is to think about it seperately from > >the draft 17 issue (?). > > > >Russ > > > >On Tue, 15 Jan 2002, Susan Hares wrote: > > > > > > > > Alex: > > > > > > I know you have been active on the mailing list. > > > And you didn't read it before the last call on the FSM. > > > And this question was asked on the list because I > > > wondered about it. > > > > > > ;-)... --- I guess not even great people are > > > perfect. > > > > > > OK, now I've got 2 more against (4 total). And 15-20 votes > > > for it inside the draft. > > > > > > I'm sure your vote is a bit more specific. :-)... > > > > > > Is the issue you want to pull exponential out of the draft? > > > This is a change to the BGP specification. This draft > > > is about corrections not changes in functionality. > > > > > > What do we do? > > > > > > Sue Hares > > > > > > > > > > > > At 10:30 AM 1/15/2002 -0800, Alex Zinin wrote: > > > > > > >Russ, Eric, > > > > > > > > I tend to agree here... > > > > I'm currently reviewing the FSM and the impression I'm > > > > getting is that we can go without the IdleHold state > > > > and say that implementations may/should use some local mechanisms > > > > to hold BGP sessions in the *Idle* state to avoid excessive > > > > session flapping. I think this will be simpler and will > > > > match current implementations better... > > > > > > > >-- > > > >Alex Zinin > > > > > > > >Tuesday, January 15, 2002, 7:21:06 AM, Russ White wrote: > > > > > > > > > > > > > Something like: "BGP implementations can/should/must > > > > > (?) implement some method to prevent continuous flapping of > > > > > peering sessions at a high rate," and then a footbote explaining > > > > > that an exponential backoff is one such possible method? > > > > > > > > > Russ > > > > > > > > > On Tue, 15 Jan 2002, Eric Gray wrote: > > > > > > > > >> Russ, > > > > >> > > > > >> Very good point. However, how would you represent "do some > > > > >> private magic here" in an FSM? That may make it the dreaded ISM. > > > > >> Perhaps it might be sufficient to remove this from the FSM and > > > > >> add a footnote (possibly mentioning an exponential back-off as an > > > > >> example?). > > > > >> > > > > >> You wrote: > > > > >> > > > > >> > Well, I just took it as 'do people do this?' I agree that it > > > > >> > won't cause interop problems either way--it's actually something > > > > >> > that's implementation local, so I'm not certain why the > > > > >> > exponential backoff would be in the fsm (?). There are, in other > > > > >> > words, other ways I could imagine handling this problem that > > > > >> > wouldn't effect interoperability as well.... > > > > >> > > > > > >> > :-) > > > > >> > > > > > >> > Russ > > > > >> > > > > > >> > On Tue, 15 Jan 2002, Eric Gray wrote: > > > > >> > > > > > >> > > Russ, > > > > >> > > > > > > >> > > I don't think that NAKs are in order on this question - even > > > > from the > > > > >> > > 1500 pound dragon. :-) > > > > >> > > > > > > >> > > The fact that anyone's implementation doesn't do X is > > > > important only > > > > >> > > if not doing X causes interoperability problems with > > implementations > > > > >> > > that do X. That is not the case here, I believe... > > > > >> > > > > > > >> > > You wrote: > > > > >> > > > > > > >> > > > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter > > wrote: > > > > >> > > > > > > Please remember that the goal of the draft is to document > > > > >> > > > > > > what is *currently* implemented and deployed, *not* what > > > > >> > > > > > > *could* be implemented and deployed. > > > > >> > > > > > > > > > >> > > > > > Is the expoential backoff in the FSM in current > > implementations? > > > > >> > > > > > > > > >> > > > > I guess we are going to find this out as part of the > > > > >> > > > > implementation report. And if it is not in (at least two) > > > > >> > > > > current implementations, we'll take it out of the text. > > > > >> > > > > > > > >> > > > Cisco doesn't do this.... > > > > >> > > > > > > > >> > > > :-) > > > > >> > > > > > > > >> > > > Russ > > > > >> > > > > > > > >> > > > _____________________________ > > > > >> > > > riw@cisco.com <>< Grace Alone > > > > >> > > > > > > >> > > -- > > > > >> > > Eric Gray (mailto:eric.gray@sandburst.com) > > > > >> > > http://www.mindspring.com/~ewgray > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > >> > _____________________________ > > > > >> > riw@cisco.com <>< Grace Alone > > > > >> > > > > >> -- > > > > >> Eric Gray (mailto:eric.gray@sandburst.com) > > > > >> http://www.mindspring.com/~ewgray > > > > >> > > > > >> > > > > >> > > > > > > > > > _____________________________ > > > > > riw@cisco.com <>< Grace Alone > > > > > > > > > >_____________________________ > >riw@cisco.com <>< Grace Alone > > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA09700 for ; Tue, 15 Jan 2002 16:33:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F015591273; Tue, 15 Jan 2002 16:32:40 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1F1C91278; Tue, 15 Jan 2002 16:32: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 995A191273 for ; Tue, 15 Jan 2002 16:32:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 51FC45DDA5; Tue, 15 Jan 2002 16:32:38 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id D05465DDAC for ; Tue, 15 Jan 2002 16:32:37 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0FLWP398942; Tue, 15 Jan 2002 16:32:25 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020115163041.02879998@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 15 Jan 2002 16:32:23 -0500 To: Russ White From: Susan Hares Subject: Re: IDR WG Last Call Cc: Enke Chen , Susan Hares , Jeffrey Haas , idr@merit.edu In-Reply-To: References: <20020115200052.03951979C1@popserv2.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk I know of at least 2 implementations that do 1,2,3 and I know of at least 2 implementations that do not (1,2 only). Sigh.. Yakov is drafting a change to text to try to address all of these concerns. I'll await his note. sue At 03:02 PM 1/15/2002 -0500, Russ White wrote: >Correct--SAFI 3.... There aren't any implementations that I've >seen, and it does complicate matters a bit more than needed. > >Russ > >On Tue, 15 Jan 2002, Enke Chen wrote: > > > Sue, > > > > > Date: Tue, 15 Jan 2002 14:49:14 -0500 > > > To: Russ White > > > From: Susan Hares > > > Subject: Re: IDR WG Last Call > > > Cc: Enke Chen , Jeffrey Haas , > > > idr@merit.edu > > > In-Reply-To: > > .com> > > > References: <20020115174716.CC5A815D3C1@popserv1.redback.com> > > > Mime-Version: 1.0 > > > Content-Type: text/plain; charset="us-ascii"; format=flowed > > > X-NextHop-MailScanner: Found to be clean > > > > > > Russ: > > > > > > We had that vote 1 month ago. The overwhelming > > > majority was to keep it in. We are not re-opening > > > that issue having closed it on the mail list already. > > > > The issue then was the "BGP State Machine". Russ was talking abut "SAFI 3" > > in his message if I am not mistaken. > > > > -- Enke > > > > > > > > > > > Sue > > > > > > At 01:03 PM 1/15/2002 -0500, Russ White wrote: > > > > > > >I think it's probably a good idea to get rid of this out of the > > > >spec--it would make things cleaner. > > > > > > > >Russ > > > > > > > >On Tue, 15 Jan 2002, Enke Chen wrote: > > > > > > > > > Jeff, > > > > > > > > > > > Date: Mon, 14 Jan 2002 23:21:28 -0500 > > > > > > From: Jeffrey Haas > > > > > > To: Enke Chen > > > > > > Cc: idr@merit.edu > > > > > > Subject: Re: IDR WG Last Call > > > > > > Message-ID: <20020114232128.B14701@nexthop.com> > > > > > > > > > > > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote: > > > > > > > It seems that the "SAFI 3" certainly makes the issue at hand > much more > > > > > > > complicated. > > > > > > > > > > > > IMO, SAFI 3 was probably not a very good idea. Dealing with it can > > > > > > be a real pain in the implementation. :-) > > > > > > > > > > So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem > to add > > > > > much value, but has caused a lot of confusion and complexity. I > am not > > > > > aware of any depolyment either. > > > > > > > > > > > > > > > > > > As Yakov and Sue pointed out, it is a good idea to discourage > > > > > > > having one prefix in multiple fields of an update message. How > > > > about the > > > > > > > following text: > > > > > > > > > > > > > > An UPDATE message should not include the same address > prefix in > > > > more than > > > > > > > one of the following fields: WITHDRAWN ROUTES field, Network > > > > Reachability > > > > > > > Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI > > > > field. The > > > > > > > processing of an UPDATE message in this form is un-defined. > > > > > > > > > > > > I think that "undefined" is overkill. I would suggest the > following > > > > instead: > > > > > > > > > > > > An UPDATE message should not include the same address prefix in > > > > > > more than one of the following fields: WITHDRAWN ROUTES, Network > > > > > > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI. > > > > > > An implementation that receives a packet in this form should > process > > > > > > the Update as if it had processed it in the following order: > > > > > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer > > > > > > Reachability Information. > > > > > > > > > > > > The wording could probably use some tightening. > > > > > > > > > > > > The intended result is that reachability rules over unreachability. > > > > > > > > > > If we want to define the behavior, I would like to suggest > sticking to > > > > > the order in the message. That probably would reflect the sender's > > > > > intention more closely, and make the processing simpler. > > > > > > > > > > -- Enke > > > > > > > > > > > > > > > > > >_____________________________ > > > >riw@cisco.com <>< Grace Alone > > > > > > > > > >_____________________________ >riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA09666 for ; Tue, 15 Jan 2002 16:31:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B87A99122A; Tue, 15 Jan 2002 16:30:45 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8875D91276; Tue, 15 Jan 2002 16:30:45 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 495C89122A for ; Tue, 15 Jan 2002 16:30:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 267EF5DDAC; Tue, 15 Jan 2002 16:30:44 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id CB7F65DDA5 for ; Tue, 15 Jan 2002 16:30:43 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0FLUK398886; Tue, 15 Jan 2002 16:30:20 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020115155854.04a7cd68@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 15 Jan 2002 16:30:18 -0500 To: Russ White From: Susan Hares Subject: Re: bgp4-17 Cease subcode Cc: Susan Hares , Alex Zinin , Eric Gray , Inter-Domain Routing Mailing List In-Reply-To: References: <5.0.0.25.0.20020115144930.04a32a00@mail.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Russ: Can I change my mind on opening the FSM conversation? Two people asking the same question encouraged me to do this. Thanks for the input. (keep those email terminals smokin' with the input ;-)).... How about a 3rd option --- Let's go back to the problem set and fix the text from there. Problem 1 - persistent flapping (bad thing), recommended fix: IDLE hold timer Problem 2 - FSM text doesn't specify how this features works from all states. Result: inter-operability between implementations is problematic. [another bad thing] If people are deploying BGP without the recommended (but not required) IDLE hold timer for persistent flapping, then this specification should allow it. [filter of what is deployed] Option 3 - fix both with background text that says: 1) recommended to have IDLE Hold timer, and 2) Not required. Now to the text: Fix to problem 1 - FSM does not require you to implemented the hold off. How about replacing this following text at the IDLE State: IDLE ============= From this text: >A manual start event is a start event initiated >by an operator. An automatic start event is >a start event generated by the system. The text can be: a manual event is intended to be a start event generated by "manual" intervention. If the presistent flapping suppression option is not set, all start events will be manual start events. How about re-adding this section at the bottom of the state machine? Manual versus Automatic start in the FSM If a BGP speaker detects an error, it shuts down the connection and changes its state to Idle-hold. Getting out of the Idle state requires generation of the Start event. Such a start event can either be manual or automatic. If this start event is generated automatically, then persistent BGP errors may result in persistent flapping of the speaker. To avoid such a condition it is recommended that the Start events should not be generated immediately for a peer that was previously transitioned to Idle due to an error. For a peer that was previously transitioned to Idle due to an error, the time between consecutive generation of Start events, if such events are generated automatically, shall exponentially increase. The value of the initial timer shall be 60 seconds. The time shall be doubled for each consecutive retry.The formula for this expotential backoff is expressed in the formula: IDLE hold time = 2**(connectRetryCnt)*60 ---------------- What do you think? Sue Hares At 03:01 PM 1/15/2002 -0500, Russ White wrote: >So, then it sounds like the way we should approach this (the >idlehold state in the fsm) is to think about it seperately from >the draft 17 issue (?). > >Russ > >On Tue, 15 Jan 2002, Susan Hares wrote: > > > > > Alex: > > > > I know you have been active on the mailing list. > > And you didn't read it before the last call on the FSM. > > And this question was asked on the list because I > > wondered about it. > > > > ;-)... --- I guess not even great people are > > perfect. > > > > OK, now I've got 2 more against (4 total). And 15-20 votes > > for it inside the draft. > > > > I'm sure your vote is a bit more specific. :-)... > > > > Is the issue you want to pull exponential out of the draft? > > This is a change to the BGP specification. This draft > > is about corrections not changes in functionality. > > > > What do we do? > > > > Sue Hares > > > > > > > > At 10:30 AM 1/15/2002 -0800, Alex Zinin wrote: > > > > >Russ, Eric, > > > > > > I tend to agree here... > > > I'm currently reviewing the FSM and the impression I'm > > > getting is that we can go without the IdleHold state > > > and say that implementations may/should use some local mechanisms > > > to hold BGP sessions in the *Idle* state to avoid excessive > > > session flapping. I think this will be simpler and will > > > match current implementations better... > > > > > >-- > > >Alex Zinin > > > > > >Tuesday, January 15, 2002, 7:21:06 AM, Russ White wrote: > > > > > > > > > > Something like: "BGP implementations can/should/must > > > > (?) implement some method to prevent continuous flapping of > > > > peering sessions at a high rate," and then a footbote explaining > > > > that an exponential backoff is one such possible method? > > > > > > > Russ > > > > > > > On Tue, 15 Jan 2002, Eric Gray wrote: > > > > > > >> Russ, > > > >> > > > >> Very good point. However, how would you represent "do some > > > >> private magic here" in an FSM? That may make it the dreaded ISM. > > > >> Perhaps it might be sufficient to remove this from the FSM and > > > >> add a footnote (possibly mentioning an exponential back-off as an > > > >> example?). > > > >> > > > >> You wrote: > > > >> > > > >> > Well, I just took it as 'do people do this?' I agree that it > > > >> > won't cause interop problems either way--it's actually something > > > >> > that's implementation local, so I'm not certain why the > > > >> > exponential backoff would be in the fsm (?). There are, in other > > > >> > words, other ways I could imagine handling this problem that > > > >> > wouldn't effect interoperability as well.... > > > >> > > > > >> > :-) > > > >> > > > > >> > Russ > > > >> > > > > >> > On Tue, 15 Jan 2002, Eric Gray wrote: > > > >> > > > > >> > > Russ, > > > >> > > > > > >> > > I don't think that NAKs are in order on this question - even > > > from the > > > >> > > 1500 pound dragon. :-) > > > >> > > > > > >> > > The fact that anyone's implementation doesn't do X is > > > important only > > > >> > > if not doing X causes interoperability problems with > implementations > > > >> > > that do X. That is not the case here, I believe... > > > >> > > > > > >> > > You wrote: > > > >> > > > > > >> > > > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter > wrote: > > > >> > > > > > > Please remember that the goal of the draft is to document > > > >> > > > > > > what is *currently* implemented and deployed, *not* what > > > >> > > > > > > *could* be implemented and deployed. > > > >> > > > > > > > > >> > > > > > Is the expoential backoff in the FSM in current > implementations? > > > >> > > > > > > > >> > > > > I guess we are going to find this out as part of the > > > >> > > > > implementation report. And if it is not in (at least two) > > > >> > > > > current implementations, we'll take it out of the text. > > > >> > > > > > > >> > > > Cisco doesn't do this.... > > > >> > > > > > > >> > > > :-) > > > >> > > > > > > >> > > > Russ > > > >> > > > > > > >> > > > _____________________________ > > > >> > > > riw@cisco.com <>< Grace Alone > > > >> > > > > > >> > > -- > > > >> > > Eric Gray (mailto:eric.gray@sandburst.com) > > > >> > > http://www.mindspring.com/~ewgray > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > _____________________________ > > > >> > riw@cisco.com <>< Grace Alone > > > >> > > > >> -- > > > >> Eric Gray (mailto:eric.gray@sandburst.com) > > > >> http://www.mindspring.com/~ewgray > > > >> > > > >> > > > >> > > > > > > > _____________________________ > > > > riw@cisco.com <>< Grace Alone > > > > > >_____________________________ >riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA09269 for ; Tue, 15 Jan 2002 16:17:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5F77F91274; Tue, 15 Jan 2002 16:16:25 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 778DE91277; Tue, 15 Jan 2002 16:16:24 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 204CC91274 for ; Tue, 15 Jan 2002 16:16:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id F06655DDAC; Tue, 15 Jan 2002 16:16:22 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id A9F9E5DDA5 for ; Tue, 15 Jan 2002 16:16:22 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0FLFr398465; Tue, 15 Jan 2002 16:15:53 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0FLFqL16584; Tue, 15 Jan 2002 16:15:52 -0500 (EST) Date: Tue, 15 Jan 2002 16:15:52 -0500 From: Jeffrey Haas To: Enke Chen Cc: idr@merit.edu Subject: Re: IDR WG Last Call Message-ID: <20020115161552.C16527@nexthop.com> References: <20020115174716.CC5A815D3C1@popserv1.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020115174716.CC5A815D3C1@popserv1.redback.com>; from enke@redback.com on Tue, Jan 15, 2002 at 09:47:16AM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Tue, Jan 15, 2002 at 09:47:16AM -0800, Enke Chen wrote: > If we want to define the behavior, I would like to suggest sticking to > the order in the message. That probably would reflect the sender's > intention more closely, and make the processing simpler. Two issues: 1. Path attribute order, when sorted, puts MP_UNREACH_NLRI after MP_REACH_NLRI. 2. Path attributes are now explicitly allowed to be unordered. I'd rather see some determinism across implementations. > -- Enke -- Jeff Haas NextHop Technologies 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 QAA09203 for ; Tue, 15 Jan 2002 16:13:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 79C9F9126A; Tue, 15 Jan 2002 16:12:51 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49ADA9126C; Tue, 15 Jan 2002 16:12: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 499CE9126A for ; Tue, 15 Jan 2002 16:12:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 242035DDCA; Tue, 15 Jan 2002 16:12:50 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 0A7A15DDA5 for ; Tue, 15 Jan 2002 16:12:50 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0FLCM398333; Tue, 15 Jan 2002 16:12:22 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0FLCMa16574; Tue, 15 Jan 2002 16:12:22 -0500 (EST) Date: Tue, 15 Jan 2002 16:12:22 -0500 From: Jeffrey Haas To: Dave Thaler Cc: Enke Chen , idr@merit.edu Subject: Re: IDR WG Last Call Message-ID: <20020115161222.B16527@nexthop.com> References: <2E33960095B58E40A4D3345AB9F65EC1047CE682@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1047CE682@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>; from dthaler@windows.microsoft.com on Tue, Jan 15, 2002 at 11:13:42AM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Dave, On Tue, Jan 15, 2002 at 11:13:42AM -0800, Dave Thaler wrote: > SAFI 3 was put in at operator's requests (Dorian, for one, I forget who > else now). They considered it a MUST to avoid doubling the routing > table size and amount of BGP traffic when one's unicast and multicast > topology are the same. > > Before taking it out, you might want to check with Dorian. While I agree that its nice in theory, you have the added difficulty of having to maintain additional state for things such as WRD and potentially awkward queue mechanisms for outgoing routes. As such, you actually implement at least as much, if not more, infrastructure to deal with the additional overhead of having a SAFI that covers the unicast+multicast case. Additionally, policy is now a real pain - and very ambiguous in the current spec. If you say "accept unicast and multicast routes", does that mean accept only SAFI 3 or SAFI's 1, 2 and 3? As Sue has mentioned, treating them as bits works fine for these three SAFI's. But I'd rather not have to. I'm not going to argue very hard for removing SAFI 3 - we already implement it. But there are complications that don't seem to be accounted for with regards to its supposed information overhead reduction. > -Dave -- 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 QAA08999 for ; Tue, 15 Jan 2002 16:06:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A4FF691269; Tue, 15 Jan 2002 16:05:35 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CAD39126A; Tue, 15 Jan 2002 16:05: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 628ED91269 for ; Tue, 15 Jan 2002 16:05:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 35B5F5DDB0; Tue, 15 Jan 2002 16:05:34 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id DE9775DDA5 for ; Tue, 15 Jan 2002 16:05:33 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0FL5Q398122; Tue, 15 Jan 2002 16:05:27 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0FL5Qg16553; Tue, 15 Jan 2002 16:05:26 -0500 (EST) Date: Tue, 15 Jan 2002 16:05:26 -0500 From: Jeffrey Haas To: Susan Hares Cc: Yakov Rekhter , idr@merit.edu Subject: Re: bgp4-17 Cease subcode Message-ID: <20020115160526.A16527@nexthop.com> References: <200201141728.g0EHSr633936@merlot.juniper.net> <005001c2b9ba$3094a9e0$9989bc3e@tom3> <200201141728.g0EHSr633936@merlot.juniper.net> <20020114123700.C7761@nexthop.com> <5.0.0.25.0.20020114151919.0329db98@mail.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.0.25.0.20020114151919.0329db98@mail.nexthop.com>; from skh@nexthop.com on Mon, Jan 14, 2002 at 03:19:58PM -0500 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Gentlefolk, Perhaps this will add some clarification on "what does this mean to me" to have the "new state" in the FSM: 1. RFC 1771 has exponential backoff documented. 1a. The current draft allows a ceiling on this value. 2. The original FSM documents 6 states. When you attempt to expand the state table from the normative text (even without the distinction of a manual vs. automatic start/stop events), you arrive at another undocumented state. 3. The draft explicitly documents this state and makes explicit the difference between the manual vs. the automatic events. The state table the Sue had posted some time ago (wasn't that supposed to be in the appendix?) covers all the events and the states. 4. What does this do to implementations that supported the exponential backoff? Probably not much. You can LIVE with the existing Idle state for both MIB and for CLI display purposes. What was originally implied was that there was a timer (you could show it in your CLI for example) that would implement the exponential backoff. 5. The new draft makes the state explicitly visible. As this primarily affects the display within a CLI and the MIB rather than the on-the-wire protocol, there's no need to panic. Implementation: If you implement exponential backoff, it should be pretty trivial to insert the new "state" into you FSM to deal with the un-expired timer event. It will be 7 in the MIB obviously. :-) If we don't have enough wiggle room in the spec to deal with those who don't implment the expoential backoff, perhaps a SHOULD can be added in the appropriate spot - or the spec should remain silent on the issue and let people be non-compliant. Sue, Yakov: Is the fact that the new state would only be visible by a outside of protocol scope means going to stop us from going to full standard? Technically, it is measurable by watching for the packets and the delays between them but this doesn't break interoperability. -- 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 PAA07382 for ; Tue, 15 Jan 2002 15:16:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 98F2391260; Tue, 15 Jan 2002 15:15:33 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62A8891261; Tue, 15 Jan 2002 15:15:33 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C99891260 for ; Tue, 15 Jan 2002 15:15:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1BC505DDC7; Tue, 15 Jan 2002 15:15:32 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id C59455DDA5 for ; Tue, 15 Jan 2002 15:15:31 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0FKFG396504; Tue, 15 Jan 2002 15:15:16 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0FKFH016478; Tue, 15 Jan 2002 15:15:17 -0500 (EST) Date: Tue, 15 Jan 2002 15:15:16 -0500 From: Jeffrey Haas To: Russ White Cc: idr@merit.edu Subject: Re: IDR WG Last Call Message-ID: <20020115151516.A16106@nexthop.com> References: <20020115200052.03951979C1@popserv2.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ruwhite@cisco.com on Tue, Jan 15, 2002 at 03:02:55PM -0500 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Tue, Jan 15, 2002 at 03:02:55PM -0500, Russ White wrote: > Correct--SAFI 3.... There aren't any implementations that I've > seen, and it does complicate matters a bit more than needed. Ahem. GateD supports it perfectly fine. > Russ -- 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 PAA07051 for ; Tue, 15 Jan 2002 15:05:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2CBBB91268; Tue, 15 Jan 2002 15:03:25 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F042991275; Tue, 15 Jan 2002 15:03:24 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D885791268 for ; Tue, 15 Jan 2002 15:03:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id B15E35DDC9; Tue, 15 Jan 2002 15:03:19 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 6D4975DDC8 for ; Tue, 15 Jan 2002 15:03:19 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA05254; Tue, 15 Jan 2002 15:02:55 -0500 (EST) Date: Tue, 15 Jan 2002 15:02:55 -0500 (EST) From: Russ White Reply-To: Russ White To: Enke Chen Cc: Susan Hares , Jeffrey Haas , idr@merit.edu Subject: Re: IDR WG Last Call In-Reply-To: <20020115200052.03951979C1@popserv2.redback.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Correct--SAFI 3.... There aren't any implementations that I've seen, and it does complicate matters a bit more than needed. Russ On Tue, 15 Jan 2002, Enke Chen wrote: > Sue, > > > Date: Tue, 15 Jan 2002 14:49:14 -0500 > > To: Russ White > > From: Susan Hares > > Subject: Re: IDR WG Last Call > > Cc: Enke Chen , Jeffrey Haas , > > idr@merit.edu > > In-Reply-To: > .com> > > References: <20020115174716.CC5A815D3C1@popserv1.redback.com> > > Mime-Version: 1.0 > > Content-Type: text/plain; charset="us-ascii"; format=flowed > > X-NextHop-MailScanner: Found to be clean > > > > Russ: > > > > We had that vote 1 month ago. The overwhelming > > majority was to keep it in. We are not re-opening > > that issue having closed it on the mail list already. > > The issue then was the "BGP State Machine". Russ was talking abut "SAFI 3" > in his message if I am not mistaken. > > -- Enke > > > > > > > Sue > > > > At 01:03 PM 1/15/2002 -0500, Russ White wrote: > > > > >I think it's probably a good idea to get rid of this out of the > > >spec--it would make things cleaner. > > > > > >Russ > > > > > >On Tue, 15 Jan 2002, Enke Chen wrote: > > > > > > > Jeff, > > > > > > > > > Date: Mon, 14 Jan 2002 23:21:28 -0500 > > > > > From: Jeffrey Haas > > > > > To: Enke Chen > > > > > Cc: idr@merit.edu > > > > > Subject: Re: IDR WG Last Call > > > > > Message-ID: <20020114232128.B14701@nexthop.com> > > > > > > > > > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote: > > > > > > It seems that the "SAFI 3" certainly makes the issue at hand much more > > > > > > complicated. > > > > > > > > > > IMO, SAFI 3 was probably not a very good idea. Dealing with it can > > > > > be a real pain in the implementation. :-) > > > > > > > > So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem to add > > > > much value, but has caused a lot of confusion and complexity. I am not > > > > aware of any depolyment either. > > > > > > > > > > > > > > > As Yakov and Sue pointed out, it is a good idea to discourage > > > > > > having one prefix in multiple fields of an update message. How > > > about the > > > > > > following text: > > > > > > > > > > > > An UPDATE message should not include the same address prefix in > > > more than > > > > > > one of the following fields: WITHDRAWN ROUTES field, Network > > > Reachability > > > > > > Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI > > > field. The > > > > > > processing of an UPDATE message in this form is un-defined. > > > > > > > > > > I think that "undefined" is overkill. I would suggest the following > > > instead: > > > > > > > > > > An UPDATE message should not include the same address prefix in > > > > > more than one of the following fields: WITHDRAWN ROUTES, Network > > > > > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI. > > > > > An implementation that receives a packet in this form should process > > > > > the Update as if it had processed it in the following order: > > > > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer > > > > > Reachability Information. > > > > > > > > > > The wording could probably use some tightening. > > > > > > > > > > The intended result is that reachability rules over unreachability. > > > > > > > > If we want to define the behavior, I would like to suggest sticking to > > > > the order in the message. That probably would reflect the sender's > > > > intention more closely, and make the processing simpler. > > > > > > > > -- Enke > > > > > > > > > > > > > >_____________________________ > > >riw@cisco.com <>< Grace Alone > > > > > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA07021 for ; Tue, 15 Jan 2002 15:04:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DDA0791267; Tue, 15 Jan 2002 15:01:48 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD71991268; Tue, 15 Jan 2002 15:01: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 878A791267 for ; Tue, 15 Jan 2002 15:01:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A5465DDCB; Tue, 15 Jan 2002 15:01:42 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id F200C5DDCA for ; Tue, 15 Jan 2002 15:01:41 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA05092; Tue, 15 Jan 2002 15:01:38 -0500 (EST) Date: Tue, 15 Jan 2002 15:01:38 -0500 (EST) From: Russ White Reply-To: Russ White To: Susan Hares Cc: Alex Zinin , Eric Gray , Inter-Domain Routing Mailing List Subject: Re: bgp4-17 Cease subcode In-Reply-To: <5.0.0.25.0.20020115144930.04a32a00@mail.nexthop.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk So, then it sounds like the way we should approach this (the idlehold state in the fsm) is to think about it seperately from the draft 17 issue (?). Russ On Tue, 15 Jan 2002, Susan Hares wrote: > > Alex: > > I know you have been active on the mailing list. > And you didn't read it before the last call on the FSM. > And this question was asked on the list because I > wondered about it. > > ;-)... --- I guess not even great people are > perfect. > > OK, now I've got 2 more against (4 total). And 15-20 votes > for it inside the draft. > > I'm sure your vote is a bit more specific. :-)... > > Is the issue you want to pull exponential out of the draft? > This is a change to the BGP specification. This draft > is about corrections not changes in functionality. > > What do we do? > > Sue Hares > > > > At 10:30 AM 1/15/2002 -0800, Alex Zinin wrote: > > >Russ, Eric, > > > > I tend to agree here... > > I'm currently reviewing the FSM and the impression I'm > > getting is that we can go without the IdleHold state > > and say that implementations may/should use some local mechanisms > > to hold BGP sessions in the *Idle* state to avoid excessive > > session flapping. I think this will be simpler and will > > match current implementations better... > > > >-- > >Alex Zinin > > > >Tuesday, January 15, 2002, 7:21:06 AM, Russ White wrote: > > > > > > > Something like: "BGP implementations can/should/must > > > (?) implement some method to prevent continuous flapping of > > > peering sessions at a high rate," and then a footbote explaining > > > that an exponential backoff is one such possible method? > > > > > Russ > > > > > On Tue, 15 Jan 2002, Eric Gray wrote: > > > > >> Russ, > > >> > > >> Very good point. However, how would you represent "do some > > >> private magic here" in an FSM? That may make it the dreaded ISM. > > >> Perhaps it might be sufficient to remove this from the FSM and > > >> add a footnote (possibly mentioning an exponential back-off as an > > >> example?). > > >> > > >> You wrote: > > >> > > >> > Well, I just took it as 'do people do this?' I agree that it > > >> > won't cause interop problems either way--it's actually something > > >> > that's implementation local, so I'm not certain why the > > >> > exponential backoff would be in the fsm (?). There are, in other > > >> > words, other ways I could imagine handling this problem that > > >> > wouldn't effect interoperability as well.... > > >> > > > >> > :-) > > >> > > > >> > Russ > > >> > > > >> > On Tue, 15 Jan 2002, Eric Gray wrote: > > >> > > > >> > > Russ, > > >> > > > > >> > > I don't think that NAKs are in order on this question - even > > from the > > >> > > 1500 pound dragon. :-) > > >> > > > > >> > > The fact that anyone's implementation doesn't do X is > > important only > > >> > > if not doing X causes interoperability problems with implementations > > >> > > that do X. That is not the case here, I believe... > > >> > > > > >> > > You wrote: > > >> > > > > >> > > > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote: > > >> > > > > > > Please remember that the goal of the draft is to document > > >> > > > > > > what is *currently* implemented and deployed, *not* what > > >> > > > > > > *could* be implemented and deployed. > > >> > > > > > > > >> > > > > > Is the expoential backoff in the FSM in current implementations? > > >> > > > > > > >> > > > > I guess we are going to find this out as part of the > > >> > > > > implementation report. And if it is not in (at least two) > > >> > > > > current implementations, we'll take it out of the text. > > >> > > > > > >> > > > Cisco doesn't do this.... > > >> > > > > > >> > > > :-) > > >> > > > > > >> > > > Russ > > >> > > > > > >> > > > _____________________________ > > >> > > > riw@cisco.com <>< Grace Alone > > >> > > > > >> > > -- > > >> > > Eric Gray (mailto:eric.gray@sandburst.com) > > >> > > http://www.mindspring.com/~ewgray > > >> > > > > >> > > > > >> > > > > >> > > > >> > _____________________________ > > >> > riw@cisco.com <>< Grace Alone > > >> > > >> -- > > >> Eric Gray (mailto:eric.gray@sandburst.com) > > >> http://www.mindspring.com/~ewgray > > >> > > >> > > >> > > > > > _____________________________ > > > riw@cisco.com <>< Grace Alone > > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA06992 for ; Tue, 15 Jan 2002 15:03:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DFA1E91263; Tue, 15 Jan 2002 15:00:56 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8D3191261; Tue, 15 Jan 2002 15:00:56 -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 593B49125F for ; Tue, 15 Jan 2002 15:00:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 383F05DDB0; Tue, 15 Jan 2002 15:00:53 -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 E43DF5DDA5 for ; Tue, 15 Jan 2002 15:00:52 -0500 (EST) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id 1D2EACAB6A; Tue, 15 Jan 2002 12:00:52 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv2.redback.com (Postfix) with ESMTP id 03951979C1; Tue, 15 Jan 2002 12:00:52 -0800 (PST) To: Susan Hares Cc: Russ White , Jeffrey Haas , idr@merit.edu, enke@redback.com Subject: Re: IDR WG Last Call In-Reply-To: Message from Susan Hares of "Tue, 15 Jan 2002 14:49:14 EST." <5.0.0.25.0.20020115144829.04a58df8@mail.nexthop.com> Date: Tue, 15 Jan 2002 12:00:51 -0800 From: Enke Chen Message-Id: <20020115200052.03951979C1@popserv2.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Sue, > Date: Tue, 15 Jan 2002 14:49:14 -0500 > To: Russ White > From: Susan Hares > Subject: Re: IDR WG Last Call > Cc: Enke Chen , Jeffrey Haas , > idr@merit.edu > In-Reply-To: .com> > References: <20020115174716.CC5A815D3C1@popserv1.redback.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii"; format=flowed > X-NextHop-MailScanner: Found to be clean > > Russ: > > We had that vote 1 month ago. The overwhelming > majority was to keep it in. We are not re-opening > that issue having closed it on the mail list already. The issue then was the "BGP State Machine". Russ was talking abut "SAFI 3" in his message if I am not mistaken. -- Enke > > > Sue > > At 01:03 PM 1/15/2002 -0500, Russ White wrote: > > >I think it's probably a good idea to get rid of this out of the > >spec--it would make things cleaner. > > > >Russ > > > >On Tue, 15 Jan 2002, Enke Chen wrote: > > > > > Jeff, > > > > > > > Date: Mon, 14 Jan 2002 23:21:28 -0500 > > > > From: Jeffrey Haas > > > > To: Enke Chen > > > > Cc: idr@merit.edu > > > > Subject: Re: IDR WG Last Call > > > > Message-ID: <20020114232128.B14701@nexthop.com> > > > > > > > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote: > > > > > It seems that the "SAFI 3" certainly makes the issue at hand much more > > > > > complicated. > > > > > > > > IMO, SAFI 3 was probably not a very good idea. Dealing with it can > > > > be a real pain in the implementation. :-) > > > > > > So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem to add > > > much value, but has caused a lot of confusion and complexity. I am not > > > aware of any depolyment either. > > > > > > > > > > > > As Yakov and Sue pointed out, it is a good idea to discourage > > > > > having one prefix in multiple fields of an update message. How > > about the > > > > > following text: > > > > > > > > > > An UPDATE message should not include the same address prefix in > > more than > > > > > one of the following fields: WITHDRAWN ROUTES field, Network > > Reachability > > > > > Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI > > field. The > > > > > processing of an UPDATE message in this form is un-defined. > > > > > > > > I think that "undefined" is overkill. I would suggest the following > > instead: > > > > > > > > An UPDATE message should not include the same address prefix in > > > > more than one of the following fields: WITHDRAWN ROUTES, Network > > > > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI. > > > > An implementation that receives a packet in this form should process > > > > the Update as if it had processed it in the following order: > > > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer > > > > Reachability Information. > > > > > > > > The wording could probably use some tightening. > > > > > > > > The intended result is that reachability rules over unreachability. > > > > > > If we want to define the behavior, I would like to suggest sticking to > > > the order in the message. That probably would reflect the sender's > > > intention more closely, and make the processing simpler. > > > > > > -- Enke > > > > > > > > > >_____________________________ > >riw@cisco.com <>< Grace Alone > > Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA06817 for ; Tue, 15 Jan 2002 14:59:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 693F191262; Tue, 15 Jan 2002 14:57:11 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40A909125E; Tue, 15 Jan 2002 14:57: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 28FBE9125F for ; Tue, 15 Jan 2002 14:57:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id D04525DDC9; Tue, 15 Jan 2002 14:57:05 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 4A2905DDD9 for ; Tue, 15 Jan 2002 14:57:04 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0FJu7395869; Tue, 15 Jan 2002 14:56:07 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020115144930.04a32a00@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 15 Jan 2002 14:56:05 -0500 To: Alex Zinin From: Susan Hares Subject: Re: bgp4-17 Cease subcode Cc: Russ White , Eric Gray , Russ White , Inter-Domain Routing Mailing List In-Reply-To: <12296411812.20020115103053@nexsi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Alex: I know you have been active on the mailing list. And you didn't read it before the last call on the FSM. And this question was asked on the list because I wondered about it. ;-)... --- I guess not even great people are perfect. OK, now I've got 2 more against (4 total). And 15-20 votes for it inside the draft. I'm sure your vote is a bit more specific. :-)... Is the issue you want to pull exponential out of the draft? This is a change to the BGP specification. This draft is about corrections not changes in functionality. What do we do? Sue Hares At 10:30 AM 1/15/2002 -0800, Alex Zinin wrote: >Russ, Eric, > > I tend to agree here... > I'm currently reviewing the FSM and the impression I'm > getting is that we can go without the IdleHold state > and say that implementations may/should use some local mechanisms > to hold BGP sessions in the *Idle* state to avoid excessive > session flapping. I think this will be simpler and will > match current implementations better... > >-- >Alex Zinin > >Tuesday, January 15, 2002, 7:21:06 AM, Russ White wrote: > > > > Something like: "BGP implementations can/should/must > > (?) implement some method to prevent continuous flapping of > > peering sessions at a high rate," and then a footbote explaining > > that an exponential backoff is one such possible method? > > > Russ > > > On Tue, 15 Jan 2002, Eric Gray wrote: > > >> Russ, > >> > >> Very good point. However, how would you represent "do some > >> private magic here" in an FSM? That may make it the dreaded ISM. > >> Perhaps it might be sufficient to remove this from the FSM and > >> add a footnote (possibly mentioning an exponential back-off as an > >> example?). > >> > >> You wrote: > >> > >> > Well, I just took it as 'do people do this?' I agree that it > >> > won't cause interop problems either way--it's actually something > >> > that's implementation local, so I'm not certain why the > >> > exponential backoff would be in the fsm (?). There are, in other > >> > words, other ways I could imagine handling this problem that > >> > wouldn't effect interoperability as well.... > >> > > >> > :-) > >> > > >> > Russ > >> > > >> > On Tue, 15 Jan 2002, Eric Gray wrote: > >> > > >> > > Russ, > >> > > > >> > > I don't think that NAKs are in order on this question - even > from the > >> > > 1500 pound dragon. :-) > >> > > > >> > > The fact that anyone's implementation doesn't do X is > important only > >> > > if not doing X causes interoperability problems with implementations > >> > > that do X. That is not the case here, I believe... > >> > > > >> > > You wrote: > >> > > > >> > > > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote: > >> > > > > > > Please remember that the goal of the draft is to document > >> > > > > > > what is *currently* implemented and deployed, *not* what > >> > > > > > > *could* be implemented and deployed. > >> > > > > > > >> > > > > > Is the expoential backoff in the FSM in current implementations? > >> > > > > > >> > > > > I guess we are going to find this out as part of the > >> > > > > implementation report. And if it is not in (at least two) > >> > > > > current implementations, we'll take it out of the text. > >> > > > > >> > > > Cisco doesn't do this.... > >> > > > > >> > > > :-) > >> > > > > >> > > > Russ > >> > > > > >> > > > _____________________________ > >> > > > riw@cisco.com <>< Grace Alone > >> > > > >> > > -- > >> > > Eric Gray (mailto:eric.gray@sandburst.com) > >> > > http://www.mindspring.com/~ewgray > >> > > > >> > > > >> > > > >> > > >> > _____________________________ > >> > riw@cisco.com <>< Grace Alone > >> > >> -- > >> Eric Gray (mailto:eric.gray@sandburst.com) > >> http://www.mindspring.com/~ewgray > >> > >> > >> > > > _____________________________ > > riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA06601 for ; Tue, 15 Jan 2002 14:50:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 838489125C; Tue, 15 Jan 2002 14:50:00 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30CFD9125D; Tue, 15 Jan 2002 14:50:00 -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 1261B9125C for ; Tue, 15 Jan 2002 14:49:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA61E5DDCB; Tue, 15 Jan 2002 14:49:58 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 928565DDC9 for ; Tue, 15 Jan 2002 14:49:58 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0FJnG395478; Tue, 15 Jan 2002 14:49:16 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020115144829.04a58df8@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 15 Jan 2002 14:49:14 -0500 To: Russ White From: Susan Hares Subject: Re: IDR WG Last Call Cc: Enke Chen , Jeffrey Haas , idr@merit.edu In-Reply-To: References: <20020115174716.CC5A815D3C1@popserv1.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Russ: We had that vote 1 month ago. The overwhelming majority was to keep it in. We are not re-opening that issue having closed it on the mail list already. Sue At 01:03 PM 1/15/2002 -0500, Russ White wrote: >I think it's probably a good idea to get rid of this out of the >spec--it would make things cleaner. > >Russ > >On Tue, 15 Jan 2002, Enke Chen wrote: > > > Jeff, > > > > > Date: Mon, 14 Jan 2002 23:21:28 -0500 > > > From: Jeffrey Haas > > > To: Enke Chen > > > Cc: idr@merit.edu > > > Subject: Re: IDR WG Last Call > > > Message-ID: <20020114232128.B14701@nexthop.com> > > > > > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote: > > > > It seems that the "SAFI 3" certainly makes the issue at hand much more > > > > complicated. > > > > > > IMO, SAFI 3 was probably not a very good idea. Dealing with it can > > > be a real pain in the implementation. :-) > > > > So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem to add > > much value, but has caused a lot of confusion and complexity. I am not > > aware of any depolyment either. > > > > > > > > > As Yakov and Sue pointed out, it is a good idea to discourage > > > > having one prefix in multiple fields of an update message. How > about the > > > > following text: > > > > > > > > An UPDATE message should not include the same address prefix in > more than > > > > one of the following fields: WITHDRAWN ROUTES field, Network > Reachability > > > > Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI > field. The > > > > processing of an UPDATE message in this form is un-defined. > > > > > > I think that "undefined" is overkill. I would suggest the following > instead: > > > > > > An UPDATE message should not include the same address prefix in > > > more than one of the following fields: WITHDRAWN ROUTES, Network > > > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI. > > > An implementation that receives a packet in this form should process > > > the Update as if it had processed it in the following order: > > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer > > > Reachability Information. > > > > > > The wording could probably use some tightening. > > > > > > The intended result is that reachability rules over unreachability. > > > > If we want to define the behavior, I would like to suggest sticking to > > the order in the message. That probably would reflect the sender's > > intention more closely, and make the processing simpler. > > > > -- Enke > > > > > >_____________________________ >riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA05360 for ; Tue, 15 Jan 2002 14:13:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B5B9A91259; Tue, 15 Jan 2002 14:13:31 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 878F99125A; Tue, 15 Jan 2002 14:13: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 6514191259 for ; Tue, 15 Jan 2002 14:13:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 494F45DDBF; Tue, 15 Jan 2002 14:13:30 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id F11FD5DDB0 for ; Tue, 15 Jan 2002 14:13:29 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0FJD7394004; Tue, 15 Jan 2002 14:13:07 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020115140915.04a4d188@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 15 Jan 2002 14:13:05 -0500 To: Enke Chen From: Susan Hares Subject: Re: IDR WG Last Call Cc: Jeffrey Haas , idr@merit.edu, enke@redback.com In-Reply-To: <20020115174716.CC5A815D3C1@popserv1.redback.com> References: <20020114232128.B14701@nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Enke: We are back to my original point. I would suggest a SAFI 2 + SAFI 1 being bit patterns in the specification. We could then deal with the (AFI, SAFI) pair. I would suggest (per the example) that the order of process is UNREACH and then REACH. Please see my example for the example of this problem. Sue At 09:47 AM 1/15/2002 -0800, Enke Chen wrote: >Jeff, > > > Date: Mon, 14 Jan 2002 23:21:28 -0500 > > From: Jeffrey Haas > > To: Enke Chen > > Cc: idr@merit.edu > > Subject: Re: IDR WG Last Call > > Message-ID: <20020114232128.B14701@nexthop.com> > > > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote: > > > It seems that the "SAFI 3" certainly makes the issue at hand much more > > > complicated. > > > > IMO, SAFI 3 was probably not a very good idea. Dealing with it can > > be a real pain in the implementation. :-) > >So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem to add >much value, but has caused a lot of confusion and complexity. I am not >aware of any depolyment either. > > > > > > As Yakov and Sue pointed out, it is a good idea to discourage > > > having one prefix in multiple fields of an update message. How about the > > > following text: > > > > > > An UPDATE message should not include the same address prefix in > more than > > > one of the following fields: WITHDRAWN ROUTES field, Network > Reachability > > > Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI > field. The > > > processing of an UPDATE message in this form is un-defined. > > > > I think that "undefined" is overkill. I would suggest the following > instead: > > > > An UPDATE message should not include the same address prefix in > > more than one of the following fields: WITHDRAWN ROUTES, Network > > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI. > > An implementation that receives a packet in this form should process > > the Update as if it had processed it in the following order: > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer > > Reachability Information. > > > > The wording could probably use some tightening. > > > > The intended result is that reachability rules over unreachability. > >If we want to define the behavior, I would like to suggest sticking to >the order in the message. That probably would reflect the sender's >intention more closely, and make the processing simpler. > >-- Enke 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 NAA03758 for ; Tue, 15 Jan 2002 13:34:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1327491257; Tue, 15 Jan 2002 13:33:41 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83EEF91259; Tue, 15 Jan 2002 13:33: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 27A1E91257 for ; Tue, 15 Jan 2002 13:33:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0A87F5DDB0; Tue, 15 Jan 2002 13:33:37 -0500 (EST) Delivered-To: idr@merit.edu Received: from monsoon.mail.pipex.net (monsoon.mail.pipex.net [158.43.128.69]) by segue.merit.edu (Postfix) with SMTP id 490B75DDAC for ; Tue, 15 Jan 2002 13:33:36 -0500 (EST) Received: (qmail 567 invoked from network); 15 Jan 2002 18:33:30 -0000 Received: from userbf52.uk.uudial.com (HELO tom3) (62.188.142.73) by smtp-1.dial.pipex.com with SMTP; 15 Jan 2002 18:33:30 -0000 Message-ID: <004b01c2bcc4$84018820$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Yakov Rekhter" Cc: Subject: Re: bgp4-17 Section 9 Date: Wed, 15 Jan 2003 18:28:48 -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 Combining NEXT_HOP resolution into one place (5.1.3) I suggest Revised 9.1.2 para 7 The local speaker MUST determine the immediate next-hop address from the NEXT_HOP attribute of the selected route (see section 5.1.3). If either the immediate next hop or the IGP cost to the NEXT_HOP (where the NEXT_HOP is resolved through an IGP route) changes, Phase 2: Route Selection should be performed again. ---------------------------- Revised 5.1.3 The NEXT_HOP attribute is used by the BGP speaker to determine the actual outbound interface and immediate next-hop address that should be used to forward transit packets to the associated destinations. The immediate next-hop address is determined by performing a recursive route lookup operation for the IP address in the NEXT_HOP attribute using the contents of the Routing Table, -----------revised text follows ------------ selecting one entry if multiple entries of equal cost exist. The Routing Table entry which resolves the NEXT_HOP attribute will always specify the outbound interface. If the entry also specifies the next-hop address, this address should be used as the immediate next-hop address for packet forwarding. If the entry specifies an attached subnet (and does not specify a next-hop address), then the address in the NEXT_HOP attribute should be used as the immediate next-hop address. ------------end of revision---------- I (still) believe 'resolving route' is not at all clear, hence my use of the form 'The Routing Table entry which resolves the NEXT_HOP attribute ...' But I am less hung up on whether we mention entry or use path or drop 'Routing Table'. I take the point about there being a limit as to how much we can say about routing tables; I tend to regard RFC1812 as the sine qua none. Tom Petch, Network Consultant nwnetworks@dial.pipex.com -----Original Message----- From: Yakov Rekhter To: Tom Petch Cc: idr@merit.edu Date: 14 January 2002 20:15 Subject: Re: bgp4-17 Section 9 >> >> 9.1.2 Route selection now allows for the best route in >> Loc-RIB not to be placed in the Routing table; how does this >> impact on the principle (2 Introduction) that a BGP Speaker >> should only advertise routes it itself uses? Is it enough >> for the route to be in Loc-RIB and not in the Routing Table? >> >> I believe the paragraph on immediate next hop should >> cross-reference the one in 5.1.3; and the latter allows >> route lookup to resolve to a subnet and not an immediate >> next hop address, a possibility 9.1.2 appears not to cater >> for. >> >> Perhaps the information on immediate next hop in 5.1.3 and 9 >> should be combined in one place; 5.1.3 would be my >> preference. > >Please propose the specific changes. > >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 NAA03752 for ; Tue, 15 Jan 2002 13:34:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 57CD991256; Tue, 15 Jan 2002 13:33:38 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F8B991258; Tue, 15 Jan 2002 13:33: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 54D4E91256 for ; Tue, 15 Jan 2002 13:33:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2CBBC5DDB0; Tue, 15 Jan 2002 13:33:36 -0500 (EST) Delivered-To: idr@merit.edu Received: from monsoon.mail.pipex.net (monsoon.mail.pipex.net [158.43.128.69]) by segue.merit.edu (Postfix) with SMTP id 6AE905DDAC for ; Tue, 15 Jan 2002 13:33:35 -0500 (EST) Received: (qmail 577 invoked from network); 15 Jan 2002 18:33:33 -0000 Received: from userbf52.uk.uudial.com (HELO tom3) (62.188.142.73) by smtp-1.dial.pipex.com with SMTP; 15 Jan 2002 18:33:33 -0000 Message-ID: <004c01c2bcc4$85620280$0301a8c0@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Alex Zinin" Cc: Subject: Re: bgp4-17 5.1.3 immediate next hop Date: Wed, 15 Jan 2003 18:31:52 -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 Well yes, I did understand it (I think). I still query the use of the term 'resolving route'. (I just don't see the term used in this, IP forwarding, context and there is a disjunction between this and the previous sentence, which uses the more familiar - to me - terms such as recursive route lookup). I find it much clearer when you say, as in your e-mail, 'the route resolving the NEXT_HOP' or going a bit further 'the routing table entry which resolves the NEXT_HOP attribute. I see no harm and positive benefit is spelling it out. Tom Petch, Network Consultant nwnetworks@dial.pipex.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 NAA03704 for ; Tue, 15 Jan 2002 13:32:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CE80691242; Tue, 15 Jan 2002 13:31:52 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9636D91256; Tue, 15 Jan 2002 13:31: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 6B9CC91242 for ; Tue, 15 Jan 2002 13:31:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 465CB5DDB0; Tue, 15 Jan 2002 13:31:51 -0500 (EST) Delivered-To: idr@merit.edu Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id 149DA5DDAC for ; Tue, 15 Jan 2002 13:31:51 -0500 (EST) Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id 6959B3F65; Tue, 15 Jan 2002 10:34:32 -0800 (PST) Received: from khonsu.sw.nexsi.com (cscovpn5.nexsi.com [172.16.213.5]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id KAA12177; Tue, 15 Jan 2002 10:30:55 -0800 Date: Tue, 15 Jan 2002 10:30:53 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <12296411812.20020115103053@nexsi.com> To: Russ White Cc: Eric Gray , Russ White , Inter-Domain Routing Mailing List Subject: Re: bgp4-17 Cease subcode In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Russ, Eric, I tend to agree here... I'm currently reviewing the FSM and the impression I'm getting is that we can go without the IdleHold state and say that implementations may/should use some local mechanisms to hold BGP sessions in the *Idle* state to avoid excessive session flapping. I think this will be simpler and will match current implementations better... -- Alex Zinin Tuesday, January 15, 2002, 7:21:06 AM, Russ White wrote: > Something like: "BGP implementations can/should/must > (?) implement some method to prevent continuous flapping of > peering sessions at a high rate," and then a footbote explaining > that an exponential backoff is one such possible method? > Russ > On Tue, 15 Jan 2002, Eric Gray wrote: >> Russ, >> >> Very good point. However, how would you represent "do some >> private magic here" in an FSM? That may make it the dreaded ISM. >> Perhaps it might be sufficient to remove this from the FSM and >> add a footnote (possibly mentioning an exponential back-off as an >> example?). >> >> You wrote: >> >> > Well, I just took it as 'do people do this?' I agree that it >> > won't cause interop problems either way--it's actually something >> > that's implementation local, so I'm not certain why the >> > exponential backoff would be in the fsm (?). There are, in other >> > words, other ways I could imagine handling this problem that >> > wouldn't effect interoperability as well.... >> > >> > :-) >> > >> > Russ >> > >> > On Tue, 15 Jan 2002, Eric Gray wrote: >> > >> > > Russ, >> > > >> > > I don't think that NAKs are in order on this question - even from the >> > > 1500 pound dragon. :-) >> > > >> > > The fact that anyone's implementation doesn't do X is important only >> > > if not doing X causes interoperability problems with implementations >> > > that do X. That is not the case here, I believe... >> > > >> > > You wrote: >> > > >> > > > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote: >> > > > > > > Please remember that the goal of the draft is to document >> > > > > > > what is *currently* implemented and deployed, *not* what >> > > > > > > *could* be implemented and deployed. >> > > > > > >> > > > > > Is the expoential backoff in the FSM in current implementations? >> > > > > >> > > > > I guess we are going to find this out as part of the >> > > > > implementation report. And if it is not in (at least two) >> > > > > current implementations, we'll take it out of the text. >> > > > >> > > > Cisco doesn't do this.... >> > > > >> > > > :-) >> > > > >> > > > Russ >> > > > >> > > > _____________________________ >> > > > riw@cisco.com <>< Grace Alone >> > > >> > > -- >> > > Eric Gray (mailto:eric.gray@sandburst.com) >> > > http://www.mindspring.com/~ewgray >> > > >> > > >> > > >> > >> > _____________________________ >> > riw@cisco.com <>< Grace Alone >> >> -- >> Eric Gray (mailto:eric.gray@sandburst.com) >> http://www.mindspring.com/~ewgray >> >> >> > _____________________________ > riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA02626 for ; Tue, 15 Jan 2002 13:04:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 682CE9123E; Tue, 15 Jan 2002 13:03:54 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C49D91241; Tue, 15 Jan 2002 13:03: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 C08E19123E for ; Tue, 15 Jan 2002 13:03:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B0B25DDAC; Tue, 15 Jan 2002 13:03:52 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 5E9C55DDA0 for ; Tue, 15 Jan 2002 13:03:52 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA19941; Tue, 15 Jan 2002 13:03:47 -0500 (EST) Date: Tue, 15 Jan 2002 13:03:47 -0500 (EST) From: Russ White Reply-To: Russ White To: Enke Chen Cc: Jeffrey Haas , idr@merit.edu Subject: Re: IDR WG Last Call In-Reply-To: <20020115174716.CC5A815D3C1@popserv1.redback.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk I think it's probably a good idea to get rid of this out of the spec--it would make things cleaner. Russ On Tue, 15 Jan 2002, Enke Chen wrote: > Jeff, > > > Date: Mon, 14 Jan 2002 23:21:28 -0500 > > From: Jeffrey Haas > > To: Enke Chen > > Cc: idr@merit.edu > > Subject: Re: IDR WG Last Call > > Message-ID: <20020114232128.B14701@nexthop.com> > > > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote: > > > It seems that the "SAFI 3" certainly makes the issue at hand much more > > > complicated. > > > > IMO, SAFI 3 was probably not a very good idea. Dealing with it can > > be a real pain in the implementation. :-) > > So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem to add > much value, but has caused a lot of confusion and complexity. I am not > aware of any depolyment either. > > > > > > As Yakov and Sue pointed out, it is a good idea to discourage > > > having one prefix in multiple fields of an update message. How about the > > > following text: > > > > > > An UPDATE message should not include the same address prefix in more than > > > one of the following fields: WITHDRAWN ROUTES field, Network Reachability > > > Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The > > > processing of an UPDATE message in this form is un-defined. > > > > I think that "undefined" is overkill. I would suggest the following instead: > > > > An UPDATE message should not include the same address prefix in > > more than one of the following fields: WITHDRAWN ROUTES, Network > > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI. > > An implementation that receives a packet in this form should process > > the Update as if it had processed it in the following order: > > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer > > Reachability Information. > > > > The wording could probably use some tightening. > > > > The intended result is that reachability rules over unreachability. > > If we want to define the behavior, I would like to suggest sticking to > the order in the message. That probably would reflect the sender's > intention more closely, and make the processing simpler. > > -- Enke > > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA02015 for ; Tue, 15 Jan 2002 12:47:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 73D6E91224; Tue, 15 Jan 2002 12:47:23 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DE4291239; Tue, 15 Jan 2002 12:47: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 4921991224 for ; Tue, 15 Jan 2002 12:47:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 13C2C5DDAE; Tue, 15 Jan 2002 12:47:18 -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 D1B395DDAC for ; Tue, 15 Jan 2002 12:47:17 -0500 (EST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id 2810DF2C5C; Tue, 15 Jan 2002 09:47:17 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id CC5A815D3C1; Tue, 15 Jan 2002 09:47:16 -0800 (PST) To: Jeffrey Haas Cc: idr@merit.edu, enke@redback.com Subject: Re: IDR WG Last Call In-Reply-To: Message from Jeffrey Haas of "Mon, 14 Jan 2002 23:21:28 EST." <20020114232128.B14701@nexthop.com> Date: Tue, 15 Jan 2002 09:47:16 -0800 From: Enke Chen Message-Id: <20020115174716.CC5A815D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Jeff, > Date: Mon, 14 Jan 2002 23:21:28 -0500 > From: Jeffrey Haas > To: Enke Chen > Cc: idr@merit.edu > Subject: Re: IDR WG Last Call > Message-ID: <20020114232128.B14701@nexthop.com> > > On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote: > > It seems that the "SAFI 3" certainly makes the issue at hand much more > > complicated. > > IMO, SAFI 3 was probably not a very good idea. Dealing with it can > be a real pain in the implementation. :-) So can we clean out "SAFI 3" from MP-BGP spec.? It does not seem to add much value, but has caused a lot of confusion and complexity. I am not aware of any depolyment either. > > > As Yakov and Sue pointed out, it is a good idea to discourage > > having one prefix in multiple fields of an update message. How about the > > following text: > > > > An UPDATE message should not include the same address prefix in more than > > one of the following fields: WITHDRAWN ROUTES field, Network Reachability > > Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The > > processing of an UPDATE message in this form is un-defined. > > I think that "undefined" is overkill. I would suggest the following instead: > > An UPDATE message should not include the same address prefix in > more than one of the following fields: WITHDRAWN ROUTES, Network > Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI. > An implementation that receives a packet in this form should process > the Update as if it had processed it in the following order: > WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer > Reachability Information. > > The wording could probably use some tightening. > > The intended result is that reachability rules over unreachability. If we want to define the behavior, I would like to suggest sticking to the order in the message. That probably would reflect the sender's intention more closely, and make the processing simpler. -- Enke 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 KAA25212 for ; Tue, 15 Jan 2002 10:21:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D29DA91254; Tue, 15 Jan 2002 10:21:10 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E6A891256; Tue, 15 Jan 2002 10:21: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 C786591254 for ; Tue, 15 Jan 2002 10:21:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 958835DDC0; Tue, 15 Jan 2002 10:21:08 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 1F3F45DDDA for ; Tue, 15 Jan 2002 10:21:08 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA00713; Tue, 15 Jan 2002 10:21:06 -0500 (EST) Date: Tue, 15 Jan 2002 10:21:06 -0500 (EST) From: Russ White Reply-To: Russ White To: Eric Gray Cc: Inter-Domain Routing Mailing List Subject: Re: bgp4-17 Cease subcode In-Reply-To: <3C44476C.E0FFA783@sandburst.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Something like: "BGP implementations can/should/must (?) implement some method to prevent continuous flapping of peering sessions at a high rate," and then a footbote explaining that an exponential backoff is one such possible method? Russ On Tue, 15 Jan 2002, Eric Gray wrote: > Russ, > > Very good point. However, how would you represent "do some > private magic here" in an FSM? That may make it the dreaded ISM. > Perhaps it might be sufficient to remove this from the FSM and > add a footnote (possibly mentioning an exponential back-off as an > example?). > > You wrote: > > > Well, I just took it as 'do people do this?' I agree that it > > won't cause interop problems either way--it's actually something > > that's implementation local, so I'm not certain why the > > exponential backoff would be in the fsm (?). There are, in other > > words, other ways I could imagine handling this problem that > > wouldn't effect interoperability as well.... > > > > :-) > > > > Russ > > > > On Tue, 15 Jan 2002, Eric Gray wrote: > > > > > Russ, > > > > > > I don't think that NAKs are in order on this question - even from the > > > 1500 pound dragon. :-) > > > > > > The fact that anyone's implementation doesn't do X is important only > > > if not doing X causes interoperability problems with implementations > > > that do X. That is not the case here, I believe... > > > > > > You wrote: > > > > > > > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote: > > > > > > > Please remember that the goal of the draft is to document > > > > > > > what is *currently* implemented and deployed, *not* what > > > > > > > *could* be implemented and deployed. > > > > > > > > > > > > Is the expoential backoff in the FSM in current implementations? > > > > > > > > > > I guess we are going to find this out as part of the > > > > > implementation report. And if it is not in (at least two) > > > > > current implementations, we'll take it out of the text. > > > > > > > > Cisco doesn't do this.... > > > > > > > > :-) > > > > > > > > Russ > > > > > > > > _____________________________ > > > > riw@cisco.com <>< Grace Alone > > > > > > -- > > > Eric Gray (mailto:eric.gray@sandburst.com) > > > http://www.mindspring.com/~ewgray > > > > > > > > > > > > > _____________________________ > > riw@cisco.com <>< Grace Alone > > -- > Eric Gray (mailto:eric.gray@sandburst.com) > http://www.mindspring.com/~ewgray > > > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA25076 for ; Tue, 15 Jan 2002 10:17:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3E5D591255; Tue, 15 Jan 2002 10:14:58 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D9E2C9125C; Tue, 15 Jan 2002 10:14:57 -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 325D791255 for ; Tue, 15 Jan 2002 10:14:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0EF5E5DDA0; Tue, 15 Jan 2002 10:14:54 -0500 (EST) Delivered-To: idr@merit.edu Received: from sandmail.sandburst.com (sandmail.sandburst.com [216.57.132.42]) by segue.merit.edu (Postfix) with ESMTP id BFB415DD96 for ; Tue, 15 Jan 2002 10:14:53 -0500 (EST) Message-ID: <3C44476C.E0FFA783@sandburst.com> Date: Tue, 15 Jan 2002 10:14:52 -0500 From: Eric Gray MIME-Version: 1.0 To: Russ White Cc: Inter-Domain Routing Mailing List Subject: Re: bgp4-17 Cease subcode References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Russ, Very good point. However, how would you represent "do some private magic here" in an FSM? That may make it the dreaded ISM. Perhaps it might be sufficient to remove this from the FSM and add a footnote (possibly mentioning an exponential back-off as an example?). You wrote: > Well, I just took it as 'do people do this?' I agree that it > won't cause interop problems either way--it's actually something > that's implementation local, so I'm not certain why the > exponential backoff would be in the fsm (?). There are, in other > words, other ways I could imagine handling this problem that > wouldn't effect interoperability as well.... > > :-) > > Russ > > On Tue, 15 Jan 2002, Eric Gray wrote: > > > Russ, > > > > I don't think that NAKs are in order on this question - even from the > > 1500 pound dragon. :-) > > > > The fact that anyone's implementation doesn't do X is important only > > if not doing X causes interoperability problems with implementations > > that do X. That is not the case here, I believe... > > > > You wrote: > > > > > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote: > > > > > > Please remember that the goal of the draft is to document > > > > > > what is *currently* implemented and deployed, *not* what > > > > > > *could* be implemented and deployed. > > > > > > > > > > Is the expoential backoff in the FSM in current implementations? > > > > > > > > I guess we are going to find this out as part of the > > > > implementation report. And if it is not in (at least two) > > > > current implementations, we'll take it out of the text. > > > > > > Cisco doesn't do this.... > > > > > > :-) > > > > > > Russ > > > > > > _____________________________ > > > riw@cisco.com <>< Grace Alone > > > > -- > > Eric Gray (mailto:eric.gray@sandburst.com) > > http://www.mindspring.com/~ewgray > > > > > > > > _____________________________ > riw@cisco.com <>< Grace Alone -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray 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 KAA24551 for ; Tue, 15 Jan 2002 10:08:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6464A91251; Tue, 15 Jan 2002 10:07:44 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3448591252; Tue, 15 Jan 2002 10:07: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 AC89891251 for ; Tue, 15 Jan 2002 10:07:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B1BB5DD9F; Tue, 15 Jan 2002 10:07:42 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 1E7195DD96 for ; Tue, 15 Jan 2002 10:07:42 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA29035; Tue, 15 Jan 2002 10:07:35 -0500 (EST) Date: Tue, 15 Jan 2002 10:07:34 -0500 (EST) From: Russ White Reply-To: Russ White To: Eric Gray Cc: Inter-Domain Routing Mailing List Subject: Re: bgp4-17 Cease subcode In-Reply-To: <3C4443F0.8DDC190C@sandburst.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Well, I just took it as 'do people do this?' I agree that it won't cause interop problems either way--it's actually something that's implementation local, so I'm not certain why the exponential backoff would be in the fsm (?). There are, in other words, other ways I could imagine handling this problem that wouldn't effect interoperability as well.... :-) Russ On Tue, 15 Jan 2002, Eric Gray wrote: > Russ, > > I don't think that NAKs are in order on this question - even from the > 1500 pound dragon. :-) > > The fact that anyone's implementation doesn't do X is important only > if not doing X causes interoperability problems with implementations > that do X. That is not the case here, I believe... > > You wrote: > > > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote: > > > > > Please remember that the goal of the draft is to document > > > > > what is *currently* implemented and deployed, *not* what > > > > > *could* be implemented and deployed. > > > > > > > > Is the expoential backoff in the FSM in current implementations? > > > > > > I guess we are going to find this out as part of the > > > implementation report. And if it is not in (at least two) > > > current implementations, we'll take it out of the text. > > > > Cisco doesn't do this.... > > > > :-) > > > > Russ > > > > _____________________________ > > riw@cisco.com <>< Grace Alone > > -- > Eric Gray (mailto:eric.gray@sandburst.com) > http://www.mindspring.com/~ewgray > > > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA24316 for ; Tue, 15 Jan 2002 10:00:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DAD8B91250; Tue, 15 Jan 2002 10:00:05 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 666C091251; Tue, 15 Jan 2002 10:00:05 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4AB8B91250 for ; Tue, 15 Jan 2002 10:00:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id A58215DD9F; Tue, 15 Jan 2002 10:00:02 -0500 (EST) Delivered-To: idr@merit.edu Received: from sandmail.sandburst.com (sandmail.sandburst.com [216.57.132.42]) by segue.merit.edu (Postfix) with ESMTP id B95EE5DD96 for ; Tue, 15 Jan 2002 10:00:01 -0500 (EST) Message-ID: <3C4443F0.8DDC190C@sandburst.com> Date: Tue, 15 Jan 2002 10:00:00 -0500 From: Eric Gray MIME-Version: 1.0 To: Russ White , Inter-Domain Routing Mailing List Subject: Re: bgp4-17 Cease subcode References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Russ, I don't think that NAKs are in order on this question - even from the 1500 pound dragon. :-) The fact that anyone's implementation doesn't do X is important only if not doing X causes interoperability problems with implementations that do X. That is not the case here, I believe... You wrote: > > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote: > > > > Please remember that the goal of the draft is to document > > > > what is *currently* implemented and deployed, *not* what > > > > *could* be implemented and deployed. > > > > > > Is the expoential backoff in the FSM in current implementations? > > > > I guess we are going to find this out as part of the > > implementation report. And if it is not in (at least two) > > current implementations, we'll take it out of the text. > > Cisco doesn't do this.... > > :-) > > Russ > > _____________________________ > riw@cisco.com <>< Grace Alone -- Eric Gray (mailto:eric.gray@sandburst.com) http://www.mindspring.com/~ewgray 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 JAA23560 for ; Tue, 15 Jan 2002 09:33:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CF4079124F; Tue, 15 Jan 2002 09:32:59 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9906191250; Tue, 15 Jan 2002 09:32: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 51F159124F for ; Tue, 15 Jan 2002 09:32:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F04F5DDA0; Tue, 15 Jan 2002 09:32:58 -0500 (EST) Delivered-To: idr@merit.edu Received: from cmail.packetcom.com (unknown [63.108.173.139]) by segue.merit.edu (Postfix) with ESMTP id D09005DD9F for ; Tue, 15 Jan 2002 09:32:57 -0500 (EST) Received: from caspiannetworks.com ([63.109.132.2]) by cmail.packetcom.com (Mirapoint) with ESMTP id ABQ38569 (AUTH jeffp@caspiannetworks.com); Tue, 15 Jan 2002 06:32:49 -0800 (PST) Message-ID: <3C4459E1.376D0F25@caspiannetworks.com> Date: Tue, 15 Jan 2002 08:33:38 -0800 From: Jeff Pickering X-Mailer: Mozilla 4.77 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Susan Hares Cc: Jeffrey Haas , Yakov Rekhter , idr@merit.edu Subject: Re: bgp4-17 Cease subcode References: <200201141728.g0EHSr633936@merlot.juniper.net> <005001c2b9ba$3094a9e0$9989bc3e@tom3> <200201141728.g0EHSr633936@merlot.juniper.net> <5.0.0.25.0.20020114151919.0329db98@mail.nexthop.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Sue, We have implemented the exponential backoff with a locally configured cap. Jeff Susan Hares wrote: > Jeff: > > The backoff was in the original FSM. Your question > still stands, is it in the implementations. > > Sue > > At 12:37 PM 1/14/2002 -0500, Jeffrey Haas wrote: > >On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote: > > > Please remember that the goal of the draft is to document > > > what is *currently* implemented and deployed, *not* what > > > *could* be implemented and deployed. > > > >Is the expoential backoff in the FSM in current implementations? > > > >Note that this change (IdleHold) to the FSM is going to result in > >an alteration to the MIB. This is one of the reasons I've held > >off completion of the RFC 1657 update - to accomodate for this fact > >to converge. > > > > > Therefore, the draft > > > should not list these new subcodes. > > > > > > Yakov. > > > >-- > >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 JAA22955 for ; Tue, 15 Jan 2002 09:08:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CCA929124D; Tue, 15 Jan 2002 09:07:46 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E6E09124E; Tue, 15 Jan 2002 09:07: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 5374A9124D for ; Tue, 15 Jan 2002 09:07:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 210C45DDA0; Tue, 15 Jan 2002 09:07:45 -0500 (EST) Delivered-To: idr@merit.edu Received: from utopia.opentransit.net (utopia.opentransit.net [193.251.151.78]) by segue.merit.edu (Postfix) with ESMTP id 7248C5DD9F for ; Tue, 15 Jan 2002 09:07:44 -0500 (EST) Received: from utopia.opentransit.net (localhost [127.0.0.1]) by utopia.opentransit.net (8.12.1/8.12.1/Debian -5) with ESMTP id g0FE7B77024230; Tue, 15 Jan 2002 15:07:11 +0100 Received: (from vgi@localhost) by utopia.opentransit.net (8.12.1/8.12.1/Debian -5) id g0FE7BAv024229; Tue, 15 Jan 2002 15:07:11 +0100 Date: Tue, 15 Jan 2002 15:07:11 +0100 From: Vincent Gillet To: Yakov Rekhter Cc: Jeffrey Haas , idr@merit.edu Subject: Re: bgp4-17 Cease subcode Message-ID: <20020115140711.GA23937@opentransit.net> References: <20020114123700.C7761@nexthop.com> <200201141750.g0EHo3634958@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200201141750.g0EHo3634958@merlot.juniper.net> User-Agent: Mutt/1.3.24i Sender: owner-idr@merit.edu Precedence: bulk Yakov, > > Is the expoential backoff in the FSM in current implementations? > > I guess we are going to find this out as part of the implementation > report. And if it is not in (at least two) current implementations, > we'll take it out of the text. I implemented Cease subcode in zebra-0.92a but not exponential backoff. I checked that new subcode does not put other BGP stack in trouble (checked Cisco and Juniper). I have to clean-up patch and wait for another implementation to test interoperability. I am in touch with one vendor. > > Note that this change (IdleHold) to the FSM is going to result in > > an alteration to the MIB. This is one of the reasons I've held > > off completion of the RFC 1657 update - to accomodate for this fact > > to converge. > > Understood. Sub-code implementation does not depend on backoff. Draft only suggest that speaker should have such mechanism. It is on the way with bgp4-17 draft. Vincent. 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 IAA22750 for ; Tue, 15 Jan 2002 08:56:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9E87C9124C; Tue, 15 Jan 2002 08:56:20 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C6C39124D; Tue, 15 Jan 2002 08:56: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 45C9E9124C for ; Tue, 15 Jan 2002 08:56:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 158585DDC1; Tue, 15 Jan 2002 08:55:59 -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 B89B45DDA0 for ; Tue, 15 Jan 2002 08:55:58 -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 g0FDte682134; Tue, 15 Jan 2002 05:55:41 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200201151355.g0FDte682134@merlot.juniper.net> To: Bill Fenner Cc: skh@nexthop.com, idr@merit.edu Subject: Re: 2842 to Draft Standard In-Reply-To: Your message of "Tue, 08 Jan 2002 12:01:37 PST." <200201082001.MAA06767@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <89781.1011102940.1@juniper.net> Date: Tue, 15 Jan 2002 05:55:40 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Bill, > IDR WG, > > In order to progress to Draft Standard, an implementation report > is required (see section 4.1.2 of RFC 2026). In particular: > > The requirement for at least two independent and interoperable > implementations applies to all of the options and features of the > specification. > > RFC 2842 has several optional portions (e.g. sending Notifications > and whether to include the capability in question in the Notification), > which the implementation report that you included in the original > request did not mention. Attached is an update version of the implementation report. Yakov. ------------------------------------------------------------------- The following is the list of some of the implementations of rfc2842: Ericsson: Interoperates with: Cisco, Juniper Juniper Networks Interoperates with: Cisco Laurel Networks: Interoperates with: Cisco, Juniper NetPlane Systems Inc. Interoperates with: Cisco, Juniper Redback Interoperates with: Cisco, Juniper Riverstone: Interoperates with: Cisco, Juniper, Zebra, Foundry Unisphere Networks: Interoperates with: Cisco, Juniper Gated: Interoperates with: Cisco If a BGP speaker that supports a certain capability determines that its peer doesn't support this capability, 2 implementations never send a NOTIFICATION message to the peer, and 5 implementations sometimes send a NOTIFICATION message to the peer. Out of the 5 implementations that send the NOTIFICATION message (when the peer doesn't support a particular capability), 2 implementations never include the Capability in question in the message, and 3 implementations always include the Capability in question in the message. Five implementors reported that they always terminate BGP session when receive the NOTIFICATION message with subcode 7 (unsupported capability). Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA21591 for ; Tue, 15 Jan 2002 08:02:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 153A091249; Tue, 15 Jan 2002 08:02:27 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D52A89124B; Tue, 15 Jan 2002 08:02: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 806E891249 for ; Tue, 15 Jan 2002 08:02:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 475FC5DDA9; Tue, 15 Jan 2002 08:02:14 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id CFE335DD9F for ; Tue, 15 Jan 2002 08:02:13 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA14498; Tue, 15 Jan 2002 08:02:12 -0500 (EST) Date: Tue, 15 Jan 2002 08:02:12 -0500 (EST) From: Russ White Reply-To: Russ White To: Babu Prabesh Cc: idr@merit.edu Subject: Re: ATOMIC AGGREGATE (section 9.1.4 of bgp 4-17) In-Reply-To: <3C439035.68CF936E@cosinecom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Nope--those woul dbe two seperate routes, with their own as paths, so it won't matter if you send both of them. Presumably, rtrb knows about the /16 locally, which is why it has the static, so no looping should occur. I'm not certain how you would de-aggregate in this way.... :-) Russ On Mon, 14 Jan 2002, Babu Prabesh wrote: > Section 9.1.4: overlapping routes states: > > "If a BGP speaker chooses to aggregate, then it MUST add > ATOMIC_AGGREGATE attribute > to the route. A route that carries ATOMIC_AGGREGATE attribute can not be > de-aggregated. > That is, the NLRI of this route can not be made more specific. > Forwarding along such a > route does not guarantee that IP packets will actually traverse only ASs > listed in the > AS_PATH attribute of the route". > > I was unsure of what de-aggregation means. > Consider an example > > bgp bgp > RTRA---------RTRB----------RTRC > > RTRA sends 5/8 with ATOMIC_AGGREGATE set to RTRB. > RTRB has a 5/16 route (via static). > > Is the draft indicating that RTRB should only > advertise 5/8 to RTRC and not advertise 5/16. > > Thanks > Babu > > ############################################################################ > ########################## This email communication may contain CONFIDENTIAL > INFORMATION and is intended only for the use of the intended recipients > identified above. If you are not the intended recipient of this > communication, you must not use, disclose, distribute, copy or print this > email. If you have received this communication in error, please immediately > notify the sender by reply email, delete the communication and destroy all > copies. > ############################################################################ > ########################## > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA21262 for ; Tue, 15 Jan 2002 07:48:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D83BB91248; Tue, 15 Jan 2002 07:48:03 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96B3791249; Tue, 15 Jan 2002 07:48:03 -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 EFA8C91248 for ; Tue, 15 Jan 2002 07:48:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id CB6E15DD9F; Tue, 15 Jan 2002 07:48:01 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 5371B5DDA9 for ; Tue, 15 Jan 2002 07:48:01 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA12825; Tue, 15 Jan 2002 07:47:51 -0500 (EST) Date: Tue, 15 Jan 2002 07:47:51 -0500 (EST) From: Russ White Reply-To: Russ White To: Yakov Rekhter Cc: Jeffrey Haas , idr@merit.edu Subject: Re: bgp4-17 Cease subcode In-Reply-To: <200201141750.g0EHo3634958@merlot.juniper.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk > > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote: > > > Please remember that the goal of the draft is to document > > > what is *currently* implemented and deployed, *not* what > > > *could* be implemented and deployed. > > > > Is the expoential backoff in the FSM in current implementations? > > I guess we are going to find this out as part of the > implementation report. And if it is not in (at least two) > current implementations, we'll take it out of the text. Cisco doesn't do this.... :-) Russ _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA08514 for ; Mon, 14 Jan 2002 23:22:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DAC6291238; Mon, 14 Jan 2002 23:21:41 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ACCC891239; Mon, 14 Jan 2002 23:21:41 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8041591238 for ; Mon, 14 Jan 2002 23:21:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4C0C95DDAC; Mon, 14 Jan 2002 23:21:40 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 34D705DDA7 for ; Mon, 14 Jan 2002 23:21:40 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0F4LTo68244; Mon, 14 Jan 2002 23:21:29 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0F4LSY14723; Mon, 14 Jan 2002 23:21:28 -0500 (EST) Date: Mon, 14 Jan 2002 23:21:28 -0500 From: Jeffrey Haas To: Enke Chen Cc: idr@merit.edu Subject: Re: IDR WG Last Call Message-ID: <20020114232128.B14701@nexthop.com> References: <20020115000424.A0D247E6C1@popserv3.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020115000424.A0D247E6C1@popserv3.redback.com>; from enke@redback.com on Mon, Jan 14, 2002 at 04:04:24PM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Mon, Jan 14, 2002 at 04:04:24PM -0800, Enke Chen wrote: > It seems that the "SAFI 3" certainly makes the issue at hand much more > complicated. IMO, SAFI 3 was probably not a very good idea. Dealing with it can be a real pain in the implementation. :-) > As Yakov and Sue pointed out, it is a good idea to discourage > having one prefix in multiple fields of an update message. How about the > following text: > > An UPDATE message should not include the same address prefix in more than > one of the following fields: WITHDRAWN ROUTES field, Network Reachability > Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The > processing of an UPDATE message in this form is un-defined. I think that "undefined" is overkill. I would suggest the following instead: An UPDATE message should not include the same address prefix in more than one of the following fields: WITHDRAWN ROUTES, Network Layer Reachability Information, MP_REACH_NLRI and MP_UNREACH_NLRI. An implementation that receives a packet in this form should process the Update as if it had processed it in the following order: WITHDRAWN ROUTE, MP_UNREACH_NLRI, MP_REACH_NLRI, Network Layer Reachability Information. The wording could probably use some tightening. The intended result is that reachability rules over unreachability. > -- Enke -- Jeff Haas NextHop Technologies 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 VAA05138 for ; Mon, 14 Jan 2002 21:10:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9271491236; Mon, 14 Jan 2002 21:10:00 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A29391238; Mon, 14 Jan 2002 21:10:00 -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 DEA8191236 for ; Mon, 14 Jan 2002 21:09:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id B90445DF2D; Mon, 14 Jan 2002 21:09:58 -0500 (EST) Delivered-To: idr@merit.edu Received: from exchsrv2.cosinecom.com (proxy127.cosinecom.com [63.88.104.127]) by segue.merit.edu (Postfix) with ESMTP id 7036B5DF28 for ; Mon, 14 Jan 2002 21:09:58 -0500 (EST) Received: by exchsrv2.cosinecom.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 18:09:53 -0800 Received: from cosinecom.com (BPRABESH-NT [172.20.12.177]) by imchub1.cosinecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CYWSMRQV; Mon, 14 Jan 2002 18:09:56 -0800 Message-ID: <3C439035.68CF936E@cosinecom.com> From: Babu Prabesh Reply-To: Babu Prabesh To: idr@merit.edu Subject: ATOMIC AGGREGATE (section 9.1.4 of bgp 4-17) Date: Mon, 14 Jan 2002 18:13:09 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19D69.B9F43200" Sender: owner-idr@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C19D69.B9F43200 Content-Type: text/plain; charset="iso-8859-1" Section 9.1.4: overlapping routes states: "If a BGP speaker chooses to aggregate, then it MUST add ATOMIC_AGGREGATE attribute to the route. A route that carries ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the NLRI of this route can not be made more specific. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASs listed in the AS_PATH attribute of the route". I was unsure of what de-aggregation means. Consider an example bgp bgp RTRA---------RTRB----------RTRC RTRA sends 5/8 with ATOMIC_AGGREGATE set to RTRB. RTRB has a 5/16 route (via static). Is the draft indicating that RTRB should only advertise 5/8 to RTRC and not advertise 5/16. Thanks Babu ############################################################################ ########################## This email communication may contain CONFIDENTIAL INFORMATION and is intended only for the use of the intended recipients identified above. If you are not the intended recipient of this communication, you must not use, disclose, distribute, copy or print this email. If you have received this communication in error, please immediately notify the sender by reply email, delete the communication and destroy all copies. ############################################################################ ########################## ------_=_NextPart_001_01C19D69.B9F43200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ATOMIC AGGREGATE (section 9.1.4 of bgp 4-17)

Section 9.1.4: overlapping routes states:

"If a BGP speaker chooses to aggregate, then it = MUST add
ATOMIC_AGGREGATE attribute
to the route. A route that carries ATOMIC_AGGREGATE = attribute can not be
de-aggregated.
That is, the NLRI of this route can not be made more = specific.
Forwarding along such a
route does not guarantee that IP packets will = actually traverse only ASs
listed in the
AS_PATH attribute of the route".

I was unsure of what de-aggregation means.
Consider an example

          &nb= sp;    = bgp           &nb= sp;      bgp
  RTRA---------RTRB----------RTRC

 RTRA sends 5/8 with ATOMIC_AGGREGATE set to = RTRB.
 RTRB has a 5/16 route (via static).

Is the draft indicating that RTRB should only
advertise 5/8 to RTRC and not advertise 5/16.

Thanks
 Babu

###############################################################= ####################################### This email communication may = contain CONFIDENTIAL INFORMATION and is intended only for the use of = the intended recipients identified above.  If you are not the = intended recipient of this communication, you must not use, disclose, = distribute, copy or print this email. If you have received this = communication in error, please immediately notify the sender by reply = email, delete the communication and destroy all copies. = ########################################################################= ##############################

------_=_NextPart_001_01C19D69.B9F43200-- 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 UAA03682 for ; Mon, 14 Jan 2002 20:14:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 52B0291235; Mon, 14 Jan 2002 20:13:56 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CAEC91236; Mon, 14 Jan 2002 20:13:56 -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 C98DE91235 for ; Mon, 14 Jan 2002 20:13:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id A43975DEE1; Mon, 14 Jan 2002 20:13:54 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 8661C5DEE0 for ; Mon, 14 Jan 2002 20:13:54 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0F1DMo62421; Mon, 14 Jan 2002 20:13:22 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020114183752.034a75a8@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 14 Jan 2002 20:13:20 -0500 To: Enke Chen From: Susan Hares Subject: Re: IDR WG Last Call Cc: Susan Hares , Yakov Rekhter , idr@merit.edu, enke@redback.com In-Reply-To: <20020114221214.3242A15D3C1@popserv1.redback.com> References: <5.0.0.25.0.20020111135817.028f8d28@mail.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Enke: The draft (and RFC) states: This document defines the following values for the Subsequent Address Family Identifier field carried in the MP_REACH_NLRI and MP_UNREACH_NLRI attributes: 1 - Network Layer Reachability Information used for unicast forwarding 2 - Network Layer Reachability Information used for multicast forwarding 3 - Network Layer Reachability Information used for both unicast and multicast forwarding Is the specification unclear? If so, please let us know so the final call can clarify the specifications. Now as to why/how/when.. I've given my best effort to answer your query. Why, because the operation person configures unicast and multicast topologies are the same. How, because the mp-bgp software causes it to go that direction. the pim-sm and other multicast protocol utilize the MP bgp routes for SPF. When, once upon a router the bgp converges and then the ribs SAFI 3 ;-)... Sue Hares At 02:12 PM 1/14/2002 -0800, Enke Chen wrote: >Sue: >In order for me to make sense out of your example, I need to be educated >on how/why/when one would use "SAFI 3", especially in the context of >Multi-protocol BGP. > >By the "same , I really meant the same , i.e., >identical values. > > -- Enke > > > Date: Fri, 11 Jan 2002 18:42:10 -0500 > > To: Enke Chen > > From: Susan Hares > > Subject: Re: IDR WG Last Call > > Cc: Susan Hares , Yakov Rekhter , > > idr@merit.edu, enke@redback.com > > In-Reply-To: <20020111180440.5CB8C7E6C1@popserv3.redback.com> > > References: > > <5.0.0.25.0.20020111111630.032cf5f0@mail.nexthop.com> > > > > Enke: > > > > It appears I was just too fuzzy in my last email and > > I assumed something about your last message (oops!!)... > > We may even be in violent agreement. > > > > > > Let's drop to specifics... > > > > Problem 1 in base specification: > > > > 1) no ordering of Withdraws and NRLI > > > > draft-17 fix: > > > > 1) Last ordering (NLRI works) -- good idea > > > > Problem 2 > > > > Order in the packet (by number) > > Withdrawl > > MP announce > > MP release > > announce > > > > Your solution - last announcement works for an (AFI,SAFI) pair > > > > Desired packet information: > > > > Previous announcement left us with 128.2/16 with SAFI 2 nexthop > 192.168.10.2 > > > > > > ASPATH + community green + next hop 192.168.10.15 > > > > Withdraw - nothing > > MPREACH - 128.2/16 with SAFI 3 next hop 192.168.10.2 > > MPUNREACH - 128.2/16 with SAFI 2 > > REACH - 128.2 (SAFI = 1 by default) > > > > This scenario passes your test. All things are processed. > > However, we have a order problem: > > > > 1) If you process the sections as: > > Withdraw, > > MPReach, > > MPUNREACH , > > Reach > > > > You get 128.2 (SAFI = 1) with next hop 192.168.10.15. > > > > 2) If you process: > > Withdrawa, > > MPUNREACH, > > MPREACH, > > NLRI > > > > You get 128.2 SAFI 1 next hop 192.168.10.15, > > 128.2 SAFI 2 next hop 192.168.10.2 > > > > > > > > Can we set the order with additions of the additions within your > > text: > > > > MPBGP unreachables before MPBGP reachables. > > > > If we have your text plus, the MPUNREACH before MPREACH - we have specific > > ordering. If you like these 2 additions, we are done > > > > > > If you implied that SAFI 3 = SAFI 1 + 2, your text does not > > state it. The scenario I listed would be illegal. > > > > Two summaries: > > > > 1) Do you want Your text + ordering of MPBGP unreachables before MP > reachables? > > If so, let's get yakov to swipe text from the bgp-4 draft 17 > for this > > note. > > > > > > 2) Could you please confirm that you mean SAFI 3, SAFI 2, and SAFI 1 > > can all be listed in the same PDU. > > > > > > you've hit the mark with the need to settle this for the MPBGP protocols. > > > > Sue Hares > > > > > > > > > > > > > > > > > > > > > > At 10:13 AM 1/10/2002 -0800, Enke Chen wrote: > > > > >Hi, Yakov: > > > > >How about we add the following clarification (similar to the one in > > > the base > > > > >BGP spec): > > > > > > > > > > An UPDATE message should not include the same address prefix (of > > > the same > > > > > ) in more than one of the following fields: WITHDRAWN > > > ROUTES > > > > > field, Network Reachability Information fields, MP_REACH_NLRI > > > field, and > > > > > MP_UNREACH_NLRI field. However a BGP speaker MUST be able to > process > > > > > UPDATE > > > > > messages in this form. A BGP speaker should treat an UPDATE > > > message of > > > > > this > > > > > form as if that the address prefix were included only in the last > > > field of > > > > > the message. > > > > > > > > > >Thanks. -- Enke > > > > > > > > > > > Message-Id: <200201100131.g0A1Vn658927@merlot.juniper.net> > > > > > > To: idr@merit.edu > > > > > > Subject: IDR WG Last Call > > > > > > MIME-Version: 1.0 > > > > > > Content-Type: text/plain; charset="us-ascii" > > > > > > Content-ID: <18652.1010626309.1@juniper.net> > > > > > > Date: Wed, 09 Jan 2002 17:31:49 -0800 > > > > > > From: Yakov Rekhter > > > > > > Sender: owner-idr@merit.edu > > > > > > Precedence: bulk > > > > > > > > > > > > Folks, > > > > > > > > > > > > This is to begin the WG Last Call on advancing Multiprotocol > > > > > > Extensions for BGP-4 to Draft Standard. The Last Call ends > > > > > > Jan 23, 2002. > > > > > > > > > > > > Yakov. > > > > > > ------- Forwarded Message > > > > > > > > > > > > Date: Wed, 09 Jan 2002 16:06:30 -0500 > > > > > > From: Internet-Drafts@ietf.org > > > > > > To: IETF-Announce: ; > > > > > > cc: idr@merit.edu > > > > > > Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt > > > > > > > > > > > > - --NextPart > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > > directories. > > > > > > This draft is a work item of the Inter-Domain Routing Working > Group of > > > > > the IETF > > > > > > . > > > > > > > > > > > > Title : Multiprotocol Extensions for BGP-4 > > > > > > Author(s) : T. Bates et al. > > > > > > Filename : draft-ietf-idr-rfc2858bis-00.txt > > > > > > Pages : 10 > > > > > > Date : 08-Jan-02 > > > > > > > > > > > > Currently BGP-4 [BGP-4] is capable of carrying routing information > > > > > > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to > > > > > > enable it to carry routing information for multiple Network Layer > > > > > > protocols (e.g., IPv6, IPX, etc...). The extensions are backward > > > > > > compatible - a router that supports the extensions can interoperate > > > > > > with a router that doesn't support the extensions. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt > > > > > > > > > > > > To remove yourself from the IETF Announcement list, send a > message to > > > > > > ietf-announce-request with the word unsubscribe in the body of the > > > message. > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > > > > username > > > > > > "anonymous" and a password of your e-mail address. After > logging in, > > > > > > type "cd internet-drafts" and then > > > > > > "get draft-ietf-idr-rfc2858bis-00.txt". > > > > > > > > > > > > A list of Internet-Drafts directories can be found in > > > > > > http://www.ietf.org/shadow.html > > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > > > > 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 TAA01716 for ; Mon, 14 Jan 2002 19:05:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4BAA491234; Mon, 14 Jan 2002 19:04:27 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 197D691235; Mon, 14 Jan 2002 19:04: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 1157A91234 for ; Mon, 14 Jan 2002 19:04:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id DC19B5DE51; Mon, 14 Jan 2002 19:04:25 -0500 (EST) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id A74265DE1D for ; Mon, 14 Jan 2002 19:04:25 -0500 (EST) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 25E76CAB71; Mon, 14 Jan 2002 16:04:25 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id A0D247E6C1; Mon, 14 Jan 2002 16:04:24 -0800 (PST) To: Jeffrey Haas Cc: idr@merit.edu, enke@redback.com Subject: Re: IDR WG Last Call In-Reply-To: Message from Jeffrey Haas of "Mon, 14 Jan 2002 18:12:57 EST." <20020114181256.I7761@nexthop.com> Date: Mon, 14 Jan 2002 16:04:24 -0800 From: Enke Chen Message-Id: <20020115000424.A0D247E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Jeff, Thanks for the pointer - I totally missed that part of the spec.. It seems that the "SAFI 3" certainly makes the issue at hand much more complicated. As Yakov and Sue pointed out, it is a good idea to discourage having one prefix in multiple fields of an update message. How about the following text: An UPDATE message should not include the same address prefix in more than one of the following fields: WITHDRAWN ROUTES field, Network Reachability Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. The processing of an UPDATE message in this form is un-defined. -- Enke > Date: Mon, 14 Jan 2002 18:12:57 -0500 > From: Jeffrey Haas > To: Enke Chen > Cc: idr@merit.edu > Subject: Re: IDR WG Last Call > Message-ID: <20020114181256.I7761@nexthop.com> > References: <20020114221214.3242A15D3C1@popserv1.redback.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > User-Agent: Mutt/1.2.5i > In-Reply-To: <20020114221214.3242A15D3C1@popserv1.redback.com>; from enke@redback.com on Mon, Jan 14, 2002 at 02:12:12PM -0800 > X-NextHop-MailScanner: Found to be clean > > On Mon, Jan 14, 2002 at 02:12:12PM -0800, Enke Chen wrote: > > In order for me to make sense out of your example, I need to be educated > > on how/why/when one would use "SAFI 3", especially in the context of > > Multi-protocol BGP. > > 3 - Network Layer Reachability Information used for both unicast > and multicast forwarding > > In other words, where you would otherwise send a SAFI 1 and then a SAFI 2 > announcement for the same prefix and same path attributes, you could > otherwise send a SAFI 3 advertisement. > > > -- Enke > > -- > Jeff Haas > NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA00563 for ; Mon, 14 Jan 2002 18:13:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EDFE291233; Mon, 14 Jan 2002 18:13:13 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C00BB91234; Mon, 14 Jan 2002 18:13: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 A161191233 for ; Mon, 14 Jan 2002 18:13:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 774905DDAF; Mon, 14 Jan 2002 18:13:12 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 33C765DDAE for ; Mon, 14 Jan 2002 18:13:12 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0ENCwo58787; Mon, 14 Jan 2002 18:12:58 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0ENCve14474; Mon, 14 Jan 2002 18:12:57 -0500 (EST) Date: Mon, 14 Jan 2002 18:12:57 -0500 From: Jeffrey Haas To: Enke Chen Cc: idr@merit.edu Subject: Re: IDR WG Last Call Message-ID: <20020114181256.I7761@nexthop.com> References: <20020114221214.3242A15D3C1@popserv1.redback.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020114221214.3242A15D3C1@popserv1.redback.com>; from enke@redback.com on Mon, Jan 14, 2002 at 02:12:12PM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Mon, Jan 14, 2002 at 02:12:12PM -0800, Enke Chen wrote: > In order for me to make sense out of your example, I need to be educated > on how/why/when one would use "SAFI 3", especially in the context of > Multi-protocol BGP. 3 - Network Layer Reachability Information used for both unicast and multicast forwarding In other words, where you would otherwise send a SAFI 1 and then a SAFI 2 announcement for the same prefix and same path attributes, you could otherwise send a SAFI 3 advertisement. > -- Enke -- Jeff Haas NextHop Technologies Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA28744 for ; Mon, 14 Jan 2002 17:12:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F322C9122F; Mon, 14 Jan 2002 17:12:26 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C129991230; Mon, 14 Jan 2002 17: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 A88EB9122F for ; Mon, 14 Jan 2002 17:12:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 837C65DDDC; Mon, 14 Jan 2002 17:12:24 -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 A92A85DE0A for ; Mon, 14 Jan 2002 17:12:23 -0500 (EST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id D654DF2C5C; Mon, 14 Jan 2002 14:12:18 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id 3242A15D3C1; Mon, 14 Jan 2002 14:12:13 -0800 (PST) To: Susan Hares Cc: Yakov Rekhter , idr@merit.edu, enke@redback.com Subject: Re: IDR WG Last Call In-Reply-To: Message from Susan Hares of "Fri, 11 Jan 2002 18:42:10 EST." <5.0.0.25.0.20020111135817.028f8d28@mail.nexthop.com> Date: Mon, 14 Jan 2002 14:12:12 -0800 From: Enke Chen Message-Id: <20020114221214.3242A15D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Sue: In order for me to make sense out of your example, I need to be educated on how/why/when one would use "SAFI 3", especially in the context of Multi-protocol BGP. By the "same , I really meant the same , i.e., identical values. -- Enke > Date: Fri, 11 Jan 2002 18:42:10 -0500 > To: Enke Chen > From: Susan Hares > Subject: Re: IDR WG Last Call > Cc: Susan Hares , Yakov Rekhter , > idr@merit.edu, enke@redback.com > In-Reply-To: <20020111180440.5CB8C7E6C1@popserv3.redback.com> > References: > <5.0.0.25.0.20020111111630.032cf5f0@mail.nexthop.com> > > Enke: > > It appears I was just too fuzzy in my last email and > I assumed something about your last message (oops!!)... > We may even be in violent agreement. > > > Let's drop to specifics... > > Problem 1 in base specification: > > 1) no ordering of Withdraws and NRLI > > draft-17 fix: > > 1) Last ordering (NLRI works) -- good idea > > Problem 2 > > Order in the packet (by number) > Withdrawl > MP announce > MP release > announce > > Your solution - last announcement works for an (AFI,SAFI) pair > > Desired packet information: > > Previous announcement left us with 128.2/16 with SAFI 2 nexthop 192.168.10.2 > > > ASPATH + community green + next hop 192.168.10.15 > > Withdraw - nothing > MPREACH - 128.2/16 with SAFI 3 next hop 192.168.10.2 > MPUNREACH - 128.2/16 with SAFI 2 > REACH - 128.2 (SAFI = 1 by default) > > This scenario passes your test. All things are processed. > However, we have a order problem: > > 1) If you process the sections as: > Withdraw, > MPReach, > MPUNREACH , > Reach > > You get 128.2 (SAFI = 1) with next hop 192.168.10.15. > > 2) If you process: > Withdrawa, > MPUNREACH, > MPREACH, > NLRI > > You get 128.2 SAFI 1 next hop 192.168.10.15, > 128.2 SAFI 2 next hop 192.168.10.2 > > > > Can we set the order with additions of the additions within your > text: > > MPBGP unreachables before MPBGP reachables. > > If we have your text plus, the MPUNREACH before MPREACH - we have specific > ordering. If you like these 2 additions, we are done > > > If you implied that SAFI 3 = SAFI 1 + 2, your text does not > state it. The scenario I listed would be illegal. > > Two summaries: > > 1) Do you want Your text + ordering of MPBGP unreachables before MP reachables? > If so, let's get yakov to swipe text from the bgp-4 draft 17 for this > note. > > > 2) Could you please confirm that you mean SAFI 3, SAFI 2, and SAFI 1 > can all be listed in the same PDU. > > > you've hit the mark with the need to settle this for the MPBGP protocols. > > Sue Hares > > > > > > > > > > > > > > At 10:13 AM 1/10/2002 -0800, Enke Chen wrote: > > > >Hi, Yakov: > > > >How about we add the following clarification (similar to the one in > > the base > > > >BGP spec): > > > > > > > > An UPDATE message should not include the same address prefix (of > > the same > > > > ) in more than one of the following fields: WITHDRAWN > > ROUTES > > > > field, Network Reachability Information fields, MP_REACH_NLRI > > field, and > > > > MP_UNREACH_NLRI field. However a BGP speaker MUST be able to process > > > > UPDATE > > > > messages in this form. A BGP speaker should treat an UPDATE > > message of > > > > this > > > > form as if that the address prefix were included only in the last > > field of > > > > the message. > > > > > > > >Thanks. -- Enke > > > > > > > > > Message-Id: <200201100131.g0A1Vn658927@merlot.juniper.net> > > > > > To: idr@merit.edu > > > > > Subject: IDR WG Last Call > > > > > MIME-Version: 1.0 > > > > > Content-Type: text/plain; charset="us-ascii" > > > > > Content-ID: <18652.1010626309.1@juniper.net> > > > > > Date: Wed, 09 Jan 2002 17:31:49 -0800 > > > > > From: Yakov Rekhter > > > > > Sender: owner-idr@merit.edu > > > > > Precedence: bulk > > > > > > > > > > Folks, > > > > > > > > > > This is to begin the WG Last Call on advancing Multiprotocol > > > > > Extensions for BGP-4 to Draft Standard. The Last Call ends > > > > > Jan 23, 2002. > > > > > > > > > > Yakov. > > > > > ------- Forwarded Message > > > > > > > > > > Date: Wed, 09 Jan 2002 16:06:30 -0500 > > > > > From: Internet-Drafts@ietf.org > > > > > To: IETF-Announce: ; > > > > > cc: idr@merit.edu > > > > > Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt > > > > > > > > > > - --NextPart > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > > > This draft is a work item of the Inter-Domain Routing Working Group of > > > > the IETF > > > > > . > > > > > > > > > > Title : Multiprotocol Extensions for BGP-4 > > > > > Author(s) : T. Bates et al. > > > > > Filename : draft-ietf-idr-rfc2858bis-00.txt > > > > > Pages : 10 > > > > > Date : 08-Jan-02 > > > > > > > > > > Currently BGP-4 [BGP-4] is capable of carrying routing information > > > > > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to > > > > > enable it to carry routing information for multiple Network Layer > > > > > protocols (e.g., IPv6, IPX, etc...). The extensions are backward > > > > > compatible - a router that supports the extensions can interoperate > > > > > with a router that doesn't support the extensions. > > > > > > > > > > A URL for this Internet-Draft is: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt > > > > > > > > > > To remove yourself from the IETF Announcement list, send a message to > > > > > ietf-announce-request with the word unsubscribe in the body of the > > message. > > > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > > > username > > > > > "anonymous" and a password of your e-mail address. After logging in, > > > > > type "cd internet-drafts" and then > > > > > "get draft-ietf-idr-rfc2858bis-00.txt". > > > > > > > > > > A list of Internet-Drafts directories can be found in > > > > > http://www.ietf.org/shadow.html > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > 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 QAA27669 for ; Mon, 14 Jan 2002 16:32:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B72809123C; Mon, 14 Jan 2002 16:31:38 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8746091247; Mon, 14 Jan 2002 16:31: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 5641B9123C for ; Mon, 14 Jan 2002 16:31:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2B16F5DDA0; Mon, 14 Jan 2002 16:31:37 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id C5F685DD91 for ; Mon, 14 Jan 2002 16:31:36 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0ELVRo55516; Mon, 14 Jan 2002 16:31:27 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020114145719.032b4008@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 14 Jan 2002 16:31:26 -0500 To: Yakov Rekhter From: Susan Hares Subject: Re: IDR WG Last Call Cc: idr@merit.edu In-Reply-To: <200201141726.g0EHQj633850@merlot.juniper.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Yakov: Inter-operability is the basis for IETF specifications. I suspect that indicating in the specification what is a stupid thing to stop is a good idea. Then, someone doesn't find a stupid thing in a network. Sue At 09:26 AM 1/14/2002 -0800, you wrote: >Sue, > > > Enke: > > > > It appears I was just too fuzzy in my last email and > > I assumed something about your last message (oops!!)... > > We may even be in violent agreement. > > > > > > Let's drop to specifics... > > > > Problem 1 in base specification: > > > > 1) no ordering of Withdraws and NRLI > > > > draft-17 fix: > > > > 1) Last ordering (NLRI works) -- good idea > > > > Problem 2 > > > > Order in the packet (by number) > > Withdrawl > > MP announce > > MP release > > announce > > > > Your solution - last announcement works for an (AFI,SAFI) pair > > > > Desired packet information: > > > > Previous announcement left us with 128.2/16 with SAFI 2 nexthop > 192.168.10.2 > > > > > > ASPATH + community green + next hop 192.168.10.15 > > > > Withdraw - nothing > > MPREACH - 128.2/16 with SAFI 3 next hop 192.168.10.2 > > MPUNREACH - 128.2/16 with SAFI 2 > > REACH - 128.2 (SAFI = 1 by default) > > > > This scenario passes your test. All things are processed. > > However, we have a order problem: > > > > 1) If you process the sections as: > > Withdraw, > > MPReach, > > MPUNREACH , > > Reach > > > > You get 128.2 (SAFI = 1) with next hop 192.168.10.15. > > > > 2) If you process: > > Withdrawa, > > MPUNREACH, > > MPREACH, > > NLRI > > > > You get 128.2 SAFI 1 next hop 192.168.10.15, > > 128.2 SAFI 2 next hop 192.168.10.2 > >Please note that the whole idea of carrying the same NLRI in >Withdrawn, MPUNREACH, MPREACH, and NLRI of the same UPDATE message >is kind of stupid. Enke alluded this in his proposed text: > > An UPDATE message should not include the same address prefix (of the same > ) in more than one of the following fields: WITHDRAWN ROUTES > field, Network Reachability Information fields, MP_REACH_NLRI field, and > MP_UNREACH_NLRI field. > >Thus I don't think the spec should be that much concerned with the >outcome of folks doing stupid things. > >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 QAA27232 for ; Mon, 14 Jan 2002 16:18:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A25959124A; Mon, 14 Jan 2002 16:13:00 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E01499123C; Mon, 14 Jan 2002 16:12: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 D842E9122D for ; Mon, 14 Jan 2002 16:11:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id BC4755DED4; Mon, 14 Jan 2002 16:11:43 -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 350E45DEDE for ; Mon, 14 Jan 2002 16:11:43 -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 g0ELBe647395; Mon, 14 Jan 2002 13:11:40 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200201142111.g0ELBe647395@merlot.juniper.net> To: Alex Zinin Cc: "Tom Petch" , idr@merit.edu Subject: Re: bgp4-17 Section 9 In-Reply-To: Your message of "Fri, 11 Jan 2002 09:16:54 PST." <172687938513.20020111091654@nexsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17338.1011042700.1@juniper.net> Date: Mon, 14 Jan 2002 13:11:40 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Alex, > Tom, > > > 9.1.2 Route selection now allows for the best route in > > Loc-RIB not to be placed in the Routing table; how does this > > impact on the principle (2 Introduction) that a BGP Speaker > > should only advertise routes it itself uses? Is it enough > > for the route to be in Loc-RIB and not in the Routing Table? > > The principle implies that the route is both in Loc-RIB and > in the routing table, i.e., it needs to be both selected as > the best and used by the router. > However, we can only specify so much about the routing table, > as it is (strictly speaking) outside of the scope of the BGP > protocol and administrator do have the "filter" rope in > their hands. Section 3.2 also talks about this. > > > I believe the paragraph on immediate next hop should > > cross-reference the one in 5.1.3; and the latter allows > > route lookup to resolve to a subnet and not an immediate > > next hop address, a possibility 9.1.2 appears not to cater > > for. > > Fine with me. > > > Perhaps the information on immediate next hop in 5.1.3 and 9 > > should be combined in one place; 5.1.3 would be my > > preference. > > Fine with me. > > > 9.1.2.1 Intermediate network address throws me each time as > > I start thinking of networks; I assume that this is the > > immediate next hop of Rte1; if so, would not that be > > clearer? > > The address in Rte1 can be either a direct next-hop or > a third party next-hop (not really a next hop from the RT > perspective). "Intermediate" should account for both cases. > > > Resolvability talks of routing table entries for IGP and > > directly connected networks; for consistency with 3.2, I > > would like to see static in there as well. > > I actually thought about it when writing this text, but > it fell out of my head. How about this: > > BGP routes do not refer to interfaces, but can be resolved through > the routes in the Routing Table that can be of both types. IGP routes > and routes to directly connected networks are expected to specify the > outbound interface. Static routes can specify the outbound > interface, or the intermediate address, or both. done. > > > 9.1.2.2e Again 5.1.3 impacts on this;should this be > > 'immediate next hop' as opposed to 'next hop' (or NEXT_HOP!) > > and what happens with a recursive lookup? Which of the > > metrics in the various Routing Table entries gets used? > > Perhaps 'The interior cost of a route is the metric in the > > routing table for the immediate next hop (see 5.1.3)' > > In fact, "next hop" should read as NEXT_HOP. The metric > is the IGP cost found in the route resolving the NEXT_HOP. done. 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 QAA27208 for ; Mon, 14 Jan 2002 16:17:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1144A9122D; Mon, 14 Jan 2002 16:13:00 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D2C091238; Mon, 14 Jan 2002 16:12: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 A06239123C for ; Mon, 14 Jan 2002 16:12:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 855AF5DEDE; Mon, 14 Jan 2002 16:12:41 -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 365275DED4 for ; Mon, 14 Jan 2002 16:12:41 -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 g0ELCc647431; Mon, 14 Jan 2002 13:12:38 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200201142112.g0ELCc647431@merlot.juniper.net> To: Alex Zinin Cc: "Tom Petch" , idr@merit.edu Subject: Re: bgp4-17 5.1.3 NEXT_HOP attribute determination In-Reply-To: Your message of "Fri, 11 Jan 2002 08:29:04 PST." <140685068856.20020111082904@nexsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17547.1011042757.1@juniper.net> Date: Mon, 14 Jan 2002 13:12:38 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Alex, > Tom, > > > I think that there is a problem with logic and terminology > > in the determination of NEXT_HOP. There are four cases > > listed, > > - a form of "third party" NEXT_HOP attribute > > - a second form of "third party" NEXT_HOP attribute > > - "first party" NEXT_HOP attribute > > - by default > > and respectively the BGP speaker > > - can use > > - can use > > - may use > > - should use > > which seems inconsistent; I would prefer SHOULD. > > Since use of third party next hops is an optimization > by nature and does not *have* to be implemented, > and given that "should" is used for the default, > I think "may/can" is ok. If we change the optional > cases to "should" to increase the level on insistence, > we should do the same to the default case and make > it a must. > If you ask me, I think we're all right now. > > > > But logically, the first party (common subnet) overlaps the > > two third parties (common subnet with IBGP or locally > > originated and common subnet with EBGP) which obviates > > SHOULD. > > We know how to deal with overlapping cases already--- > the more specific one wins. Same here---third party > cases are more specific in their description. > I guess it might be clearer if we changed "-if -if" > to "-if -otherwise if". done. 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 PAA25353 for ; Mon, 14 Jan 2002 15:20:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CC2F191226; Mon, 14 Jan 2002 15:20:19 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9626A91227; Mon, 14 Jan 2002 15:20:19 -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 5706291226 for ; Mon, 14 Jan 2002 15:20:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 08A225DDF2; Mon, 14 Jan 2002 15:20:18 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 759915DDFA for ; Mon, 14 Jan 2002 15:20:17 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0EKK0o52968; Mon, 14 Jan 2002 15:20:00 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020114151919.0329db98@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 14 Jan 2002 15:19:58 -0500 To: Jeffrey Haas From: Susan Hares Subject: Re: bgp4-17 Cease subcode Cc: Yakov Rekhter , idr@merit.edu In-Reply-To: <20020114123700.C7761@nexthop.com> References: <200201141728.g0EHSr633936@merlot.juniper.net> <005001c2b9ba$3094a9e0$9989bc3e@tom3> <200201141728.g0EHSr633936@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Jeff: The backoff was in the original FSM. Your question still stands, is it in the implementations. Sue At 12:37 PM 1/14/2002 -0500, Jeffrey Haas wrote: >On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote: > > Please remember that the goal of the draft is to document > > what is *currently* implemented and deployed, *not* what > > *could* be implemented and deployed. > >Is the expoential backoff in the FSM in current implementations? > >Note that this change (IdleHold) to the FSM is going to result in >an alteration to the MIB. This is one of the reasons I've held >off completion of the RFC 1657 update - to accomodate for this fact >to converge. > > > Therefore, the draft > > should not list these new subcodes. > > > > Yakov. > >-- >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 PAA25264 for ; Mon, 14 Jan 2002 15:17:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6CE6D91225; Mon, 14 Jan 2002 15:16:54 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CFE991226; Mon, 14 Jan 2002 15:16: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 EDDFD91225 for ; Mon, 14 Jan 2002 15:16:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id CB8B45DDF6; Mon, 14 Jan 2002 15:16: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 4BE1E5DDF2 for ; Mon, 14 Jan 2002 15:16: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 g0EKGo644430; Mon, 14 Jan 2002 12:16:50 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200201142016.g0EKGo644430@merlot.juniper.net> To: "Tom Petch" Cc: idr@merit.edu Subject: Re: bgp4-17 Section 9 In-Reply-To: Your message of "Sat, 11 Jan 2003 15:53:01 GMT." <007d01c2b989$a6a6c2c0$c490bc3e@tom3> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1721.1011039410.1@juniper.net> Date: Mon, 14 Jan 2002 12:16:50 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk > > 9.1.2 Route selection now allows for the best route in > Loc-RIB not to be placed in the Routing table; how does this > impact on the principle (2 Introduction) that a BGP Speaker > should only advertise routes it itself uses? Is it enough > for the route to be in Loc-RIB and not in the Routing Table? > > I believe the paragraph on immediate next hop should > cross-reference the one in 5.1.3; and the latter allows > route lookup to resolve to a subnet and not an immediate > next hop address, a possibility 9.1.2 appears not to cater > for. > > Perhaps the information on immediate next hop in 5.1.3 and 9 > should be combined in one place; 5.1.3 would be my > preference. Please propose the specific changes. 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 PAA24991 for ; Mon, 14 Jan 2002 15:11:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EB79A91221; Mon, 14 Jan 2002 15:09:08 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD4AB91226; Mon, 14 Jan 2002 15:09: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 94D6891221 for ; Mon, 14 Jan 2002 15:09:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E67C5DD91; Mon, 14 Jan 2002 15:09:03 -0500 (EST) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id B98815DDEF for ; Mon, 14 Jan 2002 15:09:01 -0500 (EST) Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0EK8w643941; Mon, 14 Jan 2002 12:08:58 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200201142008.g0EK8w643941@merlot.juniper.net> To: Alex Zinin Cc: "Tom Petch" , idr@merit.edu Subject: Re: bgp4-17 LOCAL_PREF In-Reply-To: Your message of "Fri, 11 Jan 2002 07:29:36 PST." <177681502298.20020111072936@nexsi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <99066.1011038938.1@juniper.net> Date: Mon, 14 Jan 2002 12:08:58 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Alex, > > A "see section 5.1.5" instead of "disallowed" in > the table before 5.1 should do the trick. fixed. Yakov. > > -- > Alex Zinin > > Saturday, January 11, 2003, 4:56:35 AM, Tom Petch wrote: > > > Section 5 states that LOCAL_PREF is disallowed for EBGP; > > section 5.1.5 allows it for external peers as part of BGP > > Confederations. > > > I think that Section 5 needs qualifying > > > Tom Petch, Network Consultant > > nwnetworks@dial.pipex.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 NAA22409 for ; Mon, 14 Jan 2002 13:49:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EBC599121A; Mon, 14 Jan 2002 13:48:54 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7C4D9121B; Mon, 14 Jan 2002 13:48: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 7EB409121A for ; Mon, 14 Jan 2002 13:48:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 59CDA5DE19; Mon, 14 Jan 2002 13:48: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 C8F185DE0A for ; Mon, 14 Jan 2002 13:48: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 g0EImo638481; Mon, 14 Jan 2002 10:48:50 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200201141848.g0EImo638481@merlot.juniper.net> To: Bill Fenner Cc: idr@merit.edu Subject: Re: 2842 to Draft Standard In-Reply-To: Your message of "Tue, 08 Jan 2002 12:01:37 PST." <200201082001.MAA06767@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72198.1011034130.1@juniper.net> Date: Mon, 14 Jan 2002 10:48:50 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Bill > IDR WG, > > In order to progress to Draft Standard, an implementation report > is required (see section 4.1.2 of RFC 2026). In particular: > > The requirement for at least two independent and interoperable > implementations applies to all of the options and features of the > specification. > > RFC 2842 has several optional portions (e.g. sending Notifications > and whether to include the capability in question in the Notification), > which the implementation report that you included in the original > request did not mention. > > I'd like to see a more complete implementation report. For > example, if vendors don't mind being named: > http://www.ietf.org/IESG/Implementations/IPCOMP-Implementation.txt > or if they don't want to be named: > http://www.ietf.org/IESG/Implementations/AGENTX-IMPLEMENTATION See below. > Also, the process would go much more smoothly if there was an > Internet-Draft containing the revision, even though it's so small. > The RFC-Editor can supply the nroff of RFC 2842 if the authors > don't still have their source. Done (see draft-ietf-idr-rfc2842bis-00.txt) Yakov. ---------------------------------------------------------------------- The following is the list of some of the implementations of rfc2842: Ericsson: Interoperates with: Cisco, Juniper Juniper Networks Interoperates with: Cisco Laurel Networks: Interoperates with: Cisco, Juniper NetPlane Systems Inc. Interoperates with: Cisco, Juniper Redback Interoperates with: Cisco, Juniper Riverstone: Interoperates with: Cisco, Juniper, Zebra, Foundry Unisphere Networks: Interoperates with: Cisco, Juniper If a BGP speaker that supports a certain capability determines that its peer doesn't support this capability, 2 implementations never send a NOTIFICATION message to the peer, and 4 implementations sometimes send a NOTIFICATION message to the peer. Out of the 4 implementations that send the NOTIFICATION message (when the peer doesn't support a particular capability), 2 implementations never include the Capability in question in the message, and 2 implementations always include the Capability in question in the message. 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 MAA20642 for ; Mon, 14 Jan 2002 12:50:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EEA8391216; Mon, 14 Jan 2002 12:50:07 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2B6B91217; Mon, 14 Jan 2002 12:50: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 85A1E91216 for ; Mon, 14 Jan 2002 12:50:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F15B5DDC7; Mon, 14 Jan 2002 12:50:05 -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 BB43F5DDA2 for ; Mon, 14 Jan 2002 12:50:04 -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 g0EHo3634958; Mon, 14 Jan 2002 09:50:03 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200201141750.g0EHo3634958@merlot.juniper.net> To: Jeffrey Haas Cc: idr@merit.edu Subject: Re: bgp4-17 Cease subcode In-Reply-To: Your message of "Mon, 14 Jan 2002 12:37:00 EST." <20020114123700.C7761@nexthop.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <56151.1011030603.1@juniper.net> Date: Mon, 14 Jan 2002 09:50:03 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Jeff, > On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote: > > Please remember that the goal of the draft is to document > > what is *currently* implemented and deployed, *not* what > > *could* be implemented and deployed. > > Is the expoential backoff in the FSM in current implementations? I guess we are going to find this out as part of the implementation report. And if it is not in (at least two) current implementations, we'll take it out of the text. > Note that this change (IdleHold) to the FSM is going to result in > an alteration to the MIB. This is one of the reasons I've held > off completion of the RFC 1657 update - to accomodate for this fact > to converge. Understood. 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 MAA20276 for ; Mon, 14 Jan 2002 12:37:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5D82A91213; Mon, 14 Jan 2002 12:37:25 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2362D91216; Mon, 14 Jan 2002 12:37: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 06B9191213 for ; Mon, 14 Jan 2002 12:37:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id D67265DDA2; Mon, 14 Jan 2002 12:37:23 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 8E3EC5DD9F for ; Mon, 14 Jan 2002 12:37:23 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0EHb0o47249; Mon, 14 Jan 2002 12:37:00 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0EHb0h13847; Mon, 14 Jan 2002 12:37:00 -0500 (EST) Date: Mon, 14 Jan 2002 12:37:00 -0500 From: Jeffrey Haas To: Yakov Rekhter Cc: idr@merit.edu Subject: Re: bgp4-17 Cease subcode Message-ID: <20020114123700.C7761@nexthop.com> References: <005001c2b9ba$3094a9e0$9989bc3e@tom3> <200201141728.g0EHSr633936@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200201141728.g0EHSr633936@merlot.juniper.net>; from yakov@juniper.net on Mon, Jan 14, 2002 at 09:28:53AM -0800 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Mon, Jan 14, 2002 at 09:28:53AM -0800, Yakov Rekhter wrote: > Please remember that the goal of the draft is to document > what is *currently* implemented and deployed, *not* what > *could* be implemented and deployed. Is the expoential backoff in the FSM in current implementations? Note that this change (IdleHold) to the FSM is going to result in an alteration to the MIB. This is one of the reasons I've held off completion of the RFC 1657 update - to accomodate for this fact to converge. > Therefore, the draft > should not list these new subcodes. > > Yakov. -- 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 MAA20005 for ; Mon, 14 Jan 2002 12:29:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 61F899120D; Mon, 14 Jan 2002 12:29:02 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2FF0191213; Mon, 14 Jan 2002 12:29: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 ED2369120D for ; Mon, 14 Jan 2002 12:29:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id C25D55DDA7; Mon, 14 Jan 2002 12:29:00 -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 420B15DDA6 for ; Mon, 14 Jan 2002 12:29:00 -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 g0EHSr633936; Mon, 14 Jan 2002 09:28:58 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200201141728.g0EHSr633936@merlot.juniper.net> To: "Tom Petch" Cc: idr@merit.edu Subject: Re: bgp4-17 Cease subcode In-Reply-To: Your message of "Sat, 11 Jan 2003 21:41:20 GMT." <005001c2b9ba$3094a9e0$9989bc3e@tom3> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <50786.1011029333.1@juniper.net> Date: Mon, 14 Jan 2002 09:28:53 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Tom, > Ouch; I had forgotten reading that I-D. > > But I am still uncomfortable with last call on this > capabillity in bgp4-17 with the prospect of a subcode > appearing, or possibly not, at some point in the future in a > separate RFC. Please remember that the goal of the draft is to document what is *currently* implemented and deployed, *not* what *could* be implemented and deployed. Therefore, the draft should not list these new subcodes. 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 TAA24035 for ; Fri, 11 Jan 2002 19:33:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D34B1912A5; Fri, 11 Jan 2002 19:33:01 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7838F912A4; Fri, 11 Jan 2002 19:33: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 1EFE491245 for ; Fri, 11 Jan 2002 19:33:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 19E385DD8E; Fri, 11 Jan 2002 19:32:18 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id C3F9E5DD8D for ; Fri, 11 Jan 2002 19:32:17 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0C0Vmo59685; Fri, 11 Jan 2002 19:31:48 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020111135817.028f8d28@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 11 Jan 2002 18:42:10 -0500 To: Enke Chen From: Susan Hares Subject: Re: IDR WG Last Call Cc: Susan Hares , Yakov Rekhter , idr@merit.edu, enke@redback.com In-Reply-To: <20020111180440.5CB8C7E6C1@popserv3.redback.com> References: <5.0.0.25.0.20020111111630.032cf5f0@mail.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Enke: It appears I was just too fuzzy in my last email and I assumed something about your last message (oops!!)... We may even be in violent agreement. Let's drop to specifics... Problem 1 in base specification: 1) no ordering of Withdraws and NRLI draft-17 fix: 1) Last ordering (NLRI works) -- good idea Problem 2 Order in the packet (by number) Withdrawl MP announce MP release announce Your solution - last announcement works for an (AFI,SAFI) pair Desired packet information: Previous announcement left us with 128.2/16 with SAFI 2 nexthop 192.168.10.2 ASPATH + community green + next hop 192.168.10.15 Withdraw - nothing MPREACH - 128.2/16 with SAFI 3 next hop 192.168.10.2 MPUNREACH - 128.2/16 with SAFI 2 REACH - 128.2 (SAFI = 1 by default) This scenario passes your test. All things are processed. However, we have a order problem: 1) If you process the sections as: Withdraw, MPReach, MPUNREACH , Reach You get 128.2 (SAFI = 1) with next hop 192.168.10.15. 2) If you process: Withdrawa, MPUNREACH, MPREACH, NLRI You get 128.2 SAFI 1 next hop 192.168.10.15, 128.2 SAFI 2 next hop 192.168.10.2 Can we set the order with additions of the additions within your text: MPBGP unreachables before MPBGP reachables. If we have your text plus, the MPUNREACH before MPREACH - we have specific ordering. If you like these 2 additions, we are done If you implied that SAFI 3 = SAFI 1 + 2, your text does not state it. The scenario I listed would be illegal. Two summaries: 1) Do you want Your text + ordering of MPBGP unreachables before MP reachables? If so, let's get yakov to swipe text from the bgp-4 draft 17 for this note. 2) Could you please confirm that you mean SAFI 3, SAFI 2, and SAFI 1 can all be listed in the same PDU. you've hit the mark with the need to settle this for the MPBGP protocols. Sue Hares > > > > > > At 10:13 AM 1/10/2002 -0800, Enke Chen wrote: > > >Hi, Yakov: > > >How about we add the following clarification (similar to the one in > the base > > >BGP spec): > > > > > > An UPDATE message should not include the same address prefix (of > the same > > > ) in more than one of the following fields: WITHDRAWN > ROUTES > > > field, Network Reachability Information fields, MP_REACH_NLRI > field, and > > > MP_UNREACH_NLRI field. However a BGP speaker MUST be able to process > > > UPDATE > > > messages in this form. A BGP speaker should treat an UPDATE > message of > > > this > > > form as if that the address prefix were included only in the last > field of > > > the message. > > > > > >Thanks. -- Enke > > > > > > > Message-Id: <200201100131.g0A1Vn658927@merlot.juniper.net> > > > > To: idr@merit.edu > > > > Subject: IDR WG Last Call > > > > MIME-Version: 1.0 > > > > Content-Type: text/plain; charset="us-ascii" > > > > Content-ID: <18652.1010626309.1@juniper.net> > > > > Date: Wed, 09 Jan 2002 17:31:49 -0800 > > > > From: Yakov Rekhter > > > > Sender: owner-idr@merit.edu > > > > Precedence: bulk > > > > > > > > Folks, > > > > > > > > This is to begin the WG Last Call on advancing Multiprotocol > > > > Extensions for BGP-4 to Draft Standard. The Last Call ends > > > > Jan 23, 2002. > > > > > > > > Yakov. > > > > ------- Forwarded Message > > > > > > > > Date: Wed, 09 Jan 2002 16:06:30 -0500 > > > > From: Internet-Drafts@ietf.org > > > > To: IETF-Announce: ; > > > > cc: idr@merit.edu > > > > Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt > > > > > > > > - --NextPart > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > This draft is a work item of the Inter-Domain Routing Working Group of > > > the IETF > > > > . > > > > > > > > Title : Multiprotocol Extensions for BGP-4 > > > > Author(s) : T. Bates et al. > > > > Filename : draft-ietf-idr-rfc2858bis-00.txt > > > > Pages : 10 > > > > Date : 08-Jan-02 > > > > > > > > Currently BGP-4 [BGP-4] is capable of carrying routing information > > > > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to > > > > enable it to carry routing information for multiple Network Layer > > > > protocols (e.g., IPv6, IPX, etc...). The extensions are backward > > > > compatible - a router that supports the extensions can interoperate > > > > with a router that doesn't support the extensions. > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt > > > > > > > > To remove yourself from the IETF Announcement list, send a message to > > > > ietf-announce-request with the word unsubscribe in the body of the > message. > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > > username > > > > "anonymous" and a password of your e-mail address. After logging in, > > > > type "cd internet-drafts" and then > > > > "get draft-ietf-idr-rfc2858bis-00.txt". > > > > > > > > A list of Internet-Drafts directories can be found in > > > > http://www.ietf.org/shadow.html > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > 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 QAA20232 for ; Fri, 11 Jan 2002 16:42:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D063E912A2; Fri, 11 Jan 2002 16:42:02 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A422A912A3; Fri, 11 Jan 2002 16:42: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 8DFCC912A2 for ; Fri, 11 Jan 2002 16:42:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6443C5DDB8; Fri, 11 Jan 2002 16:42:01 -0500 (EST) Delivered-To: idr@merit.edu Received: from hose.mail.pipex.net (hose.mail.pipex.net [158.43.128.58]) by segue.merit.edu (Postfix) with SMTP id A1FBF5DDB7 for ; Fri, 11 Jan 2002 16:42:00 -0500 (EST) Received: (qmail 22449 invoked from network); 11 Jan 2002 21:41:58 -0000 Received: from userat50.uk.uudial.com (HELO tom3) (62.188.137.153) by smtp-4.dial.pipex.com with SMTP; 11 Jan 2002 21:41:58 -0000 Message-ID: <005001c2b9ba$3094a9e0$9989bc3e@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: "Yakov Rekhter" Cc: , Subject: Re: bgp4-17 Cease subcode Date: Sat, 11 Jan 2003 21:41:20 -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 Ouch; I had forgotten reading that I-D. But I am still uncomfortable with last call on this capabillity in bgp4-17 with the prospect of a subcode appearing, or possibly not, at some point in the future in a separate RFC. Tom Petch, Network Consultant nwnetworks@dial.pipex.com +(44) 192 575 3018 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 PAA18951 for ; Fri, 11 Jan 2002 15:48:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D50B49129E; Fri, 11 Jan 2002 15:48:23 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A4BB9912A0; Fri, 11 Jan 2002 15:48: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 A97989129E for ; Fri, 11 Jan 2002 15:48:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 827E35DDCC; Fri, 11 Jan 2002 15:48:21 -0500 (EST) Delivered-To: idr@merit.edu Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id E87BE5DDC6 for ; Fri, 11 Jan 2002 15:48:20 -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 g0BKm8650359; Fri, 11 Jan 2002 12:48:08 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200201112048.g0BKm8650359@merlot.juniper.net> To: "Tom Petch" Cc: idr@merit.edu, yakov@juniper.net Subject: Re: bgp4-17 Cease subcode In-Reply-To: Your message of "Sat, 11 Jan 2003 15:48:06 GMT." <007c01c2b989$a60811c0$c490bc3e@tom3> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <32230.1010782088.1@juniper.net> Date: Fri, 11 Jan 2002 12:48:08 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Tom, > I believe there should be a Cease sub-code to differentiate > the case where the upper bound on the number of acceptable > address prefixes is exceeded. If not, then the recipient of > the Cease could assume this is due to some other transient, > re-establish the connection and repeat the process ad > infinitum. See draft-ietf-idr-cease-subcode-00.txt for more details. 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 OAA16248 for ; Fri, 11 Jan 2002 14:11:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 585D49129D; Fri, 11 Jan 2002 14:11:27 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A1B29129E; Fri, 11 Jan 2002 14:11: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 0BC789129D for ; Fri, 11 Jan 2002 14:11:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id D1DB45DD92; Fri, 11 Jan 2002 14:11:25 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 856285DD90 for ; Fri, 11 Jan 2002 14:11:25 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0BJAoo49582; Fri, 11 Jan 2002 14:10:51 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020111140950.03d4ac18@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 11 Jan 2002 14:10:48 -0500 To: "Tom Petch" From: Susan Hares Subject: Re: bgp4-16 ATOMIC_AGGREGATE Cc: In-Reply-To: <00db01c2b81e$5ea693e0$2d91bc3e@tom3> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Tom: Tom: Do you mean, "Excludes at least some of the AS numbers"? Sue Hares At 08:33 PM 1/9/2003 +0000, Tom Petch wrote: >In 5.1.6, ATOMIC_AGGREGATE MUST be included if the AS_PATH >of the aggregated route excludes at least some of the AS >numbers present in the AS_PATHs of the routes that are >aggregated. > >In 9.1.4, if a BGP speaker chooses to aggregate, then it >MUST add ATOMIC_AGGREGATE attribute to the route ie >ATOMIC_AGGREGATE will be present in every aggregate >regardless of whether or not an AS number is no longer in >the AS-PATH. > >Is this really what is meant? > > >Tom Petch, Network Consultant >nwnetworks@dial.pipex.com >+(44) 192 575 3018 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 OAA16121 for ; Fri, 11 Jan 2002 14:05:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B78C09129C; Fri, 11 Jan 2002 14:04:42 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B42B9129D; Fri, 11 Jan 2002 14:04: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 4A71F9129C for ; Fri, 11 Jan 2002 14:04:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2B38C5DD93; Fri, 11 Jan 2002 14:04:41 -0500 (EST) Delivered-To: idr@merit.edu Received: from snowstorm.mail.pipex.net (snowstorm.mail.pipex.net [158.43.192.97]) by segue.merit.edu (Postfix) with SMTP id B7D4E5DD90 for ; Fri, 11 Jan 2002 14:04:40 -0500 (EST) Received: (qmail 1230 invoked from network); 11 Jan 2002 19:04:32 -0000 Received: from useraq73.uk.uudial.com (HELO tom3) (62.188.136.133) by smtp-6.dial.pipex.com with SMTP; 11 Jan 2002 19:04:32 -0000 Message-ID: <00c301c2b9a4$323e1620$2a8ebc3e@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: Subject: Fw: bgp4-17 Section 9 Date: Sat, 11 Jan 2003 19:02:22 -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 ----Original Message----- From: Alex Zinin To: Tom Petch Cc: idr@merit.edu Date: 11 January 2002 17:17 Subject: Re: bgp4-17 Section 9 [edited] >> >> Resolvability talks of routing table entries for IGP and >> directly connected networks; for consistency with 3.2, I >> would like to see static in there as well. > >I actually thought about it when writing this text, but >it fell out of my head. How about this: > > BGP routes do not refer to interfaces, but can be resolved through > the routes in the Routing Table that can be of both types. IGP routes > and routes to directly connected networks are expected to specify the > outbound interface. Static routes can specify the outbound > interface, or the intermediate address, or both. Yes I like the additional sentence. One final tweak could be to amend > the routes in the Routing Table that can be of both types to the routes in the Routing Table which can be of either type > >> 9.1.2.2e Again 5.1.3 impacts on this;should this be >> 'immediate next hop' as opposed to 'next hop' (or NEXT_HOP!) >> and what happens with a recursive lookup? Which of the >> metrics in the various Routing Table entries gets used? >> Perhaps 'The interior cost of a route is the metric in the >> routing table for the immediate next hop (see 5.1.3)' > >In fact, "next hop" should read as NEXT_HOP. The metric >is the IGP cost found in the route resolving the NEXT_HOP. > >Alex. I think recursive lookup - great concept - does make it hard to specify these things in English without getting clumsy. Perhaps we need terminology to differentiate the first from the subsequent from the last entry to be used from the routing table. I think the last is intended here or is it intended to be ambiguous? Tom Petch, Network Consultant nwnetworks@dial.pipex.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 OAA16054 for ; Fri, 11 Jan 2002 14:03:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BE8289129A; Fri, 11 Jan 2002 14:00:24 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85AE69129B; Fri, 11 Jan 2002 14:00:24 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 969E79129A for ; Fri, 11 Jan 2002 14:00:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 678175DDBC; Fri, 11 Jan 2002 14:00:16 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id AA6EF5DDAE for ; Fri, 11 Jan 2002 13:57:58 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0BIvKo49138; Fri, 11 Jan 2002 13:57:20 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020111134444.03e98fd0@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 11 Jan 2002 13:57:18 -0500 To: Enke Chen From: Susan Hares Subject: Re: IDR WG Last Call Cc: Susan Hares , Yakov Rekhter , idr@merit.edu, enke@redback.com In-Reply-To: <20020111180440.5CB8C7E6C1@popserv3.redback.com> References: <5.0.0.25.0.20020111111630.032cf5f0@mail.nexthop.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk At 10:04 AM 1/11/2002 -0800, Enke Chen wrote: >Sue: >As the processing of a UPDATE message (with the same prefix in multiple >fields) is un-specified in the MP spec., there is really nothing to "change" >from. > >-- Enke > > > Message-Id: <5.0.0.25.0.20020111111630.032cf5f0@mail.nexthop.com> > > Date: Fri, 11 Jan 2002 11:20:02 -0500 > > To: Enke Chen > > From: Susan Hares > > Subject: Re: IDR WG Last Call > > Cc: Yakov Rekhter , idr@merit.edu, > > enke@redback.com > > In-Reply-To: <20020110181325.1F29C7E6C1@popserv3.redback.com> > > > > > > Enke: > > > > I don't think this is a clarification, I think this is a change in the > > specification. The original idea was to allow: > > > > Withdraw and announce to withdraw the SAFI: uni,multi in the > MP_UNREACH_NLRI > > filed and to announce it in the NLRI field. > > > > Can you site a technical reason for this change or common practice > > regarding this text? > > > > Sue Hares > > > > > > > > At 10:13 AM 1/10/2002 -0800, Enke Chen wrote: > > >Hi, Yakov: > > >How about we add the following clarification (similar to the one in > the base > > >BGP spec): > > > > > > An UPDATE message should not include the same address prefix (of > the same > > > ) in more than one of the following fields: WITHDRAWN > ROUTES > > > field, Network Reachability Information fields, MP_REACH_NLRI > field, and > > > MP_UNREACH_NLRI field. However a BGP speaker MUST be able to process > > > UPDATE > > > messages in this form. A BGP speaker should treat an UPDATE > message of > > > this > > > form as if that the address prefix were included only in the last > field of > > > the message. > > > > > >Thanks. -- Enke > > > > > > > Message-Id: <200201100131.g0A1Vn658927@merlot.juniper.net> > > > > To: idr@merit.edu > > > > Subject: IDR WG Last Call > > > > MIME-Version: 1.0 > > > > Content-Type: text/plain; charset="us-ascii" > > > > Content-ID: <18652.1010626309.1@juniper.net> > > > > Date: Wed, 09 Jan 2002 17:31:49 -0800 > > > > From: Yakov Rekhter > > > > Sender: owner-idr@merit.edu > > > > Precedence: bulk > > > > > > > > Folks, > > > > > > > > This is to begin the WG Last Call on advancing Multiprotocol > > > > Extensions for BGP-4 to Draft Standard. The Last Call ends > > > > Jan 23, 2002. > > > > > > > > Yakov. > > > > ------- Forwarded Message > > > > > > > > Date: Wed, 09 Jan 2002 16:06:30 -0500 > > > > From: Internet-Drafts@ietf.org > > > > To: IETF-Announce: ; > > > > cc: idr@merit.edu > > > > Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt > > > > > > > > - --NextPart > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > This draft is a work item of the Inter-Domain Routing Working Group of > > > the IETF > > > > . > > > > > > > > Title : Multiprotocol Extensions for BGP-4 > > > > Author(s) : T. Bates et al. > > > > Filename : draft-ietf-idr-rfc2858bis-00.txt > > > > Pages : 10 > > > > Date : 08-Jan-02 > > > > > > > > Currently BGP-4 [BGP-4] is capable of carrying routing information > > > > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to > > > > enable it to carry routing information for multiple Network Layer > > > > protocols (e.g., IPv6, IPX, etc...). The extensions are backward > > > > compatible - a router that supports the extensions can interoperate > > > > with a router that doesn't support the extensions. > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt > > > > > > > > To remove yourself from the IETF Announcement list, send a message to > > > > ietf-announce-request with the word unsubscribe in the body of the > message. > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > > username > > > > "anonymous" and a password of your e-mail address. After logging in, > > > > type "cd internet-drafts" and then > > > > "get draft-ietf-idr-rfc2858bis-00.txt". > > > > > > > > A list of Internet-Drafts directories can be found in > > > > http://www.ietf.org/shadow.html > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > 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 NAA14775 for ; Fri, 11 Jan 2002 13:05:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2396091298; Fri, 11 Jan 2002 13:04:44 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E761591299; Fri, 11 Jan 2002 13:04: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 D7E3091298 for ; Fri, 11 Jan 2002 13:04:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id AFEED5DDE3; Fri, 11 Jan 2002 13:04:41 -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 796405DDD9 for ; Fri, 11 Jan 2002 13:04:41 -0500 (EST) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 9B2B94BA215; Fri, 11 Jan 2002 10:04:40 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 5CB8C7E6C1; Fri, 11 Jan 2002 10:04:40 -0800 (PST) To: Susan Hares Cc: Yakov Rekhter , idr@merit.edu, enke@redback.com Subject: Re: IDR WG Last Call In-Reply-To: Message from Susan Hares of "Fri, 11 Jan 2002 11:20:02 EST." <5.0.0.25.0.20020111111630.032cf5f0@mail.nexthop.com> Date: Fri, 11 Jan 2002 10:04:39 -0800 From: Enke Chen Message-Id: <20020111180440.5CB8C7E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Sue: As the processing of a UPDATE message (with the same prefix in multiple fields) is un-specified in the MP spec., there is really nothing to "change" from. -- Enke > Message-Id: <5.0.0.25.0.20020111111630.032cf5f0@mail.nexthop.com> > Date: Fri, 11 Jan 2002 11:20:02 -0500 > To: Enke Chen > From: Susan Hares > Subject: Re: IDR WG Last Call > Cc: Yakov Rekhter , idr@merit.edu, > enke@redback.com > In-Reply-To: <20020110181325.1F29C7E6C1@popserv3.redback.com> > > > Enke: > > I don't think this is a clarification, I think this is a change in the > specification. The original idea was to allow: > > Withdraw and announce to withdraw the SAFI: uni,multi in the MP_UNREACH_NLRI > filed and to announce it in the NLRI field. > > Can you site a technical reason for this change or common practice > regarding this text? > > Sue Hares > > > > At 10:13 AM 1/10/2002 -0800, Enke Chen wrote: > >Hi, Yakov: > >How about we add the following clarification (similar to the one in the base > >BGP spec): > > > > An UPDATE message should not include the same address prefix (of the same > > ) in more than one of the following fields: WITHDRAWN ROUTES > > field, Network Reachability Information fields, MP_REACH_NLRI field, and > > MP_UNREACH_NLRI field. However a BGP speaker MUST be able to process > > UPDATE > > messages in this form. A BGP speaker should treat an UPDATE message of > > this > > form as if that the address prefix were included only in the last field of > > the message. > > > >Thanks. -- Enke > > > > > Message-Id: <200201100131.g0A1Vn658927@merlot.juniper.net> > > > To: idr@merit.edu > > > Subject: IDR WG Last Call > > > MIME-Version: 1.0 > > > Content-Type: text/plain; charset="us-ascii" > > > Content-ID: <18652.1010626309.1@juniper.net> > > > Date: Wed, 09 Jan 2002 17:31:49 -0800 > > > From: Yakov Rekhter > > > Sender: owner-idr@merit.edu > > > Precedence: bulk > > > > > > Folks, > > > > > > This is to begin the WG Last Call on advancing Multiprotocol > > > Extensions for BGP-4 to Draft Standard. The Last Call ends > > > Jan 23, 2002. > > > > > > Yakov. > > > ------- Forwarded Message > > > > > > Date: Wed, 09 Jan 2002 16:06:30 -0500 > > > From: Internet-Drafts@ietf.org > > > To: IETF-Announce: ; > > > cc: idr@merit.edu > > > Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt > > > > > > - --NextPart > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Inter-Domain Routing Working Group of > > the IETF > > > . > > > > > > Title : Multiprotocol Extensions for BGP-4 > > > Author(s) : T. Bates et al. > > > Filename : draft-ietf-idr-rfc2858bis-00.txt > > > Pages : 10 > > > Date : 08-Jan-02 > > > > > > Currently BGP-4 [BGP-4] is capable of carrying routing information > > > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to > > > enable it to carry routing information for multiple Network Layer > > > protocols (e.g., IPv6, IPX, etc...). The extensions are backward > > > compatible - a router that supports the extensions can interoperate > > > with a router that doesn't support the extensions. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt > > > > > > To remove yourself from the IETF Announcement list, send a message to > > > ietf-announce-request with the word unsubscribe in the body of the message. > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username > > > "anonymous" and a password of your e-mail address. After logging in, > > > type "cd internet-drafts" and then > > > "get draft-ietf-idr-rfc2858bis-00.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > 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 NAA14730 for ; Fri, 11 Jan 2002 13:02:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0A78791297; Fri, 11 Jan 2002 13:01:24 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9D8A91298; Fri, 11 Jan 2002 13:01: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 68F9B91297 for ; Fri, 11 Jan 2002 13:01:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 411F05DDE2; Fri, 11 Jan 2002 13:01:22 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id EC4D05DDD9 for ; Fri, 11 Jan 2002 13:01:21 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0BI0po47491; Fri, 11 Jan 2002 13:00:51 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g0BI0ms14318; Fri, 11 Jan 2002 13:00:48 -0500 (EST) Date: Fri, 11 Jan 2002 13:00:48 -0500 From: Jeffrey Haas To: Tom Petch Cc: idr@merit.edu Subject: Re: bgp4-16 ATOMIC_AGGREGATE Message-ID: <20020111130048.B13903@nexthop.com> References: <00db01c2b81e$5ea693e0$2d91bc3e@tom3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00db01c2b81e$5ea693e0$2d91bc3e@tom3>; from nwnetworks@dial.pipex.com on Thu, Jan 09, 2003 at 08:33:25PM -0000 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Thu, Jan 09, 2003 at 08:33:25PM -0000, Tom Petch wrote: > In 5.1.6, ATOMIC_AGGREGATE MUST be included if the AS_PATH > of the aggregated route excludes at least some of the AS > numbers present in the AS_PATHs of the routes that are > aggregated. Yes. Especially when the path is truncated as is default in certain router vendors. > In 9.1.4, if a BGP speaker chooses to aggregate, then it > MUST add ATOMIC_AGGREGATE attribute to the route ie > ATOMIC_AGGREGATE will be present in every aggregate > regardless of whether or not an AS number is no longer in > the AS-PATH. > > Is this really what is meant? Arguably, it is not necessary to append atomic aggregate if the paths and nexthop are identical. However, there are a lot of other circumstances where appending AA would make sense, but they're messy since they require a great amount of additional overhead. Generally, I consider AA to be not very useful in its current form. > Tom Petch, Network Consultant > nwnetworks@dial.pipex.com > +(44) 192 575 3018 -- 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 MAA14399 for ; Fri, 11 Jan 2002 12:50:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A047391296; Fri, 11 Jan 2002 12:44:06 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63AFE91297; Fri, 11 Jan 2002 12:44: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 C673291296 for ; Fri, 11 Jan 2002 12:44:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id A13075DD8E; Fri, 11 Jan 2002 12:44:03 -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 6B5E85DD8D for ; Fri, 11 Jan 2002 12:44:03 -0500 (EST) Received: from popserv1.redback.com (popserv1.redback.com [155.53.12.56]) by prattle.redback.com (Postfix) with ESMTP id B9D624BA215; Fri, 11 Jan 2002 09:43:52 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv1.redback.com (Postfix) with ESMTP id E34A915D3C1; Fri, 11 Jan 2002 09:43:49 -0800 (PST) To: Susan Hares Cc: Yakov Rekhter , idr@merit.edu, enke@redback.com Subject: Re: IDR WG Last Call In-Reply-To: Message from Susan Hares of "Fri, 11 Jan 2002 11:20:02 EST." <5.0.0.25.0.20020111111630.032cf5f0@mail.nexthop.com> Date: Fri, 11 Jan 2002 09:43:48 -0800 From: Enke Chen Message-Id: <20020111174350.E34A915D3C1@popserv1.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Sue, > Message-Id: <5.0.0.25.0.20020111111630.032cf5f0@mail.nexthop.com> > Date: Fri, 11 Jan 2002 11:20:02 -0500 > To: Enke Chen > From: Susan Hares > Subject: Re: IDR WG Last Call > Cc: Yakov Rekhter , idr@merit.edu, > enke@redback.com > In-Reply-To: <20020110181325.1F29C7E6C1@popserv3.redback.com> > References: > <200201100131.g0A1Vn658927@merlot.juniper.net> > Mime-Version: 1.0 > > Enke: > > I don't think this is a clarification, I think this is a change in the > specification. The original idea was to allow: > > Withdraw and announce to withdraw the SAFI: uni,multi in the MP_UNREACH_NLRI > filed and to announce it in the NLRI field. Could not find it in the spec.. > > Can you site a technical reason for this change or common practice > regarding this text? That is what the widely deployed code does. -- Enke > > Sue Hares > > > > At 10:13 AM 1/10/2002 -0800, Enke Chen wrote: > >Hi, Yakov: > >How about we add the following clarification (similar to the one in the base > >BGP spec): > > > > An UPDATE message should not include the same address prefix (of the same > > ) in more than one of the following fields: WITHDRAWN ROUTES > > field, Network Reachability Information fields, MP_REACH_NLRI field, and > > MP_UNREACH_NLRI field. However a BGP speaker MUST be able to process > > UPDATE > > messages in this form. A BGP speaker should treat an UPDATE message of > > this > > form as if that the address prefix were included only in the last field of > > the message. > > > >Thanks. -- Enke > > > > > Message-Id: <200201100131.g0A1Vn658927@merlot.juniper.net> > > > To: idr@merit.edu > > > Subject: IDR WG Last Call > > > MIME-Version: 1.0 > > > Content-Type: text/plain; charset="us-ascii" > > > Content-ID: <18652.1010626309.1@juniper.net> > > > Date: Wed, 09 Jan 2002 17:31:49 -0800 > > > From: Yakov Rekhter > > > Sender: owner-idr@merit.edu > > > Precedence: bulk > > > > > > Folks, > > > > > > This is to begin the WG Last Call on advancing Multiprotocol > > > Extensions for BGP-4 to Draft Standard. The Last Call ends > > > Jan 23, 2002. > > > > > > Yakov. > > > ------- Forwarded Message > > > > > > Date: Wed, 09 Jan 2002 16:06:30 -0500 > > > From: Internet-Drafts@ietf.org > > > To: IETF-Announce: ; > > > cc: idr@merit.edu > > > Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt > > > > > > - --NextPart > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Inter-Domain Routing Working Group of > > the IETF > > > . > > > > > > Title : Multiprotocol Extensions for BGP-4 > > > Author(s) : T. Bates et al. > > > Filename : draft-ietf-idr-rfc2858bis-00.txt > > > Pages : 10 > > > Date : 08-Jan-02 > > > > > > Currently BGP-4 [BGP-4] is capable of carrying routing information > > > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to > > > enable it to carry routing information for multiple Network Layer > > > protocols (e.g., IPv6, IPX, etc...). The extensions are backward > > > compatible - a router that supports the extensions can interoperate > > > with a router that doesn't support the extensions. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt > > > > > > To remove yourself from the IETF Announcement list, send a message to > > > ietf-announce-request with the word unsubscribe in the body of the message. > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username > > > "anonymous" and a password of your e-mail address. After logging in, > > > type "cd internet-drafts" and then > > > "get draft-ietf-idr-rfc2858bis-00.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > 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 MAA13451 for ; Fri, 11 Jan 2002 12:18:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CC12691286; Fri, 11 Jan 2002 12:17:52 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95C0A91287; Fri, 11 Jan 2002 12:17: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 91BF991286 for ; Fri, 11 Jan 2002 12:17:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 60C755DD8D; Fri, 11 Jan 2002 12:17:51 -0500 (EST) Delivered-To: idr@merit.edu Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id 3060D5DD8C for ; Fri, 11 Jan 2002 12:17:51 -0500 (EST) Received: from mail.nexsi.com (ripper1.nexsi.com [66.35.212.35]) by relay1.nexsi.com (Postfix) with ESMTP id 9DA3A3F65; Fri, 11 Jan 2002 09:20:34 -0800 (PST) Received: from khonsu.sw.nexsi.com (cscovpn4.nexsi.com [172.16.213.4]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id JAA24827; Fri, 11 Jan 2002 09:21:38 -0800 Date: Fri, 11 Jan 2002 09:16:54 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <172687938513.20020111091654@nexsi.com> To: "Tom Petch" Cc: idr@merit.edu Subject: Re: bgp4-17 Section 9 In-Reply-To: <007d01c2b989$a6a6c2c0$c490bc3e@tom3> References: <007d01c2b989$a6a6c2c0$c490bc3e@tom3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Tom, > 9.1.2 Route selection now allows for the best route in > Loc-RIB not to be placed in the Routing table; how does this > impact on the principle (2 Introduction) that a BGP Speaker > should only advertise routes it itself uses? Is it enough > for the route to be in Loc-RIB and not in the Routing Table? The principle implies that the route is both in Loc-RIB and in the routing table, i.e., it needs to be both selected as the best and used by the router. However, we can only specify so much about the routing table, as it is (strictly speaking) outside of the scope of the BGP protocol and administrator do have the "filter" rope in their hands. Section 3.2 also talks about this. > I believe the paragraph on immediate next hop should > cross-reference the one in 5.1.3; and the latter allows > route lookup to resolve to a subnet and not an immediate > next hop address, a possibility 9.1.2 appears not to cater > for. Fine with me. > Perhaps the information on immediate next hop in 5.1.3 and 9 > should be combined in one place; 5.1.3 would be my > preference. Fine with me. > 9.1.2.1 Intermediate network address throws me each time as > I start thinking of networks; I assume that this is the > immediate next hop of Rte1; if so, would not that be > clearer? The address in Rte1 can be either a direct next-hop or a third party next-hop (not really a next hop from the RT perspective). "Intermediate" should account for both cases. > Resolvability talks of routing table entries for IGP and > directly connected networks; for consistency with 3.2, I > would like to see static in there as well. I actually thought about it when writing this text, but it fell out of my head. How about this: BGP routes do not refer to interfaces, but can be resolved through the routes in the Routing Table that can be of both types. IGP routes and routes to directly connected networks are expected to specify the outbound interface. Static routes can specify the outbound interface, or the intermediate address, or both. > 9.1.2.2e Again 5.1.3 impacts on this;should this be > 'immediate next hop' as opposed to 'next hop' (or NEXT_HOP!) > and what happens with a recursive lookup? Which of the > metrics in the various Routing Table entries gets used? > Perhaps 'The interior cost of a route is the metric in the > routing table for the immediate next hop (see 5.1.3)' In fact, "next hop" should read as NEXT_HOP. The metric is the IGP cost found in the route resolving the NEXT_HOP. Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA12659 for ; Fri, 11 Jan 2002 11:53:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A85B591295; Fri, 11 Jan 2002 11:53:04 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8238591296; Fri, 11 Jan 2002 11:53: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 69F2B91295 for ; Fri, 11 Jan 2002 11:53:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F3915DDDC; Fri, 11 Jan 2002 11:53:03 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 0925B5DDAE for ; Fri, 11 Jan 2002 11:53:03 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0BGqno45257 for ; Fri, 11 Jan 2002 11:52:50 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020111114933.03f67b30@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 11 Jan 2002 11:52:47 -0500 To: idr@merit.edu From: Susan Hares Subject: Agenda Items Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk It's time to send agenda items for the March IETF. If you have something you wish to add to the agenda, please let me know. Our agenda is: 1) BGP MIBs 2) Security Document 3) Standardization report for BGP-4 Sue Hares Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA12441 for ; Fri, 11 Jan 2002 11:43:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C49D091294; Fri, 11 Jan 2002 11:43:01 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 902C991295; Fri, 11 Jan 2002 11:43: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 71ECE91294 for ; Fri, 11 Jan 2002 11:43:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 591F65DD97; Fri, 11 Jan 2002 11:43:00 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 1DD715DD8F for ; Fri, 11 Jan 2002 11:43:00 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0BGgho44882; Fri, 11 Jan 2002 11:42:43 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020111114235.03e5fe80@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 11 Jan 2002 11:42:41 -0500 To: Bill Fenner From: Susan Hares Subject: Re: Resending: Re: 2842 to Draft Standard Cc: idr@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk IDR working group: I will be sending out a questionnaire that you can fill out to the working group. As I did prior to the the -17 draft, I will also create a web site. I, Yakov and Bill really encourage you to report your BGP implementations, and any deployment experience on these forms. Sue Hares At 10:16 AM 1/10/2002 -0800, Bill Fenner wrote: >I am re-sending this message to the IDR mailing list since I didn't >see it come through either on the list or in the archives. > >Subject: Re: 2842 to Draft Standard >Date: Tue, 8 Jan 2002 12:01:37 -0800 >To: yakov@juniper.net >Cc: idr@merit.edu > >IDR WG, > > In order to progress to Draft Standard, an implementation report >is required (see section 4.1.2 of RFC 2026). In particular: > > The requirement for at least two independent and interoperable > implementations applies to all of the options and features of the > specification. > >RFC 2842 has several optional portions (e.g. sending Notifications >and whether to include the capability in question in the Notification), >which the implementation report that you included in the original >request did not mention. > > I'd like to see a more complete implementation report. For >example, if vendors don't mind being named: >http://www.ietf.org/IESG/Implementations/IPCOMP-Implementation.txt >or if they don't want to be named: >http://www.ietf.org/IESG/Implementations/AGENTX-IMPLEMENTATION > > Also, the process would go much more smoothly if there was an >Internet-Draft containing the revision, even though it's so small. >The RFC-Editor can supply the nroff of RFC 2842 if the authors >don't still have their source. > > Bill 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 LAA12383 for ; Fri, 11 Jan 2002 11:42:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5150891293; Fri, 11 Jan 2002 11:41:57 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24FF391294; Fri, 11 Jan 2002 11:41:57 -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 F0C5291293 for ; Fri, 11 Jan 2002 11:41:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id D7BDF5DD97; Fri, 11 Jan 2002 11:41:55 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 913295DD8F for ; Fri, 11 Jan 2002 11:41:55 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0BGfio44848; Fri, 11 Jan 2002 11:41:44 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20011128140801.01d63320@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 28 Nov 2001 14:18:50 -0500 To: "Manav Bhatia" From: Susan Hares Subject: Re: draft-ietf-idr-bgp-dpa-04.txt Cc: In-Reply-To: <025a01c177b9$100a2540$b4036c6b@Manav> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Historical At 08:32 AM 11/28/2001 +0530, Manav Bhatia wrote: >Hi, >Can anybody please tell me as to what is the current status of >draft-ietf-idr-bgp-dpa-04.txt ? > >Regards, >Manav > > >_________________________________________________________ >Do You Yahoo!? >Get your free @yahoo.com address at http://mail.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 LAA12349 for ; Fri, 11 Jan 2002 11:41:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C94F891291; Fri, 11 Jan 2002 11:40:31 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F0D991293; Fri, 11 Jan 2002 11:40: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 78A7991291 for ; Fri, 11 Jan 2002 11:40:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 548B15DD97; Fri, 11 Jan 2002 11:40:30 -0500 (EST) Delivered-To: idr@merit.edu Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id 31E645DD8F for ; Fri, 11 Jan 2002 11:40:30 -0500 (EST) Received: from mail.nexsi.com (ripper1.nexsi.com [66.35.212.35]) by relay1.nexsi.com (Postfix) with ESMTP id 4F0BF3F66; Fri, 11 Jan 2002 08:43:13 -0800 (PST) Received: from khonsu.sw.nexsi.com (cscovpn4.nexsi.com [172.16.213.4]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id IAA24585; Fri, 11 Jan 2002 08:44:12 -0800 Date: Fri, 11 Jan 2002 08:39:32 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <6685696749.20020111083932@nexsi.com> To: "Tom Petch" Cc: idr@merit.edu Subject: Re: bgp4-17 5.1.3 immediate next hop In-Reply-To: <007b01c2b989$a54f7020$c490bc3e@tom3> References: <007b01c2b989$a54f7020$c490bc3e@tom3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Tom, I think you might have gotten confused with terms, i.e., what resolves something and what gets resolved. We resolve an address (specifically the address in the NEXT_HOP attribute) to a direct next-hop address. We do this by performing a routing table look up for the address to be resolved. The route that gives us the result is the resolving route. -- Alex Zinin Saturday, January 11, 2003, 6:22:02 AM, Tom Petch wrote: > Each time I read this paragraph I am left wondering if I > really understand it! The use of 'resolving' conveys to me > something on-going and incomplete, surely the opposite of > what is intended. Might I suggest > The NEXT_HOP attribute is used by the BGP speaker to > determine the > actual outbound interface and immediate next-hop address > that should > be used to forward transit packets to the associated > destinations. > The immediate next-hop address is determined by > performing a > recursive route lookup operation for the IP address in > the NEXT_HOP > attribute using the contents of the Routing Table (see > Section > 9.1.2.2). The > *** result of this operation will always will always resolve > the outbound interface and may resolve either the next-hop > address or an attached subnet to be used. If the operation > resolves the next-hop address, this address should be used > as the immediate next-hop address for packet forwarding. If > the operation does not resolve the next-hop address but does > resolve the attached subnet to be used, then the address in > the NEXT_HOP attribute should be used as the immediate > next-hop address. *** > Tom Petch, Network Consultant > nwnetworks@dial.pipex.com > +(44) 192 575 3018 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 LAA12291 for ; Fri, 11 Jan 2002 11:40:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ECE1491292; Fri, 11 Jan 2002 11:38:57 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE9DE91291; Fri, 11 Jan 2002 11:38:56 -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 D7AA591292 for ; Fri, 11 Jan 2002 11:38:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id B0CD45DD98; Fri, 11 Jan 2002 11:38:54 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 5C2285DD8F for ; Fri, 11 Jan 2002 11:38:54 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0BGcNo44690; Fri, 11 Jan 2002 11:38:24 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020111111630.032cf5f0@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 11 Jan 2002 11:20:02 -0500 To: Enke Chen From: Susan Hares Subject: Re: IDR WG Last Call Cc: Yakov Rekhter , idr@merit.edu, enke@redback.com In-Reply-To: <20020110181325.1F29C7E6C1@popserv3.redback.com> References: <200201100131.g0A1Vn658927@merlot.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Enke: I don't think this is a clarification, I think this is a change in the specification. The original idea was to allow: Withdraw and announce to withdraw the SAFI: uni,multi in the MP_UNREACH_NLRI filed and to announce it in the NLRI field. Can you site a technical reason for this change or common practice regarding this text? Sue Hares At 10:13 AM 1/10/2002 -0800, Enke Chen wrote: >Hi, Yakov: >How about we add the following clarification (similar to the one in the base >BGP spec): > > An UPDATE message should not include the same address prefix (of the same > ) in more than one of the following fields: WITHDRAWN ROUTES > field, Network Reachability Information fields, MP_REACH_NLRI field, and > MP_UNREACH_NLRI field. However a BGP speaker MUST be able to process > UPDATE > messages in this form. A BGP speaker should treat an UPDATE message of > this > form as if that the address prefix were included only in the last field of > the message. > >Thanks. -- Enke > > > Message-Id: <200201100131.g0A1Vn658927@merlot.juniper.net> > > To: idr@merit.edu > > Subject: IDR WG Last Call > > MIME-Version: 1.0 > > Content-Type: text/plain; charset="us-ascii" > > Content-ID: <18652.1010626309.1@juniper.net> > > Date: Wed, 09 Jan 2002 17:31:49 -0800 > > From: Yakov Rekhter > > Sender: owner-idr@merit.edu > > Precedence: bulk > > > > Folks, > > > > This is to begin the WG Last Call on advancing Multiprotocol > > Extensions for BGP-4 to Draft Standard. The Last Call ends > > Jan 23, 2002. > > > > Yakov. > > ------- Forwarded Message > > > > Date: Wed, 09 Jan 2002 16:06:30 -0500 > > From: Internet-Drafts@ietf.org > > To: IETF-Announce: ; > > cc: idr@merit.edu > > Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt > > > > - --NextPart > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Inter-Domain Routing Working Group of > the IETF > > . > > > > Title : Multiprotocol Extensions for BGP-4 > > Author(s) : T. Bates et al. > > Filename : draft-ietf-idr-rfc2858bis-00.txt > > Pages : 10 > > Date : 08-Jan-02 > > > > Currently BGP-4 [BGP-4] is capable of carrying routing information > > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to > > enable it to carry routing information for multiple Network Layer > > protocols (e.g., IPv6, IPX, etc...). The extensions are backward > > compatible - a router that supports the extensions can interoperate > > with a router that doesn't support the extensions. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-ietf-idr-rfc2858bis-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > 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 LAA12224 for ; Fri, 11 Jan 2002 11:39:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7ACBA91290; Fri, 11 Jan 2002 11:38:53 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C91E91291; Fri, 11 Jan 2002 11: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 1BF1691290 for ; Fri, 11 Jan 2002 11:38:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id DB4C65DD98; Fri, 11 Jan 2002 11:38:51 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id C1ACC5DD8F for ; Fri, 11 Jan 2002 11:38:51 -0500 (EST) Received: from SKH.nexthop.com ([64.211.218.122]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0BGcKo44686; Fri, 11 Jan 2002 11:38:20 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020111090329.032cffc8@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 11 Jan 2002 09:47:19 -0500 To: Bill Fenner From: Susan Hares Subject: Re: Resending: Re: 2842 to Draft Standard Cc: idr@merit.edu In-Reply-To: <200201101816.KAA05421@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk IDR working group: I will be sending out a questionnaire that you can fill out to the working group. As I did prior to the the -17 draft, I will also create a web site. I, Yakov and Bill really encourage you to report your BGP implementations, and any deployment experience on these forms. Sue Hares At 10:16 AM 1/10/2002 -0800, Bill Fenner wrote: >I am re-sending this message to the IDR mailing list since I didn't >see it come through either on the list or in the archives. > >Subject: Re: 2842 to Draft Standard >Date: Tue, 8 Jan 2002 12:01:37 -0800 >To: yakov@juniper.net >Cc: idr@merit.edu > >IDR WG, > > In order to progress to Draft Standard, an implementation report >is required (see section 4.1.2 of RFC 2026). In particular: > > The requirement for at least two independent and interoperable > implementations applies to all of the options and features of the > specification. > >RFC 2842 has several optional portions (e.g. sending Notifications >and whether to include the capability in question in the Notification), >which the implementation report that you included in the original >request did not mention. > > I'd like to see a more complete implementation report. For >example, if vendors don't mind being named: >http://www.ietf.org/IESG/Implementations/IPCOMP-Implementation.txt >or if they don't want to be named: >http://www.ietf.org/IESG/Implementations/AGENTX-IMPLEMENTATION > > Also, the process would go much more smoothly if there was an >Internet-Draft containing the revision, even though it's so small. >The RFC-Editor can supply the nroff of RFC 2842 if the authors >don't still have their source. > > Bill 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 LAA12015 for ; Fri, 11 Jan 2002 11:30:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 659AD9128F; Fri, 11 Jan 2002 11:29:59 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 313AF91290; Fri, 11 Jan 2002 11:29:59 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 398619128F for ; Fri, 11 Jan 2002 11:29:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 118D35DF0D; Fri, 11 Jan 2002 11:29:58 -0500 (EST) Delivered-To: idr@merit.edu Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id D53315DF09 for ; Fri, 11 Jan 2002 11:29:57 -0500 (EST) Received: from mail.nexsi.com (ripper1.nexsi.com [66.35.212.35]) by relay1.nexsi.com (Postfix) with ESMTP id 10CF23F65; Fri, 11 Jan 2002 08:32:41 -0800 (PST) Received: from khonsu.sw.nexsi.com (cscovpn4.nexsi.com [172.16.213.4]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id IAA24475; Fri, 11 Jan 2002 08:33:44 -0800 Date: Fri, 11 Jan 2002 08:29:04 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <140685068856.20020111082904@nexsi.com> To: "Tom Petch" Cc: idr@merit.edu Subject: Re: bgp4-17 5.1.3 NEXT_HOP attribute determination In-Reply-To: <001e01c2b978$fa384140$c490bc3e@tom3> References: <001e01c2b978$fa384140$c490bc3e@tom3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Tom, > I think that there is a problem with logic and terminology > in the determination of NEXT_HOP. There are four cases > listed, > - a form of "third party" NEXT_HOP attribute > - a second form of "third party" NEXT_HOP attribute > - "first party" NEXT_HOP attribute > - by default > and respectively the BGP speaker > - can use > - can use > - may use > - should use > which seems inconsistent; I would prefer SHOULD. Since use of third party next hops is an optimization by nature and does not *have* to be implemented, and given that "should" is used for the default, I think "may/can" is ok. If we change the optional cases to "should" to increase the level on insistence, we should do the same to the default case and make it a must. If you ask me, I think we're all right now. > But logically, the first party (common subnet) overlaps the > two third parties (common subnet with IBGP or locally > originated and common subnet with EBGP) which obviates > SHOULD. We know how to deal with overlapping cases already--- the more specific one wins. Same here---third party cases are more specific in their description. I guess it might be clearer if we changed "-if -if" to "-if -otherwise if". > And what does locally originated actually mean? It means that the route was not received from another BGP peer and was created by the guy we're talking about. > Presumably IGP and static except that the subsequent use of > internal router does not quite match that. > I wonder if it would be clearer if the focus was on the > common subnet rather than where the route came from. Can eg > the third party cases be combined as > 'if the external peer X shares a common subnet with the > immediate next hop that the BGP speaker itself has installed > in its routing table for this route, then the speaker SHOULD > use this immediate next hop in the NEXT_HOP attribute' When I changed this text to what it is now, I tried to preserve the spirit of the old one, and keep some "educational" info. I think both ways are fine and functionally equivalent, it is more a question of preference. So, I guess my vote is to stet it :) Alex. Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA11018 for ; Fri, 11 Jan 2002 10:56:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 306E49128A; Fri, 11 Jan 2002 10:54:45 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8A1D9128E; Fri, 11 Jan 2002 10:54: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 65BCD9128A for ; Fri, 11 Jan 2002 10:54:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9236C5DF50; Fri, 11 Jan 2002 10:54:37 -0500 (EST) Delivered-To: idr@merit.edu Received: from hose.mail.pipex.net (hose.mail.pipex.net [158.43.128.58]) by segue.merit.edu (Postfix) with SMTP id CD9E45DF4F for ; Fri, 11 Jan 2002 10:54:36 -0500 (EST) Received: (qmail 8345 invoked from network); 11 Jan 2002 15:54:28 -0000 Received: from useraq84.uk.uudial.com (HELO tom3) (62.188.136.144) by smtp-4.dial.pipex.com with SMTP; 11 Jan 2002 15:54:28 -0000 Message-ID: <007b01c2b989$a54f7020$c490bc3e@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: Subject: bgp4-17 5.1.3 immediate next hop Date: Sat, 11 Jan 2003 14:22:02 -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 Each time I read this paragraph I am left wondering if I really understand it! The use of 'resolving' conveys to me something on-going and incomplete, surely the opposite of what is intended. Might I suggest The NEXT_HOP attribute is used by the BGP speaker to determine the actual outbound interface and immediate next-hop address that should be used to forward transit packets to the associated destinations. The immediate next-hop address is determined by performing a recursive route lookup operation for the IP address in the NEXT_HOP attribute using the contents of the Routing Table (see Section 9.1.2.2). The *** result of this operation will always will always resolve the outbound interface and may resolve either the next-hop address or an attached subnet to be used. If the operation resolves the next-hop address, this address should be used as the immediate next-hop address for packet forwarding. If the operation does not resolve the next-hop address but does resolve the attached subnet to be used, then the address in the NEXT_HOP attribute should be used as the immediate next-hop address. *** Tom Petch, Network Consultant nwnetworks@dial.pipex.com +(44) 192 575 3018 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 KAA11012 for ; Fri, 11 Jan 2002 10:56:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2636F91288; Fri, 11 Jan 2002 10:54:45 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2CD839128F; Fri, 11 Jan 2002 10:54: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 7F36A9128B for ; Fri, 11 Jan 2002 10:54:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id AFF325DF4F; Fri, 11 Jan 2002 10:54:37 -0500 (EST) Delivered-To: idr@merit.edu Received: from hose.mail.pipex.net (hose.mail.pipex.net [158.43.128.58]) by segue.merit.edu (Postfix) with SMTP id E855C5DF4B for ; Fri, 11 Jan 2002 10:54:36 -0500 (EST) Received: (qmail 8341 invoked from network); 11 Jan 2002 15:54:27 -0000 Received: from useraq84.uk.uudial.com (HELO tom3) (62.188.136.144) by smtp-4.dial.pipex.com with SMTP; 11 Jan 2002 15:54:27 -0000 Message-ID: <007a01c2b989$a4753cc0$c490bc3e@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: Subject: AS4bytes old and new Date: Sat, 11 Jan 2003 14:10:35 -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 Near me is a town called Newtown; reasonable as it is only 700 years old :-) but it does confuse people even after all these years. I think the use of Old and New in the 4byte AS draft will cause similar confusion in the not too distant future and we should come up with an absolute term to differentiate them rather than a relative term that may soon be obsolete. If you want to see an example of how not to do it, look at SCSI terminology; narrow, wide, ultra-wide, ultra2, really wide, ultra160, ... Tom Petch, Network Consultant nwnetworks@dial.pipex.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 KAA10993 for ; Fri, 11 Jan 2002 10:55:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B708C9128D; Fri, 11 Jan 2002 10:54:40 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 560D491288; Fri, 11 Jan 2002 10:54: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 CF95E91289 for ; Fri, 11 Jan 2002 10:54:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id A49655DF4B; Fri, 11 Jan 2002 10:54:36 -0500 (EST) Delivered-To: idr@merit.edu Received: from hose.mail.pipex.net (hose.mail.pipex.net [158.43.128.58]) by segue.merit.edu (Postfix) with SMTP id CC65C5DF4F for ; Fri, 11 Jan 2002 10:54:35 -0500 (EST) Received: (qmail 8360 invoked from network); 11 Jan 2002 15:54:31 -0000 Received: from useraq84.uk.uudial.com (HELO tom3) (62.188.136.144) by smtp-4.dial.pipex.com with SMTP; 11 Jan 2002 15:54:31 -0000 Message-ID: <007d01c2b989$a6a6c2c0$c490bc3e@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: Subject: bgp4-17 Section 9 Date: Sat, 11 Jan 2003 15:53:01 -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 9.1.2 Route selection now allows for the best route in Loc-RIB not to be placed in the Routing table; how does this impact on the principle (2 Introduction) that a BGP Speaker should only advertise routes it itself uses? Is it enough for the route to be in Loc-RIB and not in the Routing Table? I believe the paragraph on immediate next hop should cross-reference the one in 5.1.3; and the latter allows route lookup to resolve to a subnet and not an immediate next hop address, a possibility 9.1.2 appears not to cater for. Perhaps the information on immediate next hop in 5.1.3 and 9 should be combined in one place; 5.1.3 would be my preference. 9.1.2.1 Intermediate network address throws me each time as I start thinking of networks; I assume that this is the immediate next hop of Rte1; if so, would not that be clearer? Resolvability talks of routing table entries for IGP and directly connected networks; for consistency with 3.2, I would like to see static in there as well. 9.1.2.2e Again 5.1.3 impacts on this;should this be 'immediate next hop' as opposed to 'next hop' (or NEXT_HOP!) and what happens with a recursive lookup? Which of the metrics in the various Routing Table entries gets used? Perhaps 'The interior cost of a route is the metric in the routing table for the immediate next hop (see 5.1.3)' Tom Petch, Network Consultant nwnetworks@dial.pipex.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 KAA10979 for ; Fri, 11 Jan 2002 10:55:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8026991289; Fri, 11 Jan 2002 10:54:40 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EAD8F9128C; Fri, 11 Jan 2002 10:54: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 BF51B91288 for ; Fri, 11 Jan 2002 10:54:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8CC395DF50; Fri, 11 Jan 2002 10:54:36 -0500 (EST) Delivered-To: idr@merit.edu Received: from hose.mail.pipex.net (hose.mail.pipex.net [158.43.128.58]) by segue.merit.edu (Postfix) with SMTP id CA8035DF4B for ; Fri, 11 Jan 2002 10:54:35 -0500 (EST) Received: (qmail 8351 invoked from network); 11 Jan 2002 15:54:29 -0000 Received: from useraq84.uk.uudial.com (HELO tom3) (62.188.136.144) by smtp-4.dial.pipex.com with SMTP; 11 Jan 2002 15:54:29 -0000 Message-ID: <007c01c2b989$a60811c0$c490bc3e@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: Subject: bgp4-17 Cease subcode Date: Sat, 11 Jan 2003 15:48:06 -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 believe there should be a Cease sub-code to differentiate the case where the upper bound on the number of acceptable address prefixes is exceeded. If not, then the recipient of the Cease could assume this is due to some other transient, re-establish the connection and repeat the process ad infinitum. Tom Petch, Network Consultant nwnetworks@dial.pipex.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 KAA10391 for ; Fri, 11 Jan 2002 10:31:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 47A1391223; Fri, 11 Jan 2002 10:30:54 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 095AC91285; Fri, 11 Jan 2002 10:30: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 1568491223 for ; Fri, 11 Jan 2002 10:30:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id E74655DE42; Fri, 11 Jan 2002 10:30:52 -0500 (EST) Delivered-To: idr@merit.edu Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id C45945DE01 for ; Fri, 11 Jan 2002 10:30:52 -0500 (EST) Received: from mail.nexsi.com (ripper1.nexsi.com [66.35.212.35]) by relay1.nexsi.com (Postfix) with ESMTP id 440CF3F65; Fri, 11 Jan 2002 07:33:15 -0800 (PST) Received: from khonsu.sw.nexsi.com (cscovpn4.nexsi.com [172.16.213.4]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id HAA24166; Fri, 11 Jan 2002 07:34:17 -0800 Date: Fri, 11 Jan 2002 07:29:36 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <177681502298.20020111072936@nexsi.com> To: "Tom Petch" Cc: idr@merit.edu Subject: Re: bgp4-17 LOCAL_PREF In-Reply-To: <001d01c2b978$f97f9fa0$c490bc3e@tom3> References: <001d01c2b978$f97f9fa0$c490bc3e@tom3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk A "see section 5.1.5" instead of "disallowed" in the table before 5.1 should do the trick. -- Alex Zinin Saturday, January 11, 2003, 4:56:35 AM, Tom Petch wrote: > Section 5 states that LOCAL_PREF is disallowed for EBGP; > section 5.1.5 allows it for external peers as part of BGP > Confederations. > I think that Section 5 needs qualifying > Tom Petch, Network Consultant > nwnetworks@dial.pipex.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 IAA07751 for ; Fri, 11 Jan 2002 08:56:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1099191284; Fri, 11 Jan 2002 08:55:52 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9DCC91285; Fri, 11 Jan 2002 08:55: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 78D6D91284 for ; Fri, 11 Jan 2002 08:55:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 40CFB5DEC4; Fri, 11 Jan 2002 08:55:27 -0500 (EST) Delivered-To: idr@merit.edu Received: from hose.mail.pipex.net (hose.mail.pipex.net [158.43.128.58]) by segue.merit.edu (Postfix) with SMTP id 806915DEC9 for ; Fri, 11 Jan 2002 08:55:26 -0500 (EST) Received: (qmail 13253 invoked from network); 11 Jan 2002 13:55:09 -0000 Received: from userbl89.uk.uudial.com (HELO tom3) (62.188.144.196) by smtp-4.dial.pipex.com with SMTP; 11 Jan 2002 13:55:09 -0000 Message-ID: <001e01c2b978$fa384140$c490bc3e@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: Subject: bgp4-17 5.1.3 NEXT_HOP attribute determination Date: Sat, 11 Jan 2003 13:48:10 -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 think that there is a problem with logic and terminology in the determination of NEXT_HOP. There are four cases listed, - a form of "third party" NEXT_HOP attribute - a second form of "third party" NEXT_HOP attribute - "first party" NEXT_HOP attribute - by default and respectively the BGP speaker - can use - can use - may use - should use which seems inconsistent; I would prefer SHOULD. But logically, the first party (common subnet) overlaps the two third parties (common subnet with IBGP or locally originated and common subnet with EBGP) which obviates SHOULD. And what does locally originated actually mean? Presumably IGP and static except that the subsequent use of internal router does not quite match that. I wonder if it would be clearer if the focus was on the common subnet rather than where the route came from. Can eg the third party cases be combined as 'if the external peer X shares a common subnet with the immediate next hop that the BGP speaker itself has installed in its routing table for this route, then the speaker SHOULD use this immediate next hop in the NEXT_HOP attribute' Tom Petch, Network Consultant nwnetworks@dial.pipex.com Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA07744 for ; Fri, 11 Jan 2002 08:56:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0157191283; Fri, 11 Jan 2002 08:55:39 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF0BB91284; Fri, 11 Jan 2002 08:55: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 7A3EE91283 for ; Fri, 11 Jan 2002 08:55:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id D8BED5DECE; Fri, 11 Jan 2002 08:55:26 -0500 (EST) Delivered-To: idr@merit.edu Received: from hose.mail.pipex.net (hose.mail.pipex.net [158.43.128.58]) by segue.merit.edu (Postfix) with SMTP id 721BE5DEC4 for ; Fri, 11 Jan 2002 08:55:26 -0500 (EST) Received: (qmail 13248 invoked from network); 11 Jan 2002 13:55:08 -0000 Received: from userbl89.uk.uudial.com (HELO tom3) (62.188.144.196) by smtp-4.dial.pipex.com with SMTP; 11 Jan 2002 13:55:08 -0000 Message-ID: <001d01c2b978$f97f9fa0$c490bc3e@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: Subject: bgp4-17 LOCAL_PREF Date: Sat, 11 Jan 2003 12:56:35 -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 Section 5 states that LOCAL_PREF is disallowed for EBGP; section 5.1.5 allows it for external peers as part of BGP Confederations. I think that Section 5 needs qualifying Tom Petch, Network Consultant nwnetworks@dial.pipex.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 WAA23275 for ; Thu, 10 Jan 2002 22:13:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CE25A91272; Thu, 10 Jan 2002 22:12:50 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99E4B9127A; Thu, 10 Jan 2002 22:12: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 755AE91272 for ; Thu, 10 Jan 2002 22:12:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 495275DDFA; Thu, 10 Jan 2002 22:12:49 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 324795DDF1 for ; Thu, 10 Jan 2002 22:12:49 -0500 (EST) Received: from SKH.nexthop.com (gateway3bo.networktwo.net [206.88.0.53]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g0B3C9o19223; Thu, 10 Jan 2002 22:12:10 -0500 (EST) (envelope-from skh@nexthop.com) Message-Id: <5.0.0.25.0.20020110221148.01db6100@mail.nexthop.com> X-Sender: skh@mail.nexthop.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Thu, 10 Jan 2002 22:12:08 -0500 To: Bill Fenner From: Susan Hares Subject: Re: Resending: Re: 2842 to Draft Standard Cc: idr@merit.edu In-Reply-To: <200201101816.KAA05421@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk Bill: You need to be a part of idr-post@merit.edu to send to the list. This cuts out spam. Sue At 10:16 AM 1/10/2002 -0800, Bill Fenner wrote: >I am re-sending this message to the IDR mailing list since I didn't >see it come through either on the list or in the archives. > >Subject: Re: 2842 to Draft Standard >Date: Tue, 8 Jan 2002 12:01:37 -0800 >To: yakov@juniper.net >Cc: idr@merit.edu > >IDR WG, > > In order to progress to Draft Standard, an implementation report >is required (see section 4.1.2 of RFC 2026). In particular: > > The requirement for at least two independent and interoperable > implementations applies to all of the options and features of the > specification. > >RFC 2842 has several optional portions (e.g. sending Notifications >and whether to include the capability in question in the Notification), >which the implementation report that you included in the original >request did not mention. > > I'd like to see a more complete implementation report. For >example, if vendors don't mind being named: >http://www.ietf.org/IESG/Implementations/IPCOMP-Implementation.txt >or if they don't want to be named: >http://www.ietf.org/IESG/Implementations/AGENTX-IMPLEMENTATION > > Also, the process would go much more smoothly if there was an >Internet-Draft containing the revision, even though it's so small. >The RFC-Editor can supply the nroff of RFC 2842 if the authors >don't still have their source. > > Bill 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 NAA09995 for ; Thu, 10 Jan 2002 13:16:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ED5D691242; Thu, 10 Jan 2002 13:16:26 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B713591243; Thu, 10 Jan 2002 13:16: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 456E391242 for ; Thu, 10 Jan 2002 13:16:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1FD5C5DEF8; Thu, 10 Jan 2002 13:16:24 -0500 (EST) Delivered-To: idr@merit.edu Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by segue.merit.edu (Postfix) with ESMTP id F0E205DE7D for ; Thu, 10 Jan 2002 13:16:23 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 7F4BB1E03E for ; Thu, 10 Jan 2002 13:16:23 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id NAA21841 for ; Thu, 10 Jan 2002 13:16:22 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id KAA05421; Thu, 10 Jan 2002 10:16:23 -0800 (PST) Message-Id: <200201101816.KAA05421@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: idr@merit.edu Subject: Resending: Re: 2842 to Draft Standard Date: Thu, 10 Jan 2002 10:16:23 -0800 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-idr@merit.edu Precedence: bulk I am re-sending this message to the IDR mailing list since I didn't see it come through either on the list or in the archives. Subject: Re: 2842 to Draft Standard Date: Tue, 8 Jan 2002 12:01:37 -0800 To: yakov@juniper.net Cc: idr@merit.edu IDR WG, In order to progress to Draft Standard, an implementation report is required (see section 4.1.2 of RFC 2026). In particular: The requirement for at least two independent and interoperable implementations applies to all of the options and features of the specification. RFC 2842 has several optional portions (e.g. sending Notifications and whether to include the capability in question in the Notification), which the implementation report that you included in the original request did not mention. I'd like to see a more complete implementation report. For example, if vendors don't mind being named: http://www.ietf.org/IESG/Implementations/IPCOMP-Implementation.txt or if they don't want to be named: http://www.ietf.org/IESG/Implementations/AGENTX-IMPLEMENTATION Also, the process would go much more smoothly if there was an Internet-Draft containing the revision, even though it's so small. The RFC-Editor can supply the nroff of RFC 2842 if the authors don't still have their source. Bill 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 NAA09913 for ; Thu, 10 Jan 2002 13:13:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 01ED791240; Thu, 10 Jan 2002 13:13:30 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBB8391242; Thu, 10 Jan 2002 13:13: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 C5E9091240 for ; Thu, 10 Jan 2002 13:13:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id A845C5DED2; Thu, 10 Jan 2002 13:13:28 -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 35E2A5DECF for ; Thu, 10 Jan 2002 13:13:28 -0500 (EST) Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id A9E1A1DCC68; Thu, 10 Jan 2002 10:13:27 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 1F29C7E6C1; Thu, 10 Jan 2002 10:13:23 -0800 (PST) To: Yakov Rekhter Cc: idr@merit.edu, enke@redback.com Subject: Re: IDR WG Last Call In-Reply-To: Message from Yakov Rekhter of "Wed, 09 Jan 2002 17:31:49 PST." <200201100131.g0A1Vn658927@merlot.juniper.net> Date: Thu, 10 Jan 2002 10:13:21 -0800 From: Enke Chen Message-Id: <20020110181325.1F29C7E6C1@popserv3.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, Yakov: How about we add the following clarification (similar to the one in the base BGP spec): An UPDATE message should not include the same address prefix (of the same ) in more than one of the following fields: WITHDRAWN ROUTES field, Network Reachability Information fields, MP_REACH_NLRI field, and MP_UNREACH_NLRI field. However a BGP speaker MUST be able to process UPDATE messages in this form. A BGP speaker should treat an UPDATE message of this form as if that the address prefix were included only in the last field of the message. Thanks. -- Enke > Message-Id: <200201100131.g0A1Vn658927@merlot.juniper.net> > To: idr@merit.edu > Subject: IDR WG Last Call > MIME-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Content-ID: <18652.1010626309.1@juniper.net> > Date: Wed, 09 Jan 2002 17:31:49 -0800 > From: Yakov Rekhter > Sender: owner-idr@merit.edu > Precedence: bulk > > Folks, > > This is to begin the WG Last Call on advancing Multiprotocol > Extensions for BGP-4 to Draft Standard. The Last Call ends > Jan 23, 2002. > > Yakov. > ------- Forwarded Message > > Date: Wed, 09 Jan 2002 16:06:30 -0500 > From: Internet-Drafts@ietf.org > To: IETF-Announce: ; > cc: idr@merit.edu > Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt > > - --NextPart > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Inter-Domain Routing Working Group of the IETF > . > > Title : Multiprotocol Extensions for BGP-4 > Author(s) : T. Bates et al. > Filename : draft-ietf-idr-rfc2858bis-00.txt > Pages : 10 > Date : 08-Jan-02 > > Currently BGP-4 [BGP-4] is capable of carrying routing information > only for IPv4 [IPv4]. This document defines extensions to BGP-4 to > enable it to carry routing information for multiple Network Layer > protocols (e.g., IPv6, IPX, etc...). The extensions are backward > compatible - a router that supports the extensions can interoperate > with a router that doesn't support the extensions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-idr-rfc2858bis-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > 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 UAA15585 for ; Wed, 9 Jan 2002 20:38:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 545F891267; Wed, 9 Jan 2002 20:37:54 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 201DC91268; Wed, 9 Jan 2002 20:37: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 EDB7491267 for ; Wed, 9 Jan 2002 20:37:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id BE17E5DE39; Wed, 9 Jan 2002 20:37: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 3B0C05DDF9 for ; Wed, 9 Jan 2002 20:37: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 g0A1bp659252 for ; Wed, 9 Jan 2002 17:37:52 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200201100137.g0A1bp659252@merlot.juniper.net> To: idr@merit.edu Subject: BGP with FSM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20813.1010626671.1@juniper.net> Date: Wed, 09 Jan 2002 17:37:51 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, This is to start WG Last Call on the -17 version of the document. The Last Call ends Jan 23, 2002. Yakov. P.S. As was agree before, we added the FSM description to the document (Many thanks to Sue Hares for providing the text). ------- Forwarded Message Date: Wed, 09 Jan 2002 16:06:18 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: idr@merit.edu Subject: I-D ACTION:draft-ietf-idr-bgp4-17.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : A Border Gateway Protocol 4 (BGP-4) Author(s) : Y. Rekhter, T. Li Filename : draft-ietf-idr-bgp4-17.txt Pages : 66 Date : 08-Jan-02 The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. It is built on experience gained with EGP as defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as described in RFC 1092 [2] and RFC 1093 [3]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-17.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-17.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-17.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020108150854.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-17.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020108150854.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message 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 UAA15402 for ; Wed, 9 Jan 2002 20:32:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A160C91222; Wed, 9 Jan 2002 20:31:52 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6539291267; Wed, 9 Jan 2002 20:31: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 11C4291222 for ; Wed, 9 Jan 2002 20:31:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA3D95DE34; Wed, 9 Jan 2002 20:31:50 -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 569E15DDF9 for ; Wed, 9 Jan 2002 20:31:50 -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 g0A1Vn658927 for ; Wed, 9 Jan 2002 17:31:49 -0800 (PST) (envelope-from yakov@juniper.net) Message-Id: <200201100131.g0A1Vn658927@merlot.juniper.net> To: idr@merit.edu Subject: IDR WG Last Call MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <18652.1010626309.1@juniper.net> Date: Wed, 09 Jan 2002 17:31:49 -0800 From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, This is to begin the WG Last Call on advancing Multiprotocol Extensions for BGP-4 to Draft Standard. The Last Call ends Jan 23, 2002. Yakov. ------- Forwarded Message Date: Wed, 09 Jan 2002 16:06:30 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; cc: idr@merit.edu Subject: I-D ACTION:draft-ietf-idr-rfc2858bis-00.txt - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF . Title : Multiprotocol Extensions for BGP-4 Author(s) : T. Bates et al. Filename : draft-ietf-idr-rfc2858bis-00.txt Pages : 10 Date : 08-Jan-02 Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idr-rfc2858bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-rfc2858bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-rfc2858bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020108150907.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-rfc2858bis-00.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-rfc2858bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020108150907.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message 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 TAA13726 for ; Wed, 9 Jan 2002 19:30:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BE6329123E; Wed, 9 Jan 2002 19:29:50 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A43F91267; Wed, 9 Jan 2002 19:29: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 8C2369123E for ; Wed, 9 Jan 2002 19:29:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 538A85DDC3; Wed, 9 Jan 2002 19:29:49 -0500 (EST) Delivered-To: idr@merit.edu Received: from nova.explosive.net (ns.explosive.net [205.158.174.194]) by segue.merit.edu (Postfix) with ESMTP id B6F185DD98 for ; Wed, 9 Jan 2002 19:29:48 -0500 (EST) Received: from localhost (edc@localhost) by nova.explosive.net (8.9.3/8.9.3) with ESMTP id QAA27893; Wed, 9 Jan 2002 16:33:11 -0800 (PST) Date: Wed, 9 Jan 2002 16:33:11 -0800 (PST) From: Edward Crabbe To: Tom Petch Cc: idr@merit.edu Subject: Re: bgp4-16 'it is critical that' In-Reply-To: <002701c2b822$bd466020$ee89bc3e@tom3> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk > 9.1.2 Phase 2: Route Selection says > > 'It is critical that routers within an AS do not make > conflicting > decisions regarding route selection that would cause > forwarding loops > to occur.' > > Well yes but how does 'it is critical that' stand in the > customary pantheon of MUST, SHALL, MAY etc etc ? > unless you want to remove the ability to apply policy to ibgp sessions, you will end up with the possibility of inconsistant forwarding across; ibgp policy is often used as a traffic engineering tool, and it's removal may irritate some backbone engineers. 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 RAA09985 for ; Wed, 9 Jan 2002 17:09:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C05959123D; Wed, 9 Jan 2002 17:09:09 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9250391268; Wed, 9 Jan 2002 17:09:09 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8806C9123D for ; Wed, 9 Jan 2002 17:09:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5C6275DEA3; Wed, 9 Jan 2002 17:09:08 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 159E15DE8B for ; Wed, 9 Jan 2002 17:09:08 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g09M8co68589; Wed, 9 Jan 2002 17:08:38 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g09M8bn03671; Wed, 9 Jan 2002 17:08:37 -0500 (EST) Date: Wed, 9 Jan 2002 17:08:37 -0500 From: Jeffrey Haas To: Tom Petch Cc: idr@merit.edu Subject: Re: bgp4-16 'it is critical that' Message-ID: <20020109170837.L26498@nexthop.com> References: <002701c2b822$bd466020$ee89bc3e@tom3> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002701c2b822$bd466020$ee89bc3e@tom3>; from nwnetworks@dial.pipex.com on Thu, Jan 09, 2003 at 09:04:41PM -0000 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk I read this as a "may", but only in the sense of "You may mount a loaded shotgun and rig up a trigger mechanism so you can shoot yourself, but it is recommended highly that you don't do this." On Thu, Jan 09, 2003 at 09:04:41PM -0000, Tom Petch wrote: > 9.1.2 Phase 2: Route Selection says > > 'It is critical that routers within an AS do not make > conflicting > decisions regarding route selection that would cause > forwarding loops > to occur.' > > Well yes but how does 'it is critical that' stand in the > customary pantheon of MUST, SHALL, MAY etc etc ? > > Tom Petch, Network Consultant > nwnetworks@dial.pipex.com > +(44) 192 575 3018 > > -- 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 QAA08533 for ; Wed, 9 Jan 2002 16:05:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D163D91261; Wed, 9 Jan 2002 16:05:23 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D38391262; Wed, 9 Jan 2002 16: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 6038491261 for ; Wed, 9 Jan 2002 16:05:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3A28A5DE21; Wed, 9 Jan 2002 16:05:22 -0500 (EST) Delivered-To: idr@merit.edu Received: from snowstorm.mail.pipex.net (snowstorm.mail.pipex.net [158.43.192.97]) by segue.merit.edu (Postfix) with SMTP id 771925DDCA for ; Wed, 9 Jan 2002 16:05:21 -0500 (EST) Received: (qmail 20360 invoked from network); 9 Jan 2002 21:05:19 -0000 Received: from userau36.uk.uudial.com (HELO tom3) (62.188.137.238) by smtp-5.dial.pipex.com with SMTP; 9 Jan 2002 21:05:19 -0000 Message-ID: <002701c2b822$bd466020$ee89bc3e@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: Subject: bgp4-16 'it is critical that' Date: Thu, 9 Jan 2003 21:04:41 -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 9.1.2 Phase 2: Route Selection says 'It is critical that routers within an AS do not make conflicting decisions regarding route selection that would cause forwarding loops to occur.' Well yes but how does 'it is critical that' stand in the customary pantheon of MUST, SHALL, MAY etc etc ? Tom Petch, Network Consultant nwnetworks@dial.pipex.com +(44) 192 575 3018 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 PAA07197 for ; Wed, 9 Jan 2002 15:34:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3EEB39123C; Wed, 9 Jan 2002 15:34:16 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04D7B91261; Wed, 9 Jan 2002 15:34:15 -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 D02549123C for ; Wed, 9 Jan 2002 15:34:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id B247B5DE88; Wed, 9 Jan 2002 15:34:14 -0500 (EST) Delivered-To: idr@merit.edu Received: from typhoon.mail.pipex.net (unknown [158.43.128.27]) by segue.merit.edu (Postfix) with SMTP id E809B5DE9E for ; Wed, 9 Jan 2002 15:34:13 -0500 (EST) Received: (qmail 25414 invoked from network); 9 Jan 2002 20:34:02 -0000 Received: from userau36.uk.uudial.com (HELO tom3) (62.188.137.238) by smtp-2.dial.pipex.com with SMTP; 9 Jan 2002 20:34:02 -0000 Message-ID: <00db01c2b81e$5ea693e0$2d91bc3e@tom3> Reply-To: "Tom Petch" From: "Tom Petch" To: Subject: bgp4-16 ATOMIC_AGGREGATE Date: Thu, 9 Jan 2003 20:33:25 -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 In 5.1.6, ATOMIC_AGGREGATE MUST be included if the AS_PATH of the aggregated route excludes at least some of the AS numbers present in the AS_PATHs of the routes that are aggregated. In 9.1.4, if a BGP speaker chooses to aggregate, then it MUST add ATOMIC_AGGREGATE attribute to the route ie ATOMIC_AGGREGATE will be present in every aggregate regardless of whether or not an AS number is no longer in the AS-PATH. Is this really what is meant? Tom Petch, Network Consultant nwnetworks@dial.pipex.com +(44) 192 575 3018 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 NAA03878 for ; Wed, 9 Jan 2002 13:44:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7280391256; Wed, 9 Jan 2002 13:43:38 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 424E091261; Wed, 9 Jan 2002 13:43: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 3E44591256 for ; Wed, 9 Jan 2002 13:43:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 26FDA5DE69; Wed, 9 Jan 2002 13:43:37 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id D4F995DE66 for ; Wed, 9 Jan 2002 13:43:36 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g09IhFo61402; Wed, 9 Jan 2002 13:43:16 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g09IhFD26897; Wed, 9 Jan 2002 13:43:15 -0500 (EST) Date: Wed, 9 Jan 2002 13:43:15 -0500 From: Jeffrey Haas To: Raghavendran Gururajan Cc: idr@merit.edu Subject: Re: Clarifications reg. draft-ietf-idr-as4bytes-04.txt Message-ID: <20020109134315.F26498@nexthop.com> References: <20020109053851.18443.qmail@mailweb18.rediffmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020109053851.18443.qmail@mailweb18.rediffmail.com>; from raagoo@rediffmail.com on Wed, Jan 09, 2002 at 05:38:51AM -0000 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Wed, Jan 09, 2002 at 05:38:51AM -0000, Raghavendran Gururajan wrote: > But what happens now to the policies based on AS_PATH, > that are configured in the old BGP speaker ? The OLD speakers cannot exactly determine which route has traversed which AS for routes propagated by the NEW BGP speakers. No reasonable policy is possible. The 4-byte space that isn't covered by the 2-byte space is a "black box". If you are a 4-byte speaker, policy on the NEW_AS_PATH will work. As I see more data from groups like CAIDA and previously from IPMA, I think AS adjacency policy is less and less a good idea, especially when it comes to completely excluding routes from eligibility. > Raghavendran. -- 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 NAA03778 for ; Wed, 9 Jan 2002 13:40:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2131A9123B; Wed, 9 Jan 2002 13:40:06 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E33C291256; Wed, 9 Jan 2002 13:40:05 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6F469123B for ; Wed, 9 Jan 2002 13:40:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id B71815DE66; Wed, 9 Jan 2002 13:40:04 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 9FCDF5DE64 for ; Wed, 9 Jan 2002 13:40:04 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g09IdVo61251; Wed, 9 Jan 2002 13:39:31 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g09IdUM26878; Wed, 9 Jan 2002 13:39:30 -0500 (EST) Date: Wed, 9 Jan 2002 13:39:30 -0500 From: Jeffrey Haas To: claus.bauer@tellabs.com Cc: idr@merit.edu Subject: Re: question Message-ID: <20020109133930.D26498@nexthop.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from claus.bauer@tellabs.com on Wed, Jan 09, 2002 at 09:23:53AM -0600 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Wed, Jan 09, 2002 at 09:23:53AM -0600, claus.bauer@tellabs.com wrote: > The route reflector is not > involved in data forwarding so that even if the BGP session to another > router fails, that does not mean that the routes advertised by the route > reflector are not valid any more. Therefore it might make sense to keep > the BGP routes learned by the router from the route reflector even if > the BGP session between both breaks down. > Any comments ? Has there been any related work ? There are similar issues for any element in a reflection mechanism. Route Servers had similar issues. BGP does not propagate the reason why a given route has been withdrawn, only that it has. Even if you passed along that the, for example, transport session has been torn down between the advertising router and the reflector you can't tell why it was done. It could be as simple as it getting shutoff, configuration change, etc. In the cases where loss of a peering session is expected, there are proposed mechanisms such as Graceful Restart that would allow the forwarding path to remain good while the sessions came back up. > Dr. Claus Bauer -- 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 AAA28321 for ; Wed, 9 Jan 2002 00:38:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D646691224; Wed, 9 Jan 2002 00:38:22 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A64D591234; Wed, 9 Jan 2002 00:38: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 0DDF491224 for ; Wed, 9 Jan 2002 00:38:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id E26145DDAE; Wed, 9 Jan 2002 00:38:20 -0500 (EST) Delivered-To: idr@merit.edu Received: from mailweb18.rediffmail.com (unknown [203.199.83.142]) by segue.merit.edu (Postfix) with SMTP id A91525DD95 for ; Wed, 9 Jan 2002 00:38:19 -0500 (EST) Received: (qmail 18444 invoked by uid 510); 9 Jan 2002 05:38:51 -0000 Date: 9 Jan 2002 05:38:51 -0000 Message-ID: <20020109053851.18443.qmail@mailweb18.rediffmail.com> Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 09 Jan 2002 05:38:51 -0000 MIME-Version: 1.0 From: "Raghavendran Gururajan" Reply-To: "Raghavendran Gururajan" To: idr@merit.edu Subject: Clarifications reg. draft-ietf-idr-as4bytes-04.txt Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Sender: owner-idr@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id AAA28321 Hi, Some clarifications regarding "draft-ietf-idr-as4bytes-04.txt". About AS_TRANS: The draft talks about AS_TRANS, reserved 2-octet AS number assigned by IANA. The draft even mentions a scenario where a old BGP speaker is peering with two or more AS that have NEW BGP speakers (section 6). The scenario considers only the route selection based on MED. But what happens now to the policies based on AS_PATH, that are configured in the old BGP speaker ? The OLD speakers cannot exactly determine which route has traversed which AS for routes propagated by the NEW BGP speakers. Also, are there already any implementation (vendor & public domain) of the same to interop with ? Any pointers to the above areas will be helpful and will be appreciated. Regards, Raghavendran. 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 IAA02123 for ; Tue, 8 Jan 2002 08:45:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5F08191203; Tue, 8 Jan 2002 08:44:48 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3306391228; Tue, 8 Jan 2002 08:44: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 2D69E91203 for ; Tue, 8 Jan 2002 08:44:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id F26075DE94; Tue, 8 Jan 2002 08:44:45 -0500 (EST) Delivered-To: idr@merit.edu Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id B62DA5DDCD for ; Tue, 8 Jan 2002 08:44:45 -0500 (EST) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA08334; Tue, 8 Jan 2002 08:44:39 -0500 (EST) Date: Tue, 8 Jan 2002 08:44:39 -0500 (EST) From: Russ White Reply-To: Russ White To: Dong Ha Cc: isp-bgp@isp-bgp.com, idr@merit.edu Subject: Re: what is a different BGP route? In-Reply-To: <20020107201459.4008.qmail@web14911.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk These are different, and will not be aggregated unless the bgp speaker is configured to do so. Russ On Mon, 7 Jan 2002, Dong Ha wrote: > Hello everyone, > > My name is Dong and I'm working on a BGP conformance > test suite. I'm wondering if anyone can tell me if the > two BGP routes below are different from each other. > This information is taken from two different BGP > Update messages from the same source. I only show the > different values. Everything else is the same. Aslo, > when a router receives these two routes, would it > aggregate the route or not? > > Route 1: Community attribute value: 888:4369; NLRI > field value: 192.168.0.0/16 > > Route 2: Community attribute value: 888:8738; NLRI > field value: 192.168.120.0/24 > > Thanks. > > -dong > > > __________________________________________________ > Do You Yahoo!? > Send FREE video emails in Yahoo! Mail! > http://promo.yahoo.com/videomail/ > _____________________________ riw@cisco.com <>< Grace Alone Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA05598 for ; Mon, 7 Jan 2002 15:15:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 108489121A; Mon, 7 Jan 2002 15:15:06 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F4159121B; Mon, 7 Jan 2002 15:15:05 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F5769121A for ; Mon, 7 Jan 2002 15:15:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 75FE55DDA5; Mon, 7 Jan 2002 15:15:02 -0500 (EST) Delivered-To: idr@merit.edu Received: from web14911.mail.yahoo.com (web14911.mail.yahoo.com [216.136.225.249]) by segue.merit.edu (Postfix) with SMTP id 207405DDEC for ; Mon, 7 Jan 2002 15:15:01 -0500 (EST) Message-ID: <20020107201459.4008.qmail@web14911.mail.yahoo.com> Received: from [12.104.224.46] by web14911.mail.yahoo.com via HTTP; Mon, 07 Jan 2002 12:14:59 PST Date: Mon, 7 Jan 2002 12:14:59 -0800 (PST) From: Dong Ha Subject: what is a different BGP route? To: isp-bgp@isp-bgp.com, idr@merit.edu In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk Hello everyone, My name is Dong and I'm working on a BGP conformance test suite. I'm wondering if anyone can tell me if the two BGP routes below are different from each other. This information is taken from two different BGP Update messages from the same source. I only show the different values. Everything else is the same. Aslo, when a router receives these two routes, would it aggregate the route or not? Route 1: Community attribute value: 888:4369; NLRI field value: 192.168.0.0/16 Route 2: Community attribute value: 888:8738; NLRI field value: 192.168.120.0/24 Thanks. -dong __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ 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 NAA03070 for ; Mon, 7 Jan 2002 13:50:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 189A291216; Mon, 7 Jan 2002 13:50:00 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE80291217; Mon, 7 Jan 2002 13:49: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 D470891216 for ; Mon, 7 Jan 2002 13:49:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id A9C115DDEE; Mon, 7 Jan 2002 13:49:58 -0500 (EST) Delivered-To: idr@merit.edu Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 83EE05DDA5 for ; Mon, 7 Jan 2002 13:49:58 -0500 (EST) Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id D570A4BA216; Mon, 7 Jan 2002 10:49:57 -0800 (PST) Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv2.redback.com (Postfix) with ESMTP id EEF79979C1; Mon, 7 Jan 2002 10:49:53 -0800 (PST) To: idr@merit.edu Cc: enke@redback.com Subject: AS_TRAN in draft-ietf-idr-as4bytes-04.txt Date: Mon, 07 Jan 2002 10:49:53 -0800 From: Enke Chen Message-Id: <20020107184955.EEF79979C1@popserv2.redback.com> Sender: owner-idr@merit.edu Precedence: bulk Hi, folks: I have received several messages asking about the value of AS_TRAN as described in the draft. IANA has allocated 23456 for AS_TRAN, though it has not shown up on their web page. -- Enke Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA20323 for ; Mon, 7 Jan 2002 05:48:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C8A6191233; Mon, 7 Jan 2002 05:47:53 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E9EF9124D; Mon, 7 Jan 2002 05:47: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 6DE1591233 for ; Mon, 7 Jan 2002 05:47:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 444855DE0E; Mon, 7 Jan 2002 05:47:52 -0500 (EST) Delivered-To: idr@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id BB7F85DDC4 for ; Mon, 7 Jan 2002 05:47:51 -0500 (EST) Received: from unknown (HELO firewall) (203.200.20.224) by smtp.mail.vip.sc5.yahoo.com with SMTP; 7 Jan 2002 10:47:50 -0000 Message-ID: <037801c19769$1a772260$b4036c6b@Manav> Reply-To: "Manav Bhatia" From: "Manav Bhatia" To: "Katia Linker" , References: <42AB6BE23C29D511831E0002B32024885BDD1D@messenger.radlan.co.il> Subject: Re: Capabilities advertisement in BGP Date: Mon, 7 Jan 2002 16:20:21 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" 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 Before 2858 came out CISCO was using a value of 128 for route refresh messages. So the additional 80 00 is for the CISCO specific routers. They are still using this value for the backward compatibility (my guess!). Manav ----- Original Message ----- From: "Katia Linker" To: ; ; Sent: Monday, January 07, 2002 3:09 PM Subject: Capabilities advertisement in BGP | Hi, | I need your help regards capabilities advertisement as | an Optional parameters in BGP Open message. | When I receives Cisco Open message, I can see in | optional parameters 2 capabilities: | 1) 01 04 00 01 00 01 which describes multiprotocol | extension (RFC 2858) | 2) 80 00 - what does this capability means ??? | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | The whole optonal parameter field looks like this: | 02 06 01 04 00 01 00 01 02 02 80 00 | Please help me !!!!!!!!!!!!!!! | Thanks in advance. | Katya _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.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 FAA19056 for ; Mon, 7 Jan 2002 05:00:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BC90E91213; Mon, 7 Jan 2002 04:59:47 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A45A91232; Mon, 7 Jan 2002 04:59: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 5DB6491213 for ; Mon, 7 Jan 2002 04:59:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 323855DDEE; Mon, 7 Jan 2002 04:59:46 -0500 (EST) Delivered-To: idr@merit.edu Received: from titanium.zebra.org (sdsl-64-139-11-202.dsl.sca.megapath.net [64.139.11.202]) by segue.merit.edu (Postfix) with ESMTP id 5D75E5DD9A for ; Mon, 7 Jan 2002 04:59:45 -0500 (EST) Received: from titanium.zebra.org (IDENT:kunihiro@localhost [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id EAA02871; Mon, 7 Jan 2002 04:00:36 -0500 Date: Mon, 07 Jan 2002 01:00:36 -0800 Message-ID: From: Kunihiro Ishiguro To: Katia Linker Cc: zebra@zebra.org, isp-bgp@isp-bgp.com, idr@merit.edu Subject: Re: [zebra 11779] Capabilities advertisement in BGP In-Reply-To: <42AB6BE23C29D511831E0002B32024885BDD1D@messenger.radlan.co.il> References: <42AB6BE23C29D511831E0002B32024885BDD1D@messenger.radlan.co.il> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.1 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk >I need your help regards capabilities advertisement as >an Optional parameters in BGP Open message. >When I receives Cisco Open message, I can see in >optional parameters 2 capabilities: >1) 01 04 00 01 00 01 which describes multiprotocol > extension (RFC 2858) >2) 80 00 - what does this capability means ??? > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >The whole optonal parameter field looks like this: >02 06 01 04 00 01 00 01 02 02 80 00 >Please help me !!!!!!!!!!!!!!! It is simple. Cisco was using 128 value (and still is using with RFC value 2) for capability code refresh. In Zebra code we defined like this. /* Route refresh capabilities. */ #define CAPABILITY_CODE_REFRESH 2 #define CAPABILITY_CODE_REFRESH_OLD 128 #define CAPABILITY_CODE_REFRESH_LEN 0 So "80 00" Means capability code refresh (old non RFC value) with length 0. I don't recommend to announce it. But for backward compatibility reason Zebra accept it. -- Kunihiro Ishiguro Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA18865 for ; Mon, 7 Jan 2002 04:53:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2EF9D91212; Mon, 7 Jan 2002 04:53:28 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 051FC91213; Mon, 7 Jan 2002 04:53: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 192DE91212 for ; Mon, 7 Jan 2002 04:53:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id E97805DDEE; Mon, 7 Jan 2002 04:53:26 -0500 (EST) Delivered-To: idr@merit.edu Received: from mlry.radlan.co.il (unknown [209.88.194.205]) by segue.merit.edu (Postfix) with ESMTP id 29A995DD9A for ; Mon, 7 Jan 2002 04:53:21 -0500 (EST) Received: by MLRY with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 11:45:40 +0200 Message-ID: <42AB6BE23C29D511831E0002B32024885BDD1D@messenger.radlan.co.il> From: Katia Linker To: zebra@zebra.org, isp-bgp@isp-bgp.com, idr@merit.edu Subject: Capabilities advertisement in BGP Date: Mon, 7 Jan 2002 11:39:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Sender: owner-idr@merit.edu Precedence: bulk Hi, I need your help regards capabilities advertisement as an Optional parameters in BGP Open message. When I receives Cisco Open message, I can see in optional parameters 2 capabilities: 1) 01 04 00 01 00 01 which describes multiprotocol extension (RFC 2858) 2) 80 00 - what does this capability means ??? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The whole optonal parameter field looks like this: 02 06 01 04 00 01 00 01 02 02 80 00 Please help me !!!!!!!!!!!!!!! Thanks in advance. Katya 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 OAA20958 for ; Fri, 4 Jan 2002 14:26:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 236009123C; Fri, 4 Jan 2002 14:25:38 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E383E91271; Fri, 4 Jan 2002 14:25: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 B4AB49123C for ; Fri, 4 Jan 2002 14:25:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 95EDC5DE4E; Fri, 4 Jan 2002 14:25:36 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 4F21A5DE4C for ; Fri, 4 Jan 2002 14:25:36 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g04JPJo50972; Fri, 4 Jan 2002 14:25:19 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g04JPIr21168; Fri, 4 Jan 2002 14:25:18 -0500 (EST) Date: Fri, 4 Jan 2002 14:25:18 -0500 From: Jeffrey Haas To: "Chang, Ellen" Cc: "'idr@merit.edu'" Subject: Re: Need clarification on BGP4 specifications Message-ID: <20020104142518.B19455@nexthop.com> References: <8AC36D3167EED41184C800508BD95405013311A5@apollo.adtech-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8AC36D3167EED41184C800508BD95405013311A5@apollo.adtech-inc.com>; from Ellen.Chang@SpirentCom.COM on Fri, Jan 04, 2002 at 08:28:55AM -1000 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Fri, Jan 04, 2002 at 08:28:55AM -1000, Chang, Ellen wrote: > ***** What if the AFI indicate IPv6 address in MP Reachable NLRI? Would the > system B advertise to the system C or not? RFC 2858, section 7. > Ellen -- 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 NAA19120 for ; Fri, 4 Jan 2002 13:23:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1D25191239; Fri, 4 Jan 2002 13:23:15 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E151191271; Fri, 4 Jan 2002 13:23:14 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7BAF491239 for ; Fri, 4 Jan 2002 13:23:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4872F5DDCF; Fri, 4 Jan 2002 13:23:13 -0500 (EST) Delivered-To: idr@merit.edu Received: from Thor.Adtech-Inc.COM (Thor.Adtech-Inc.COM [63.165.80.10]) by segue.merit.edu (Postfix) with ESMTP id A27DF5DD98 for ; Fri, 4 Jan 2002 13:23:12 -0500 (EST) Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.12.1/8.12.1) with ESMTP id g04IN69E023031; Fri, 4 Jan 2002 08:23:10 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 08:28:57 -1000 Message-ID: <8AC36D3167EED41184C800508BD95405013311A5@apollo.adtech-inc.com> From: "Chang, Ellen" To: "'Jeffrey Haas'" Cc: "'idr@merit.edu'" Subject: RE: Need clarification on BGP4 specifications Date: Fri, 4 Jan 2002 08:28:55 -1000 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 On Fri, Jan 04, 2002 at 06:20:36AM -1000, Chang, Ellen wrote: > ***** Assume system A, B and C have the MP capabilities, and they are > external peers. > If the system A sends MP Reachable NLRI (AFI indicate IPv4 address) to the > system B, would the system B put MP Reachable NLRI (AFI indicate IPv4 > address) in the regular NLRI field and advertise to the system C? Also, If > the system A sends MP Unreachable NLRI (AFI indicate IPv4 address) to the > system B, would the system B put MP Unreachable NLRI (AFI indicate IPv4 > address) in the regular withdrawn routes field and advertise to the system > C? For IPv4/unicast, putting the information in the non-MP NLRI fields is certainly acceptable. The MPE spec itself is somewhat vague about what happens if you have the same reachability with differing nexthops in the same packet, i.e. reachable NLRI and MP-reachable NLRI that are identical but with different nexthops. ***** What if the AFI indicate IPv6 address in MP Reachable NLRI? Would the system B advertise to the system C or not? Thank you Ellen 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 LAA15586 for ; Fri, 4 Jan 2002 11:28:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 632B291256; Fri, 4 Jan 2002 11:27:38 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3920891271; Fri, 4 Jan 2002 11:27: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 045FE91256 for ; Fri, 4 Jan 2002 11:27:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id D6F075DE4C; Fri, 4 Jan 2002 11:27:36 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 9202E5DE49 for ; Fri, 4 Jan 2002 11:27:36 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g04GR5o44539; Fri, 4 Jan 2002 11:27:06 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g04GR6D17887; Fri, 4 Jan 2002 11:27:06 -0500 (EST) Date: Fri, 4 Jan 2002 11:27:06 -0500 From: Jeffrey Haas To: "Chang, Ellen" Cc: "'idr@merit.edu'" Subject: Re: Need clarification on BGP4 specifications Message-ID: <20020104112706.C17766@nexthop.com> References: <8AC36D3167EED41184C800508BD95405013311A4@apollo.adtech-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8AC36D3167EED41184C800508BD95405013311A4@apollo.adtech-inc.com>; from Ellen.Chang@SpirentCom.COM on Fri, Jan 04, 2002 at 06:20:36AM -1000 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Fri, Jan 04, 2002 at 06:20:36AM -1000, Chang, Ellen wrote: > ***** Assume system A, B and C have the MP capabilities, and they are > external peers. > If the system A sends MP Reachable NLRI (AFI indicate IPv4 address) to the > system B, would the system B put MP Reachable NLRI (AFI indicate IPv4 > address) in the regular NLRI field and advertise to the system C? Also, If > the system A sends MP Unreachable NLRI (AFI indicate IPv4 address) to the > system B, would the system B put MP Unreachable NLRI (AFI indicate IPv4 > address) in the regular withdrawn routes field and advertise to the system > C? For IPv4/unicast, putting the information in the non-MP NLRI fields is certainly acceptable. The MPE spec itself is somewhat vague about what happens if you have the same reachability with differing nexthops in the same packet, i.e. reachable NLRI and MP-reachable NLRI that are identical but with different nexthops. > ****** The FSM indicates that if the system A is in OpenSent state, it is > only allow to receive an Open message, all the other messages will cause it > to close TCP. Also the system A will not transition to Openconfirm state > until it sends a KeepAlive message. The system A just received Open message > from the system B, and haven't process the Open message yet, then it > received KeepAlive message from the system B. So from the system A point of > view, the system B's action violates the FSM. A: Sends Open, State now OpenSent B: Sends Open, State now OpenSent B: Receives A's Open. B: Sends Keepalive. State now OpenConfirm A*: on queue: one open PDU, one keepalive PDU. A: Receives packet, its open. A: Sends keepalive. State now OpenConfirm. A: Receives packet, its keepalive. State now Established. So, keeping in mind *, the only way it knows that it has received a packet is to pull it off the transport stream and look at it. > > Ellen -- 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 LAA15182 for ; Fri, 4 Jan 2002 11:15:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 78A9991218; Fri, 4 Jan 2002 11:15:08 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 075B29123B; Fri, 4 Jan 2002 11:15: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 49EA491218 for ; Fri, 4 Jan 2002 11:15:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 77AFB5DE49; Fri, 4 Jan 2002 11:15:04 -0500 (EST) Delivered-To: idr@merit.edu Received: from Thor.Adtech-Inc.COM (Thor.Adtech-Inc.COM [63.165.80.10]) by segue.merit.edu (Postfix) with ESMTP id 3AD755DDAB for ; Fri, 4 Jan 2002 11:15:03 -0500 (EST) Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.12.1/8.12.1) with ESMTP id g04GEl9E016558; Fri, 4 Jan 2002 06:14:55 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 06:20:38 -1000 Message-ID: <8AC36D3167EED41184C800508BD95405013311A4@apollo.adtech-inc.com> From: "Chang, Ellen" To: "'Jeffrey Haas'" , "Chang, Ellen" Cc: "'idr@merit.edu'" Subject: RE: Need clarification on BGP4 specifications Date: Fri, 4 Jan 2002 06:20:36 -1000 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 On Fri, Jan 04, 2002 at 05:15:32AM -1000, Chang, Ellen wrote: > 1. If two Update message are received back to back, the first Update > message includes 2 IP address prefixes in the NLRI field, the second Update > message withdrawn one of the IP address prefix, how would a BGP speaker > advertise the route to it's external peers? Would the BGP speaker only > advertise the route with the IP address prefix that's not withdrawed? Or, > would the BGP speaker advertise the first Update message first, then > withdraw a route with the second Update message (same as the receiving order > of the Update msgs)? This is implementation dependant. One would hope your implementation, where it can, will minimize churn. So, if you have not, for whatever reason, advertised the prefix that is withdrawn, you shouldn't send it in the first place. This limits the flap to you and doesn't propagate it to your downstream. > 2. The spec indicates ' An UPDATE message that contains correct path > attributes, but no NLRI, > shall be treated as a valid UPDATE message.' > Does it mean that the receiver of this message should advertise to its > peers, because a valid Update message should be advertise to its peers? Implementation dependant. Why would someone do something like this? In the case BGP-MPE, its because NLRI isn't in the traditional fields. Its also possible that just normal path attributes are being passed around to provide additional information, but thats outside the scope of the protocol. > 3. If a system receives a UPDATE message with MP Reachable or Unreachable > NLRI (AFI indicate IPv4 address), would the system propagates/advertises or > withdrawn the MP Reachable or Unreachable NLRI to its peers? The attributes are non-transitive. Additonally, they should only be exchanged if the capabilities are exchanged for them. ***** Assume system A, B and C have the MP capabilities, and they are external peers. If the system A sends MP Reachable NLRI (AFI indicate IPv4 address) to the system B, would the system B put MP Reachable NLRI (AFI indicate IPv4 address) in the regular NLRI field and advertise to the system C? Also, If the system A sends MP Unreachable NLRI (AFI indicate IPv4 address) to the system B, would the system B put MP Unreachable NLRI (AFI indicate IPv4 address) in the regular withdrawn routes field and advertise to the system C? > 4.If system A and B are connected. The system A initiates TCP connection to > system B, then the system A transmits an Open message and waits for an Open > message from the system B. The system B transmits an Open message and a > Keepalive message back to back. Is the system A allow to receive a > Keepalive message when it's still in the OpenSent state, because the system > A has not send KeepAlive message to system B yet for it transition to > OpenConfirm state? But from the system B point of view, it received Open > message from system A and it can send KeepAlive message. Is there a > conflict? There is no conflict. If you examine things from a packet by packet standpoint, the ordering is correct. Considering that BGP is a stream based protocol, this makes sense. :-) ****** The FSM indicates that if the system A is in OpenSent state, it is only allow to receive an Open message, all the other messages will cause it to close TCP. Also the system A will not transition to Openconfirm state until it sends a KeepAlive message. The system A just received Open message from the system B, and haven't process the Open message yet, then it received KeepAlive message from the system B. So from the system A point of view, the system B's action violates the FSM. > Ellen -- 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 KAA14447 for ; Fri, 4 Jan 2002 10:47:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1E32F91238; Fri, 4 Jan 2002 10:47:06 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E26A89123B; Fri, 4 Jan 2002 10:47:05 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 86D6D91238 for ; Fri, 4 Jan 2002 10:47:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5BA2A5DE49; Fri, 4 Jan 2002 10:47:04 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id 13B4B5DDAB for ; Fri, 4 Jan 2002 10:47:04 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g04FkYo43201; Fri, 4 Jan 2002 10:46:34 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g04FkYK17812; Fri, 4 Jan 2002 10:46:34 -0500 (EST) Date: Fri, 4 Jan 2002 10:46:34 -0500 From: Jeffrey Haas To: "Chang, Ellen" Cc: "'idr@merit.edu'" Subject: Re: Need clarification on BGP4 specifications Message-ID: <20020104104634.B17766@nexthop.com> References: <8AC36D3167EED41184C800508BD95405013311A2@apollo.adtech-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8AC36D3167EED41184C800508BD95405013311A2@apollo.adtech-inc.com>; from Ellen.Chang@SpirentCom.COM on Fri, Jan 04, 2002 at 05:15:32AM -1000 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Fri, Jan 04, 2002 at 05:15:32AM -1000, Chang, Ellen wrote: > 1. If two Update message are received back to back, the first Update > message includes 2 IP address prefixes in the NLRI field, the second Update > message withdrawn one of the IP address prefix, how would a BGP speaker > advertise the route to it's external peers? Would the BGP speaker only > advertise the route with the IP address prefix that's not withdrawed? Or, > would the BGP speaker advertise the first Update message first, then > withdraw a route with the second Update message (same as the receiving order > of the Update msgs)? This is implementation dependant. One would hope your implementation, where it can, will minimize churn. So, if you have not, for whatever reason, advertised the prefix that is withdrawn, you shouldn't send it in the first place. This limits the flap to you and doesn't propagate it to your downstream. > 2. The spec indicates ' An UPDATE message that contains correct path > attributes, but no NLRI, > shall be treated as a valid UPDATE message.' > Does it mean that the receiver of this message should advertise to its > peers, because a valid Update message should be advertise to its peers? Implementation dependant. Why would someone do something like this? In the case BGP-MPE, its because NLRI isn't in the traditional fields. Its also possible that just normal path attributes are being passed around to provide additional information, but thats outside the scope of the protocol. > 3. If a system receives a UPDATE message with MP Reachable or Unreachable > NLRI (AFI indicate IPv4 address), would the system propagates/advertises or > withdrawn the MP Reachable or Unreachable NLRI to its peers? The attributes are non-transitive. Additonally, they should only be exchanged if the capabilities are exchanged for them. > 4.If system A and B are connected. The system A initiates TCP connection to > system B, then the system A transmits an Open message and waits for an Open > message from the system B. The system B transmits an Open message and a > Keepalive message back to back. Is the system A allow to receive a > Keepalive message when it's still in the OpenSent state, because the system > A has not send KeepAlive message to system B yet for it transition to > OpenConfirm state? But from the system B point of view, it received Open > message from system A and it can send KeepAlive message. Is there a > conflict? There is no conflict. If you examine things from a packet by packet standpoint, the ordering is correct. Considering that BGP is a stream based protocol, this makes sense. :-) > Ellen -- 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 KAA13351 for ; Fri, 4 Jan 2002 10:13:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3814191273; Fri, 4 Jan 2002 10:09:52 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E733091272; Fri, 4 Jan 2002 10:09: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 61CB89123B for ; Fri, 4 Jan 2002 10:09:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3DCE45DE47; Fri, 4 Jan 2002 10:09:44 -0500 (EST) Delivered-To: idr@merit.edu Received: from Thor.Adtech-Inc.COM (Thor.Adtech-Inc.COM [63.165.80.10]) by segue.merit.edu (Postfix) with ESMTP id 993A05DDAB for ; Fri, 4 Jan 2002 10:09:43 -0500 (EST) Received: from apollo.adtech-inc.com (apollo.adtech-inc.com [10.12.0.17]) by Thor.Adtech-Inc.COM (8.12.1/8.12.1) with ESMTP id g04F9g9E013276 for ; Fri, 4 Jan 2002 05:09:43 -1000 (HST) Received: by apollo.adtech-inc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 05:15:33 -1000 Message-ID: <8AC36D3167EED41184C800508BD95405013311A2@apollo.adtech-inc.com> From: "Chang, Ellen" To: "'idr@merit.edu'" Subject: Need clarification on BGP4 specifications Date: Fri, 4 Jan 2002 05:15:32 -1000 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: I am resending few questions on BGP4. Can anyone clarify them for me? 1. If two Update message are received back to back, the first Update message includes 2 IP address prefixes in the NLRI field, the second Update message withdrawn one of the IP address prefix, how would a BGP speaker advertise the route to it's external peers? Would the BGP speaker only advertise the route with the IP address prefix that's not withdrawed? Or, would the BGP speaker advertise the first Update message first, then withdraw a route with the second Update message (same as the receiving order of the Update msgs)? 2. The spec indicates ' An UPDATE message that contains correct path attributes, but no NLRI, shall be treated as a valid UPDATE message.' Does it mean that the receiver of this message should advertise to its peers, because a valid Update message should be advertise to its peers? 3. If a system receives a UPDATE message with MP Reachable or Unreachable NLRI (AFI indicate IPv4 address), would the system propagates/advertises or withdrawn the MP Reachable or Unreachable NLRI to its peers? 4.If system A and B are connected. The system A initiates TCP connection to system B, then the system A transmits an Open message and waits for an Open message from the system B. The system B transmits an Open message and a Keepalive message back to back. Is the system A allow to receive a Keepalive message when it's still in the OpenSent state, because the system A has not send KeepAlive message to system B yet for it transition to OpenConfirm state? But from the system B point of view, it received Open message from system A and it can send KeepAlive message. Is there a conflict? Thank you very much Ellen 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 LAA08666 for ; Thu, 3 Jan 2002 11:21:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7248D91221; Thu, 3 Jan 2002 11:20:56 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 423879122B; Thu, 3 Jan 2002 11:20:56 -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 3C02691221 for ; Thu, 3 Jan 2002 11:20:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1019F5DDE8; Thu, 3 Jan 2002 11:20:55 -0500 (EST) Delivered-To: idr@merit.edu Received: from presque.djinesys.com (presque.djinesys.com [198.108.88.2]) by segue.merit.edu (Postfix) with ESMTP id E75C35DDE3 for ; Thu, 3 Jan 2002 11:20:54 -0500 (EST) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g03GKPo00836; Thu, 3 Jan 2002 11:20:25 -0500 (EST) (envelope-from jhaas@nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.0/8.11.0) id g03GKOT14204; Thu, 3 Jan 2002 11:20:24 -0500 (EST) Date: Thu, 3 Jan 2002 11:20:24 -0500 From: Jeffrey Haas To: Anand Kumar Goenka Cc: idr@merit.edu Subject: Re: ATOMIC AGGREGATE Doubts Message-ID: <20020103112024.A14039@nexthop.com> References: <3C276E61.88B4BC4F@miel.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C276E61.88B4BC4F@miel.mot.com>; from anandkg@miel.mot.com on Mon, Dec 24, 2001 at 11:35:21PM +0530 X-NextHop-MailScanner: Found to be clean Sender: owner-idr@merit.edu Precedence: bulk On Mon, Dec 24, 2001 at 11:35:21PM +0530, Anand Kumar Goenka wrote: > I have some basic doubts regarding "ATOMIC AGGREGATE" attribute of BGP > as > mentioned in RFC1771. > > Consider a case where a BGP speaker receives following overlapping > routes from one of > it's peers as follows. > 150.1.0.0/16 - Path A > 150.1.1.0/24 - Path B > Local BGP speaker selects the less specific route (150.1.0.0/16) and > advertises it to it's > Peers with ATOMIC AGGREGATE attribute. > > - Does the local BGP speaker adds the ATOMIC AGGREGATE in the Path > Attribute of the less specific route (150.1.0.0/16) and then store > that route in it's > local-RIB or it does so only while advertising the route to it's peers > ?? That's an implementation decision. > - What happens when the less specific routes (150.1.0.0/16) > is withdrawn by the BGP peer which had earlier advertised that route > to local BGP > speaker ?? Does the local BGP speaker need to re-install the more > specific route > (150.1.1.0/24) in the local-RIB and advertised to it's peers ?? > (this is assuming the > local BGP speaker maintains the both less & more specific route in > corresponding > Adj-RIB-In) No. BGP route selection shouldn't be use the presence or absence of other routes as a selection criteria. > - What happens when the more specific routes (150.1.1.0/24) > is withdrawn by the BGP peer which had earlier advertised that route > to local BGP > speaker ?? Does the local BGP speaker need to re-advertise the less > specific route > (150.1.0.0/16) to it's peers without the ATOMIC ATTRIBUTE attribute > ?? Yes, it should. > Thanks, > Anand Goenka. -- 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 RAA11255 for ; Wed, 2 Jan 2002 17:05:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 42A1A91268; Wed, 2 Jan 2002 17:04:53 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 002A39126A; Wed, 2 Jan 2002 17:04: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 0A56B91268 for ; Wed, 2 Jan 2002 17:04:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id E40455DDA8; Wed, 2 Jan 2002 17:04:51 -0500 (EST) Delivered-To: idr@merit.edu Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id C19AF5DDA1 for ; Wed, 2 Jan 2002 17:04:51 -0500 (EST) Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id 8CECF3F6B; Wed, 2 Jan 2002 14:07:27 -0800 (PST) Received: from khonsu.sw.nexsi.com ([172.17.212.34]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id OAA31157; Wed, 2 Jan 2002 14:08:32 -0800 Date: Wed, 2 Jan 2002 14:08:31 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <182529216272.20020102140831@nexsi.com> To: RJ Atkinson Cc: idr@merit.edu Subject: Re: Working Group notes from 12/13/01 meeting In-Reply-To: <5.1.0.14.2.20020102164352.01e26690@10.30.15.3> References: <200112201436.fBKEaZ720223@raven.gw.tislabs.com> <200112201436.fBKEaZ720223@raven.gw.tislabs.com> <5.1.0.14.2.20020102164352.01e26690@10.30.15.3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Wednesday, January 02, 2002, 1:44:52 PM, RJ Atkinson wrote: > It means I am on vacation. An odd thing for me to do > this time of year, I know, but nonetheless there it is. I found myself having done the same odd thing recently. Must be an infection or something :) Alex. P.S. Sorry for an off-topic. 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 QAA11039 for ; Wed, 2 Jan 2002 16:56:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CC5B891234; Wed, 2 Jan 2002 16:55:43 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A271691268; Wed, 2 Jan 2002 16:55: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 79B6591234 for ; Wed, 2 Jan 2002 16:55:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 53EFD5DDA8; Wed, 2 Jan 2002 16:55:32 -0500 (EST) Delivered-To: idr@merit.edu Received: from gnat.inet.org (unknown [63.108.254.91]) by segue.merit.edu (Postfix) with ESMTP id 1DE6B5DDA1 for ; Wed, 2 Jan 2002 16:55:32 -0500 (EST) Received: from mosquito.inet.org (unknown [10.30.20.240]) by gnat.inet.org (Postfix) with ESMTP id 409A56710D; Wed, 2 Jan 2002 17:06:41 -0500 (EST) Message-Id: <5.1.0.14.2.20020102164352.01e26690@10.30.15.3> X-Sender: rja@10.30.15.3 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 02 Jan 2002 16:44:52 -0500 To: Alex Zinin From: RJ Atkinson Subject: Re: Working Group notes from 12/13/01 meeting Cc: idr@merit.edu In-Reply-To: <140515155915.20020102101410@nexsi.com> References: <200112201436.fBKEaZ720223@raven.gw.tislabs.com> <200112201436.fBKEaZ720223@raven.gw.tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idr@merit.edu Precedence: bulk At 13:14 02/01/02, Alex Zinin wrote: >Ran, > > I don't think I've seen you follow up on this. > Does this mean a silent agreement with Sandy? It means I am on vacation. An odd thing for me to do this time of year, I know, but nonetheless there it is. For my part, silence NEVER implies anything other than silence. Ran 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 NAA04513 for ; Wed, 2 Jan 2002 13:11:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9E1ED91216; Wed, 2 Jan 2002 13:10:33 -0500 (EST) Delivered-To: idr-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7026291217; Wed, 2 Jan 2002 13:10:33 -0500 (EST) Delivered-To: idr@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8858391216 for ; Wed, 2 Jan 2002 13:10:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6F3585DE1A; Wed, 2 Jan 2002 13:10:32 -0500 (EST) Delivered-To: idr@merit.edu Received: from relay1.nexsi.com (relay1.nexsi.com [66.35.205.133]) by segue.merit.edu (Postfix) with ESMTP id 4C5D85DDA1 for ; Wed, 2 Jan 2002 13:10:32 -0500 (EST) Received: from mail.nexsi.com (unknown [66.35.212.41]) by relay1.nexsi.com (Postfix) with ESMTP id E6F433F63; Wed, 2 Jan 2002 10:13:07 -0800 (PST) Received: from khonsu.sw.nexsi.com (cscovpn7.nexsi.com [172.16.213.7]) by mail.nexsi.com (8.9.3/8.9.3) with ESMTP id KAA28370; Wed, 2 Jan 2002 10:14:11 -0800 Date: Wed, 2 Jan 2002 10:14:10 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin Organization: Nexsi Systems X-Priority: 3 (Normal) Message-ID: <140515155915.20020102101410@nexsi.com> To: rja@inet.org Cc: skh@nexthop.com, idr@merit.edu, sandy@tislabs.com Subject: Re: Working Group notes from 12/13/01 meeting In-Reply-To: <200112201436.fBKEaZ720223@raven.gw.tislabs.com> References: <200112201436.fBKEaZ720223@raven.gw.tislabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Ran, I don't think I've seen you follow up on this. Does this mean a silent agreement with Sandy? Just like Sue, I'd love to see your analysis. -- Alex Zinin Thursday, December 20, 2001, 6:36:35 AM, sandy@tislabs.com wrote: > According to the crypto folk down the hall, here are some sites that > talk about the general vulnerability of prefix (hash[key,message]), > suffix (hash[message,key]) and even envelope (hash[key1,message,key2]) > techniques, particularly compared to nested keyed crypto-hash > techniques (twistycombination[hash,key,message]). > Rogaway's talk at the 96 RSA Data Security Conference: > http://www.cs.ucdavis.edu/~rogaway/talks/mac-survey-19jan96.ps > Gene Tsudik's paper on Keyed-MD4/5: > http://citeseer.nj.nec.com/tsudik92message.html > Bert Preneel and Paul Van Oorschot's evaluation of Tsudik's approach, > demonstrating the weaknesses of keyed-MD4/5 for the prefix, suffix, and > envelope methods: > http://citeseer.nj.nec.com/preneel95mdxmac.html > and more about the envelope method: > http://citeseer.nj.nec.com/16659.html > Bellare/Canetti/Krawczyk HMAC paper that references Preneel/Oorschot, but > goes beyond by inventing NMACs and HMACs: > http://citeseer.nj.nec.com/bellare96keying.html > Hope this helps :-) (you'll see why the smiley when you look at the papers). > --Sandy > P.S. Slide 22 of the Rogaway talk gives a summary table.