Re: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)

[[e-mail]]

That is what I thought.  It will be updated in the next revision.

Andrew

On Mon, Dec 23, 2002 at 11:10:30PM -0000, Tom Petch wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Reply-To: "Tom Petch" <[e-mail]>
> From: "Tom Petch" <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>, <[e-mail]>
> Subject: Re: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)
> Date: Mon, 23 Dec 2002 23:10:30 -0000
> 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
> Precedence: bulk
> X-Spam-Status: No, hits=0.3 required=6.0
> 	tests=AWL,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,SUBJECT_IS_LIST,
> 	      USER_AGENT_OE
> 	version=2.43
> X-OriginalArrivalTime: 23 Dec 2002 23:11:20.0640 (UTC) FILETIME=[9ACA4400:01C2AAD8]
> 
> Oh dear a typo I do mean 13.5 should go.
> 
> Tom Petch
> [e-mail]
> 
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> To: Tom Petch <[e-mail]>
> Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> Date: 23 December 2002 19:40
> Subject: Re: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)
> 
> 
> >Easy enough to do that.  To clarify, in your last paragraph, do you
> >mean 13.4 should go in addition to 13.5, or was the 13.4 a typo?
> >
> >Andrew
> >
> >On Mon, Dec 23, 2002 at 02:36:26PM +0000, Tom Petch wrote:
> >> Date: Mon, 23 Dec 2002 14:36:26 +0000
> >> From: Tom Petch <[e-mail]>
> >> Subject: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)
> >> To: [e-mail], [e-mail]
> >> Cc: [e-mail]
> >> Reply-to: Tom Petch <[e-mail]>
> >> X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4
> >> X-Mailer: Microsoft Outlook Express 4.72.2106.4
> >> X-Priority: 3
> >> X-MSMail-priority: Normal
> >>
> >> I think this issue SHOULD be administratively terminated.
> >>
> >> It relates to Connect state Event 17 (TCP connection fails) and I
> am
> >> credited with raising it; in fact, the issue I raised was missing
> next
> >> state for Active state event 17 and this has now been subsumed into
> >> 13.4 (but note that 13.4 does not explicitly say Active state - I
> know
> >> it should because I raised that issue too).  I will ensure it does
> not
> >> get lost from any resolution of 13.4.
> >>
> >> And Connect state event 17 does appear as part of issue 45 which
> Siva
> >> raised so I think that either way, 13.4 can go.
> >>
> >> Tom Petch
> >> [e-mail]
> >>



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA01602 for <[e-mail]>; Mon, 23 Dec 2002 18:23:11 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 4799591214; Mon, 23 Dec 2002 18:22:35 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 115F191250; Mon, 23 Dec 2002 18:22:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0733491214 for <[e-mail]>; Mon, 23 Dec 2002 18:22:33 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D638E5DF2F; Mon, 23 Dec 2002 18:22:33 -0500 (EST)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 7AC015DE64 for <[e-mail]>; Mon, 23 Dec 2002 18:22:33 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id PAA24100; Mon, 23 Dec 2002 15:19:24 -0800 (PST)
Date: Mon, 23 Dec 2002 15:19:24 -0800
From: [e-mail]
To: Tom Petch <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)
Message-ID: <[e-mail]>
References: <000e01c2aad8$805f9200$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: <000e01c2aad8$805f9200$0301a8c0@tom3>; from [e-mail] on Mon, Dec 23, 2002 at 11:10:30PM -0000
Sender: [e-mail]
Precedence: bulk

That is what I thought.  It will be updated in the next revision.

Andrew

On Mon, Dec 23, 2002 at 11:10:30PM -0000, Tom Petch wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Reply-To: "Tom Petch" <[e-mail]>
> From: "Tom Petch" <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>, <[e-mail]>
> Subject: Re: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)
> Date: Mon, 23 Dec 2002 23:10:30 -0000
> 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
> Precedence: bulk
> X-Spam-Status: No, hits=0.3 required=6.0
> 	tests=AWL,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01,SUBJECT_IS_LIST,
> 	      USER_AGENT_OE
> 	version=2.43
> X-OriginalArrivalTime: 23 Dec 2002 23:11:20.0640 (UTC) FILETIME=[9ACA4400:01C2AAD8]
> 
> Oh dear a typo I do mean 13.5 should go.
> 
> Tom Petch
> [e-mail]
> 
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> To: Tom Petch <[e-mail]>
> Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> Date: 23 December 2002 19:40
> Subject: Re: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)
> 
> 
> >Easy enough to do that.  To clarify, in your last paragraph, do you
> >mean 13.4 should go in addition to 13.5, or was the 13.4 a typo?
> >
> >Andrew
> >
> >On Mon, Dec 23, 2002 at 02:36:26PM +0000, Tom Petch wrote:
> >> Date: Mon, 23 Dec 2002 14:36:26 +0000
> >> From: Tom Petch <[e-mail]>
> >> Subject: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)
> >> To: [e-mail], [e-mail]
> >> Cc: [e-mail]
> >> Reply-to: Tom Petch <[e-mail]>
> >> X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4
> >> X-Mailer: Microsoft Outlook Express 4.72.2106.4
> >> X-Priority: 3
> >> X-MSMail-priority: Normal
> >>
> >> I think this issue SHOULD be administratively terminated.
> >>
> >> It relates to Connect state Event 17 (TCP connection fails) and I
> am
> >> credited with raising it; in fact, the issue I raised was missing
> next
> >> state for Active state event 17 and this has now been subsumed into
> >> 13.4 (but note that 13.4 does not explicitly say Active state - I
> know
> >> it should because I raised that issue too).  I will ensure it does
> not
> >> get lost from any resolution of 13.4.
> >>
> >> And Connect state event 17 does appear as part of issue 45 which
> Siva
> >> raised so I think that either way, 13.4 can go.
> >>
> >> Tom Petch
> >> [e-mail]
> >>


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA01238 for <[e-mail]>; Mon, 23 Dec 2002 18:11:29 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6CB8791231; Mon, 23 Dec 2002 18:11:10 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C96291250; Mon, 23 Dec 2002 18:11:10 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F417891231 for <[e-mail]>; Mon, 23 Dec 2002 18:11:08 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D60315DF18; Mon, 23 Dec 2002 18:11:08 -0500 (EST)
Delivered-To: [e-mail]
Received: from nemesis.systems.pipex.net (nemesis.systems.pipex.net [62.241.160.8]) by segue.merit.edu (Postfix) with ESMTP id A57895DF03 for <[e-mail]>; Mon, 23 Dec 2002 18:11:08 -0500 (EST)
Received: from tom3 (userbm19.uk.uudial.com [62.188.144.225]) by nemesis.systems.pipex.net (Postfix) with SMTP id 9552716007FAE; Mon, 23 Dec 2002 23:11:01 +0000 (GMT)
Message-ID: <000e01c2aad8$805f9200$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)
Date: Mon, 23 Dec 2002 23:10:30 -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: [e-mail]
Precedence: bulk

Oh dear a typo I do mean 13.5 should go.

Tom Petch
[e-mail]

-----Original Message-----
From: [e-mail] <[e-mail]>
To: Tom Petch <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Date: 23 December 2002 19:40
Subject: Re: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)


>Easy enough to do that.  To clarify, in your last paragraph, do you
>mean 13.4 should go in addition to 13.5, or was the 13.4 a typo?
>
>Andrew
>
>On Mon, Dec 23, 2002 at 02:36:26PM +0000, Tom Petch wrote:
>> Date: Mon, 23 Dec 2002 14:36:26 +0000
>> From: Tom Petch <[e-mail]>
>> Subject: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)
>> To: [e-mail], [e-mail]
>> Cc: [e-mail]
>> Reply-to: Tom Petch <[e-mail]>
>> X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4
>> X-Mailer: Microsoft Outlook Express 4.72.2106.4
>> X-Priority: 3
>> X-MSMail-priority: Normal
>>
>> I think this issue SHOULD be administratively terminated.
>>
>> It relates to Connect state Event 17 (TCP connection fails) and I
am
>> credited with raising it; in fact, the issue I raised was missing
next
>> state for Active state event 17 and this has now been subsumed into
>> 13.4 (but note that 13.4 does not explicitly say Active state - I
know
>> it should because I raised that issue too).  I will ensure it does
not
>> get lost from any resolution of 13.4.
>>
>> And Connect state event 17 does appear as part of issue 45 which
Siva
>> raised so I think that either way, 13.4 can go.
>>
>> Tom Petch
>> [e-mail]
>>



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA24019 for <[e-mail]>; Mon, 23 Dec 2002 14:40:55 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id F1ED79124D; Mon, 23 Dec 2002 14:40:37 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B97589124E; Mon, 23 Dec 2002 14:40:36 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C9E269124D for <[e-mail]>; Mon, 23 Dec 2002 14:40:35 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B107D5DDB8; Mon, 23 Dec 2002 14:40:35 -0500 (EST)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 54B5F5DDA1 for <[e-mail]>; Mon, 23 Dec 2002 14:40:35 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id LAA21412; Mon, 23 Dec 2002 11:37:30 -0800 (PST)
Date: Mon, 23 Dec 2002 11:37:30 -0800
From: [e-mail]
To: Tom Petch <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)
Message-ID: <[e-mail]>
References: <003701c2aa95$2d8a90e0$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: <003701c2aa95$2d8a90e0$0301a8c0@tom3>; from [e-mail] on Mon, Dec 23, 2002 at 02:36:26PM +0000
Sender: [e-mail]
Precedence: bulk

Easy enough to do that.  To clarify, in your last paragraph, do you
mean 13.4 should go in addition to 13.5, or was the 13.4 a typo?

Andrew

On Mon, Dec 23, 2002 at 02:36:26PM +0000, Tom Petch wrote:
> Date: Mon, 23 Dec 2002 14:36:26 +0000
> From: Tom Petch <[e-mail]>
> Subject: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)
> To: [e-mail], [e-mail]
> Cc: [e-mail]
> Reply-to: Tom Petch <[e-mail]>
> X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4
> X-Mailer: Microsoft Outlook Express 4.72.2106.4
> X-Priority: 3
> X-MSMail-priority: Normal
> 
> I think this issue SHOULD be administratively terminated.
> 
> It relates to Connect state Event 17 (TCP connection fails) and I am
> credited with raising it; in fact, the issue I raised was missing next
> state for Active state event 17 and this has now been subsumed into
> 13.4 (but note that 13.4 does not explicitly say Active state - I know
> it should because I raised that issue too).  I will ensure it does not
> get lost from any resolution of 13.4.
> 
> And Connect state event 17 does appear as part of issue 45 which Siva
> raised so I think that either way, 13.4 can go.
> 
> Tom Petch
> [e-mail]
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA16266 for <[e-mail]>; Mon, 23 Dec 2002 10:40:03 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id C286191245; Mon, 23 Dec 2002 10:39:36 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9235C91248; Mon, 23 Dec 2002 10:39:36 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 536F591245 for <[e-mail]>; Mon, 23 Dec 2002 10:39:35 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 394705DE40; Mon, 23 Dec 2002 10:39:35 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 419BE5DE28 for <[e-mail]>; Mon, 23 Dec 2002 10:39:34 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA96263; Mon, 23 Dec 2002 10:38:52 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: Mareline Sheldon <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Max nos of routes in FIB 
In-reply-to: Your message of "Sun, 22 Dec 2002 15:11:12 MST." <[e-mail]> 
Date: Mon, 23 Dec 2002 10:38:52 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Danny McPherson writes:
> 
> > As i understand we can have some 60-100K routes in the BGP table in the 
> > core. I wanted an estimate as to how many of these are actually injected
> > into the forwarding table? Are all these 80K+ routes actually inserted 
> > into the forwarding table also?
> 
> Actually, I've seen 2+ million BGP paths (sum of all the routes in the 
> Adj-RIBs-In) in the core of some large networks, with ~115-160k unique 
> prefixes in the Loc-RIB (and FIB, subsequently).  The CIDR report is 
> teetering around 117k unique prefixes, as of late, I believe.
> 
> Of course, with the add-paths draft it could be be more, with the 
> bounded-longest-match it could be less.
> 
> Of course, you could do clever things when populating the FIB to 
> reduce the size, but that's an implementation issue.  
> 
> -danny


I think the question was how big does the FIB have to be and for a few
ISPs with lots of internal unaggregated routes that get aggregated on
the way out its around 2m+ paths (Adj-In entries) and around 200k
routes (FIB entries), maybe a bit more.  The number of routes in the
CIDR reports represent routes after aggregation exported to a peer.

Routers which are being designed so as not to become obsolete quickly
have to set targets quite a bit higher.

Curtis


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15119 for <[e-mail]>; Mon, 23 Dec 2002 10:10:19 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 3FE6B91246; Mon, 23 Dec 2002 10:09:19 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E753991245; Mon, 23 Dec 2002 10:09:18 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D035391246 for <[e-mail]>; Mon, 23 Dec 2002 10:09:15 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B09B95DF54; Mon, 23 Dec 2002 10:09:15 -0500 (EST)
Delivered-To: [e-mail]
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by segue.merit.edu (Postfix) with ESMTP id 7F8FF5DE40 for <[e-mail]>; Mon, 23 Dec 2002 10:09:15 -0500 (EST)
Received: from tom3 (userbo34.uk.uudial.com [62.188.145.184]) by colossus.systems.pipex.net (Postfix) with SMTP id 1645316000558; Mon, 23 Dec 2002 15:09:14 +0000 (GMT)
Message-ID: <003901c2aa95$2f143e20$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: <[e-mail]>, "idr" <[e-mail]>
Cc: <[e-mail]>
Subject: Issue 26 BGP Base Draft - Issue List v2.0 (Draft-19)
Date: Mon, 23 Dec 2002 15:06:42 -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: [e-mail]
Precedence: bulk

Issue 26 discusses adding a new event or events for start with
bgp-stop flap option set.

But if we add an event, then we must add and agree on actions for all
six existing states so I think to say that adding a new event settle
things might be naive.

If we do add
   3) Automatic start with passive TCP establishment and bgp_stop_flap
option set

which I understand is Sue's resolution, then for Idle state the
actions are straightforward but for the other five, is the event
completely ignored?  If so, does it mean that the passive flag and the
bgp_stop_flap option are ignored and we carry on as if we were when we
were started which may have been without them.  Or is the fact of
starting ignored but the flags remain set and so color the effect of
other events?  Needs defining.


Tom Petch
[e-mail]





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15099 for <[e-mail]>; Mon, 23 Dec 2002 10:09:57 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 3C31691230; Mon, 23 Dec 2002 10:09:18 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C970091248; Mon, 23 Dec 2002 10:09:17 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8573791230 for <[e-mail]>; Mon, 23 Dec 2002 10:09:14 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 6DBBF5DF54; Mon, 23 Dec 2002 10:09:14 -0500 (EST)
Delivered-To: [e-mail]
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by segue.merit.edu (Postfix) with ESMTP id 308C55DE40 for <[e-mail]>; Mon, 23 Dec 2002 10:09:14 -0500 (EST)
Received: from tom3 (userbo34.uk.uudial.com [62.188.145.184]) by colossus.systems.pipex.net (Postfix) with SMTP id D534B16000298; Mon, 23 Dec 2002 15:09:12 +0000 (GMT)
Message-ID: <003801c2aa95$2e5b9c80$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Issue 45 BGP Base Draft - Issue List v2.0 (Draft-19)
Date: Mon, 23 Dec 2002 14:51:56 -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: [e-mail]
Precedence: bulk

Issue 45 is event 17 (TCP connection fails) in Connect state which
wants a textual description to reflect Jeff's statement.

I propose

       If the TCP connection fails[Event 17] and the Open Delay
       timer is running, the local system:
           - restarts the connect retry timer,
           - clears the Open Delay timer
           - continues to listen for a connection that may be
              initiated by the remote BGP peer, and
           - changes its state to Active.

        If the TCP connection fails [Event17] and the Open Delay
        timer is not running, the local system:
             - drops the TCP connection,
             - releases all BGP resources,
             - sets ConnectRetryCnt (the connect retry count) to zero
             - resets the connect retry timer (sets to zero), and
             - goes to Idle state.

to replace

       If the TCP connection fails (timeout or disconnect)
        [Event17], the local system:
            - restarts the connect retry timer,
            - continues to listen for a connection that may be
              initiated by the remote BGP peer, and
            - changes its state to Active.


Tom Petch
[e-mail]




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15085 for <[e-mail]>; Mon, 23 Dec 2002 10:09:38 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 9933091226; Mon, 23 Dec 2002 10:09:15 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4515291245; Mon, 23 Dec 2002 10:09:15 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BAC5B91226 for <[e-mail]>; Mon, 23 Dec 2002 10:09:13 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 9E45B5DF54; Mon, 23 Dec 2002 10:09:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from colossus.systems.pipex.net (colossus.systems.pipex.net [62.241.160.73]) by segue.merit.edu (Postfix) with ESMTP id 6DBF45DE40 for <[e-mail]>; Mon, 23 Dec 2002 10:09:13 -0500 (EST)
Received: from tom3 (userbo34.uk.uudial.com [62.188.145.184]) by colossus.systems.pipex.net (Postfix) with SMTP id 111A5160001C3; Mon, 23 Dec 2002 15:09:11 +0000 (GMT)
Message-ID: <003701c2aa95$2d8a90e0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)
Date: Mon, 23 Dec 2002 14:36:26 -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: [e-mail]
Precedence: bulk

I think this issue SHOULD be administratively terminated.

It relates to Connect state Event 17 (TCP connection fails) and I am
credited with raising it; in fact, the issue I raised was missing next
state for Active state event 17 and this has now been subsumed into
13.4 (but note that 13.4 does not explicitly say Active state - I know
it should because I raised that issue too).  I will ensure it does not
get lost from any resolution of 13.4.

And Connect state event 17 does appear as part of issue 45 which Siva
raised so I think that either way, 13.4 can go.

Tom Petch
[e-mail]




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA19478 for <[e-mail]>; Mon, 23 Dec 2002 00:11:44 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A1EFC9121C; Mon, 23 Dec 2002 00:11:07 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67A659122E; Mon, 23 Dec 2002 00:11:07 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6598A9121C for <[e-mail]>; Mon, 23 Dec 2002 00:11:06 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 49D3C5DEEB; Mon, 23 Dec 2002 00:11:06 -0500 (EST)
Delivered-To: [e-mail]
Received: from nomad.tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by segue.merit.edu (Postfix) with ESMTP id 1B0A15DEE7 for <[e-mail]>; Mon, 23 Dec 2002 00:11:06 -0500 (EST)
Received: by nomad.tcb.net (Postfix, from userid 500) id 0D03355FCC; Sun, 22 Dec 2002 15:11:17 -0700 (MST)
Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id 0A2073E83; Sun, 22 Dec 2002 15:11:17 -0700 (MST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: Mareline Sheldon <[e-mail]>
Cc: [e-mail]
From: Danny McPherson <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Max nos of routes in FIB 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 22 Dec 2002 15:11:12 -0700
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> As i understand we can have some 60-100K routes in the BGP table in the 
> core. I wanted an estimate as to how many of these are actually injected
> into the forwarding table? Are all these 80K+ routes actually inserted 
> into the forwarding table also?

Actually, I've seen 2+ million BGP paths (sum of all the routes in the 
Adj-RIBs-In) in the core of some large networks, with ~115-160k unique 
prefixes in the Loc-RIB (and FIB, subsequently).  The CIDR report is 
teetering around 117k unique prefixes, as of late, I believe.

Of course, with the add-paths draft it could be be more, with the 
bounded-longest-match it could be less.

Of course, you could do clever things when populating the FIB to 
reduce the size, but that's an implementation issue.  

-danny



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA17431 for <[e-mail]>; Sun, 22 Dec 2002 23:35:24 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id F341F91201; Sun, 22 Dec 2002 23:35:06 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF0BF9121C; Sun, 22 Dec 2002 23:35:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B6ECE91201 for <[e-mail]>; Sun, 22 Dec 2002 23:35:04 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A36835DE5B; Sun, 22 Dec 2002 23:35:04 -0500 (EST)
Delivered-To: [e-mail]
Received: from web20304.mail.yahoo.com (web20304.mail.yahoo.com [216.136.226.85]) by segue.merit.edu (Postfix) with SMTP id 05C5D5DE44 for <[e-mail]>; Sun, 22 Dec 2002 23:35:04 -0500 (EST)
Message-ID: <[e-mail]>
Received: from [165.213.1.1] by web20304.mail.yahoo.com via HTTP; Sun, 22 Dec 2002 20:35:03 PST
Date: Sun, 22 Dec 2002 20:35:03 -0800 (PST)
From: Mareline Sheldon <[e-mail]>
Subject: Max nos of routes in FIB
To: [e-mail]
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-500218568-1040618103=:42697"
Sender: [e-mail]
Precedence: bulk

--0-500218568-1040618103=:42697
Content-Type: text/plain; charset=us-ascii


Hello,

As i understand we can have some 60-100K routes in the BGP table in the core. I wanted an estimate as to how many of these are actually injected into the forwarding table? Are all these 80K+ routes actually inserted into the forwarding table also?

Regards,

Mareline S.

 

 



---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
--0-500218568-1040618103=:42697
Content-Type: text/html; charset=us-ascii

<P>Hello,</P>
<P>As i understand we can have some 60-100K routes in the BGP table in the core. I wanted an estimate as to how many of these are actually injected into the forwarding table? Are all these 80K+ routes actually inserted into the forwarding table also?</P>
<P>Regards,</P>
<P>Mareline S.</P>
<P>&nbsp;</P>
<P>&nbsp;</P><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com">Yahoo! Mail Plus</a> - Powerful. Affordable. <a href="http://rd.yahoo.com/mail/mailsig/*http://mailplus.yahoo.com">Sign up now</a>
--0-500218568-1040618103=:42697--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA11705 for <[e-mail]>; Sun, 22 Dec 2002 03:34:59 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5397691217; Sun, 22 Dec 2002 03:34:35 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 257B591221; Sun, 22 Dec 2002 03:34:35 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1B4ED91217 for <[e-mail]>; Sun, 22 Dec 2002 03:34:34 -0500 (EST)
Received: by segue.merit.edu (Postfix) id EF6E75DE17; Sun, 22 Dec 2002 03:34:33 -0500 (EST)
Delivered-To: [e-mail]
Received: from smtp.cwnt.com (smtp.cwnt.com [192.116.246.129]) by segue.merit.edu (Postfix) with ESMTP id 3956F5DD9F for <[e-mail]>; Sun, 22 Dec 2002 03:34:32 -0500 (EST)
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
Subject: Diff between -17 and -18 draft
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1255"
Date: Sun, 22 Dec 2002 10:34:25 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Diff between -17 and -18 draft
Thread-Index: AcKplO9ZrZWqCQAFRCWzwbeKbOCwgQ==
From: "Amir Hermelin" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id DAA11705

Hi,
can someone point out the differences between -17 and -18 draft, either in:
* short titles (sections would be helpful), or
* subject of the message sent in the past to the wg, in case I missed it.
any help would be greatly appreciated.

I also suggest that, the documents being the length they are, you include a permanent section comparing differences to the last version of the draft (as you do with the RFCs).

Thanks in advance.

--
Amir Hermelin                    <mailto:[e-mail]>
Charlotte's Web Networks Inc.     <http://www.cwnt.com>


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA24920 for <[e-mail]>; Fri, 20 Dec 2002 18:26:38 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 0A5FE912F0; Fri, 20 Dec 2002 18:25:57 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A963D912F1; Fri, 20 Dec 2002 18:25:56 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C86A2912F0 for <[e-mail]>; Fri, 20 Dec 2002 18:25:51 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 97CB15E075; Fri, 20 Dec 2002 18:25:51 -0500 (EST)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 3EF205DFFA for <[e-mail]>; Fri, 20 Dec 2002 18:25:50 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id PAA02338; Fri, 20 Dec 2002 15:22:49 -0800 (PST)
Date: Fri, 20 Dec 2002 15:22:49 -0800
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: BGP Base Draft - Issue List v2.0 (Draft-19)
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="5vNYLRcllDrimb99"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: [e-mail]
Precedence: bulk

--5vNYLRcllDrimb99
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Greetings,

Attached is v2.0 of the issues list.  This version covers the issues that
have been raised in various discussions about draft-19.  As always,
mistakes are mine, please let me know if I have missed anything.

Andrew

--5vNYLRcllDrimb99
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="Issue_List-v2.0.txt"

2002-12-09
v2.0

This is version 2.0 of this list.  All the 2.x versions pertain to
draft-ietf-idr-bgp4-18.txt.  The revisions discussed here are targeted
to be incorporated into the -19 version of this document.

Since late August 2002, there has been a push to get any and all
issues with the base spec. resolved so the IDR group can move
this draft forward to the IESG.

This is a list of the issues that have been brought up regarding the
base draft, and the current working group consensus on them.

All mistakes are mine, please email me at [e-mail] with corrections.

Please include the number and the title of the issue in the subject
lines of email discussing that issue.  It will help in keeping track.

N.B. There is no rhyme or reason to the numbering scheme other than
unique tags to address the issues.

============================================================================
Table of Contents
============================================================================
1) Reference to RFC 1772
2) MUST/SHOULD Capitalization
3) Fix Update Error Subcode 7 -- accidently removed.
4) Section 5.1.4 - Editoral Comment
5) Section 9.1 - Change "all peers" to "peers"
6) AS Loop Detection & Implicit Withdraws
7) Standardize FSM Timer Descriptions
8) FSM MIB enumerations
9) Make "delete routes" language consistant
10) Correct OpenSent and OpenConfirm delete wording
11) Incorrect next state when the delay open timer expires.
12) Entering OpenConfirm / Adding "Stop OpenDelay" action
13) FSM Missing Next States
13.1) FSM Missing Next States - Event 15 or 16 (Connect State)
13.2) FSM Missing Next States - Event 14 (Connect State)
13.3) FSM Missing Next States - Event 15 or 16 (Active State)
13.4) FSM Missing Next States - Event 13-17 (TCP Connection)
13.5) FSM Missing Next States - Event 17 (Connect State)
13.6) FSM Missing Next States - Event 18 (Open Confirm)
14) FSM - Peer Oscillation Damping
15) FSM - Consistant FSM Event Names
16) Many Editorial Comments
17) Section 3, Page 8, Paragraph 3 - Obsolete?
18) MED Removal Text
19) Security Considerations
20) Peer Oscillation Damping
21) Session Attributes - IdleHold Timer
22) Specify New Attributes (Accept Connections/Peer Oscillation Damping)
23) Event1/Event2 Clean Up
24) Events 3, 5, 6 & 7 Give Examples
25) Event 4 & 5 Session Initiation Text
26) Event 4 & 5 - bgp_stop_flap option
27) Event 5 Clarification 
28) Timer Events Definition - Make Consistant
29) Event 8 - Clean Up
30) Hold Timer - Split?
31) OpenDelay Timer Definition
32) Definition of TCP Connection Accept (Event 13)
33) Event 13 & 14 - Valid Addresses & Ports
34) Event 17 - TCP Connection Fails to TCP Connection Termination
35) Making Definition Style Consistant 
36) Event 19 - Definition Cleanup
37) Event 22 - Cleanup
38) FSM Description - ConnectRetry Count
39) Handling Event 7 (Auto Stop) to Idle State processing
40) Clearing the Connection Retry Timer
41) Handling of Event 14 in the Connect State
42) Handling events 20, 21 in the Connect State and Active State
43) Handling the default events in the Connect state
44) Handling Event 23 in Connect and OpenSent
45) Event 17 in the Connect state
46) Handling of Event 17 in Active state
47) Handling of Event 19 in Active state
48) Handling of Event 2 in Active state
49) Default Event handling in Active state
50) Clearing Hold timer in OpenSent, OpenConfirm and Established State
51) Clearing Keepalive timer in OpenConfirm and Established State
52) Handling Event 18 in the OpenSent state (Keepalive Timer)
53) Established State MIB
54) State impact of not supporting Optional Events
55) New DelayOpen State

============================================================================
Issues with Consensus
============================================================================
1) Reference to RFC 1772
2) MUST/SHOULD Capitalization
3) Fix Update Error Subcode 7 -- accidently removed.
4) Section 5.1.4 - Editoral Comment
5) Section 9.1 - Change "all peers" to "peers"
6) AS Loop Detection & Implicit Withdraws
7) Standardize FSM Timer Descriptions
8) FSM MIB enumerations
9) Make "delete routes" language consistant
10) Correct OpenSent and OpenConfirm delete wording
11) Incorrect next state when the delay open timer expires.
13.1) FSM Missing Next States - Event 15 or 16 (Connect State)
13.3) FSM Missing Next States - Event 15 or 16 (Active State)
14) FSM - Peer Oscillation Damping
16) Many Editorial Comments
19) Security Considerations
20) Peer Oscillation Damping
23) Event1/Event2 Clean Up
25) Event 4 & 5 Session Initiation Text
27) Event 5 Clarification 
28) Timer Events Definition - Make Consistant
29) Event 8 - Clean Up
30) Hold Timer - Split?
31) OpenDelay Timer Definition
32) Definition of TCP Connection Accept (Event 13)
36) Event 19 - Definition Cleanup
37) Event 22 - Cleanup
38) FSM Description - ConnectRetry Count
39) Handling Event 7 (Auto Stop) to Idle State processing
46) Handling of Event 17 in Active state
49) Default Event handling in Active state
50) Clearing Hold timer in OpenSent, OpenConfirm and Established State
51) Clearing Keepalive timer in OpenConfirm and Established State
53) Established State MIB
55) New DelayOpen State

============================================================================
Issues WITHOUT Consensus
============================================================================
12) Entering OpenConfirm / Adding "Stop OpenDelay" action
13) FSM Missing Next States
13.2) FSM Missing Next States - Event 14 (Connect State)
13.4) FSM Missing Next States - Event 13-17 (TCP Connection)
13.5) FSM Missing Next States - Event 17 (Connect State)
13.6) FSM Missing Next States - Event 18 (Open Confirm)
15) FSM - Consistant FSM Event Names
17) Section 3, Page 8, Paragraph 3 - Obsolete?
18) MED Removal Text
21) Session Attributes - IdleHold Timer
22) Specify New Attributes (Accept Connections/Peer Oscillation Damping)
24) Events 3, 5, 6 & 7 Give Examples
26) Event 4 & 5 - bgp_stop_flap option
33) Event 13 & 14 - Valid Addresses & Ports
34) Event 17 - TCP Connection Fails to TCP Connection Termination
35) Making Definition Style Consistant 
40) Clearing the Connection Retry Timer
41) Handling of Event 14 in the Connect State
42) Handling events 20, 21 in the Connect State and Active State
43) Handling the default events in the Connect state
44) Handling Event 23 in Connect and OpenSent
45) Event 17 in the Connect state
47) Handling of Event 19 in Active state
48) Handling of Event 2 in Active state
52) Handling Event 18 in the OpenSent state (Keepalive Timer)
54) State impact of not supporting Optional Events

----------------------------------------------------------------------------
1) Reference to RFC 1772
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Proposed changing RFC 1772 reference, since that document should
 be updated.

Discussion:

Jeff proposed that we reconsider referencing RFC 1772, since that document
should be updated.

Yakov pointed out that this is a non-normative reference and can just be
left as is.

Jeff agreed that this wasn't a big deal.  We are at consensus to leave
things as they are.

This was discussed in the "-18 last call comments" thread.

----------------------------------------------------------------------------
2) MUST/SHOULD Capitalization
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Capitalize MUST/SHOULD where appropate.

Discussion:

Jeff brought this up, and Yakov reponded asking that he point out 
specific instances where this is needed.  Jeff said he would do so,
given some time.

Yakov later replied that this would be fixed in the -19 version.

This was discussed in the "18 last call comments" thread.
This was also brought up in the "proxy: comments on draft -18" thread.

----------------------------------------------------------------------------
3) Fix Update Error Subcode 7 -- accidently removed.
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add error subcode 7 back in, it looks like it was inadvertently
 removed.  Add deprication text to Open Message Error subcode 5.

Discussion:

Jeff supplied:

 Update message error subcode 7 is removed.  Especially in -18,
 it looks like an editing mistake based on where it would fall
 in the editing..

Yakov mentioned that this is addressed in Appendix A.

Jeff replied:

 What I would like to see is something like this:

 6 - Invalid ORIGIN Attribute
 7 - [Deprecated - See Appendix A]
 8 - Invalid NEXT_HOP Attribute

 As it stands, 7 lies on a page boundary and looks like it got clipped
 by the roff.

Yakov agreed, and also said he would add similar text for Open Message
Error subcode 5.

This was discussed in the "18 last call comments" thread.

----------------------------------------------------------------------------
4) Section 5.1.4 - Editoral Comment
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Fix "restricts" to "RESTRICTIONS"

Discussion:

Jeff proposed an editorial fix.  This is agreed to.

This was discussed in the "-18 last call comments" thread.

----------------------------------------------------------------------------
5) Section 9.1 - Change "all peers" to "peers"
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Section 9.1 - Change "all peers" to "peers"

Discussion:

Jeff proposed:

 9.1:
 The output of the Decision Process is the set of routes that will be
 advertised to (delete all) peers; the selected routes will be stored
 in the local speaker's Adj-RIB-Out according to policy.

 The previous wording implied that routes in the LocRib MUST be placed
 in the adj-rib-out.

Yakov agreed, this fix will be in the next revision.

This was discussed in the "-18 last call comments" thread.

----------------------------------------------------------------------------
6) AS Loop Detection & Implicit Withdraws
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Update the text to reflect the AS Loop detection should be done
 in the BGP decision process.

Discussion:

John brought this up, and suggested:

 I have one further comment just in case it's not perfectly obvious to
 everyone, which is that "ignore the UPDATE" is not strictly the
 action you take when receiving a looped update.  Rather, you treat it
 as an implicit withdraw, i.e. you process it as any other update but
 treat the contained NLRI as unfeasible.

 I was going to write that this is sufficiently clear from the spec,
 but I regret to say that it isn't.  Here is the fourth paragraph of
 section 9:

    The information carried by the AS_PATH attribute is checked for AS
    loops. AS loop detection is done by scanning the full AS path (as
    specified in the AS_PATH attribute), and checking that the autonomous
    system number of the local system does not appear in the AS path.  If
    the autonomous system number appears in the AS path the route may be
    stored in the Adj-RIB-In, but unless the router is configured to
    accept routes with its own autonomous system in the AS path, the
    route shall not be passed to the BGP Decision Process. Operations of
    a router that is configured to accept routes with its own autonomous
    system number in the AS path are outside the scope of this document.

 I don't think this is quite right -- the decision process needs to be
 run if the looped routes had previously been advertised feasibly on
 the same session.  This could be fixed by hacking the quoted
 paragraph, but it seems more straightforward to do it by removing the
 quoted paragraph and making the fix in 9.1.2 Phase 2 instead.  This
 could be done by inserting the following between the third and fourth
 paragraphs of 9.1.2 Phase 2:

    If the AS_PATH attribute of a BGP route contains an AS loop, the
    BGP route should be excluded from the Phase 2 decision function.
    AS loop detection is done by scanning the full AS path (as
    specified in the AS_PATH attribute), and checking that the autonomous
    system number of the local system does not appear in the AS path.
    Operations of a router that is configured to accept routes with its
    own autonomous system number in the AS path are outside the scope of
    this document.

 Section 9.3, first bullet, also addresses this topic, but I don't
 think it's sufficient.

Yakov agreed that this was a change for the better and will include this
in the next revision.

We are at consensus on this issue.

This is discussed in the "-18 last call comments" thread.

----------------------------------------------------------------------------
7) Standardize FSM Timer Descriptions
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Standardize the state descriptions on those listed in the 
 discussion section of this issue.

Discussion:

Tom proposed:

 I think a standard description would serve us better instead of using 
 the  following different ways (which I take all to refer to the same
 entity):
      
 delayBGP open timer
 BGP delay open timer
 BGP open delay timer
 delay open timer
 BGP delay timer
      
 I suggest Open Delay timer (with those capitals)
      
 I believe that the corresponding flag is consistently referred to
 (apart from the capitalisation) as Delay Open flag

Yakov agreed with this suggestion, no one else disagreed, we are at 
consensus.

This was discussed in the "BGP18-FSM-terminology" thread.

----------------------------------------------------------------------------
8) FSM MIB enumerations
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Move MIB references from the base spec into the MIB document.

Discussion:

Tom pointed out that:

 The FSM makes several references to putting values into MIB objects   
 and while some of the values are defined, eg FSM error or Hold Timer
 expired, I can find no definition of the following in any of the BGP
 documents, MIB or otherwise.
   connect retry expired
   TCP disconnect
   administrative down
   collision detect closure
   Call Collision cease
   collision detected and dump connection
   Administrative stop
 I believe an implementation needs to be told these values somewhere
 and that there should be a reference to that place in bgp18.

Jeff replied that to make things easier, the MIB references will be
removed from the base spec, and into the MIB document.

This was discussed in the "WG Last Call FSM MIB enumeration" thread,
and the "bgp18 WG Last Call fsm MIB objects" thread.

----------------------------------------------------------------------------
9) Make "delete routes" language consistant
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Replace a variety of wording with "deletes all routes associated 
 with this connection,".

Discussion:

Tom pointed out that we use a variety of language to say how we are
going to delete routes in the FSM.  He proposed that we instead use:

        - deletes all routes associated with this connection,

This met with agreement, and will be reflected in the next version.

This was discussed in the "bgp18 WG Last Call fsm delete action" thread.

----------------------------------------------------------------------------
10) Correct OpenSent and OpenConfirm delete wording
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Remove delete wording from OpenSent and OpenConfirm states.

Discussion:

Venu asked why there was delete wording in the OpenSent and OpenConfirm
states when a BGP speaker cannot recieve routes in these states.

Jeff acknowledged that this was an error.  Yakov agreed to fix the
next version.

This was discussed in the "bgp18 WG Last Call fsm delete action" thread.

----------------------------------------------------------------------------
11) Incorrect next state when the delay open timer expires.
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Fix the next state.

Discussion:

Tom pointed out that:

 I believe that there is an incorrect next state when the delay open
 timer expires [event 12] in the Active state.  The next state should
 be OpenSent and not OpenConfirm.

 OpenConfirm is for KeepAlive processing when Open messages have been
 sent and received.

 OpenSent is for Open sent and not yet received.

 The corresponding section in Connect state I believe is correct.

Yakov agreed, and will fix this in the next revision.

This was discussed in the "bgp18 WG Last CAll fsm incorrect next state"

----------------------------------------------------------------------------
12) Entering OpenConfirm / Adding "Stop OpenDelay" action
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Add new text agreeded upon in the discussion section, resolve
 possible addition of Stop OpenDelay action (not state, which we agreed
 doesn't reflect current practice.)

Discussion:

This discussion began with Tom outlining these two points:

 When the OpenConfirm state is entered from OpenSent with the receipt
 of a valid open [Event 18], then a KeepAlive message is sent and the
 timer is started.

 When the OpenConfirm state is entered from Active or Connect on
 receipt of a valid open [Event 19], no message is sent, no timer is
 started.
        
 I believe this inconsistency is an error and should be corrected by
 adding these two actions in those two places.

Sue replied:

 Just to clarify this comment:
        
        Event 19 = valid open with delay timer running

        Active = 1) awaiting TCP connection, or
                   2) TCP connection completed and awaiting the
                      TCP connection with delay timer running

 Case 1:  - should not see Event 19
  In transition from Active to Open Confirm, the connection
  must have a TCP connection completed. Case 1 does not
  have this occurring, so the transition must be avoided.

 Case 2: - should see Event 19

        - Open, Keepalive should be sent.

 Previous text: (Action H from FSM document)

        If an Open is received with the BGP Delay Open timer running,
        [Event 19], the local system:
        - clears the connect retry timer [cleared to zero),
        - completes the BGP initialization,
        - stop and clears the BGP Open Delay timer,
        - Sends an Open Message,  
        - sets the hold timer to a large value (4 minutes), and
        - changes its state to an Open Confirm.

 New text: [a New Action - N-2 : N + BGP keepalive sent]

        If an Open is received with the BGP Delay Open Timer running
        [Event 19], the local system:
        - clear the connect retry timer [cleared to zero],
        - completes the BGP initialization,
        - stops and clears the BGP Open Delay timer,
        - Send an Open message,
        - Sends a Keepalive message,
        - If hold timer value is non-zero,
                - set keepalive timer
                - hold timer reset to negotiated value
          else if hold timer is zero,
                - reset the keepalive timer, and
                - reset the hold timer.

        - If the value of the autonomous system field is the
          same as the local Autonomous system number, set  
          the connection status to a internal connection;
          otherwise it is "external".

Tom and Sue discussed the OpenDelay state, and recalled that this was
excluded a number of months ago as not reflecting current practice.

By way of clarification, Sue added:

 1) Agree, this can occur in the Active state as well as the
   Connect state.  Will you accept the earlier text below
   to be inserted both places?

 Background:

 The state machine for Event 19 is:  

               Idle  Connect Active    Open    Open     Estb
                                               Sent    Confirm
               ===============================================
 Event 19      |     |        |        |        |      |      |
   next state  |Idle | Open   | Open   | Open   |Idle  | Idle |
               |     | confirm| confirm| Confirm|      |      |   
               ===============================================
   action      | V   |  N-2   | N-2    |  N     | E-1  |  E   |
               ===============================================

 Per the State Machine.

 Action v - FSM Error
 Action E - FSM Error, drop connection - etc, drop routes
 Action E-1 - FSM Error, drop connection (lots of
 Action N-2 (text below)
 Action N   (text below, without sending Open)

 2) Do you think that Event 19 is possible in the Open Sent state?

        Please answer this separately.

Tom replied that:

 1) yes I think the same text in both Active and Connect states is a
 good resolution

 2) complicated.  As the fsm text stands,  Event 19, along with a host
 of others, takes us back from Open Sent  to Idle (I assume on the
 grounds this is an error condition) which seems very reasonable.

 But ...in quite a few places, such as Connect state events 2,
 7,8,9,10,11, 17, 18, 20 thru 27, we do not stop the OpenDelay timer
 when going to Idle or Active so we could then go from eg Idle with
 Manual start [event 1] to Connect to Open Sent all before the
 OpenDelay timer expires in which case event 19 can occur validly in
 Open Sent - obscure but possible. (This is also true with Active state
 and events 2, 17 and the default list at the end).

 But I think this is an error, and that when exiting Connect state or
 Active state as listed above, we should have an additional action to
 stop the OpenDelay timer in which case event 19 in Open Sent becomes
 an error condition (again).

 But but but as ever, I cannot speak with authority for implementations
 and so if implementations do not stop the OpenDelay timer when exiting
 as above, then Event 19 is valid in Open Sent state - obscure but
 possible (again).

 My wish is to add the extra action, stop OpenDelay timer, for the
 events listed above in Active and Connect states in the expectation
 that that is what people have or should have implemented.

Tom added a reponse to Sue after some other threads have been discussed:

 You asked if event 19 (Open with OpenDelay timer running) was possible
 in OpenSent state; I gave a lengthy reply (below) to the effect yes it
 could because the OpenDelay timer did not always get stopped but the
 timer should be stopped in which case the event would not happen.

 Reading your responses to Siva , I see you include stopping the Open
 Delay timer in the action 'release all BGP resources' when going to
 Idle (which I missed seeing earlier in the year).

 That eliminates most but not all of the possibilities I mentioned.  I
 now believe we would need to add the action 'stop OpenDelay timer' for
 
 Connect state
 event 17 (currently defined as going to Active)
 event 9 (stays in Connect state)

 in order to stop event 19 in Open Sent

This was discussed in the "bgp 18 WG Last Call fsm missing keepalive" thread.
And also in the "Event 19 in Open Sent state was Re: bgp18 WG Last Call 
fsm missing keepalive" thread.

----------------------------------------------------------------------------
13) FSM Missing Next States
----------------------------------------------------------------------------
Status: See sub-issues
Change: Potentially
Summary: Seven sub-issues spawned to resolve each of the next-state 
 questions. 

Discussion:

This began with Tom pointing out 7 places where the next state was not 
clear.  Interlaced with his comments below is the proposed text to fix
the problems and the status of the issue.

This conversation was started in the "bgp18 WG Last Call fsm missing next
state" thread.
        
----------------------------------------------------------------------------
13.1) FSM Missing Next States - Event 15 or 16 (Connect State)
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add next state of Connect.

Discussion:

Tom pointed out that:

      Connect State:

        If the TCP connection succeeds [Event 15 or
        Event 16], the local system checks the "Delay Open
        Flag".  If the delay Open flag is set, the local system:
 **enters what state

Sue proposed these changes:

 1) Connect State - Event 15 or Event 16 [consensus, editorial]

 note:  The delay retry timer is utilized instead of the
         connect retry timer for the next two changes.
                
 Previous text:
 If the TCP connection succeeds [Event 15 or Event 16], 
 local system checks the "Delay Open Flag".  If the delay
 open flag is set, the local system:
        - clears the connect retry timer,
        - sets the BGP open delay timer to initial value
                
   If the Delay Open flag is not set, the local system:
        - clears the connect retry timer,
        - clear BGP Open Delay timer (set to zero),
        - completes the BGP initialization,
        - send an Open message to its peer,
        - sets hold timer to a large value, and
        - change the state to Open Sent.


 New text:
 If the TCP connection succeeds [Event 15 or Event 16],
 local system checks the Delay Open flag prior to
 processing:   If the Delay Open flag is set, the local system:
        - clears the connect retry timer,
        - sets the BGP open delay timer to initial value, and
        - stays in the Connect state.

 If the Delay Open flag is not set, the local system:
        - clears the connect retry timer,
        - clears the BGP Delay timer (sets to zero),
        - completes the BGP initialization,
        - sends an Open message to its peer,
        - sets the hold timer to a large value, and
        - changes the state to Open Sent.

Tom agreed that this was good, with the change to "Open Delay timer"
as discussed in issue 7.

This conversation was started in the "bgp18 WG Last Call fsm missing next 
state" thread.

----------------------------------------------------------------------------
13.2) FSM Missing Next States - Event 14 (Connect State)
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Choose one of two alternatives for the next state after event 14.
 Possibly add a clause about peer oscillation damping.

Discussion:

Tom pointed out that:

      Connect State:

        If the TCP connection receives an indication
        that is invalid or unconfigured. [Event 14]:
 **enters what state

Sue proposed these alternatives:

 2)Connect State - Event 14  [no consensus]

 Current Text:
        If the TCP connection receives an indication that
        that is invalid or unconfigured [Event 14],
        - the TCP connection is rejected.
 
 At the very least this section needs more "word smithing",
 so I'd like to change it for more clarity at least.

 I'm not sure this represents the implementations.
 What I'd like to do is query the implementations
 to see what they do if they receive a valid TCP
 connection with an invalid or unconfigured peer.   
        
 Two options:
        
 Alternative 1: Count it as a valid response
                
 New Text: If a TCP connection is received that has
             an invalid format, or an unconfigured host [Event 14],
             the local system:
                - rejects the TCP connection,
                - increments the connect retry counter,
                - performs bgp peer oscillation checks.
        
                If bgp peer oscillation checks allow for a new
                connection, the bgp peer
                - restarts the Connect retry timer with configured
                  value, and
                - enters the Active state.
        
 FSM table:
            Idle   Connect Active Open-Sent Open-Confirm Establish
 Event-14   =======================================================
 Next state Idle  | Active|Active|Open-Sent|Open-Confirm|Establish|
            =======================================================
  action       V  | Y2    | L    | Ignore  | Ignore     | Ignore  |
            =======================================================
        
        
 Alternative 2: Reject the connection and see if valid or
                   configured one appears within the
                   connect timer window.

 New Text: If a TCP connection is received that has an invalid format,
            or an unconfigured host [Event 14], the local system:
                - rejects the TCP connection,   
                - and stays in the Connect state.

 FSM table:
            Idle   Connect Active Open-Sent Open-Confirm Establish
 Event-14   =======================================================
  Nxt state Idle  |Connect|Active|Open-Sent|Open-Confirm|Establish|
            =======================================================
  action       V  | L    | L     | Ignore  | Ignore     | Ignore  |
            =======================================================

Sue then sent out a call to implementors to let the list know what they
did with their FSMs.  Tom replied that he agreed that we need to wait
to see what the existing implementations do.  He also suggested:

 **tp  need a then clause here 'if bgp peer oscillation damping does
 not allow for a new connection, then the local system ???'

be added before the FSM table in option 1 of the proposed text.

This conversation was started in the "bgp18 WG Last Call fsm missing next
state" thread.

----------------------------------------------------------------------------
13.3) FSM Missing Next States - Event 15 or 16 (Active State)
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add text listed in discussion.

Discussion:

Tom pointed out:

      Active State:

        A TCP connection succeeds [Event 15 or Event 16], the
        local system: process the TCP connection flags
         - If the BGP delay open flag is set:
 ** enters what state (I think this is an FSM error in TCP because it
 has not initiated a connection!)

Sue proposed these changes:

 Previous text:
 A TCP connection succeeds [Event 15 or Event 16],
 the local system: process the TCP connection flags
 - If the BGP delay open flag is set:   
        - clears the connect retry timer
                  
   [through the following text:
 - and changes its state to Open Sent.

           
 New text:
 If the TCP connection succeeds [Event 15 or Event 16],
 local system checks the "Delay Open Flag" prior to
 processing:   If the delay open flag is set, the local system:   
        - clears the connect retry timer,
        - sets the BGP open delay timer to initial value, and
        - stays in the Active state.

 If the Delay Open flag is not set, the local system:
        - clears the connect retry timer,
        - clears the BGP Delay timer (sets to zero),
        - completes the BGP initialization,
        - sends an Open message to its peer,
        - sets the hold timer to a large value, and
        - changes the state to Open Sent.

Tom agreeded with this.

This conversation was started in the "bgp18 WG Last Call fsm missing next 
state" thread.

----------------------------------------------------------------------------
13.4) FSM Missing Next States - Event 13-17 (TCP Connection)
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Get feedback from implementors on TCP connection events.

Discussion:

Tom started this by saying that:

        If the local system receives a valid TCP Indication
        [Event 13], the local system processes the TCP connection
        flags.
 ** enters what state

      
        If the local system receives a TCP indication 
        that is invalid for this connection [Event 14]:
 ** enters what state

Sue proposed we move this to the "fsm missing next state - Events 13-17 and
the TCP connection" thread.

The response in this thread was:

 4) Active State, Event 13 [no consensus]
 5) Active State, Event 14 [no consensus]

  The problem with this state is it is difficult to
  exactly specify without discussing the TCP
  Messages that FSM document covers.
             
  I'll query if the implementors require all
  of events 13-17 as mandatory.

Sue polled the implemtentors on the list with this query:

 These events are described in section 8.1.3.

 In our discussion in January through May of 2002, many
 implementers mapped their implementation onto the
 following TCP events  list in 8.1.3.


 Events 13 - 17  

        Event 13 - TCP connection indication & valid
                   remote peer

        Event 14 - TCP connection indication with invalid
                   source or destination
   
        Event 15 - TCP connection request sent (by this
                   peer) received an Acknowledgement

                [ local system sent a TCP SYN, Received a
                  TCP SYN, ACK pair back, and Sent a TCP ACK]

        Event 16 - TCP connection confirmed

                [local system received a TCP SYN, sent
                 a TCP SYN, ACK back, and received a TCP ACK]

        Event 17 - TCP connections

 Should we have all of these states?  Which implementations
 support all of these Events?

The full FSM text was snipped here for brevity.
                
This was started in the "bgp18 WG Last Call fsm missing next
state" thread.	And continued in the "fsm missing next state - Events 13-17
and the TCP connection" thread.
 
----------------------------------------------------------------------------
13.5) FSM Missing Next States - Event 17 (Connect State)
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Choose one of the two options outlined in the discussion.  Currently
 Option 2 has received the most support.

Discussion:


        If the local system receives a TCP connection
        failed [Event 17] (timeout or receives connection
        disconnect), the local system will:
 ** enters what state

Sue replied with this:

 comment:
 In the Active state, we may already have a connection and be awaiting
 the Open Delay timer.  The TCP disconnect or timeout could occur in this
 state due to the "Open Delay Timer".   If the TCP Disconnect is ignored,
 we could have some peer oscillation.
           
 If the we wait, then the connection retry timer needs to be kept running.
 The text below allows this timer.  The real question is what is the status
 of the current implementations.
 
 I agree, the Active state and the connect state should match.
        
 Old Text:
        If the TCP connection fails (timeout or disconnection) [Event 17],
        the local system:
                - set TCP disconnect in the MIB reason code,
                - restart Connect retry timer (with initial value),
                - release all BGP resources,
                - Acknowledge the Drop of the TCP connection if TCP disconnect
                  (FIN ACK),
                - Increment ConnectRetryCnt (connect retry count) by 1, and
                - performs the BGP peer oscillation damping process.

 Applicable FSM State table:
  
 FSM table old:
  
 Event 17    
  current:   Idle   Connect Active Open-Sent Open-Confirm Establish
            =========================================================
 Next state  Idle  |Active |Idle   |Active | Idle       |Idle       |
                   |       |       |       |            |           |
            =========================================================
  action        V  | Y2     | G    | Ignore| Track 2nd  | Track 2nd |
                   |       |       |       | connection | connection|
            =========================================================

 Alternative 1:


 FSM table new:

 Event 17
 current:   Idle   Connect Active Open-Sent Open-Confirm Establish
           =========================================================
 Next state Idle  |Active |Active |Active   | Idle     |Idle       |
                  |       |       |         |          |           |
           =========================================================
 action       V   | G     | G     | Ignore| Track 2nd  | Track 2nd |
                  |       |       |       | connection | connection|
           =========================================================
                
 G:  The local system:
        - restarts the connect retry timer (at intial value),
        - continues to listen for a connection that may be initiated
          by the remote peer, and
        - sets its next state to Active.

 New Text: (for Connect and Active state)
                If the TCP connection fails (timeout or disconnect)
                [Event 17], the local system:
                - restarts the connect retry timer,
                - continues to listen for a connection that may be
                  initiated by the remote BGP peer, and
                - changes it state to Active.
         
 Alternative 2:
 FSM table new:
 
 Event 17
 current:    Idle   Connect Active Open-Sent Open-Confirm Establish
            =========================================================
 Next state  Idle  |Idle   |Idle   |Active | Idle       |Idle       |
                   |       |       |       |            |           |
            =========================================================
 action       V    | Y2    | Y2    | Ignore| Track 2nd  | Track 2nd |
                   |       |       |       | connection | connection|
            =========================================================
                
 Next Text:
        If the location system receives a TCP connection failed [Event 17],
        the local system will:
                - increment the ConnectRetrycnt (connect retry count) by 1,
                - release all BGP resources associated with this connection,
                - perform BGP peer oscillation (if configured), and
                - go to Idle

 Y2 - is:
        The local system:
                1) increments the ConnectRetryCnt (connect retry count) by 1,
                2) releases all BGP resources associated with this connection,
                   and
                3) performs the BGP peer oscillation damping process

        if the damping process allows for a new connection, the local system
                - restarts the connect retry timer (with initial value, and
                - goes to Idle
  
        If the damping process does not allow for a new connection, the local
        system
                - set the flags to damp the creation of a new bgp connection
                until a manual start occurs, and
                - goes to Idle.

Tom agreed with the options, and stated that he prefered option 2.  Sue
is also happy with option 2, if no one else chimes in.

This conversation was started in the "bgp18 WG Last Call fsm missing next 
state" thread.

----------------------------------------------------------------------------
13.6) FSM Missing Next States - Event 18 (Open Confirm)
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Get reponses from implementors, get collision detection text 
 cleared up.  Proposed text is below.

Discussion:
        
Tom opened this with:

      Open Confirm State:

        If the Open messages is valid [Event 18], the collision
        detect function is processed per section 6.8.  If this
        connection is to be dropped due to call collision, the  
        local system:
 ** enters what state

Sue replied with:

 Here's my proposed text. Please let me know what you think.
 I think this is an editorial change.
        
             
 Old text:  If the open message is valid, the collision detect
            function is processed per section 6.8.  If this
            connection is to be dropped due to call collision, the local
             system:
                - sends a Notification with a Cease
                - resets the Connect timer (to zero),
                - releases all BGP resources,
                - Drop the TCP connection (sends a TCP FIN),
                - increments the ConnectRetryCnt by 1 (connect retry count), and                - performs an BGP peer oscillation damping process.

 New text:  If the open message is valid, the BGP peer connection
             is check to detect a collision per section 6.8.  If this
           connection is to be dropped due to call collision, the local
             system:
                - sends a Notification with a Cease
                - resets the Connect timer (to zero),
                - releases all BGP resources,
                - Drop the TCP connection (sends a TCP FIN),
                - increments the ConnectRetryCnt by 1 (connect retry count), and                - performs an BGP peer oscillation damping processing, and
                - enters the Idle State.
  
        notes: Collision detect impacts Open Sent, Open Confirm, and
                 Established states.

Tom replied:

 I am still struggling with; we are in OpenConfirm so we already have
 received an Open from the remote peer and Event 18 is a second Open
 from the same peer.  Perhaps my struggle is that I think in terms of
 two (or more) FSM for a given IP address pair so the Open Collision
 detection will occur when the/an- other FSM receives a valid Open in
 states Active/Connect/Open Sent and will generate Event 22 into this
 FSM so Event 18 cannot occur.  But yes, if Event 18 can occur in this
 FSM and this connection is to be dumped, then Idle state it should be
 as you suggest.  I have slotted in [optionally] in front of the peer
 oscillation damping in your text because I think it should be
 optional:-)

Sue replied:

    this mechanism allows a single fsm to
    handle both.  2 fsm and 1 fsm BGP FSM
    seem to exist.  (I queried implementors
    a few times on this one.  So, I just
    put in this change to provide the
    flexibility.

        Collision detect tends to give
        scrambled brains for most people..
        As Dennis Ferguson said 2 years ago,
        that's the hardest part of the FSM.

Sue then stated that she would query implementors to see what is being done.

This conversation was started in the "bgp18 WG Last Call fsm missing next 
state" thread.

----------------------------------------------------------------------------
14) FSM - Peer Oscillation Damping
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Change references to peer oscillation damping to consistant phrase:
 "[optionally] performs peer oscillation damping".  Also remove old 
 reference to "BGP Peer Restart Backoff Mechanisms".

Discussion:

Tom suggested we use consistant terminology to refer to peer osillation
damping.  He also pointed out a stale reference.

Yakov agreed to fix both of these.

----------------------------------------------------------------------------
15) FSM - Consistant FSM Event Names
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Proposal to make the FSM Event Names consistant.  There have
 been no comments on this propsal.

Discussion:

Tom proposed that:

 The event name used in the FSM show much variation to the point
 sometimes where I am not clear that it is always the same event (eg
 where the event name is qualified by a subset of the possible causes).
 Assuming that it is, I propose the following changes to make the
 wording consistent, clear and concise for event names.

 ** denotes changed text using the convention /'old text'/'new text'/

 8. BGP Finite State machine

       Event1:  Manual start
       Event2:  Manual stop
       Event3:  Automatic start
     **Event4:  Manual start with passive TCP /estabishment/flag/
     **Event5:  Automatic start with passive TCP /establishment/flag/
       Event6:  Automatic start with bgp_stop_flap option set
     **Event7:  Auto//matic/ stop
       Event8:  Idle hold timer expires
       Event9:  Connect retry timer expires
     **Event10: Hold time//r/ expires
       Event11: Keepalive timer expires
       Event12: Open Delay timer expires
     **Event13: TCP connection valid indication
     **Event14: TCP connection invalid indication
     **Event15: TCP connection request /sent received an ACK/acknowledged/
       Event16: TCP connection confirmed
       Event17: TCP connection fails
       Event18: BGPOpen
       Event19: BGPOpen with *Open Delay timer running
       Event20: BGPHeaderErr
       Event21: BGPOpenMsgErr
       Event22: Open collision dump
       Event23: NotifMsgVerErr
       Event24: NotifMsg
       Event25: KeepAliveMsg
       Event26: UpdateMsg
       Event27: UpdateMsgErr

 8.2.2 Finite State Machine

      Connect State:

        If the BGP port receives a ** valid TCP connection indication
 [Event 13],

        If the TCP connection receives **an invalid indication [Event
 14]:

        If the TCP connection fails **/(timeout or disconnect)//
 [Event17]

      Active State:

       If the local system receives a **valid TCP //indication/ [Event
 13],
     
       If the local system receives a TCP connection failed [Event 17]
 **/(timeout or receives connection disconnect)//,

      Open Sent:
     
       If a connection in Open Sent is determined to be the
       connection that must be closed, an **/administrative collision
       detect/Open collision dump/ [Event 22] is signaled to the state
       machine. If such
       an **/administrative collision detect dump [Event 22]/event/ is
       
       If a TCP **//connection valid/ indication [Event 13] or
       TCP **//connection/ request **//acknowledged/ [Event 15]
       
      Open Confirm State:
       
       ... or receives a TCP **/Disconnect// connection fails/ [Event
 17] from the

       In the event of **/TCP establishment//TCP connection valid
 indication /[Event 13]

       .... the local system will
       **/issue a call/generate an Open/ collision dump [Event 22].
 When the local
       system receives a **/call/open/ collision dump event [Event   
 22]/such an event/, the

      Established State:
    
       **/disconnect from the underlying TCP/TCP connection fails/
 [Event17], it:

       ... it will process **/a Call/an Open/ Collision dump
 event[Event 22].   

       
 Notes:
 Event 4 title brought in line with text
 Event 5 title brought in line with text
 Event 7 title brought in line with text
 Event 13 title shortened to be closer to text, text brought in line
 Event 14 title shortened to be closer to text, text brought in line
 Event 15 title brought in line with text
 Event 17 text brought in line with title (text often introduces
 qualifying conditions that are too restrictive)
 Event 22 text brought in line with title

This is discussed in the thread: "bgp18 WG Last Call fsm event names."

----------------------------------------------------------------------------
16) Many Editorial Comments
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Many editorial suggestions, and what we are doing with them
 are listed below.  Some issues have been broken out seperately where there
 is a longer discussion on them.

Discussion:

Alex began this by presenting comments from an anonymous reviewer, unless
otherwise noted, responses are from Yakov:

 > Almost all of these are simple clarifications.
 >  
 > Section 1, page 5: IGP definition - it's not clear from this
 > definition whether IBGP would be considered an IGP?
 
 any suggestion on how to improve the definition to clarify
 this issue would be appreciated.

There was some further discussion on this and it was decided that people
reading this document ought to know what an IGP is.

 > Section 3, page 7, para 4: Does RFC 1772 still represent the *planned*
 > use of BGP?  Or the actual use?  Or something different from actual
 > use?

 Perhaps we should just take out references to 1772.

Further discussion seemed to indicate that this reference should stay.

 > Section 3, page 8, para 3 - "The hosts executing..."  This paragraph
 > seems obsolete.

 I'll take it out.

With regard to this, Siva asked if some route optimizaiton vendors rely on
this.  Since this wasn't resolved, it is discussed further in issue 17.

 > Section 4.1, page 11 - Length is in network byte order.

 all the encodings are in network byte order. This applies not just
 to the BGP spec, but to other protocols as well.

This comment was made about a number of fields.  It was later agreed that
a reference would be made to this at the beginning of the document.

 > Section 4.2, page 12 - Hold Time - what does a value of zero indicate?

 if you read section 4.4 then you'll find that:
  
   If the negotiated Hold Time interval is zero, then periodic KEEPALIVE
   messages MUST NOT be sent.

 > Section 4.2, page 13 - BGP Identifier - network byte order?
 >         "IP address" -> "IPv4 address"

 I'll put at the beginning a sentence saying that in the context of
 this document the term "IP address" means an IP Version 4 address.

 > Section 4.3, Page 14, para1, sentence 2 - "path attribute" -> "path   
 > attributes"

 fixed.

 > Section 4.3,Page 17, NEXT_HOP: "IP address" -> "IPv4 address"
 >         Specify that this is 4 octets.
 >         Reference here to multi-protocol extensions for IPv6 nexthop?

 no.

 >         RFC 2283 is unclear whether NEXT_HOP should always be included
 >         when using multiprotocol extensions. Clarify this here?

 It is already clarified in 2283bis.

 > Section 4.3, Page 17/18 - MED and LocalPref:
 >         "non-negative" -> "unsigned" for consistency with elsewhere.
 >         (non-negative might imply values > 2^31 cannot be used).
   
 fixed.
    
 > Section 4.3, Page 19 - Prefix: "IP address" -> "IPv4 address"
 >         Prefix: "enough trailing bits to" -> "the minimum number of
 >         trailing bits needed to"

 fixed.

 > Section 4.4, Page 20:  - "BGP does not use any TCP-based keep-alive
 > mechanism to determine if peers are reachable".  Is it worth noting   
 > that TCP may still timeout the connection even if TCP keepalives are
 > turned off?

 the text is fine as it is.

 > Section 4.4, Page 20:
 > KEEPALIVE message consists" -> "A KEEPALIVE message consists"
 
 fixed.

 > Section 5, Page 23: "The same attribute can not appear more than once
 > with the Path Attributes field...".  Does this mean the same attribute
 > type, or the same attribute type and value?

 the former (the same attribute type).

 > Section 5.1 "The usage of each BGP path attributes .." -> attribute

 fixed.

 > Section 5.1.3 "IP address" -> "IPv4 address"
 > 
 > "A BGP speaker must never advertise an address of a peer to that peer
 > as a NEXT_HOP, for a route that the speaker is originating."
 >   suggest replace this text with:
 > "A route originated by a BGP speaker must never be advertised to a 
 > peer using an address of that peer as NEXT_HOP"

 fixed.

 > Section 5.1.4: "A BGP speaker MUST IMPLEMENT a mechanism ... which
 > allows the MULTI_EXIT_DISC to be removed from a route."  Might want to
 > say that this is dangerous unless you received the route from an EBGP
 > peer?

 think we should keep the text as is.

 > Section 5.1.5: "If it [LOCAL_PREF] is contained in an UPDATE message
 > that is received from an external peer, then this attribute MUST be
 > ignored by the receiving speaker, except for the case of BGP
 > Confederations [RF3065]."
 >  - "ignored" might be taken to mean that you don't process it for
 >    decision, but that you propagate it to internal peers.  I might
 >    write "silently removed" or something similar.

 I think the text is ok as is.

 > Section 5.1.5, para 2.  "set of AS" -> "set of ASs"

 fixed.

 > Section 6.3: wrt NEXT_HOP semantic correctness: should we check that a 
 > NEXT_HOP is not a multicast or broadcast address?

 I'll add to the definition of NEXT_HOP that it is a unicast address.

 > Section 6.3, page 32, para 7:  "peer than sent" -> "peer that sent"

 fixed.

 > Section 6.3: "if any attribute appears more than once" - does this
 > mean the same attribute type, or the same attribute type and value?

 the former.

 > Section 6.8 "Comparing BGP identifiers is done by treating them as 
 > (4-octet-long) unsigned integers".  Need to convert to host byte order
 > before comparing.

 fixed.

 > Section 6.8, item 2:  "closes BGP connection" -> "closes the BGP connection"
 > "accepts BGP connection" -> "accepts the BGP connection".

 fixed.

 > Section 9.1.2.2: item (c): in the explanation of neighborAS(n), it is
 > unclear for IBGP connections how to determine "the neighbor AS from
 > which the other IBGP speaker learned the route".  If this is really
 > the leftmost entry in the AS path (or the local AS if the path is
 > empty), the spec should explicitly say so.

 fixed.

 > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC
 > attribute is removed before..."  The first sentence is pretty nearly
 > incomprehensible.

This topic has some more discussion surrounding what text we should use
to clarify this issue.  This is followed up in issue 18.

 > Section 9.1.2.2 (d)
 >      "d) If at least one of the candidate routes was received from an 
 >       external peer in a neighboring autonomous system, remove from con-
 >       sideration all routes which were received from internal peers."
 > For consistency with (c) and clarity, this might be reworded:
 >      "d) If any of the candidate routes was learned via EBGP, remove
 >      from consideration all routes which were learned by IBGP."

 fixed.

 > Section 9.1.2.2 (e)
 >      "cost (n) is better than cost (m)"
 >      Given the definition of cost, it might be clearer to say
 >      "cost (n) is lower than cost (m)"

 fixed.

 > Section 9.1.2.2 (g)
 >      "neighbor address" has not been defined.

 I'll replace "neighbor address" with "peer address".

 > Section 9.2.2.2, Page 70 (AGGREGATOR) - "All AGGREGATOR attributes of
 >      all routes to be aggregated should be ignored."
 >
 >      Perhaps "ignored" is ambiguous here, and it's not clear whether
 >      should is a SHOULD.  Suggest:
 >
 >      "Any AGGREGATOR attributes from the routes to be aggregated MUST
 >      NOT be included in the aggregated route."
 
 fixed.

 > Section 9.3 - shouldn't this subsection be moved to the discussion of
 > Phase 1 or Phase 2 of the decision process?  Or at least move it
 > before Section 9.2.

 I think it is fine where it is now.

 > Appendix E, para 2: IP precedence has been deprecated.  Delete this 
 > paragraph, or replace with appropriate diffserv codepoint.

 deleted.

 > Security Considerations:
 >    "BGP supports the ability to authenticate BGP messages by using BGP
 >    authentication."
 >    This sentence should be removed, and the Authentication Information
 >    parameter has been deprecated.

 Please see the recent e-mail exchange on the Security Considerations

See issue 19 for more on the Security Considerations section of the draft.

These topics were discussed in the "proxy: more comments on the draft -18"
thread.

----------------------------------------------------------------------------
17) Section 3, Page 8, Paragraph 3 - Obsolete?
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Do existing vendors rely on this, or no?  If no, remove it.

Discussion:

This issue was spawned from the discussions in issue 16, specifically:

Anonymous reviwer:

 > Section 3, page 8, para 3 - "The hosts executing..."  This paragraph
 > seems obsolete.

Yakov:

 I'll take it out.

With regard to this, Siva asked if some route optimizaiton vendors rely on
this.

This was discussed in the "proxy: more commetns on draft -18" thread.

----------------------------------------------------------------------------
18) MED Removal Text
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Select new text from the options below.

Discussion:

This issue is spawned from issue 16.

An anonymous reviewer pointed out:

> Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC
> attribute is removed before..."  The first sentence is pretty nearly
> incomprehensible.

Yakov replied:

 here is my attempt to clarify this:

  If a MULTI_EXIT_DISC attribute is removed before re-advertising a 
  route into IBGP, then (prior to the removal) the MULTI_EXIT_DISC
  attribute may only be considered in the comparison of EBGP learned 
  routes; the attribute is then removed, and then the remaining EBGP
  learned routes may be compared to the remaining IBGP learned routes,
  without considering the MULTI_EXIT_DISC attribute for those EBGP
  learned routes whose MULTI_EXIT_DISC attribute will be removed
  before advertising these routes to IBGP.

 Any further suggestions on how to improve this would be appreciated.

Siva replied:

  How about this:

 %   If a MULTI_EXIT_DISC attribute is removed before re-advertising a
 %   route into IBGP, then comparison based on the MULT_EXIT_DISC
 %   attribute may (MUST?) be performed only among the EBGP learned routes.
 %   This comparison MUST be performed before the removal of the
 %   MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute must then
 %   be removed from those EBGP routes where such removal is required and
 %   which are still eligible. This is followed by comparison with IBGP
 %   learned routes.

    I think this reflects our objectives, which is:

    a) If MED is to be removed, compare EBGP routes based on the MED

    b) Then remove the MED

    c) Then do comparison with IBGP routes

Andrew suggested:

 If a router is configured to remove a MUTLI_EXIT_DISC attribute from
 a route learned from EBGP, before readvertising it into IBGP the
 router MUST compare the route with other EBGP-learned routes before
 removing the MULTI_EXIT_DISC.  Once this comparison is complete,
 the MED may be removed, and any remaining routes can be compared with
 IBGP routes to determine the best route.

This is discussed  in the "proxy: more comments on draft 18" thread.

----------------------------------------------------------------------------
19) Security Considerations
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Fix Security Considerations section to include manditory MD5 auth
 and advance security considerations draft along with the base draft.

Discussion:

Yakov started this discussion by proposing text which would require 
TCP MD5 authententication for BGP implementations.  This is to bring
the spec in line with an IETF requirement that authentication be available.

After some discussion the plan is to advance draft-ietf-idr-bgp-vuln-00.txt
as Informational along with the base BGP specification.  This draft
will serve as the security analysis section of the base spec.

This is discussed in the "revised Security Considerations section" thread.

----------------------------------------------------------------------------
20) Peer Oscillation Damping
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Keep the Peer Oscillation Damping reference in the specification.

Discussion:

This began when Siva proposed:

 Since this feature is going to be added in a new draft, and its
 addition will change the operation of the state machine, can we remove
 all mention of it in the state machine ? As part of this removal, can
 we also remove the IdleHold Timer from the FSM since it is not useful
 in the absence of peer oscillation damping ?

 The draft that describes this procedure can then describe the change
 in the state machine required to do this.

Sue replied that:

 The reason we should not remove the peer oscillation damping
 from the state machine:

  1) Deployed implementations support peer oscillation damping
  2) Hooks for the additions in the FSM cannot be added later.

 These hooks are optional and do not need to be implemented.

Siva replied:

  I understand. I am not trying to object to peer oscillation
  damping, I think it is a good idea and we have included it in
  our implementation as well. I was suggesting that instead of
  a partial description in this draft, it be completely described
  in the draft on peer oscillation damping.

  However, I do see your point, and unless there are any objections
  from others, I think we have consensus on this issue.

This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #1.

----------------------------------------------------------------------------
21) Session Attributes - IdleHold Timer
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Text about the IdleHold timer is on the table, we need to decide 
 if it is what we want.  The addition of the DelayBgpOpenTimer and DelayOpen
 Flag have not yet been addressed.

Discussion:

This discussion began with Siva asking:

 Why have a Hold Timer and a Hold Time ? Can we replace this with just
 Hold timer ?

 Can we also add the following session attributes:

 a) DelayBgpOpenTimer
 b) IdleHold Timer (in case we choose not to remove this from the bas =
    FSM)

 Can we also add the following flag to the session attributes:
 a) DelayOpen Flag

After some discussion we have this text on the table:

    Event8: Idle hold timer expires

           Definition: An Event generated when the Idle Hold Timer
                       expires.  The Idle Hold Timer is only used
                       when the persistent peer oscillation
                       damping function is enabled.
%
%                            Implementations not implemented persistent
%                            peer oscillations damping functions may not
%                            have the Idle Hold Timer.
        


This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #2.

----------------------------------------------------------------------------
22) Specify New Attributes (Accept Connections/Peer Oscillation Damping)
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentailly
Summary: Is proposed text acceptable?

Discussion:

This begain with Siva propsosing:

  Can we call these out as well:

  * Accept Connections from unconfigured peers (Enabled/Disabled)
  * Peer Oscillation Dampening (Enabled/Disabled) (In case we choose
    not to remove it from base spec)

After some discussion we have this text on the table:

The following will be added to 8.0
        
 Optional parameters that may be supported either per
 connection or per implementation:

 1) Delay Open flag
 2) Delay Open Timer
 3) Perform automatic start flag
 4) Passive TCP establishment flag
 5) BGP stop_peer_flag flag
 6) Idle Hold timer
 7) Perform automatic stop flag
 8) Perform Collision detect in Establish mode flag

This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #3.

----------------------------------------------------------------------------
23) Event1/Event2 Clean Up
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Use "Local system administrator" in both sections.

Discussion:

Siva proposed that we clean up the text for these Events by selecting
either "Administrator" or "Local system" but not both.

Sue proposed text using "Local system administrator" that was agreed on.

This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #4.

----------------------------------------------------------------------------
24) Events 3, 5, 6 & 7 Give Examples
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Move Automatic Disconnect example to the event description.
  Possibly add example text/description clarification to other events.

Discussion:

This began with Siva proposing we add examples for these event states.
Sue believes this is largely out-of-scope, but did agree to move
the example of "automatic stop" to the event description section.
She asked for proposed text for additional examples.

This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #5.

----------------------------------------------------------------------------
25) Event 4 & 5 Session Initiation Text
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Leave the text as is.

Discussion:

This began with Siva wanting to change:

	  Definition:  Local system automatically starts the
		BGP session with the passive flag=20
		enabled.  The passive flag indicates=20
		that the peer will listen prior to=20
		establishing a connection.

to:

 The passive flag indicates that the state machine will wait for
 specified peer to initiate a connection with the local system. If
 this does not happen within a specific time (hold time), the local
 system will then also attempt to initiate connection with the
 specified peer.

Sue replied:

 The text in 8.2.1.1 indicates the definition of the passive flag.
    
 6a)
 ==========
 My understanding of your text is that you want to replace in both
 sets of text:

 "The passive flag indicates the peer will listen prior to
  establishing a connection".

 with:

 "The passive flag indicates that the state machine will wait for the
 specified peer to initiate a connection with a local system. 

 The problem with this sentence is that in the "unconfigured" case
 the phrase "specified" peer is confusing.  I think the original text
 is clearer.

 6b)
 ==========
 If this does not happen within a specific time (hold time), the local
 system will then also attempt to initiate (a) connection with the
 specified peer.
  
 My comments: Again, the "specified peer" term is confusing.  Also,
 the 2nd half of the statement mixes the actions of the state machine  
 with the events.  I believe this muddies the text instead of
 clarifying it.

Siva and Sue later agreed to leave the text the same because of the
Unconfigured + passive TCP connection + Delay Open situation.

This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #6.

----------------------------------------------------------------------------
26) Event 4 & 5 - bgp_stop_flap option
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Add new event (#3) below. Does that settle things?

Discussion:

This began with Siva asking:

  Won't a variant of this with bgp_stop_flap option set be requried ?
  We can also achieve the same by using the bgp_stop-Flap option as a
  flag that is provided as an input to the state machine.

Siva later clarified this to include:

   We already have
   Event 3 - Automatic Start
   Event 5 - Automatic start with bgp_stop_flap option set
   To make things consistent, shouldn't we either
 
   a) Add 3 new events : 1) Manual start with bgp_stop flap option set
                         2) Manual start with passive TCP establishment
                            and bgp_stop_flap option set
                         3) Automatic start with passive TCP establishment
                            and bgp_stop_flap option set

   or
  
   b) Remove Event 6, and rely on a flag to tell us wether peer flap damping
      is to be performed for the session or not.

Sue said she prefered option A.  And stated that #1 & #2 are infeasible,
but that we need to add #3.

This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #7.

----------------------------------------------------------------------------
27) Event 5 Clarification 
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Leave the text as is.

Discussion:

This began when Siva asked that in event 5:

 Is it correct that this event will occur only when we want to restart
 a connection (after it had been terminated due to some reason beside
 administrative action) that we had accepted from an unconfigured peer ?

Sue replied:

 The automatic start function is an implementation specific mechanism.
 This text does not seek to restrict it in any fashion.
  
Siva said that although he felt his original clarification would be more
useful to new implementors he is ok with the text as is.

This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #8.

----------------------------------------------------------------------------
28) Timer Events Definition - Make Consistant
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Change text to use "generate" across the board.

Discussion:

Can we use similar language for Events 8-12 to make them consistant?

It was agreed that we will use "generate" i.e.:

 Event 8: An event generated when the Idle Hold timer expires. 
 Event 9: An event generated when the ConnectRetry timer expires.
 Event 10: An event generated when the Hold timer expires.
 Event 11: An event generated when the Keepalive timer expires
 Event 12: An event generated when the Delay BGP Open timer expires.
 
This is at consensus.

This was discussed in the "Response to FSM input - Comments 1-10" thread
Comment #9.

----------------------------------------------------------------------------
29) Event 8 - Clean Up
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Clean up first sentance.  New text below.

Discussion:

Siva began this by asking if we could clean up the wording of Event 8.

After some discussion with Sue we are at this change for the first sentance:

  An event trigerred by the expiry of the Idle Hold timer, indicating
  that the session has completed waiting for a back-off period to
  prevent bgp peer oscillation.

This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #10.

----------------------------------------------------------------------------
30) Hold Timer - Split?
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Keep the hold timer text as is.

Discussion:

Siva proposed that since:

  We use the hold timer for two purposes

  * Waiting for an open message (with a default value of 240 seconds)
  * Waiting for Keepalives (with a default value of 90 seconds)

  Can we use two different timers (or at least call them two different
  timer events) ?

Sue replied that this is not how it is implemented currently.  Siva
replied that we have two conceptually different timers, but that
it would certainly work to only have one, since only one needs to be
running at any given time.

Tom agreed that we can keep things as is.

This was discussed in the "Comments 11-20" thread: Comment #11.

----------------------------------------------------------------------------
31) OpenDelay Timer Definition
----------------------------------------------------------------------------
Status: Consensus
Change: Yes - See issue 28
Summary: This is fixed by the fixing of issue 28.

Discussion:

This began with Siva's request that we add something to Event 12 to
specify what to do when the timer expires.  This seems to have been
addressed in issue 28.

This was discussed in the "Comments 11-20" thread:  Comment #12.

----------------------------------------------------------------------------
32) Definition of TCP Connection Accept (Event 13)
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Change "Definition" text as indicated below.

Discussion:

Siva proposed that we change text from refering to "TCP connection request"
to "receiving a TCP connection".  This led to this proposed text:

        Definition: Event indicating the reception of a TCP connection
                        request with a valid source IP address and TCP
                        port, and valid destination IP address and
                        TCP Port.  The definition of invalid source address
                        and port and invalid destination address
                        is left to the implementation.

This met with agreement.

This thread also discussed the idea of filtering the incomming address/port.
It was decided that this was implementation dependant.

This was discussed in the "Comments 11-20" thread: Comment #13.

----------------------------------------------------------------------------
33) Event 13 & 14 - Valid Addresses & Ports
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: We're at consensus for most of this, but we need to agree on
 the destination port portion of this.

Discussion:

With regard to Event 13 & 14, Siva raised questions about: 1) What does
it mean to validate a port, and 2) Should we state what we consider
an invalid IP addres to be?

Sue replied that this is local policy and is implementation dependant.
Siva agreed regarding the source port & IP address, but disagreed about the
destination port.  He argued that we need to know the destination port
for interoperability.

This was discussed in the "Comments 11-20" thread: Comment #14.

----------------------------------------------------------------------------
34) Event 17 - TCP Connection Fails to TCP Connection Termination
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Select either "fails" or "disconnect", and choose title from
 either "TCP connection fails" or "TCP connection termination".

Discussion:

This began with Siva observing:

 This event can occur even when the transport connection is closed by
 the other end. Since this does not reflect a 'failure ', can we change
 the event name to

 % Event17: TCP connection termination

Sue replied that:

 Discussion:  It both terminates from the remote site
                 and can "timeout" - fail.
 
 Suggestions? I can use "disconnect", what do you think.

Siva replied that this was a minor issue, and on further reflection, either
"fails" or "disconnect" would be acceptable.

This was discussed in the "Comments 11-20" thread: Comment #15.

----------------------------------------------------------------------------
35) Making Definition Style Consistant 
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Almost at consensus with this, just need to decide if we're going
 to adopt the same style for events 18-21.  Text for 13-21 is below

Discussion:

This started with Siva asking if we could make the definition style 
consistant across eventsr.  Sue replied to this with text for 13-17,
Siva clarified that he was talking more about 18-21, and proposed
text.

We are agreed on the text for 13-17:

     Event13: TCP connection indication and valid remote peer

            Definition: Event indicating the local system reception of
                      a TCP connection request with a valid source
                        IP address and TCP port, and valid destination
                        IP address and TCP Port. The definition of 
                        invalid source, and invalid destination  
                        IP address is left to the implementation.
                        
                        BGP's destination port SHOULD be port
                        179 as defined by IANA.
           
                        TCP connection request is denoted by
                        the local system receiving a TCP SYN.

            Status:     Mandatory (Optional)


     Event14: RCV TCP connection indication with invalid source or
              destination
       
            Definition: Event indicating the local system reception of
                      a TCP connection request with either  
                        an invalid source address or port
                        number or an invalid destination
                        address or port number.
            
                        BGP destination port  number SHOULD be 179
                        as defined by IANA.

                        Again, a TCP connection request
                        denoted by local system receiving a TCP
                        SYN.
 
            Status:     Mandatory (Optional)
 
     Event15: TCP connection request sent received an ACK.   

            Definition: Event indicating the Local system's request   
                        to establish a TCP connection to the remote
                        peer.
                        
                        The local system's TCP session sent a TCP
                        SYN, and received a TCP SYN, ACK pair of 
                        messages, and Sent a TCP ACK.
                        
            Status:     Mandatory
           
     Event16: TCP connection confirmed
      
            Definition: Event indicates that the local system receiving
                      a confirmation that the TCP connection has
                        been established by the remote site.

                        The remote peer's TCP engine sent a TCP SYN.
                        The local peer's TCP engine sent a SYN, ACK
                        pair, and now has received a final ACK.
 
            Status:     Mandatory
                        
     Event17: TCP connection fails
       
            Definition: Event indicates that the local system has
                        received a TCP connection failure notice. 

                        The remote BGP peer's TCP machine could have
                        sent a FIN.  The local peer would respond
                        with a FIN-ACK. Another alternative is that
                        the local peer indicated a timeout in the
                        TCP session and downed the connection.
            
            Status:     Mandatory

Siva proposed these changes for 18-21:

>       Event18: BGPOpen
> 
>              Definition:  An event indicating that a valid Open
>                  message has been received.

    with
             
%       Event18: BGPOpen
%
%              Definition:  An event is generated when a valid Open
%                           message has been received.  

>       Event19: BGPOpen with BGP Delay Open Timer running
> 
>              Definition: An event indicating that a valid Open
>                          message has been successful
>                          established for a peer that is
>                          currently delaying the sending of an
>                          BGP Open message.

   with

%       Event19: BGPOpen with BGP Open Delay Timer running
%
%              Definition: An event is generated when a valid Open
%                          message has been received for a peer that
%                          is currently delaying the sending of a 
%                          BGP Open message.

Editorial Note: "Delay Open Timer" replaced with "Open Delay Timer"
per issue 7.
                         
>       Event20: BGPHeaderErr
>
>           Definition: BGP message header is not valid.

   with

%       Event20: BGPHeaderErr
%
%           Definition: An event is generated when a received BGP
%                       message header is not valid.

>       Event21: BGPOpenMsgErr
> 
>           Definition: An BGP Open message has been received
>                          with errors.

    with
             
%       Event21: BGPOpenMsgErr
%
%           Definition: An event is generated when BGP Open message
%                       with errors has been received.

There haven't been any comments back on this text.

This was discussed in the "Comments 11-20" thread: Comment #16.

----------------------------------------------------------------------------
36) Event 19 - Definition Cleanup
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Replace definition for Event 19 with the text in the discussion.

Discussion:

Siva propsosed we replace:

>	    Definition: An event indicating that a valid Open=20
>			Message has been successful=20
>			established for a peer that is=20
>			currently delaying the sending of an=20
>			BGP Open message.=20

with:

% Definition: An event indicating that a valid OPEN
%		Message has been received for a peer
%		that has a successfully established
%		transport connection and is currently
%		delaying the seending of a BGP open
%		message

in Event 19.  Sue agreed to the changes.

This was discussed in the "Comments 11-20" thread: Comment #17.

----------------------------------------------------------------------------
37) Event 22 - Cleanup
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Replace Event 22 definition with the text from the discussion.

Discussion:

Siva began with observing:

> Event22: Open collision discard
>
>	    Definition: An event generated administratively=20
>			when a connection Collision has been=20
>			detected while processing an incoming =20
>			Open message. This connection has been=20

 Isn't this event 'automatically' generated, since it is a system
 generated event ?=20

Sue replied that:

 response: How this generated is implementation specific.  The
          "administratively" is to cover policy.


Siva also proposed an editorial fix with:

>			Event 22 is an administrative could=20
>			occur if FSM is implemented as two=20
>

 The word event is missing. How about

%			Event 22 is an automatic event that
%			could occur if FSM is implemented as two=20

Sue replied with this rewritten text:

   Event22: Open collision dump
 
           Definition: An event generated administratively
                       when a connection collision has been
                       detected while processing an incoming     
                       OPEN message and this connection has been
                       selected to disconnected. See Section
                       6.8 for more information on collision
                       detection.

                       Event22 is an administrative based only
                           implementation specific policy. This
                           Event may occur if the FSM is implemented
                           as two linked state machines.

Sive agreed with this new text.

This was discussed in the "Comments 11-20" thread: Comment #18.

----------------------------------------------------------------------------
38) FSM Description - ConnectRetry Count
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Leave the counter text alone, since it is used in peer oscillation
  and will be in the MIB.

Discussion:

Siva opened with this question:

 The Connect Retry count is updated by the FSM but never used. In the
 absence of peer oscillation damping, will this be used to stop
 connection establishment attempts after a certain maximum number ?

<Sue>
        Yes, this is either implementation specific or
        is it based on the peer oscillation damping draft.   
</Sue>

 Can we include the use of this counter in some place ?

<Sue>
        Connect retry counter
                1) Will be utilized by the peer oscillation damping drat.
                2) Will be included in bgp-4-mibv2-xx.
                        I just check and I didn't find it.

 Do you still want text in the main?
</Sue>

To which Siva replied that he believes we can leave the main text alone.

This was discussed in the "Comments 11-20" thread: Comment #19.

----------------------------------------------------------------------------
39) Handling Event 7 (Auto Stop) to Idle State processing
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Fix the text as indicated in the discussion.

Discussion:

Siva began with:

 The handling of Event 7 is missing from the Idle State processing. Can
 we add this ? How about replacing

> An manual stop event (Event2) is ignored in the Idle state.

 with

% Manual stop (Event 2) and Auto stop (Event 7) events are ignored
% in the Idle state

Sue replied that she would add the text.

This was discussed in the "Comments 11-20" thread: Comment #20.

----------------------------------------------------------------------------
40) Clearing the Connection Retry Timer
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Do we remove the redundant resets from the text?  Or leave them
  to allow action routines to be shared across multiple states?

Discussion:

Siva opend with the observation:

 There are a few sections where the FSM draft states that the Connection
 Retry timer needs to be reset, wheras the conenct retry timer had been
 cleared prior to entering that state. We can remove these instructions
 to clear the connect retry timer.

 List of places where the connect retry timer need not be cleared

    a) Handling of Event 19 in the Connect State
    b) Handling of Events 12 in the Active State
    c) All cases where it is refered to in the OpenSent,
	OpenConfirm and Established states

Sue replied:

 Comment:
 1) Does it hurt to have the connect retry timer cleared
   at these points, since it has already been cleared.

 I felt it eased the implementations to allow the action
 routines to be shared across as many states as possible.
 You can see this a bit more actively.

This was discussed in the "Comments 21-30" thread: Comment #21.

----------------------------------------------------------------------------
41) Handling of Event 14 in the Connect State
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Is this really part of Issue 13.4?  

Discussion:

Siva opened the discussion with:

>  If the transport connection receives an indication
>  that is invalid or unconfigured. [Event 14]:
>	- the TCP connection is rejected.

 I don't understand how we would get this event while in this state.

Sue replied:

 See my earlier comments (1-10) on the connection state.
 It happens in implementations which track the TCP state more
 closely.  I suggest that Event 14 become optional.

Sue also suggested we fold this into the discussion about events 13-17,
which is tracked in issue 13.4.

This was discussed in the "Comments 21-30" thread: Comment #22.

----------------------------------------------------------------------------
42) Handling events 20, 21 in the Connect State and Active State
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Modify section 4.2 to avoid precluding sending NOTIFICATIONs
 in early states (text is in the discussion).  Still need to clarify 
 the FSM behavior.

Discussion:

Siva began this with:

 We need to consider the case where we receive events 20 (message
 header error) and 21 (Open message error) when the delay timer is 
 running.

 Since the connection has been established at this point, we need to
 send a Notification message and then terminate the connection.

To which Sue replied:

 Alternative comments:

 1) We have not sent an Open statement.   
 2) Why do we have to send an Notification? I see no justification
    for it.

 Suggestion:
 Do you have implementations that send notification?  Do
 you know of others that don't.

Jeff saw this as indicative of an issue with section 4.2 the way it
is currently written:

>From section 4.2 of -18:
: 4.2 OPEN Message Format  
:
:    After a TCP is established, the first message sent by each side is an
:    OPEN message. If the OPEN message is acceptable, a KEEPALIVE message
:    confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE,
:    KEEPALIVE, and NOTIFICATION messages may be exchanged.

 This text implies that NOTIFICATIONs can only be sent once we
 have sent an open and then a keepalive, generally meaning we're in the
 Established state.
      
 Anyone suggestions for modifying the wording?

 Section 6.1 (Message header error) is one situation that implies
 that a NOTIFICATION can be sent without sending even an OPEN message.
 Note that since the base FSM implies that we send an OPEN message
 immediately when we have a completed trasnport connection, we SHOULD
 be in at least OpenSent.  However, the DelayOpen timer means that we
 MAY send a NOTIFICATION when we are in the Connect state.

 GateD, at least, will not send a NOTIFICATION without first sending
 an OPEN.

 We need to pick one: You can send NOTIFICATIONS before OPEN or before
 OPEN if the OpenDelay timer is running.  However, we MUST fix the text
 above.

Tom opined:

 A NOTIFICATION without a preceding OPEN is rather hard to interpret;
 it is the OPEN that gives the recipient what it needs to know about
 its potential peer (Version, AS number, ID, options etc) so it makes
 sense to send an OPEN even if it is followed by a NOTIFICATION to say
 goodbye :-( as opposed to a KEEPALIVE which says hello:-).

 But as ever, what is implemented?

Yakov suggested these modifications to the text to resolve this:

 1. Delete the last sentence in the above paragraph
   
  or

 2. Delete "and NOTIFICATION" in the last sentence in the above paragraph

Jeff replied that he prefered the first option, and that the second could
be interpreted as NOTIFICAITONs not being legal, when, in fact, they may.

So the text on the table to resolve this is:

4.2 OPEN Message Format

    After a TCP is established, the first message sent by each side is an
    OPEN message. If the OPEN message is acceptable, a KEEPALIVE message
    confirming the OPEN is sent back.

However, this does not entirely clear up the original point about the
FSM.  If we reveive an error in Connect/Active, do we send a NOTIFY?
Do we preface it with an OPEN, so that OPEN/NOTIFY are sent in 
immediete succession?

This was discussed in the "Comments 21-30" thread: Comment #23.

----------------------------------------------------------------------------
43) Handling the default events in the Connect state
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary:

Discussion:

Siva opened this with:

 The Open Delay timer [original: BGP Delay OpenTimers) needs to be cleared 
 if it is running.

 How about adding this:

 % - If the ConnectRetry Timer is running
 % -    Clear the Connect Retry timer
 % - Otherwise
 % -    Clear the Open Delay timer [original: BGP Delay Open Timer]

Sue replied that:

 By the default you mean the text:

 In response to any other events[Events 7-8, 10-11, 18,
 20-27], the local system:

 "resets" to me implies stops and clears.  I think the
 text is clear than the text above.
 ------------
 Is this the replacement text you imply above:
 - resets the connect retry timer (sets to zero),
 - clears the Open Delay timer [original: BGP Delay timer] (sets to zero),
 - increments the ConnectRetryCnt (connect retry count) by 1,
 - [optionally] performs bgp peer oscillation damping, and
 - goes to Idle text:

Editor's note: various incarnations of "Open Delay timer" have been replaced
with "Open Delay timer".  See issue 7.

This was discussed in the "Comments 21-30" thread: Comment #24.

----------------------------------------------------------------------------
44) Handling Event 23 in Connect and OpenSent
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Does the supplied state table suffice to meet this handling of
 Event 23?

Discussion:

This began with Siva saying:

 This is currently being handled in the default event processing section.
 However, we do not need to go through the peer oscillation damping
 process in this case. Can we change the wordings to reflect this, or
 move this out of peer oscillation damping processing ?

Sue replied:

1)  There is no default event handling process in the text, you
    will need to specify the text.

2) The state table below (hares-statemt-03.txt) states shows
   the changes 

-------------
Event 23
states:
current    Idle Connect Active Open-Sent Open-Cnf  Establish
     ----------------------------------------------------
next state Idle  Idle    Idle  Idle      Idle       Idle
           -----------------------------------------------
action     V      D       D     Y        Y           T
           ==============================================

V - Indicate FSM errors and ignore.
D - 1) resets the connect retry timer (sets to zero),
     2) drops the TCP connection,
     2) releases all BGP resources,
     3) increments the ConnectRetryCnt (connect retry count) by 1,
     4) [optionally] performs the bgp peer oscillation damping, and
       Goes to Idle state.
   
  Y  1) resets the connect retry timer (sets to zero),
     2) Drops the TCP connection,
     3) releases all BGP resources,
     4) [optionally]

This was discussed in the "Comments 21-30" thread: Comment #25.

----------------------------------------------------------------------------
45) Event 17 in the Connect state
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: We are at consensus, we just need the text.

Discussion:

This began with Siva asking:

>  If the transport connection fails (timeout or transport
>  disconnect) [Event17], the local system:
>	- changes its state to Active.

 If the transport connection fails when the Open Delay timer [original:
 BGP Open Delay timer] is running, should we still be going into the 
 Active state ?

Sue replied refering to the disussion tracked in issue 13.4.

Jeff responded that:

 In this particular case, I think the issue is separate from the issues
 for events 13-17 since this isn't particular to how deep the BGP
 implementation meddles in the TCP implementation.

 If we are in the Connect state, because we have an incoming transport 
 connection that has completed, but we have the OpenDelay timer
 running and the transport connection is closed, we can simply
 drop into Active after resetting the ConnectRetry timer and clearing
 the OpenDelay timer (if set/exists).  In the case of an unconfigured
 peer, we can discard the FSM instance.

Tom replied that he agreed with this.

This was discussed in the "Comments 21-30" thread: Comment #26.

----------------------------------------------------------------------------
46) Handling of Event 17 in Active state
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: See issue 13.4, this issue closed in favor of that one.

Discussion:

This began with Siva saying:

 We should now move into Idle state. Can we add

% - Goes to Idle state

Sue replied that she thought this should be bundled in with the issue
tracked in 13.4.  Since no one objected, this issue has been closed
in favor of that one.

This was discussed in the "Comments 21-30" thread: Comment #27.

----------------------------------------------------------------------------
47) Handling of Event 19 in Active state
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Which of the texts is prefered?

Discussion:

This began with Siva suggesting:

> - Set the Hold timer to a large value (4 minutes),
     
 Since OPEN messages have been exchanged, can we change this to
       
% - If the negotiated Hold time is not 0, set the Hold time to
%     - the negotiated value

Sue replied that:

 The text in Active and Open Sent needs to be the same.
 The text in Open Sent is:
 - sets the Hold timer according to the negotiated value
  (see section 4.2), and

 Which text do you prefer?

This was discussed in the "Comments 21-30" thread: Comment #28.

----------------------------------------------------------------------------
48) Handling of Event 2 in Active state
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Clear up procedure for handling Event 2.  

Discussion:

Siva opened with:

> A manual stop event[Event2], the local system:
>	- Sends a notification with a Cease,
>	- drops the Transport connection

 These two actions are possible only if a transport connection had already
 been established. How about changing the text to

% - If a transport connection had been successfully established
% - Send a Notification with a Cease
% - Drop the Transport Connection

Sue counter suggested:

 A manual stop event [Event 2], the local system
 - Drop the TCP connection,
 - Release all BGP resources,
 - resets the connection retry timer [sets to zero],
 - goes to Idle.

Jeff replied:

 I'm rather confused.  Under exactly what circumstances can we be
 in the Active state and have an active TCP connection at all?
 Ditto for having any BGP resources?

 Going to Idle is fine.

Tom offered this example:

 eg start with passive flag, TCP SYN received, SYN-ACK sent, ACK
 received, Delay Open flag set and there we are.  Most events are now
 possible either from a well-implemented remote peer or a badly
 implemented remote peer.

This was discussed in the "Comments 21-30" thread: Comment #29.

----------------------------------------------------------------------------
49) Default Event handling in Active state
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: No routes in active. 

Discussion:

Siva began with:

 To ensure consistencey with E2 handling, can we add

% - If any BGP Routes exist, delete the routes

Sue replied:

 Comment: Yakov and Jeff noted, there are no routes in Active state.

Since there were no responses disagreeing, we'll consider this closed
unless someone wants to open it back up.

This was discussed in the "Comments 21-30" thread: Comment #30.

----------------------------------------------------------------------------
50) Clearing Hold timer in OpenSent, OpenConfirm and Established State
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: This issue is addressed in the "Clear BGP resources"

Discussion:

This began with Siva stating:

 In all event handling where we go to Idle state, we need to clear the
 Hold Timer as well.

Sue replied that:

        issue resolve one way last Jan - March
        Clearing of keep alive timer included
        in Clear BGP resources

No response to this yet, but since this seems to be resolved it is
at consensus unless someone objects.

This was discussed in the "Comments 30-36" thread: Comment #31.

----------------------------------------------------------------------------
51) Clearing Keepalive timer in OpenConfirm and Established State
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: This issue is addressed in the "Clear BGP resources"

Discussion:

This began with Siva stating:

 In all event handling where we go to Idle state, we need to clear the
 Keepalive Timer as well.

Sue replied that:

        issue resolve one way last Jan - March
        Clearing of keep alive timer included
        in Clear BGP resources

No response to this yet, but since this seems to be resolved it is
at consensus unless someone objects.

This was discussed in the "Comments 30-36" thread: Comment #32.

----------------------------------------------------------------------------
52) Handling Event 18 in the OpenSent state (Keepalive Timer)
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: At what point do we start the Keepalive timer.

Discussion:

This began with Siva asking:

 Why do we start the Keepalive timer at this stage ? Isn't it sufficient to
 do so when we move into Established state ?

Sue replied:

 An earlier comment from Tom (and you) requested the following:

                <---Open
                        [Open sent state]

        Open-->
                        [Event 18]

                <---Open
                <---Keepalive
                        [Action from Event 18 in Open Sent]
                        [Open Confirm]
        Keepalive -> [Event 25]
 
                        [established]

 What do implementations do?  We'll have to query implementations.

Jeff added:

 I'm assuming the second OPEN going from right to left is a typo.
 If it isn't, thats a FSM error to the peer on the left.

 Theoretically, an implementation that utilizes its keepalive timer
 to send the first keepalive to transition to Established is 
 still interoperable.  However:

 o Keepalives can be disabled by negotiating hold time of zero
 o We really shouldn't need to restart the Keepalive timer.
   If there is a delay in the keepalive that transitions from
   OpenConfirm to Established, its due to the transport connection.
   It should be reliable and it *should* get through.  If it
   doesn't, there's other problems and the hold timer for the
   peer on the right should do the Right Thing and drop the
   connection.

> What do implementations do?  We'll have to query implementations.

 GateD at least waits to enter the Established state prior to starting
 the KeepAlive timer.

Tom also added:

 My comment was that if we do not send a KeepAlive (and start the
 KeepAlive timer), on exiting from Active with Event 19 to OpenConfirm
 then we never will and the connection will die.  Open Confirm state
 means valid Open received so we must send a KeepAlive to acknowledge
 the Open  (as pointed out in Jeff's other posting) and we never do it
 in OpenConfirm state itself (unless the KeepAlive timer expires which
 it cannot because we have not started it).

 So for me,  OpenSent state Event 18 was and is correct, sending the
 KeepAlive without which the connection goes no further and Active
 state Event 19 needs to be brought into line.

 To say that the timer is started when entering Established state is
 fine except for a slight problem; we have no way in this FSM of
 defining actions that are taken on entering a state, only actions to
 be taken on leaving another state so that is why the KeepAlive actions
 need to be where they are (or are not in the case of Active state
 Event 19).

This was discussed in the "Comments 30-36" thread: Comment #33.

----------------------------------------------------------------------------
53) Established State MIB
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: MIB references pulled in favor of having them in the MIB document.
 See issue 8. 

Discussion:

This began with Siva asking:

 Some event handling in the Established state do not set the MIB Reason
 when handling an event that causes an error. Can we add this ?

Sue replied that we have pulled the MIB wording from the FSM. See issue 8.

This was discussed in the "Comments 30-36" thread: Comment #34.

----------------------------------------------------------------------------
54) State impact of not supporting Optional Events
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Should we develop the text?  If so we need text.

Discussion:

Siva stated that:

 For the events whose status is optional, can we state the impact of not
 supporting them (in terms of any interoperability issues). I understand 
 that most of the optional events will not have such an impact; but a
 clarification statement for the optional events would benefit new 
 implementors.

Sue responded:

 Much of the support of optional parameters depends on policy.
 I could put a short note about the optional events and
 parameters as part of 8.1.5 or 8.2.1.3

             I think it fits better in 8.1.5.
                
 Optional: Events: 3-8, 12, 13-14[my suggestion]
                        19, 22
        
            Timers: Idle Hold Timer
                      Open Delay Timer

 Required flags for optional parameters:
        
                Open Delay Flag
                BGP Stop Flap

Sue said she would try to work up more if it is agreed that this is on
the right track.

This was discussed in the "Comments 30-36" thread: Comment #35.

----------------------------------------------------------------------------
55) New DelayOpen State
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: We've chosen not to reopen the debate about adding a DelayOpen
 State to the FSM.

Discussion:

Siva began with asking:

 Is delaying the sending of an OPEN message a standrad industry practice ?

 Also, in the FSM, this has been handled by practically implementing a
 sub-state each, within the CONNECT and ACTIVE states. Won't the FSM
 look more simple if we just had a new DelayOpen state that we could
 move into ?

Sue responded that this was something we have tried to do before, but that
it spawned some degree of rabid response on both sides.  Given our current
mandate to stick with what is implemented, it is probably best not to
reopen this debate.

Unless someone badly wants to reopen this debate, the issue is at Consenus.

This was discussed in the "Comments 30-36" thread: Comment #36.

--5vNYLRcllDrimb99--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA05581 for <[e-mail]>; Thu, 19 Dec 2002 19:01:35 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id AD61C91232; Thu, 19 Dec 2002 19:00:20 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D4619129C; Thu, 19 Dec 2002 19:00:20 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15B0291232 for <[e-mail]>; Thu, 19 Dec 2002 19:00:19 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 78DCE5DE6A; Thu, 19 Dec 2002 19:00:18 -0500 (EST)
Delivered-To: [e-mail]
Received: from realname (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id EDA095DDB6 for <[e-mail]>; Thu, 19 Dec 2002 19:00:17 -0500 (EST)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) id <[e-mail]> for [e-mail]; Fri, 20 Dec 2002 09:00:08 +0900 (KST)
Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 20 Dec 2002 09:00:08 +0900 (KST)
Received: from samsungy77z6fd ([165.213.70.137]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) with ESMTPA id <[e-mail]> for [e-mail]; Fri, 20 Dec 2002 09:07:23 +0900 (KST)
Date: Fri, 20 Dec 2002 08:59:19 -0800
From: Manav Bhatia <[e-mail]>
Subject: Re: Error handling in the update message..
To: Shankar Ananthanarayanan Kambat <[e-mail]>
Cc: [e-mail]
Message-id: <023c01c2a849$23031a00$8946d5a5@samsungy77z6fd>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Shankar,
If a Loc Pref is present in an UPDATE from the external peer then the Loc
Pref should be ignored and the rest of the attributes must be processed. We
must send a notification only in the extreme cases.

--Manav
----- Original Message -----
From: "Shankar Ananthanarayanan Kambat" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, December 19, 2002 6:04 AM
Subject: Error handling in the update message..


Hi,
   It is well known that LOCAL_PREF and ORIGINATOR_ID(Route Reflector
Scenario) should not be sent across autonomous system by BGP. However, if an
EBGP speaker receives an update message with such an attribute, may be due
to malfunctioning of the peer router, should it ignore the attribute or sent
a notification? I don't see an error subcode for the same in the draft/RFC.
If it is ignored will it not have any problem?

Thanks
Shankar K A




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA01849 for <[e-mail]>; Thu, 19 Dec 2002 09:05:13 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B7928912CF; Thu, 19 Dec 2002 09:04:53 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8CD1D912CE; Thu, 19 Dec 2002 09:04:53 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 45EF2912D1 for <[e-mail]>; Thu, 19 Dec 2002 09:04:52 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 2072F5DE2C; Thu, 19 Dec 2002 09:04:52 -0500 (EST)
Delivered-To: [e-mail]
Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by segue.merit.edu (Postfix) with ESMTP id BD1FF5DDAF for <[e-mail]>; Thu, 19 Dec 2002 09:04:48 -0500 (EST)
Received: from m2vwall2 (m2vwall2.wipro.com [164.164.29.236]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id gBJE4ic14651 for <[e-mail]>; Thu, 19 Dec 2002 19:34:44 +0530 (IST)
Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 19 Dec 2002 19:34:42 +0530
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-81b2487a-9120-4fd9-99f7-af568ea83ca9"
Subject: Error handling in the update message..
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Thu, 19 Dec 2002 19:34:42 +0530
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Error handling in the update message..
Thread-Index: AcKmq4jlO2oyIhOZSrS2ldGxuV73NAAuvriQ
From: "Shankar Ananthanarayanan Kambat" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 19 Dec 2002 14:04:42.0636 (UTC) FILETIME=[940104C0:01C2A767]
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPartTM-000-81b2487a-9120-4fd9-99f7-af568ea83ca9
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
   It is well known that LOCAL_PREF and ORIGINATOR_ID(Route Reflector =
Scenario) should not be sent across autonomous system by BGP. However, =
if an EBGP speaker receives an update message with such an attribute, =
may be due to malfunctioning of the peer router, should it ignore the =
attribute or sent a notification? I don't see an error subcode for the =
same in the draft/RFC. If it is ignored will it not have any problem?

Thanks=20
Shankar K A

------=_NextPartTM-000-81b2487a-9120-4fd9-99f7-af568ea83ca9
Content-Type: text/plain;
	name="Wipro_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Wipro_Disclaimer.txt"

**************************Disclaimer**************************************************    
 
 Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' 
and 'confidential' and intended for use only by the individual or entity to which it is 
addressed. You are notified that any use, copying or dissemination of the information 
contained in the E-MAIL in any manner whatsoever is strictly prohibited.

****************************************************************************************

------=_NextPartTM-000-81b2487a-9120-4fd9-99f7-af568ea83ca9--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA17042 for <[e-mail]>; Wed, 18 Dec 2002 10:38:28 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DF4C5912AF; Wed, 18 Dec 2002 10:38:04 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8C82912B0; Wed, 18 Dec 2002 10:38:04 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3B649912AF for <[e-mail]>; Wed, 18 Dec 2002 10:38:03 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1E2BB5DF84; Wed, 18 Dec 2002 10:38:03 -0500 (EST)
Delivered-To: [e-mail]
Received: from mailscan.telica.com (bouncer.telica.com [4.19.224.197]) by segue.merit.edu (Postfix) with ESMTP id 7A7CA5DFD3 for <[e-mail]>; Wed, 18 Dec 2002 10:38:02 -0500 (EST)
Received: (from root@localhost) by mailscan.telica.com (8.11.6/8.11.6) id gBIFTPg07617; Wed, 18 Dec 2002 10:29:25 -0500
Received: from ran.ietf.org (ran.ietf.org [132.151.6.60]) by mailscan.telica.com (8.11.6/8.11.6) with SMTP id gBIEahV04972 for <[e-mail]>; Wed, 18 Dec 2002 09:36:43 -0500
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18Oe3t-0006fv-00 for [e-mail]; Wed, 18 Dec 2002 08:16:33 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18Odvn-0006Qq-00 for [e-mail]; Wed, 18 Dec 2002 08:08:11 -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04734; Wed, 18 Dec 2002 08:04:44 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-as4bytes-06.txt
Date: Wed, 18 Dec 2002 08:04:43 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: BGP support for four-octet AS number space
	Author(s)	: Q. Vohra, E. Chen
	Filename	: draft-ietf-idr-as4bytes-06.txt
	Pages		: 7
	Date		: 2002-12-16
	
Currently the Autonomous System number is encoded in BGP [BGP] as a
two-octets field. This document describes extensions to BGP to carry
the Autonomous System number as a four-octets field.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-06.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-as4bytes-06.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-as4bytes-06.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-as4bytes-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-as4bytes-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA09187 for <[e-mail]>; Wed, 18 Dec 2002 08:08:22 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6474691226; Wed, 18 Dec 2002 08:07:48 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 34627912A9; Wed, 18 Dec 2002 08:07:48 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0C29191226 for <[e-mail]>; Wed, 18 Dec 2002 08:07:46 -0500 (EST)
Received: by segue.merit.edu (Postfix) id EDAB15DFCD; Wed, 18 Dec 2002 08:07:45 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 74A765DEF1 for <[e-mail]>; Wed, 18 Dec 2002 08:07:45 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04734; Wed, 18 Dec 2002 08:04:44 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-as4bytes-06.txt
Date: Wed, 18 Dec 2002 08:04:43 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: BGP support for four-octet AS number space
	Author(s)	: Q. Vohra, E. Chen
	Filename	: draft-ietf-idr-as4bytes-06.txt
	Pages		: 7
	Date		: 2002-12-16
	
Currently the Autonomous System number is encoded in BGP [BGP] as a
two-octets field. This document describes extensions to BGP to carry
the Autonomous System number as a four-octets field.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-06.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-as4bytes-06.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-as4bytes-06.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-as4bytes-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-as4bytes-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA06613 for <[e-mail]>; Mon, 16 Dec 2002 11:07:03 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D274A9123D; Mon, 16 Dec 2002 11:06:25 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A408C91261; Mon, 16 Dec 2002 11:06:25 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2C4159123D for <[e-mail]>; Mon, 16 Dec 2002 11:06:24 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 103A85DF3D; Mon, 16 Dec 2002 11:06:24 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id AA65D5DE85 for <[e-mail]>; Mon, 16 Dec 2002 11:06:23 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gBGG6MT19799; Mon, 16 Dec 2002 11:06:22 -0500 (EST) (envelope-from [e-mail])
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 gBGG6IC19792; Mon, 16 Dec 2002 11:06:18 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gBGG6Ik03488; Mon, 16 Dec 2002 11:06:18 -0500 (EST)
Date: Mon, 16 Dec 2002 11:06:18 -0500
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: Comments 21-30
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Dec 16, 2002 at 08:03:29AM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Mon, Dec 16, 2002 at 08:03:29AM -0800, Yakov Rekhter wrote:
> > From section 4.2 of -18:
> > : 4.2 OPEN Message Format
> > : 
> > :    After a TCP is established, the first message sent by each side is an
> > :    OPEN message. If the OPEN message is acceptable, a KEEPALIVE message
> > :    confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE,
> > :    KEEPALIVE, and NOTIFICATION messages may be exchanged.
> > 
> > This text implies that NOTIFICATIONs can only be sent once we
> > have sent an open and then a keepalive, generally meaning we're in the
> > Established state.
> > 
> > Anyone suggestions for modifying the wording?
> 
> I have two suggestions:
> 
> 1. Delete the last sentence in the above paragraph

I would suggest this option.

> 2. Delete "and NOTIFICATION" in the last sentence in the above paragraph

This option could be interpreted as NOTIFICATIONs not being legal here.

-- Jeff

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA06443 for <[e-mail]>; Mon, 16 Dec 2002 11:03:53 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 3872E9122D; Mon, 16 Dec 2002 11:03:33 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 042199123D; Mon, 16 Dec 2002 11:03:32 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CBB569122D for <[e-mail]>; Mon, 16 Dec 2002 11:03:31 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B9AE35DE85; Mon, 16 Dec 2002 11:03:31 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 620BF5DDA8 for <[e-mail]>; Mon, 16 Dec 2002 11:03:31 -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 gBGG3TS85345; Mon, 16 Dec 2002 08:03:29 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: Susan Hares <[e-mail]>, [e-mail]
Subject: Re: Comments 21-30 
In-Reply-To: Your message of "Thu, 12 Dec 2002 18:07:48 EST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 16 Dec 2002 08:03:29 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> > 23) Handling events 20, 21 in the Connect State and Active State
> > 
> > We need to consider the case where we receive events 20 (message
> > header error) and 21 (Open message error) when the delay timer is 
> > running.
> > 
> > Since the connection has been established at this point, we need to 
> > send a Notification message and then terminate the connection.
> > 
> > Alternative comments: 
> > 
> > 	1) We have not sent an Open statement.
> > 	2) Why do we have to send an Notification? I see no justification
> > 	   for it. 
> > 	  
> > Suggestion: 
> > 	Do you have implementations that send notification?  Do
> > 	you know of others that don't. 
> 
> This points out a potential issue.
> From section 4.2 of -18:
> : 4.2 OPEN Message Format
> : 
> :    After a TCP is established, the first message sent by each side is an
> :    OPEN message. If the OPEN message is acceptable, a KEEPALIVE message
> :    confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE,
> :    KEEPALIVE, and NOTIFICATION messages may be exchanged.
> 
> This text implies that NOTIFICATIONs can only be sent once we
> have sent an open and then a keepalive, generally meaning we're in the
> Established state.
> 
> Anyone suggestions for modifying the wording?

I have two suggestions:

1. Delete the last sentence in the above paragraph

  or 

2. Delete "and NOTIFICATION" in the last sentence in the above paragraph

Yakov.

> Section 6.1 (Message header error) is one situation that implies
> that a NOTIFICATION can be sent without sending even an OPEN message.
> Note that since the base FSM implies that we send an OPEN message
> immediately when we have a completed trasnport connection, we SHOULD
> be in at least OpenSent.  However, the DelayOpen timer means that we
> MAY send a NOTIFICATION when we are in the Connect state.
> 
> GateD, at least, will not send a NOTIFICATION without first sending
> an OPEN.
> 
> We need to pick one: You can send NOTIFICATIONS before OPEN or before
> OPEN if the OpenDelay timer is running.  However, we MUST fix the text
> above.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA15836 for <[e-mail]>; Fri, 13 Dec 2002 17:49:53 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 03546912FD; Fri, 13 Dec 2002 17:49:12 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF4A891240; Fri, 13 Dec 2002 17:49:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A279391214 for <[e-mail]>; Fri, 13 Dec 2002 17:47:39 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 7F5A75DEBD; Fri, 13 Dec 2002 17:47:39 -0500 (EST)
Delivered-To: [e-mail]
Received: from nemesis.systems.pipex.net (nemesis.systems.pipex.net [62.241.160.8]) by segue.merit.edu (Postfix) with ESMTP id 32E0A5DE5A for <[e-mail]>; Fri, 13 Dec 2002 17:47:39 -0500 (EST)
Received: from tom3 (useran15.uk.uudial.com [62.188.135.32]) by nemesis.systems.pipex.net (Postfix) with SMTP id 7240616007F8F; Fri, 13 Dec 2002 22:47:32 +0000 (GMT)
Message-ID: <011301c2a2f9$94e53180$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Jeffrey Haas" <[e-mail]>, "Susan Hares" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Comments 21-30
Date: Fri, 13 Dec 2002 22:29:23 -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: [e-mail]
Precedence: bulk

Comments in-line on 23 and 29

Tom Petch
[e-mail]

-----Original Message-----
From: Jeffrey Haas <[e-mail]>
To: Susan Hares <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: 12 December 2002 23:08
Subject: Re: Comments 21-30


>On Thu, Dec 05, 2002 at 04:21:00PM -0500, Susan Hares wrote:
>> 23) Handling events 20, 21 in the Connect State and Active State
>>
>> We need to consider the case where we receive events 20 (message
>> header error) and 21 (Open message error) when the delay timer is
>> running.
>>
>> Since the connection has been established at this point, we need to
>> send a Notification message and then terminate the connection.
>>
>> Alternative comments:
>>
>> 1) We have not sent an Open statement.
>> 2) Why do we have to send an Notification? I see no justification
>>    for it.
>>
>> Suggestion:
>> Do you have implementations that send notification?  Do
>> you know of others that don't.
>
>This points out a potential issue.
>From section 4.2 of -18:
>: 4.2 OPEN Message Format
>:
>:    After a TCP is established, the first message sent by each side
is an
>:    OPEN message. If the OPEN message is acceptable, a KEEPALIVE
message
>:    confirming the OPEN is sent back. Once the OPEN is confirmed,
UPDATE,
>:    KEEPALIVE, and NOTIFICATION messages may be exchanged.
>
>This text implies that NOTIFICATIONs can only be sent once we
>have sent an open and then a keepalive, generally meaning we're in
the
>Established state.
>
>Anyone suggestions for modifying the wording?
>
>Section 6.1 (Message header error) is one situation that implies
>that a NOTIFICATION can be sent without sending even an OPEN message.
>Note that since the base FSM implies that we send an OPEN message
>immediately when we have a completed trasnport connection, we SHOULD
>be in at least OpenSent.  However, the DelayOpen timer means that we
>MAY send a NOTIFICATION when we are in the Connect state.
>
>GateD, at least, will not send a NOTIFICATION without first sending
>an OPEN.
>
>We need to pick one: You can send NOTIFICATIONS before OPEN or before
>OPEN if the OpenDelay timer is running.  However, we MUST fix the
text
>above.


A NOTIFICATION without a preceding OPEN is rather hard to interpret;
it is the OPEN that gives the recipient what it needs to know about
its potential peer (Version, AS number, ID, options etc) so it makes
sense to send an OPEN even if it is followed by a NOTIFICATION to say
goodbye :-( as opposed to a KEEPALIVE which says hello:-).

But as ever, what is implemented?

>
>> =============================
>>
>> 26) Handling Event 17 in The connect state
>>
>> >  If the transport connection fails (timeout or transport
>> >  disconnect) [Event17], the local system:
>> >      - changes its state to Active.=20
>>
>> >If the transport connection fails when the BGP Open Delay timer is
>> > running, should we still be going into the Active state ?
>>
>> see mail thread on eventse 13-17
>
>In this particular case, I think the issue is separate from the
issues
>for events 13-17 since this isn't particular to how deep the BGP
>implementation meddles in the TCP implementation.
>
>If we are in the Connect state, because we have an incoming transport
>connection that has completed, but we have the OpenDelay timer
>running and the transport connection is closed, we can simply
>drop into Active after resetting the ConnectRetry timer and clearing
>the OpenDelay timer (if set/exists).  In the case of an unconfigured
>peer, we can discard the FSM instance.
>

Yup, makes sense to me

>> =========================================
>>
>> 29) Handling Event 2 in Active state
>>
>> >> A manual stop event[Event2], the local system:
>> >> - Sends a notification with a Cease,
>> >> - drops the Transport connection,=20
>> >
>> >These two actions are possible only if a transport connection had
=
>> > already been established. How about changing the text to
>> >
>> > % - If a transport connection had been successfully established
>> > % - Send a Notification with a Cease
>> > % - Drop the Transport Connection
>>
>> How about this text:
>>
>>  A manual stop event [Event 2], the local system
>> - Drop the TCP connection,
>> - Release all BGP resources,
>> - resets the connection retry timer [sets to zero],
>> - goes to Idle.
>
>I'm rather confused.  Under exactly what circumstances can we be
>in the Active state and have an active TCP connection at all?
>Ditto for having any BGP resources?
>
>Going to Idle is fine.
>
>
eg start with passive flag, TCP SYN received, SYN-ACK sent, ACK
received, Delay Open flag set and there we are.  Most events are now
possible either from a well-implemented remote peer or a badly
implemented remote peer.

>--
>Jeff Haas
>NextHop Technologies



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA15810 for <[e-mail]>; Fri, 13 Dec 2002 17:49:29 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id C723191214; Fri, 13 Dec 2002 17:49:11 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 37769912E1; Fri, 13 Dec 2002 17:49:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 507A491240 for <[e-mail]>; Fri, 13 Dec 2002 17:47:42 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 341F25DEBD; Fri, 13 Dec 2002 17:47:42 -0500 (EST)
Delivered-To: [e-mail]
Received: from nemesis.systems.pipex.net (nemesis.systems.pipex.net [62.241.160.8]) by segue.merit.edu (Postfix) with ESMTP id DDD0F5DE5A for <[e-mail]>; Fri, 13 Dec 2002 17:47:41 -0500 (EST)
Received: from tom3 (useran15.uk.uudial.com [62.188.135.32]) by nemesis.systems.pipex.net (Postfix) with SMTP id 76506160080B2; Fri, 13 Dec 2002 22:47:35 +0000 (GMT)
Message-ID: <011401c2a2f9$96028860$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Jeffrey Haas" <[e-mail]>, "Susan Hares" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Comments 30-36 from Siva
Date: Fri, 13 Dec 2002 22:46: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: [e-mail]
Precedence: bulk

Sue, Jeff

My comment was that if we do not send a KeepAlive (and start the
KeepAlive timer), on exiting from Active with Event 19 to OpenConfirm
then we never will and the connection will die.  Open Confirm state
means valid Open received so we must send a KeepAlive to acknowledge
the Open  (as pointed out in Jeff's other posting) and we never do it
in OpenConfirm state itself (unless the KeepAlive timer expires which
it cannot because we have not started it).

So for me,  OpenSent state Event 18 was and is correct, sending the
KeepAlive without which the connection goes no further and Active
state Event 19 needs to be brought into line.

To say that the timer is started when entering Established state is
fine except for a slight problem; we have no way in this FSM of
defining actions that are taken on entering a state, only actions to
be taken on leaving another state so that is why the KeepAlive actions
need to be where they are (or are not in the case of Active state
Event 19).

Tom Petch
[e-mail]

-----Original Message-----
From: Jeffrey Haas <[e-mail]>
To: Susan Hares <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: 12 December 2002 23:22
Subject: Re: Comments 30-36 from Siva


>Sue,
>
>On Thu, Dec 05, 2002 at 04:18:18PM -0500, Susan Hares wrote:
>> 33) Handling Event 18 in the OpenSent state
>>
>> >Why do we start the Keepalive timer at this stage ? Isn't it
sufficient =
>> >to do so when we move into Established state ?
>>
>> An earlier comment from Tom (and you) requested the following:
>>
>> <---Open
>> [Open sent state]
>>
>> Open-->
>> [Event 18]
>>
>> <---Open
>> <---Keepalive
>> [Action from Event 18 in Open Sent]
>> [Open Confirm]
>> Keepalive -> [Event 25]
>>
>> [established]
>
>I'm assuming the second OPEN going from right to left is a typo.
>If it isn't, thats a FSM error to the peer on the left.
>
>Theoretically, an implementation that utilizes its keepalive timer
>to send the first keepalive to transition to Established is
>still interoperable.  However:
>
>o Keepalives can be disabled by negotiating hold time of zero
>o We really shouldn't need to restart the Keepalive timer.
>  If there is a delay in the keepalive that transitions from
>  OpenConfirm to Established, its due to the transport connection.
>  It should be reliable and it *should* get through.  If it
>  doesn't, there's other problems and the hold timer for the
>  peer on the right should do the Right Thing and drop the
>  connection.
>
>> What do implementations do?  We'll have to query implementations.
>
>GateD at least waits to enter the Established state prior to starting
>the KeepAlive timer.
>
>--
>Jeff Haas
>NextHop Technologies



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA12792 for <[e-mail]>; Fri, 13 Dec 2002 16:52:22 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5787C912FC; Fri, 13 Dec 2002 16:51:46 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 249F2912FD; Fri, 13 Dec 2002 16:51:46 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 05554912FC for <[e-mail]>; Fri, 13 Dec 2002 16:51:36 -0500 (EST)
Received: by segue.merit.edu (Postfix) id E36A35E005; Fri, 13 Dec 2002 16:51:35 -0500 (EST)
Delivered-To: [e-mail]
Received: from nemesis.systems.pipex.net (nemesis.systems.pipex.net [62.241.160.8]) by segue.merit.edu (Postfix) with ESMTP id 332785DDFF for <[e-mail]>; Fri, 13 Dec 2002 16:51:35 -0500 (EST)
Received: from tom3 (userbf91.uk.uudial.com [62.188.142.112]) by nemesis.systems.pipex.net (Postfix) with SMTP id CA27016007448; Fri, 13 Dec 2002 21:51:24 +0000 (GMT)
Message-ID: <004c01c2a2f1$be159a20$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Susan Hares" <[e-mail]>, "Sivananda Ramnath - CTD, Chennai." <[e-mail]>, "Yakov Rekhter" <[e-mail]>, "Jeffrey Haas" <[e-mail]>
Cc: "idr" <[e-mail]>, "Venu Kumar G - CTD, Chennai." <[e-mail]>
Subject: Re: Response to FSM input - Comments 1-10
Date: Fri, 13 Dec 2002 21:49:56 -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: [e-mail]
Precedence: bulk

Sue, Siva

Please can we stay with the terms

Open Delay timer
peer oscillation damping

in any new text (as previously agreed on the list).

There are some new variations confusing their way into the text you
are suggesting below.

Tom Petch
[e-mail]

-----Original Message-----
From: Susan Hares <[e-mail]>
To: Sivananda Ramnath - CTD, Chennai. <[e-mail]>; Yakov
Rekhter <[e-mail]>; Jeffrey Haas <[e-mail]>
Cc: [e-mail] <[e-mail]>; Venu Kumar G - CTD, Chennai.
<[e-mail]>
Date: 09 December 2002 21:46
Subject: RE: Response to FSM input - Comments 1-10

Siva:

Thanks for such a quick turn around.

So.. our summary is

1 - consensus, no text change
2 - no consensus, see text change
3 - mostly consensus,
Policy in implementations may dictate some options
      per peer and some options per implementation. I
suggest we specify the list you came up with plus
Idle Hold Timer in 8.0.

4 - consensus, text change [done]
5 - no consensus, see comment below
5a - answer question [no text intended]
5b.1 - text proposed
5b.2 - your text or mine?

6 - consensus on text, answer given below
7 - no consensus, text proposal below

2 of the 3 events could be considered infeasible.
The 3rd event all add.  Please review the text.

8 - consensus, no text change
9 - consensus, text change [done]
10 - consensus, text changed [done]

Note 9 + 10 are taken together

Comments to resolve: 2,3, 5, 7,

Thanks for the quick response.

Sue Hares

=====================

Comment 2 -

    Event8: Idle hold timer expires

           Definition: An Event generated when the Idle Hold Timer
           expires.  The Idle Hold Timer is only used
                       when the persistent peer oscillation
                       damping function is enabled.
%
%      Implementations not implemented persistent
%      peer oscillations damping functions may not
%       have the Idle Hold Timer.

Is this approach ok?
============

Comment 3

The following will be added to 8.0

Optional parameters that may be supported either per
connection or per implementation:

1) Delay Open flag
2) Delay Open Timer
3) Perform automatic start flag
4) Passive TCP establishment flag
5) BGP stop_peer_flag flag
%6) Idle Hold timer
7) Perform automatic stop flag
8) Perform Collision detect in Establish mode flag

=====================
Comment 4: consensus, change made to Event 1 and 2

===============
Comment 5:

5a:
Automatic stop and stop are implemented by cisco's policy
engine.  The origination of the damping peer oscillation was
in result to a bug that was listed in comment 5.

5b:

1.) Example of "automatic disconnect" in Established state

  Is the text you wanted moved:
    An example automatic stop event is exceeding the number of
    prefixes for a given peer and the local system
    automatically disconnecting the peer.

  If so, I can move this to the automatic stop event

2.) Text describing the optional parameters.

We can add text for the optional parameters to
describe their function.  Can you propose some text?
======================
Comment 6

>  I am ok to leave the text as is, based on text in 8.2.1.1. However,
>  I do not quite understand your point. In the case of an
un-configured
> peer, the local system cannot 'establish a connection', so is the
>  unconfigured peer case still valid in this context ?

Unconfigured + passive TCP connection + Delay Open is valid.

============================================
Comment 7

>
>
>   We already have
>   Event 3 - Automatic Start
>   Event 5 - Automatic start with bgp_stop_flap option set
>
>
>  To make things consistent, shouldn't we either
>
>  a) Add 3 new events :  1) Manual start with bgp_stop flap option
set
>                         2) Manual start with passive TCP
establishment
>                            and bgp_stop_flap option set
>                         3) Automatic start with passive TCP
establishment
>                            and bgp_stop_flap option set

I like option A, it is clearer.

The Manual start or stop terminates the bgp peer oscillation damping.
The theory is the operator "did" something, therefore the events need
to
chagne.  Since these events do not have valid implementation in the
peer flap damping, I did not include them.

#3 is something I missed.  I will add that event.  Is that resolution
OK, or
I can put all 3 new events in.

=========================



-----Original Message-----
From: Sivananda Ramnath - CTD, Chennai. [mailto:[e-mail]]
Sent: Friday, December 06, 2002 6:05 AM
To: Susan Hares; Yakov Rekhter; Jeffrey Haas
Cc: [e-mail]; Sivananda Ramnath (E-mail); Venu Kumar G - CTD,
Chennai.
Subject: RE: Response to FSM input - Comments 1-10


Hello,

Revised summary:

Comment 1 - No text change, Potential consensus
Comment 2a - No consensus
Comment 2b - No consensus
Comment 3 - New text suggested, no consensus
Comment 4 - Resolved, text changed. Can we consider this closed ?
Comment 5 - No text change, Potential consensus
Comment 6 - No consensus
Comment 7 - No consensus, comment re-phrased.
Comment 8 - No text change, potential consensus
Comment 9 - Resolved, text changed. Can we consider this closed ?
Comment 10 - Resolved, text changed. Can we consider this closed ?

>
> Comment 1 - no consensus
> Comment 2a - out of date (No IdleHold Timer exists)
> Comment 2b - no consensus, can't remove due to OpenSent state
> action.
>
> Comment 3 - no text proposed, do we want all options
> specified in 8.1 (7 options)
> Please review and comment on text
>
> Comment 4 - agree
> Comment 5 - no text proposed, no consensus
> Comment 6 - no consensus on the text
> Comment 7 - see comment 3, no consensus
> Comment 8 - question, no text
> Comment 9 - agree, I supplied text
> Comment 10 - agree to remove text in option,
> different text for definition.
>
>
> Sue Hares
>
> ==========
>
> comment 1:
>
> 1) removal of peer oscillation damping
>
> The reason we should not remove the peer oscillation damping
> from the state machine:
>
>   1) Deployed implementations support peer oscillation damping
>   2) Hooks for the additions in the FSM cannot be added later.
>
> These hooks are optional and do not need to be implemented.

  I understand. I am not trying to object to peer oscillation
  damping, I think it is a good idea and we have included it in
  our implementation as well. I was suggesting that instead of
  a partial description in this draft, it be completely described
  in the draft on peer oscillation damping.

  However, I do see your point, and unless there are any objections
  from others, I think we have consensus on this issue.

>
>
> 2) Idle HoldTimer in draft-18
>
>   Perhaps this is an old comment.  I don't find IdleHoldTimer
>   in the messages.

    It is listed as Event 8. Perhaps this is what needs to be
    removed ?

>
> 3) HoldTime and HoldTimer
>
>    The Hold Time is specified on page 13 of the draft-18
specification
>    as to the value and size.  The text in OpenSent requires
>    both a HoldTime and HoldTimer value.
> ===========
>    OpenSent:
>
>     In this state BGP waits for an Open Message from its peer.
[SNIP]
>
> ===================

  I understand. However, on this basis, we would also need a Keepalive
  time (since the basis on wihch this is be arrived at can be
  configurable). I don't know whether we do need to make such changes
  to the draft, and I am OK to leaving this portion as it stands.

> The earlier comments on the list indicated we need to collect what
> timers or Timer values were utilized in the FSM.  I believe Alex
> made this comment last January.  (the list archives will have
> this information.)
>
> So, I don't see any way to

  The DelayBgpOpenTimer is missing from the session attributes list,
  how about including it ?

>
> Comment 3: optional parameters specified
>
> Please suggest text.  We have the following optional parameters:
>
> 1) Delay Open
> 2) Accept unconfigured peers
> 3) automatic start [Event 3]
> 4) passive TCP establishment (optional)
> 4 + 5 = Event 5
> 5) BGP_stop_flap (BGP Peer oscillation) [Event 6]
> 6)automatic stop [Event 7]
> 7)Collision detect in Established State
>
> If you want some of the optional parameters specified, let's
> catch all.  Please suggest text and location.  It could
> go in 8.1.

  My view is this can be split into two categories:

  Optional attributes exist per session, and optional attributes
  for the entire system.

  How about adding the following to section 8 (immediately before 8.1)

%  Optional session attributes that a implementation may support
%  for a session are:
%
%    1) DelayOpen flag
%    2) DelayOpen Timer
%    3) Perform automatic start
%    4) Passive TCP establishment
%    5) Perform automatic stop
%    6) BGP Perform
%
%
%  Implementations may also support the following optinal attributes
%  that modify the behavior of the state machine
%
%    1) Accept un-configured peers
%    2) Perform collision detect in Established state

    I guess it is possible to have some of these things listed under
    both categories. Am I opening up a can of worms here ?  :-)

> --------------------------------
> Comment 4
>
> Old Text:
>   Event 1: Manual Start
>       Definition: Administrator manually starts peer connection.
>
>  ...
>   Event 2: Manual Stop
> Definition: Local system administrator manually stops the
>        peer connection.
> New Text:
>   Event1: Manual start
>        Definition: Local system administrator manually starts the
>        bgp connection.
>
>   ...
>   Event 2: Manual stop:
>   Definition: Local system administrator manually stops the
>   bgp connection.
>
> agree?

  Agreed.

> ---------------
> Comment 5:
>
> 5) Event3, Event5, Event6 and Event7
>
> 5a)
> =========
>   Event 3/6/7 - cisco indicated the automatic stop, see the NANOG
>   archives for a discussion of the Bad Route
>
>     http://www.merit.edu/mail.archives/nanog/2001-06/msg00805.html
>
>   The "event" sequences are new with this version of the FSM
>   to identify particular events by number.

    I am unclear on what this issue is!

> 5b
> ======
>
>   Can we give examples of these events, as implemneted by curent
>   implementations ? This will be of help to new implementaions.
>
>   An example of Auto Stop is already present in the Update event
>   handling section, and we can move that to this place as well.
>
> I believe that examples are outside the scope of this specification.
> If you have text clarifying the event descriptions, please send it
in.

  Well, the current text in the established state already gives an
example
  for an automatic start event. I was suggesting that such examples be
  moved to the event description section.

  I also think adding text to clarify the intent behind optional
events,
  and giving examples would help, especially for new implementors.
However,
  if you feel this is outside the scope of the RFC, we can leave
things
  as is.


>
>
> =======================================================
>
> 6) Event 4,5 Definition
>
> >    Definition: Administrator manually start the peer
> >                       Connection, but has the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing the connection.
>
>
> >   Definition:  Local system automatically starts the
> >                       BGP session with the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing a connection.
>
>
> >My understanding is this is used to indicate a peer configuration
> >where we start the state machine, and wait for an incoming
connection
> >request from the configured peer. Can we re-phrase this section to
> >indicate this.
>
> >How about something like:
> >
> >% The passive flag indicates that the state machine will wait for
> >% specified peer to initiate a connection with the local system. If
> >% this does not happen within a specific time (hold time), the
local
> >% system will then also attempt to initiate connection with the
> >% specified peer.
>
> The text in 8.2.1.1 indicates the definition of the passive flag.

   Yes.
>
> 6a)
> ==========
> My understanding of your text is that you want to replace in both
> sets of text:
>
> "The passive flag indicates the peer will listen prior to
>  establishing a connection".
>
> with:
>
> "The passive flag indicates that the state machine will wait for the
> specified peer to initiate a connection with a local system.
>
> The problem with this sentence is that in the "unconfigured" case
> the phrase "specified" peer is confusing.  I think the original text
> is clearer.

  I am ok to leave the text as is, based on text in 8.2.1.1. However,
  I do not quite understand your point. In the case of an
un-configured
  peer, the local system cannot 'establish a connection', so is the
  unconfigured peer case still valid in this context ?

> 6b)
> ==========
> If this does not happen within a specific time (hold time), the
local
> system will then also attempt to initiate (a) connection with the
> specified peer.
>
> My comments: Again, the "specified peer" term is confusing.  Also,
> the 2nd half of the statement mixes the actions of the state machine
> with the events.  I believe this muddies the text instead of
> clarifying it.

  Please refer to my comments for 6a.

  I think a reason for this is the requirement (in 8.2.1) that a FSM
be
  established a-priori for "accepting each incoming TCP connection for
  which the peer has not beet identified".

  Is the intent to establish a FSM session for accepting TCP
connections
  from un-configured peers ? If so, I am of the opinion that this is
  purely an implementation issue, and need not be a requirement in the
spec.

>
> =================
> Comment 7 -
>
> Event 6 - (not specified, please confirm)
>
> >  Won't a variant of this with bgp_stop_flap option set be requried
?
> >  We can also achieve the same by using the bgp_stop-Flap option as
a
> >  flag that is provided as an input to the state machine.
>
> see comment number 3.  bgp_stop_flap is an option.
>
> This state machine description has many events to describe the
> mixture of options and actions.  I believe it has a better clarity
> than testing lots of flags within a state.
>
> A proof in case, is that many people are making comments about
> specific transitions.

   I tink I should have phrased my question much better.

   We already have
   Event 3 - Automatic Start
   Event 5 - Automatic start with bgp_stop_flap option set

   To make things consistent, shouldn't we either

   a) Add 3 new events : 1) Manual start with bgp_stop flap option set
                         2) Manual start with passive TCP
establishment
                            and bgp_stop_flap option set
                         3) Automatic start with passive TCP
establishment
                            and bgp_stop_flap option set

   or

   b) Remove Event 6, and rely on a flag to tell us wether peer flap
damping
      is to be performed for the session or not.


>
> ============
> Comment 8 -
>
>
> 8) Event 5 Definition
>
> >   Definition:  Local system automatically starts the
> >                       BGP session with the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing a connection.
>
> > Is it correct that this event will occur only when we want
> to restart
> > a connection (after it had been terminated due to some reason besi
de
> > administrative action) that we had accepted from an
> unconfigured peer ?
>
> The automatic start function is an implementation specific
mechanism.
> This text does not seek to restrict it in any fashion.

  Well, for new implementors, such clarifications will help undertsand
  how to generate and make use of this event. Again, I am OK with
  leaving text as is.

>
> ================
> 9) Timer Events Definition
>
> > Event8:  idle Hold timer expires=20
> >
> >           Definition: Idle Hold timer expires.  The Idle=20
> >
> > Event9: connect retry timer expires
> >
> >           Definition: An event triggered by the expiration of=20
> > Event10: hold time expires
> >
> >    Definition: An event generated when the HoldTimer=20
>
> We can use any one of these terms (trigerred by/generated
> when) for all
> timer event definitions to make it look more consistent.
>
> agree: Will use "generate"
>
> Event 8: An event generated when the Idle Hold timer expires.
> Event 9: An event generated when the ConnectRetry timer expires.
> Event 10: An event generated when the Hold timer expires.
> Event 11: An event generated when the Keepalive timer expires
> Event 12: An event generated when the Delay BGP Open timer expires.
>
> Please confirm that this change to the definitions is agreeable to
> you.

  Agreed.

  I think we have consensus on this issue, unless anyone else
  has any comments on this.

>
> ================
> 10) Event 8 Definition
>
> > Event8:  idle Hold timer expires=20
> >
> >           Definition: Idle Hold timer expires.  The Idle=20
> >                       Hold Timer is only used when persistent =20
> >                       BGP oscillation damping functions are=20
> >                       enabled. =20
> >
> >           Status: Optional.  Used when persistent
> > BGP peer oscillation damping functions
> > are enabled.=20
>
>
> The status repeats the senetnce in the definition. Can we remove the
> sentence from the Status, or replace with a different definition.
>
> Do you think the defenition below would fit ?
>
> % An event trigerred by the expiry of the Idle Hold timer,
indicating
> % that the session has completed waiting for a back-off period to
> % prevent flap, and may now proceed to take any further systemm
> % initiated action for this session.
>
> text change suggestion for 1st sentence that I'll agree to.
>
>  An event trigerred by the expiry of the Idle Hold timer, indicating
>  that the session has completed waiting for a back-off period to
>  prevent bgp peer oscillation.
>
> Please confirm that you will agree to this.

  Agreed.
  I think we have consensus on this issue, unless anyone else
  has any comments on this.


Siva
([e-mail])>


Original text of comments 1-10 follow:


>
> ------- Message 4
>
> Date:    Fri, 29 Nov 2002 19:46:06 +0530
> From:    "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
> To:      [e-mail], Yakov Rekhter <[e-mail]>
> cc:      [e-mail]
> Subject: Comments on draft 18
>
> 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_000_01C297B1.DB0F1700
> Content-Type: text/plain;
> charset="iso-8859-1"
>
> Hello,
>
>     Attached are some comments that I have on
draft-ietf-idr-bgp4-18.
>
>     Please have a look at these and tell me if the same can
> be raised to the
> mailing list as well.
>
> Thanks,
> Siva
> ([e-mail])
>
>
>
> - ------_=_NextPart_000_01C297B1.DB0F1700
> Content-Type: text/plain;
> name="BGP_Issues.txt"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: attachment;
> filename="BGP_Issues.txt"
>
> All quoted sections of the original document have been
> prefixed by a '> =
> '
> All lines of proposed text have been prefixed by a '% '
>
>
> 1) Performing of peer oscillation damping:
>
> Since this feature is going to be added in a new draft, and its
> addition will change the operation of the state machine, can we
remove
> all mention of it in the state machine ? As part of this removal,
can
> we also remove the IdleHold Timer from the FSM since it is not
useful
> in the absence of peer oscillation damping ?
>
> The draft that describes this procedure can then describe the change
> in the state machine required to do this.
>
>
> 2) Session Attributes:
>
> > Session Attributes required for each connection are;=20
>
> >   1) state
> >   2) Connect Retry timer
> >   3) Hold timer
> >   4) Hold time
> >   5) Keepalive timer
>
> Why have a Hold Timer and a Hold Time ? Can we replace this with
just
> Hold timer ?
>
> Can we also add the following session attributes:
>
> a) DelayBgpOpenTimer
> b) IdleHold Timer (in case we choose not to remove this from the bas
=
> FSM)
>
> Can we also add the following flag to the session attributes:
> a) DelayOpen Flag
>
> 3) All sessions attributes:
>
>   There are some attributes that are common to all sessions of the =
> system.
>   Can we call these out as well:
>
>   * Accept Connections from unconfigured peers (Enabled/Disabled)
>   * Peer Oscillation Dampening (Enabled/Disabled) (In case we choose
>     not to remove it from base spec)
>
> 4) Description for Event1/Event2
>
> > Event1: Manual start=20
> >
> >    Definition: Administrator manually starts peer
> >                       connection
>
> > Event2: Manual stop
>
> >    Definition: Local system administrator manually=20
> >                       stops the peer connection.
>
> We can make these look consistent by using the Term Administrator or
> Local System administrator in both cases.
>
> 5) Event3, Event5, Event6 and Event7
>
>   Can we give examples of these events, as implemneted by curent
>   implementations ? This will be of help to new implementaions.
>
>   An example of Auto Stop is already present in the Update event
>   handling section, and we can move that to this place as well.
>
> 6) Event 4,5 Definition
>
> >    Definition: Administrator manually start the peer
> >                       Connection, but has the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing the connection.
>
> >   Definition:  Local system automatically starts the
> >                       BGP session with the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing a connection.
>
> My understanding is this is used to indicate a peer configuration
> where we start the state machine, and wait for an incoming
connection
> request from the configured peer. Can we re-phrase this section to
> indicate this.
>
> How about something like:
>
> % The passive flag indicates that the state machine will wait for
> % specified peer to initiate a connection with the local system. If
> % this does not happen within a specific time (hold time), the local
> % system will then also attempt to initiate connection with the
> % specified peer.
>
> 7) Event 4,5
>
>   Won't a variant of this with bgp_stop_flap option set be requried
?
>   We can also achieve the same by using the bgp_stop-Flap option as
a
>   flag that is provided as an input to the state machine.
>
> 8) Event 5 Definition
>
> >   Definition:  Local system automatically starts the
> >                       BGP session with the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing a connection.
>
> Is it correct that this event will occur only when we want to
restart
> a connection (after it had been terminated due to some reason beside
> administrative action) that we had accepted from an
> unconfigured peer ?
>
> 9) Timer Events Definition
>
> > Event8:  idle Hold timer expires=20
> >
> >           Definition: Idle Hold timer expires.  The Idle=20
> >
> > Event9: connect retry timer expires
> >
> >           Definition: An event triggered by the expiration of=20
> > Event10: hold time expires
> >
> >    Definition: An event generated when the HoldTimer=20
>
> We can use any one of these terms (trigerred by/generated
> when) for all
> timer event definitions to make it look more consistent.
>
> 10) Event 8 Definition
>
> > Event8:  idle Hold timer expires=20
> >
> >           Definition: Idle Hold timer expires.  The Idle=20
> >                       Hold Timer is only used when persistent =20
> >                       BGP oscillation damping functions are=20
> >                       enabled. =20
> >
> >           Status: Optional.  Used when persistent
> > BGP peer oscillation damping functions
> > are enabled.=20
>
> The status repeats the senetnce in the definition. Can we remove the
> sentence from the Status, or replace with a different definition.
>
> Do you think the defenition below would fit ?
>
> % An event trigerred by the expiry of the Idle Hold timer,
indicating
> % that the session has completed waiting for a back-off period to
> % prevent flap, and may now proceed to take any further systemm
> % initiated action for this session.






Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA12713 for <[e-mail]>; Fri, 13 Dec 2002 16:51:55 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E002A912FA; Fri, 13 Dec 2002 16:51:30 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD146912FC; Fri, 13 Dec 2002 16:51:30 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 43F3F912FA for <[e-mail]>; Fri, 13 Dec 2002 16:51:29 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 2A0705E00B; Fri, 13 Dec 2002 16:51:29 -0500 (EST)
Delivered-To: [e-mail]
Received: from nemesis.systems.pipex.net (nemesis.systems.pipex.net [62.241.160.8]) by segue.merit.edu (Postfix) with ESMTP id D31425E005 for <[e-mail]>; Fri, 13 Dec 2002 16:51:28 -0500 (EST)
Received: from tom3 (userbf91.uk.uudial.com [62.188.142.112]) by nemesis.systems.pipex.net (Postfix) with SMTP id A908816008BB3; Fri, 13 Dec 2002 21:51:21 +0000 (GMT)
Message-ID: <004b01c2a2f1$bb97c8e0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Susan Hares" <[e-mail]>, "idr" <[e-mail]>
Cc: "Jeffrey Haas" <[e-mail]>
Subject: Event 19 in Open Sent state was Re: bgp18 WG Last Call fsm missing keepalive
Date: Fri, 13 Dec 2002 21:46: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: [e-mail]
Precedence: bulk

Sue

You asked if event 19 (Open with OpenDelay timer running) was possible
in OpenSent state; I gave a lengthy reply (below) to the effect yes it
could because the OpenDelay timer did not always get stopped but the
timer should be stopped in which case the event would not happen.

Reading your responses to Siva , I see you include stopping the Open
Delay timer in the action 'release all BGP resources' when going to
Idle (which I missed seeing earlier in the year).

That eliminates most but not all of the possibilities I mentioned.  I
now believe we would need to add the action 'stop OpenDelay timer' for

Connect state
event 17 (currently defined as going to Active)
event 9 (stays in Connect state)

in order to stop event 19 in Open Sent

Tom Petch
[e-mail]

-----Original Message-----
From: Tom Petch <[e-mail]>
To: Susan Hares <[e-mail]>; idr <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>
Date: 05 December 2002 19:02
Subject: Re: bgp18 WG Last Call fsm missing keepalive


>Sue


<snip>

>2) complicated.  As the fsm text stands,  Event 19, along with a host
>of others, takes us back from Open Sent  to Idle (I assume on the
>grounds this is an error condition) which seems very reasonable.
>
>But ...in quite a few places, such as Connect state events 2,
>7,8,9,10,11, 17, 18, 20 thru 27, we do not stop the OpenDelay timer
>when going to Idle or Active so we could then go from eg Idle with
>Manual start [event 1] to Connect to Open Sent all before the
>OpenDelay timer expires in which case event 19 can occur validly in
>Open Sent - obscure but possible. (This is also true with Active
state
>and events 2, 17 and the default list at the end).
>
>But I think this is an error, and that when exiting Connect state or
>Active state as listed above, we should have an additional action to
>stop the OpenDelay timer in which case event 19 in Open Sent becomes
>an error condition (again).
>
>But but but as ever, I cannot speak with authority for
implementations
>and so if implementations do not stop the OpenDelay timer when
exiting
>as above, then Event 19 is valid in Open Sent state - obscure but
>possible (again).
>
>My wish is to add the extra action, stop OpenDelay timer, for the
>events listed above in Active and Connect states in the expectation
>that that is what people have or should have implemented.
>
>Tom Petch
>[e-mail]
>
>-----Original Message-----
>From: Susan Hares <[e-mail]>
>To: Tom Petch <[e-mail]>; idr <[e-mail]>
>Cc: Jeffrey Haas <[e-mail]>
>Date: 04 December 2002 19:50
>Subject: RE: bgp18 WG Last Call fsm missing keepalive
>
>
>Tom:
>
<snip>

>2) Do you think that Event 19 is possible in the Open Sent state?
>
>Please answer this separately.
>
>Thanks for all the wonderful review of the State machine.
>I'm working my way through the comments.
>
>Sue
>
>-



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA04346 for <[e-mail]>; Fri, 13 Dec 2002 14:31:54 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 7449C912F7; Fri, 13 Dec 2002 14:31:28 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF8EF912F8; Fri, 13 Dec 2002 14:31:27 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7C083912F7 for <[e-mail]>; Fri, 13 Dec 2002 14:31:26 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 33C155DFCC; Fri, 13 Dec 2002 14:31:01 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 609575DF45 for <[e-mail]>; Fri, 13 Dec 2002 14:31:00 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA52205; Fri, 13 Dec 2002 14:30:50 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: deterministic-med 
In-reply-to: Your message of "Fri, 13 Dec 2002 12:37:00 EST." <[e-mail]> 
Date: Fri, 13 Dec 2002 14:30:50 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> Is any reason why someone would want 'non-deterministic-med' behavior, I do
> not.  Maybe I missed something.
> 
> thnx

I don't agree with it but I've heard the argument that if there are
two or more routes and one route flaps they'd rather just lock in one
that doesn't flap.  I haven't heard that argument in a while.  The
obvious counter argument is persistent route loops make customers very
unhappy and route damping does the job.

Curtis


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA27934 for <[e-mail]>; Fri, 13 Dec 2002 12:37:27 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 9811691209; Fri, 13 Dec 2002 12:37:03 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61D72912EE; Fri, 13 Dec 2002 12:37:03 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3931891209 for <[e-mail]>; Fri, 13 Dec 2002 12:37:02 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 14AB95DDE0; Fri, 13 Dec 2002 12:37:02 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id D0F255DDB2 for <[e-mail]>; Fri, 13 Dec 2002 12:37:01 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <YN1W9ASW>; Fri, 13 Dec 2002 12:37:01 -0500
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail], [e-mail]
Subject: deterministic-med
Date: Fri, 13 Dec 2002 12:37:00 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Is any reason why someone would want 'non-deterministic-med' behavior, I do
not.  Maybe I missed something.

thnx


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA01598 for <[e-mail]>; Thu, 12 Dec 2002 18:23:01 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6C07D912E7; Thu, 12 Dec 2002 18:22:34 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B6B1912E8; Thu, 12 Dec 2002 18:22:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0307E912E7 for <[e-mail]>; Thu, 12 Dec 2002 18:22:32 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D95675DE1A; Thu, 12 Dec 2002 18:22:32 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 7E6D25DDAB for <[e-mail]>; Thu, 12 Dec 2002 18:22:32 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gBCNMVV55750; Thu, 12 Dec 2002 18:22:31 -0500 (EST) (envelope-from [e-mail])
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 gBCNMSC55743; Thu, 12 Dec 2002 18:22:28 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gBCNMS709777; Thu, 12 Dec 2002 18:22:28 -0500 (EST)
Date: Thu, 12 Dec 2002 18:22:28 -0500
From: Jeffrey Haas <[e-mail]>
To: Susan Hares <[e-mail]>
Cc: [e-mail]
Subject: Re: Comments 30-36 from Siva
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Dec 05, 2002 at 04:18:18PM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Sue,

On Thu, Dec 05, 2002 at 04:18:18PM -0500, Susan Hares wrote:
> 33) Handling Event 18 in the OpenSent state
> 
> >Why do we start the Keepalive timer at this stage ? Isn't it sufficient =
> >to do so when we move into Established state ?
> 
> An earlier comment from Tom (and you) requested the following:
> 
> 		<---Open
> 			[Open sent state]
> 
> 	Open-->	
> 			[Event 18]
> 			
> 		<---Open
> 		<---Keepalive
> 			[Action from Event 18 in Open Sent]
> 			[Open Confirm]
> 	Keepalive -> [Event 25]
> 			
> 			[established]

I'm assuming the second OPEN going from right to left is a typo.
If it isn't, thats a FSM error to the peer on the left.

Theoretically, an implementation that utilizes its keepalive timer
to send the first keepalive to transition to Established is
still interoperable.  However:

o Keepalives can be disabled by negotiating hold time of zero
o We really shouldn't need to restart the Keepalive timer.
  If there is a delay in the keepalive that transitions from
  OpenConfirm to Established, its due to the transport connection.
  It should be reliable and it *should* get through.  If it
  doesn't, there's other problems and the hold timer for the
  peer on the right should do the Right Thing and drop the
  connection.

> What do implementations do?  We'll have to query implementations.

GateD at least waits to enter the Established state prior to starting
the KeepAlive timer.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA00799 for <[e-mail]>; Thu, 12 Dec 2002 18:08:22 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BBDFA912E4; Thu, 12 Dec 2002 18:07:59 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D4B0912E6; Thu, 12 Dec 2002 18:07:59 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 366D0912E4 for <[e-mail]>; Thu, 12 Dec 2002 18:07:57 -0500 (EST)
Received: by segue.merit.edu (Postfix) id CAACF5DDFA; Thu, 12 Dec 2002 18:07:57 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 6AA055DDD2 for <[e-mail]>; Thu, 12 Dec 2002 18:07:57 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gBCN7uo55062; Thu, 12 Dec 2002 18:07:56 -0500 (EST) (envelope-from [e-mail])
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 gBCN7mC55049; Thu, 12 Dec 2002 18:07:48 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gBCN7mt09636; Thu, 12 Dec 2002 18:07:48 -0500 (EST)
Date: Thu, 12 Dec 2002 18:07:48 -0500
From: Jeffrey Haas <[e-mail]>
To: Susan Hares <[e-mail]>
Cc: [e-mail]
Subject: Re: Comments 21-30
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Dec 05, 2002 at 04:21:00PM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Dec 05, 2002 at 04:21:00PM -0500, Susan Hares wrote:
> 23) Handling events 20, 21 in the Connect State and Active State
> 
> We need to consider the case where we receive events 20 (message
> header error) and 21 (Open message error) when the delay timer is 
> running.
> 
> Since the connection has been established at this point, we need to 
> send a Notification message and then terminate the connection.
> 
> Alternative comments: 
> 
> 	1) We have not sent an Open statement.
> 	2) Why do we have to send an Notification? I see no justification
> 	   for it. 
> 	  
> Suggestion: 
> 	Do you have implementations that send notification?  Do
> 	you know of others that don't. 

This points out a potential issue.
>From section 4.2 of -18:
: 4.2 OPEN Message Format
: 
:    After a TCP is established, the first message sent by each side is an
:    OPEN message. If the OPEN message is acceptable, a KEEPALIVE message
:    confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE,
:    KEEPALIVE, and NOTIFICATION messages may be exchanged.

This text implies that NOTIFICATIONs can only be sent once we
have sent an open and then a keepalive, generally meaning we're in the
Established state.

Anyone suggestions for modifying the wording?

Section 6.1 (Message header error) is one situation that implies
that a NOTIFICATION can be sent without sending even an OPEN message.
Note that since the base FSM implies that we send an OPEN message
immediately when we have a completed trasnport connection, we SHOULD
be in at least OpenSent.  However, the DelayOpen timer means that we
MAY send a NOTIFICATION when we are in the Connect state.

GateD, at least, will not send a NOTIFICATION without first sending
an OPEN.

We need to pick one: You can send NOTIFICATIONS before OPEN or before
OPEN if the OpenDelay timer is running.  However, we MUST fix the text
above.

> =============================
> 
> 26) Handling Event 17 in The connect state
> 
> >  If the transport connection fails (timeout or transport
> >  disconnect) [Event17], the local system:
> >      - changes its state to Active.=20
> 
> >If the transport connection fails when the BGP Open Delay timer is
> > running, should we still be going into the Active state ?
> 
> see mail thread on eventse 13-17

In this particular case, I think the issue is separate from the issues
for events 13-17 since this isn't particular to how deep the BGP 
implementation meddles in the TCP implementation.

If we are in the Connect state, because we have an incoming transport
connection that has completed, but we have the OpenDelay timer
running and the transport connection is closed, we can simply
drop into Active after resetting the ConnectRetry timer and clearing
the OpenDelay timer (if set/exists).  In the case of an unconfigured
peer, we can discard the FSM instance.

> =========================================
> 
> 29) Handling Event 2 in Active state
> 
> >> A manual stop event[Event2], the local system:
> >>	- Sends a notification with a Cease,
> >>	- drops the Transport connection,=20
> > 
> >These two actions are possible only if a transport connection had =
> > already been established. How about changing the text to
> >
> > % - If a transport connection had been successfully established
> > % - Send a Notification with a Cease
> > % - Drop the Transport Connection
> 
> How about this text:
> 
>  A manual stop event [Event 2], the local system
> 	- Drop the TCP connection, 
> 	- Release all BGP resources,
> 	- resets the connection retry timer [sets to zero],
> 	- goes to Idle.

I'm rather confused.  Under exactly what circumstances can we be
in the Active state and have an active TCP connection at all?
Ditto for having any BGP resources?

Going to Idle is fine.


-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA28177 for <[e-mail]>; Thu, 12 Dec 2002 17:19:45 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 83A5E912E5; Thu, 12 Dec 2002 17:16:30 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5BA3912E4; Thu, 12 Dec 2002 17:16:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 27747912E2 for <[e-mail]>; Thu, 12 Dec 2002 17:16:24 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 27C0D5DEC5; Thu, 12 Dec 2002 17:16:01 -0500 (EST)
Delivered-To: [e-mail]
Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by segue.merit.edu (Postfix) with ESMTP id 7E60D5DE3C for <[e-mail]>; Thu, 12 Dec 2002 17:16:00 -0500 (EST)
Received: from tom3 (userbh03.uk.uudial.com [62.188.142.222]) by shockwave.systems.pipex.net (Postfix) with SMTP id 69CAB16001ADD; Thu, 12 Dec 2002 22:15:54 +0000 (GMT)
Message-ID: <001c01c2a22b$feb0faa0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>, "Susan Hares" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, <[e-mail]>
Cc: "Venu Kumar G - CTD, Chennai." <[e-mail]>
Subject: Re: Comments 11-20
Date: Thu, 12 Dec 2002 22:13:53 -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: [e-mail]
Precedence: bulk

Comments  ** in line

Tom Petch [e-mail]

-----Original Message-----
From: Sivananda Ramnath - CTD, Chennai. <[e-mail]>
To: Susan Hares <[e-mail]>; Yakov Rekhter
<[e-mail]>;[e-mail] <[e-mail]>
Cc: Venu Kumar G - CTD, Chennai. <[e-mail]>
Date: 10 December 2002 18:09
Subject: RE: Comments 11-20


>    Revised summary:
>
>    11 - No consensus, but current text can stand as is
>         any comments from others ?

** these are two distinct timers, two distinct events (KeepAlive 11
and Hold 10) so keep the existing text
>
>    12 - text changed, potential consensus
** Open Delay timer in any new text please

>    13a - text changed, potential consensus
>    13b - no change, potential consensus

**I found and find
** Transport Connection Indication & valid remote peer
**verbose and clumsy to read and write and suggested/suggest
** 13 Transport connection valid indication
** 14 Transport connection invalid indication
**at most, even cutting the names down to three words if possible.
** There remains plenty of scope for verbosity in the textual
description although I think we should beware of nailing it down too
tightly.  eg Invalid in a security conscious system might come to mean
this address has been added to a black list on account of its recent
malicious behaviour, perhaps dynamically blocking some source port
numbers on account of denial of service attacks.  While valid in a lax
implementation could mean anything goes, even port 179.  I am ok with
the existing description.
> >

>    14 - additional comments, no consensus
>        Note: No consensus on one part only
>    15 - Consensus, author's choice.
>    16 - Agree to your comments.
>         Have clarified original comment,
>         proposed some text.
** Open Delay timer in any new text please
>    17 - consensus
** Open Delay timer in any new text please
>    18 - text revised, potential consensus
>    19 - no change, potential consensus
>    20 - text changed, potential consensus
>
>
>> Here's the summary of 11-20
>>
>> comment:
>>
>> 11 - no consensus, no text supplied
>>
>>     note: usage varies from my understanding
>>     of common usage.
>>
>> 12 - consensus, no text supplied
>>      see comment 9 and proposed text below.
>>
>> 13a - no consensus, see alternate text
>> 13b - no consensus, implementation specific detail
>>
>> 14 - no consensus, disagree with comment
>> policy issues, outside scope of document
>>
>> 15 - no consensus, see alternative text.
>> 16 - no consensus, see my proposed text.
>>
>> You did not propose text
>>       See alternate text for events 13-17
>> Also note, that I consider that
>> events 13 and 14 should go to
>> optional.
>>
>> 17 - consensus, agree to change in text.
>> 18 - agree needs to be fixed, see my alternative text.
>> 19 - further clarity needed,
>> please respond to question
>>
>> 20 - agree, text will be changed
>>
>>
>> Sue
>>
>> =====================
>>
>> 11) Event 10 (Hold timer)
>>
>>   We use the hold timer for two purposes
>>
>>   * Waiting for an open message (with a default value of 240
seconds)
>>   * Waiting for Keepalives (with a default value of 90 seconds)
>>
>>   Can we use two different timers (or at least call them two
different
>>   timer events) ?
>>
>> Siva: I do not believe that most implementatios
>>       utilize two timers.  Can you indicate implementations
>> that do?
>
>   Implementations can certainly use a single timer, since at any
time
>   at most only one of these two timers will need to be running.
>
>   The reason for the comment is that conceptually these are two
>   different timers:
>
>   One is a standard (or configurable) value, and is used to wait for
an
>   Open Message.
>
>   The other is negotiated, and is used to wait for Keepalives.
>
>   I feel that representing these as two different events will make
the
>   state machine look better. Of course, nothing prevents an
implementation
>   from achieving this by using the same timer, or any other means as
long
>   the same effect is realized; so existing implementations will not
be
>   affected in any fashion.
>
>   I am not very particular on this issue, since things will work
fine
>   with the current means as well, do others have any comments on
>   modeling this as two separate events in the state machine ?
>
>>
>> ==============================================================
>> =========
>> 12) Event 12
>>
>> > Event12: DelayBGP Open timer expires [changed]
>> >
>> >    Definition: A timer that delays sending of the BGP
>> >                Open message for n seconds after the
>> >                       Transport connection has been completed.=
>>
>> >The Definition seems to better define what the timer is,
>> rather than =
>> > what
>> > its expiry means. Can we change it to reflect this ?
>>
>> new text:  see comment on 9 on Timer definition,
>>      and earlier change.
>>
>> Event 12: An event generated when the Delay BGP Open timer expires.
>> =========================================
>>
>
>  Ok.
>  Can we add any text on the need or use of a Delay Open ?
>
>
>> 13) Event 13, 14 definition
>>
>> > Event13: Transport Connection Indication & valid remote
>> peer[changed]
>> >
>> >    Definition: Event indicating that TCP connection
>> >                       request with a valid source IP address and
TCP
>> >                       port, and valid destination IP address
>> >                       and TCP Port.  The definition of
>> >                       invalid Source, and invalid Destination=
>> >                       IP address is left to the implementation.
>>
>>
>> a) How about changing this slighty to:
>> %    Definition: Event indicating receiving a TCP connection
>> %                       request with a valid source IP address and
TCP
>> %                       port, and valid destination IP address=
>> %                       and TCP Port.  The definition of invalid
>> My completion of  your sentence:
>> source, and invalid destination
>> IP address
>> is left to the implementation.
>>
>> How about:
>> Definition: Event indicating the reception of a TCP connection
>> request with a valid source IP address and TCP
>> port, and valid destination IP address and
>> TCP Port.  The definition of invalid
>> source address
>> and port and invalid destination address
>> is left to the implementation.
>>
>>
>> Please comment if you agree with this change.
>
>  This looks good.
>
>>
>> b) Is it correct that Destination IP address validation is
>> used when we
>> do not wish to accept BGP connections on one of the local IP
addresses
>> (either because we wish to accept such addresses on only our
loopback
>> interfaces, or because the address to which we received the
connection
>> was not the optimal interface with which to speak to the sender) ?
If
>> so, can we add this to the description ?
>>
>>
>> No, this is an implementation dependent change.
>
>  Ok. Again, if there are any validations that are considered
>  desirable, adding this to the draft text as a suggestion to
>  implementers would be useful.
>
>  We can leave things as is if you feel that such details should
>  be left out of the draft.
>
>
>> ==============================================================
>> ===================
>
>
>>
>> 14) Event 13,14
>>
>> > Event13: Transport Connection Indication & valid remote
>> peer[changed]
>> >
>> >    Definition: Event indicating that transport
>> >                       Request valid source IP address and TCP=20
>> >                       port, and valid destination IP address=20
>> >                       and TCP Port.  The definition of=20
>> >                       invalid Source, and invalid Destination=20
>> >                       IP address is left to the implementation.
>> >
>> > a) I am unclear as to what validation of source and
>> destination port =
>> > mean.
>> >
>> > The source port's value should be of no concern to connection =
>> > receipient system.
>>
>> The definition of "valid" is an implementation policy issue.
>> Validating is the process of checking to make sure it is valid
>> for the implementation's policy.
>
>    Ok.
>
>>
>> > The destination port cannot be invalid, since BGP would not
>> receive the
>> > connection request in such a situation.
>>
>> Again, this is a policy issue.  We are providing hooks for
>> policy to be engaged.  Policy is outside the scope of this
>> document.
>
>   Isn't this more than just a policy issue ? It seems difficult
>   to identify a connection destined to a port other than to
>   the one on which BGP is running as an error event for BGP.
>   So, I don't understand how a policy can be applied in this
>   regard.
>
>>
>> > b) I think it will be useful to state what we consider to
>> be an invalid
>> > IP address.
>>
>> Again, it is policy issue which is implementation dependent.
>
>    Ok.
>
>>
>> ====================
>> 15) Event 17
>>
>> > Event17: TCP connection fails
>>
>> > This event can occur even when the transport connection is closed
by
>> > the other end. Since this does not reflect a 'failure ',
>> can we change
>> > the event name to
>> >
>> > % Event17: TCP connection termination
>>
>> Discussion:  It both terminates from the remote site
>> and can "timeout" - fail.
>>
>> Suggestions? I can use "disconnect", what do you think.
>
>  That looks fine too. I don't know what the best words
>  to describe this are. Also, the description for this
>  event does a good job of explaining this, so either
>  the original text (connection fails) or your suggestion
>  (disconnect) can be used.
>  This really should not have been raised as a comment. :-)
>
>> ==========================
>>
>> 16) Events related to BGP Messages
>>
>> Can we make the definition style across these events consistent ?
>>
>> thanks for the comment.
>> proposed text below, please agree on it.
>
>  Yes, the text below looks fine.
>
>  I should have phrased the original comment much better, I was
>  referring to consistency across the following: Events 18, 19,
>  20, 21 vs. Events 23, 24, 25, 26, 27.
>
>  This is a very minor issue, so not making these changes is fine
>  too. The way the latter events are described
>  are different from the former. I suggest adopting the style for
>  Events 23-27 for Events 18-21.
>
>  As per this, the following changes would have to be made:
>
>>       Event18: BGPOpen
>>
>>              Definition:  An event indicating that a valid Open
>>                  message has been received.
>
>    with
>
>%       Event18: BGPOpen
>%
>%              Definition:  An event is generated when a valid Open
>%                           message has been received.
>
>>       Event19: BGPOpen with BGP Delay Open Timer running
>>
>>              Definition: An event indicating that a valid Open
>>                          message has been successful
>>                          established for a peer that is
>>                          currently delaying the sending of an
>>                          BGP Open message.
>
>   with
>
>%       Event19: BGPOpen with BGP Delay Open Timer running
>%
>%              Definition: An event is generated when a valid Open
>%                          message has been received for a peer that
>%                          is currently delaying the sending of a
>%                          BGP Open message.
>
>>       Event20: BGPHeaderErr
>>
>>           Definition: BGP message header is not valid.
>
>   with
>
>%       Event20: BGPHeaderErr
>%
>%           Definition: An event is generated when a received BGP
>%                       message header is not valid.
>
>>       Event21: BGPOpenMsgErr
>>
>>           Definition: An BGP Open message has been received
>>                          with errors.
>
>    with
>
>%       Event21: BGPOpenMsgErr
>%
>%           Definition: An event is generated when BGP Open message
>%                       with errors has been received.
>
>
>>
>> proposed text replacement
>> ------------------------
>>     Event13: TCP connection indication and valid remote peer
>>
>>            Definition: Event indicating the local system reception
of
>>        a TCP connection request with a valid source
>>                        IP address and TCP port, and valid
destination
>>                        IP address and TCP Port. The definition of
>>                        invalid source, and invalid destination
>>                        IP address is left to the implementation.
>>
>>                        BGP's destination port SHOULD be port
>>                        179 as defined by IANA.
>>
>>                        TCP connection request is denoted by
>>                        the local system receiving a TCP SYN.
>>
>>            Status:     Mandatory (Optional)
>>
>>
>>     Event14: RCV TCP connection indication with invalid source or
>>              destination
>>
>>            Definition: Event indicating the local system reception
of
>>        a TCP connection request with either
>>                        an invalid source address or port
>>                        number or an invalid destination
>>                        address or port number.
>>
>>                        BGP destination port  number SHOULD be 179
>>                        as defined by IANA.
>>
>>                        Again, a TCP connection request
>>                        denoted by local system receiving a TCP
>>                        SYN.
>>
>>            Status:     Mandatory (Optional)
>>
>>     Event15: TCP connection request sent received an ACK.
>>
>>            Definition: Event indicating the Local system's request
>>                        to establish a TCP connection to the remote
>>                        peer.
>>
>>                        The local system's TCP session sent a TCP
>>                        SYN, and received a TCP SYN, ACK pair of
>>                        messages, and Sent a TCP ACK.
>>
>>            Status:     Mandatory
>>
>>     Event16: TCP connection confirmed
>>
>>            Definition: Event indicates that the local system
receiving
>>        a confirmation that the TCP connection has
>>                        been established by the remote site.
>>
>>                        The remote peer's TCP engine sent a TCP SYN.
>>                        The local peer's TCP engine sent a SYN, ACK
>>                        pair, and now has received a final ACK.
>>
>>            Status:     Mandatory
>>
>>     Event17: TCP connection fails
>>
>>            Definition: Event indicates that the local system has
>>                        received a TCP connection failure notice.
>>
>>                        The remote BGP peer's TCP machine could have
>>                        sent a FIN.  The local peer would respond
>>                        with a FIN-ACK. Another alternative is that
>>                        the local peer indicated a timeout in the
>>                        TCP session and downed the connection.
>>
>>            Status:     Mandatory
>>
>> ---------------------
>>
>>
>> 17) Event 19 Definition
>>
>> > Event19: BGPOpen with BGP Delay Open Timer running [changed]
>> >
>> >           Definition: An event indicating that a valid Open=20
>> >                       Message has been successful=20
>> >                       established for a peer that is=20
>> >                       currently delaying the sending of an=20
>> >                       BGP Open message.=20
>>
>>
>> The definition appears a little fragmented. How about:
>>
>> % Definition: An event indicating that a valid OPEN
>> %             Message has been received for a peer
>> %             that has a successfully established
>> %             transport connection and is currently
>> %             delaying the seending of a BGP open
>> %             message
>>
>>
>> agreed, changed in text.  I will send out definition
>> text for review in a separate message.
>
>  Ok.
>
>> ==============================================================
>> 18) Event 22 Definition
>>
>> a)=20
>>
>> > Event22: Open collision discard
>> >
>> >           Definition: An event generated administratively=20
>> >                       when a connection Collision has been=20
>> >                       detected while processing an incoming =20
>> >                       Open message. This connection has been=20
>>
>> Isn't this event 'automatically' generated, since it is a system
>> generated event ?=20
>>
>> response: How this generated is implementation specific.  The
>>           "administratively" is to cover policy.
>>
>> b)
>>
>> >                       Event 22 is an administrative could=20
>> >                       occur if FSM is implemented as two=20
>> >
>>
>> The word event is missing. How about
>>
>> %                       Event 22 is an automatic event that
>> %                       could occur if FSM is implemented as two=20
>>
>>
>> I've re-written the whole definition.  What do you think about:
>>
>>    Event22: Open collision dump
>>
>>            Definition: An event generated administratively
>>                        when a connection collision has been
>>                        detected while processing an incoming
>>                        OPEN message and this connection has been
>>                        selected to disconnected. See Section
>>                        6.8 for more information on collision
>>                        detection.
>>
>>                        Event22 is an administrative based only
>>            implementation specific policy. This
>>            Event may occur if the FSM is implemented
>>            as two linked state machines.
>>
>> Please confirm that you like this.
>
>  Agreed.
>
>>
>> ====================================
>> 19) FSM Description: ConnectRetry Count
>>
>> > The Connect Retry count is updated by the FSM but never used. In
the
>> > absence of peer oscillation damping, will this be used to stop
>> > connection establishment attempts after a certain maximum number
?
>>
>> Yes, this is either implementation specific or
>> is it based on the peer oscillation damping draft.
>>
>> > Can we include the use of this counter in some place ?
>>
>> Connect retry counter
>> 1) Will be utilized by the peer oscillation
>> damping drat.
>> 2) Will be included in bgp-4-mibv2-xx.
>> I just check and I didn't find it.
>>
>> Do you still want text in the main
>
>  We can leave the main text as is.
>
>>
>> ====================================
>>
>> 20) Handling Event 7 (Auto Stop) to Idle State processing:
>>
>> The handling of Event 7 is missing from the Idle State processing.
Can
>> we add this ? How about replacing
>>
>> > An manual stop event (Event2) is ignored in the Idle state.
>>
>> with
>>
>> % Manual stop (Event 2) and Auto stop (Event 7) events are ignored
>> % in the Idle state
>>
>> we'll add that in the text.
>
>  Ok.
>
>>
>> ==============================
>>
>
>Siva
>([e-mail])





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA27984 for <[e-mail]>; Thu, 12 Dec 2002 17:16:54 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 7B7FD912E3; Thu, 12 Dec 2002 17:16:30 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85DC3912E2; Thu, 12 Dec 2002 17:16:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9310B912E3 for <[e-mail]>; Thu, 12 Dec 2002 17:16:24 -0500 (EST)
Received: by segue.merit.edu (Postfix) id DD5A75DE12; Thu, 12 Dec 2002 17:16:04 -0500 (EST)
Delivered-To: [e-mail]
Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by segue.merit.edu (Postfix) with ESMTP id 21DB05DE3C for <[e-mail]>; Thu, 12 Dec 2002 17:16:04 -0500 (EST)
Received: from tom3 (userbh03.uk.uudial.com [62.188.142.222]) by shockwave.systems.pipex.net (Postfix) with SMTP id 01A0C160009C6; Thu, 12 Dec 2002 22:16:00 +0000 (GMT)
Message-ID: <001d01c2a22c$010d3a20$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>, "Susan Hares" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, "idr" <[e-mail]>
Cc: "Venu Kumar G - CTD, Chennai." <[e-mail]>
Subject: Re: Comments 11-20
Date: Thu, 12 Dec 2002 22:14:39 -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: [e-mail]
Precedence: bulk

Comments  ** in line

Tom Petch [e-mail]

-----Original Message-----
From: Sivananda Ramnath - CTD, Chennai. <[e-mail]>
To: Susan Hares <[e-mail]>; Yakov Rekhter
<[e-mail]>;[e-mail] <[e-mail]>
Cc: Venu Kumar G - CTD, Chennai. <[e-mail]>
Date: 10 December 2002 18:09
Subject: RE: Comments 11-20


>    Revised summary:
>
>    11 - No consensus, but current text can stand as is
>         any comments from others ?

** these are two distinct timers, two distinct events (KeepAlive 11
and Hold 10) so keep the existing text
>
>    12 - text changed, potential consensus
** Open Delay timer in any new text please

>    13a - text changed, potential consensus
>    13b - no change, potential consensus

**I found and find
** Transport Connection Indication & valid remote peer
**verbose and clumsy to read and write and suggested/suggest
** 13 Transport connection valid indication
** 14 Transport connection invalid indication
**at most, even cutting the names down to three words if possible.
** There remains plenty of scope for verbosity in the textual
description although I think we should beware of nailing it down too
tightly.  eg Invalid in a security conscious system might come to mean
this address has been added to a black list on account of its recent
malicious behaviour, perhaps dynamically blocking some source port
numbers on account of denial of service attacks.  While valid in a lax
implementation could mean anything goes, even port 179.  I am ok with
the existing description.
> >

>    14 - additional comments, no consensus
>        Note: No consensus on one part only
>    15 - Consensus, author's choice.
>    16 - Agree to your comments.
>         Have clarified original comment,
>         proposed some text.
** Open Delay timer in any new text please
>    17 - consensus
** Open Delay timer in any new text please
>    18 - text revised, potential consensus
>    19 - no change, potential consensus
>    20 - text changed, potential consensus
>
>
>> Here's the summary of 11-20
>>
>> comment:
>>
>> 11 - no consensus, no text supplied
>>
>>     note: usage varies from my understanding
>>     of common usage.
>>
>> 12 - consensus, no text supplied
>>      see comment 9 and proposed text below.
>>
>> 13a - no consensus, see alternate text
>> 13b - no consensus, implementation specific detail
>>
>> 14 - no consensus, disagree with comment
>> policy issues, outside scope of document
>>
>> 15 - no consensus, see alternative text.
>> 16 - no consensus, see my proposed text.
>>
>> You did not propose text
>>       See alternate text for events 13-17
>> Also note, that I consider that
>> events 13 and 14 should go to
>> optional.
>>
>> 17 - consensus, agree to change in text.
>> 18 - agree needs to be fixed, see my alternative text.
>> 19 - further clarity needed,
>> please respond to question
>>
>> 20 - agree, text will be changed
>>
>>
>> Sue
>>
>> =====================
>>
>> 11) Event 10 (Hold timer)
>>
>>   We use the hold timer for two purposes
>>
>>   * Waiting for an open message (with a default value of 240
seconds)
>>   * Waiting for Keepalives (with a default value of 90 seconds)
>>
>>   Can we use two different timers (or at least call them two
different
>>   timer events) ?
>>
>> Siva: I do not believe that most implementatios
>>       utilize two timers.  Can you indicate implementations
>> that do?
>
>   Implementations can certainly use a single timer, since at any
time
>   at most only one of these two timers will need to be running.
>
>   The reason for the comment is that conceptually these are two
>   different timers:
>
>   One is a standard (or configurable) value, and is used to wait for
an
>   Open Message.
>
>   The other is negotiated, and is used to wait for Keepalives.
>
>   I feel that representing these as two different events will make
the
>   state machine look better. Of course, nothing prevents an
implementation
>   from achieving this by using the same timer, or any other means as
long
>   the same effect is realized; so existing implementations will not
be
>   affected in any fashion.
>
>   I am not very particular on this issue, since things will work
fine
>   with the current means as well, do others have any comments on
>   modeling this as two separate events in the state machine ?
>
>>
>> ==============================================================
>> =========
>> 12) Event 12
>>
>> > Event12: DelayBGP Open timer expires [changed]
>> >
>> >    Definition: A timer that delays sending of the BGP
>> >                Open message for n seconds after the
>> >                       Transport connection has been completed.=
>>
>> >The Definition seems to better define what the timer is,
>> rather than =
>> > what
>> > its expiry means. Can we change it to reflect this ?
>>
>> new text:  see comment on 9 on Timer definition,
>>      and earlier change.
>>
>> Event 12: An event generated when the Delay BGP Open timer expires.
>> =========================================
>>
>
>  Ok.
>  Can we add any text on the need or use of a Delay Open ?
>
>
>> 13) Event 13, 14 definition
>>
>> > Event13: Transport Connection Indication & valid remote
>> peer[changed]
>> >
>> >    Definition: Event indicating that TCP connection
>> >                       request with a valid source IP address and
TCP
>> >                       port, and valid destination IP address
>> >                       and TCP Port.  The definition of
>> >                       invalid Source, and invalid Destination=
>> >                       IP address is left to the implementation.
>>
>>
>> a) How about changing this slighty to:
>> %    Definition: Event indicating receiving a TCP connection
>> %                       request with a valid source IP address and
TCP
>> %                       port, and valid destination IP address=
>> %                       and TCP Port.  The definition of invalid
>> My completion of  your sentence:
>> source, and invalid destination
>> IP address
>> is left to the implementation.
>>
>> How about:
>> Definition: Event indicating the reception of a TCP connection
>> request with a valid source IP address and TCP
>> port, and valid destination IP address and
>> TCP Port.  The definition of invalid
>> source address
>> and port and invalid destination address
>> is left to the implementation.
>>
>>
>> Please comment if you agree with this change.
>
>  This looks good.
>
>>
>> b) Is it correct that Destination IP address validation is
>> used when we
>> do not wish to accept BGP connections on one of the local IP
addresses
>> (either because we wish to accept such addresses on only our
loopback
>> interfaces, or because the address to which we received the
connection
>> was not the optimal interface with which to speak to the sender) ?
If
>> so, can we add this to the description ?
>>
>>
>> No, this is an implementation dependent change.
>
>  Ok. Again, if there are any validations that are considered
>  desirable, adding this to the draft text as a suggestion to
>  implementers would be useful.
>
>  We can leave things as is if you feel that such details should
>  be left out of the draft.
>
>
>> ==============================================================
>> ===================
>
>
>>
>> 14) Event 13,14
>>
>> > Event13: Transport Connection Indication & valid remote
>> peer[changed]
>> >
>> >    Definition: Event indicating that transport
>> >                       Request valid source IP address and TCP=20
>> >                       port, and valid destination IP address=20
>> >                       and TCP Port.  The definition of=20
>> >                       invalid Source, and invalid Destination=20
>> >                       IP address is left to the implementation.
>> >
>> > a) I am unclear as to what validation of source and
>> destination port =
>> > mean.
>> >
>> > The source port's value should be of no concern to connection =
>> > receipient system.
>>
>> The definition of "valid" is an implementation policy issue.
>> Validating is the process of checking to make sure it is valid
>> for the implementation's policy.
>
>    Ok.
>
>>
>> > The destination port cannot be invalid, since BGP would not
>> receive the
>> > connection request in such a situation.
>>
>> Again, this is a policy issue.  We are providing hooks for
>> policy to be engaged.  Policy is outside the scope of this
>> document.
>
>   Isn't this more than just a policy issue ? It seems difficult
>   to identify a connection destined to a port other than to
>   the one on which BGP is running as an error event for BGP.
>   So, I don't understand how a policy can be applied in this
>   regard.
>
>>
>> > b) I think it will be useful to state what we consider to
>> be an invalid
>> > IP address.
>>
>> Again, it is policy issue which is implementation dependent.
>
>    Ok.
>
>>
>> ====================
>> 15) Event 17
>>
>> > Event17: TCP connection fails
>>
>> > This event can occur even when the transport connection is closed
by
>> > the other end. Since this does not reflect a 'failure ',
>> can we change
>> > the event name to
>> >
>> > % Event17: TCP connection termination
>>
>> Discussion:  It both terminates from the remote site
>> and can "timeout" - fail.
>>
>> Suggestions? I can use "disconnect", what do you think.
>
>  That looks fine too. I don't know what the best words
>  to describe this are. Also, the description for this
>  event does a good job of explaining this, so either
>  the original text (connection fails) or your suggestion
>  (disconnect) can be used.
>  This really should not have been raised as a comment. :-)
>
>> ==========================
>>
>> 16) Events related to BGP Messages
>>
>> Can we make the definition style across these events consistent ?
>>
>> thanks for the comment.
>> proposed text below, please agree on it.
>
>  Yes, the text below looks fine.
>
>  I should have phrased the original comment much better, I was
>  referring to consistency across the following: Events 18, 19,
>  20, 21 vs. Events 23, 24, 25, 26, 27.
>
>  This is a very minor issue, so not making these changes is fine
>  too. The way the latter events are described
>  are different from the former. I suggest adopting the style for
>  Events 23-27 for Events 18-21.
>
>  As per this, the following changes would have to be made:
>
>>       Event18: BGPOpen
>>
>>              Definition:  An event indicating that a valid Open
>>                  message has been received.
>
>    with
>
>%       Event18: BGPOpen
>%
>%              Definition:  An event is generated when a valid Open
>%                           message has been received.
>
>>       Event19: BGPOpen with BGP Delay Open Timer running
>>
>>              Definition: An event indicating that a valid Open
>>                          message has been successful
>>                          established for a peer that is
>>                          currently delaying the sending of an
>>                          BGP Open message.
>
>   with
>
>%       Event19: BGPOpen with BGP Delay Open Timer running
>%
>%              Definition: An event is generated when a valid Open
>%                          message has been received for a peer that
>%                          is currently delaying the sending of a
>%                          BGP Open message.
>
>>       Event20: BGPHeaderErr
>>
>>           Definition: BGP message header is not valid.
>
>   with
>
>%       Event20: BGPHeaderErr
>%
>%           Definition: An event is generated when a received BGP
>%                       message header is not valid.
>
>>       Event21: BGPOpenMsgErr
>>
>>           Definition: An BGP Open message has been received
>>                          with errors.
>
>    with
>
>%       Event21: BGPOpenMsgErr
>%
>%           Definition: An event is generated when BGP Open message
>%                       with errors has been received.
>
>
>>
>> proposed text replacement
>> ------------------------
>>     Event13: TCP connection indication and valid remote peer
>>
>>            Definition: Event indicating the local system reception
of
>>        a TCP connection request with a valid source
>>                        IP address and TCP port, and valid
destination
>>                        IP address and TCP Port. The definition of
>>                        invalid source, and invalid destination
>>                        IP address is left to the implementation.
>>
>>                        BGP's destination port SHOULD be port
>>                        179 as defined by IANA.
>>
>>                        TCP connection request is denoted by
>>                        the local system receiving a TCP SYN.
>>
>>            Status:     Mandatory (Optional)
>>
>>
>>     Event14: RCV TCP connection indication with invalid source or
>>              destination
>>
>>            Definition: Event indicating the local system reception
of
>>        a TCP connection request with either
>>                        an invalid source address or port
>>                        number or an invalid destination
>>                        address or port number.
>>
>>                        BGP destination port  number SHOULD be 179
>>                        as defined by IANA.
>>
>>                        Again, a TCP connection request
>>                        denoted by local system receiving a TCP
>>                        SYN.
>>
>>            Status:     Mandatory (Optional)
>>
>>     Event15: TCP connection request sent received an ACK.
>>
>>            Definition: Event indicating the Local system's request
>>                        to establish a TCP connection to the remote
>>                        peer.
>>
>>                        The local system's TCP session sent a TCP
>>                        SYN, and received a TCP SYN, ACK pair of
>>                        messages, and Sent a TCP ACK.
>>
>>            Status:     Mandatory
>>
>>     Event16: TCP connection confirmed
>>
>>            Definition: Event indicates that the local system
receiving
>>        a confirmation that the TCP connection has
>>                        been established by the remote site.
>>
>>                        The remote peer's TCP engine sent a TCP SYN.
>>                        The local peer's TCP engine sent a SYN, ACK
>>                        pair, and now has received a final ACK.
>>
>>            Status:     Mandatory
>>
>>     Event17: TCP connection fails
>>
>>            Definition: Event indicates that the local system has
>>                        received a TCP connection failure notice.
>>
>>                        The remote BGP peer's TCP machine could have
>>                        sent a FIN.  The local peer would respond
>>                        with a FIN-ACK. Another alternative is that
>>                        the local peer indicated a timeout in the
>>                        TCP session and downed the connection.
>>
>>            Status:     Mandatory
>>
>> ---------------------
>>
>>
>> 17) Event 19 Definition
>>
>> > Event19: BGPOpen with BGP Delay Open Timer running [changed]
>> >
>> >           Definition: An event indicating that a valid Open=20
>> >                       Message has been successful=20
>> >                       established for a peer that is=20
>> >                       currently delaying the sending of an=20
>> >                       BGP Open message.=20
>>
>>
>> The definition appears a little fragmented. How about:
>>
>> % Definition: An event indicating that a valid OPEN
>> %             Message has been received for a peer
>> %             that has a successfully established
>> %             transport connection and is currently
>> %             delaying the seending of a BGP open
>> %             message
>>
>>
>> agreed, changed in text.  I will send out definition
>> text for review in a separate message.
>
>  Ok.
>
>> ==============================================================
>> 18) Event 22 Definition
>>
>> a)=20
>>
>> > Event22: Open collision discard
>> >
>> >           Definition: An event generated administratively=20
>> >                       when a connection Collision has been=20
>> >                       detected while processing an incoming =20
>> >                       Open message. This connection has been=20
>>
>> Isn't this event 'automatically' generated, since it is a system
>> generated event ?=20
>>
>> response: How this generated is implementation specific.  The
>>           "administratively" is to cover policy.
>>
>> b)
>>
>> >                       Event 22 is an administrative could=20
>> >                       occur if FSM is implemented as two=20
>> >
>>
>> The word event is missing. How about
>>
>> %                       Event 22 is an automatic event that
>> %                       could occur if FSM is implemented as two=20
>>
>>
>> I've re-written the whole definition.  What do you think about:
>>
>>    Event22: Open collision dump
>>
>>            Definition: An event generated administratively
>>                        when a connection collision has been
>>                        detected while processing an incoming
>>                        OPEN message and this connection has been
>>                        selected to disconnected. See Section
>>                        6.8 for more information on collision
>>                        detection.
>>
>>                        Event22 is an administrative based only
>>            implementation specific policy. This
>>            Event may occur if the FSM is implemented
>>            as two linked state machines.
>>
>> Please confirm that you like this.
>
>  Agreed.
>
>>
>> ====================================
>> 19) FSM Description: ConnectRetry Count
>>
>> > The Connect Retry count is updated by the FSM but never used. In
the
>> > absence of peer oscillation damping, will this be used to stop
>> > connection establishment attempts after a certain maximum number
?
>>
>> Yes, this is either implementation specific or
>> is it based on the peer oscillation damping draft.
>>
>> > Can we include the use of this counter in some place ?
>>
>> Connect retry counter
>> 1) Will be utilized by the peer oscillation
>> damping drat.
>> 2) Will be included in bgp-4-mibv2-xx.
>> I just check and I didn't find it.
>>
>> Do you still want text in the main
>
>  We can leave the main text as is.
>
>>
>> ====================================
>>
>> 20) Handling Event 7 (Auto Stop) to Idle State processing:
>>
>> The handling of Event 7 is missing from the Idle State processing.
Can
>> we add this ? How about replacing
>>
>> > An manual stop event (Event2) is ignored in the Idle state.
>>
>> with
>>
>> % Manual stop (Event 2) and Auto stop (Event 7) events are ignored
>> % in the Idle state
>>
>> we'll add that in the text.
>
>  Ok.
>
>>
>> ==============================
>>
>
>Siva
>([e-mail])





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA06373 for <[e-mail]>; Tue, 10 Dec 2002 13:09:36 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 15530912A9; Tue, 10 Dec 2002 13:09:08 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C255C912AB; Tue, 10 Dec 2002 13:09:07 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9C96C912A9 for <[e-mail]>; Tue, 10 Dec 2002 13:09:05 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 820BB5DEF5; Tue, 10 Dec 2002 13:09:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id E75575DEE8 for <[e-mail]>; Tue, 10 Dec 2002 13:09:01 -0500 (EST)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <YT9SJPJY>; Tue, 10 Dec 2002 23:48:30 +0530
Message-ID: <[e-mail]>
From: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
To: Susan Hares <[e-mail]>, Yakov Rekhter <[e-mail]>, Jeffrey Haas <[e-mail]>, [e-mail]
Cc: "Venu Kumar G - CTD, Chennai." <[e-mail]>
Subject: RE: Comments 11-20
Date: Tue, 10 Dec 2002 23:41:06 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hello,

    Revised summary:

    11 - No consensus, but current text can stand as is
         any comments from others ?

    12 - text changed, potential consensus

    13a - text changed, potential consensus
    13b - no change, potential consensus
    14 - additional comments, no consensus
        Note: No consensus on one part only
    15 - Consensus, author's choice.
    16 - Agree to your comments.
         Have clarified original comment,
         proposed some text.
    17 - consensus
    18 - text revised, potential consensus
    19 - no change, potential consensus
    20 - text changed, potential consensus


> Here's the summary of 11-20
> 
> comment:
> 
> 11 - no consensus, no text supplied  
> 	
>     note: usage varies from my understanding
> 	    of common usage.
> 
> 12 - consensus, no text supplied 
>      see comment 9 and proposed text below.
> 
> 13a - no consensus, see alternate text 
> 13b - no consensus, implementation specific detail
> 
> 14 - no consensus, disagree with comment
> 	policy issues, outside scope of document
> 	
> 15 - no consensus, see alternative text.
> 16 - no consensus, see my proposed text.  
> 
> 	You did not propose text 
>       See alternate text for events 13-17
> 	Also note, that I consider that
> 	events 13 and 14 should go to 
> 	optional.
> 
> 17 - consensus, agree to change in text. 
> 18 - agree needs to be fixed, see my alternative text.
> 19 - further clarity needed,
> 	 please respond to question
> 
> 20 - agree, text will be changed
> 
> 
> Sue 
>  
> =====================
> 
> 11) Event 10 (Hold timer)
> 
>   We use the hold timer for two purposes
> 
>   * Waiting for an open message (with a default value of 240 seconds)
>   * Waiting for Keepalives (with a default value of 90 seconds)
> 
>   Can we use two different timers (or at least call them two different
>   timer events) ?
> 
> Siva: I do not believe that most implementatios
>       utilize two timers.  Can you indicate implementations
> 	that do? 

   Implementations can certainly use a single timer, since at any time
   at most only one of these two timers will need to be running.

   The reason for the comment is that conceptually these are two
   different timers:

   One is a standard (or configurable) value, and is used to wait for an
   Open Message.

   The other is negotiated, and is used to wait for Keepalives.

   I feel that representing these as two different events will make the
   state machine look better. Of course, nothing prevents an implementation
   from achieving this by using the same timer, or any other means as long
   the same effect is realized; so existing implementations will not be
   affected in any fashion.

   I am not very particular on this issue, since things will work fine
   with the current means as well, do others have any comments on
   modeling this as two separate events in the state machine ?

> 
> ==============================================================
> =========
> 12) Event 12
> 
> > Event12: DelayBGP Open timer expires [changed]
> > 
> >	   Definition: A timer that delays sending of the BGP
> >	               Open message for n seconds after the
> >                       Transport connection has been completed.=
> 
> >The Definition seems to better define what the timer is, 
> rather than =
> > what
> > its expiry means. Can we change it to reflect this ?
> 
> new text:  see comment on 9 on Timer definition,
> 	     and earlier change.
> 
> Event 12: An event generated when the Delay BGP Open timer expires.
> =========================================
> 

  Ok.
  Can we add any text on the need or use of a Delay Open ?


> 13) Event 13, 14 definition
> 
> > Event13: Transport Connection Indication & valid remote 
> peer[changed]
> >
> >	   Definition: Event indicating that TCP connection
> >                       request with a valid source IP address and TCP
> >                       port, and valid destination IP address
> >                       and TCP Port.  The definition of
> >                       invalid Source, and invalid Destination=
> >                       IP address is left to the implementation.
> 
> 
> a) How about changing this slighty to:
> %	   Definition: Event indicating receiving a TCP connection
> %                       request with a valid source IP address and TCP
> %                       port, and valid destination IP address=
> %                       and TCP Port.  The definition of invalid
> My completion of  your sentence: 
> 			 	source, and invalid destination 
> IP address
> 				is left to the implementation. 
> 
> How about:
> 	Definition: Event indicating the reception of a TCP connection
> 			request with a valid source IP address and TCP 
> 			port, and valid destination IP address and
> 			TCP Port.  The definition of invalid 
> source address
> 			and port and invalid destination address
> 			is left to the implementation. 
> 
> 
> Please comment if you agree with this change.

  This looks good.
 
> 
> b) Is it correct that Destination IP address validation is 
> used when we
> do not wish to accept BGP connections on one of the local IP addresses
> (either because we wish to accept such addresses on only our loopback
> interfaces, or because the address to which we received the connection
> was not the optimal interface with which to speak to the sender) ? If
> so, can we add this to the description ?
> 
> 
> No, this is an implementation dependent change. 

  Ok. Again, if there are any validations that are considered
  desirable, adding this to the draft text as a suggestion to
  implementers would be useful.

  We can leave things as is if you feel that such details should
  be left out of the draft.


> ==============================================================
> ===================


> 
> 14) Event 13,14
> 
> > Event13: Transport Connection Indication & valid remote 
> peer[changed]
> >
> >	   Definition: Event indicating that transport
> >                       Request valid source IP address and TCP=20
> >                       port, and valid destination IP address=20
> >                       and TCP Port.  The definition of=20
> >                       invalid Source, and invalid Destination=20
> >                       IP address is left to the implementation.
> > 
> > a) I am unclear as to what validation of source and 
> destination port =
> > mean.
> > 
> > The source port's value should be of no concern to connection =
> > receipient system.
> 
> 	The definition of "valid" is an implementation policy issue. 
> 	Validating is the process of checking to make sure it is valid
> 	for the implementation's policy.  

    Ok.

> 
> > The destination port cannot be invalid, since BGP would not 
> receive the
> > connection request in such a situation.
> 
> 	Again, this is a policy issue.  We are providing hooks for
> 	policy to be engaged.  Policy is outside the scope of this
> 	document. 

   Isn't this more than just a policy issue ? It seems difficult
   to identify a connection destined to a port other than to
   the one on which BGP is running as an error event for BGP.
   So, I don't understand how a policy can be applied in this
   regard.

> 
> > b) I think it will be useful to state what we consider to 
> be an invalid
> > IP address.
> 
> 	Again, it is policy issue which is implementation dependent. 

    Ok.

> 
> ====================
> 15) Event 17
> 
> > Event17: TCP connection fails
> 
> > This event can occur even when the transport connection is closed by
> > the other end. Since this does not reflect a 'failure ', 
> can we change
> > the event name to
> > 
> > % Event17: TCP connection termination
> 
> Discussion:  It both terminates from the remote site
> 		 and can "timeout" - fail. 
> 
> Suggestions? I can use "disconnect", what do you think. 

  That looks fine too. I don't know what the best words
  to describe this are. Also, the description for this
  event does a good job of explaining this, so either
  the original text (connection fails) or your suggestion
  (disconnect) can be used.
  This really should not have been raised as a comment. :-)


> 
> 
> ==========================
> 
> 16) Events related to BGP Messages
> 
> Can we make the definition style across these events consistent ?
> 
> thanks for the comment.
> proposed text below, please agree on it.

  Yes, the text below looks fine.

  I should have phrased the original comment much better, I was
  referring to consistency across the following: Events 18, 19,
  20, 21 vs. Events 23, 24, 25, 26, 27.

  This is a very minor issue, so not making these changes is fine
  too. The way the latter events are described
  are different from the former. I suggest adopting the style for
  Events 23-27 for Events 18-21.

  As per this, the following changes would have to be made:

>       Event18: BGPOpen
>
>              Definition:  An event indicating that a valid Open
>                  message has been received.

    with 

%       Event18: BGPOpen
%
%              Definition:  An event is generated when a valid Open
%                           message has been received.

>       Event19: BGPOpen with BGP Delay Open Timer running
>
>              Definition: An event indicating that a valid Open
>                          message has been successful
>                          established for a peer that is
>                          currently delaying the sending of an
>                          BGP Open message.

   with

%       Event19: BGPOpen with BGP Delay Open Timer running
%
%              Definition: An event is generated when a valid Open
%                          message has been received for a peer that
%                          is currently delaying the sending of a
%                          BGP Open message.

>       Event20: BGPHeaderErr
>
>           Definition: BGP message header is not valid.

   with

%       Event20: BGPHeaderErr
%
%           Definition: An event is generated when a received BGP
%                       message header is not valid.

>       Event21: BGPOpenMsgErr
>
>           Definition: An BGP Open message has been received
>                          with errors.

    with

%       Event21: BGPOpenMsgErr
%
%           Definition: An event is generated when BGP Open message 
%                       with errors has been received.


> 
> proposed text replacement
> ------------------------
>     Event13: TCP connection indication and valid remote peer
>    
>            Definition: Event indicating the local system reception of 
> 		       a TCP connection request with a valid source
>                        IP address and TCP port, and valid destination
>                        IP address and TCP Port. The definition of
>                        invalid source, and invalid destination 
>                        IP address is left to the implementation.
> 
>                        BGP's destination port SHOULD be port 
>                        179 as defined by IANA.
>    
>                        TCP connection request is denoted by
>                        the local system receiving a TCP SYN.
>    
>            Status:     Mandatory (Optional) 
>  
>    
>     Event14: RCV TCP connection indication with invalid source or 
>              destination
>    
>            Definition: Event indicating the local system reception of
> 		       a TCP connection request with either 
>                        an invalid source address or port
>                        number or an invalid destination 
>                        address or port number. 
> 
>                        BGP destination port  number SHOULD be 179
>                        as defined by IANA.
>   
>                        Again, a TCP connection request 
>                        denoted by local system receiving a TCP
>                        SYN.
>    
>            Status:     Mandatory (Optional) 
>    	
>     Event15: TCP connection request sent received an ACK.
>    
>            Definition: Event indicating the Local system's request
>                        to establish a TCP connection to the remote
>                        peer. 
>    
>                        The local system's TCP session sent a TCP
>                        SYN, and received a TCP SYN, ACK pair of
>                        messages, and Sent a TCP ACK.
>    
>            Status:     Mandatory
>    
>     Event16: TCP connection confirmed
>    
>            Definition: Event indicates that the local system receiving
> 		       a confirmation that the TCP connection has 
>                        been established by the remote site. 
>    
>                        The remote peer's TCP engine sent a TCP SYN.
>                        The local peer's TCP engine sent a SYN, ACK
>                        pair, and now has received a final ACK.
>    
>            Status:     Mandatory
>    
>     Event17: TCP connection fails 
>    
>            Definition: Event indicates that the local system has
>                        received a TCP connection failure notice.
>    
>                        The remote BGP peer's TCP machine could have
>                        sent a FIN.  The local peer would respond
>                        with a FIN-ACK. Another alternative is that
>                        the local peer indicated a timeout in the
>                        TCP session and downed the connection.
>    
>            Status:     Mandatory
> 
> ---------------------
> 
> 
> 17) Event 19 Definition
> 
> > Event19: BGPOpen with BGP Delay Open Timer running [changed]
> >
> >           Definition: An event indicating that a valid Open=20
> >                       Message has been successful=20
> >                       established for a peer that is=20
> >                       currently delaying the sending of an=20
> >                       BGP Open message.=20
> 
> 
> The definition appears a little fragmented. How about:
> 
> % Definition: An event indicating that a valid OPEN
> %             Message has been received for a peer
> %             that has a successfully established
> %             transport connection and is currently
> %             delaying the seending of a BGP open
> %             message
> 
> 
> agreed, changed in text.  I will send out definition
> text for review in a separate message. 

  Ok.

> ==============================================================
> 18) Event 22 Definition
> 
> a)=20
> 
> > Event22: Open collision discard
> >
> >           Definition: An event generated administratively=20
> >                       when a connection Collision has been=20
> >                       detected while processing an incoming =20
> >                       Open message. This connection has been=20
> 
> Isn't this event 'automatically' generated, since it is a system
> generated event ?=20
> 
> response: How this generated is implementation specific.  The
>           "administratively" is to cover policy.  
> 
> b)
> 
> >                       Event 22 is an administrative could=20
> >                       occur if FSM is implemented as two=20
> >
> 
> The word event is missing. How about
> 
> %                       Event 22 is an automatic event that
> %                       could occur if FSM is implemented as two=20
> 
> 
> I've re-written the whole definition.  What do you think about:
> 
>    Event22: Open collision dump
>    
>            Definition: An event generated administratively
>                        when a connection collision has been 
>                        detected while processing an incoming  
>                        OPEN message and this connection has been 
>                        selected to disconnected. See Section 
>                        6.8 for more information on collision
>                        detection.  
>    
>                        Event22 is an administrative based only
> 		           implementation specific policy. This 
> 		           Event may occur if the FSM is implemented
> 		           as two linked state machines.  
>    
> Please confirm that you like this. 

  Agreed.

> 
> ====================================
> 19) FSM Description: ConnectRetry Count
> 
> > The Connect Retry count is updated by the FSM but never used. In the
> > absence of peer oscillation damping, will this be used to stop
> > connection establishment attempts after a certain maximum number ?
> 
> 	Yes, this is either implementation specific or
> 	is it based on the peer oscillation damping draft. 
> 
> > Can we include the use of this counter in some place ?
> 
> 	Connect retry counter 
> 		1) Will be utilized by the peer oscillation 
> damping drat.
> 		2) Will be included in bgp-4-mibv2-xx.  
> 			I just check and I didn't find it.
> 
> Do you still want text in the main 

  We can leave the main text as is.

> 
> ====================================
> 
> 20) Handling Event 7 (Auto Stop) to Idle State processing:
> 
> The handling of Event 7 is missing from the Idle State processing. Can
> we add this ? How about replacing
> 
> > An manual stop event (Event2) is ignored in the Idle state.
> 
> with
> 
> % Manual stop (Event 2) and Auto stop (Event 7) events are ignored
> % in the Idle state
> 
> we'll add that in the text.

  Ok.

> 
> ==============================
> 

Siva
([e-mail])


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA00784 for <[e-mail]>; Mon, 9 Dec 2002 16:50:38 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id EF68D91274; Mon,  9 Dec 2002 16:50:11 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2E1B91275; Mon,  9 Dec 2002 16:50:10 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 373A391274 for <[e-mail]>; Mon,  9 Dec 2002 16:50:09 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1834A5E075; Mon,  9 Dec 2002 16:50:09 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 7AE135DE1F for <[e-mail]>; Mon,  9 Dec 2002 16:50:08 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gB9Lo6M54518 for [e-mail]; Mon, 9 Dec 2002 16:50:06 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gB9LnoC54464 for <[e-mail]>; Mon, 9 Dec 2002 16:49:50 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: damping persistent peer oscillations
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Mon, 9 Dec 2002 16:49:50 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: damping persistent peer oscillations
Thread-Index: AcKdavRo3W9hPEyyRMqO6rtQrK+uYQCYaH9w
From: "Susan Hares" <[e-mail]>
To: "Tom Petch" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, "idr" <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id QAA00784

Tom:

peer oscillation damping ---- 
The document -19 draft already has
the corrections (thanks to yakov).

thanks for catching this.

I'll double check prior to release of 
the document.

Sue

-----Original Message-----
From: Tom Petch [mailto:[e-mail]]
Sent: Friday, December 06, 2002 4:02 PM
To: Susan Hares; Natale, Jonathan; idr
Subject: Re: damping persistent peer oscillations


** comment inline

-----Original Message-----
From: Susan Hares <[e-mail]>
To: Natale, Jonathan <[e-mail]>; [e-mail]
<[e-mail]>
Date: 06 December 2002 19:18
Subject: RE: damping persistent peer oscillations



Jonathan:

The draft is below.  I'll be updating the
draft-hares-bgp-backoff-00.txt
draft this month.  Please send comments.  The base specification
will simply state "damping persistent BGP adjacency flapping

** aka peer oscillation damping :-)


are
outside the scope of this document.

Sue


---------------------


Internet Draft                                              S. Hares
   Document: draft-hares-bgp-backoff-00.txt
NextHop

Technologies,

Inc.
   Expires: December 2002                                     June
2002


                   BGP Peer Restart Backoff Mechanisms

-----Original Message-----
From: Natale, Jonathan [mailto:[e-mail]]
Sent: Friday, December 06, 2002 10:47 AM
To: [e-mail]
Subject: damping persistent peer oscillations


>From Draft 18:
"Local system automatically starts the BGP peer connection with
persistent
peer oscillation damping enabled.  The exact method of damping
persistent
peer oscillations is left up to the implementation.   These methods of
damping persistent BGP adjacency flapping are outside the scope of
this
document."

-- is there a draft describing a "method of damping persistent peer
oscillations" ?


Tom Petch
[e-mail]




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA00653 for <[e-mail]>; Mon, 9 Dec 2002 16:46:36 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 35D0C91233; Mon,  9 Dec 2002 16:45:21 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9AB191274; Mon,  9 Dec 2002 16:45:20 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7C76891233 for <[e-mail]>; Mon,  9 Dec 2002 16:45:18 -0500 (EST)
Received: by segue.merit.edu (Postfix) id F414A5E07A; Mon,  9 Dec 2002 16:45:16 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id E86DE5E075 for <[e-mail]>; Mon,  9 Dec 2002 16:45:14 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gB9LjDn54334 for [e-mail]; Mon, 9 Dec 2002 16:45:13 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gB9Lj2C54309 for <[e-mail]>; Mon, 9 Dec 2002 16:45:02 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Response to FSM input - Comments 1-10
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Mon, 9 Dec 2002 16:45:02 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Response to FSM input - Comments 1-10
Thread-Index: AcKdFw/Ma0ArdhU1STmrF5x92p3z/QARRo5g
From: "Susan Hares" <[e-mail]>
To: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>, "Yakov Rekhter" <[e-mail]>, "Jeffrey Haas" <[e-mail]>
Cc: <[e-mail]>, "Venu Kumar G - CTD, Chennai." <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id QAA00653

Siva:

Thanks for such a quick turn around.

So.. our summary is

1 - consensus, no text change
2 - no consensus, see text change 
3 - mostly consensus,
	Policy in implementations may dictate some options
      per peer and some options per implementation. I 
	suggest we specify the list you came up with plus
	Idle Hold Timer in 8.0.

4 - consensus, text change [done]  
5 - no consensus, see comment below
	5a - answer question [no text intended]
	5b.1 - text proposed 
	5b.2 - your text or mine?

6 - consensus on text, answer given below
7 - no consensus, text proposal below

	2 of the 3 events could be considered infeasible.
	The 3rd event all add.  Please review the text.

8 - consensus, no text change  
9 - consensus, text change [done] 
10 - consensus, text changed [done] 

	Note 9 + 10 are taken together 

Comments to resolve: 2,3, 5, 7, 

Thanks for the quick response.

Sue Hares


=====================

Comment 2 -

    Event8: Idle hold timer expires 
   
           Definition: An Event generated when the Idle Hold Timer
		           expires.  The Idle Hold Timer is only used
                       when the persistent peer oscillation
                       damping function is enabled.
%
%			     Implementations not implemented persistent
% 			     peer oscillations damping functions may not
%  			     have the Idle Hold Timer. 

Is this approach ok? 
============

Comment 3

The following will be added to 8.0

Optional parameters that may be supported either per
connection or per implementation: 

1) Delay Open flag 
2) Delay Open Timer
3) Perform automatic start flag 
4) Passive TCP establishment flag 
5) BGP stop_peer_flag flag 
%6) Idle Hold timer 
7) Perform automatic stop flag  
8) Perform Collision detect in Establish mode flag 

=====================
Comment 4: consensus, change made to Event 1 and 2

===============
Comment 5:

5a:
Automatic stop and stop are implemented by cisco's policy
engine.  The origination of the damping peer oscillation was
in result to a bug that was listed in comment 5.

5b:

 1.) Example of "automatic disconnect" in Established state

  Is the text you wanted moved: 
    An example automatic stop event is exceeding the number of 
    prefixes for a given peer and the local system 
    automatically disconnecting the peer.
   
  If so, I can move this to the automatic stop event

 2.) Text describing the optional parameters.

	We can add text for the optional parameters to 
	describe their function.  Can you propose some text?
======================
Comment 6

>  I am ok to leave the text as is, based on text in 8.2.1.1. However,
>  I do not quite understand your point. In the case of an un-configured
> peer, the local system cannot 'establish a connection', so is the
>  unconfigured peer case still valid in this context ?

Unconfigured + passive TCP connection + Delay Open is valid.

============================================
Comment 7

>
>
>   We already have 
>   Event 3 - Automatic Start
>   Event 5 - Automatic start with bgp_stop_flap option set
>
>
>  To make things consistent, shouldn't we either
>
>  a) Add 3 new events :  1) Manual start with bgp_stop flap option set
>                         2) Manual start with passive TCP establishment
>                            and bgp_stop_flap option set
>                         3) Automatic start with passive TCP establishment
>                            and bgp_stop_flap option set

I like option A, it is clearer.   

The Manual start or stop terminates the bgp peer oscillation damping. 
The theory is the operator "did" something, therefore the events need to
chagne.  Since these events do not have valid implementation in the
peer flap damping, I did not include them.   

#3 is something I missed.  I will add that event.  Is that resolution OK, or
I can put all 3 new events in. 

=========================



-----Original Message-----
From: Sivananda Ramnath - CTD, Chennai. [mailto:[e-mail]]
Sent: Friday, December 06, 2002 6:05 AM
To: Susan Hares; Yakov Rekhter; Jeffrey Haas
Cc: [e-mail]; Sivananda Ramnath (E-mail); Venu Kumar G - CTD,
Chennai.
Subject: RE: Response to FSM input - Comments 1-10


Hello,

Revised summary:

Comment 1 - No text change, Potential consensus
Comment 2a - No consensus
Comment 2b - No consensus
Comment 3 - New text suggested, no consensus
Comment 4 - Resolved, text changed. Can we consider this closed ?
Comment 5 - No text change, Potential consensus
Comment 6 - No consensus
Comment 7 - No consensus, comment re-phrased.
Comment 8 - No text change, potential consensus
Comment 9 - Resolved, text changed. Can we consider this closed ?
Comment 10 - Resolved, text changed. Can we consider this closed ?

> 
> Comment 1 - no consensus
> Comment 2a - out of date (No IdleHold Timer exists) 
> Comment 2b - no consensus, can't remove due to OpenSent state
> 		 action.
> 
> Comment 3 - no text proposed, do we want all options
> 		specified in 8.1 (7 options) 
> 		Please review and comment on text 
>  
> Comment 4 - agree
> Comment 5 - no text proposed, no consensus
> Comment 6 - no consensus on the text
> Comment 7 - see comment 3, no consensus
> Comment 8 - question, no text 
> Comment 9 - agree, I supplied text 
> Comment 10 - agree to remove text in option,
> 		 different text for definition.
> 
> 
> Sue Hares
> 
> ==========
> 
> comment 1: 
> 
> 1) removal of peer oscillation damping 
> 
> The reason we should not remove the peer oscillation damping
> from the state machine:
> 
>   1) Deployed implementations support peer oscillation damping 
>   2) Hooks for the additions in the FSM cannot be added later.
> 
> These hooks are optional and do not need to be implemented. 

  I understand. I am not trying to object to peer oscillation
  damping, I think it is a good idea and we have included it in
  our implementation as well. I was suggesting that instead of
  a partial description in this draft, it be completely described
  in the draft on peer oscillation damping.

  However, I do see your point, and unless there are any objections
  from others, I think we have consensus on this issue.

> 
>  
> 2) Idle HoldTimer in draft-18
> 
>   Perhaps this is an old comment.  I don't find IdleHoldTimer
>   in the messages.

    It is listed as Event 8. Perhaps this is what needs to be
    removed ?

> 
> 3) HoldTime and HoldTimer
> 
>    The Hold Time is specified on page 13 of the draft-18 specification
>    as to the value and size.  The text in OpenSent requires
>    both a HoldTime and HoldTimer value.
> ===========
>    OpenSent:
>    
>     In this state BGP waits for an Open Message from its peer.  
 [SNIP]
>   
> ===================

  I understand. However, on this basis, we would also need a Keepalive
  time (since the basis on wihch this is be arrived at can be
  configurable). I don't know whether we do need to make such changes
  to the draft, and I am OK to leaving this portion as it stands.

> The earlier comments on the list indicated we need to collect what
> timers or Timer values were utilized in the FSM.  I believe Alex
> made this comment last January.  (the list archives will have
> this information.)
> 
> So, I don't see any way to

  The DelayBgpOpenTimer is missing from the session attributes list,
  how about including it ?

> 
> Comment 3: optional parameters specified
> 
> Please suggest text.  We have the following optional parameters:
> 
> 1) Delay Open
> 2) Accept unconfigured peers
> 3) automatic start [Event 3] 
> 4) passive TCP establishment (optional)
> 	4 + 5 = Event 5
> 5) BGP_stop_flap (BGP Peer oscillation) [Event 6] 
> 6)automatic stop [Event 7] 
> 7)Collision detect in Established State 
> 
> If you want some of the optional parameters specified, let's
> catch all.  Please suggest text and location.  It could
> go in 8.1.

  My view is this can be split into two categories:

  Optional attributes exist per session, and optional attributes
  for the entire system.

  How about adding the following to section 8 (immediately before 8.1)

%  Optional session attributes that a implementation may support
%  for a session are:
%
%    1) DelayOpen flag
%    2) DelayOpen Timer
%    3) Perform automatic start
%    4) Passive TCP establishment
%    5) Perform automatic stop
%    6) BGP Perform 
%
%
%  Implementations may also support the following optinal attributes
%  that modify the behavior of the state machine
%
%    1) Accept un-configured peers
%    2) Perform collision detect in Established state

    I guess it is possible to have some of these things listed under
    both categories. Am I opening up a can of worms here ?  :-)

> --------------------------------
> Comment 4
> 
> Old Text: 
>   Event 1: Manual Start
>       Definition: Administrator manually starts peer connection.
> 
>  ... 
>   Event 2: Manual Stop 
> 	 Definition: Local system administrator manually stops the 
> 		       peer connection. 
> New Text: 
>   Event1: Manual start
>        Definition: Local system administrator manually starts the
> 		       bgp connection.
> 
>   ... 
>   Event 2: Manual stop:
> 	  Definition: Local system administrator manually stops the 
> 			  bgp connection.
> 
> agree? 

  Agreed.

> ---------------
> Comment 5: 
> 
> 5) Event3, Event5, Event6 and Event7
> 
> 5a) 
> =========
>   Event 3/6/7 - cisco indicated the automatic stop, see the NANOG
> 		  archives for a discussion of the Bad Route
> 
>     http://www.merit.edu/mail.archives/nanog/2001-06/msg00805.html
> 
>   The "event" sequences are new with this version of the FSM
>   to identify particular events by number. 

    I am unclear on what this issue is!

> 5b
> ======
> 
>   Can we give examples of these events, as implemneted by curent
>   implementations ? This will be of help to new implementaions.
> 
>   An example of Auto Stop is already present in the Update event
>   handling section, and we can move that to this place as well.
> 
> I believe that examples are outside the scope of this specification.
> If you have text clarifying the event descriptions, please send it in.

  Well, the current text in the established state already gives an example
  for an automatic start event. I was suggesting that such examples be
  moved to the event description section.

  I also think adding text to clarify the intent behind optional events,
  and giving examples would help, especially for new implementors. However,
  if you feel this is outside the scope of the RFC, we can leave things
  as is.


> 
> 
> =======================================================
> 
> 6) Event 4,5 Definition
> 
> >	   Definition: Administrator manually start the peer
> >                       Connection, but has the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing the connection.
> 
> 
> >	  Definition:  Local system automatically starts the
> >                       BGP session with the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing a connection.
> 
> 
> >My understanding is this is used to indicate a peer configuration
> >where we start the state machine, and wait for an incoming connection
> >request from the configured peer. Can we re-phrase this section to
> >indicate this.
> 
> >How about something like:
> >
> >% The passive flag indicates that the state machine will wait for
> >% specified peer to initiate a connection with the local system. If
> >% this does not happen within a specific time (hold time), the local
> >% system will then also attempt to initiate connection with the
> >% specified peer.
> 
> The text in 8.2.1.1 indicates the definition of the passive flag. 

   Yes. 
> 
> 6a) 
> ==========
> My understanding of your text is that you want to replace in both
> sets of text: 
> 
> "The passive flag indicates the peer will listen prior to 
>  establishing a connection".  
> 
> with: 
> 
> "The passive flag indicates that the state machine will wait for the
> specified peer to initiate a connection with a local system.
> 
> The problem with this sentence is that in the "unconfigured" case
> the phrase "specified" peer is confusing.  I think the original text
> is clearer. 

  I am ok to leave the text as is, based on text in 8.2.1.1. However,
  I do not quite understand your point. In the case of an un-configured
  peer, the local system cannot 'establish a connection', so is the
  unconfigured peer case still valid in this context ?

> 6b)
> ==========
> If this does not happen within a specific time (hold time), the local
> system will then also attempt to initiate (a) connection with the
> specified peer.
> 
> My comments: Again, the "specified peer" term is confusing.  Also,
> the 2nd half of the statement mixes the actions of the state machine
> with the events.  I believe this muddies the text instead of
> clarifying it.

  Please refer to my comments for 6a.

  I think a reason for this is the requirement (in 8.2.1) that a FSM be
  established a-priori for "accepting each incoming TCP connection for
  which the peer has not beet identified".

  Is the intent to establish a FSM session for accepting TCP connections
  from un-configured peers ? If so, I am of the opinion that this is
  purely an implementation issue, and need not be a requirement in the spec.

>  
> =================
> Comment 7 -
> 
> Event 6 - (not specified, please confirm) 
> 
> >  Won't a variant of this with bgp_stop_flap option set be requried ?
> >  We can also achieve the same by using the bgp_stop-Flap option as a
> >  flag that is provided as an input to the state machine.
> 
> see comment number 3.  bgp_stop_flap is an option.  
> 
> This state machine description has many events to describe the
> mixture of options and actions.  I believe it has a better clarity
> than testing lots of flags within a state. 
> 
> A proof in case, is that many people are making comments about
> specific transitions. 

   I tink I should have phrased my question much better.

   We already have 
   Event 3 - Automatic Start
   Event 5 - Automatic start with bgp_stop_flap option set

   To make things consistent, shouldn't we either

   a) Add 3 new events : 1) Manual start with bgp_stop flap option set
                         2) Manual start with passive TCP establishment
                            and bgp_stop_flap option set
                         3) Automatic start with passive TCP establishment
                            and bgp_stop_flap option set

   or

   b) Remove Event 6, and rely on a flag to tell us wether peer flap damping
      is to be performed for the session or not.


> 
> ============
> Comment 8 - 
> 
> 
> 8) Event 5 Definition
> 
> >	  Definition:  Local system automatically starts the
> >                       BGP session with the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing a connection.
> 
> > Is it correct that this event will occur only when we want 
> to restart
> > a connection (after it had been terminated due to some reason beside
> > administrative action) that we had accepted from an 
> unconfigured peer ?
> 
> The automatic start function is an implementation specific mechanism.
> This text does not seek to restrict it in any fashion.

  Well, for new implementors, such clarifications will help undertsand
  how to generate and make use of this event. Again, I am OK with
  leaving text as is.

> 
> ================
> 9) Timer Events Definition
> 
> > Event8:  idle Hold timer expires=20
> >
> >           Definition: Idle Hold timer expires.  The Idle=20
> >
> > Event9: connect retry timer expires
> >
> >           Definition: An event triggered by the expiration of=20
> > Event10: hold time expires
> >
> >	   Definition: An event generated when the HoldTimer=20
> 
> We can use any one of these terms (trigerred by/generated 
> when) for all
> timer event definitions to make it look more consistent.
> 
> agree: Will use "generate" 
> 
> Event 8: An event generated when the Idle Hold timer expires.
> Event 9: An event generated when the ConnectRetry timer expires.
> Event 10: An event generated when the Hold timer expires.  
> Event 11: An event generated when the Keepalive timer expires
> Event 12: An event generated when the Delay BGP Open timer expires.
> 
> Please confirm that this change to the definitions is agreeable to
> you.

  Agreed.

  I think we have consensus on this issue, unless anyone else
  has any comments on this.

> 
> ================
> 10) Event 8 Definition
> 
> > Event8:  idle Hold timer expires=20
> >
> >           Definition: Idle Hold timer expires.  The Idle=20
> >                       Hold Timer is only used when persistent =20
> >                       BGP oscillation damping functions are=20
> >                       enabled. =20
> >
> >           Status: 	Optional.  Used when persistent
> >			BGP peer oscillation damping functions
> >			are enabled.=20
> 
> 
> The status repeats the senetnce in the definition. Can we remove the
> sentence from the Status, or replace with a different definition.
> 
> Do you think the defenition below would fit ?
> 
> % An event trigerred by the expiry of the Idle Hold timer, indicating
> % that the session has completed waiting for a back-off period to
> % prevent flap, and may now proceed to take any further systemm
> % initiated action for this session. 
> 
> text change suggestion for 1st sentence that I'll agree to.
> 
>  An event trigerred by the expiry of the Idle Hold timer, indicating
>  that the session has completed waiting for a back-off period to
>  prevent bgp peer oscillation.
> 
> Please confirm that you will agree to this.

  Agreed.
  I think we have consensus on this issue, unless anyone else
  has any comments on this.


Siva
([e-mail])> 


Original text of comments 1-10 follow:


> 
> ------- Message 4
> 
> Date:    Fri, 29 Nov 2002 19:46:06 +0530
> From:    "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
> To:      [e-mail], Yakov Rekhter <[e-mail]>
> cc:      [e-mail]
> Subject: Comments on draft 18
> 
> 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_000_01C297B1.DB0F1700
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> Hello,
> 
>     Attached are some comments that I have on draft-ietf-idr-bgp4-18.
> 
>     Please have a look at these and tell me if the same can 
> be raised to the
> mailing list as well.
> 
> Thanks,
> Siva
> ([e-mail])
>   
> 
> 
> - ------_=_NextPart_000_01C297B1.DB0F1700
> Content-Type: text/plain;
> 	name="BGP_Issues.txt"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: attachment;
> 	filename="BGP_Issues.txt"
> 
> All quoted sections of the original document have been 
> prefixed by a '> =
> '
> All lines of proposed text have been prefixed by a '% '
> 
> 
> 1) Performing of peer oscillation damping:
> 
> Since this feature is going to be added in a new draft, and its
> addition will change the operation of the state machine, can we remove
> all mention of it in the state machine ? As part of this removal, can
> we also remove the IdleHold Timer from the FSM since it is not useful
> in the absence of peer oscillation damping ?
> 
> The draft that describes this procedure can then describe the change
> in the state machine required to do this.
> 
> 
> 2) Session Attributes:
> 
> > Session Attributes required for each connection are;=20
> 
> >   1) state
> >   2) Connect Retry timer
> >   3) Hold timer
> >   4) Hold time
> >   5) Keepalive timer
> 
> Why have a Hold Timer and a Hold Time ? Can we replace this with just
> Hold timer ?
> 
> Can we also add the following session attributes:
> 
> a) DelayBgpOpenTimer
> b) IdleHold Timer (in case we choose not to remove this from the bas =
> FSM)
> 
> Can we also add the following flag to the session attributes:
> a) DelayOpen Flag
> 
> 
> 3) All sessions attributes:
> 
>   There are some attributes that are common to all sessions of the =
> system.
>   Can we call these out as well:
> 
>   * Accept Connections from unconfigured peers (Enabled/Disabled)
>   * Peer Oscillation Dampening (Enabled/Disabled) (In case we choose
>     not to remove it from base spec)
> 
> 
> 4) Description for Event1/Event2
> 
> > Event1: Manual start=20
> >
> >	   Definition: Administrator manually starts peer
> >                       connection
> 
> > Event2: Manual stop
> 
> >	   Definition: Local system administrator manually=20
> >                       stops the peer connection.
> 
> We can make these look consistent by using the Term Administrator or
> Local System administrator in both cases.
> 
> 
> 5) Event3, Event5, Event6 and Event7
> 
>   Can we give examples of these events, as implemneted by curent
>   implementations ? This will be of help to new implementaions.
> 
>   An example of Auto Stop is already present in the Update event
>   handling section, and we can move that to this place as well.
> 
> 
> 6) Event 4,5 Definition
> 
> >	   Definition: Administrator manually start the peer
> >                       Connection, but has the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing the connection.
> 
> 
> >	  Definition:  Local system automatically starts the
> >                       BGP session with the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing a connection.
> 
> 
> My understanding is this is used to indicate a peer configuration
> where we start the state machine, and wait for an incoming connection
> request from the configured peer. Can we re-phrase this section to
> indicate this.
> 
> How about something like:
> 
> % The passive flag indicates that the state machine will wait for
> % specified peer to initiate a connection with the local system. If
> % this does not happen within a specific time (hold time), the local
> % system will then also attempt to initiate connection with the
> % specified peer.
> 
> 
> 7) Event 4,5
> 
>   Won't a variant of this with bgp_stop_flap option set be requried ?
>   We can also achieve the same by using the bgp_stop-Flap option as a
>   flag that is provided as an input to the state machine.
> 
> 
> 8) Event 5 Definition
> 
> >	  Definition:  Local system automatically starts the
> >                       BGP session with the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing a connection.
> 
> Is it correct that this event will occur only when we want to restart
> a connection (after it had been terminated due to some reason beside
> administrative action) that we had accepted from an 
> unconfigured peer ?
> 
> 
> 9) Timer Events Definition
> 
> > Event8:  idle Hold timer expires=20
> >
> >           Definition: Idle Hold timer expires.  The Idle=20
> >
> > Event9: connect retry timer expires
> >
> >           Definition: An event triggered by the expiration of=20
> > Event10: hold time expires
> >
> >	   Definition: An event generated when the HoldTimer=20
> 
> We can use any one of these terms (trigerred by/generated 
> when) for all
> timer event definitions to make it look more consistent.
> 
> 
> 
> 10) Event 8 Definition
> 
> > Event8:  idle Hold timer expires=20
> >
> >           Definition: Idle Hold timer expires.  The Idle=20
> >                       Hold Timer is only used when persistent =20
> >                       BGP oscillation damping functions are=20
> >                       enabled. =20
> >
> >           Status: 	Optional.  Used when persistent
> >			BGP peer oscillation damping functions
> >			are enabled.=20
> 
> 
> The status repeats the senetnce in the definition. Can we remove the
> sentence from the Status, or replace with a different definition.
> 
> Do you think the defenition below would fit ?
> 
> % An event trigerred by the expiry of the Idle Hold timer, indicating
> % that the session has completed waiting for a back-off period to
> % prevent flap, and may now proceed to take any further systemm
> % initiated action for this session.
> 
> 
> --



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA22545 for <[e-mail]>; Mon, 9 Dec 2002 13:15:55 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 55CF39126C; Mon,  9 Dec 2002 13:15:08 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 903719126E; Mon,  9 Dec 2002 13:15:07 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 73E699126C for <[e-mail]>; Mon,  9 Dec 2002 13:15:05 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 294575E061; Mon,  9 Dec 2002 13:15:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 5CFA35DE42 for <[e-mail]>; Mon,  9 Dec 2002 13:15:04 -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 NAA08530; Mon, 9 Dec 2002 13:15:01 -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 NAA20043; Mon, 9 Dec 2002 13:15:02 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <X91YVFJA>; Mon, 9 Dec 2002 13:15:01 -0500
Message-ID: <[e-mail]>
From: "Krishnan, Vijay G." <[e-mail]>
To: "'PamSri'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: BGP routes with label information
Date: Mon, 9 Dec 2002 13:14:52 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Sri,

I am sending my reply to IDR as well.

Should the label information be considered part of NLRI or an attribute.

According to section 3 of RFC3107, label is part of an attribute.
   "A BGP speaker can withdraw a previously advertised route (as well as
   the binding between this route and a label) by either (a) advertising
   a new route (and a label) with the same NLRI as the previously
   advertised route, or (b) listing the NLRI of the previously
   advertised route in the Withdrawn Routes field of an Update message.
   The label information carried (as part of NLRI) in the Withdrawn
   Routes field should be set to 0x800000."

In section 4, it says that we can withdraw a particular label (like an NLRI)
   "In the case where a BGP speaker advertises multiple routes to a
   destination, if a route is withdrawn, and a label(s) is specified at
   the time of withdrawal, only the corresponding route with the
   corresponding label is withdrawn."

So if we need to change the label mapping should we send the new set of
labels or withdraw it before sending the new update.

thanks
Vijay



-----Original Message-----
From: PamSri [mailto:[e-mail]]
Sent: Monday, December 09, 2002 11:48 AM
To: Krishnan, Vijay G.
Subject: Re: BGP routes with label information


Vijay ,
      Can you provide some more info on scenario which
causes 2 updates to be sent out back with different
label info ? Normally if you encounter a situation
whereby you send 2 different sets of path attribs
separately then you overwrite the path attribs with
the latest update. 

sri

--- "Krishnan, Vijay G."
<[e-mail]> wrote:
> Hi,
> 
> I have a question regarding multiple label
> advertisements for BGP route
> (RFC-3107).
> 
> Suppose a BGP speaker receives in a single update
> message, a destination
> prefix (p) with a nexthop (n) and multiple mpls
> labels (L1, L2 and L3). In
> the next update, it receives prefix (p) and nexthop
> (n) but a different
> label (L4). 
> 
> Will (p,n,L4) replace {(p,n,L1), (p,n,L2) and
> (p,n,L3)}. 
> Or 
> Will the new one be added to get {(p,n,L1),
> (p,n,L2), (p,n,L3) and
> (p,n,L4)}. 
> 
> thanks
> Vijay
> 
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA17220 for <[e-mail]>; Mon, 9 Dec 2002 11:05:32 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id AF8439127A; Mon,  9 Dec 2002 11:04:23 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76AC891269; Mon,  9 Dec 2002 11:04:23 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9BE349127A for <[e-mail]>; Mon,  9 Dec 2002 11:02:13 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 864395E056; Mon,  9 Dec 2002 11:02:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 369E35DDC9 for <[e-mail]>; Mon,  9 Dec 2002 11:02:13 -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 LAA26346; Mon, 9 Dec 2002 11:01:47 -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 LAA15771; Mon, 9 Dec 2002 11:01:48 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <X91Y4742>; Mon, 9 Dec 2002 11:01:47 -0500
Message-ID: <[e-mail]>
From: "Krishnan, Vijay G." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: BGP routes with label information
Date: Mon, 9 Dec 2002 11:01:45 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hi,

I have a question regarding multiple label advertisements for BGP route
(RFC-3107).

Suppose a BGP speaker receives in a single update message, a destination
prefix (p) with a nexthop (n) and multiple mpls labels (L1, L2 and L3). In
the next update, it receives prefix (p) and nexthop (n) but a different
label (L4). 

Will (p,n,L4) replace {(p,n,L1), (p,n,L2) and (p,n,L3)}. 
Or 
Will the new one be added to get {(p,n,L1), (p,n,L2), (p,n,L3) and
(p,n,L4)}. 

thanks
Vijay




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA08976 for <[e-mail]>; Mon, 9 Dec 2002 08:05:22 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 0E5F09123A; Mon,  9 Dec 2002 08:04:54 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C838F91259; Mon,  9 Dec 2002 08:04:53 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 790009123A for <[e-mail]>; Mon,  9 Dec 2002 08:04:52 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 559A45DDC9; Mon,  9 Dec 2002 08:04:52 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id CC0EC5DDA8 for <[e-mail]>; Mon,  9 Dec 2002 08:04:51 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07024; Mon, 9 Dec 2002 08:01:56 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-bgp-gr-survey-00.txt
Date: Mon, 09 Dec 2002 08:01:56 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: BGP Graceful Restart - Implementation Survey
	Author(s)	: J. Scudder
	Filename	: draft-ietf-idr-bgp-gr-survey-00.txt
	Pages		: 10
	Date		: 2002-12-6
	
This document provides a survey of BGP-4 Graceful Restart
implementations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-gr-survey-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-bgp-gr-survey-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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp-gr-survey-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp-gr-survey-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp-gr-survey-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA08701 for <[e-mail]>; Fri, 6 Dec 2002 16:05:04 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 0566191306; Fri,  6 Dec 2002 16:03:40 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8BD19130B; Fri,  6 Dec 2002 16:03:39 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE97691306 for <[e-mail]>; Fri,  6 Dec 2002 16:03:33 -0500 (EST)
Received: by segue.merit.edu (Postfix) id DC9335DEE1; Fri,  6 Dec 2002 16:03:33 -0500 (EST)
Delivered-To: [e-mail]
Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by segue.merit.edu (Postfix) with ESMTP id AB4EA5DE84 for <[e-mail]>; Fri,  6 Dec 2002 16:03:33 -0500 (EST)
Received: from tom3 (usercq28.uk.uudial.com [62.188.156.156]) by shockwave.systems.pipex.net (Postfix) with SMTP id 5B9901600102C; Fri,  6 Dec 2002 21:03:30 +0000 (GMT)
Message-ID: <004a01c29d6a$e5acda80$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Susan Hares" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, "idr" <[e-mail]>
Subject: Re: damping persistent peer oscillations
Date: Fri, 6 Dec 2002 21: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: [e-mail]
Precedence: bulk

** comment inline

-----Original Message-----
From: Susan Hares <[e-mail]>
To: Natale, Jonathan <[e-mail]>; [e-mail]
<[e-mail]>
Date: 06 December 2002 19:18
Subject: RE: damping persistent peer oscillations



Jonathan:

The draft is below.  I'll be updating the
draft-hares-bgp-backoff-00.txt
draft this month.  Please send comments.  The base specification
will simply state "damping persistent BGP adjacency flapping

** aka peer oscillation damping :-)


are
outside the scope of this document.

Sue


---------------------


Internet Draft                                              S. Hares
   Document: draft-hares-bgp-backoff-00.txt
NextHop

Technologies,

Inc.
   Expires: December 2002                                     June
2002


                   BGP Peer Restart Backoff Mechanisms

-----Original Message-----
From: Natale, Jonathan [mailto:[e-mail]]
Sent: Friday, December 06, 2002 10:47 AM
To: [e-mail]
Subject: damping persistent peer oscillations


>From Draft 18:
"Local system automatically starts the BGP peer connection with
persistent
peer oscillation damping enabled.  The exact method of damping
persistent
peer oscillations is left up to the implementation.   These methods of
damping persistent BGP adjacency flapping are outside the scope of
this
document."

-- is there a draft describing a "method of damping persistent peer
oscillations" ?


Tom Petch
[e-mail]




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA02729 for <[e-mail]>; Fri, 6 Dec 2002 14:18:55 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DC4E0912EC; Fri,  6 Dec 2002 14:18:43 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADC88912ED; Fri,  6 Dec 2002 14:18:43 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 215DE912EC for <[e-mail]>; Fri,  6 Dec 2002 14:17:51 -0500 (EST)
Received: by segue.merit.edu (Postfix) id F13345DE95; Fri,  6 Dec 2002 14:17:50 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 945DD5DE8B for <[e-mail]>; Fri,  6 Dec 2002 14:17:50 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gB6JHnG92226 for [e-mail]; Fri, 6 Dec 2002 14:17:49 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gB6JHhC92212 for <[e-mail]>; Fri, 6 Dec 2002 14:17:43 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: damping persistent peer oscillations
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Fri, 6 Dec 2002 14:17:42 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: damping persistent peer oscillations
Thread-Index: AcKdPu5Bw+ERPh5gSV6yMqSEWwKbfAAHPs+w
From: "Susan Hares" <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id OAA02729

Jonathan:

	The draft is below.  I'll be updating the draft-hares-bgp-backoff-00.txt
draft this month.  Please send comments.  The base specification
will simply state "damping persistent BGP adjacency flapping are
outside the scope of this document.

Sue


---------------------                                                                         
  

 Internet Draft                                              S. Hares 
   Document: draft-hares-bgp-backoff-00.txt                     NextHop 
                                                          Technologies, 
                                                                   Inc. 
   Expires: December 2002                                     June 2002 
 
 
                   BGP Peer Restart Backoff Mechanisms 

-----Original Message-----
From: Natale, Jonathan [mailto:[e-mail]]
Sent: Friday, December 06, 2002 10:47 AM
To: [e-mail]
Subject: damping persistent peer oscillations


>From Draft 18:
"Local system automatically starts the BGP peer connection with persistent
peer oscillation damping enabled.  The exact method of damping persistent
peer oscillations is left up to the implementation.   These methods of
damping persistent BGP adjacency flapping are outside the scope of this
document."

-- is there a draft describing a "method of damping persistent peer
oscillations" ?


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA02492 for <[e-mail]>; Fri, 6 Dec 2002 14:14:21 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 28237912EB; Fri,  6 Dec 2002 14:13:45 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E37C4912EC; Fri,  6 Dec 2002 14:13:44 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E7CF912EB for <[e-mail]>; Fri,  6 Dec 2002 14:13:43 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 6D0CE5DFB7; Fri,  6 Dec 2002 14:13:43 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 3AB545DFBB for <[e-mail]>; Fri,  6 Dec 2002 14:13:42 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id OAA22088; Fri, 6 Dec 2002 14:12:31 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: damping persistent peer oscillations 
In-reply-to: Your message of "Fri, 06 Dec 2002 14:01:10 EST." <[e-mail]> 
Date: Fri, 06 Dec 2002 14:12:31 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> Curtis,
> 
> Thanks for the reply.
> 
> But I was looking for *peer* oscillation damping, not *route* oscillation
> damping.  RFC1771 had:
> 
>     "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 text I quoted started with

  When a peer routing session is broken, ...

and suggested

  the peering session itself may be marked as unstable.

How is this not applicable?

> --Current implementations (AKA Juniper and Cisco) do not do this, and the
> draft-18 has it tagged as out of scope (see below).
> 
> Maybe this will be in the RFC1772 re-do and/or a BCP?

Since its out of scope but OK to do something as stated in -18, its OK
to do what is recommended in RFC2439 but not required.

You asked if anything addressed a "method of damping persistent peer
oscillations".  The answer is "yes there is".

Curtis


> > -----Original Message-----
> > From: Curtis Villamizar [mailto:[e-mail]] 
> > Sent: Friday, December 06, 2002 1:33 PM
> > To: Natale, Jonathan
> > Cc: [e-mail]
> > Subject: Re: damping persistent peer oscillations 
> > 
> > 
> > 
> > In message 
> > <[e-mail]
> > ks.com>, "Natale, Jonathan" writes:
> > > >From Draft 18:
> > > "Local system automatically starts the BGP peer connection 
> > with persistent
> > > peer oscillation damping enabled.  The exact method of 
> > damping persistent
> > > peer oscillations is left up to the implementation.   These 
> > methods of
> > > damping persistent BGP adjacency flapping are outside the 
> > scope of this
> > > document."
> > > 
> > > -- is there a draft describing a "method of damping persistent peer
> > > oscillations" ?
> > 
> > 
> > RFC 2439 "BGP Route Flap Damping":
> > 
> >   4.8.5 Processing A Peer Router Loss
> > 
> >    When a peer routing session is broken, either all individual routes
> >    advertised by that peer may be marked as unstable, or the peering
> >    session itself may be marked as unstable.  Marking the 
> > peer will save
> >    considerable memory.  Since the individual routes are advertised as
> >    unreachable to routers beyond the immediate problem, per 
> > route state
> >    will be incurred beyond the peer immediately adjacent to the BGP
> >    session that went down.  If the instability continues, the
> >    immediately adjacent router need only keep track of the peer
> >    stability history.  The routers beyond that point will receive no
> >    further advertisements or withdrawal of routes and will dispose of
> >    the damping structure over time.
> > 
> >    BGP notification through an optional transitive attribute that
> >    damping will already be applied may be considered in the future to
> >    reduce the number of routers that incur damping structure storage
> > 
> > Curtis
> > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA02318 for <[e-mail]>; Fri, 6 Dec 2002 14:11:13 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BC241912EA; Fri,  6 Dec 2002 14:10:40 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8357A912EB; Fri,  6 Dec 2002 14:10:40 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 08041912EA for <[e-mail]>; Fri,  6 Dec 2002 14:10:39 -0500 (EST)
Received: by segue.merit.edu (Postfix) id E80655DDC8; Fri,  6 Dec 2002 14:10:38 -0500 (EST)
Delivered-To: [e-mail]
Received: from nemesis.systems.pipex.net (nemesis.systems.pipex.net [62.241.160.8]) by segue.merit.edu (Postfix) with ESMTP id 9A8115DFB6 for <[e-mail]>; Fri,  6 Dec 2002 14:10:38 -0500 (EST)
Received: from tom3 (userbm41.uk.uudial.com [62.188.144.247]) by nemesis.systems.pipex.net (Postfix) with SMTP id 9C34416008098; Fri,  6 Dec 2002 19:10:32 +0000 (GMT)
Message-ID: <00e701c29d5b$1f5bf460$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "idr" <[e-mail]>
Subject: Re: damping persistent peer oscillations 
Date: Fri, 6 Dec 2002 19:10:15 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

Whoops; I asked for the word flapping to be taken out of this section
because it had nothing to do with this RFC and might confuse people
into thinking it had!  (And my comment was accepted by Yakov).

My understanding is different, that peer oscillation damping refers to
IDs such as
draft-hares-bgp-backoff-01.txt
which appeared in the summer and which are on hold, to be returned to
once the base spec has been finalised.

Tom Petch
[e-mail]

-----Original Message-----
From: Curtis Villamizar <[e-mail]>
To: Natale, Jonathan <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: 06 December 2002 18:34
Subject: Re: damping persistent peer oscillations


>
>In message
<[e-mail]
>ks.com>, "Natale, Jonathan" writes:
>> >From Draft 18:
>> "Local system automatically starts the BGP peer connection with
persistent
>> peer oscillation damping enabled.  The exact method of damping
persistent
>> peer oscillations is left up to the implementation.   These methods
of
>> damping persistent BGP adjacency flapping are outside the scope of
this
>> document."
>>
>> -- is there a draft describing a "method of damping persistent peer
>> oscillations" ?
>
>
>RFC 2439 "BGP Route Flap Damping":
>
>  4.8.5 Processing A Peer Router Loss
>
>   When a peer routing session is broken, either all individual
routes
>   advertised by that peer may be marked as unstable, or the peering
>   session itself may be marked as unstable.  Marking the peer will
save
>   considerable memory.  Since the individual routes are advertised
as
>   unreachable to routers beyond the immediate problem, per route
state
>   will be incurred beyond the peer immediately adjacent to the BGP
>   session that went down.  If the instability continues, the
>   immediately adjacent router need only keep track of the peer
>   stability history.  The routers beyond that point will receive no
>   further advertisements or withdrawal of routes and will dispose of
>   the damping structure over time.
>
>   BGP notification through an optional transitive attribute that
>   damping will already be applied may be considered in the future to
>   reduce the number of routers that incur damping structure storage
>
>Curtis




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA01778 for <[e-mail]>; Fri, 6 Dec 2002 14:02:02 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id CBC06912E7; Fri,  6 Dec 2002 14:01:34 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81A7F912E8; Fri,  6 Dec 2002 14:01:32 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 79BA6912E5 for <[e-mail]>; Fri,  6 Dec 2002 14:01:26 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 88DDD5DF61; Fri,  6 Dec 2002 14:01:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 4C0A55DDC8 for <[e-mail]>; Fri,  6 Dec 2002 14:01:11 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <YL0CTXQY>; Fri, 6 Dec 2002 14:01:11 -0500
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: damping persistent peer oscillations 
Date: Fri, 6 Dec 2002 14:01:10 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Curtis,

Thanks for the reply.

But I was looking for *peer* oscillation damping, not *route* oscillation
damping.  RFC1771 had:

    "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."

--Current implementations (AKA Juniper and Cisco) do not do this, and the
draft-18 has it tagged as out of scope (see below).

Maybe this will be in the RFC1772 re-do and/or a BCP?


> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]] 
> Sent: Friday, December 06, 2002 1:33 PM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: damping persistent peer oscillations 
> 
> 
> 
> In message 
> <[e-mail]
> ks.com>, "Natale, Jonathan" writes:
> > >From Draft 18:
> > "Local system automatically starts the BGP peer connection 
> with persistent
> > peer oscillation damping enabled.  The exact method of 
> damping persistent
> > peer oscillations is left up to the implementation.   These 
> methods of
> > damping persistent BGP adjacency flapping are outside the 
> scope of this
> > document."
> > 
> > -- is there a draft describing a "method of damping persistent peer
> > oscillations" ?
> 
> 
> RFC 2439 "BGP Route Flap Damping":
> 
>   4.8.5 Processing A Peer Router Loss
> 
>    When a peer routing session is broken, either all individual routes
>    advertised by that peer may be marked as unstable, or the peering
>    session itself may be marked as unstable.  Marking the 
> peer will save
>    considerable memory.  Since the individual routes are advertised as
>    unreachable to routers beyond the immediate problem, per 
> route state
>    will be incurred beyond the peer immediately adjacent to the BGP
>    session that went down.  If the instability continues, the
>    immediately adjacent router need only keep track of the peer
>    stability history.  The routers beyond that point will receive no
>    further advertisements or withdrawal of routes and will dispose of
>    the damping structure over time.
> 
>    BGP notification through an optional transitive attribute that
>    damping will already be applied may be considered in the future to
>    reduce the number of routers that incur damping structure storage
> 
> Curtis
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA00246 for <[e-mail]>; Fri, 6 Dec 2002 13:34:28 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2D694912E3; Fri,  6 Dec 2002 13:34:14 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EEE43912E4; Fri,  6 Dec 2002 13:34:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AA5A9912E3 for <[e-mail]>; Fri,  6 Dec 2002 13:34:12 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 882905DF61; Fri,  6 Dec 2002 13:34:12 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id C8BB75DE6B for <[e-mail]>; Fri,  6 Dec 2002 13:34:11 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA21255; Fri, 6 Dec 2002 13:33:01 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Reply-To: [e-mail]
Subject: Re: damping persistent peer oscillations 
In-reply-to: Your message of "Fri, 06 Dec 2002 10:47:19 EST." <[e-mail]> 
Date: Fri, 06 Dec 2002 13:33:01 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> >From Draft 18:
> "Local system automatically starts the BGP peer connection with persistent
> peer oscillation damping enabled.  The exact method of damping persistent
> peer oscillations is left up to the implementation.   These methods of
> damping persistent BGP adjacency flapping are outside the scope of this
> document."
> 
> -- is there a draft describing a "method of damping persistent peer
> oscillations" ?


RFC 2439 "BGP Route Flap Damping":

  4.8.5 Processing A Peer Router Loss

   When a peer routing session is broken, either all individual routes
   advertised by that peer may be marked as unstable, or the peering
   session itself may be marked as unstable.  Marking the peer will save
   considerable memory.  Since the individual routes are advertised as
   unreachable to routers beyond the immediate problem, per route state
   will be incurred beyond the peer immediately adjacent to the BGP
   session that went down.  If the instability continues, the
   immediately adjacent router need only keep track of the peer
   stability history.  The routers beyond that point will receive no
   further advertisements or withdrawal of routes and will dispose of
   the damping structure over time.

   BGP notification through an optional transitive attribute that
   damping will already be applied may be considered in the future to
   reduce the number of routers that incur damping structure storage

Curtis


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA21022 for <[e-mail]>; Fri, 6 Dec 2002 10:48:39 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BEE889124F; Fri,  6 Dec 2002 10:48:18 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92B5491291; Fri,  6 Dec 2002 10:48:18 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 015179124F for <[e-mail]>; Fri,  6 Dec 2002 10:47:28 -0500 (EST)
Received: by segue.merit.edu (Postfix) id BF2B45DF1A; Fri,  6 Dec 2002 10:47:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 194105DF20 for <[e-mail]>; Fri,  6 Dec 2002 10:47:21 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <YL0CTWRR>; Fri, 6 Dec 2002 10:47:20 -0500
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: damping persistent peer oscillations
Date: Fri, 6 Dec 2002 10:47:19 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

>From Draft 18:
"Local system automatically starts the BGP peer connection with persistent
peer oscillation damping enabled.  The exact method of damping persistent
peer oscillations is left up to the implementation.   These methods of
damping persistent BGP adjacency flapping are outside the scope of this
document."

-- is there a draft describing a "method of damping persistent peer
oscillations" ?


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA05552 for <[e-mail]>; Fri, 6 Dec 2002 06:05:33 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 480F79121A; Fri,  6 Dec 2002 06:03:29 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 019649123F; Fri,  6 Dec 2002 06:03:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0FE849121A for <[e-mail]>; Fri,  6 Dec 2002 06:03:05 -0500 (EST)
Received: by segue.merit.edu (Postfix) id E25815DE6C; Fri,  6 Dec 2002 06:03:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id 2A1565DD9B for <[e-mail]>; Fri,  6 Dec 2002 06:03:02 -0500 (EST)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <YFVC170G>; Fri, 6 Dec 2002 16:41:17 +0530
Message-ID: <[e-mail]>
From: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
To: Susan Hares <[e-mail]>, Yakov Rekhter <[e-mail]>, Jeffrey Haas <[e-mail]>
Cc: [e-mail], "Sivananda Ramnath (E-mail)" <[e-mail]>, "Venu Kumar G - CTD, Chennai." <[e-mail]>
Subject: RE: Response to FSM input - Comments 1-10
Date: Fri, 6 Dec 2002 16:35:16 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hello,

Revised summary:

Comment 1 - No text change, Potential consensus
Comment 2a - No consensus
Comment 2b - No consensus
Comment 3 - New text suggested, no consensus
Comment 4 - Resolved, text changed. Can we consider this closed ?
Comment 5 - No text change, Potential consensus
Comment 6 - No consensus
Comment 7 - No consensus, comment re-phrased.
Comment 8 - No text change, potential consensus
Comment 9 - Resolved, text changed. Can we consider this closed ?
Comment 10 - Resolved, text changed. Can we consider this closed ?

> 
> Comment 1 - no consensus
> Comment 2a - out of date (No IdleHold Timer exists) 
> Comment 2b - no consensus, can't remove due to OpenSent state
> 		 action.
> 
> Comment 3 - no text proposed, do we want all options
> 		specified in 8.1 (7 options) 
> 		Please review and comment on text 
>  
> Comment 4 - agree
> Comment 5 - no text proposed, no consensus
> Comment 6 - no consensus on the text
> Comment 7 - see comment 3, no consensus
> Comment 8 - question, no text 
> Comment 9 - agree, I supplied text 
> Comment 10 - agree to remove text in option,
> 		 different text for definition.
> 
> 
> Sue Hares
> 
> ==========
> 
> comment 1: 
> 
> 1) removal of peer oscillation damping 
> 
> The reason we should not remove the peer oscillation damping
> from the state machine:
> 
>   1) Deployed implementations support peer oscillation damping 
>   2) Hooks for the additions in the FSM cannot be added later.
> 
> These hooks are optional and do not need to be implemented. 

  I understand. I am not trying to object to peer oscillation
  damping, I think it is a good idea and we have included it in
  our implementation as well. I was suggesting that instead of
  a partial description in this draft, it be completely described
  in the draft on peer oscillation damping.

  However, I do see your point, and unless there are any objections
  from others, I think we have consensus on this issue.

> 
>  
> 2) Idle HoldTimer in draft-18
> 
>   Perhaps this is an old comment.  I don't find IdleHoldTimer
>   in the messages.

    It is listed as Event 8. Perhaps this is what needs to be
    removed ?

> 
> 3) HoldTime and HoldTimer
> 
>    The Hold Time is specified on page 13 of the draft-18 specification
>    as to the value and size.  The text in OpenSent requires
>    both a HoldTime and HoldTimer value.
> ===========
>    OpenSent:
>    
>     In this state BGP waits for an Open Message from its peer.  
 [SNIP]
>   
> ===================

  I understand. However, on this basis, we would also need a Keepalive
  time (since the basis on wihch this is be arrived at can be
  configurable). I don't know whether we do need to make such changes
  to the draft, and I am OK to leaving this portion as it stands.

> The earlier comments on the list indicated we need to collect what
> timers or Timer values were utilized in the FSM.  I believe Alex
> made this comment last January.  (the list archives will have
> this information.)
> 
> So, I don't see any way to

  The DelayBgpOpenTimer is missing from the session attributes list,
  how about including it ?

> 
> Comment 3: optional parameters specified
> 
> Please suggest text.  We have the following optional parameters:
> 
> 1) Delay Open
> 2) Accept unconfigured peers
> 3) automatic start [Event 3] 
> 4) passive TCP establishment (optional)
> 	4 + 5 = Event 5
> 5) BGP_stop_flap (BGP Peer oscillation) [Event 6] 
> 6)automatic stop [Event 7] 
> 7)Collision detect in Established State 
> 
> If you want some of the optional parameters specified, let's
> catch all.  Please suggest text and location.  It could
> go in 8.1.

  My view is this can be split into two categories:

  Optional attributes exist per session, and optional attributes
  for the entire system.

  How about adding the following to section 8 (immediately before 8.1)

%  Optional session attributes that a implementation may support
%  for a session are:
%
%    1) DelayOpen flag
%    2) DelayOpen Timer
%    3) Perform automatic start
%    4) Passive TCP establishment
%    5) Perform automatic stop
%    6) BGP Perform 
%
%
%  Implementations may also support the following optinal attributes
%  that modify the behavior of the state machine
%
%    1) Accept un-configured peers
%    2) Perform collision detect in Established state

    I guess it is possible to have some of these things listed under
    both categories. Am I opening up a can of worms here ?  :-)

> --------------------------------
> Comment 4
> 
> Old Text: 
>   Event 1: Manual Start
>       Definition: Administrator manually starts peer connection.
> 
>  ... 
>   Event 2: Manual Stop 
> 	 Definition: Local system administrator manually stops the 
> 		       peer connection. 
> New Text: 
>   Event1: Manual start
>        Definition: Local system administrator manually starts the
> 		       bgp connection.
> 
>   ... 
>   Event 2: Manual stop:
> 	  Definition: Local system administrator manually stops the 
> 			  bgp connection.
> 
> agree? 

  Agreed.

> ---------------
> Comment 5: 
> 
> 5) Event3, Event5, Event6 and Event7
> 
> 5a) 
> =========
>   Event 3/6/7 - cisco indicated the automatic stop, see the NANOG
> 		  archives for a discussion of the Bad Route
> 
>     http://www.merit.edu/mail.archives/nanog/2001-06/msg00805.html
> 
>   The "event" sequences are new with this version of the FSM
>   to identify particular events by number. 

    I am unclear on what this issue is!

> 5b
> ======
> 
>   Can we give examples of these events, as implemneted by curent
>   implementations ? This will be of help to new implementaions.
> 
>   An example of Auto Stop is already present in the Update event
>   handling section, and we can move that to this place as well.
> 
> I believe that examples are outside the scope of this specification.
> If you have text clarifying the event descriptions, please send it in.

  Well, the current text in the established state already gives an example
  for an automatic start event. I was suggesting that such examples be
  moved to the event description section.

  I also think adding text to clarify the intent behind optional events,
  and giving examples would help, especially for new implementors. However,
  if you feel this is outside the scope of the RFC, we can leave things
  as is.


> 
> 
> =======================================================
> 
> 6) Event 4,5 Definition
> 
> >	   Definition: Administrator manually start the peer
> >                       Connection, but has the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing the connection.
> 
> 
> >	  Definition:  Local system automatically starts the
> >                       BGP session with the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing a connection.
> 
> 
> >My understanding is this is used to indicate a peer configuration
> >where we start the state machine, and wait for an incoming connection
> >request from the configured peer. Can we re-phrase this section to
> >indicate this.
> 
> >How about something like:
> >
> >% The passive flag indicates that the state machine will wait for
> >% specified peer to initiate a connection with the local system. If
> >% this does not happen within a specific time (hold time), the local
> >% system will then also attempt to initiate connection with the
> >% specified peer.
> 
> The text in 8.2.1.1 indicates the definition of the passive flag. 

   Yes. 
> 
> 6a) 
> ==========
> My understanding of your text is that you want to replace in both
> sets of text: 
> 
> "The passive flag indicates the peer will listen prior to 
>  establishing a connection".  
> 
> with: 
> 
> "The passive flag indicates that the state machine will wait for the
> specified peer to initiate a connection with a local system.
> 
> The problem with this sentence is that in the "unconfigured" case
> the phrase "specified" peer is confusing.  I think the original text
> is clearer. 

  I am ok to leave the text as is, based on text in 8.2.1.1. However,
  I do not quite understand your point. In the case of an un-configured
  peer, the local system cannot 'establish a connection', so is the
  unconfigured peer case still valid in this context ?

> 6b)
> ==========
> If this does not happen within a specific time (hold time), the local
> system will then also attempt to initiate (a) connection with the
> specified peer.
> 
> My comments: Again, the "specified peer" term is confusing.  Also,
> the 2nd half of the statement mixes the actions of the state machine
> with the events.  I believe this muddies the text instead of
> clarifying it.

  Please refer to my comments for 6a.

  I think a reason for this is the requirement (in 8.2.1) that a FSM be
  established a-priori for "accepting each incoming TCP connection for
  which the peer has not beet identified".

  Is the intent to establish a FSM session for accepting TCP connections
  from un-configured peers ? If so, I am of the opinion that this is
  purely an implementation issue, and need not be a requirement in the spec.

>  
> =================
> Comment 7 -
> 
> Event 6 - (not specified, please confirm) 
> 
> >  Won't a variant of this with bgp_stop_flap option set be requried ?
> >  We can also achieve the same by using the bgp_stop-Flap option as a
> >  flag that is provided as an input to the state machine.
> 
> see comment number 3.  bgp_stop_flap is an option.  
> 
> This state machine description has many events to describe the
> mixture of options and actions.  I believe it has a better clarity
> than testing lots of flags within a state. 
> 
> A proof in case, is that many people are making comments about
> specific transitions. 

   I tink I should have phrased my question much better.

   We already have 
   Event 3 - Automatic Start
   Event 5 - Automatic start with bgp_stop_flap option set

   To make things consistent, shouldn't we either

   a) Add 3 new events : 1) Manual start with bgp_stop flap option set
                         2) Manual start with passive TCP establishment
                            and bgp_stop_flap option set
                         3) Automatic start with passive TCP establishment
                            and bgp_stop_flap option set

   or

   b) Remove Event 6, and rely on a flag to tell us wether peer flap damping
      is to be performed for the session or not.


> 
> ============
> Comment 8 - 
> 
> 
> 8) Event 5 Definition
> 
> >	  Definition:  Local system automatically starts the
> >                       BGP session with the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing a connection.
> 
> > Is it correct that this event will occur only when we want 
> to restart
> > a connection (after it had been terminated due to some reason beside
> > administrative action) that we had accepted from an 
> unconfigured peer ?
> 
> The automatic start function is an implementation specific mechanism.
> This text does not seek to restrict it in any fashion.

  Well, for new implementors, such clarifications will help undertsand
  how to generate and make use of this event. Again, I am OK with
  leaving text as is.

> 
> ================
> 9) Timer Events Definition
> 
> > Event8:  idle Hold timer expires=20
> >
> >           Definition: Idle Hold timer expires.  The Idle=20
> >
> > Event9: connect retry timer expires
> >
> >           Definition: An event triggered by the expiration of=20
> > Event10: hold time expires
> >
> >	   Definition: An event generated when the HoldTimer=20
> 
> We can use any one of these terms (trigerred by/generated 
> when) for all
> timer event definitions to make it look more consistent.
> 
> agree: Will use "generate" 
> 
> Event 8: An event generated when the Idle Hold timer expires.
> Event 9: An event generated when the ConnectRetry timer expires.
> Event 10: An event generated when the Hold timer expires.  
> Event 11: An event generated when the Keepalive timer expires
> Event 12: An event generated when the Delay BGP Open timer expires.
> 
> Please confirm that this change to the definitions is agreeable to
> you.

  Agreed.
  I think we have consensus on this issue, unless anyone else
  has any comments on this.

> 
> ================
> 10) Event 8 Definition
> 
> > Event8:  idle Hold timer expires=20
> >
> >           Definition: Idle Hold timer expires.  The Idle=20
> >                       Hold Timer is only used when persistent =20
> >                       BGP oscillation damping functions are=20
> >                       enabled. =20
> >
> >           Status: 	Optional.  Used when persistent
> >			BGP peer oscillation damping functions
> >			are enabled.=20
> 
> 
> The status repeats the senetnce in the definition. Can we remove the
> sentence from the Status, or replace with a different definition.
> 
> Do you think the defenition below would fit ?
> 
> % An event trigerred by the expiry of the Idle Hold timer, indicating
> % that the session has completed waiting for a back-off period to
> % prevent flap, and may now proceed to take any further systemm
> % initiated action for this session. 
> 
> text change suggestion for 1st sentence that I'll agree to.
> 
>  An event trigerred by the expiry of the Idle Hold timer, indicating
>  that the session has completed waiting for a back-off period to
>  prevent bgp peer oscillation.
> 
> Please confirm that you will agree to this.

  Agreed.
  I think we have consensus on this issue, unless anyone else
  has any comments on this.


Siva
([e-mail])> 


Original text of comments 1-10 follow:


> 
> ------- Message 4
> 
> Date:    Fri, 29 Nov 2002 19:46:06 +0530
> From:    "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
> To:      [e-mail], Yakov Rekhter <[e-mail]>
> cc:      [e-mail]
> Subject: Comments on draft 18
> 
> 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_000_01C297B1.DB0F1700
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> 
> Hello,
> 
>     Attached are some comments that I have on draft-ietf-idr-bgp4-18.
> 
>     Please have a look at these and tell me if the same can 
> be raised to the
> mailing list as well.
> 
> Thanks,
> Siva
> ([e-mail])
>   
> 
> 
> - ------_=_NextPart_000_01C297B1.DB0F1700
> Content-Type: text/plain;
> 	name="BGP_Issues.txt"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: attachment;
> 	filename="BGP_Issues.txt"
> 
> All quoted sections of the original document have been 
> prefixed by a '> =
> '
> All lines of proposed text have been prefixed by a '% '
> 
> 
> 1) Performing of peer oscillation damping:
> 
> Since this feature is going to be added in a new draft, and its
> addition will change the operation of the state machine, can we remove
> all mention of it in the state machine ? As part of this removal, can
> we also remove the IdleHold Timer from the FSM since it is not useful
> in the absence of peer oscillation damping ?
> 
> The draft that describes this procedure can then describe the change
> in the state machine required to do this.
> 
> 
> 2) Session Attributes:
> 
> > Session Attributes required for each connection are;=20
> 
> >   1) state
> >   2) Connect Retry timer
> >   3) Hold timer
> >   4) Hold time
> >   5) Keepalive timer
> 
> Why have a Hold Timer and a Hold Time ? Can we replace this with just
> Hold timer ?
> 
> Can we also add the following session attributes:
> 
> a) DelayBgpOpenTimer
> b) IdleHold Timer (in case we choose not to remove this from the bas =
> FSM)
> 
> Can we also add the following flag to the session attributes:
> a) DelayOpen Flag
> 
> 
> 3) All sessions attributes:
> 
>   There are some attributes that are common to all sessions of the =
> system.
>   Can we call these out as well:
> 
>   * Accept Connections from unconfigured peers (Enabled/Disabled)
>   * Peer Oscillation Dampening (Enabled/Disabled) (In case we choose
>     not to remove it from base spec)
> 
> 
> 4) Description for Event1/Event2
> 
> > Event1: Manual start=20
> >
> >	   Definition: Administrator manually starts peer
> >                       connection
> 
> > Event2: Manual stop
> 
> >	   Definition: Local system administrator manually=20
> >                       stops the peer connection.
> 
> We can make these look consistent by using the Term Administrator or
> Local System administrator in both cases.
> 
> 
> 5) Event3, Event5, Event6 and Event7
> 
>   Can we give examples of these events, as implemneted by curent
>   implementations ? This will be of help to new implementaions.
> 
>   An example of Auto Stop is already present in the Update event
>   handling section, and we can move that to this place as well.
> 
> 
> 6) Event 4,5 Definition
> 
> >	   Definition: Administrator manually start the peer
> >                       Connection, but has the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing the connection.
> 
> 
> >	  Definition:  Local system automatically starts the
> >                       BGP session with the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing a connection.
> 
> 
> My understanding is this is used to indicate a peer configuration
> where we start the state machine, and wait for an incoming connection
> request from the configured peer. Can we re-phrase this section to
> indicate this.
> 
> How about something like:
> 
> % The passive flag indicates that the state machine will wait for
> % specified peer to initiate a connection with the local system. If
> % this does not happen within a specific time (hold time), the local
> % system will then also attempt to initiate connection with the
> % specified peer.
> 
> 
> 7) Event 4,5
> 
>   Won't a variant of this with bgp_stop_flap option set be requried ?
>   We can also achieve the same by using the bgp_stop-Flap option as a
>   flag that is provided as an input to the state machine.
> 
> 
> 8) Event 5 Definition
> 
> >	  Definition:  Local system automatically starts the
> >                       BGP session with the passive flag=20
> >                       enabled.  The passive flag indicates=20
> >                       that the peer will listen prior to=20
> >                       establishing a connection.
> 
> Is it correct that this event will occur only when we want to restart
> a connection (after it had been terminated due to some reason beside
> administrative action) that we had accepted from an 
> unconfigured peer ?
> 
> 
> 9) Timer Events Definition
> 
> > Event8:  idle Hold timer expires=20
> >
> >           Definition: Idle Hold timer expires.  The Idle=20
> >
> > Event9: connect retry timer expires
> >
> >           Definition: An event triggered by the expiration of=20
> > Event10: hold time expires
> >
> >	   Definition: An event generated when the HoldTimer=20
> 
> We can use any one of these terms (trigerred by/generated 
> when) for all
> timer event definitions to make it look more consistent.
> 
> 
> 
> 10) Event 8 Definition
> 
> > Event8:  idle Hold timer expires=20
> >
> >           Definition: Idle Hold timer expires.  The Idle=20
> >                       Hold Timer is only used when persistent =20
> >                       BGP oscillation damping functions are=20
> >                       enabled. =20
> >
> >           Status: 	Optional.  Used when persistent
> >			BGP peer oscillation damping functions
> >			are enabled.=20
> 
> 
> The status repeats the senetnce in the definition. Can we remove the
> sentence from the Status, or replace with a different definition.
> 
> Do you think the defenition below would fit ?
> 
> % An event trigerred by the expiry of the Idle Hold timer, indicating
> % that the session has completed waiting for a back-off period to
> % prevent flap, and may now proceed to take any further systemm
> % initiated action for this session.
> 
> 
> --



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA01446 for <[e-mail]>; Thu, 5 Dec 2002 19:01:49 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 17F59912D8; Thu,  5 Dec 2002 19:00:29 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFE2A912D9; Thu,  5 Dec 2002 19:00:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1450F912D8 for <[e-mail]>; Thu,  5 Dec 2002 19:00:25 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B0F505DF3A; Thu,  5 Dec 2002 19:00:22 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id B51305E0FB for <[e-mail]>; Thu,  5 Dec 2002 19:00:20 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gB600Jg71542 for [e-mail]; Thu, 5 Dec 2002 19:00:19 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gB600DC71529 for <[e-mail]>; Thu, 5 Dec 2002 19:00:13 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
Subject: RE: bgp18 WG Last Call fsm missing next state
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Thu, 5 Dec 2002 19:00:13 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: bgp18 WG Last Call fsm missing next state
Thread-Index: AcKcrBbJC1arMGN2RcqWX3lbKoQCwgABrflg
From: "Susan Hares" <[e-mail]>
To: "Tom Petch" <[e-mail]>, "Jeffrey Haas" <[e-mail]>
Cc: "idr" <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id TAA01446

Tom:

Thanks for the input.

1 - done  
2 - sent to the list for implementations
3 - done, and question about
	     1 addition.


4,5 - I'll look for different thread

6 - sent to list for implementations
    I'm happy with alternative 2 if
    no one else works on it.

7 - this mechanism allows a single fsm to
    handle both.  2 fsm and 1 fsm BGP FSM
    seem to exist.  (I queried implementors
    a few times on this one.  So, I just
    put in this change to provide the 
    flexibility.  

	Collision detect tends to give
	scrambled brains for most people..
	As Dennis Ferguson said 2 years ago,
	that's the hardest part of the FSM.


Soo.. bottom line.  I'll look to see if
any implementors work on 2, 6 or 7.
I'll query a few of the implementors in
a questionnaire as well.

Thanks for the hard work!

Sue

3's question
---------
	Should I add completes BGP initialization in
	the following list:

If the TCP connection succeeds [Event 15 or Event 16],
local system checks the Delay Open flag prior to
processing:   If the Delay Open flag is set, the local system:
- clears the connect retry timer,
%- sets the BGP** Open Delay timer to initial value, and
%- complets the BGP initialization 
- stays in the Connect state.

If the Delay Open flag is not set, the local system:
- clears the connect retry timer,
- clears the BGP**Open Delay timer (sets to zero),
- completes the BGP initialization,
- sends an Open message to its peer,
- sets the hold timer to a large value, and
- changes the state to Open Sent.





-----Original Message-----
From: Tom Petch [mailto:[e-mail]]
Sent: Thursday, December 05, 2002 5:15 PM
To: Susan Hares; Jeffrey Haas
Cc: idr
Subject: Re: bgp18 WG Last Call fsm missing next state


Sue, Jeff
Agree with 1 (with a slight change of words put **inline to make the
name the Open Delay timer as Yakov accepted

	- done

2 wait on implementors -  but do we need a then clause for when peer
oscillation damping does not allow a new connection in alternative
1(also flagged inline)?

	- I think I sent out the query to the implementors. 
	  I'll resend to the list. 

agree with 3
4,5 on a different thread

6 as you say, it depends on the implementations; I always like
failures such as Event 17 to take us to Idle so I hope the answer is
alternative 2
7 I am still struggling with; we are in OpenConfirm so we already have
received an Open from the remote peer and Event 18 is a second Open
from the same peer.  Perhaps my struggle is that I think in terms of
two (or more) FSM for a given IP address pair so the Open Collision
detection will occur when the/an- other FSM receives a valid Open in
states Active/Connect/Open Sent and will generate Event 22 into this
FSM so Event 18 cannot occur.  But yes, if Event 18 can occur in this
FSM and this connection is to be dumped, then Idle state it should be
as you suggest.  I have slotted in [optionally] in front of the peer
oscillation damping in your text because I think it should be
optional:-)
Collection collision is simple until I think about it :-(

Tom Petch
[e-mail]

-----Original Message-----
From: Susan Hares <[e-mail]>
To: Tom Petch <[e-mail]>; Jeffrey Haas
<[e-mail]>
Cc: idr <[e-mail]>
Date: 05 December 2002 02:17
Subject: RE: bgp18 WG Last Call fsm missing next state


Tom and Jeff:

Thanks for the great review of the state machine.
Please confirm I've got my 7 changes numbered right.

Here's where we have consensus:
change 1 - consensus, editorial
state: Connect
Events: 15 and 16

change 2 - no consensus
I've given two alternatives.
We need to get implementers to pick 1.
thread:
State: Connect
Event: 14

change 3 - consensus, editorial
state: Active:
Events: 15 and 16

change 4 and 5:
State: Active
Events: 13 and 14

On changes 4 and 5 - moved to a different thread
thread titled:  fsm missing next state - Events 13 - 17 and the TCP
connection

on change 6 - no consensus
State: Active
Event: 17

Review my explanation and the new text, and
see if we have consensus.

on change 7: no consensus.
State: Open Confirm
Event: 18

Review my explanation and see if we have
      consensus.

Sue Hares
([e-mail])
=============


Warning - put the screen on wide mode for the following text:

-------------------


Here's my response on the 7 changes

1) Connect State - Event 15 or Event 16 [consensus, editorial]

note:  The delay retry timer is utilized instead of the
connect retry timer for the next two changes.

Previous text:
If the TCP connection succeeds [Event 15 or Event 16],
local system checks the "Delay Open Flag".  If the delay
open flag is set, the local system:
- clears the connect retry timer,
- sets the BGP Open delay timer to initial value

   If the Delay Open flag is not set, the local system:
- clears the connect retry timer,
- clear BGP Open Delay timer (set to zero),
- completes the BGP initialization,
- send an Open message to its peer,
- sets hold timer to a large value, and
- change the state to Open Sent.


New text:
If the TCP connection succeeds [Event 15 or Event 16],
local system checks the Delay Open flag prior to
processing:   If the Delay Open flag is set, the local system:
- clears the connect retry timer,
- sets the BGP** Open Delay timer to initial value, and
- stays in the Connect state.

If the Delay Open flag is not set, the local system:
- clears the connect retry timer,
- clears the BGP**Open Delay timer (sets to zero),
- completes the BGP initialization,
- sends an Open message to its peer,
- sets the hold timer to a large value, and
- changes the state to Open Sent.


**tp agreed with changes to make it Open Delay timer

2)Connect State - Event 14  [no consensus]

Current Text:
If the TCP connection receives an indication that
that is invalid or unconfigured [Event 14],
- the TCP connection is rejected.

At the very least this section needs more "word smithing",
so I'd like to change it for more clarity at least.

I'm not sure this represents the implementations.
What I'd like to do is query the implementations
to see what they do if they receive a valid TCP
connection with an invalid or unconfigured peer.

Two options:

Alternative 1: Count it as a valid response

New Text: If a TCP connection is received that has
     an invalid format, or an unconfigured host [Event 14],
     the local system:
- rejects the TCP connection,
- increments the connect retry counter,
- performs bgp peer oscillation checks.

If bgp peer oscillation checks allow for a new
connection, the bgp peer
- restarts the Connect retry timer with configured
  value, and
- enters the Active state.


**tp  need a then clause here 'if bgp peer oscillation damping does
not allow for a new connection, then the local system ???'

FSM table:
           Idle   Connect Active Open-Sent Open-Confirm Establish
Event-14   =======================================================
Next state Idle  | Active|Active|Open-Sent|Open-Confirm|Establish|
     =======================================================
action       V  | Y2    | L    | Ignore  | Ignore     | Ignore  |
           =======================================================


Alternative 2: Reject the connection and see if valid or
   configured one appears within the
   connect timer window.

New Text: If a TCP connection is received that has an invalid format,
    or an unconfigured host [Event 14], the local system:
- rejects the TCP connection,
- and stays in the Connect state.

FSM table:
           Idle   Connect Active Open-Sent Open-Confirm Establish
Event-14   =======================================================
Nxt state Idle  |Connect|Active|Open-Sent|Open-Confirm|Establish|
     =======================================================
action       V  | L    | L     | Ignore  | Ignore     | Ignore  |
     =======================================================

3) Active State - Event 15 or Event 16 [consensus, editorial]

Previous text:
A TCP connection succeeds [Event 15 or Event 16],
the local system: process the TCP connection flags
- If the BGP delay open flag is set:
- clears the connect retry timer

   [through the following text:
- and changes its state to Open Sent.


New text:
If the TCP connection succeeds [Event 15 or Event 16],
local system checks the "Delay Open Flag" prior to
processing:   If the delay open flag is set, the local system:
- clears the connect retry timer,
- sets the BGP open delay timer to initial value, and
- stays in the Active state.

If the Delay Open flag is not set, the local system:
- clears the connect retry timer,
- clears the BGP Delay timer (sets to zero),
- completes the BGP initialization,
- sends an Open message to its peer,
- sets the hold timer to a large value, and
- changes the state to Open Sent.

4) Active State, Event 13 [no consensus]
5) Active State, Event 14 [no consensus]

  The problem with this state is it is difficult to
  exactly specify without discussing the TCP
  Messages that FSM document covers.

  I'll query if the implementors require all
  of events 13-17 as mandatory.

  We'll

6) Active State, Event 17 [no consensus]

comment:
In the Active state, we may already have a connection and be awaiting
the Open Delay timer.  The TCP disconnect or timeout could occur in
this
state due to the "Open Delay Timer".   If the TCP Disconnect is
ignored,
we could have some peer oscillation.

If the we wait, then the connection retry timer needs to be kept
running.
The text below allows this timer.  The real question is what is the
status
of the current implementations.

I agree, the Active state and the connect state should match.

Old Text:
If the TCP connection fails (timeout or disconnection) [Event 17],
the local system:
- set TCP disconnect in the MIB reason code,
- restart Connect retry timer (with initial value),
- release all BGP resources,
- Acknowledge the Drop of the TCP connection if TCP disconnect (FIN
ACK),
- Increment ConnectRetryCnt (connect retry count) by 1, and
- performs the BGP peer oscillation damping process.

Applicable FSM State table:


FSM table old:

Event 17
current:  Idle   Connect Active Open-Sent Open-Confirm Establish
           =========================================================
Next state Idle  |Active |Idle   |Active | Idle       |Idle       |
     |       |       |       |            |           |
     =========================================================
action       V  | Y2     | G     | Ignore| Track 2nd  | Track 2nd |
                 |       |       |       | connection | connection|
     =========================================================

Alternative 1:


FSM table new:

Event 17
current:  Idle   Connect Active Open-Sent Open-Confirm Establish
           ========================================================
Next state Idle  |Active |Active  |Active | Idle       |Idle      |
         |       |        |       |       |            |          |
     ==============================================================
action        V  | G     | G      | Ignore| Track 2nd  | Track 2nd |
                 |       |        |       | connection | connection|
     ===============================================================

G:  The local system:
- restarts the connect retry timer (at intial value),
- continues to listen for a connection that may be initiated
  by the remote peer, and
- sets its next state to Active.

New Text: (for Connect and Active state)
If the TCP connection fails (timeout or disconnect)
[Event 17], the local system:
- restarts the connect retry timer,
- continues to listen for a connection that may be
  initiated by the remote BGP peer, and
- changes it state to Active.


Alternative 2:
FSM table new:

Event 17
current:  Idle   Connect Active Open-Sent Open-Confirm Establish
           =========================================================
Next state Idle  |Idle   |Idle   |Active | Idle       |Idle       |
     |       |       |       |            |           |
     =========================================================
action       V  | Y2    | Y2    | Ignore| Track 2nd  | Track 2nd |
                 |       |       |       | connection | connection|
     =========================================================

Next Text:
If the location system receives a TCP connection failed [Event 17],
the local system will:
- increment the ConnectRetrycnt (connect retry count) by 1,
- release all BGP resources associated with this connection,
- perform BGP peer oscillation (if configured), and
- go to Idle

Y2 - is:
The local system:
1) increments the ConnectRetryCnt (connect retry count) by 1,
2) releases all BGP resources associated with this connection, and
3) performs the BGP peer oscillation damping process

if the damping process allows for a new connection, the local system
- restarts the connect retry timer (with initial value, and
- goes to Idle

If the damping process does not allow for a new connection, the local
system
- set the flags to damp the creation of a new bgp connection
        until a manual start occurs, and
- goes to Idle.


7) Open Confirm state, Event 18

Here's my proposed text. Please let me know what you think.
I think this is an editorial change.


Old text:  If the open message is valid, the collision detect
           function is processed per section 6.8.  If this
           connection is to be dropped due to call collision, the
local
     system:
- sends a Notification with a Cease
- resets the Connect timer (to zero),
- releases all BGP resources,
- Drop the TCP connection (sends a TCP FIN),
- increments the ConnectRetryCnt by 1 (connect retry count), and
- performs an BGP peer oscillation damping process.

New text:  If the open message is valid, the BGP peer connection
     is check to detect a collision per section 6.8.  If this
           connection is to be dropped due to call collision, the
local
     system:
- sends a Notification with a Cease
- resets the Connect timer (to zero),
- releases all BGP resources,
- Drop the TCP connection (sends a TCP FIN),
- increments the ConnectRetryCnt by 1 (connect retry count), and
- **[optionally] performs an BGP peer oscillation damping processing,
and
- enters the Idle State.

notes: Collision detect impacts Open Sent, Open Confirm, and
Established states.

Applicable FSM state


>>       Open Confirm State:
>>
>>         If the Open messages is valid [Event 18], the collision
>>         detect function is processed per section 6.8.  If this
>>         connection is to be dropped due to call collision, the
>>         local system:
>>** enters what state
>
> This instance of the FSM should be discarded since it implies there
is
> another FSM instance running that will proceed to Established?


-----Original Message-----
From: Tom Petch [mailto:[e-mail]]
Sent: Monday, December 02, 2002 11:07 AM
To: Jeffrey Haas
Cc: idr
Subject: Re: bgp18 WG Last Call fsm missing next state


Jeff

I appreciate your comments, agreeing with many.

A minor supplementary; Open Confirm, valid open [event 18], decide to
drop this connection and so the FSM but what about the actions of
incrementing the ConnectRetryCnt (and optional peer oscillation
damping)?  Are we doing that in the other FSM?  on a per router id or
per IP address pair independent of FSM?

And a slightly bigger issue in the Active state (which is the passive
state because we have entered it from Idle with Passive TCP flag set
Events 4/5).  In which case, TCP Indication valid [event 13] or
invalid [event 14] are what I would expect with event 14 keeping us in
Active state; and if event 13 also keeps us in Active state (while
sending a TCP SYN-ACK) then TCP Connection Confirmed [event 16] will
ensue while TCP Connection Acknowledged [event 15] would be an FSM
error.

Except that you suggest that event 14 in the Connect state takes us to
Active state which seems fine but for the fact that we will have sent
a TCP SYN (because that is what the Connect state is), this invalid
Indication may be a coincidence, in which case our SYN is about to
receive a SYN-ACK back ie event 15 is valid after all.  And I am then
in agreement with you over events 15/16 in the Active (ie passive)
state (delay open flag keeps us in the Active state).

Tom Petch
[e-mail]

-----Original Message-----
From: Jeffrey Haas <[e-mail]>
To: Tom Petch <[e-mail]>
Cc: idr <[e-mail]>
Date: 30 November 2002 01:33
Subject: Re: bgp18 WG Last Call fsm missing next state


>Tom,
>
>On Thu, Nov 28, 2002 at 02:53:56PM -0000, Tom Petch wrote:
>> In seven places in the FSM, the actions listed for the occurrence
of
>> an event do not include any indication of what the next state
should
>> be, nor can I be sure I can guess what it should be.
>>
>> I believe the FSM should specify the new state in the cases listed
>> below.
>>
Change 1:

>>       Connect State:
>>
>>         If the TCP connection succeeds [Event 15 or
>>         Event 16], the local system checks the "Delay Open
>>         Flag".  If the delay Open flag is set, the local system:
>> **enters what state
>
>Remains in the connect state awaiting either an open message or
>for the opendelay timer to expire.
Agreed

Change 2:
>
>>         If the TCP connection receives an indication
>>         that is invalid or unconfigured. [Event 14]:
>> **enters what state
>
>Enters the active state.
>Connectretrytimer should be started.
Agreed

Change 3:
>>       Active State:
>>
>>         A TCP connection succeeds [Event 15 or Event 16], the
>>         local system: process the TCP connection flags
>>          - If the BGP delay open flag is set:
>> ** enters what state (I think this is an FSM error in TCP because
it
>> has not initiated a connection!)
>In the active state, we are awaiting incoming tcp connections to be
>completed.  Here we should:
>
>remain in the active state
>wait for an open message or the opendelay timer to expire.
>
Change 4:

>>         If the local system receives a valid TCP Indication
>>         [Event 13], the local system processes the TCP connection
>> flags.
>> ** enters what state
>
>I'm also confused by this event.  Since we are not initiating a TCP
>connection, but are awaiting one to complete, why would we get an
>Indication here?  FSM error?

We would get an indication from the remote side that it had
send us a TCP Syn.  The real question is

Change 5:

>>         If the local system receives a TCP indication
>>         that is invalid for this connection [Event 14]:
>> ** enters what state
>
>Ditto.

Change 6:
>>
>>         If the local system receives a TCP connection
>>         failed [Event 17] (timeout or receives connection
>>         disconnect), the local system will:
>> ** enters what state
>
>Ditto.

Change 7:
>>       Open Confirm State:
>>
>>         If the Open messages is valid [Event 18], the collision
>>         detect function is processed per section 6.8.  If this
>>         connection is to be dropped due to call collision, the
>>         local system:
>> ** enters what state
>
>This instance of the FSM should be discarded since it implies there
is
>another FSM instance running that will proceed to Established?
>
>> Tom Petch
>> [e-mail]
>
>--
>Jeff Haas
>NextHop Technologies





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA25840 for <[e-mail]>; Thu, 5 Dec 2002 17:18:32 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D7161912D5; Thu,  5 Dec 2002 17:18:02 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E5AD912D7; Thu,  5 Dec 2002 17:18:02 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 622AE912D5 for <[e-mail]>; Thu,  5 Dec 2002 17:17:20 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 422C35DDFE; Thu,  5 Dec 2002 17:17:20 -0500 (EST)
Delivered-To: [e-mail]
Received: from nemesis.systems.pipex.net (nemesis.systems.pipex.net [62.241.160.8]) by segue.merit.edu (Postfix) with ESMTP id 5614D5DEAD for <[e-mail]>; Thu,  5 Dec 2002 17:17:19 -0500 (EST)
Received: from tom3 (usermh96.uk.uudial.com [62.188.122.181]) by nemesis.systems.pipex.net (Postfix) with SMTP id AB7BA1600277B; Thu,  5 Dec 2002 22:17:09 +0000 (GMT)
Message-ID: <018f01c29cac$089cd8c0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Susan Hares" <[e-mail]>, "Jeffrey Haas" <[e-mail]>
Cc: "idr" <[e-mail]>
Subject: Re: bgp18 WG Last Call fsm missing next state
Date: Thu, 5 Dec 2002 22:14:46 -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: [e-mail]
Precedence: bulk

Sue, Jeff
Agree with 1 (with a slight change of words put **inline to make the
name the Open Delay timer as Yakov accepted
2 wait on implementors -  but do we need a then clause for when peer
oscillation damping does not allow a new connection in alternative
1(also flagged inline)?
agree with 3
4,5 on a different thread
6 as you say, it depends on the implementations; I always like
failures such as Event 17 to take us to Idle so I hope the answer is
alternative 2
7 I am still struggling with; we are in OpenConfirm so we already have
received an Open from the remote peer and Event 18 is a second Open
from the same peer.  Perhaps my struggle is that I think in terms of
two (or more) FSM for a given IP address pair so the Open Collision
detection will occur when the/an- other FSM receives a valid Open in
states Active/Connect/Open Sent and will generate Event 22 into this
FSM so Event 18 cannot occur.  But yes, if Event 18 can occur in this
FSM and this connection is to be dumped, then Idle state it should be
as you suggest.  I have slotted in [optionally] in front of the peer
oscillation damping in your text because I think it should be
optional:-)
Collection collision is simple until I think about it :-(

Tom Petch
[e-mail]

-----Original Message-----
From: Susan Hares <[e-mail]>
To: Tom Petch <[e-mail]>; Jeffrey Haas
<[e-mail]>
Cc: idr <[e-mail]>
Date: 05 December 2002 02:17
Subject: RE: bgp18 WG Last Call fsm missing next state


Tom and Jeff:

Thanks for the great review of the state machine.
Please confirm I've got my 7 changes numbered right.

Here's where we have consensus:
change 1 - consensus, editorial
state: Connect
Events: 15 and 16

change 2 - no consensus
I've given two alternatives.
We need to get implementers to pick 1.
thread:
State: Connect
Event: 14

change 3 - consensus, editorial
state: Active:
Events: 15 and 16

change 4 and 5:
State: Active
Events: 13 and 14

On changes 4 and 5 - moved to a different thread
thread titled:  fsm missing next state - Events 13 - 17 and the TCP
connection

on change 6 - no consensus
State: Active
Event: 17

Review my explanation and the new text, and
see if we have consensus.

on change 7: no consensus.
State: Open Confirm
Event: 18

Review my explanation and see if we have
      consensus.

Sue Hares
([e-mail])
=============


Warning - put the screen on wide mode for the following text:

-------------------


Here's my response on the 7 changes

1) Connect State - Event 15 or Event 16 [consensus, editorial]

note:  The delay retry timer is utilized instead of the
connect retry timer for the next two changes.

Previous text:
If the TCP connection succeeds [Event 15 or Event 16],
local system checks the "Delay Open Flag".  If the delay
open flag is set, the local system:
- clears the connect retry timer,
- sets the BGP open delay timer to initial value

   If the Delay Open flag is not set, the local system:
- clears the connect retry timer,
- clear BGP Open Delay timer (set to zero),
- completes the BGP initialization,
- send an Open message to its peer,
- sets hold timer to a large value, and
- change the state to Open Sent.


New text:
If the TCP connection succeeds [Event 15 or Event 16],
local system checks the Delay Open flag prior to
processing:   If the Delay Open flag is set, the local system:
- clears the connect retry timer,
- sets the BGP** Open Delay timer to initial value, and
- stays in the Connect state.

If the Delay Open flag is not set, the local system:
- clears the connect retry timer,
- clears the BGP**Open Delay timer (sets to zero),
- completes the BGP initialization,
- sends an Open message to its peer,
- sets the hold timer to a large value, and
- changes the state to Open Sent.


**tp agreed with changes to make it Open Delay timer

2)Connect State - Event 14  [no consensus]

Current Text:
If the TCP connection receives an indication that
that is invalid or unconfigured [Event 14],
- the TCP connection is rejected.

At the very least this section needs more "word smithing",
so I'd like to change it for more clarity at least.

I'm not sure this represents the implementations.
What I'd like to do is query the implementations
to see what they do if they receive a valid TCP
connection with an invalid or unconfigured peer.

Two options:

Alternative 1: Count it as a valid response

New Text: If a TCP connection is received that has
     an invalid format, or an unconfigured host [Event 14],
     the local system:
- rejects the TCP connection,
- increments the connect retry counter,
- performs bgp peer oscillation checks.

If bgp peer oscillation checks allow for a new
connection, the bgp peer
- restarts the Connect retry timer with configured
  value, and
- enters the Active state.


**tp  need a then clause here 'if bgp peer oscillation damping does
not allow for a new connection, then the local system ???'

FSM table:
           Idle   Connect Active Open-Sent Open-Confirm Establish
Event-14   =======================================================
Next state Idle  | Active|Active|Open-Sent|Open-Confirm|Establish|
     =======================================================
action       V  | Y2    | L    | Ignore  | Ignore     | Ignore  |
           =======================================================


Alternative 2: Reject the connection and see if valid or
   configured one appears within the
   connect timer window.

New Text: If a TCP connection is received that has an invalid format,
    or an unconfigured host [Event 14], the local system:
- rejects the TCP connection,
- and stays in the Connect state.

FSM table:
           Idle   Connect Active Open-Sent Open-Confirm Establish
Event-14   =======================================================
Nxt state Idle  |Connect|Active|Open-Sent|Open-Confirm|Establish|
     =======================================================
action       V  | L    | L     | Ignore  | Ignore     | Ignore  |
     =======================================================

3) Active State - Event 15 or Event 16 [consensus, editorial]

Previous text:
A TCP connection succeeds [Event 15 or Event 16],
the local system: process the TCP connection flags
- If the BGP delay open flag is set:
- clears the connect retry timer

   [through the following text:
- and changes its state to Open Sent.


New text:
If the TCP connection succeeds [Event 15 or Event 16],
local system checks the "Delay Open Flag" prior to
processing:   If the delay open flag is set, the local system:
- clears the connect retry timer,
- sets the BGP open delay timer to initial value, and
- stays in the Active state.

If the Delay Open flag is not set, the local system:
- clears the connect retry timer,
- clears the BGP Delay timer (sets to zero),
- completes the BGP initialization,
- sends an Open message to its peer,
- sets the hold timer to a large value, and
- changes the state to Open Sent.

4) Active State, Event 13 [no consensus]
5) Active State, Event 14 [no consensus]

  The problem with this state is it is difficult to
  exactly specify without discussing the TCP
  Messages that FSM document covers.

  I'll query if the implementors require all
  of events 13-17 as mandatory.

  We'll

6) Active State, Event 17 [no consensus]

comment:
In the Active state, we may already have a connection and be awaiting
the Open Delay timer.  The TCP disconnect or timeout could occur in
this
state due to the "Open Delay Timer".   If the TCP Disconnect is
ignored,
we could have some peer oscillation.

If the we wait, then the connection retry timer needs to be kept
running.
The text below allows this timer.  The real question is what is the
status
of the current implementations.

I agree, the Active state and the connect state should match.

Old Text:
If the TCP connection fails (timeout or disconnection) [Event 17],
the local system:
- set TCP disconnect in the MIB reason code,
- restart Connect retry timer (with initial value),
- release all BGP resources,
- Acknowledge the Drop of the TCP connection if TCP disconnect (FIN
ACK),
- Increment ConnectRetryCnt (connect retry count) by 1, and
- performs the BGP peer oscillation damping process.

Applicable FSM State table:


FSM table old:

Event 17
current:  Idle   Connect Active Open-Sent Open-Confirm Establish
           =========================================================
Next state Idle  |Active |Idle   |Active | Idle       |Idle       |
     |       |       |       |            |           |
     =========================================================
action       V  | Y2     | G     | Ignore| Track 2nd  | Track 2nd |
                 |       |       |       | connection | connection|
     =========================================================

Alternative 1:


FSM table new:

Event 17
current:  Idle   Connect Active Open-Sent Open-Confirm Establish
           =========================================================
Next state Idle  |Active |Active   |Active | Idle       |Idle       |
     |       |        |       |            |           |
     =========================================================
action       V  | G     | G      | Ignore| Track 2nd  | Track 2nd |
                 |       |        |       | connection | connection|
     =========================================================

G:  The local system:
- restarts the connect retry timer (at intial value),
- continues to listen for a connection that may be initiated
  by the remote peer, and
- sets its next state to Active.

New Text: (for Connect and Active state)
If the TCP connection fails (timeout or disconnect)
[Event 17], the local system:
- restarts the connect retry timer,
- continues to listen for a connection that may be
  initiated by the remote BGP peer, and
- changes it state to Active.


Alternative 2:
FSM table new:

Event 17
current:  Idle   Connect Active Open-Sent Open-Confirm Establish
           =========================================================
Next state Idle  |Idle   |Idle   |Active | Idle       |Idle       |
     |       |       |       |            |           |
     =========================================================
action       V  | Y2    | Y2    | Ignore| Track 2nd  | Track 2nd |
                 |       |       |       | connection | connection|
     =========================================================

Next Text:
If the location system receives a TCP connection failed [Event 17],
the local system will:
- increment the ConnectRetrycnt (connect retry count) by 1,
- release all BGP resources associated with this connection,
- perform BGP peer oscillation (if configured), and
- go to Idle

Y2 - is:
The local system:
1) increments the ConnectRetryCnt (connect retry count) by 1,
2) releases all BGP resources associated with this connection, and
3) performs the BGP peer oscillation damping process

if the damping process allows for a new connection, the local system
- restarts the connect retry timer (with initial value, and
- goes to Idle

If the damping process does not allow for a new connection, the local
system
- set the flags to damp the creation of a new bgp connection
        until a manual start occurs, and
- goes to Idle.


7) Open Confirm state, Event 18

Here's my proposed text. Please let me know what you think.
I think this is an editorial change.


Old text:  If the open message is valid, the collision detect
           function is processed per section 6.8.  If this
           connection is to be dropped due to call collision, the
local
     system:
- sends a Notification with a Cease
- resets the Connect timer (to zero),
- releases all BGP resources,
- Drop the TCP connection (sends a TCP FIN),
- increments the ConnectRetryCnt by 1 (connect retry count), and
- performs an BGP peer oscillation damping process.

New text:  If the open message is valid, the BGP peer connection
     is check to detect a collision per section 6.8.  If this
           connection is to be dropped due to call collision, the
local
     system:
- sends a Notification with a Cease
- resets the Connect timer (to zero),
- releases all BGP resources,
- Drop the TCP connection (sends a TCP FIN),
- increments the ConnectRetryCnt by 1 (connect retry count), and
- **[optionally] performs an BGP peer oscillation damping processing,
and
- enters the Idle State.

notes: Collision detect impacts Open Sent, Open Confirm, and
Established states.

Applicable FSM state


>>       Open Confirm State:
>>
>>         If the Open messages is valid [Event 18], the collision
>>         detect function is processed per section 6.8.  If this
>>         connection is to be dropped due to call collision, the
>>         local system:
>>** enters what state
>
> This instance of the FSM should be discarded since it implies there
is
> another FSM instance running that will proceed to Established?


-----Original Message-----
From: Tom Petch [mailto:[e-mail]]
Sent: Monday, December 02, 2002 11:07 AM
To: Jeffrey Haas
Cc: idr
Subject: Re: bgp18 WG Last Call fsm missing next state


Jeff

I appreciate your comments, agreeing with many.

A minor supplementary; Open Confirm, valid open [event 18], decide to
drop this connection and so the FSM but what about the actions of
incrementing the ConnectRetryCnt (and optional peer oscillation
damping)?  Are we doing that in the other FSM?  on a per router id or
per IP address pair independent of FSM?

And a slightly bigger issue in the Active state (which is the passive
state because we have entered it from Idle with Passive TCP flag set
Events 4/5).  In which case, TCP Indication valid [event 13] or
invalid [event 14] are what I would expect with event 14 keeping us in
Active state; and if event 13 also keeps us in Active state (while
sending a TCP SYN-ACK) then TCP Connection Confirmed [event 16] will
ensue while TCP Connection Acknowledged [event 15] would be an FSM
error.

Except that you suggest that event 14 in the Connect state takes us to
Active state which seems fine but for the fact that we will have sent
a TCP SYN (because that is what the Connect state is), this invalid
Indication may be a coincidence, in which case our SYN is about to
receive a SYN-ACK back ie event 15 is valid after all.  And I am then
in agreement with you over events 15/16 in the Active (ie passive)
state (delay open flag keeps us in the Active state).

Tom Petch
[e-mail]

-----Original Message-----
From: Jeffrey Haas <[e-mail]>
To: Tom Petch <[e-mail]>
Cc: idr <[e-mail]>
Date: 30 November 2002 01:33
Subject: Re: bgp18 WG Last Call fsm missing next state


>Tom,
>
>On Thu, Nov 28, 2002 at 02:53:56PM -0000, Tom Petch wrote:
>> In seven places in the FSM, the actions listed for the occurrence
of
>> an event do not include any indication of what the next state
should
>> be, nor can I be sure I can guess what it should be.
>>
>> I believe the FSM should specify the new state in the cases listed
>> below.
>>
Change 1:

>>       Connect State:
>>
>>         If the TCP connection succeeds [Event 15 or
>>         Event 16], the local system checks the "Delay Open
>>         Flag".  If the delay Open flag is set, the local system:
>> **enters what state
>
>Remains in the connect state awaiting either an open message or
>for the opendelay timer to expire.
Agreed

Change 2:
>
>>         If the TCP connection receives an indication
>>         that is invalid or unconfigured. [Event 14]:
>> **enters what state
>
>Enters the active state.
>Connectretrytimer should be started.
Agreed

Change 3:
>>       Active State:
>>
>>         A TCP connection succeeds [Event 15 or Event 16], the
>>         local system: process the TCP connection flags
>>          - If the BGP delay open flag is set:
>> ** enters what state (I think this is an FSM error in TCP because
it
>> has not initiated a connection!)
>In the active state, we are awaiting incoming tcp connections to be
>completed.  Here we should:
>
>remain in the active state
>wait for an open message or the opendelay timer to expire.
>
Change 4:

>>         If the local system receives a valid TCP Indication
>>         [Event 13], the local system processes the TCP connection
>> flags.
>> ** enters what state
>
>I'm also confused by this event.  Since we are not initiating a TCP
>connection, but are awaiting one to complete, why would we get an
>Indication here?  FSM error?

We would get an indication from the remote side that it had
send us a TCP Syn.  The real question is

Change 5:

>>         If the local system receives a TCP indication
>>         that is invalid for this connection [Event 14]:
>> ** enters what state
>
>Ditto.

Change 6:
>>
>>         If the local system receives a TCP connection
>>         failed [Event 17] (timeout or receives connection
>>         disconnect), the local system will:
>> ** enters what state
>
>Ditto.

Change 7:
>>       Open Confirm State:
>>
>>         If the Open messages is valid [Event 18], the collision
>>         detect function is processed per section 6.8.  If this
>>         connection is to be dropped due to call collision, the
>>         local system:
>> ** enters what state
>
>This instance of the FSM should be discarded since it implies there
is
>another FSM instance running that will proceed to Established?
>
>> Tom Petch
>> [e-mail]
>
>--
>Jeff Haas
>NextHop Technologies





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA23172 for <[e-mail]>; Thu, 5 Dec 2002 16:27:48 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8B7FD912D4; Thu,  5 Dec 2002 16:27:20 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 54C4A912D5; Thu,  5 Dec 2002 16:27:20 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9AD18912D4 for <[e-mail]>; Thu,  5 Dec 2002 16:27:18 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 7E27D5DF40; Thu,  5 Dec 2002 16:27:18 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id B6AE95DF3F for <[e-mail]>; Thu,  5 Dec 2002 16:27:17 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gB5LRGg66961 for [e-mail]; Thu, 5 Dec 2002 16:27:16 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gB5LR7C66941 for <[e-mail]>; Thu, 5 Dec 2002 16:27:07 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
Subject: Comments 11-20
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Thu, 5 Dec 2002 16:27:07 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments 11-20
Thread-Index: AcKcpRAd4EMRRevxTaq5YxZSayJvCg==
From: "Susan Hares" <[e-mail]>
To: "Yakov Rekhter" <[e-mail]>, "Jeffrey Haas" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id QAA23172

Siva

Again, thanks for all the comments.
Here's the summary of 11-20

comment:

11 - no consensus, no text supplied  
	
    note: usage varies from my understanding
	    of common usage.

12 - consensus, no text supplied 
     see comment 9 and proposed text below.

13a - no consensus, see alternate text 
13b - no consensus, implementation specific detail

14 - no consensus, disagree with comment
	policy issues, outside scope of document
	
15 - no consensus, see alternative text.
16 - no consensus, see my proposed text.  

	You did not propose text 
      See alternate text for events 13-17
	Also note, that I consider that
	events 13 and 14 should go to 
	optional.

17 - consensus, agree to change in text. 
18 - agree needs to be fixed, see my alternative text.
19 - further clarity needed,
	 please respond to question

20 - agree, text will be changed

So, review the comments and let me know.

Comments 21-30 in the next message.  Thanks for
working so hard on the comments. 

Sue 
 
=====================

11) Event 10 (Hold timer)

  We use the hold timer for two purposes

  * Waiting for an open message (with a default value of 240 seconds)
  * Waiting for Keepalives (with a default value of 90 seconds)

  Can we use two different timers (or at least call them two different
  timer events) ?

Siva: I do not believe that most implementatios
      utilize two timers.  Can you indicate implementations
	that do? 

=======================================================================
12) Event 12

> Event12: DelayBGP Open timer expires [changed]
> 
>	   Definition: A timer that delays sending of the BGP
>	               Open message for n seconds after the
>                       Transport connection has been completed.=

>The Definition seems to better define what the timer is, rather than =
> what
> its expiry means. Can we change it to reflect this ?

new text:  see comment on 9 on Timer definition,
	     and earlier change.

Event 12: An event generated when the Delay BGP Open timer expires.
=========================================

13) Event 13, 14 definition

> Event13: Transport Connection Indication & valid remote peer[changed]
>
>	   Definition: Event indicating that TCP connection
>                       request with a valid source IP address and TCP
>                       port, and valid destination IP address
>                       and TCP Port.  The definition of
>                       invalid Source, and invalid Destination=
>                       IP address is left to the implementation.


a) How about changing this slighty to:
%	   Definition: Event indicating receiving a TCP connection
%                       request with a valid source IP address and TCP
%                       port, and valid destination IP address=
%                       and TCP Port.  The definition of invalid
My completion of  your sentence: 
			 	source, and invalid destination IP address
				is left to the implementation. 

How about:
	Definition: Event indicating the reception of a TCP connection
			request with a valid source IP address and TCP 
			port, and valid destination IP address and
			TCP Port.  The definition of invalid source address
			and port and invalid destination address
			is left to the implementation. 


Please comment if you agree with this change. 

b) Is it correct that Destination IP address validation is used when we
do not wish to accept BGP connections on one of the local IP addresses
(either because we wish to accept such addresses on only our loopback
interfaces, or because the address to which we received the connection
was not the optimal interface with which to speak to the sender) ? If
so, can we add this to the description ?


No, this is an implementation dependent change. 
=================================================================================

14) Event 13,14

> Event13: Transport Connection Indication & valid remote peer[changed]
>
>	   Definition: Event indicating that transport
>                       Request valid source IP address and TCP=20
>                       port, and valid destination IP address=20
>                       and TCP Port.  The definition of=20
>                       invalid Source, and invalid Destination=20
>                       IP address is left to the implementation.
> 
> a) I am unclear as to what validation of source and destination port =
> mean.
> 
> The source port's value should be of no concern to connection =
> receipient system.

	The definition of "valid" is an implementation policy issue. 
	Validating is the process of checking to make sure it is valid
	for the implementation's policy.  

> The destination port cannot be invalid, since BGP would not receive the
> connection request in such a situation.

	Again, this is a policy issue.  We are providing hooks for
	policy to be engaged.  Policy is outside the scope of this
	document. 

> b) I think it will be useful to state what we consider to be an invalid
> IP address.

	Again, it is policy issue which is implementation dependent. 

====================
15) Event 17

> Event17: TCP connection fails

> This event can occur even when the transport connection is closed by
> the other end. Since this does not reflect a 'failure ', can we change
> the event name to
> 
> % Event17: TCP connection termination

Discussion:  It both terminates from the remote site
		 and can "timeout" - fail. 

Suggestions? I can use "disconnect", what do you think. 


==========================

16) Events related to BGP Messages

Can we make the definition style across these events consistent ?

thanks for the comment.
proposed text below, please agree on it.

proposed text replacement
------------------------
    Event13: TCP connection indication and valid remote peer
   
           Definition: Event indicating the local system reception of 
		       a TCP connection request with a valid source
                       IP address and TCP port, and valid destination
                       IP address and TCP Port. The definition of
                       invalid source, and invalid destination 
                       IP address is left to the implementation.

                       BGP's destination port SHOULD be port 
                       179 as defined by IANA.
   
                       TCP connection request is denoted by
                       the local system receiving a TCP SYN.
   
           Status:     Mandatory (Optional) 
 
   
    Event14: RCV TCP connection indication with invalid source or 
             destination
   
           Definition: Event indicating the local system reception of
		       a TCP connection request with either 
                       an invalid source address or port
                       number or an invalid destination 
                       address or port number. 

                       BGP destination port  number SHOULD be 179
                       as defined by IANA.
  
                       Again, a TCP connection request 
                       denoted by local system receiving a TCP
                       SYN.
   
           Status:     Mandatory (Optional) 
   	
    Event15: TCP connection request sent received an ACK.
   
           Definition: Event indicating the Local system's request
                       to establish a TCP connection to the remote
                       peer. 
   
                       The local system's TCP session sent a TCP
                       SYN, and received a TCP SYN, ACK pair of
                       messages, and Sent a TCP ACK.
   
           Status:     Mandatory
   
    Event16: TCP connection confirmed
   
           Definition: Event indicates that the local system receiving
		       a confirmation that the TCP connection has 
                       been established by the remote site. 
   
                       The remote peer's TCP engine sent a TCP SYN.
                       The local peer's TCP engine sent a SYN, ACK
                       pair, and now has received a final ACK.
   
           Status:     Mandatory
   
    Event17: TCP connection fails 
   
           Definition: Event indicates that the local system has
                       received a TCP connection failure notice.
   
                       The remote BGP peer's TCP machine could have
                       sent a FIN.  The local peer would respond
                       with a FIN-ACK. Another alternative is that
                       the local peer indicated a timeout in the
                       TCP session and downed the connection.
   
           Status:     Mandatory

---------------------


17) Event 19 Definition

> Event19: BGPOpen with BGP Delay Open Timer running [changed]
>
>           Definition: An event indicating that a valid Open=20
>                       Message has been successful=20
>                       established for a peer that is=20
>                       currently delaying the sending of an=20
>                       BGP Open message.=20


The definition appears a little fragmented. How about:

% Definition: An event indicating that a valid OPEN
%             Message has been received for a peer
%             that has a successfully established
%             transport connection and is currently
%             delaying the seending of a BGP open
%             message


agreed, changed in text.  I will send out definition
text for review in a separate message. 
==============================================================
18) Event 22 Definition

a)=20

> Event22: Open collision discard
>
>           Definition: An event generated administratively=20
>                       when a connection Collision has been=20
>                       detected while processing an incoming =20
>                       Open message. This connection has been=20

Isn't this event 'automatically' generated, since it is a system
generated event ?=20

response: How this generated is implementation specific.  The
          "administratively" is to cover policy.  

b)

>                       Event 22 is an administrative could=20
>                       occur if FSM is implemented as two=20
>

The word event is missing. How about

%                       Event 22 is an automatic event that
%                       could occur if FSM is implemented as two=20


I've re-written the whole definition.  What do you think about:

   Event22: Open collision dump
   
           Definition: An event generated administratively
                       when a connection collision has been 
                       detected while processing an incoming  
                       OPEN message and this connection has been 
                       selected to disconnected. See Section 
                       6.8 for more information on collision
                       detection.  
   
                       Event22 is an administrative based only
		           implementation specific policy. This 
		           Event may occur if the FSM is implemented
		           as two linked state machines.  
   
Please confirm that you like this. 

====================================
19) FSM Description: ConnectRetry Count

> The Connect Retry count is updated by the FSM but never used. In the
> absence of peer oscillation damping, will this be used to stop
> connection establishment attempts after a certain maximum number ?

	Yes, this is either implementation specific or
	is it based on the peer oscillation damping draft. 

> Can we include the use of this counter in some place ?

	Connect retry counter 
		1) Will be utilized by the peer oscillation damping drat.
		2) Will be included in bgp-4-mibv2-xx.  
			I just check and I didn't find it.

Do you still want text in the main 

====================================

20) Handling Event 7 (Auto Stop) to Idle State processing:

The handling of Event 7 is missing from the Idle State processing. Can
we add this ? How about replacing

> An manual stop event (Event2) is ignored in the Idle state.

with

% Manual stop (Event 2) and Auto stop (Event 7) events are ignored
% in the Idle state

Good catch, we'll add that in the text.  Sorry it got dropped
on the last revision.

Agreed

==============================



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA22812 for <[e-mail]>; Thu, 5 Dec 2002 16:21:35 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E29EB912C6; Thu,  5 Dec 2002 16:21:13 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9CBC912D4; Thu,  5 Dec 2002 16:21:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 68243912C6 for <[e-mail]>; Thu,  5 Dec 2002 16:21:11 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 537F25DF13; Thu,  5 Dec 2002 16:21:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id D8B335DEF6 for <[e-mail]>; Thu,  5 Dec 2002 16:21:10 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gB5LL9J66628 for [e-mail]; Thu, 5 Dec 2002 16:21:09 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gB5LL0C66608 for <[e-mail]>; Thu, 5 Dec 2002 16:21:00 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: 
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Thu, 5 Dec 2002 16:21:00 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Index: AcKcpDUtR520mUFcRNeIjnoraPoqqA==
From: "Susan Hares" <[e-mail]>
To: "Yakov Rekhter" <[e-mail]>, "Jeffrey Haas" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id QAA22812

Siva: 

This is my response to your comments
21-30.  Thanks again for all the comments.
Your review, Tom Petches, and Jeff's
may help tighten the text.

Please review my response. Let's
see what we can get further consensus on.

thanks for your hard work,


Sue
===================

Summary: 

21 - no consensus, see questions

22 - no consensus, 
	suggest folding this comment into
	discussion on events 13-17 on list

23 - no consensus, no text 
24 - no consensus, alternative text suggested
25 - move to own mail thread 
26 - move to mail thread on events 13-17
27 - move to mail thread on events 13-17

28 - no consensus, but close

	good catch on the 4 minutes,
	Please choose one of the alternative
	texts. 

29 -no consensus, see my alternative text
30 -no consensus
	
	mail list indicated no routes in
	active state.




===============================

21) Clearing of Connection Retry Timer:

There are a few sections where the FSM draft states that the Connection
Retry timer needs to be reset, wheras the conenct retry timer had been
cleared prior to entering that state. We can remove these instructions
to clear the connect retry timer.

List of places where the connect retry timer need not be cleared

    a) Handling of Event 19 in the Connect State
    b) Handling of Events 12 in the Active State
    c) All cases where it is refered to in the OpenSent,
       OpenConfirm and Established states

Comment:
	1) Does it hurt to have the connect retry timer cleared
	   at these points, since it has already been cleared. 
	
	I felt it eased the implementations to allow the action
	routines to be shared across as many states as possible.
	You can see this a bit more actively. 

====================
22) Handling of Event 14 in the Connect state

>  If the transport connection receives an indication
>  that is invalid or unconfigured. [Event 14]:
>     - the TCP connection is rejected.
>
> I don't understand how we would get this event while in this state.

See my earlier comments (1-10) on the connection state.
It happens in implementations which track the TCP state more
closely.  I suggest that Event 14 become optional. 


===============================================================
23) Handling events 20, 21 in the Connect State and Active State

We need to consider the case where we receive events 20 (message
header error) and 21 (Open message error) when the delay timer is 
running.

Since the connection has been established at this point, we need to 
send a Notification message and then terminate the connection.

Alternative comments: 

	1) We have not sent an Open statement.
	2) Why do we have to send an Notification? I see no justification
	   for it. 
	  
Suggestion: 
	Do you have implementations that send notification?  Do
	you know of others that don't. 

===========================================================

24) Handling the default events in the Connect state

The BGP Delay OpenTimers needs to be cleared if it is running.

>How about adding this:
>
> % - If the ConnectRetry Timer is running
> % -    Clear the Connect Retry timer
> % - Otherwise
> % -    Clear the BGP Delay Open Timer

response: 
	By the default you mean the text:

 In response to any other events[Events 7-8, 10-11, 18,
	20-27], the local system: 

"resets" to me implies stops and clears.  I think the
text is clear than the text above.  
------------
Is this the replacement text you imply above:
	- resets the connect retry timer (sets to zero),
	- clears the BGP Delay timer (sets to zero),
	- increments the ConnectRetryCnt (connect retry count) by 1,
	- [optionally] performs bgp peer oscillation damping, and
	- goes to Idle text:  

================================================

25) Handling Event 23 (Notify with version mismatch error) in Connect
   and OpenSent

>This is currently being handled in the default event processing =
> section.
> However, we do not need to go through the peer oscillation damping
> process in this case. Can we change the wordings to reflect this, or
> move this out of peer oscillation damping processing ?

response:

1)  There is no default event handling process in the text, you
    will need to specify the text.

2) The state table below (hares-statemt-03.txt) states shows
   the changes
  

-------------    
Event 23  
states:
current    Idle Connect Active Open-Sent Open-Cnf  Establish
	     ----------------------------------------------------
next state Idle  Idle    Idle  Idle      Idle       Idle
           -----------------------------------------------
action     V      D       D     Y        Y           T
           ==============================================

 V - Indicate FSM errors and ignore.
 D - 1) resets the connect retry timer (sets to zero),
     2) drops the TCP connection, 
     2) releases all BGP resources,
     3) increments the ConnectRetryCnt (connect retry count) by 1,
     4) [optionally] performs the bgp peer oscillation damping, and
       Goes to Idle state.

  Y  1) resets the connect retry timer (sets to zero),
     2) Drops the TCP connection,
     3) releases all BGP resources,
     4) [optionally] 

=============================

26) Handling Event 17 in The connect state

>  If the transport connection fails (timeout or transport
>  disconnect) [Event17], the local system:
>      - changes its state to Active.=20

>If the transport connection fails when the BGP Open Delay timer is
> running, should we still be going into the Active state ?

see mail thread on eventse 13-17

==========================================

27) Handling Event 17 in Active state

We should now move into Idle state. Can we add

% - Goes to Idle state

See mail thread on events 13-17, 
=====================================

28) Handling Event 19 in the Active state

>	- Set the Hold timer to a large value (4 minutes),

Since OPEN messages have been exchanged, can we change this to

%	- If the negotiated Hold time is not 0, set the Hold time to
%     - the negotiated value

The text in Active and Open Sent needs to be the same.
The text in Open Sent is:
	- sets the Hold timer according to the negotiated value
	  (see section 4.2), and 

Which text do you prefer?

=========================================

29) Handling Event 2 in Active state

>> A manual stop event[Event2], the local system:
>>	- Sends a notification with a Cease,
>>	- drops the Transport connection,=20
> 
>These two actions are possible only if a transport connection had =
> already been established. How about changing the text to
>
> % - If a transport connection had been successfully established
> % - Send a Notification with a Cease
> % - Drop the Transport Connection

How about this text:

 A manual stop event [Event 2], the local system
	- Drop the TCP connection, 
	- Release all BGP resources,
	- resets the connection retry timer [sets to zero],
	- goes to Idle.

=====================

30) Default event handling in Active State

To ensure consistencey with E2 handling, can we add

% - If any BGP Routes exist, delete the routes

Comment: Yakov and Jeff noted, there are no routes in
	   Active state.

===============




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA22680 for <[e-mail]>; Thu, 5 Dec 2002 16:18:58 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 92EF79123E; Thu,  5 Dec 2002 16:18:37 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5EB5C912C6; Thu,  5 Dec 2002 16:18:37 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DB12B9123E for <[e-mail]>; Thu,  5 Dec 2002 16:18:35 -0500 (EST)
Received: by segue.merit.edu (Postfix) id BEA065DF2D; Thu,  5 Dec 2002 16:18:35 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 1EC4D5DF13 for <[e-mail]>; Thu,  5 Dec 2002 16:18:35 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gB5LIUc66562 for [e-mail]; Thu, 5 Dec 2002 16:18:30 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gB5LIIC66534 for <[e-mail]>; Thu, 5 Dec 2002 16:18:18 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
Subject: Comments 30-36 from Siva 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Date: Thu, 5 Dec 2002 16:18:18 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments 30-36 from Siva 
Thread-Index: AcKco9S0K1ESZJE/Tz29y+s/qzoqAA==
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id QAA22680

Siva:

thanks again for all the comments.
Let's keep working until we get a few
more of these into the consensus model.

=======================
Here's the summary:

31 - no consensus, question

	issue resolved one way last Jan-March
	Clearing of Hold time included in
	Clear BGP resources. 

32 - no consensus, 
	issue resolve one way last Jan - March
	Clearing of keep alive timer included
	in Clear BGP resources

33 - no consensus, query implementations 

	Exact Open Exchange is being debated.
	What exactly occurs in implementations?

34 - consensus to pull mibs.

35 - no consensus, text approach suggested

36 - no consensus, no desire to open issue

	[author/chair hat on] 

	I tried to add new state 
	in 1Q 2002.  Don't want to go through
	another 3-4 months of debate.  If purchasers
	of boxes w/BGP mandate, we'll reconsider.
	[author/chair hat off] 

Sue Hares


===========================
31) Clearing Hold timer in OpenSent, OpenConfirm and Established State

> In all event handling where we go to Idle state, we need to clear the
> Hold Timer as well.

response: 
&Earlier comments (last January -March on mailing list), indicating that
&
&	- Clearing the BGP resources
&
&included clearing the Hold timer as well.  Do you disagree? 

===============
32) Clearing Keepalive timer in OpenConfirm and Established State

>In all event handling where we go to Idle state, we need to clear the
>Keepalive Timer as well.

response:
& Again, earlier comments (Last January - March on mail list indicated that
& clearing the BGP resources included this.  Are you suggesting that
&  we break this out from BGP resources.

[I used to have a number of these timers broken out.]

====================================

33) Handling Event 18 in the OpenSent state

>Why do we start the Keepalive timer at this stage ? Isn't it sufficient =
>to do so when we move into Established state ?

An earlier comment from Tom (and you) requested the following:

		<---Open
			[Open sent state]

	Open-->	
			[Event 18]
			
		<---Open
		<---Keepalive
			[Action from Event 18 in Open Sent]
			[Open Confirm]
	Keepalive -> [Event 25]
			
			[established]

What do implementations do?  We'll have to query implementations.


=============
34) Established State

> Some event handling in the Established state do not set the MIB Reason =
>when
> handling an event that causes an error. Can we add this ?

we have pulled out all the MIB reason codes. 


=======================

General Comments
==========================================

35) For the events whose status is optional, can we state the impact of =
not
   supporting them (in terms of any interoperability issues). I =
understand that
   most of the optional events will not have such an impact; but a =
clarification
   statement for the optional events would benefit new implementors.

Response:  Much of the support of optional parameters depends on policy.
	     I could put a short note about the optional events and
	     parameters as part of 8.1.5 or 8.2.1.3
	
	     I think it fits better in 8.1.5.

Optional: Events: 3-8, 12, 13-14[my suggestion]
			19, 22
	     
	    Timers: Idle Hold Timer
		      Open Delay Timer

Required flags for optional parameters:

		Open Delay Flag
		BGP Stop Flap 

(I'm sure I've missed a few after 24 hours of non-stop comment
 resolution).  If this is on the right track, I'll try to write
something up.

===========================

36) Is delaying the sending of an OPEN message a standrad industry =
practice ?

> Also, in the FSM, this has been handled by practically implementing a
>   sub-state each, within the CONNECT and ACTIVE states. Won't the FSM
>   look more simple if we just had a new DelayOpen state that we could
>   move into ?

[author hat on] 
ok, I tried the "new state" approach last January (2002), it went down to a
resounding defeat.  I'm not likely to try to this again.

So, yes I proposed new states.  No, it did not have consensus.
No, I do not think it advisable to re-open thie issues.

Whether we have sub-states or a new state, it will operate and function the
same. The purist may like it more, but I really don't want to re-enter
the 2-3 month debate on new states. 
[author hat off] 




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA15092 for <[e-mail]>; Thu, 5 Dec 2002 14:03:08 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 16ED7912D3; Thu,  5 Dec 2002 14:01:55 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38096912D4; Thu,  5 Dec 2002 14:01:51 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 91FB6912D3 for <[e-mail]>; Thu,  5 Dec 2002 14:01:49 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 772625DE94; Thu,  5 Dec 2002 14:01:49 -0500 (EST)
Delivered-To: [e-mail]
Received: from nemesis.systems.pipex.net (nemesis.systems.pipex.net [62.241.160.8]) by segue.merit.edu (Postfix) with ESMTP id 121DF5DE14 for <[e-mail]>; Thu,  5 Dec 2002 14:01:49 -0500 (EST)
Received: from tom3 (userar74.uk.uudial.com [62.188.136.233]) by nemesis.systems.pipex.net (Postfix) with SMTP id 87BE116007E87; Thu,  5 Dec 2002 19:01:41 +0000 (GMT)
Message-ID: <016c01c29c90$ba0971c0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Susan Hares" <[e-mail]>, "idr" <[e-mail]>
Cc: "Jeffrey Haas" <[e-mail]>
Subject: Re: bgp18 WG Last Call fsm missing keepalive
Date: Thu, 5 Dec 2002 18:55:36 -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: [e-mail]
Precedence: bulk

Sue

(I  promise I won't mention that state again)

1) yes I think the same text in both Active and Connect states is a
good resolution

2) complicated.  As the fsm text stands,  Event 19, along with a host
of others, takes us back from Open Sent  to Idle (I assume on the
grounds this is an error condition) which seems very reasonable.

But ...in quite a few places, such as Connect state events 2,
7,8,9,10,11, 17, 18, 20 thru 27, we do not stop the OpenDelay timer
when going to Idle or Active so we could then go from eg Idle with
Manual start [event 1] to Connect to Open Sent all before the
OpenDelay timer expires in which case event 19 can occur validly in
Open Sent - obscure but possible. (This is also true with Active state
and events 2, 17 and the default list at the end).

But I think this is an error, and that when exiting Connect state or
Active state as listed above, we should have an additional action to
stop the OpenDelay timer in which case event 19 in Open Sent becomes
an error condition (again).

But but but as ever, I cannot speak with authority for implementations
and so if implementations do not stop the OpenDelay timer when exiting
as above, then Event 19 is valid in Open Sent state - obscure but
possible (again).

My wish is to add the extra action, stop OpenDelay timer, for the
events listed above in Active and Connect states in the expectation
that that is what people have or should have implemented.

Tom Petch
[e-mail]

-----Original Message-----
From: Susan Hares <[e-mail]>
To: Tom Petch <[e-mail]>; idr <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>
Date: 04 December 2002 19:50
Subject: RE: bgp18 WG Last Call fsm missing keepalive


Tom:

I agree about the putative OpenDelay, but I do not feel
that represents the BGP implementations of today.  We
spent a long time Jan-Feb 2002 on adding any FSM States.


My earlier note was too brief.  Please answer questions


1) Agree, this can occur in the Active state as well as the
   Connect state.  Will you accept the earlier text below
   to be inserted both places?

Background:

The state machine for Event 19 is:

   Idle  Connect Active    Open    Open     Estb
               Sent    Confirm
   ===============================================
Event 19       |     |        |        |        |      |      |
   next state  |Idle | Open   | Open   | Open   |Idle  | Idle |
               |     | confirm| confirm| Confirm|      |      |
               ===============================================
   action    | V   |  N-2   | N-2    |  N     | E-1  |  E   |
               ===============================================

Per the State Machine.

Action v - FSM Error
Action E - FSM Error, drop connection - etc, drop routes
Action E-1 - FSM Error, drop connection (lots of
Action N-2 (text below)
Action N   (text below, without sending Open)

2) Do you think that Event 19 is possible in the Open Sent state?

Please answer this separately.

Thanks for all the wonderful review of the State machine.
I'm working my way through the comments.

Sue

-----Original Message-----
From: Tom Petch [mailto:[e-mail]]
Sent: Wednesday, December 04, 2002 1:30 PM
To: Susan Hares; idr
Cc: Jeffrey Haas
Subject: Re: bgp18 WG Last Call fsm missing keepalive


Still not quite.

This can occur in the Connect state as well as Active, when a TCP
connection completes with delay open flag set, my putative OpenDelay
state (sigh, point taken).

And we should still go to OpenConfirm state at the bottom of the
action list as is currently part of list H.

Tom Petch
[e-mail]

-----Original Message-----
From: Susan Hares <[e-mail]>
To: Tom Petch <[e-mail]>; idr <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>
Date: 04 December 2002 18:07
Subject: RE: bgp18 WG Last Call fsm missing keepalive


Tom:

Just to clarify this comment:

Event 19 = valid open with delay timer running

**Connect or Active = 1) awaiting TCP connection, or
   2) TCP connection completed and awaiting the
      TCP connection with delay timer running

Case 1:  - should not see Event 19
  In transition from Active to Open Confirm, the connection
  must have a TCP connection completed. Case 1 does not
  have this occurring, so the transition must be avoided.

Case 2: - should see Event 19

- Open, Keepalive should be sent.

Previous text: (Action H from FSM document)

If an Open is received with the BGP Delay Open timer running,
[Event 19], the local system:
- clears the connect retry timer [cleared to zero),
- completes the BGP initialization,
- stop and clears the BGP Open Delay timer,
- Sends an Open Message,
- sets the hold timer to a large value (4 minutes), and
- changes its state to an Open Confirm.

New text: [a New Action - N-2 : N + BGP keepalive sent]

If an Open is received with the BGP Delay Open Timer running
[Event 19], the local system:
- **clears the connect retry timer [cleared to zero],
- completes the BGP initialization,
- stops and clears the BGP Open Delay timer,
- **Sends an Open message,
- Sends a Keepalive message,
- If hold timer value is non-zero,
- **sets keepalive timer
- hold timer reset to negotiated value
  else if hold timer is zero,
- **resets the keepalive timer, and
- **resets the hold timer.
** and changes state to OpenConfirm

- If the value of the autonomous system field is the
  same as the local Autonomous system number, set
  the connection status to a internal connection;
  otherwise it is "external".

Please confirm that this change is OK for this comment.

Sue

-----Original Message-----
From: Tom Petch [mailto:[e-mail]]
Sent: Thursday, November 28, 2002 9:54 AM
To: idr
Subject: bgp18 WG Last Call fsm missing keepalive


When the OpenConfirm state is entered from OpenSent with the receipt
of a valid open [Event 18], then a KeepAlive message is sent and the
timer is started.

When the OpenConfirm state is entered from Active or Connect on
receipt of a valid open [Event 19], no message is sent, no timer is
started.

I believe this inconsistency is an error and should be corrected by
adding these two actions in those two places.

Tom Petch
[e-mail]







Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA08898 for <[e-mail]>; Thu, 5 Dec 2002 12:16:05 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D84FD91207; Thu,  5 Dec 2002 12:15:15 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 479729120E; Thu,  5 Dec 2002 12:15:14 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A29F791207 for <[e-mail]>; Thu,  5 Dec 2002 12:15:09 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D66185E135; Thu,  5 Dec 2002 12:15:08 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 50AAE5DEE8 for <[e-mail]>; Thu,  5 Dec 2002 12:15:07 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gB5HF5b60059 for [e-mail]; Thu, 5 Dec 2002 12:15:05 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gB5HEtC60028 for <[e-mail]>; Thu, 5 Dec 2002 12:14:55 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
Subject: Response to FSM input 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Thu, 5 Dec 2002 12:14:55 -0500
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: need your response to the attached messages
Thread-Index: AcKY3/TzEehR67FBQvykks4YJlFf/wDl3aWQ
From: "Susan Hares" <[e-mail]>
To: "Yakov Rekhter" <[e-mail]>, "Jeffrey Haas" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id MAA08898

Siva:

Thanks for the comments.  It helps to catch all
the nits in the specification.  I've sent response
to your comments 1-10 in this email.  I'll send the
rest of the replies in groups of 10. 

Here's a summary of the 

Comment 1 - no consensus
Comment 2a - out of date (No IdleHold Timer exists) 
Comment 2b - no consensus, can't remove due to OpenSent state
		 action.

Comment 3 - no text proposed, do we want all options
		specified in 8.1 (7 options) 
		Please review and comment on text 
 
Comment 4 - agree
Comment 5 - no text proposed, no consensus
Comment 6 - no consensus on the text
Comment 7 - see comment 3, no consensus
Comment 8 - question, no text 
Comment 9 - agree, I supplied text 
Comment 10 - agree to remove text in option,
		 different text for definition.


Sue Hares

==========

comment 1: 

1) removal of peer oscillation damping 

The reason we should not remove the peer oscillation damping
from the state machine:

  1) Deployed implementations support peer oscillation damping 
  2) Hooks for the additions in the FSM cannot be added later.

These hooks are optional and do not need to be implemented. 

 
2) Idle HoldTimer in draft-18

  Perhaps this is an old comment.  I don't find IdleHoldTimer
  in the messages.

3) HoldTime and HoldTimer

   The Hold Time is specified on page 13 of the draft-18 specification
   as to the value and size.  The text in OpenSent requires
   both a HoldTime and HoldTimer value.
===========
   OpenSent:
   
    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 there are no errors in the OPEN message 
    [Event 18] the local system:
        - resets the Open Delay timer to zero,
        - reset BGP Connect Timer to zero, 
        - sends a KEEPALIVE message and
        - sets a KeepAlive timer (via the text below)
        - sets the hold timer according to the negotiated value 
          (see Section 4.2), and 
        - changes its state to OpenConfirm.
   
   
    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.)
  
===================
The earlier comments on the list indicated we need to collect what
timers or Timer values were utilized in the FSM.  I believe Alex
made this comment last January.  (the list archives will have
this information.)

So, I don't see any way to

Comment 3: optional parameters specified

Please suggest text.  We have the following optional parameters:

1) Delay Open
2) Accept unconfigured peers
3) automatic start [Event 3] 
4) passive TCP establishment (optional)
	4 + 5 = Event 5
5) BGP_stop_flap (BGP Peer oscillation) [Event 6] 
6)automatic stop [Event 7] 
7)Collision detect in Established State 

If you want some of the optional parameters specified, let's
catch all.  Please suggest text and location.  It could
go in 8.1.
--------------------------------
Comment 4

Old Text: 
  Event 1: Manual Start
      Definition: Administrator manually starts peer connection.

 ... 
  Event 2: Manual Stop 
	 Definition: Local system administrator manually stops the 
		       peer connection. 
New Text: 
  Event1: Manual start
       Definition: Local system administrator manually starts the
		       bgp connection.

  ... 
  Event 2: Manual stop:
	  Definition: Local system administrator manually stops the 
			  bgp connection.

agree? 
---------------
Comment 5: 

5) Event3, Event5, Event6 and Event7

5a) 
=========
  Event 3/6/7 - cisco indicated the automatic stop, see the NANOG
		  archives for a discussion of the Bad Route

    http://www.merit.edu/mail.archives/nanog/2001-06/msg00805.html

  The "event" sequences are new with this version of the FSM
  to identify particular events by number. 
5b
======

  Can we give examples of these events, as implemneted by curent
  implementations ? This will be of help to new implementaions.

  An example of Auto Stop is already present in the Update event
  handling section, and we can move that to this place as well.

I believe that examples are outside the scope of this specification.
If you have text clarifying the event descriptions, please send it in.


=======================================================

6) Event 4,5 Definition

>	   Definition: Administrator manually start the peer
>                       Connection, but has the passive flag=20
>                       enabled.  The passive flag indicates=20
>                       that the peer will listen prior to=20
>                       establishing the connection.


>	  Definition:  Local system automatically starts the
>                       BGP session with the passive flag=20
>                       enabled.  The passive flag indicates=20
>                       that the peer will listen prior to=20
>                       establishing a connection.


>My understanding is this is used to indicate a peer configuration
>where we start the state machine, and wait for an incoming connection
>request from the configured peer. Can we re-phrase this section to
>indicate this.

>How about something like:
>
>% The passive flag indicates that the state machine will wait for
>% specified peer to initiate a connection with the local system. If
>% this does not happen within a specific time (hold time), the local
>% system will then also attempt to initiate connection with the
>% specified peer.

The text in 8.2.1.1 indicates the definition of the passive flag. 

6a) 
==========
My understanding of your text is that you want to replace in both
sets of text: 

"The passive flag indicates the peer will listen prior to 
 establishing a connection".  

with: 

"The passive flag indicates that the state machine will wait for the
specified peer to initiate a connection with a local system.

The problem with this sentence is that in the "unconfigured" case
the phrase "specified" peer is confusing.  I think the original text
is clearer. 
6b)
==========
If this does not happen within a specific time (hold time), the local
system will then also attempt to initiate (a) connection with the
specified peer.

My comments: Again, the "specified peer" term is confusing.  Also,
the 2nd half of the statement mixes the actions of the state machine
with the events.  I believe this muddies the text instead of
clarifying it. 
 
=================
Comment 7 -

Event 6 - (not specified, please confirm) 

>  Won't a variant of this with bgp_stop_flap option set be requried ?
>  We can also achieve the same by using the bgp_stop-Flap option as a
>  flag that is provided as an input to the state machine.

see comment number 3.  bgp_stop_flap is an option.  

This state machine description has many events to describe the
mixture of options and actions.  I believe it has a better clarity
than testing lots of flags within a state. 

A proof in case, is that many people are making comments about
specific transitions. 

============
Comment 8 - 


8) Event 5 Definition

>	  Definition:  Local system automatically starts the
>                       BGP session with the passive flag=20
>                       enabled.  The passive flag indicates=20
>                       that the peer will listen prior to=20
>                       establishing a connection.

> Is it correct that this event will occur only when we want to restart
> a connection (after it had been terminated due to some reason beside
> administrative action) that we had accepted from an unconfigured peer ?

The automatic start function is an implementation specific mechanism.
This text does not seek to restrict it in any fashion.

================
9) Timer Events Definition

> Event8:  idle Hold timer expires=20
>
>           Definition: Idle Hold timer expires.  The Idle=20
>
> Event9: connect retry timer expires
>
>           Definition: An event triggered by the expiration of=20
> Event10: hold time expires
>
>	   Definition: An event generated when the HoldTimer=20

We can use any one of these terms (trigerred by/generated when) for all
timer event definitions to make it look more consistent.

agree: Will use "generate" 

Event 8: An event generated when the Idle Hold timer expires.
Event 9: An event generated when the ConnectRetry timer expires.
Event 10: An event generated when the Hold timer expires.  
Event 11: An event generated when the Keepalive timer expires
Event 12: An event generated when the Delay BGP Open timer expires.

Please confirm that this change to the definitions is agreeable to
you.

================
10) Event 8 Definition

> Event8:  idle Hold timer expires=20
>
>           Definition: Idle Hold timer expires.  The Idle=20
>                       Hold Timer is only used when persistent =20
>                       BGP oscillation damping functions are=20
>                       enabled. =20
>
>           Status: 	Optional.  Used when persistent
>			BGP peer oscillation damping functions
>			are enabled.=20


The status repeats the senetnce in the definition. Can we remove the
sentence from the Status, or replace with a different definition.

Do you think the defenition below would fit ?

% An event trigerred by the expiry of the Idle Hold timer, indicating
% that the session has completed waiting for a back-off period to
% prevent flap, and may now proceed to take any further systemm
% initiated action for this session. 

text change suggestion for 1st sentence that I'll agree to.

 An event trigerred by the expiry of the Idle Hold timer, indicating
 that the session has completed waiting for a back-off period to
 prevent bgp peer oscillation.

Please confirm that you will agree to this.

=================
End of comments on 1st 10 issues.

Sue



------- Message 4

Date:    Fri, 29 Nov 2002 19:46:06 +0530
From:    "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
To:      [e-mail], Yakov Rekhter <[e-mail]>
cc:      [e-mail]
Subject: Comments on draft 18

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_000_01C297B1.DB0F1700
Content-Type: text/plain;
	charset="iso-8859-1"

Hello,

    Attached are some comments that I have on draft-ietf-idr-bgp4-18.

    Please have a look at these and tell me if the same can be raised to the
mailing list as well.

Thanks,
Siva
([e-mail])
  


- ------_=_NextPart_000_01C297B1.DB0F1700
Content-Type: text/plain;
	name="BGP_Issues.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="BGP_Issues.txt"

All quoted sections of the original document have been prefixed by a '> =
'
All lines of proposed text have been prefixed by a '% '


1) Performing of peer oscillation damping:

Since this feature is going to be added in a new draft, and its
addition will change the operation of the state machine, can we remove
all mention of it in the state machine ? As part of this removal, can
we also remove the IdleHold Timer from the FSM since it is not useful
in the absence of peer oscillation damping ?

The draft that describes this procedure can then describe the change
in the state machine required to do this.


2) Session Attributes:

> Session Attributes required for each connection are;=20

>   1) state
>   2) Connect Retry timer
>   3) Hold timer
>   4) Hold time
>   5) Keepalive timer

Why have a Hold Timer and a Hold Time ? Can we replace this with just
Hold timer ?

Can we also add the following session attributes:

a) DelayBgpOpenTimer
b) IdleHold Timer (in case we choose not to remove this from the bas =
FSM)

Can we also add the following flag to the session attributes:
a) DelayOpen Flag


3) All sessions attributes:

  There are some attributes that are common to all sessions of the =
system.
  Can we call these out as well:

  * Accept Connections from unconfigured peers (Enabled/Disabled)
  * Peer Oscillation Dampening (Enabled/Disabled) (In case we choose
    not to remove it from base spec)


4) Description for Event1/Event2

> Event1: Manual start=20
>
>	   Definition: Administrator manually starts peer
>                       connection

> Event2: Manual stop

>	   Definition: Local system administrator manually=20
>                       stops the peer connection.

We can make these look consistent by using the Term Administrator or
Local System administrator in both cases.


5) Event3, Event5, Event6 and Event7

  Can we give examples of these events, as implemneted by curent
  implementations ? This will be of help to new implementaions.

  An example of Auto Stop is already present in the Update event
  handling section, and we can move that to this place as well.


6) Event 4,5 Definition

>	   Definition: Administrator manually start the peer
>                       Connection, but has the passive flag=20
>                       enabled.  The passive flag indicates=20
>                       that the peer will listen prior to=20
>                       establishing the connection.


>	  Definition:  Local system automatically starts the
>                       BGP session with the passive flag=20
>                       enabled.  The passive flag indicates=20
>                       that the peer will listen prior to=20
>                       establishing a connection.


My understanding is this is used to indicate a peer configuration
where we start the state machine, and wait for an incoming connection
request from the configured peer. Can we re-phrase this section to
indicate this.

How about something like:

% The passive flag indicates that the state machine will wait for
% specified peer to initiate a connection with the local system. If
% this does not happen within a specific time (hold time), the local
% system will then also attempt to initiate connection with the
% specified peer.


7) Event 4,5

  Won't a variant of this with bgp_stop_flap option set be requried ?
  We can also achieve the same by using the bgp_stop-Flap option as a
  flag that is provided as an input to the state machine.


8) Event 5 Definition

>	  Definition:  Local system automatically starts the
>                       BGP session with the passive flag=20
>                       enabled.  The passive flag indicates=20
>                       that the peer will listen prior to=20
>                       establishing a connection.

Is it correct that this event will occur only when we want to restart
a connection (after it had been terminated due to some reason beside
administrative action) that we had accepted from an unconfigured peer ?


9) Timer Events Definition

> Event8:  idle Hold timer expires=20
>
>           Definition: Idle Hold timer expires.  The Idle=20
>
> Event9: connect retry timer expires
>
>           Definition: An event triggered by the expiration of=20
> Event10: hold time expires
>
>	   Definition: An event generated when the HoldTimer=20

We can use any one of these terms (trigerred by/generated when) for all
timer event definitions to make it look more consistent.



10) Event 8 Definition

> Event8:  idle Hold timer expires=20
>
>           Definition: Idle Hold timer expires.  The Idle=20
>                       Hold Timer is only used when persistent =20
>                       BGP oscillation damping functions are=20
>                       enabled. =20
>
>           Status: 	Optional.  Used when persistent
>			BGP peer oscillation damping functions
>			are enabled.=20


The status repeats the senetnce in the definition. Can we remove the
sentence from the Status, or replace with a different definition.

Do you think the defenition below would fit ?

% An event trigerred by the expiry of the Idle Hold timer, indicating
% that the session has completed waiting for a back-off period to
% prevent flap, and may now proceed to take any further systemm
% initiated action for this session.



11) Event 10 (Hold timer)

  We use the hold timer for two purposes

  * Waiting for an open message (with a default value of 240 seconds)
  * Waiting for Keepalives (with a default value of 90 seconds)

  Can we use two different timers (or at least call them two different
  timer events) ?


12) Event 12

> Event12: DelayBGP Open timer expires [changed]
>=09
>	   Definition: A timer that delays sending of the BGP
>	               Open message for n seconds after the
>                       Transport connection has been completed.=20

The Definition seems to better define what the timer is, rather than =
what
its expiry means. Can we change it to reflect this ?


13) Event 13, 14 definition

> Event13: Transport Connection Indication & valid remote peer[changed]
>
>	   Definition: Event indicating that TCP connection
>                       request with a valid source IP address and TCP=20
>                       port, and valid destination IP address=20
>                       and TCP Port.  The definition of=20
>                       invalid Source, and invalid Destination=20
>                       IP address is left to the implementation.


a) How about changing this slighty to:
%	   Definition: Event indicating receiving a TCP connection
%                       request with a valid source IP address and TCP=20
%                       port, and valid destination IP address=20
%                       and TCP Port.  The definition of=20

b) Is it correct that Destination IP address validation is used when we
do not wish to accept BGP connections on one of the local IP addresses
(either because we wish to accept such addresses on only our loopback
interfaces, or because the address to which we received the connection
was not the optimal interface with which to speak to the sender) ? If
so, can we add this to the description ?



14) Event 13,14

> Event13: Transport Connection Indication & valid remote peer[changed]
>
>	   Definition: Event indicating that transport
>                       Request valid source IP address and TCP=20
>                       port, and valid destination IP address=20
>                       and TCP Port.  The definition of=20
>                       invalid Source, and invalid Destination=20
>                       IP address is left to the implementation.

a) I am unclear as to what validation of source and destination port =
mean.

The source port's value should be of no concern to connection =
receipient
system.

The destination port cannot be invalid, since BGP would not receive the
connection request in such a situation.

b) I think it will be useful to state what we consider to be an invalid
IP address.


15) Event 17

> Event17: TCP connection fails

This event can occur even when the transport connection is closed by
the other end. Since this does not reflect a 'failure ', can we change
the event name to

% Event17: TCP connection termination


16) Events related to BGP Messages

Can we make the definition style across these events consistent ?



17) Event 19 Definition

> Event19: BGPOpen with BGP Delay Open Timer running [changed]
>
>           Definition: An event indicating that a valid Open=20
>                       Message has been successful=20
>                       established for a peer that is=20
>                       currently delaying the sending of an=20
>                       BGP Open message.=20


The definition appears a little fragmented. How about:

% Definition: An event indicating that a valid OPEN
%             Message has been received for a peer
%             that has a successfully established
%             transport connection and is currently
%             delaying the seending of a BGP open
%             message


18) Event 22 Definition

a)=20

> Event22: Open collision discard
>
>           Definition: An event generated administratively=20
>                       when a connection Collision has been=20
>                       detected while processing an incoming =20
>                       Open message. This connection has been=20

Isn't this event 'automatically' generated, since it is a system
generated event ?=20

b)

>                       Event 22 is an administrative could=20
>                       occur if FSM is implemented as two=20
>

The word event is missing. How about

%                       Event 22 is an automatic event that
%                       could occur if FSM is implemented as two=20


19) FSM Description: ConnectRetry Count

The Connect Retry count is updated by the FSM but never used. In the
absence of peer oscillation damping, will this be used to stop
connection establishment attempts after a certain maximum number ?
Can we include the use of this counter in some place ?


20) Handling Event 7 (Auto Stop) to Idle State processing:

The handling of Event 7 is missing from the Idle State processing. Can
we add this ? How about replacing

> An manual stop event (Event2) is ignored in the Idle state.

with

% Manual stop (Event 2) and Auto stop (Event 7) events are ignored
% in the Idle state


21) Clearing of Connection Retry Timer:

There are a few sections where the FSM draft states that the Connection
Retry timer needs to be reset, wheras the conenct retry timer had been
cleared prior to entering that state. We can remove these instructions
to clear the connect retry timer.

List of places where the connect retry timer need not be cleared

    a) Handling of Event 19 in the Connect State
    b) Handling of Events 12 in the Active State
    c) All cases where it is refered to in the OpenSent,
       OpenConfirm and Established states


22) Handling of Event 14 in the Connect state

>  If the transport connection receives an indication
>  that is invalid or unconfigured. [Event 14]:
>     - the TCP connection is rejected.

I don't understand how we would get this event while in this state.


23) Handling events 20, 21 in the Connect State and Active State

We need to consider the case where we receive events 20 (message
header error) and 21 (Open message error) when the delay timer is =
running.

Since the connection has been established at this point, we need to =
send a
Notification message and then terminate the connection.


24) Handling the default events in the Connect state

The BGP Delay OpenTimers needs to be cleared if it is running.

How about adding this:

% - If the ConnectRetry Timer is running
% -    Clear the Connect Retry timer
% - Otherwise
% -    Clear the BGP Delay Open Timer


25) Handling Event 23 (Notify with version mismatch error) in Connect
   and OpenSent

This is currently being handled in the default event processing =
section.
However, we do not need to go through the peer oscillation damping
process in this case. Can we change the wordings to reflect this, or
move this out of peer oscillation damping processing ?


26) Handling Event 17 in The connect state

>  If the transport connection fails (timeout or transport
>  disconnect) [Event17], the local system:
>      - changes its state to Active.=20

If the transport connection fails when the BGP Open Delay timer is
running, should we still be going into the Active state ?


27) Handling Event 17 in Active state

We should now move into Idle state. Can we add

% - Goes to Idle state


28) Handling Event 19 in the Active state

>	- Set the Hold timer to a large value (4 minutes),

Since OPEN messages have been exchanged, can we change this to

%	- If the negotiated Hold time is not 0, set the Hold time to
%     - the negotiated value


29) Handling Event 2 in the Active State

> A manual stop event[Event2], the local system:
>	- Sends a notification with a Cease,
>	- drops the Transport connection,=20

These two actions are possible only if a transport connection had =
already
been established. How about changing the text to

% - If a transport connection had been successfully established
% - Send a Notification with a Cease
% - Drop the Transport Connection


30) Default event handling in Active State

To ensure consistencey with E2 handling, can we add

% - If any BGP Routes exist, delete the routes


31) Clearing Hold timer in OpenSent, OpenConfirm and Established State

In all event handling where we go to Idle state, we need to clear the
Hold Timer as well.


32) Clearing Keepalive timer in OpenConfirm and Established State

In all event handling where we go to Idle state, we need to clear the
Keepalive Timer as well.


33) Handling Event 18 in the OpenSent state

Why do we start the Keepalive timer at this stage ? Isn't it sufficient =
to
do so when we move into Established state ?


34) Established State

Some event handling in the Established state do not set the MIB Reason =
when
handling an event that causes an error. Can we add this ?



General Comments

35) For the events whose status is optional, can we state the impact of =
not
   supporting them (in terms of any interoperability issues). I =
understand that
   most of the optional events will not have such an impact; but a =
clarification
   statement for the optional events would benefit new implementors.

36) Is delaying the sending of an OPEN message a standrad industry =
practice ?

   Also, in the FSM, this has been handled by practically implementing =
a
   sub-state each, within the CONNECT and ACTIVE states. Won't the FSM
   look more simple if we just had a new DelayOpen state that we could
   move into ?


- ------_=_NextPart_000_01C297B1.DB0F1700--

--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA28570 for <[e-mail]>; Thu, 5 Dec 2002 09:20:26 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5E907912CC; Thu,  5 Dec 2002 09:20:01 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25D43912CD; Thu,  5 Dec 2002 09:20:01 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C15C5912CC for <[e-mail]>; Thu,  5 Dec 2002 09:19:59 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A65515DF2E; Thu,  5 Dec 2002 09:19:59 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 078425DF16 for <[e-mail]>; Thu,  5 Dec 2002 09:19:59 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12304; Thu, 5 Dec 2002 09:17:07 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-aspath-orf-04.txt
Date: Thu, 05 Dec 2002 09:17:05 -0500
Sender: [e-mail]
Precedence: bulk

--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		: Aspath Based Outbound Route Filter for BGP-4
	Author(s)	: K. Patel, S. Hares
	Filename	: draft-ietf-idr-aspath-orf-04.txt
	Pages		: 0
	Date		: 2002-12-4
	
This document defines a new Outbound Router Filter type for BGP,
termed 'Aspath Outbound Route Filter', that can be used to perform 
aspath based route filtering. This ORF-type supports aspath based 
route filtering as well as regular expression based matching, for 
address groups.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-aspath-orf-04.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-aspath-orf-04.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-aspath-orf-04.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-aspath-orf-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-aspath-orf-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA18645 for <[e-mail]>; Wed, 4 Dec 2002 21:25:15 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1A0CE912C3; Wed,  4 Dec 2002 21:24:49 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF9A7912C4; Wed,  4 Dec 2002 21:24:48 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5644E912C3 for <[e-mail]>; Wed,  4 Dec 2002 21:24:47 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 338ED5DEB1; Wed,  4 Dec 2002 21:24:47 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 867815DE99 for <[e-mail]>; Wed,  4 Dec 2002 21:24:46 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gB52Oj244159 for [e-mail]; Wed, 4 Dec 2002 21:24:45 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gB52OdC44145 for <[e-mail]>; Wed, 4 Dec 2002 21:24:39 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
Subject:  fsm missing next state - Event 14 in Connect state : Implementers - review needed
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Wed, 4 Dec 2002 21:24:39 -0500
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic:  fsm missing next state - Event 14 in Connect state : Implementers - review needed
Thread-Index: AcKcBXY6q+Y3GYOeRhOVBwM78XFN4Q==
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Jeffrey Haas" <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id VAA18645

Calling all implementers, please comment on this proposed
change.



Connect State - Event 14  [no consensus] 

Current Text:
	If the TCP connection receives an indication that
	that is invalid or unconfigured [Event 14], 
	- the TCP connection is rejected.

At the very least this section needs more "word smithing",
so I'd like to change it for more clarity at least.

I'm not sure this represents the implementations.
What I'd like to do is query the implementations
to see what they do if they receive a valid TCP
connection with an invalid or unconfigured peer.

Two options:

Alternative 1: Count it as a valid response

 New Text: If a TCP connection is received that has
	     an invalid format, or an unconfigured host [Event 14],
	     the local system:
		- rejects the TCP connection,
		- increments the connect retry counter,
		- performs bgp peer oscillation checks.
	
		If bgp peer oscillation checks allow for a new
		connection, the bgp peer
		- restarts the Connect retry timer with configured 
		  value, and
		- enters the Active state. 

FSM table:
           Idle   Connect Active Open-Sent Open-Confirm Establish
Event-14   =======================================================
 Nxt state Idle  | Active|Active|Open-Sent|Open-Confirm|Establish|  
	     =======================================================
 action       V  | Y2    | L    | Ignore  | Ignore     | Ignore  |
           =======================================================


Alternative 2: Reject the connection and see if valid or
		   configured one appears within the 
		   connect timer window. 

New Text: If a TCP connection is received that has an invalid format,
	    or an unconfigured host [Event 14], the local system:
		- rejects the TCP connection,
		- and stays in the Connect state. 

FSM table:
           Idle   Connect Active Open-Sent Open-Confirm Establish
Event-14   =======================================================
 Nxt state Idle  |Connect|Active|Open-Sent|Open-Confirm|Establish|  
	     =======================================================
 action       V  | L    | L     | Ignore  | Ignore     | Ignore  |
	     =======================================================



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA18284 for <[e-mail]>; Wed, 4 Dec 2002 21:19:04 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 40EBF912C2; Wed,  4 Dec 2002 21:18:46 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1205F912C3; Wed,  4 Dec 2002 21:18:45 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A5C2912C2 for <[e-mail]>; Wed,  4 Dec 2002 21:18:44 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 52A1A5E100; Wed,  4 Dec 2002 21:18:44 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 9B9685E0FB for <[e-mail]>; Wed,  4 Dec 2002 21:18:43 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gB52IgE44042 for [e-mail]; Wed, 4 Dec 2002 21:18:42 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gB52IUC44007 for <[e-mail]>; Wed, 4 Dec 2002 21:18:30 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
Subject:  fsm missing next state - Events 13 - 17 and the TCP connection   
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Wed, 4 Dec 2002 21:18:30 -0500
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic:  fsm missing next state - Events 13 - 17 and the TCP connection   
Thread-Index: AcKcBJocOcelZzGqSwmzlHSQ0QCkoA==
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Jeffrey Haas" <[e-mail]>, <[e-mail]>, <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id VAA18284

Implementers of the BGP FSM we need your help! 
Tom Petch has raised a concern about events 13-17
on the mail list in thread:

	RE: bgp18 WG Last Call fsm missing next state

I welcome any comments public (or to me or Yakov privately)
on this topic.  I will utilize private comments to answer
some of the questions below. 

============================

These events are described in section 8.1.3.

In our discussion in January through May of 2002, many
implementers mapped their implementation onto the
following TCP events  list in 8.1.3. 


Events 13 - 17 

	Event 13 - TCP connection indication & valid
		   remote peer

	Event 14 - TCP connection indication with invalid
		   source or destination
	
	Event 15 - TCP connection request sent (by this
		   peer) received an Acknowledgement
		
		[ local system sent a TCP SYN, Received a
		  TCP SYN, ACK pair back, and Sent a TCP ACK]

	Event 16 - TCP connection confirmed 

		[local system received a TCP SYN, sent
		 a TCP SYN, ACK back, and received a TCP ACK]

	Event 17 - TCP connections

Should we have all of these states?  Which implementations
support all of these Events?   

The FSM State machine for this group is

           Idle   Connect Active Open-Sent Open-Confirm Establish
Event-13:  [TCP connection request from valid remote peer] 
           =======================================================
 Nxt state Idle  |Connect|Active|Open-Sent|Open-Confirm|Establish |  
	     ========================================================
 action       V  | *1    | *2   |Track 2nd | Track 2nd  | Track 2nd |
                 |       |      |connection| connection | connection
	     =========================================================
  V - Process FSM Error.

 * 1 We sent TCP SYN.  Is this TCP connection in response or 
     a new connection to port 179?  

     The FSM state machine in the hares-bgp4-statemt-02 draft
     uses this event to track the TCP connection messages.
     The sub-state machine uses flags
	 1) Await TCP SYN
	 2) Sent TCP SYN
	 3) Await TCP ACK 
       4) Null - no flags

     These state is being used to track the TCP connection state.  

    recommendation: Make this Event optional.
    Open questions: 
     Do we believe the Two TCP SYN cross for the same
     connection?  Does this TCP related portion of the state
     machine handle this? 

 * 2 - local system received a TCP SYN from the remote port. All the same
       comments from *1 apply. 


Event 14  TCP REQ request received from an invalid peer
	     =======================================================
Current            Idle   Connect Active Open-Sent Open-Confirm Establish
           =======================================================
 Nxt state Idle  |Connect|Active|Open-Sent|Open-Confirm|Establish|  
	     =======================================================
 action       V  | L    | L     | Ignore  | Ignore     | Ignore  |
	     =======================================================



Event 15    - TCP connection request sent received an ACK
                      =======================================================
Current            Idle   Connect Active Open-Sent Open-Confirm Establish
           =======================================================
Next state Idle  |Connect|Active  |Open-Sent|Open-Confirm|Establish|  
	           |or Open|or Open |         |            |         |
                 | Sent  | Sent   |         |            |         |
	     =========================================================
 action       V  | *3    | *4     | Ignore  | Ignore     | Ignore  |
	     =========================================================

  *3/*4 - The actions taken in *3/*4 differ only in the next state
	    if the Delay Open flag is set.  

     - If Delay Open flag is set, the local system will:
		do (ZZ): - Clear the connection retry timer, and 
			   - Set Open Delay timer to initial value, and
			   - [*3]stay in the Connect state 
			     [*4]stay in the Active state 
			      
    	 - If Delay Open flag is not set, the local system will:
		do (H)
			- clears the connect retry timer,
			- completes the BGP initialization,
			- clears the Open Delay timer (sets to zero), 
			- send an Open message to its peer,
			- sets hold timer to a large value, and
			- change the state to Open Sent.
  

Event 16   - TCP connection confirmed (Received TCP Req, Sent TCP SYN, ACK),
Current            Idle   Connect Active Open-Sent Open-Confirm Establish
           =========================================================
Next state Idle  |Connect|Active  |Open-Sent|Open-Confirm|Establish|  
	           |or Open|or Open |         |            |         |
                 | Sent  | Sent   |         |            |         |
	     =========================================================
 action       V  | *3    | *4     | Ignore  | Ignore     | Ignore  |
		========================================================


Event 17  - TCP Connection Fails 
           ======================================================== 
 Current   Idle   Connect Active Open-Sent Open-Confirm Establish
           =========================================================
 Nxt state Idle  |Active |Idle    |Active | Idle       |Idle       |  
	     =========================================================
 action       V  | G     | Y2     | Ignore| Track 2nd  | Track 2nd |
                 |       |        |       | connection | connection|
	     =========================================================

    G: the local system will:
		- restart the connect retry timer (with initial value),
		- continue to listen for a connection that may be initiated
		  by remote peer, and
		- change its state to active. 

	Y2 - is:
	The local system: 
		1) increments the ConnectRetryCnt (connect retry count) by 1,
		2) Releases all BGP resources associated with this connection, and
		3) performs the BGP peer oscillation damping process.

	If the damping process allows for a new connection, the local system
		- restarts the connect retry timer (with initial value), and 
		- goes to Idle

	If the damping process does not allow for a new connection, the local
	system
		- releases the BGP resources, and goes to 
		- Idle.


	Please note: the proposal for event 17, has Connect and Active doing the same thing.
		       Please comment on how your state machine works.

 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA18229 for <[e-mail]>; Wed, 4 Dec 2002 21:18:23 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DDFA291205; Wed,  4 Dec 2002 21:18:03 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A5868912C2; Wed,  4 Dec 2002 21:18:03 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D77991205 for <[e-mail]>; Wed,  4 Dec 2002 21:17:54 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 283C95E103; Wed,  4 Dec 2002 21:17:54 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 9A3C45E102 for <[e-mail]>; Wed,  4 Dec 2002 21:17:53 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gB52Hq343955 for [e-mail]; Wed, 4 Dec 2002 21:17:52 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gB52HkC43942 for <[e-mail]>; Wed, 4 Dec 2002 21:17:46 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
Subject: RE: bgp18 WG Last Call fsm missing next state
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Wed, 4 Dec 2002 21:17:46 -0500
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: bgp18 WG Last Call fsm missing next state
Thread-Index: AcKaHxSLTG7nC0wCT3C+gannXhGWHwBtZ4Kg
From: "Susan Hares" <[e-mail]>
To: "Tom Petch" <[e-mail]>, "Jeffrey Haas" <[e-mail]>
Cc: "idr" <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id VAA18229

Tom and Jeff:

Thanks for the great review of the state machine. 
Please confirm I've got my 7 changes numbered right.

Here's where we have consensus:
	change 1 - consensus, editorial
		state: Connect
		Events: 15 and 16

	change 2 - no consensus
		 I've given two alternatives.
		 We need to get implementers to pick 1.
		 thread: 
		State: Connect
		Event: 14

	change 3 - consensus, editorial
		state: Active:
		Events: 15 and 16

	change 4 and 5:
		State: Active
		Events: 13 and 14

	On changes 4 and 5 - moved to a different thread
	thread titled:  fsm missing next state - Events 13 - 17 and the TCP connection   

	on change 6 - no consensus
		State: Active
		Event: 17
	
		Review my explanation and the new text, and
		see if we have consensus.

	on change 7: no consensus.
		State: Open Confirm
		Event: 18

		Review my explanation and see if we have
	      consensus.

Sue Hares
([e-mail]) 
=============


Warning - put the screen on wide mode for the following text: 

-------------------


Here's my response on the 7 changes

1) Connect State - Event 15 or Event 16 [consensus, editorial]

note:  The delay retry timer is utilized instead of the
	 connect retry timer for the next two changes. 

Previous text:
 If the TCP connection succeeds [Event 15 or Event 16], 
 local system checks the "Delay Open Flag".  If the delay
 open flag is set, the local system:
	- clears the connect retry timer,
	- sets the BGP open delay timer to initial value

   If the Delay Open flag is not set, the local system:
	- clears the connect retry timer,
	- clear BGP Open Delay timer (set to zero), 
	- completes the BGP initialization,
	- send an Open message to its peer,
	- sets hold timer to a large value, and
	- change the state to Open Sent.


New text: 
 If the TCP connection succeeds [Event 15 or Event 16], 
 local system checks the Delay Open flag prior to
 processing:   If the Delay Open flag is set, the local system:
	- clears the connect retry timer,
	- sets the BGP open delay timer to initial value, and
	- stays in the Connect state.

 If the Delay Open flag is not set, the local system:
	- clears the connect retry timer,
	- clears the BGP Delay timer (sets to zero), 
	- completes the BGP initialization,
	- sends an Open message to its peer,
	- sets the hold timer to a large value, and
	- changes the state to Open Sent. 

2)Connect State - Event 14  [no consensus] 

Current Text:
	If the TCP connection receives an indication that
	that is invalid or unconfigured [Event 14], 
	- the TCP connection is rejected.

At the very least this section needs more "word smithing",
so I'd like to change it for more clarity at least.

I'm not sure this represents the implementations.
What I'd like to do is query the implementations
to see what they do if they receive a valid TCP
connection with an invalid or unconfigured peer.

Two options:

Alternative 1: Count it as a valid response

 New Text: If a TCP connection is received that has
	     an invalid format, or an unconfigured host [Event 14],
	     the local system:
		- rejects the TCP connection,
		- increments the connect retry counter,
		- performs bgp peer oscillation checks.
	
		If bgp peer oscillation checks allow for a new
		connection, the bgp peer
		- restarts the Connect retry timer with configured 
		  value, and
		- enters the Active state. 

FSM table:
           Idle   Connect Active Open-Sent Open-Confirm Establish
Event-14   =======================================================
Next state Idle  | Active|Active|Open-Sent|Open-Confirm|Establish|  
	     =======================================================
 action       V  | Y2    | L    | Ignore  | Ignore     | Ignore  |
           =======================================================


Alternative 2: Reject the connection and see if valid or
		   configured one appears within the 
		   connect timer window. 

New Text: If a TCP connection is received that has an invalid format,
	    or an unconfigured host [Event 14], the local system:
		- rejects the TCP connection,
		- and stays in the Connect state. 

FSM table:
           Idle   Connect Active Open-Sent Open-Confirm Establish
Event-14   =======================================================
 Nxt state Idle  |Connect|Active|Open-Sent|Open-Confirm|Establish|  
	     =======================================================
 action       V  | L    | L     | Ignore  | Ignore     | Ignore  |
	     =======================================================
  
3) Active State - Event 15 or Event 16 [consensus, editorial]

Previous text: 
 A TCP connection succeeds [Event 15 or Event 16], 
 the local system: process the TCP connection flags 
 - If the BGP delay open flag is set:
	- clears the connect retry timer

   [through the following text:
 - and changes its state to Open Sent.


New text: 
 If the TCP connection succeeds [Event 15 or Event 16], 
 local system checks the "Delay Open Flag" prior to
 processing:   If the delay open flag is set, the local system:
	- clears the connect retry timer,
	- sets the BGP open delay timer to initial value, and
	- stays in the Active state.

 If the Delay Open flag is not set, the local system:
	- clears the connect retry timer,
	- clears the BGP Delay timer (sets to zero),  
	- completes the BGP initialization,
	- sends an Open message to its peer,
	- sets the hold timer to a large value, and
	- changes the state to Open Sent. 
  
4) Active State, Event 13 [no consensus] 
5) Active State, Event 14 [no consensus] 

  The problem with this state is it is difficult to
  exactly specify without discussing the TCP
  Messages that FSM document covers.
  
  I'll query if the implementors require all
  of events 13-17 as mandatory. 
  
  We'll 

6) Active State, Event 17 [no consensus] 

comment: 
In the Active state, we may already have a connection and be awaiting
the Open Delay timer.  The TCP disconnect or timeout could occur in this
state due to the "Open Delay Timer".   If the TCP Disconnect is ignored,
we could have some peer oscillation. 

If the we wait, then the connection retry timer needs to be kept running.
The text below allows this timer.  The real question is what is the status
of the current implementations.  

I agree, the Active state and the connect state should match.  

Old Text:
	If the TCP connection fails (timeout or disconnection) [Event 17],
	the local system:
		- set TCP disconnect in the MIB reason code,
		- restart Connect retry timer (with initial value),
		- release all BGP resources,
		- Acknowledge the Drop of the TCP connection if TCP disconnect (FIN ACK),
		- Increment ConnectRetryCnt (connect retry count) by 1, and
		- performs the BGP peer oscillation damping process.  

Applicable FSM State table:


FSM table old: 

 Event 17
 current:  Idle   Connect Active Open-Sent Open-Confirm Establish
           =========================================================
Next state Idle  |Active |Idle   |Active | Idle       |Idle       |  
		     |       |       |       |            |           |
	     =========================================================
 action       V  | Y2     | G     | Ignore| Track 2nd  | Track 2nd |
                 |       |       |       | connection | connection|
	     =========================================================

Alternative 1: 


FSM table new: 

 Event 17
 current:  Idle   Connect Active Open-Sent Open-Confirm Establish
           =========================================================
Next state Idle  |Active |Active   |Active | Idle       |Idle       |  
		     |       |        |       |            |           |
	     =========================================================
 action       V  | G     | G      | Ignore| Track 2nd  | Track 2nd |
                 |       |        |       | connection | connection|
	     =========================================================

G:  The local system:
	- restarts the connect retry timer (at intial value),
	- continues to listen for a connection that may be initiated
	  by the remote peer, and
	- sets its next state to Active. 

New Text: (for Connect and Active state)
		If the TCP connection fails (timeout or disconnect) 
		[Event 17], the local system:
		- restarts the connect retry timer,
		- continues to listen for a connection that may be 
		  initiated by the remote BGP peer, and
		- changes it state to Active.


Alternative 2: 
FSM table new: 

 Event 17
 current:  Idle   Connect Active Open-Sent Open-Confirm Establish
           =========================================================
Next state Idle  |Idle   |Idle   |Active | Idle       |Idle       |  
		     |       |       |       |            |           |
	     =========================================================
 action       V  | Y2    | Y2    | Ignore| Track 2nd  | Track 2nd |
                 |       |       |       | connection | connection|
	     =========================================================

Next Text: 
	If the location system receives a TCP connection failed [Event 17],
	the local system will:
		- increment the ConnectRetrycnt (connect retry count) by 1,
		- release all BGP resources associated with this connection,
		- perform BGP peer oscillation (if configured), and
		- go to Idle 

Y2 - is:
	The local system: 
		1) increments the ConnectRetryCnt (connect retry count) by 1,
		2) releases all BGP resources associated with this connection, and
		3) performs the BGP peer oscillation damping process

	if the damping process allows for a new connection, the local system
		- restarts the connect retry timer (with initial value, and 
		- goes to Idle

	If the damping process does not allow for a new connection, the local
	system
		- set the flags to damp the creation of a new bgp connection
	        until a manual start occurs, and
		- goes to Idle.


7) Open Confirm state, Event 18

Here's my proposed text. Please let me know what you think.
I think this is an editorial change.


Old text:  If the open message is valid, the collision detect 
           function is processed per section 6.8.  If this
           connection is to be dropped due to call collision, the local
	     system:
		- sends a Notification with a Cease
		- resets the Connect timer (to zero),
		- releases all BGP resources,
		- Drop the TCP connection (sends a TCP FIN),
		- increments the ConnectRetryCnt by 1 (connect retry count), and
		- performs an BGP peer oscillation damping process.

New text:  If the open message is valid, the BGP peer connection
	     is check to detect a collision per section 6.8.  If this
           connection is to be dropped due to call collision, the local
	     system:
		- sends a Notification with a Cease
		- resets the Connect timer (to zero),
		- releases all BGP resources,
		- Drop the TCP connection (sends a TCP FIN),
		- increments the ConnectRetryCnt by 1 (connect retry count), and
		- performs an BGP peer oscillation damping processing, and
		- enters the Idle State. 

	notes: Collision detect impacts Open Sent, Open Confirm, and
		 Established states. 

Applicable FSM state
		

>>       Open Confirm State:
>>
>>         If the Open messages is valid [Event 18], the collision
>>         detect function is processed per section 6.8.  If this
>>         connection is to be dropped due to call collision, the
>>         local system:
>>** enters what state
>
> This instance of the FSM should be discarded since it implies there is
> another FSM instance running that will proceed to Established?


-----Original Message-----
From: Tom Petch [mailto:[e-mail]]
Sent: Monday, December 02, 2002 11:07 AM
To: Jeffrey Haas
Cc: idr
Subject: Re: bgp18 WG Last Call fsm missing next state


Jeff

I appreciate your comments, agreeing with many.

A minor supplementary; Open Confirm, valid open [event 18], decide to
drop this connection and so the FSM but what about the actions of
incrementing the ConnectRetryCnt (and optional peer oscillation
damping)?  Are we doing that in the other FSM?  on a per router id or
per IP address pair independent of FSM?

And a slightly bigger issue in the Active state (which is the passive
state because we have entered it from Idle with Passive TCP flag set
Events 4/5).  In which case, TCP Indication valid [event 13] or
invalid [event 14] are what I would expect with event 14 keeping us in
Active state; and if event 13 also keeps us in Active state (while
sending a TCP SYN-ACK) then TCP Connection Confirmed [event 16] will
ensue while TCP Connection Acknowledged [event 15] would be an FSM
error.

Except that you suggest that event 14 in the Connect state takes us to
Active state which seems fine but for the fact that we will have sent
a TCP SYN (because that is what the Connect state is), this invalid
Indication may be a coincidence, in which case our SYN is about to
receive a SYN-ACK back ie event 15 is valid after all.  And I am then
in agreement with you over events 15/16 in the Active (ie passive)
state (delay open flag keeps us in the Active state).

Tom Petch
[e-mail]

-----Original Message-----
From: Jeffrey Haas <[e-mail]>
To: Tom Petch <[e-mail]>
Cc: idr <[e-mail]>
Date: 30 November 2002 01:33
Subject: Re: bgp18 WG Last Call fsm missing next state


>Tom,
>
>On Thu, Nov 28, 2002 at 02:53:56PM -0000, Tom Petch wrote:
>> In seven places in the FSM, the actions listed for the occurrence
of
>> an event do not include any indication of what the next state
should
>> be, nor can I be sure I can guess what it should be.
>>
>> I believe the FSM should specify the new state in the cases listed
>> below.
>>
Change 1: 

>>       Connect State:
>>
>>         If the TCP connection succeeds [Event 15 or
>>         Event 16], the local system checks the "Delay Open
>>         Flag".  If the delay Open flag is set, the local system:
>> **enters what state
>
>Remains in the connect state awaiting either an open message or
>for the opendelay timer to expire.
Agreed

Change 2: 
>
>>         If the TCP connection receives an indication
>>         that is invalid or unconfigured. [Event 14]:
>> **enters what state
>
>Enters the active state.
>Connectretrytimer should be started.
Agreed

Change 3: 
>>       Active State:
>>
>>         A TCP connection succeeds [Event 15 or Event 16], the
>>         local system: process the TCP connection flags
>>          - If the BGP delay open flag is set:
>> ** enters what state (I think this is an FSM error in TCP because
it
>> has not initiated a connection!)
>In the active state, we are awaiting incoming tcp connections to be
>completed.  Here we should:
>
>remain in the active state
>wait for an open message or the opendelay timer to expire.
>
Change 4: 

>>         If the local system receives a valid TCP Indication
>>         [Event 13], the local system processes the TCP connection
>> flags.
>> ** enters what state
>
>I'm also confused by this event.  Since we are not initiating a TCP
>connection, but are awaiting one to complete, why would we get an
>Indication here?  FSM error?

We would get an indication from the remote side that it had
send us a TCP Syn.  The real question is 

Change 5: 

>>         If the local system receives a TCP indication
>>         that is invalid for this connection [Event 14]:
>> ** enters what state
>
>Ditto.

Change 6: 
>>
>>         If the local system receives a TCP connection
>>         failed [Event 17] (timeout or receives connection
>>         disconnect), the local system will:
>> ** enters what state
>
>Ditto.

Change 7: 
>>       Open Confirm State:
>>
>>         If the Open messages is valid [Event 18], the collision
>>         detect function is processed per section 6.8.  If this
>>         connection is to be dropped due to call collision, the
>>         local system:
>> ** enters what state
>
>This instance of the FSM should be discarded since it implies there
is
>another FSM instance running that will proceed to Established?
>
>> Tom Petch
>> [e-mail]
>
>--
>Jeff Haas
>NextHop Technologies




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA26115 for <[e-mail]>; Wed, 4 Dec 2002 14:50:40 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A7A2A91232; Wed,  4 Dec 2002 14:50:12 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F5A3912BF; Wed,  4 Dec 2002 14:50:12 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E7A7C91232 for <[e-mail]>; Wed,  4 Dec 2002 14:50:10 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C58245E0E0; Wed,  4 Dec 2002 14:50:10 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 324755DE1F for <[e-mail]>; Wed,  4 Dec 2002 14:50:10 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gB4Jo7p34679 for [e-mail]; Wed, 4 Dec 2002 14:50:07 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gB4Jo1C34666 for <[e-mail]>; Wed, 4 Dec 2002 14:50:01 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
Subject: RE: bgp18 WG Last Call fsm missing keepalive
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Wed, 4 Dec 2002 14:50:01 -0500
Message-ID: <[e-mail]>
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: bgp18 WG Last Call fsm missing keepalive
Thread-Index: AcKbw0Li6ovNFLNkRbqWXgkZU9oIGQACM0UA
From: "Susan Hares" <[e-mail]>
To: "Tom Petch" <[e-mail]>, "idr" <[e-mail]>
Cc: "Jeffrey Haas" <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id OAA26115

Tom:

I agree about the putative OpenDelay, but I do not feel
that represents the BGP implementations of today.  We
spent a long time Jan-Feb 2002 on adding any FSM States.


My earlier note was too brief.  Please answer questions


1) Agree, this can occur in the Active state as well as the
   Connect state.  Will you accept the earlier text below
   to be inserted both places? 

Background: 

The state machine for Event 19 is: 

		   Idle  Connect Active    Open    Open     Estb
				               Sent    Confirm
		   ===============================================
Event 19       |     |        |        |        |      |      |
   next state  |Idle | Open   | Open   | Open   |Idle  | Idle |
               |     | confirm| confirm| Confirm|      |      |
               ===============================================			
   action	   | V   |  N-2   | N-2    |  N     | E-1  |  E   |
               ===============================================

Per the State Machine.

Action v - FSM Error
Action E - FSM Error, drop connection - etc, drop routes
Action E-1 - FSM Error, drop connection (lots of
Action N-2 (text below)
Action N   (text below, without sending Open)

2) Do you think that Event 19 is possible in the Open Sent state?

	Please answer this separately.

Thanks for all the wonderful review of the State machine.
I'm working my way through the comments. 

Sue 

-----Original Message-----
From: Tom Petch [mailto:[e-mail]]
Sent: Wednesday, December 04, 2002 1:30 PM
To: Susan Hares; idr
Cc: Jeffrey Haas
Subject: Re: bgp18 WG Last Call fsm missing keepalive


Still not quite.

This can occur in the Connect state as well as Active, when a TCP
connection completes with delay open flag set, my putative OpenDelay
state (sigh, point taken).

And we should still go to OpenConfirm state at the bottom of the
action list as is currently part of list H.

Tom Petch
[e-mail]

-----Original Message-----
From: Susan Hares <[e-mail]>
To: Tom Petch <[e-mail]>; idr <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>
Date: 04 December 2002 18:07
Subject: RE: bgp18 WG Last Call fsm missing keepalive


Tom:

Just to clarify this comment:

Event 19 = valid open with delay timer running

**Connect or Active = 1) awaiting TCP connection, or
   2) TCP connection completed and awaiting the
      TCP connection with delay timer running

Case 1:  - should not see Event 19
  In transition from Active to Open Confirm, the connection
  must have a TCP connection completed. Case 1 does not
  have this occurring, so the transition must be avoided.

Case 2: - should see Event 19

- Open, Keepalive should be sent.

Previous text: (Action H from FSM document)

If an Open is received with the BGP Delay Open timer running,
[Event 19], the local system:
- clears the connect retry timer [cleared to zero),
- completes the BGP initialization,
- stop and clears the BGP Open Delay timer,
- Sends an Open Message,
- sets the hold timer to a large value (4 minutes), and
- changes its state to an Open Confirm.

New text: [a New Action - N-2 : N + BGP keepalive sent]

If an Open is received with the BGP Delay Open Timer running
[Event 19], the local system:
- **clears the connect retry timer [cleared to zero],
- completes the BGP initialization,
- stops and clears the BGP Open Delay timer,
- **Sends an Open message,
- Sends a Keepalive message,
- If hold timer value is non-zero,
- **sets keepalive timer
- hold timer reset to negotiated value
  else if hold timer is zero,
- **resets the keepalive timer, and
- **resets the hold timer.
** and changes state to OpenConfirm

- If the value of the autonomous system field is the
  same as the local Autonomous system number, set
  the connection status to a internal connection;
  otherwise it is "external".

Please confirm that this change is OK for this comment.

Sue

-----Original Message-----
From: Tom Petch [mailto:[e-mail]]
Sent: Thursday, November 28, 2002 9:54 AM
To: idr
Subject: bgp18 WG Last Call fsm missing keepalive


When the OpenConfirm state is entered from OpenSent with the receipt
of a valid open [Event 18], then a KeepAlive message is sent and the
timer is started.

When the OpenConfirm state is entered from Active or Connect on
receipt of a valid open [Event 19], no message is sent, no timer is
started.

I believe this inconsistency is an error and should be corrected by
adding these two actions in those two places.

Tom Petch
[e-mail]






Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA22364 for <[e-mail]>; Wed, 4 Dec 2002 13:32:09 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1D37A912BD; Wed,  4 Dec 2002 13:30:46 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DEE13912BE; Wed,  4 Dec 2002 13:30:45 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 65A2F912BD for <[e-mail]>; Wed,  4 Dec 2002 13:30:44 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3F8A35E0DD; Wed,  4 Dec 2002 13:30:42 -0500 (EST)
Delivered-To: [e-mail]
Received: from nemesis.systems.pipex.net (nemesis.systems.pipex.net [62.241.160.8]) by segue.merit.edu (Postfix) with ESMTP id 90F115DE20 for <[e-mail]>; Wed,  4 Dec 2002 13:30:41 -0500 (EST)
Received: from tom3 (usercb13.uk.uudial.com [62.188.150.180]) by nemesis.systems.pipex.net (Postfix) with SMTP id 0125116007F9C; Wed,  4 Dec 2002 18:30:36 +0000 (GMT)
Message-ID: <010601c29bc3$382a00c0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Susan Hares" <[e-mail]>, "idr" <[e-mail]>
Cc: "Jeffrey Haas" <[e-mail]>
Subject: Re: bgp18 WG Last Call fsm missing keepalive
Date: Wed, 4 Dec 2002 18:29:49 -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: [e-mail]
Precedence: bulk

Still not quite.

This can occur in the Connect state as well as Active, when a TCP
connection completes with delay open flag set, my putative OpenDelay
state (sigh, point taken).

And we should still go to OpenConfirm state at the bottom of the
action list as is currently part of list H.

Tom Petch
[e-mail]

-----Original Message-----
From: Susan Hares <[e-mail]>
To: Tom Petch <[e-mail]>; idr <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>
Date: 04 December 2002 18:07
Subject: RE: bgp18 WG Last Call fsm missing keepalive


Tom:

Just to clarify this comment:

Event 19 = valid open with delay timer running

**Connect or Active = 1) awaiting TCP connection, or
   2) TCP connection completed and awaiting the
      TCP connection with delay timer running

Case 1:  - should not see Event 19
  In transition from Active to Open Confirm, the connection
  must have a TCP connection completed. Case 1 does not
  have this occurring, so the transition must be avoided.

Case 2: - should see Event 19

- Open, Keepalive should be sent.

Previous text: (Action H from FSM document)

If an Open is received with the BGP Delay Open timer running,
[Event 19], the local system:
- clears the connect retry timer [cleared to zero),
- completes the BGP initialization,
- stop and clears the BGP Open Delay timer,
- Sends an Open Message,
- sets the hold timer to a large value (4 minutes), and
- changes its state to an Open Confirm.

New text: [a New Action - N-2 : N + BGP keepalive sent]

If an Open is received with the BGP Delay Open Timer running
[Event 19], the local system:
- **clears the connect retry timer [cleared to zero],
- completes the BGP initialization,
- stops and clears the BGP Open Delay timer,
- **Sends an Open message,
- Sends a Keepalive message,
- If hold timer value is non-zero,
- **sets keepalive timer
- hold timer reset to negotiated value
  else if hold timer is zero,
- **resets the keepalive timer, and
- **resets the hold timer.
** and changes state to OpenConfirm

- If the value of the autonomous system field is the
  same as the local Autonomous system number, set
  the connection status to a internal connection;
  otherwise it is "external".

Please confirm that this change is OK for this comment.

Sue

-----Original Message-----
From: Tom Petch [mailto:[e-mail]]
Sent: Thursday, November 28, 2002 9:54 AM
To: idr
Subject: bgp18 WG Last Call fsm missing keepalive


When the OpenConfirm state is entered from OpenSent with the receipt
of a valid open [Event 18], then a KeepAlive message is sent and the
timer is started.

When the OpenConfirm state is entered from Active or Connect on
receipt of a valid open [Event 19], no message is sent, no timer is
started.

I believe this inconsistency is an error and should be corrected by
adding these two actions in those two places.

Tom Petch
[e-mail]






Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA21309 for <[e-mail]>; Wed, 4 Dec 2002 13:07:56 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 32064912BC; Wed,  4 Dec 2002 13:07:28 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3B54912BD; Wed,  4 Dec 2002 13:07:27 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E772912BC for <[e-mail]>; Wed,  4 Dec 2002 13:07:26 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 74C365E0DD; Wed,  4 Dec 2002 13:07:26 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id CA1525E0DA for <[e-mail]>; Wed,  4 Dec 2002 13:07:25 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gB4I7OR30577 for [e-mail]; Wed, 4 Dec 2002 13:07:24 -0500 (EST) (envelope-from [e-mail])
Received: from mail.corp.nexthop.com ([64.211.218.233]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id gB4I7JC30564 for <[e-mail]>; Wed, 4 Dec 2002 13:07:19 -0500 (EST) (envelope-from [e-mail])
content-class: urn:content-classes:message
Subject: RE: bgp18 WG Last Call fsm missing keepalive
Date: Wed, 4 Dec 2002 13:07:19 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
X-MS-TNEF-Correlator: 
Thread-Topic: bgp18 WG Last Call fsm missing keepalive
Thread-Index: AcKW7j4aVoADIlDnRJmySTnzE0qoPgEzTRsw
From: "Susan Hares" <[e-mail]>
To: "Tom Petch" <[e-mail]>, "idr" <[e-mail]>
Cc: "Jeffrey Haas" <[e-mail]>
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id NAA21309

Tom:

Just to clarify this comment: 

	Event 19 = valid open with delay timer running

	Active = 1) awaiting TCP connection, or
		   2) TCP connection completed and awaiting the
		      TCP connection with delay timer running

Case 1:  - should not see Event 19
  In transition from Active to Open Confirm, the connection
  must have a TCP connection completed. Case 1 does not
  have this occurring, so the transition must be avoided.

Case 2: - should see Event 19

	- Open, Keepalive should be sent.

Previous text: (Action H from FSM document) 

	If an Open is received with the BGP Delay Open timer running,
	[Event 19], the local system:
	- clears the connect retry timer [cleared to zero),
	- completes the BGP initialization, 
	- stop and clears the BGP Open Delay timer,
	- Sends an Open Message,
	- sets the hold timer to a large value (4 minutes), and
	- changes its state to an Open Confirm.

New text: [a New Action - N-2 : N + BGP keepalive sent]

	If an Open is received with the BGP Delay Open Timer running
	[Event 19], the local system:
	- clear the connect retry timer [cleared to zero],
	- completes the BGP initialization,
	- stops and clears the BGP Open Delay timer,
	- Send an Open message,
	- Sends a Keepalive message,
	- If hold timer value is non-zero, 
		- set keepalive timer
		- hold timer reset to negotiated value
	  else if hold timer is zero,
		- reset the keepalive timer, and
		- reset the hold timer.

	- If the value of the autonomous system field is the 
	  same as the local Autonomous system number, set
	  the connection status to a internal connection;
	  otherwise it is "external".  

Please confirm that this change is OK for this comment.

Sue 

-----Original Message-----
From: Tom Petch [mailto:[e-mail]]
Sent: Thursday, November 28, 2002 9:54 AM
To: idr
Subject: bgp18 WG Last Call fsm missing keepalive


When the OpenConfirm state is entered from OpenSent with the receipt
of a valid open [Event 18], then a KeepAlive message is sent and the
timer is started.

When the OpenConfirm state is entered from Active or Connect on
receipt of a valid open [Event 19], no message is sent, no timer is
started.

I believe this inconsistency is an error and should be corrected by
adding these two actions in those two places.

Tom Petch
[e-mail]





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA19627 for <[e-mail]>; Wed, 4 Dec 2002 12:25:38 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5D1B2912BB; Wed,  4 Dec 2002 12:25:19 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2CA7F912BC; Wed,  4 Dec 2002 12:25:19 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D26E1912BB for <[e-mail]>; Wed,  4 Dec 2002 12:25:16 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C19D65E0D3; Wed,  4 Dec 2002 12:25:16 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 383745DDD5 for <[e-mail]>; Wed,  4 Dec 2002 12:25:16 -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 gB4HPDS55420; Wed, 4 Dec 2002 09:25:13 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Tom Petch" <[e-mail]>
Cc: "idr" <[e-mail]>
Subject: Re: bgp18 WG Last Call fsm incorrect next state 
In-Reply-To: Your message of "Thu, 28 Nov 2002 14:52:59 GMT." <002501c296ee$1b8e7920$0301a8c0@tom3> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 04 Dec 2002 09:25:13 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Tom,

> I believe that there is an incorrect next state when the delay open
> timer expires [event 12] in the Active state.  The next state should
> be OpenSent and not OpenConfirm.

you are correct. Will be fixed in the next revision.

Yakov. 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA21590 for <[e-mail]>; Tue, 3 Dec 2002 08:04:23 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 322DC91297; Tue,  3 Dec 2002 08:03:53 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0F34912A0; Tue,  3 Dec 2002 08:03:40 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6AE8B91297 for <[e-mail]>; Tue,  3 Dec 2002 08:02:59 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 45FEC5E027; Tue,  3 Dec 2002 08:02:59 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 587F05DF39 for <[e-mail]>; Tue,  3 Dec 2002 08:02:58 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17205; Tue, 3 Dec 2002 08:00:07 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-route-filter-07.txt
Date: Tue, 03 Dec 2002 08:00:07 -0500
Sender: [e-mail]
Precedence: bulk

--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		: Cooperative Route Filtering Capability for BGP-4
	Author(s)	: E. Chen, Y. Rekhter
	Filename	: draft-ietf-idr-route-filter-07.txt
	Pages		: 11
	Date		: 2002-12-2
	
This document defines a BGP-based mechanism that allows a BGP speaker
to send to its BGP peer a set of route filters that the peer would
use to constrain/filter its outbound routing updates to the speaker.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-07.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-route-filter-07.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:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-route-filter-07.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-route-filter-07.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-route-filter-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA21388 for <[e-mail]>; Tue, 3 Dec 2002 08:00:30 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1E4C491294; Tue,  3 Dec 2002 08:00:00 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3B3F91295; Tue,  3 Dec 2002 07:59:59 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8F4C291294 for <[e-mail]>; Tue,  3 Dec 2002 07:59:58 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 6D05B5E0B3; Tue,  3 Dec 2002 07:59:58 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id B03975E008 for <[e-mail]>; Tue,  3 Dec 2002 07:59:57 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id HAA01283; Tue, 3 Dec 2002 07:59:20 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
Cc: Mathew Richardson <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: proxy: more comments on draft -18 
In-reply-to: Your message of "Mon, 02 Dec 2002 23:23:07 +0530." <[e-mail]> 
Date: Tue, 03 Dec 2002 07:59:20 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, "Sivanand
a Ramnath - CTD, Chennai." writes:
> Hello,
> 
>     That does not quite solve the problem. Curtis wrote a detailed mail on
> the issue in which he explained a possibility for formation of loops if this
> were done.
> 
> Sivanand
> ([e-mail])
> > 
> > I've always thought (perhaps erroneously) that the reason support for
> > removing MEDs was included in the spec was to allow an AS to choose to
> > ignore MEDs.  If it is desirable to allow an AS to choose to 
> > ignore MEDs,
> > and this was the motivation for supporting the removal of MEDs, then I
> > propose:
> > 
> > 	If a MULTI_EXIT_DISC attribute will be removed before re-
> > 	advertising a route into IBGP, then the attribute SHALL be
> > 	considered missing when performing comparisons based on the
> > 	MULTI_EXIT_DISC attribute of a route.
> > 
> > mrr


The text above would be sufficient to eliminate the route loops but
the action recommended by it would be more than is needed to eliminate
route loops and does not match current practice (afaik).  It is safe
to use the MED in comparisons of EBGP learned routes, pick one, then
strip MED, then compare the best EBGP learned routes with the IBGP
learned routes, then advertise.  The text above oversimplifies
yielding two (not quite correct) steps: strip MED, then compare.

Curtis


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA21370 for <[e-mail]>; Mon, 2 Dec 2002 22:49:06 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 4FFB591284; Mon,  2 Dec 2002 22:48:44 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B87191285; Mon,  2 Dec 2002 22:48:44 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D137491284 for <[e-mail]>; Mon,  2 Dec 2002 22:48:42 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B49C95DF81; Mon,  2 Dec 2002 22:48:42 -0500 (EST)
Delivered-To: [e-mail]
Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id 3F81B5DFDB for <[e-mail]>; Mon,  2 Dec 2002 22:48:41 -0500 (EST)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <YD7Z6TPM>; Mon, 2 Dec 2002 23:29:12 +0530
Message-ID: <[e-mail]>
From: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
To: Mathew Richardson <[e-mail]>, [e-mail]
Subject: RE: proxy: more comments on draft -18
Date: Mon, 2 Dec 2002 23:23:07 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hello,

    That does not quite solve the problem. Curtis wrote a detailed mail on
the issue in which he explained a possibility for formation of loops if this
were done.

Sivanand
([e-mail])
> 
> I've always thought (perhaps erroneously) that the reason support for
> removing MEDs was included in the spec was to allow an AS to choose to
> ignore MEDs.  If it is desirable to allow an AS to choose to 
> ignore MEDs,
> and this was the motivation for supporting the removal of MEDs, then I
> propose:
> 
> 	If a MULTI_EXIT_DISC attribute will be removed before re-
> 	advertising a route into IBGP, then the attribute SHALL be
> 	considered missing when performing comparisons based on the
> 	MULTI_EXIT_DISC attribute of a route.
> 
> mrr
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA10120 for <[e-mail]>; Mon, 2 Dec 2002 19:24:24 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DA1A491283; Mon,  2 Dec 2002 19:23:07 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A762691282; Mon,  2 Dec 2002 19:23:07 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7EBAD91281 for <[e-mail]>; Mon,  2 Dec 2002 19:23:04 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 53D7D5E016; Mon,  2 Dec 2002 19:23:04 -0500 (EST)
Delivered-To: [e-mail]
Received: from nomad.tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by segue.merit.edu (Postfix) with ESMTP id 138105DFFD for <[e-mail]>; Mon,  2 Dec 2002 19:23:04 -0500 (EST)
Received: by nomad.tcb.net (Postfix, from userid 500) id D0B5755F67; Mon,  2 Dec 2002 17:23:23 -0700 (MST)
Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id CDD5F3E83 for <[e-mail]>; Mon,  2 Dec 2002 17:23:23 -0700 (MST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: [e-mail]
From: Danny McPherson <[e-mail]>
Reply-To: [e-mail]
Subject: RFC1773bis - Experience with BGP
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 02 Dec 2002 17:23:18 -0700
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,
As required by RFC 1264 as part of the BGP-4 standardization process RFC 
1773 (Experience with BGP) needs to be updated, and I've volunteered to 
do the update.  Namely, this update needs to focus on [from RFC 1264]:

  Revisions to the Protocol and Usage documents showing changes and 
  clarifications made based on experience gained in the time between 
  when the protocol was made a Draft Standard and it being submitted 
  for Standard.  The changes should be to clarify the protocol or 
  provide guidance in its implementation.  

With that said, (and 4 other items from 1264 being required as well),
I'd like to solicit feedback from the WG on what items they'd like to 
see in the update, in addition to those items discussed in Appendix A 
of idr-bgp4-18.txt.

Thanks in advance!

-danny



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA07470 for <[e-mail]>; Mon, 2 Dec 2002 18:34:03 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 083AD91238; Mon,  2 Dec 2002 18:33:36 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8360D9127C; Mon,  2 Dec 2002 18:32:10 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 330D591238 for <[e-mail]>; Mon,  2 Dec 2002 18:32:08 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 067765DEA4; Mon,  2 Dec 2002 18:32:08 -0500 (EST)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 6B91F5DDC5 for <[e-mail]>; Mon,  2 Dec 2002 18:32:07 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id PAA21422; Mon, 2 Dec 2002 15:28:45 -0800 (PST)
Date: Mon, 2 Dec 2002 15:28:45 -0800
From: [e-mail]
To: Yakov Rekhter <[e-mail]>
Cc: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>, Alex Zinin <[e-mail]>, [e-mail]
Subject: Re: proxy: more comments on draft -18
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Dec 02, 2002 at 06:54:34AM -0800
Sender: [e-mail]
Precedence: bulk

> > > here is my attempt to clarify this:
> > > 
> > >   If a MULTI_EXIT_DISC attribute is removed before re-advertising a
> > >   route into IBGP, then (prior to the removal) the MULTI_EXIT_DISC 
> > >   attribute may only be considered in the comparison of EBGP learned
> > >   routes; the attribute is then removed, and then the remaining EBGP
> > >   learned routes may be compared to the remaining IBGP learned routes,
> > >   without considering the MULTI_EXIT_DISC attribute for those EBGP
> > >   learned routes whose MULTI_EXIT_DISC attribute will be removed   
> > >   before advertising these routes to IBGP.
> > > 
> > > Any further suggestions on how to improve this would be appreciated.
> > 
> >   How about this:
> > 
> > %   If a MULTI_EXIT_DISC attribute is removed before re-advertising a
> > %   route into IBGP, then comparison based on the MULT_EXIT_DISC
> > %   attribute may (MUST?) be performed only among the EBGP learned routes.
> > %   This comparison MUST be performed before the removal of the
> > %   MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute must then
> > %   be removed from those EBGP routes where such removal is required and
> > %   which are still eligible. This is followed by comparison with IBGP
> > %   learned routes.
> > 
> >     I think this reflects our objectives, which is:
> > 
> >     a) If MED is to be removed, compare EBGP routes based on the MED
> > 
> >     b) Then remove the MED
> > 
> >     c) Then do comparison with IBGP routes
> 
> If nobody would propose anything better, then I'll use your text in
> the next revision.

How about:

If a router is configured to remove a MUTLI_EXIT_DISC attribute from
a route learned from EBGP, before readvertising it into IBGP the
router MUST compare the route with other EBGP-learned routes before
removing the MULTI_EXIT_DISC.  Once this comparison is complete, 
the MED may be removed, and any remaining routes can be compared with 
IBGP routes to determine the best route.

Andrew



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA28637 for <[e-mail]>; Mon, 2 Dec 2002 14:49:03 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2B2E391275; Mon,  2 Dec 2002 14:47:48 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F300191276; Mon,  2 Dec 2002 14:47:47 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6DA7A91275 for <[e-mail]>; Mon,  2 Dec 2002 14:47:23 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3C80C5DE4B; Mon,  2 Dec 2002 14:47:23 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 649625E021 for <[e-mail]>; Mon,  2 Dec 2002 14:47:18 -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 gB2JlIS72581 for <[e-mail]>; Mon, 2 Dec 2002 11:47:18 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Close of Last Call
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 02 Dec 2002 11:47:17 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

The last call on BGP Base spec:

  draft-ietf-idr-bgp4-18.txt

has ended.

The editors will reply to all the comments received so far and
will re-issue a revised draft that reflects the comments.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA28410 for <[e-mail]>; Mon, 2 Dec 2002 14:44:40 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1AB9591270; Mon,  2 Dec 2002 14:44:21 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D66D591273; Mon,  2 Dec 2002 14:44:20 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE3A991270 for <[e-mail]>; Mon,  2 Dec 2002 14:44:19 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A58E95E021; Mon,  2 Dec 2002 14:44:19 -0500 (EST)
Delivered-To: [e-mail]
Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by segue.merit.edu (Postfix) with ESMTP id 1111A5DE4B for <[e-mail]>; Mon,  2 Dec 2002 14:44:19 -0500 (EST)
Received: from bifocal.cisco.com (bifocal.cisco.com [161.44.172.150]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA06992; Mon, 2 Dec 2002 14:44:17 -0500 (EST)
Received: from localhost (swallow@localhost) by bifocal.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA19839; Mon, 2 Dec 2002 14:44:17 -0500 (EST)
Message-Id: <[e-mail]>
X-Authentication-Warning: bifocal.cisco.com: swallow owned process doing -bs
To: [e-mail], [e-mail]
Subject: Close of Last Call
Date: Mon, 02 Dec 2002 14:44:17 -0500
From: George Swallow <[e-mail]>
Sender: [e-mail]
Precedence: bulk

The last call on 

 "Graceful Restart Mechanisms for BGP with MPLS"

    draft-ietf-mpls-bgp-mpls-restart-02.txt

has ended.

...George

======================================================================
George Swallow          Cisco Systems                   [phone]
                        250 Apollo Drive
                        Chelmsford, Ma 01824





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA23520 for <[e-mail]>; Mon, 2 Dec 2002 12:42:07 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B7BCE91262; Mon,  2 Dec 2002 12:41:48 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D45F91263; Mon,  2 Dec 2002 12:41:48 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3459391262 for <[e-mail]>; Mon,  2 Dec 2002 12:41:47 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 187705DEB2; Mon,  2 Dec 2002 12:41:47 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 7EFCE5DE89 for <[e-mail]>; Mon,  2 Dec 2002 12:41:46 -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 gB2HfkS59895 for <[e-mail]>; Mon, 2 Dec 2002 09:41:46 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: slides
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 02 Dec 2002 09:41:46 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

Those of you who presented at the last IDR meeting, please
send your slides to [e-mail]

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA22747 for <[e-mail]>; Mon, 2 Dec 2002 12:24:15 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A617991261; Mon,  2 Dec 2002 12:23:52 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6781491262; Mon,  2 Dec 2002 12:23:52 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2EDE091261 for <[e-mail]>; Mon,  2 Dec 2002 12:23:51 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1251E5DE89; Mon,  2 Dec 2002 12:23:51 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 77BF05DDE2 for <[e-mail]>; Mon,  2 Dec 2002 12:23:50 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gB2HNnb77605 for [e-mail]; Mon, 2 Dec 2002 12:23:49 -0500 (EST) (envelope-from [e-mail])
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 gB2HNkC77598 for <[e-mail]>; Mon, 2 Dec 2002 12:23:46 -0500 (EST) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id gB2HNkw18921 for [e-mail]; Mon, 2 Dec 2002 12:23:46 -0500 (EST)
Date: Mon, 2 Dec 2002 12:23:46 -0500
From: Mathew Richardson <[e-mail]>
To: [e-mail]
Subject: Re: proxy: more comments on draft -18
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4i
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

> Yakov Rekhter <[e-mail]> [Mon, Dec 02, 2002 at 06:54:34AM -0800]:
>Siva,

<snip>

>> > here is my attempt to clarify this:
>> > 
>> >   If a MULTI_EXIT_DISC attribute is removed before re-advertising a
>> >   route into IBGP, then (prior to the removal) the MULTI_EXIT_DISC 
>> >   attribute may only be considered in the comparison of EBGP learned
>> >   routes; the attribute is then removed, and then the remaining EBGP
>> >   learned routes may be compared to the remaining IBGP learned routes,
>> >   without considering the MULTI_EXIT_DISC attribute for those EBGP
>> >   learned routes whose MULTI_EXIT_DISC attribute will be removed   
>> >   before advertising these routes to IBGP.
>> > 
>> > Any further suggestions on how to improve this would be appreciated.
>> 
>>   How about this:
>> 
>> %   If a MULTI_EXIT_DISC attribute is removed before re-advertising a
>> %   route into IBGP, then comparison based on the MULT_EXIT_DISC
>> %   attribute may (MUST?) be performed only among the EBGP learned routes.
>> %   This comparison MUST be performed before the removal of the
>> %   MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute must then
>> %   be removed from those EBGP routes where such removal is required and
>> %   which are still eligible. This is followed by comparison with IBGP
>> %   learned routes.
>> 
>>     I think this reflects our objectives, which is:
>> 
>>     a) If MED is to be removed, compare EBGP routes based on the MED
>> 
>>     b) Then remove the MED
>> 
>>     c) Then do comparison with IBGP routes
>
>If nobody would propose anything better, then I'll use your text in
>the next revision.

<snip>

I've always thought (perhaps erroneously) that the reason support for
removing MEDs was included in the spec was to allow an AS to choose to
ignore MEDs.  If it is desirable to allow an AS to choose to ignore MEDs,
and this was the motivation for supporting the removal of MEDs, then I
propose:

	If a MULTI_EXIT_DISC attribute will be removed before re-
	advertising a route into IBGP, then the attribute SHALL be
	considered missing when performing comparisons based on the
	MULTI_EXIT_DISC attribute of a route.

mrr


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA20621 for <[e-mail]>; Mon, 2 Dec 2002 11:36:12 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6973C9125F; Mon,  2 Dec 2002 11:33:34 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79B6891261; Mon,  2 Dec 2002 11:33:31 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C6BA791260 for <[e-mail]>; Mon,  2 Dec 2002 11:33:27 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3B4855DDDF; Mon,  2 Dec 2002 11:33:27 -0500 (EST)
Delivered-To: [e-mail]
Received: from smail2.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by segue.merit.edu (Postfix) with ESMTP id 92AF75DDD2 for <[e-mail]>; Mon,  2 Dec 2002 11:33:26 -0500 (EST)
Received: from nmu.alcatel.fr (tcmh80.nmu.alcatel.fr [139.54.143.3]) by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id gB2GXPaX011915 for <[e-mail]>; Mon, 2 Dec 2002 17:33:25 +0100
Received: from nmu.alcatel.fr (houat [192.200.245.153]) by nmu.alcatel.fr (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id RAA05425 for <[e-mail]>; Mon, 2 Dec 2002 17:33:06 +0100 (MET)
Message-ID: <[e-mail]>
Date: Mon, 02 Dec 2002 17:33:07 +0100
From: christophe preguica <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: MD5 and MP-BGP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: [e-mail]
Precedence: bulk

Does anyone know if TCP MD5 signature option (RFC 2385) for MP-BGP is
applicable for IPv6 ?

Thanks.




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA20358 for <[e-mail]>; Mon, 2 Dec 2002 11:27:46 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A7BEE9125D; Mon,  2 Dec 2002 11:27:20 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F55F9125E; Mon,  2 Dec 2002 11:27:20 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 634549125D for <[e-mail]>; Mon,  2 Dec 2002 11:27:19 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 4EB5F5DF37; Mon,  2 Dec 2002 11:27:19 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id CAC185DDDF for <[e-mail]>; Mon,  2 Dec 2002 11:27:18 -0500 (EST)
Received: by sentry.gw.tislabs.com; id LAA08767; Mon, 2 Dec 2002 11:27:32 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma008754; Mon, 2 Dec 02 11:26:58 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id gB2GQhk21933; Mon, 2 Dec 2002 11:26:43 -0500 (EST)
Date: Mon, 2 Dec 2002 11:26:43 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail], [e-mail], [e-mail]
Subject: Re: BGP security in practice
Sender: [e-mail]
Precedence: bulk

>>In the judgement of those on this list, is the general ISP as clueless
>>as this?  Mind you, I'm not asking if the common ISP uses the MD5, just
>>if they know that there's a security vulnerability if they don't.
>
>
>They probably also know there is a gaping hole even if they do - re TCP RST
>attacks etc. 

But the TCP MD5 protections were said to be a good idea expressly because
they do protect against TCP RST.  Do you have news to the contrary?

--Sandy


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA20155 for <[e-mail]>; Mon, 2 Dec 2002 11:23:07 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8AFFB91230; Mon,  2 Dec 2002 11:22:45 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E9A59125D; Mon,  2 Dec 2002 11:22:45 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8306B91230 for <[e-mail]>; Mon,  2 Dec 2002 11:22:41 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 7271E5DF37; Mon,  2 Dec 2002 11:22:41 -0500 (EST)
Delivered-To: [e-mail]
Received: from nemesis.systems.pipex.net (nemesis.systems.pipex.net [62.241.160.8]) by segue.merit.edu (Postfix) with ESMTP id 26CEB5DDDF for <[e-mail]>; Mon,  2 Dec 2002 11:22:41 -0500 (EST)
Received: from tom3 (userbm24.uk.uudial.com [62.188.144.230]) by nemesis.systems.pipex.net (Postfix) with SMTP id 6BC9916007E5C; Mon,  2 Dec 2002 16:22:35 +0000 (GMT)
Message-ID: <004b01c29a1f$033ba760$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Jeffrey Haas" <[e-mail]>
Cc: "idr" <[e-mail]>
Subject: Re: bgp18 WG Last Call fsm missing next state
Date: Mon, 2 Dec 2002 16:06:30 -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: [e-mail]
Precedence: bulk

Jeff

I appreciate your comments, agreeing with many.

A minor supplementary; Open Confirm, valid open [event 18], decide to
drop this connection and so the FSM but what about the actions of
incrementing the ConnectRetryCnt (and optional peer oscillation
damping)?  Are we doing that in the other FSM?  on a per router id or
per IP address pair independent of FSM?

And a slightly bigger issue in the Active state (which is the passive
state because we have entered it from Idle with Passive TCP flag set
Events 4/5).  In which case, TCP Indication valid [event 13] or
invalid [event 14] are what I would expect with event 14 keeping us in
Active state; and if event 13 also keeps us in Active state (while
sending a TCP SYN-ACK) then TCP Connection Confirmed [event 16] will
ensue while TCP Connection Acknowledged [event 15] would be an FSM
error.

Except that you suggest that event 14 in the Connect state takes us to
Active state which seems fine but for the fact that we will have sent
a TCP SYN (because that is what the Connect state is), this invalid
Indication may be a coincidence, in which case our SYN is about to
receive a SYN-ACK back ie event 15 is valid after all.  And I am then
in agreement with you over events 15/16 in the Active (ie passive)
state (delay open flag keeps us in the Active state).

Tom Petch
[e-mail]

-----Original Message-----
From: Jeffrey Haas <[e-mail]>
To: Tom Petch <[e-mail]>
Cc: idr <[e-mail]>
Date: 30 November 2002 01:33
Subject: Re: bgp18 WG Last Call fsm missing next state


>Tom,
>
>On Thu, Nov 28, 2002 at 02:53:56PM -0000, Tom Petch wrote:
>> In seven places in the FSM, the actions listed for the occurrence
of
>> an event do not include any indication of what the next state
should
>> be, nor can I be sure I can guess what it should be.
>>
>> I believe the FSM should specify the new state in the cases listed
>> below.
>>
>>       Connect State:
>>
>>         If the TCP connection succeeds [Event 15 or
>>         Event 16], the local system checks the "Delay Open
>>         Flag".  If the delay Open flag is set, the local system:
>> **enters what state
>
>Remains in the connect state awaiting either an open message or
>for the opendelay timer to expire.
Agreed
>
>>         If the TCP connection receives an indication
>>         that is invalid or unconfigured. [Event 14]:
>> **enters what state
>
>Enters the active state.
>Connectretrytimer should be started.
Agreed
>
>>       Active State:
>>
>>         A TCP connection succeeds [Event 15 or Event 16], the
>>         local system: process the TCP connection flags
>>          - If the BGP delay open flag is set:
>> ** enters what state (I think this is an FSM error in TCP because
it
>> has not initiated a connection!)
>
>In the active state, we are awaiting incoming tcp connections to be
>completed.  Here we should:
>
>remain in the active state
>wait for an open message or the opendelay timer to expire.
>
>>         If the local system receives a valid TCP Indication
>>         [Event 13], the local system processes the TCP connection
>> flags.
>> ** enters what state
>
>I'm also confused by this event.  Since we are not initiating a TCP
>connection, but are awaiting one to complete, why would we get an
>Indication here?  FSM error?
>
>>         If the local system receives a TCP indication
>>         that is invalid for this connection [Event 14]:
>> ** enters what state
>
>Ditto.
>
>>
>>         If the local system receives a TCP connection
>>         failed [Event 17] (timeout or receives connection
>>         disconnect), the local system will:
>> ** enters what state
>
>Ditto.
>
>>       Open Confirm State:
>>
>>         If the Open messages is valid [Event 18], the collision
>>         detect function is processed per section 6.8.  If this
>>         connection is to be dropped due to call collision, the
>>         local system:
>> ** enters what state
>
>This instance of the FSM should be discarded since it implies there
is
>another FSM instance running that will proceed to Established?
>
>> Tom Petch
>> [e-mail]
>
>--
>Jeff Haas
>NextHop Technologies




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA19945 for <[e-mail]>; Mon, 2 Dec 2002 11:18:20 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B3F839125C; Mon,  2 Dec 2002 11:17:40 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D5D391258; Mon,  2 Dec 2002 11:17:40 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BEFC79125C for <[e-mail]>; Mon,  2 Dec 2002 11:17:38 -0500 (EST)
Received: by segue.merit.edu (Postfix) id AB9565DF37; Mon,  2 Dec 2002 11:17:38 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 1B6355DDDF for <[e-mail]>; Mon,  2 Dec 2002 11:17:38 -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 gB2GHUS52750; Mon, 2 Dec 2002 08:17:30 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "John G. Scudder" <[e-mail]>
Cc: [e-mail]
Subject: Re: -18 last call comments 
In-Reply-To: Your message of "Mon, 02 Dec 2002 10:54:45 EST." <p05200f10ba112e474dfe@[192.168.42.10]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 02 Dec 2002 08:17:30 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

John,

> At 10:25 AM -0500 12/2/02, Jeffrey Haas wrote:
> >On Mon, Dec 02, 2002 at 01:03:50PM -0800, Manav wrote:
> >>  I understand that there can be situations when you receive your own AS
> >>  number in the UPDATE message and the best course of action is to simply
> >>  ignore it and proceed with the next set.
> >
> >In the case of receiving your own AS number, this is fairly typical.
> >
> >You may wish to search the archives for the thread on outbound
> >as-loop detection.
> [etc]
> 
> I agree with Jeff's comments.
> 
> I have one further comment just in case it's not perfectly obvious to 
> everyone, which is that "ignore the UPDATE" is not strictly the 
> action you take when receiving a looped update.  Rather, you treat it 
> as an implicit withdraw, i.e. you process it as any other update but 
> treat the contained NLRI as unfeasible.
> 
> I was going to write that this is sufficiently clear from the spec, 
> but I regret to say that it isn't.  Here is the fourth paragraph of 
> section 9:
> 
>     The information carried by the AS_PATH attribute is checked for AS
>     loops. AS loop detection is done by scanning the full AS path (as
>     specified in the AS_PATH attribute), and checking that the autonomous
>     system number of the local system does not appear in the AS path.  If
>     the autonomous system number appears in the AS path the route may be
>     stored in the Adj-RIB-In, but unless the router is configured to
>     accept routes with its own autonomous system in the AS path, the
>     route shall not be passed to the BGP Decision Process. Operations of
>     a router that is configured to accept routes with its own autonomous
>     system number in the AS path are outside the scope of this document.
> 
> I don't think this is quite right -- the decision process needs to be 
> run if the looped routes had previously been advertised feasibly on 
> the same session.  This could be fixed by hacking the quoted 
> paragraph, but it seems more straightforward to do it by removing the 
> quoted paragraph and making the fix in 9.1.2 Phase 2 instead.  This 
> could be done by inserting the following between the third and fourth 
> paragraphs of 9.1.2 Phase 2:
> 
>     If the AS_PATH attribute of a BGP route contains an AS loop, the
>     BGP route should be excluded from the Phase 2 decision function.
>     AS loop detection is done by scanning the full AS path (as
>     specified in the AS_PATH attribute), and checking that the autonomous
>     system number of the local system does not appear in the AS path.
>     Operations of a router that is configured to accept routes with its
>     own autonomous system number in the AS path are outside the scope of
>     this document.
> 
> Section 9.3, first bullet, also addresses this topic, but I don't 
> think it's sufficient.

The change you suggested seems reasonable. Will be incorporated
in the next revision.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA19463 for <[e-mail]>; Mon, 2 Dec 2002 11:07:09 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 22E4F9122F; Mon,  2 Dec 2002 11:06:36 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DEA4D9125B; Mon,  2 Dec 2002 11:06:35 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B21529122F for <[e-mail]>; Mon,  2 Dec 2002 11:06:34 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A10205E087; Mon,  2 Dec 2002 11:06:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 127855E015 for <[e-mail]>; Mon,  2 Dec 2002 11:06:34 -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 gB2G6WS51976; Mon, 2 Dec 2002 08:06:32 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: -18 last call comments 
In-Reply-To: Your message of "Mon, 02 Dec 2002 10:52:49 EST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 02 Dec 2002 08:06:32 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> On Sat, Nov 30, 2002 at 04:46:57PM -0800, Yakov Rekhter wrote:
> > 1772 is in the non-normative section. I think we could keep it there,
> > and keep the references as well.
> 
> My concern is mostly that as we publish the BGP spec as an RFC
> it'd be nice for it to refer to whatever replaces 1772.
> 
> I don't know how this is handled in practice, but I don't think its
> a big deal.  I just thought it was worth bringing up.
> 
> > > Capitalization of magic words such as MUST and SHOULD should be done.
> > 
> > It should be done *as appropriate*. Therefore, if you think there
> > are places where it is *appropriate* to do capitalization, please
> > point them out.
> 
> Will do when I can find a few cycles.
> 
> > > Update message error subcode 7 is removed.  Especially in -18,
> > > it looks like an editing mistake based on where it would fall
> > > in the editing..
> > 
> > From Appendix A:
> > 
> >   UPDATE Message Error subcode 7 (AS Routing Loop) has been deprecated.
> 
> What I would like to see is something like this:
> 
> 6 - Invalid ORIGIN Attribute
> 7 - [Deprecated - See Appendix A]
> 8 - Invalid NEXT_HOP Attribute
> As it stands, 7 lies on a page boundary and looks like it got clipped
> by the roff.

Ok. I'll also add a similar text for Open Message Error subcode 5.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA19090 for <[e-mail]>; Mon, 2 Dec 2002 10:57:35 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BB2EF91259; Mon,  2 Dec 2002 10:57:08 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CAFB9125A; Mon,  2 Dec 2002 10:57:08 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76B7C91259 for <[e-mail]>; Mon,  2 Dec 2002 10:57:07 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 64CB25DDDF; Mon,  2 Dec 2002 10:57:07 -0500 (EST)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id AE51B5DDB8 for <[e-mail]>; Mon,  2 Dec 2002 10:57:06 -0500 (EST)
Received: from [192.168.42.10] (dhcp-64-101-214-208.cisco.com [64.101.214.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA19878 for <[e-mail]>; Mon, 2 Dec 2002 10:57:02 -0500 (EST)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05200f10ba112e474dfe@[192.168.42.10]>
In-Reply-To: <[e-mail]>
References: <00bf01c29a46$503abc50$8946d5a5@samsungy77z6fd> <[e-mail]>
Date: Mon, 2 Dec 2002 10:54:45 -0500
To: [e-mail]
From: "John G. Scudder" <[e-mail]>
Subject: Re: -18 last call comments
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 10:25 AM -0500 12/2/02, Jeffrey Haas wrote:
>On Mon, Dec 02, 2002 at 01:03:50PM -0800, Manav wrote:
>>  I understand that there can be situations when you receive your own AS
>>  number in the UPDATE message and the best course of action is to simply
>>  ignore it and proceed with the next set.
>
>In the case of receiving your own AS number, this is fairly typical.
>
>You may wish to search the archives for the thread on outbound
>as-loop detection.
[etc]

I agree with Jeff's comments.

I have one further comment just in case it's not perfectly obvious to 
everyone, which is that "ignore the UPDATE" is not strictly the 
action you take when receiving a looped update.  Rather, you treat it 
as an implicit withdraw, i.e. you process it as any other update but 
treat the contained NLRI as unfeasible.

I was going to write that this is sufficiently clear from the spec, 
but I regret to say that it isn't.  Here is the fourth paragraph of 
section 9:

    The information carried by the AS_PATH attribute is checked for AS
    loops. AS loop detection is done by scanning the full AS path (as
    specified in the AS_PATH attribute), and checking that the autonomous
    system number of the local system does not appear in the AS path.  If
    the autonomous system number appears in the AS path the route may be
    stored in the Adj-RIB-In, but unless the router is configured to
    accept routes with its own autonomous system in the AS path, the
    route shall not be passed to the BGP Decision Process. Operations of
    a router that is configured to accept routes with its own autonomous
    system number in the AS path are outside the scope of this document.

I don't think this is quite right -- the decision process needs to be 
run if the looped routes had previously been advertised feasibly on 
the same session.  This could be fixed by hacking the quoted 
paragraph, but it seems more straightforward to do it by removing the 
quoted paragraph and making the fix in 9.1.2 Phase 2 instead.  This 
could be done by inserting the following between the third and fourth 
paragraphs of 9.1.2 Phase 2:

    If the AS_PATH attribute of a BGP route contains an AS loop, the
    BGP route should be excluded from the Phase 2 decision function.
    AS loop detection is done by scanning the full AS path (as
    specified in the AS_PATH attribute), and checking that the autonomous
    system number of the local system does not appear in the AS path.
    Operations of a router that is configured to accept routes with its
    own autonomous system number in the AS path are outside the scope of
    this document.

Section 9.3, first bullet, also addresses this topic, but I don't 
think it's sufficient.

--John


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA18803 for <[e-mail]>; Mon, 2 Dec 2002 10:53:17 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DF9F291206; Mon,  2 Dec 2002 10:52:55 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A96D291259; Mon,  2 Dec 2002 10:52:55 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9F37391206 for <[e-mail]>; Mon,  2 Dec 2002 10:52:54 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8262E5DDB8; Mon,  2 Dec 2002 10:52:54 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 1A3EC5E088 for <[e-mail]>; Mon,  2 Dec 2002 10:52:54 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gB2Fqqt74572; Mon, 2 Dec 2002 10:52:52 -0500 (EST) (envelope-from [e-mail])
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 gB2FqnC74565; Mon, 2 Dec 2002 10:52:49 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gB2Fqn314728; Mon, 2 Dec 2002 10:52:49 -0500 (EST)
Date: Mon, 2 Dec 2002 10:52:49 -0500
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: -18 last call comments
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Sat, Nov 30, 2002 at 04:46:57PM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Sat, Nov 30, 2002 at 04:46:57PM -0800, Yakov Rekhter wrote:
> 1772 is in the non-normative section. I think we could keep it there,
> and keep the references as well.

My concern is mostly that as we publish the BGP spec as an RFC
it'd be nice for it to refer to whatever replaces 1772.

I don't know how this is handled in practice, but I don't think its
a big deal.  I just thought it was worth bringing up.

> > Capitalization of magic words such as MUST and SHOULD should be done.
> 
> It should be done *as appropriate*. Therefore, if you think there
> are places where it is *appropriate* to do capitalization, please
> point them out.

Will do when I can find a few cycles.

> > Update message error subcode 7 is removed.  Especially in -18,
> > it looks like an editing mistake based on where it would fall
> > in the editing..
> 
> From Appendix A:
> 
>   UPDATE Message Error subcode 7 (AS Routing Loop) has been deprecated.

What I would like to see is something like this:

6 - Invalid ORIGIN Attribute
7 - [Deprecated - See Appendix A]
8 - Invalid NEXT_HOP Attribute


As it stands, 7 lies on a page boundary and looks like it got clipped
by the roff.

> > Reference to IDRP should be ISO10747 not IS10747.
> 
> No, it should be IS10747.

I'll take your word on this, however what I have on my shelf reads:
ISO/IEC DIS 10747: 1992

Which probably means I have a last-call version of the draft standard.

> Yakov.

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA17658 for <[e-mail]>; Mon, 2 Dec 2002 10:26:13 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1169591257; Mon,  2 Dec 2002 10:25:51 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D535691258; Mon,  2 Dec 2002 10:25:50 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BB00591257 for <[e-mail]>; Mon,  2 Dec 2002 10:25:49 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A20325E019; Mon,  2 Dec 2002 10:25:49 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 477825DDE0 for <[e-mail]>; Mon,  2 Dec 2002 10:25:49 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id gB2FPj473646; Mon, 2 Dec 2002 10:25:45 -0500 (EST) (envelope-from [e-mail])
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 gB2FPfC73634; Mon, 2 Dec 2002 10:25:41 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id gB2FPeO14605; Mon, 2 Dec 2002 10:25:40 -0500 (EST)
Date: Mon, 2 Dec 2002 10:25:40 -0500
From: Jeffrey Haas <[e-mail]>
To: Manav <[e-mail]>
Cc: [e-mail]
Subject: Re: -18 last call comments
Message-ID: <[e-mail]>
References: <00bf01c29a46$503abc50$8946d5a5@samsungy77z6fd>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <00bf01c29a46$503abc50$8946d5a5@samsungy77z6fd>; from [e-mail] on Mon, Dec 02, 2002 at 01:03:50PM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Manav,

On Mon, Dec 02, 2002 at 01:03:50PM -0800, Manav wrote:
> I understand that there can be situations when you receive your own AS
> number in the UPDATE message and the best course of action is to simply
> ignore it and proceed with the next set.

In the case of receiving your own AS number, this is fairly typical.

You may wish to search the archives for the thread on outbound 
as-loop detection.

> But I personally feel uncomfortable
> at simply ignoring UPDATE messages without doing anything else! 

This is a case of doing the thing that is least annoying to the user.
*Sure* you could log the messages, but in the above case, you'd 
end up saturating your logs with useless messages.

> I agree,
> that tearing down a  session based solely on one UPDATE message is rather
> unfair but isn't there something which we should do to inform our remote
> peer that it is sending us UPDATEs which have our AS nos in the AS Path.

But this is normal behavior.

If I have some route which I have selected as active, I will propagate
this route to you and prepend my AS number to the AS PATH.  Nothing
in the current protocol specification says that I should check the
outgoing AS Path to see if *your* AS number is in it before I send it 
to you.

Note that actually *doing* the outbound loop detection may speed
convergence and is completely interoperable with existing implementations.

> I remember there was a discussion going on some time back in this list over
> such non destructive messages (I think it was INFORM messages) and it
> somehow never clicked! Are we sure that we *don't* require any such
> mechanisms?

In this particular case, definitely not.

> Regards,
> Manav

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA16224 for <[e-mail]>; Mon, 2 Dec 2002 09:55:41 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B538A91255; Mon,  2 Dec 2002 09:55:14 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84E8691256; Mon,  2 Dec 2002 09:55:14 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 25A4791255 for <[e-mail]>; Mon,  2 Dec 2002 09:55:13 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0B6695E002; Mon,  2 Dec 2002 09:55:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 95DDB5DFCC for <[e-mail]>; Mon,  2 Dec 2002 09:55:12 -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 gB2EsYS39593; Mon, 2 Dec 2002 06:54:34 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
Cc: Alex Zinin <[e-mail]>, [e-mail]
Subject: Re: proxy: more comments on draft -18 
In-Reply-To: Your message of "Mon, 02 Dec 2002 17:23:28 +0530." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 02 Dec 2002 06:54:34 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Siva,

>     My comments are inline.
> 
> > > 
> > > Section 1, page 5: IGP definition - it's not clear from this
> > > definition whether IBGP would be considered an IGP?
> > 
> > any suggestion on how to improve the definition to clarify
> > this issue would be appreciated.
> 
>    IBGP is not a protocol, so is such a clarification really required ?

Just to add, a reader possessing a thorough understanding of
foundations of this work, including IP routing, and the referenced
documents wouldn't consider IBGP as an IGP.

>    If it will make things clearer for readers, however, how about a simple
> clarification along the lines of:
> 
>    The usage of BGP to distribute routing information within an AS does not
> fall under this definition of an IGP.
> 
> > 
> > > Section 3, page 7, para 4: Does RFC 1772 still represent 
> > the *planned*
> > > use of BGP?  Or the actual use?  Or something different from actual
> > > use?
> > 
> > Perhaps we should just take out references to 1772. 
> 
>   My opinion is this should stay, because it does act as pointer to useful
> information on this topic.

It will stay, but just in the reference section.

> > > Section 3, page 8, para 3 - "The hosts executing..."  This paragraph
> > > seems obsolete.
> > 
> > I'll take it out.
> 
>     Don't some route optimization vendors sell boxes that operate on this
> basis ?
> 
> > > Section 4.3, Page 14/15: all multi-byte length fields - 
> > network byte order
> 
>   Do you think it is useful to state once at the beginning of the document
> that all fields are considered to be in network order ?

I'll do this for the next revision.

> > > Section 4.4, Page 20:  - "BGP does not use any TCP-based keep-alive
> > > mechanism to determine if peers are reachable".  Is it worth noting
> > > that TCP may still timeout the connection even if TCP keepalives are
> > > turned off?
> > 
> > the text is fine as it is.
> 
>   I concur.
> 
> > 
> > > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC
> > > attribute is removed before..."  The first sentence is pretty nearly
> > > incomprehensible.
> > 
> > here is my attempt to clarify this:
> > 
> >   If a MULTI_EXIT_DISC attribute is removed before re-advertising a
> >   route into IBGP, then (prior to the removal) the MULTI_EXIT_DISC 
> >   attribute may only be considered in the comparison of EBGP learned
> >   routes; the attribute is then removed, and then the remaining EBGP
> >   learned routes may be compared to the remaining IBGP learned routes,
> >   without considering the MULTI_EXIT_DISC attribute for those EBGP
> >   learned routes whose MULTI_EXIT_DISC attribute will be removed   
> >   before advertising these routes to IBGP.
> > 
> > Any further suggestions on how to improve this would be appreciated.
> 
>   How about this:
> 
> %   If a MULTI_EXIT_DISC attribute is removed before re-advertising a
> %   route into IBGP, then comparison based on the MULT_EXIT_DISC
> %   attribute may (MUST?) be performed only among the EBGP learned routes.
> %   This comparison MUST be performed before the removal of the
> %   MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute must then
> %   be removed from those EBGP routes where such removal is required and
> %   which are still eligible. This is followed by comparison with IBGP
> %   learned routes.
> 
>     I think this reflects our objectives, which is:
> 
>     a) If MED is to be removed, compare EBGP routes based on the MED
> 
>     b) Then remove the MED
> 
>     c) Then do comparison with IBGP routes

If nobody would propose anything better, then I'll use your text in
the next revision.

> > > Section 9.3 - shouldn't this subsection be moved to the 
> > discussion of
> > > Phase 1 or Phase 2 of the decision process?  Or at least move it
> > > before Section 9.2.
> > 
> > I think it is fine where it is now.
> 
>   I concur.

Thanks for your comments.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA10739 for <[e-mail]>; Mon, 2 Dec 2002 07:48:43 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 563089122E; Mon,  2 Dec 2002 07:48:24 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C3E091251; Mon,  2 Dec 2002 07:48:24 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F1399122E for <[e-mail]>; Mon,  2 Dec 2002 07:47:56 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 144E55DFF0; Mon,  2 Dec 2002 07:47:56 -0500 (EST)
Delivered-To: [e-mail]
Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by segue.merit.edu (Postfix) with ESMTP id 4F99A5DE2A for <[e-mail]>; Mon,  2 Dec 2002 07:47:54 -0500 (EST)
Received: from Bemail06.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gB2ClhD12588; Mon, 2 Dec 2002 13:47:43 +0100
Received: from alcatel.be ([138.203.191.116]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.9a) with ESMTP id 2002120213474176:3576 ; Mon, 2 Dec 2002 13:47:41 +0100 
Message-ID: <[e-mail]>
Date: Mon, 02 Dec 2002 13:47:29 +0100
From: [e-mail]
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Manav <[e-mail]>
Cc: "John G. Scudder" <[e-mail]>, [e-mail]
Subject: Re: -18 last call comments
References: <00bf01c29a46$503abc50$8946d5a5@samsungy77z6fd>
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/02/2002 13:47:41, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.9a |January 7, 2002) at 12/02/2002 13:47:43, Serialize complete at 12/02/2002 13:47:43
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Manav wrote:

> > Right.  In fact this is nothing new.  The existence of the "AS
> > Routing Loop" error incorrectly implied that such an UPDATE was a
> > protocol violation, which it is not.
>
> I understand that there can be situations when you receive your own AS
> number in the UPDATE message and the best course of action is to simply
> ignore it and proceed with the next set. But I personally feel uncomfortable
> at simply ignoring UPDATE messages without doing anything else!

In case of VPNs, it seems that loop prevention based on  AS-path is sometimes
disabled and replaced by loop prevention based on 'site of origin' to make sure
that routes learned from a  site (via eBGP)  are not readvertised to that site.
(example of hub and spoke VPN architecture). In this case it seems that ignoring
the UPDATE is a fair thing to do.

regards,
 Hans De Vleeschouwer



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA08519 for <[e-mail]>; Mon, 2 Dec 2002 06:51:45 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 88BAF9122C; Mon,  2 Dec 2002 06:51:17 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E72691250; Mon,  2 Dec 2002 06:51:17 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C6BB39122C for <[e-mail]>; Mon,  2 Dec 2002 06:51:15 -0500 (EST)
Received: by segue.merit.edu (Postfix) id AD80A5DFEB; Mon,  2 Dec 2002 06:51:15 -0500 (EST)
Delivered-To: [e-mail]
Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id 223685DD8C for <[e-mail]>; Mon,  2 Dec 2002 06:51:14 -0500 (EST)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <YCXKTHJT>; Mon, 2 Dec 2002 17:29:25 +0530
Message-ID: <[e-mail]>
From: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
To: Yakov Rekhter <[e-mail]>, Alex Zinin <[e-mail]>
Cc: [e-mail]
Subject: RE: proxy: more comments on draft -18 
Date: Mon, 2 Dec 2002 17:23:28 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hello,

    My comments are inline.

> > 
> > Section 1, page 5: IGP definition - it's not clear from this
> > definition whether IBGP would be considered an IGP?
> 
> any suggestion on how to improve the definition to clarify
> this issue would be appreciated.

   IBGP is not a protocol, so is such a clarification really required ?

   If it will make things clearer for readers, however, how about a simple
clarification along the lines of:

   The usage of BGP to distribute routing information within an AS does not
fall under this definition of an IGP.

> 
> > Section 3, page 7, para 4: Does RFC 1772 still represent 
> the *planned*
> > use of BGP?  Or the actual use?  Or something different from actual
> > use?
> 
> Perhaps we should just take out references to 1772. 

  My opinion is this should stay, because it does act as pointer to useful
information on this topic.

>
> > Section 3, page 8, para 3 - "The hosts executing..."  This paragraph
> > seems obsolete.
> 
> I'll take it out.

    Don't some route optimization vendors sell boxes that operate on this
basis ?

> 
> > Section 4.3, Page 14/15: all multi-byte length fields - 
> network byte order

  Do you think it is useful to state once at the beginning of the document
that all fields are considered to be in network order ?

> 
> >  
> > Section 4.4, Page 20:  - "BGP does not use any TCP-based keep-alive
> > mechanism to determine if peers are reachable".  Is it worth noting
> > that TCP may still timeout the connection even if TCP keepalives are
> > turned off?
> 
> the text is fine as it is.

  I concur.

> 
> > Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC
> > attribute is removed before..."  The first sentence is pretty nearly
> > incomprehensible.
> 
> here is my attempt to clarify this:
> 
>   If a MULTI_EXIT_DISC attribute is removed before re-advertising a
>   route into IBGP, then (prior to the removal) the MULTI_EXIT_DISC 
>   attribute may only be considered in the comparison of EBGP learned
>   routes; the attribute is then removed, and then the remaining EBGP
>   learned routes may be compared to the remaining IBGP learned routes,
>   without considering the MULTI_EXIT_DISC attribute for those EBGP
>   learned routes whose MULTI_EXIT_DISC attribute will be removed   
>   before advertising these routes to IBGP.
> 
> Any further suggestions on how to improve this would be appreciated.

  How about this:

%   If a MULTI_EXIT_DISC attribute is removed before re-advertising a
%   route into IBGP, then comparison based on the MULT_EXIT_DISC
%   attribute may (MUST?) be performed only among the EBGP learned routes.
%   This comparison MUST be performed before the removal of the
%   MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute must then
%   be removed from those EBGP routes where such removal is required and
%   which are still eligible. This is followed by comparison with IBGP
%   learned routes.

    I think this reflects our objectives, which is:

    a) If MED is to be removed, compare EBGP routes based on the MED

    b) Then remove the MED

    c) Then do comparison with IBGP routes


> 
> > Section 9.3 - shouldn't this subsection be moved to the 
> discussion of
> > Phase 1 or Phase 2 of the decision process?  Or at least move it
> > before Section 9.2.
> 
> I think it is fine where it is now.

  I concur.


Siva
([e-mail])


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA15253 for <[e-mail]>; Sun, 1 Dec 2002 23:18:36 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id CDD929124E; Sun,  1 Dec 2002 23:18:17 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 997F39124F; Sun,  1 Dec 2002 23:18:17 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4869E9124E for <[e-mail]>; Sun,  1 Dec 2002 23:18:16 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 28DAE5DECE; Sun,  1 Dec 2002 23:18:16 -0500 (EST)
Delivered-To: [e-mail]
Received: from realname (unknown [203.254.224.25]) by segue.merit.edu (Postfix) with ESMTP id C90755DE74 for <[e-mail]>; Sun,  1 Dec 2002 23:18:15 -0500 (EST)
Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) id <[e-mail]> for [e-mail]; Mon, 02 Dec 2002 13:23:47 +0900 (KST)
Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 02 Dec 2002 13:23:47 +0900 (KST)
Received: from samsungy77z6fd ([165.213.70.137]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov  6 2002)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 02 Dec 2002 13:24:44 +0900 (KST)
Date: Mon, 02 Dec 2002 13:03:50 -0800
From: Manav <[e-mail]>
Subject: Re: -18 last call comments
To: "John G. Scudder" <[e-mail]>, [e-mail]
Message-id: <00bf01c29a46$503abc50$8946d5a5@samsungy77z6fd>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
Sender: [e-mail]
Precedence: bulk

> Right.  In fact this is nothing new.  The existence of the "AS
> Routing Loop" error incorrectly implied that such an UPDATE was a
> protocol violation, which it is not.

I understand that there can be situations when you receive your own AS
number in the UPDATE message and the best course of action is to simply
ignore it and proceed with the next set. But I personally feel uncomfortable
at simply ignoring UPDATE messages without doing anything else! I agree,
that tearing down a  session based solely on one UPDATE message is rather
unfair but isn't there something which we should do to inform our remote
peer that it is sending us UPDATEs which have our AS nos in the AS Path.
Some sort of no destructive CEASE message with an appropriate sub-code. I am
sure there can be plenty of other uses too!

I remember there was a discussion going on some time back in this list over
such non destructive messages (I think it was INFORM messages) and it
somehow never clicked! Are we sure that we *don't* require any such
mechanisms?

Just a thought.

Regards,
Manav






Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA13514 for <[e-mail]>; Sun, 1 Dec 2002 22:47:18 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1EC529124D; Sun,  1 Dec 2002 22:46:47 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C60B9124E; Sun,  1 Dec 2002 22:46:42 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 84E169124D for <[e-mail]>; Sun,  1 Dec 2002 22:46:28 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 588625DFC4; Sun,  1 Dec 2002 22:46:28 -0500 (EST)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id 8D63F5E085 for <[e-mail]>; Sun,  1 Dec 2002 22:46:27 -0500 (EST)
Received: from [192.168.42.10] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA26120; Sun, 1 Dec 2002 22:46:18 -0500 (EST)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05200f0bba10872ad660@[192.168.42.10]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sun, 1 Dec 2002 22:46:21 -0500
To: Mareline Sheldon <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: -18 last call comments
Cc: Yakov Rekhter <[e-mail]>, Jeffrey Haas <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 6:05 PM -0800 12/1/02, Mareline Sheldon wrote:
>Hi,
>>  From Appendix A:
>>
>>    UPDATE Message Error subcode 7 (AS Routing Loop) has been deprecated.
>
>Can you please tell me the reason why this subcode has been 
>deprecated? As i understand it means that if i now recieve this 
>UPDATE which carries the same AS as mine then i need not close the 
>session. I just need to ignore this particular UPDATE.

Right.  In fact this is nothing new.  The existence of the "AS 
Routing Loop" error incorrectly implied that such an UPDATE was a 
protocol violation, which it is not.

>Incidentally, i was doing some testing yesterday and was confused 
>with one major vendor's BGP implementation. It is accepting UPDATEs 
>which carry its own AS number in the AS-SET and advertises them to 
>its EBGP peers. It refuses these UPDATEs if it finds its own AS 
>number in the AS SEQ and does not advertise them to its EBGP 
>neighbors.
>
>AFAIK, a BGP implementation should check for its own AS nos. in both 
>the AS-SET and AS-SEQ. Am i missing something here?

What you describe sounds like a bug in the implementation to me.

--John


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA07615 for <[e-mail]>; Sun, 1 Dec 2002 21:05:38 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 10A5391249; Sun,  1 Dec 2002 21:05:12 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE59B9124B; Sun,  1 Dec 2002 21:05:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE0B691249 for <[e-mail]>; Sun,  1 Dec 2002 21:05:10 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 885325DDB3; Sun,  1 Dec 2002 21:05:10 -0500 (EST)
Delivered-To: [e-mail]
Received: from web20302.mail.yahoo.com (web20302.mail.yahoo.com [216.136.226.83]) by segue.merit.edu (Postfix) with SMTP id D30CF5DDF9 for <[e-mail]>; Sun,  1 Dec 2002 21:05:09 -0500 (EST)
Message-ID: <[e-mail]>
Received: from [165.213.1.1] by web20302.mail.yahoo.com via HTTP; Sun, 01 Dec 2002 18:05:08 PST
Date: Sun, 1 Dec 2002 18:05:08 -0800 (PST)
From: Mareline Sheldon <[e-mail]>
Subject: Re: -18 last call comments 
To: Yakov Rekhter <[e-mail]>, Jeffrey Haas <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Hi,
> From Appendix A:
> 
>   UPDATE Message Error subcode 7 (AS Routing Loop) has been deprecated.

Can you please tell me the reason why this subcode has been deprecated? As i understand it
means that if i now recieve this UPDATE which carries the same AS as mine then i need not
close the session. I just need to ignore this particular UPDATE.

Incidentally, i was doing some testing yesterday and was confused with one major vendor's BGP
implementation. It is accepting UPDATEs which carry its own AS number in the AS-SET and
advertises them to its EBGP peers. It refuses these UPDATEs if it finds its own AS number in
the AS SEQ and does not advertise them to its EBGP neighbors.

AFAIK, a BGP implementation should check for its own AS nos. in both the AS-SET and AS-SEQ. Am
i missing something here?

with regards,
mareline s.




__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA08806 for <[e-mail]>; Sun, 1 Dec 2002 12:17:12 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1028991247; Sun,  1 Dec 2002 12:16:54 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7278891249; Sun,  1 Dec 2002 12:16:53 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 04BDD91247 for <[e-mail]>; Sun,  1 Dec 2002 12:16:49 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D2C225E054; Sun,  1 Dec 2002 12:16:49 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 5B3265E02C for <[e-mail]>; Sun,  1 Dec 2002 12:16:49 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id gB1HGIS00373; Sun, 1 Dec 2002 09:16:18 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: [e-mail]
Subject: Re: proxy: more comments on draft -18 
In-Reply-To: Your message of "Sat, 30 Nov 2002 21:52:34 PST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sun, 01 Dec 2002 09:16:18 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Alex,

> Comments from another rtg-dir reviewer.
> May overlap with those already discussed--
> didn't check latest threads.
> 
> Thanks.
> 
> -- 
> Alex
> 
> Almost all of these are simple clarifications.
> 
> Section 1, page 5: IGP definition - it's not clear from this
> definition whether IBGP would be considered an IGP?

any suggestion on how to improve the definition to clarify
this issue would be appreciated.

> Section 3, page 7, para 4: Does RFC 1772 still represent the *planned*
> use of BGP?  Or the actual use?  Or something different from actual
> use?

Perhaps we should just take out references to 1772. 
  
> Section 3, page 8, para 3 - "The hosts executing..."  This paragraph
> seems obsolete.

I'll take it out.

> Section 4.1, page 11 - Length is in network byte order.

all the encodings are in network byte order. This applies not just
to the BGP spec, but to other protocols as well. 
  
> Section 4.2, page 12 - "My autonomous system" and "Hold time" are in
> network byte order.
> 
> Section 4.2, page 12 - Hold Time - what does a value of zero indicate?

if you read section 4.4 then you'll find that:

   If the negotiated Hold Time interval is zero, then periodic KEEPALIVE
   messages MUST NOT be sent.

> Section 4.2, page 13 - BGP Identifier - network byte order?  
>         "IP address" -> "IPv4 address"

I'll put at the beginning a sentence saying that in the context of
this document the term "IP address" means an IP Version 4 address.

> 
>         This section should probably comment on the globally
>         routable/uniqueness requirements of BGP ID.
> 
> Section 4.3, Page 14, para1, sentence 2 - "path attribute" -> "path
> attributes"

fixed.

> Section 4.3, Page 14/15: all multi-byte length fields - network byte order
> 
> Section 4.3, Page 16 - two byte extended length is in network byte order.
> 
> Section 4.3,Page 17, NEXT_HOP: "IP address" -> "IPv4 address"
>         Specify that this is 4 octets.
>         Reference here to multi-protocol extensions for IPv6 nexthop?

no.

>         RFC 2283 is unclear whether NEXT_HOP should always be included
>         when using multiprotocol extensions. Clarify this here?

It is already clarified in 2283bis.

> Section 4.3, Page 17/18 - MED and LocalPref:  
>         "non-negative" -> "unsigned" for consistency with elsewhere.
>         (non-negative might imply values > 2^31 cannot be used).

fixed.

> Section 4.3, Page 18 - AGGREGATOR:  "IP address" -> "IPv4 address".
> 
> Section 4.3, Page 19 - Prefix: "IP address" -> "IPv4 address"
>         Prefix: "enough trailing bits to" -> "the minimum number of 
>         trailing bits needed to"

fixed.

>  
> Section 4.4, Page 20:  - "BGP does not use any TCP-based keep-alive
> mechanism to determine if peers are reachable".  Is it worth noting
> that TCP may still timeout the connection even if TCP keepalives are
> turned off?

the text is fine as it is.

> Section 4.4, Page 20:
> KEEPALIVE message consists" -> "A KEEPALIVE message consists"

fixed.

> Section 5, Page 23: "The same attribute can not appear more than once
> with the Path Attributes field...".  Does this mean the same attribute
> type, or the same attribute type and value?

the former (the same attribute type).
  
> Section 5.1 "The usage of each BGP path attributes .." -> attribute

fixed.

> Section 5.1.3 "IP address" -> "IPv4 address"
> 
> "A BGP speaker must never advertise an address of a peer to that peer
> as a NEXT_HOP, for a route that the speaker is originating."
>   suggest replace this text with:
> "A route originated by a BGP speaker must never be advertised to a
> peer using an address of that peer as NEXT_HOP"

fixed.

> 
> Section 5.1.4: "A BGP speaker MUST IMPLEMENT a mechanism ... which
> allows the MULTI_EXIT_DISC to be removed from a route."  Might want to
> say that this is dangerous unless you received the route from an EBGP
> peer? 

I think we should keep the text as is.

> Section 5.1.5: "If it [LOCAL_PREF] is contained in an UPDATE message
> that is received from an external peer, then this attribute MUST be
> ignored by the receiving speaker, except for the case of BGP
> Confederations [RF3065]."
>  - "ignored" might be taken to mean that you don't process it for
>    decision, but that you propagate it to internal peers.  I might
>    write "silently removed" or something similar.

I think the text is ok as is.

> Section 5.1.5, para 2.  "set of AS" -> "set of ASs"

fixed.

> 
> Section 5.1.7: "IP address" -> "IPv4 address"
> 
> Secton 6.2: note that Data field is in network byte order.
> 
> Section 6.2, para 5: "IP host address" -> "IPv4 host address"
> 
> Section 6.3, wrt NEXT_HOP: "IP address" -> "IPv4 address"
> 
> Section 6.3: wrt NEXT_HOP semantic correctness: should we check that a
> NEXT_HOP is not a multicast or broadcast address?

I'll add to the definition of NEXT_HOP that it is a unicast address.
  
> Section 6.3, page 32, para 7:  "peer than sent" -> "peer that sent"

fixed.

> Section 6.3: "if any attribute appears more than once" - does this
> mean the same attribute type, or the same attribute type and value?

the former.

> Section 6.8 "Comparing BGP identifiers is done by treating them as
> (4-octet-long) unsigned integers".  Need to convert to host byte order
> before comparing.

fixed.

> Section 6.8, item 2:  "closes BGP connection" -> "closes the BGP connection"
> "accepts BGP connection" -> "accepts the BGP connection".

fixed.

> Section 9.1.2.2: item (c): in the explanation of neighborAS(n), it is
> unclear for IBGP connections how to determine "the neighbor AS from
> which the other IBGP speaker learned the route".  If this is really
> the leftmost entry in the AS path (or the local AS if the path is
> empty), the spec should explicitly say so.

fixed.

> Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC
> attribute is removed before..."  The first sentence is pretty nearly
> incomprehensible.

here is my attempt to clarify this:

  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
  route into IBGP, then (prior to the removal) the MULTI_EXIT_DISC 
  attribute may only be considered in the comparison of EBGP learned
  routes; the attribute is then removed, and then the remaining EBGP
  learned routes may be compared to the remaining IBGP learned routes,
  without considering the MULTI_EXIT_DISC attribute for those EBGP
  learned routes whose MULTI_EXIT_DISC attribute will be removed   
  before advertising these routes to IBGP.

Any further suggestions on how to improve this would be appreciated.

> Section 9.1.2.2 (d)
>      "d) If at least one of the candidate routes was received from an
>       external peer in a neighboring autonomous system, remove from con-
>       sideration all routes which were received from internal peers."
> For consistency with (c) and clarity, this might be reworded:
>      "d) If any of the candidate routes was learned via EBGP, remove
>      from consideration all routes which were learned by IBGP."

fixed.

> 
> Section 9.1.2.2 (e)
>      "cost (n) is better than cost (m)"
>      Given the definition of cost, it might be clearer to say 
>      "cost (n) is lower than cost (m)"

fixed.

> Section 9.1.2.2 (g)
>      "neighbor address" has not been defined.

I'll replace "neighbor address" with "peer address".

> Section 9.2.2.2, Page 70 (AGGREGATOR) - "All AGGREGATOR attributes of
>      all routes to be aggregated should be ignored."  
> 
>      Perhaps "ignored" is ambiguous here, and it's not clear whether
>      should is a SHOULD.  Suggest:
> 
>      "Any AGGREGATOR attributes from the routes to be aggregated MUST
>      NOT be included in the aggregated route."

fixed.

> Section 9.3 - shouldn't this subsection be moved to the discussion of
> Phase 1 or Phase 2 of the decision process?  Or at least move it
> before Section 9.2.

I think it is fine where it is now.

> 
> Appendix E, para 2: IP precedence has been deprecated.  Delete this
> paragraph, or replace with appropriate diffserv codepoint.

deleted.

> Security Considerations:
>    "BGP supports the ability to authenticate BGP messages by using BGP
>    authentication."
>    This sentence should be removed, and the Authentication Information
>    parameter has been deprecated.

Please see the recent e-mail exchange on the Security Considerations

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA04651 for <[e-mail]>; Sun, 1 Dec 2002 11:02:07 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 9C2FF9121B; Sun,  1 Dec 2002 11:01:53 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27AC391247; Sun,  1 Dec 2002 11:01:44 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DD0589121B for <[e-mail]>; Sun,  1 Dec 2002 11:01:22 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B25965DFA7; Sun,  1 Dec 2002 11:01:22 -0500 (EST)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 502645DE07 for <[e-mail]>; Sun,  1 Dec 2002 11:01:22 -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 gB1G0pS98632; Sun, 1 Dec 2002 08:00:51 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: [e-mail]
Subject: Re: proxy: comments on draft -18 
In-Reply-To: Your message of "Sat, 30 Nov 2002 21:49:14 PST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sun, 01 Dec 2002 08:00:51 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Alex,

> Sorry for late posting--been traveling.
> Below are comments from a rtg-dir reviewer.
> Thanks.
> 
> -- 
> Alex
> 
>         A few comments
> 
>         (i).    I agree with the concern voiced on the IDR list
>                 by Tom Petch (and possibly others), namely, that
>                 it appears that the FSM specification is
>                 inconsistent when describing the action that
>                 places a value in a MIB object when a
>                 NOTIFICATION is sent.  

See Jeff's reply to Tom on this topic.

>         (ii).   It might be useful for section 3 to describe the
>                 relationship between the various (conceptual)
>                 RIBs (Adj-RIB-In, Adj-RIB-Out, and Loc-RIB) and
>                 what we are currently calling a FIB. This,
>                 however, is not critical to the protocol
>                 specification. 

and therefore the text will stay as is.

>         (iii).  Page 23, 3rd paragraph says "The sender of an
>                 UPDATE message should order ..."
> 
>                 Is this "should" a "SHOULD" (in the RFC 2119
>                 sense)? Likewise section 5.1.2 (AS_PATH), section
>                 a): "the advertising speaker shall not
>                 modifiy..."
> 
>                 Actually, there seems to be a lot of use of the
>                 terms "shall" and "shall not" which are not
>                 capitalized, so it is unclear what the exact
>                 meaning is. "may" is also used in the same way. 

Will fix in the next revision.

Yakov.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA04887 for <[e-mail]>; Sun, 1 Dec 2002 00:53:40 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A444D91245; Sun,  1 Dec 2002 00:53:04 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6FD5591246; Sun,  1 Dec 2002 00:53:04 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 067CD91245 for <[e-mail]>; Sun,  1 Dec 2002 00:53:02 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D9B195DE96; Sun,  1 Dec 2002 00:53:02 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 5BE025DDA6 for <[e-mail]>; Sun,  1 Dec 2002 00:53:02 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18IN2L-000Im5-00 for [e-mail]; Sat, 30 Nov 2002 21:53:01 -0800
Date: Sat, 30 Nov 2002 21:52:34 -0800
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: proxy: more comments on draft -18
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Comments from another rtg-dir reviewer.
May overlap with those already discussed--
didn't check latest threads.

Thanks.

-- 
Alex

Almost all of these are simple clarifications.

Section 1, page 5: IGP definition - it's not clear from this
definition whether IBGP would be considered an IGP?

Section 3, page 7, para 4: Does RFC 1772 still represent the *planned*
use of BGP?  Or the actual use?  Or something different from actual
use?

Section 3, page 8, para 3 - "The hosts executing..."  This paragraph
seems obsolete.

Section 4.1, page 11 - Length is in network byte order.

Section 4.2, page 12 - "My autonomous system" and "Hold time" are in
network byte order.

Section 4.2, page 12 - Hold Time - what does a value of zero indicate?

Section 4.2, page 13 - BGP Identifier - network byte order?  
        "IP address" -> "IPv4 address"

        This section should probably comment on the globally
        routable/uniqueness requirements of BGP ID.

Section 4.3, Page 14, para1, sentence 2 - "path attribute" -> "path
attributes"

Section 4.3, Page 14/15: all multi-byte length fields - network byte order

Section 4.3, Page 16 - two byte extended length is in network byte order.

Section 4.3,Page 17, NEXT_HOP: "IP address" -> "IPv4 address"
        Specify that this is 4 octets.
        Reference here to multi-protocol extensions for IPv6 nexthop?

        RFC 2283 is unclear whether NEXT_HOP should always be included
        when using multiprotocol extensions. Clarify this here?

Section 4.3, Page 17/18 - MED and LocalPref:  
        "non-negative" -> "unsigned" for consistency with elsewhere.
        (non-negative might imply values > 2^31 cannot be used).

Section 4.3, Page 18 - AGGREGATOR:  "IP address" -> "IPv4 address".

Section 4.3, Page 19 - Prefix: "IP address" -> "IPv4 address"
        Prefix: "enough trailing bits to" -> "the minimum number of 
        trailing bits needed to"
 
Section 4.4, Page 20:  - "BGP does not use any TCP-based keep-alive
mechanism to determine if peers are reachable".  Is it worth noting
that TCP may still timeout the connection even if TCP keepalives are
turned off?
"
Section 4.4, Page 20:
KEEPALIVE message consists" -> "A KEEPALIVE message consists"

Section 5, Page 23: "The same attribute can not appear more than once
with the Path Attributes field...".  Does this mean the same attribute
type, or the same attribute type and value?

Section 5.1 "The usage of each BGP path attributes .." -> attribute

Section 5.1.3 "IP address" -> "IPv4 address"

"A BGP speaker must never advertise an address of a peer to that peer
as a NEXT_HOP, for a route that the speaker is originating."
  suggest replace this text with:
"A route originated by a BGP speaker must never be advertised to a
peer using an address of that peer as NEXT_HOP"

Section 5.1.4: "A BGP speaker MUST IMPLEMENT a mechanism ... which
allows the MULTI_EXIT_DISC to be removed from a route."  Might want to
say that this is dangerous unless you received the route from an EBGP
peer? 

Section 5.1.5: "If it [LOCAL_PREF] is contained in an UPDATE message
that is received from an external peer, then this attribute MUST be
ignored by the receiving speaker, except for the case of BGP
Confederations [RF3065]."
 - "ignored" might be taken to mean that you don't process it for
   decision, but that you propagate it to internal peers.  I might
   write "silently removed" or something similar.

Section 5.1.5, para 2.  "set of AS" -> "set of ASs"

Section 5.1.7: "IP address" -> "IPv4 address"

Secton 6.2: note that Data field is in network byte order.

Section 6.2, para 5: "IP host address" -> "IPv4 host address"

Section 6.3, wrt NEXT_HOP: "IP address" -> "IPv4 address"

Section 6.3: wrt NEXT_HOP semantic correctness: should we check that a
NEXT_HOP is not a multicast or broadcast address?

Section 6.3, page 32, para 7:  "peer than sent" -> "peer that sent"

Section 6.3: "if any attribute appears more than once" - does this
mean the same attribute type, or the same attribute type and value?

Section 6.8 "Comparing BGP identifiers is done by treating them as
(4-octet-long) unsigned integers".  Need to convert to host byte order
before comparing.

Section 6.8, item 2:  "closes BGP connection" -> "closes the BGP connection"
"accepts BGP connection" -> "accepts the BGP connection".

Section 9.1.2.2: item (c): in the explanation of neighborAS(n), it is
unclear for IBGP connections how to determine "the neighbor AS from
which the other IBGP speaker learned the route".  If this is really
the leftmost entry in the AS path (or the local AS if the path is
empty), the spec should explicitly say so.

Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC
attribute is removed before..."  The first sentence is pretty nearly
incomprehensible.

Section 9.1.2.2 (d)
     "d) If at least one of the candidate routes was received from an
      external peer in a neighboring autonomous system, remove from con-
      sideration all routes which were received from internal peers."
For consistency with (c) and clarity, this might be reworded:
     "d) If any of the candidate routes was learned via EBGP, remove
     from consideration all routes which were learned by IBGP."

Section 9.1.2.2 (e)
     "cost (n) is better than cost (m)"
     Given the definition of cost, it might be clearer to say 
     "cost (n) is lower than cost (m)"

Section 9.1.2.2 (g)
     "neighbor address" has not been defined.

Section 9.2.2.2, Page 70 (AGGREGATOR) - "All AGGREGATOR attributes of
     all routes to be aggregated should be ignored."  

     Perhaps "ignored" is ambiguous here, and it's not clear whether
     should is a SHOULD.  Suggest:

     "Any AGGREGATOR attributes from the routes to be aggregated MUST
     NOT be included in the aggregated route."

Section 9.3 - shouldn't this subsection be moved to the discussion of
Phase 1 or Phase 2 of the decision process?  Or at least move it
before Section 9.2.

Appendix E, para 2: IP precedence has been deprecated.  Delete this
paragraph, or replace with appropriate diffserv codepoint.

Security Considerations:
   "BGP supports the ability to authenticate BGP messages by using BGP
   authentication."
   This sentence should be removed, and the Authentication Information
   parameter has been deprecated.




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA04697 for <[e-mail]>; Sun, 1 Dec 2002 00:50:06 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A85CC91243; Sun,  1 Dec 2002 00:49:43 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DE5B91245; Sun,  1 Dec 2002 00:49:43 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3125891243 for <[e-mail]>; Sun,  1 Dec 2002 00:49:42 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 100555DE96; Sun,  1 Dec 2002 00:49:42 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id D80095DDA6 for <[e-mail]>; Sun,  1 Dec 2002 00:49:41 -0500 (EST)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 18IMz7-000Ign-00 for [e-mail]; Sat, 30 Nov 2002 21:49:41 -0800
Date: Sat, 30 Nov 2002 21:49:14 -0800
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: proxy: comments on draft -18
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Sorry for late posting--been traveling.
Below are comments from a rtg-dir reviewer.
Thanks.

-- 
Alex

        A few comments

        (i).    I agree with the concern voiced on the IDR list
                by Tom Petch (and possibly others), namely, that
                it appears that the FSM specification is
                inconsistent when describing the action that
                places a value in a MIB object when a
                NOTIFICATION is sent.  

        (ii).   It might be useful for section 3 to describe the
                relationship between the various (conceptual)
                RIBs (Adj-RIB-In, Adj-RIB-Out, and Loc-RIB) and
                what we are currently calling a FIB. This,
                however, is not critical to the protocol
                specification. 

        (iii).  Page 23, 3rd paragraph says "The sender of an
                UPDATE message should order ..."

                Is this "should" a "SHOULD" (in the RFC 2119
                sense)? Likewise section 5.1.2 (AS_PATH), section
                a): "the advertising speaker shall not
                modifiy..."

                Actually, there seems to be a lot of use of the
                terms "shall" and "shall not" which are not
                capitalized, so it is unclear what the exact
                meaning is. "may" is also used in the same way.