Re: Issue 18

[Mathew Richardson <[e-mail]>]

> [e-mail] <[e-mail]> [Fri, Jan 31, 2003 at 02:41:31PM -0800]:
>Although I don't want to extend the time this issue is still open, I have 
>to agree with mrr here.  The text, as it stands is not as clear as 
>the text mrr is proposing, or the text I proposed a while back.  Of the
>two alternates, I prefer mrr's text, since it states more clearly that
>the comparison is optional.  
>
>Is there any compelling reason NOT to go with one of these two?
>
>>  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
>>  route into IBGP, then if MULTI_EXIT_DISC comparisons are performed
>                    ^^^^^^^  "and if" better?

Yes, definitely.

>>  during tie-breaking, the routes that will have their MULTI_EXIT_DISC
>>  attributes removed before readvertisement in IGBP MUST be treated
>>  as having been received without a MULTI_EXIT_DISC attribute.
>
>
>or
>
>>  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
>>  route into IBGP, then comparison based on the received MULTI_EXIT_DISC
>>  attribute MAY still be performed.  If an implementation chooses to
>>  perform this comparison, then the comparison MUST be performed only
>>  among EBGP learned routes, and it MUST be performed before the removal
>>  of the MULTI_EXIT_DISC attribute.

<snip>

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 SAA13930 for <[e-mail]>; Fri, 31 Jan 2003 18:43:00 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8B5F49128E; Fri, 31 Jan 2003 18:42:34 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 52D3E9128F; Fri, 31 Jan 2003 18:42: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 2E8DE9128E for <[e-mail]>; Fri, 31 Jan 2003 18:42:33 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0E1075DF8F; Fri, 31 Jan 2003 18:42:33 -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 838A95DDDD for <[e-mail]>; Fri, 31 Jan 2003 18:42:32 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0VNgPF61980; Fri, 31 Jan 2003 18:42:25 -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 h0VNgLC61973; Fri, 31 Jan 2003 18:42:21 -0500 (EST) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id h0VNgLD23810; Fri, 31 Jan 2003 18:42:21 -0500 (EST)
Date: Fri, 31 Jan 2003 18:42:21 -0500
From: Mathew Richardson <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Issue 18
Message-ID: <[e-mail]>
References: <[e-mail]> <[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

> [e-mail] <[e-mail]> [Fri, Jan 31, 2003 at 02:41:31PM -0800]:
>Although I don't want to extend the time this issue is still open, I have 
>to agree with mrr here.  The text, as it stands is not as clear as 
>the text mrr is proposing, or the text I proposed a while back.  Of the
>two alternates, I prefer mrr's text, since it states more clearly that
>the comparison is optional.  
>
>Is there any compelling reason NOT to go with one of these two?
>
>>  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
>>  route into IBGP, then if MULTI_EXIT_DISC comparisons are performed
>                    ^^^^^^^  "and if" better?

Yes, definitely.

>>  during tie-breaking, the routes that will have their MULTI_EXIT_DISC
>>  attributes removed before readvertisement in IGBP MUST be treated
>>  as having been received without a MULTI_EXIT_DISC attribute.
>
>
>or
>
>>  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
>>  route into IBGP, then comparison based on the received MULTI_EXIT_DISC
>>  attribute MAY still be performed.  If an implementation chooses to
>>  perform this comparison, then the comparison MUST be performed only
>>  among EBGP learned routes, and it MUST be performed before the removal
>>  of the MULTI_EXIT_DISC attribute.

<snip>

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 RAA11715 for <[e-mail]>; Fri, 31 Jan 2003 17:45:13 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 42AA791261; Fri, 31 Jan 2003 17:44:36 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 105899128B; Fri, 31 Jan 2003 17:44: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 EE47391261 for <[e-mail]>; Fri, 31 Jan 2003 17:44:34 -0500 (EST)
Received: by segue.merit.edu (Postfix) id CBEAE5DFA9; Fri, 31 Jan 2003 17:44:34 -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 4016D5DE64 for <[e-mail]>; Fri, 31 Jan 2003 17:44:34 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id OAA00946; Fri, 31 Jan 2003 14:41:31 -0800 (PST)
Date: Fri, 31 Jan 2003 14:41:31 -0800
From: [e-mail]
To: Mathew Richardson <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: Issue 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 Fri, Jan 31, 2003 at 12:04:13PM -0500
Sender: [e-mail]
Precedence: bulk

Although I don't want to extend the time this issue is still open, I have 
to agree with mrr here.  The text, as it stands is not as clear as 
the text mrr is proposing, or the text I proposed a while back.  Of the
two alternates, I prefer mrr's text, since it states more clearly that
the comparison is optional.  

Is there any compelling reason NOT to go with one of these two?

>  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
>  route into IBGP, then if MULTI_EXIT_DISC comparisons are performed
                    ^^^^^^^  "and if" better?
>  during tie-breaking, the routes that will have their MULTI_EXIT_DISC
>  attributes removed before readvertisement in IGBP MUST be treated
>  as having been received without a MULTI_EXIT_DISC attribute.


or

>  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
>  route into IBGP, then comparison based on the received MULTI_EXIT_DISC
>  attribute MAY still be performed.  If an implementation chooses to
>  perform this comparison, then the comparison MUST be performed only
>  among EBGP learned routes, and it MUST be performed before the removal
>  of the MULTI_EXIT_DISC attribute.

Andrew


On Fri, Jan 31, 2003 at 12:04:13PM -0500, Mathew Richardson wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Date: Fri, 31 Jan 2003 12:04:13 -0500
> From: Mathew Richardson <[e-mail]>
> To: [e-mail]
> Cc: [e-mail], [e-mail]
> Subject: Issue 18
> In-Reply-To: <[e-mail]>
> User-Agent: Mutt/1.4i
> X-Virus-Scanned: by AMaViS perl-11
> Precedence: bulk
> X-Spam-Status: No, hits=-2.9 required=5.0
> 	tests=AWL,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,
> 	      SPAM_PHRASE_02_03,USER_AGENT,USER_AGENT_MUTT
> 	version=2.43
> X-OriginalArrivalTime: 31 Jan 2003 17:08:55.0107 (UTC) FILETIME=[6F8D8130:01C2C94B]
> 
> While in the process of writing this reply, I received Yakov's e-mail
> stating that the issue is closed.  I'm sending this along anyways,
> if only to make my position clear for the record (since I do think
> that the proposed wording is open to two different interpretations.)
> 
> > [e-mail] <[e-mail]> [Thu, Jan 30, 2003 at 03:31:13PM -0800]:
> 
> <snip>
> 
> >----------------------------------------------------------------------------
> >18) MED Removal Text
> >----------------------------------------------------------------------------
> 
> <snip>
> 
> >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
> 
> <snip>
> 
> I think my real disagreement is with this list of objectives.  In
> particular, I think the option to perform tie breaking as
> normal, treating routes whose MEDs will be removed as having been
> received without a MED, should be included.
> 
> Despite that, and despite assertions to the contrary, the most
> recently proposed text (other than mine ;)) is open to two
> interpretations:
> 
> <snip>
> 
> >Matthew responded to this with:
> >
> > I think this new text is ambiguous.
> >
> > >Here is the text that will go in the next version of the draft:
> > >
> > >  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
> > >  route into IBGP, then comparison based on the MULT_EXIT_DISC
> > >  attribute MAY be performed only among the EBGP learned routes.
> >
> > This could be taken to mean either that the comparison may be performed,
> > and if it's performed it must be performed only between EBGP learned
> > routes, or that the comparison must be performed, but it may be performed
> > only between EBGP learned routes.
> 
> <snip>
> 
> To clarify, what the "MAY" applies to is not clear.
> 
> It could apply to either the act of comparing, or it could apply to
> the exclusion of IBGP learned routes from the comparison.
> 
> Regardless, what I'd really like to see is something like:
> 
>  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
>  route into IBGP, then if MULTI_EXIT_DISC comparisons are performed
>  during tie-breaking, the routes that will have their MULTI_EXIT_DISC
>  attributes removed before readvertisement in IGBP MUST be treated
>  as having been received without a MULTI_EXIT_DISC attribute.
> 
> but if that's unacceptable, I'd be willing to settle for something like:
> 
>  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
>  route into IBGP, then comparison based on the received MULTI_EXIT_DISC
>  attribute MAY still be performed.  If an implementation chooses to
>  perform this comparison, then the comparison MUST be performed only
>  among EBGP learned routes, and it MUST be performed before the removal
>  of the MULTI_EXIT_DISC attribute.
> 
> <snip>
> 
> >Curtis replied to Yakov's message:
> >
> > Looks good to me.
> >
> > I see no need to change "This comparison MUST be performed before the
> > removal of the MULTI_EXIT_DISC attribute".  There is no implication
> > that MULTI_EXIT_DISC must be removed and the first sentence clearly
> > indicates that doing so is not required therefore no ambiguity.
> 
> The ambiguity is not whether MULTI_EXIT_DISC attributes must be
> removed or not, it's whther MULTI_EXIT_DISC comparison must be performed
> including the received MULTI_EXIT_DISC attributes (that will be
> removed).
> 
> <snip>
> 
> 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 QAA08737 for <[e-mail]>; Fri, 31 Jan 2003 16:39:09 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 7C3CE9125E; Fri, 31 Jan 2003 16:38:32 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4DF3E9128B; Fri, 31 Jan 2003 16:38: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 113209125E for <[e-mail]>; Fri, 31 Jan 2003 16:38:31 -0500 (EST)
Received: by segue.merit.edu (Postfix) id EBF9E5DEA2; Fri, 31 Jan 2003 16:38:30 -0500 (EST)
Delivered-To: [e-mail]
Received: from pengo.systems.pipex.net (pengo.systems.pipex.net [62.241.160.193]) by segue.merit.edu (Postfix) with ESMTP id 9DB8B5DE96 for <[e-mail]>; Fri, 31 Jan 2003 16:38:30 -0500 (EST)
Received: from tom3 (userbf78.uk.uudial.com [62.188.142.99]) by pengo.systems.pipex.net (Postfix) with SMTP id 603F14C0014D; Fri, 31 Jan 2003 21:36:57 +0000 (GMT)
Message-ID: <000a01c2c970$a62ecbc0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Tom Petch" <[e-mail]>, "Susan Hares" <[e-mail]>
Cc: "idr" <[e-mail]>, "andrew" <[e-mail]>
Subject: Re: bgp19 issue 13
Date: Fri, 31 Jan 2003 21:35:12 -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 and Andrew

In case you wondered, I sent this before I got the revised Issues 2.2
list.  Having now read the list, I still have the concern about
missing next state for Active state events 13, 14 and 17.

Issue 46 did also pick up the question of what state we go to from
Active event 17 and suggested Idle.  Yes fine, but it also said move
the discussion to 13.4 and I see nothing in 13.4 about it; so I fear
this may be lost.

Also, from the issues list, I see I never received Sue's last e-mail
on Issue 45, Connect state event 17 which I reference below.

Tom Petch
[e-mail]

-----Original Message-----
From: Tom Petch <[e-mail]>
To: Susan Hares <[e-mail]>
Cc: idr <[e-mail]>
Date: 31 January 2003 20:35
Subject: bgp19 issue 13


>Sue
>
>I am concerned we may lose part of issue 13; I raised this as there
>being seven places where the next state was missing (which I see as
>wrong for the FSM we have).
>
>Of the seven, I think two have consensus, three you have proposals
>outstanding but two may be slipping away.
>
>For Connect state, events 15/16 we have consensus ie stay in Connect
>state (issue 13.1)
>
>For Active state, events 15/16, we have consensus ie stay in Active
>state (issue 13.3)
>
>For Connect state event 14, you have proposed rejecting the
connection
>and awaiting the connect retry timer; I assume that this means stay
in
>Connect state (fine with me - issue 13.2)
>
>For Open Confirm event 18, Jeff proposed discarding the FSM, you
>suggested Idle state (I prefer Idle - issue 13.6)
>
>For Active state event 17 (TCP failure), you have asked implementors
>for Active v Idle (without much response on the list); I think rather
>that as and when we have consensus for Connect state event 17 (Issue
>45) where there was a next state but we have now refined that
>depending on the Open Delay timer, the logic we arrive at for Connect
>state may also apply to Active state for event 17.
>
>But that leaves two which still concern me (and which I think of as
>part of issue 13.4).
>
>Active state (waiting for a connection) event 13 (SYN received) I
>think we should respond as for the Connect state (ie send SYN-ACK)
and
>stay in Active state
>
>Active state event 14 (TCP connection invalid) I would go back to
Idle
>state - we haven't reached first base with this peer - but the
>alternative would be to stay put in Active (like we stay put in
>Connect for Connect state event 14).
>
>You have suggested events 13 and 14 be optional; fine, but we still
>need next states for them.
>
>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 PAA06114 for <[e-mail]>; Fri, 31 Jan 2003 15:35:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 14DE29128A; Fri, 31 Jan 2003 15:34:35 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF1FF9128D; Fri, 31 Jan 2003 15:34: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 A77F79128A for <[e-mail]>; Fri, 31 Jan 2003 15:33:12 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 87E795DE96; Fri, 31 Jan 2003 15:33:12 -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 5672E5DE35 for <[e-mail]>; Fri, 31 Jan 2003 15:33:12 -0500 (EST)
Received: from tom3 (usermg17.uk.uudial.com [62.188.122.3]) by shockwave.systems.pipex.net (Postfix) with SMTP id 721FF160010F8; Fri, 31 Jan 2003 20:33:10 +0000 (GMT)
Message-ID: <001901c2c967$bd0dae00$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Susan Hares" <[e-mail]>
Cc: "idr" <[e-mail]>
Subject: bgp19 issue 13
Date: Fri, 31 Jan 2003 20:30:24 -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 am concerned we may lose part of issue 13; I raised this as there
being seven places where the next state was missing (which I see as
wrong for the FSM we have).

Of the seven, I think two have consensus, three you have proposals
outstanding but two may be slipping away.

For Connect state, events 15/16 we have consensus ie stay in Connect
state (issue 13.1)

For Active state, events 15/16, we have consensus ie stay in Active
state (issue 13.3)

For Connect state event 14, you have proposed rejecting the connection
and awaiting the connect retry timer; I assume that this means stay in
Connect state (fine with me - issue 13.2)

For Open Confirm event 18, Jeff proposed discarding the FSM, you
suggested Idle state (I prefer Idle - issue 13.6)

For Active state event 17 (TCP failure), you have asked implementors
for Active v Idle (without much response on the list); I think rather
that as and when we have consensus for Connect state event 17 (Issue
45) where there was a next state but we have now refined that
depending on the Open Delay timer, the logic we arrive at for Connect
state may also apply to Active state for event 17.

But that leaves two which still concern me (and which I think of as
part of issue 13.4).

Active state (waiting for a connection) event 13 (SYN received) I
think we should respond as for the Connect state (ie send SYN-ACK) and
stay in Active state

Active state event 14 (TCP connection invalid) I would go back to Idle
state - we haven't reached first base with this peer - but the
alternative would be to stay put in Active (like we stay put in
Connect for Connect state event 14).

You have suggested events 13 and 14 be optional; fine, but we still
need next states for them.

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 MAA28036 for <[e-mail]>; Fri, 31 Jan 2003 12:09:19 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 626DC9127B; Fri, 31 Jan 2003 12:04:31 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A285E91280; Fri, 31 Jan 2003 12:04: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 49E8F91284 for <[e-mail]>; Fri, 31 Jan 2003 12:04:19 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 26D3D5DE20; Fri, 31 Jan 2003 12:04:19 -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 6A7D95DDA4 for <[e-mail]>; Fri, 31 Jan 2003 12:04:18 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0VH4Gn51776; Fri, 31 Jan 2003 12:04:16 -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 h0VH4DC51768; Fri, 31 Jan 2003 12:04:13 -0500 (EST) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id h0VH4Dw06411; Fri, 31 Jan 2003 12:04:13 -0500 (EST)
Date: Fri, 31 Jan 2003 12:04:13 -0500
From: Mathew Richardson <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Issue 18
Message-ID: <[e-mail]>
References: <[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

While in the process of writing this reply, I received Yakov's e-mail
stating that the issue is closed.  I'm sending this along anyways,
if only to make my position clear for the record (since I do think
that the proposed wording is open to two different interpretations.)

> [e-mail] <[e-mail]> [Thu, Jan 30, 2003 at 03:31:13PM -0800]:

<snip>

>----------------------------------------------------------------------------
>18) MED Removal Text
>----------------------------------------------------------------------------

<snip>

>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

<snip>

I think my real disagreement is with this list of objectives.  In
particular, I think the option to perform tie breaking as
normal, treating routes whose MEDs will be removed as having been
received without a MED, should be included.

Despite that, and despite assertions to the contrary, the most
recently proposed text (other than mine ;)) is open to two
interpretations:

<snip>

>Matthew responded to this with:
>
> I think this new text is ambiguous.
>
> >Here is the text that will go in the next version of the draft:
> >
> >  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
> >  route into IBGP, then comparison based on the MULT_EXIT_DISC
> >  attribute MAY be performed only among the EBGP learned routes.
>
> This could be taken to mean either that the comparison may be performed,
> and if it's performed it must be performed only between EBGP learned
> routes, or that the comparison must be performed, but it may be performed
> only between EBGP learned routes.

<snip>

To clarify, what the "MAY" applies to is not clear.

It could apply to either the act of comparing, or it could apply to
the exclusion of IBGP learned routes from the comparison.

Regardless, what I'd really like to see is something like:

 If a MULTI_EXIT_DISC attribute is removed before re-advertising a
 route into IBGP, then if MULTI_EXIT_DISC comparisons are performed
 during tie-breaking, the routes that will have their MULTI_EXIT_DISC
 attributes removed before readvertisement in IGBP MUST be treated
 as having been received without a MULTI_EXIT_DISC attribute.

but if that's unacceptable, I'd be willing to settle for something like:

 If a MULTI_EXIT_DISC attribute is removed before re-advertising a
 route into IBGP, then comparison based on the received MULTI_EXIT_DISC
 attribute MAY still be performed.  If an implementation chooses to
 perform this comparison, then the comparison MUST be performed only
 among EBGP learned routes, and it MUST be performed before the removal
 of the MULTI_EXIT_DISC attribute.

<snip>

>Curtis replied to Yakov's message:
>
> Looks good to me.
>
> I see no need to change "This comparison MUST be performed before the
> removal of the MULTI_EXIT_DISC attribute".  There is no implication
> that MULTI_EXIT_DISC must be removed and the first sentence clearly
> indicates that doing so is not required therefore no ambiguity.

The ambiguity is not whether MULTI_EXIT_DISC attributes must be
removed or not, it's whther MULTI_EXIT_DISC comparison must be performed
including the received MULTI_EXIT_DISC attributes (that will be
removed).

<snip>

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 LAA27359 for <[e-mail]>; Fri, 31 Jan 2003 11:51:15 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 0742A9127D; Fri, 31 Jan 2003 11:49:38 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 69D4F9127B; Fri, 31 Jan 2003 11:47:06 -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 EEBC991260 for <[e-mail]>; Fri, 31 Jan 2003 11:46:55 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D1B1A5DF31; Fri, 31 Jan 2003 11:46:55 -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 632D75DDA4 for <[e-mail]>; Fri, 31 Jan 2003 11:46:55 -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 h0VGklS18664; Fri, 31 Jan 2003 08:46:47 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: issue 18 
In-Reply-To: Your message of "Tue, 21 Jan 2003 21:38:10 EST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 31 Jan 2003 08:46:47 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Curtis,

> > Here is the text that will go in the next version of the draft:
> > 
> >   If a MULTI_EXIT_DISC attribute is removed before re-advertising a
> >   route into IBGP, then comparison based on the MULT_EXIT_DISC
> >   attribute MAY be performed only among the EBGP learned routes.
> >   This comparison MUST be performed before the removal of the
> >   MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute is then
> >   removed from those EBGP routes where such removal is required and
> >   which are still eligible. This is followed by comparison with
> >   IBGP learned routes. 
> > 
> > Yakov.
> 
> 
> Looks good to me.
> 
> I see no need to change "This comparison MUST be performed before the
> removal of the MULTI_EXIT_DISC attribute".  There is no implication
> that MULTI_EXIT_DISC must be removed and the first sentence clearly
> indicates that doing so is not required therefore no ambiguity.
> Adding a "If a MULTI_EXIT_DISC attribute is removed" to the second
> sentence would be redundant.

with this in mind, and taking into account the absence of any objections 
since your posting the issue is closed (no changes to the text).

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 HAA18210 for <[e-mail]>; Fri, 31 Jan 2003 07:55:51 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 4B0059125F; Fri, 31 Jan 2003 07:55:13 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16A7291260; Fri, 31 Jan 2003 07:55: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 9CEA29125F for <[e-mail]>; Fri, 31 Jan 2003 07:55:08 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8B8EF5DF42; Fri, 31 Jan 2003 07:55:08 -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 08E9D5DE43 for <[e-mail]>; Fri, 31 Jan 2003 07:55:08 -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 HAA05013; Fri, 31 Jan 2003 07:51:34 -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-restart-06.txt
Date: Fri, 31 Jan 2003 07:51:34 -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		: Graceful Restart Mechanism for BGP
	Author(s)	: S. Ramachandra, Y. Rekhter, R. Fernando, J. Scudder
	Filename	: draft-ietf-idr-restart-06.txt
	Pages		: 10
	Date		: 2003-1-30
	
This document proposes a mechanism for BGP that would help minimize
the negative effects on routing caused by BGP restart. An End-of-RIB
marker is specified and can be used to convey routing convergence
information.  A new BGP capability, termed 'Graceful Restart
Capability', is defined which would allow a BGP speaker to express
its ability to preserve forwarding state during BGP restart. Finally,
procedures are outlined for temporarily retaining routing information
across a TCP transport reset.
The mechanisms described in this document are applicable to all
routers, both those with the ability to preserve forwarding state
during BGP restart and those without (although the latter need to
implement only a subset of the mechanisms described in this
document).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-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-restart-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-restart-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-restart-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-restart-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 HAA18189 for <[e-mail]>; Fri, 31 Jan 2003 07:55:25 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E217C9125D; Fri, 31 Jan 2003 07:55:04 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADC6C9125F; Fri, 31 Jan 2003 07:55: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 62C239125D for <[e-mail]>; Fri, 31 Jan 2003 07:55:03 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 46B905DE43; Fri, 31 Jan 2003 07:55:03 -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 C38EA5DFA8 for <[e-mail]>; Fri, 31 Jan 2003 07:55:02 -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 HAA04995; Fri, 31 Jan 2003 07:51:28 -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-08.txt
Date: Fri, 31 Jan 2003 07:51:28 -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)	: Y. Rekhter et al.
	Filename	: draft-ietf-idr-route-filter-08.txt
	Pages		: 11
	Date		: 2003-1-30
	
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-08.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-08.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-08.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-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-route-filter-08.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 SAA23385 for <[e-mail]>; Thu, 30 Jan 2003 18:39:11 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1BF12912F2; Thu, 30 Jan 2003 18:36:52 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3766A912ED; Thu, 30 Jan 2003 18:34: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 1205E912EA for <[e-mail]>; Thu, 30 Jan 2003 18:34:13 -0500 (EST)
Received: by segue.merit.edu (Postfix) id DB1575DE5D; Thu, 30 Jan 2003 18:34:12 -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 C5EBD5DDF3 for <[e-mail]>; Thu, 30 Jan 2003 18:34:10 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id PAA14261; Thu, 30 Jan 2003 15:31:13 -0800 (PST)
Date: Thu, 30 Jan 2003 15:31:13 -0800
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: BGP Base Draft - Issue List v2.2 (Draft-19)
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: [e-mail]
Precedence: bulk

--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Greetings,

Attached is the latest copy of the issues list.  We've done a lot of work
since the 2.1 version came out.  We've updated 22 issues, and brought
12 to consensus.  We have 10 issues remaining with open discussion,
and some of those are close.

Andrew

--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="Issue_List-v2.2.txt"

2003-01-30
v2.2

This is version 2.2 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.
12) Entering OpenConfirm / Adding "Stop OpenDelay" action
13) FSM Missing Next States
13.1) FSM Missing Next States - Event 15 or 16 (Connect State)
13.2) FSM Missing Next States - Event 14 (Connect State)
13.3) FSM Missing Next States - Event 15 or 16 (Active State)
13.4) FSM Missing Next States - Event 13-17 (TCP Connection)
13.5) FSM Missing Next States - Event 17 (Connect State)
13.6) FSM Missing Next States - Event 18 (Open Confirm)
14) FSM - Peer Oscillation Damping
15) FSM - Consistent FSM Event Names
16) Many Editorial Comments
17) Section 3, Page 8, Paragraph 3 - Obsolete?
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
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)
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
43) Handling the default events 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
53) Established State MIB
55) New DelayOpen State

============================================================================
Issues WITHOUT Consensus
============================================================================
18) MED Removal Text
24) Events 3, 5, 6 & 7 Give Examples
26) Event 4 & 5 - bgp_stop_flap option
33) Event 13 & 14 - Valid Addresses & Ports
41) Handling of Event 14 in the Connect State
42) Handling events 20, 21 in the Connect State and Active State
44) Handling Event 23 in Connect and OpenSent
45) Event 17 in the Connect state
52) Handling Event 18 in the OpenSent state (Keepalive Timer)
54) State impact of not supporting Optional Events

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

Discussion:

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

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

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

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

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

Discussion:

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

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

Jeff replied with a master diff showing the MUST/SHOULDs, for the entire
document please see the beginning of the thread entitled: 
"Issues list, #2: MUST/SHOULD Capitalization"

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

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

Discussion:

Jeff supplied:

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

Yakov mentioned that this is addressed in Appendix A.

Jeff replied:

 What I would like to see is something like this:

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

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

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

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

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

Discussion:

Jeff proposed an editorial fix.  This is agreed to.

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

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

Discussion:

Jeff proposed:

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

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

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

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

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

Discussion:

John brought this up, and suggested:

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

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

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

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

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

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

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

We are at consensus on this issue.

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

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

Discussion:

Tom proposed:

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

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

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

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

Discussion:

Tom pointed out that:

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

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

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

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

Discussion:

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

        - deletes all routes associated with this connection,

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

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

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

Discussion:

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

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

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

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

Discussion:

Tom pointed out that:

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

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

 OpenSent is for Open sent and not yet received.

 The corresponding section in Connect state I believe is correct.

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

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

----------------------------------------------------------------------------
12) Entering OpenConfirm / Adding "Stop OpenDelay" action
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add this text:

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

 new Text:

     In response to the connect retry timer expires event [Event
     9], the local system:
        - drops the TCP connection,
        - restarts the connect retry timer,
        - stops the Open Delay timer and resets the timer to zero,
        - initiates a TCP connection to the other BGP peer,
        - continues to listen for a connection that may be
          initiated by the remote BGP peer, and
        - stays in Connect state.


     If the TCP connection fails [Event17], the local system:
         - restarts the connect retry timer,
         - stops the Open Delay timer and resets value to zero,
         - continues to listen for a connection that may be
           initiated by the remote BGP peer, and
         - changes its state to Active.

  Further discussion on Keepalives has been moved to issue 52.

Discussion:

This discussion began with Tom outlining these two points:

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

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

Sue replied:

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

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

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

 Case 2: - should see Event 19

        - Open, Keepalive should be sent.

 Previous text: (Action H from FSM document)

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

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

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

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

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

By way of clarification, Sue added:

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

 Background:

 The state machine for Event 19 is:  

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

 Per the State Machine.

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

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

        Please answer this separately.

Tom replied that:

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

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

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

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

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

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

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

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

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

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

 in order to stop event 19 in Open Sent

Sue replied that, she thought this was at consensus, and provided the
new text, which is:

 Change 1:  new text

 Active state - event 19

    If an Open is received with the Open Delay timer is
    running [Event 19], the local system   
        - clears the connect retry timer (cleared to zero),
        - stops and clears the Open Delay timer
        - completes the BGP initialization,
        - stops and clears the Open Delay timer
        - sends an OPEN message, 
        - send a Keepalive message,
        - if the hold timer value is non-zero,
                - starts the keepalive timer to initial value,
                - resets the hold timer to the negotiated value,
          else if the hold timer is zero
                - resets the keepalive timer (set to zero),
                - resets the hold timer to zero.

        - changes its state to OpenConfirm.

    If the value of the autonomous system field is the same as the local
    Autonomous System number, set the connection status to an internal
    connection; otherwise it is "external".
      
 Change 2 -
  Connect state
  event 17 (currently defined as going to Active)
  event 9 (stays in Connect state)

 new Text:

     In response to the connect retry timer expires event [Event
     9], the local system:
        - drops the TCP connection,
        - restarts the connect retry timer,
        - stops the Open Delay timer and resets the timer to zero,
        - initiates a TCP connection to the other BGP peer,
        - continues to listen for a connection that may be
          initiated by the remote BGP peer, and
        - stays in Connect state.
        
        
     If the TCP connection fails [Event17], the local system: 
         - restarts the connect retry timer,
         - stops the Open Delay timer and resets value to zero,
         - continues to listen for a connection that may be
           initiated by the remote BGP peer, and
         - changes its state to Active.

Tom replied that:

 Change 2, stop Open Delay timer in Connect state events 9 and 17,
 fine; that is what I understand to be the real issue 12.

 Change 1, event 19 in Active state, is IMHO issues 47 and 52.  This is
 tangled because the initial paragraphs of Issue 12 in the issue list
 are nothing to to with stopping Open Delay timer and everything to to
 with sending a Keepalive message before entering Open Confirm state
 from Active or Connect state on event 19; which I raised and see as
 issue 52.  Issue 47 was Siva's issue 28 and relates to a different
 action for Active state event 19.

 I agree with change 1 in that it adds in the sending of Keepalive
 which I believe essential; I think Siva needs to respond concerning
 issue 47.  (nb the stop Open Delay action is duplicated)  I wonder if
 we should use a different character for the bullet points under the if
 and else clauses to make it clear where they end ie
 - if the hold timer ....
 + do this
 + and this
   else if ...
 + do the other
 + and this

 But I still have an issue for Connect state event 19 where I believe,
 as for Active state event 19, we should send a Keepalive and start the
 Keepalive timer.  I will pursue this as part of issue 52 if that suits
 you.  I think the text will be the same as whatever we agree for
 Active state event 19.

This was discussed in the "bgp 18 WG Last Call fsm missing keepalive" thread.
And also in the "Event 19 in Open Sent state was Re: bgp18 WG Last Call 
fsm missing keepalive" thread.  This also came up in the "issues 12 -
consensus & two changes - 2nd message" thread.

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

Discussion:

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

All sub-issues are at consensus.

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

Discussion:

Tom pointed out that:

      Connect State:

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

Sue proposed these changes:

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

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


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

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

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

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

----------------------------------------------------------------------------
13.2) FSM Missing Next States - Event 14 (Connect State)
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: We selected option 2 from discussion as the correct text:

   2) treat it as an invalid response, reject the connection and see
      if a valid configured one comes iwthin the connect timer's window.

Discussion:

Tom pointed out that:

      Connect State:

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

Sue proposed these alternatives:

 2)Connect State - Event 14  [no consensus]

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

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

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

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

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

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

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

Sue prodded the list saying that:

 Should the peer:
   1) Treat it as a valid response, and enters the active state
      to watch for a another TCP connection with a valid peer.

   2) treat it as an invalid response, reject the connection and see 
      if a valid configured one comes iwthin the connect timer's window.

 Without further input, I will select option 2.

Curtis replied that this was fine with him.

There has been no further disagreement, we are at consensus on this.

This conversation was started in the "bgp18 WG Last Call fsm missing next
state" thread.  It was also discussed in the "BGP draft-19 - FSM input
needed from developers" thread.

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

Discussion:

Tom pointed out:

      Active State:

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

Sue proposed these changes:

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

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

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

Tom agreeded with this.

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

----------------------------------------------------------------------------
13.4) FSM Missing Next States - Event 13-17 (TCP Connection)
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: We selected:

   Choice 2:  Event 13 and Event 14 be optional, and Events 15 - 17
              be mandatory.

Discussion:

Tom started this by saying that:

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

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

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

The response in this thread was:

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

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

Sue polled the implemtentors on the list with this query:

 These events are described in section 8.1.3.

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


 Events 13 - 17  

        Event 13 - TCP connection indication & valid
                   remote peer

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

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

        Event 16 - TCP connection confirmed

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

        Event 17 - TCP connections

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

The full FSM text was snipped here for brevity.

Sue prodded the list with:

 Do the implementors require Events 13 - 17 in the State machine ?

   Event 13 - TCP connection valid indication
   Event 14 - TCP connection invalid indication
   Event 15 - TCP connection request acknowedged
   Event 16 - TCP connection confirmed
   Event 17 - TCP connection fails

   Choice 1:  Events 13 - 17 are mandatory
   Choice 2:  Event 13 and Event 14 be optional, and Events 15 - 17 
              be mandatory.
 
 If no one objects, we will use Choice 2.

Curtis said this was fine with him.

There has been no further disagreement, we are at consensus on this.
                
This was started in the "bgp18 WG Last Call fsm missing next
state" thread.	And continued in the "fsm missing next state - Events 13-17
and the TCP connection" thread.  It was also discussed in the "BGP draft-19 
- FSM input needed from developers" thread.
 
----------------------------------------------------------------------------
13.5) FSM Missing Next States - Event 17 (Connect State)
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Closed in favor of 13.4

Discussion:


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

Sue replied with this:

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

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

 Alternative 1:


 FSM table new:

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

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

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

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

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

After the issues list came out Tom responded to this issue, saying:

 I think this issue SHOULD be administratively terminated.
     
 It relates to Connect state Event 17 (TCP connection fails) and I am
 credited with raising it; in fact, the issue I raised was missing next
 state for Active state event 17 and this has now been subsumed into
 13.4 (but note that 13.4 does not explicitly say Active state - I know
 it should because I raised that issue too).  I will ensure it does not
 get lost from any resolution of 13.4.
     
 And Connect state event 17 does appear as part of issue 45 which Siva
 raised so I think that either way, 13.5 can go.

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

----------------------------------------------------------------------------
13.6) FSM Missing Next States - Event 18 (Open Confirm)
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: This is the text:

 In the Open Confirm state, a valid Open message [Event 22] is received.
 The BGP Peer connection is check to ee if there is a collision per
 section 6.8.  If this connection is to be dropped due to the call
 collision, the local system will drop the call by:

   - sending a NOTIFICATION with a CEASE,
   - resets the Connect timer (to zero),
   - releases all BGP resources (this includes stopping the Open Delay Timer
       and reseting it to zero),
   - increments the ConnectRetryCnt by 1 (connect retry +count), and
   - optionally performs a BGP peer oscilation damping processing, and
   - enters the Idle State.

Discussion:
        
Tom opened this with:

      Open Confirm State:

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

Sue replied with:

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

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

Tom replied:

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

Sue replied:

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

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

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

Sue prodded the list with:

 In the Open Confirm state, a valid Open message [Event 22] is received.
 The BGP Peer connection is check to ee if there is a collision per
 section 6.8.  If this connection is to be dropped due to the call 
 collision, the local system will drop the call by:

   - sending a NOTIFICATION with a CEASE,
   - resets the Connect timer (to zero),
   - releases all BGP resources (this includes stopping the Open Delay Timer 
       and reseting it to zero),
   - increments the ConnectRetryCnt by 1 (connect retry +count), and
   - optionally performs a BGP peer oscilation damping processing, and
   - enters the Idle State.
   
 Implementors need to verify if this text and the text for Event 22
 allows all implementors to perform the necessary Call Collision actions.
 
 If no objects, we will use this text.

Curtis said he had no problem with this.

There has been no disagreement, we are at consensus with this.

This conversation was started in the "bgp18 WG Last Call fsm missing next 
state" thread. It was also discussed in the "BGP draft-19 - FSM input needed 
from developers" thread.

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

Discussion:

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

Yakov agreed to fix both of these.

----------------------------------------------------------------------------
15) FSM - Consistent FSM Event Names
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Make FSM names consistent.  Specifics are in the discssion section.

Discussion:

Tom proposed that:

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

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

 8. BGP Finite State machine

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

 8.2.2 Finite State Machine

      Connect State:

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

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

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

      Active State:

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

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

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

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

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

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

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

Sue replied:

 I will accept the text you proposed for the Event names.
 I will update the FSM text to include your changes.
    
 We'll consider issue 15 in consensus.  I've fixed the text.

So we are at consensus here.

This is discussed in the thread: "bgp18 WG Last Call fsm event names."  It
was also discussed in the "Issue 15 - Consistent FSM Event Names" thread.

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

Discussion:

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

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

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

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

 Perhaps we should just take out references to 1772.

Further discussion seemed to indicate that this reference should stay.

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

 I'll take it out.

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

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

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

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

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

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

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

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

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

 fixed.

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

 no.

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

 It is already clarified in 2283bis.

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

 fixed.

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

 the text is fine as it is.

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

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

 the former (the same attribute type).

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

 fixed.

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

 fixed.

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

 think we should keep the text as is.

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

 I think the text is ok as is.

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

 fixed.

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

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

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

 fixed.

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

 the former.

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

 fixed.

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

 fixed.

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

 fixed.

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

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

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

 fixed.

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

 fixed.

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

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

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

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

 I think it is fine where it is now.

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

 deleted.

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

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

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

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

----------------------------------------------------------------------------
17) Section 3, Page 8, Paragraph 3 - Obsolete?
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Leave the current definition of BGP Speaker, and normalize the
 text to use "BGP Speaker" instead of router.

Discussion:

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

Anonymous reviwer:

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

Yakov:

 I'll take it out.

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

Jeff replied:

 To provide context, this paragraph currently reads:

 :   The hosts executing BGP need not be routers.  A non-routing host
 :   could exchange routing information with routers via EGP [RFC904] or
 :   even an interior routing protocol. That non-routing host could then
 :   use BGP to exchange routing information with a border router in
 :   another Autonomous System. The implications and applications of this
 :   architecture are for further study.  
  
 There are several deployed entities that could be considered to "exploit"
 this paragraph.  Route collectors, route servers, bandwidth shapers
 and other optimizers.  However, the original text may be showing its
 age a little bit.

 Perhaps the following might be a bit more appropriate:

 "The hosts executing BGP need not be routers.  A non-routing host may 
  exchange routing information with a BGP speaker for reasons
  that are outside the scope of this document."
 
 I would also propose adding to the same paragraph (but could be persuaded
 to drop it since it is *logically* redundant):
 "These non-routing hosts should exercise great care not to insert
  themselves into the forwarding path if they re-announce BGP routes."

Yakov replied:

 Since operations of non-routing host are outside the scope of the
 document, and since the document doesn't preclude non-routing hosts
 to run BGP, I would prefer just to take the following paragraph out,
 and not to add any new text.

   The hosts executing BGP need not be routers.  A non-routing host
   could exchange routing information with routers via EGP [RFC904] or
   even an interior routing protocol. That non-routing host could then
   use BGP to exchange routing information with a border router in
   another Autonomous System. The implications and applications of this  
   architecture are for further study.

Jeff replied that this was ok, and instead suggested:

At the beginning of the document, we define:
   BGP speaker
         A router that implements BGP.

 This (potentially) restricts a speaker to being a router.
 Additionally, several spots in the text where we probably should
 say "BGP speaker", we use router.   

Yakov agreed to add this definition.

Jeff replied that there still was a problem with this definition being
too limiting.  The discussion meandered off list for a couple of 
exchanges and these additional definitions were proposed:

First Jeff proposed this:

 "A router that implements the BGP protocol.
  Non-routing hosts that also implement BGP are out of scope of this
  document."

Then Andrew replied, that we should make sure the definition does not
opt out entirely from making sure that non-routing hosts are interoperable:

BGP Speaker
    A router that implements the BGP protocol.  The internal behavior of
    non-routing hosts that also implement BGP are out of scope of this
    document.  However, in their interactions with routers, non-routing hosts
    must behave as if they were routers.

And Jeff replied:

BGP Speaker
    A router that implements the BGP protocol.  The internal behavior of
    non-routing hosts that also implement BGP are out of scope of this
    document.  However, in their interactions with BGP speaking routers, 
    non-routing hosts that implement BGP should be indistinguishable from 
    a router on the wire.

 (or something like that - s/on the wire/ with whatever sounds best.)

 IOW, look like bgp on the wire - what you do internally is out of scope.

Yakov replied, that we should keep the current definition, since it is
clear that non-routing hosts are outside of the scope.  Jeff responded
that he is ok with that if we normalize the use of "BGP Speaker" instead
of "BGP router" in the document.  Yakov agreed to this, we are at consensus
on this.

This was discussed in the "proxy: more comments on draft -18" thread.  
And in the "Issues list, #17: Section 3, Page 8, Paragraph 3 - Obsolete?"
thread.  And also, the "issue 17 - final resolution" thread.

----------------------------------------------------------------------------
18) MED Removal Text
----------------------------------------------------------------------------
Status: 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.

Yakov replied:

 Here is the text that will go in the next version of the draft:

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

Matthew responded to this with:

 I think this new text is ambiguous.

 >Here is the text that will go in the next version of the draft:
 >
 >  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
 >  route into IBGP, then comparison based on the MULT_EXIT_DISC
 >  attribute MAY be performed only among the EBGP learned routes.

 This could be taken to mean either that the comparison may be performed,
 and if it's performed it must be performed only between EBGP learned
 routes, or that the comparison must be performed, but it may be performed
 only between EBGP learned routes.

 >  This comparison MUST be performed before the removal of the
 >  MULTI_EXIT_DISC attribute.

 If doing the comparison is optional, then I think that this sentence
 should read "If the comparsion is performed, then it MUST be perfo..."

 >                             The MULT_EXIT_DISC attribute is then
 >  removed from those EBGP routes where such removal is required and
 >  which are still eligible. This is followed by comparison with
 >  IBGP learned routes.

 <snip>

 I think that it is desirable for an operator to be able to turn off
 MED processing entirely (including turning off all MED based
 comparisons), so I would suggest the following text:
 
  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
  route into IBGP, comparison based on the received MULTI_EXIT_DISC
  attribute MAY be performed.  If an implementation chooses to perform
  this comparison, then the comparison MUST be performed only among EBGP
  learned routes, and it MUST be performed before the removal of the
  MULTI_EXIT_DISC attribute.

Curtis replied to Yakov's message:

 Looks good to me.

 I see no need to change "This comparison MUST be performed before the
 removal of the MULTI_EXIT_DISC attribute".  There is no implication
 that MULTI_EXIT_DISC must be removed and the first sentence clearly
 indicates that doing so is not required therefore no ambiguity.
 Adding a "If a MULTI_EXIT_DISC attribute is removed" to the second
 sentence would be redundant.

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

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

Discussion:

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

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

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

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

Discussion:

This began when Siva proposed:

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

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

Sue replied that:

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

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

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

Siva replied:

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

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

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

----------------------------------------------------------------------------
21) Session Attributes - IdleHold Timer
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add the text in the discussion section.

Discussion:

This discussion began with Siva asking:

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

 Can we also add the following session attributes:

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

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

After some discussion we have this text on the table:

    Event8: Idle hold timer expires

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

 I will accept the new text for the following total text:
     
    Event8: Idle hold timer expires

           Definition: An event generated when the Idle Hold Timer
                       expires indicating that the session has completed
                       a back-off period to prevent bgp peer oscillation.

                       The Idle Hold Timer is only used when the persistent
                       peer oscillation damping function is enabled.

                       Implementations not implementing the presistent peer
                       oscillation damping functions may not have the Idle Hold
                       Timer.

           Status:     Optional

We are at consensus with this.

Tom added a couple of minor edits, correcting the spelling of "persistent"
in the third paragraph, and pointing out that:


                       oscillation damping functions may not have the Idle Hold
**                                                       function
** (because we only have function not functions in the previous sentence)
                       Timer.

Sue added the edits.

Siva also liked the way this issue has turned out.

This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #2.  And in the "Draft 19 - issue #21" thread, alternately
the "Draft 19 - Issue 21" thread.

----------------------------------------------------------------------------
22) Specify New Attributes (Accept Connections/Peer Oscillation Damping)
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add the text in the discussion section to section 8.0.

Discussion:

This begain with Siva propsosing:

  Can we call these out as well:

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

After some discussion we have this text on the table:

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

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

Sue accepted these changes.

Tom added this correction for item 2 in Sue's text:

 2) Delay Open Timer

 ** Open Delay timer
 ** (for which we have consensus in Issue list v2 item 7)

Siva asked, and Sue accepted these additional changes:

        9) accept connections from un-configured peers
        5) BGP stop_peer_flap flag

We are at consensus on this.

This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #3.  This was also discussed in the "BGP Draft 19 - Close open
items 22" thread.

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

Discussion:

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

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

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

----------------------------------------------------------------------------
24) Events 3, 5, 6 & 7 Give Examples
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Do we have consensus on the new text?

Discussion:

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

Sue replied that she has made the following changes, and asked if these
worked for Siva.

New text:
 
    Event7: Automatic stop

           Definition: Local system automatically stops the
                       BGP connection.

                       An example of an automatic stop event is
                       exceeding the number of prefixes for a given
                       peer and the local system  automatically
                       disconnecting the peer.


           Status:     Optional depending on local system

Siva thought this for Event 7 was fine.

Sue replied to the list, saying that, previously examples had caused
dissention, and asked if there was a strong feeling either way.

Siva proposed this text for Events 3, 5 & 6:

  Event 3:
   Examples of this event are:
   When a connection is terminated during exchange of Open
   messages due to version failure

  Event 5:
   Examples of this event are:
   Similar to Event 3

  Event 6:
   Examples of this event are:
   Similar to Event 3 and
   b) When a Idle Hold timer expires (within local limit)

This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #5.  This was also in the "Issue 25" thread, and the "Issue 25 -
this is really issue 24" threads.  This is also in the "Draft 19 - Issue 24"
thread.

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

Discussion:

This began with Siva wanting to change:

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

to:

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

Sue replied:

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

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

 with:

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

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

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

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

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

----------------------------------------------------------------------------
26) Event 4 & 5 - bgp_stop_flap option
----------------------------------------------------------------------------
Status: 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.

Tom replied:

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

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

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

Jeff replied to this, quoting the existing draft:

       The start events [Event 1, 3-6] are ignored in connect
       state.

       The start events [Event1, 3-6] are ignored in the Active
       state.

       The Start events [Event1, 3-6] are ignored in the OpenSent
       state.

       Any start event [Event1, 3-6] is ignored in the OpenConfirm
       state.

       Any start event (Event 1, 3-6) is ignored in the
       Established state.

And elaborated, saying that:

 "ignore" means do nothing.  This means don't twiddle with the flags. :-)

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.

Sue asked Siva to provide some text.

This was discussed in the "Comments 11-20" thread: Comment #14.  This
was also in the "BGP-19: Issue 33" thread.

----------------------------------------------------------------------------
34) Event 17 - TCP Connection Fails to TCP Connection Termination
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Change the text to "fails."

Discussion:

This began with Siva observing:

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

 % Event17: TCP connection termination

Sue replied that:

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

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

Sue replied that she has accepted Siva's comments, and the text will
be changed to "fails".

This was discussed in the "Comments 11-20" thread: Comment #15.  This
was also discussed in the "BGP-19: Issue 34-35, 40-48" thread.

----------------------------------------------------------------------------
35) Making Definition Style Consistant 
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Adpot consistant style for the definition of events.

Discussion:

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

We are agreed on the text for 13-17:

     Event13: TCP connection indication and valid remote peer

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

            Status:     Mandatory (Optional)


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

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

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

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

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

Siva proposed these changes for 18-21:

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

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

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

   with

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

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

   with

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

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

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

Sue replied that she accepted Siva's comments, so we are at consensus
here.

This was discussed in the "Comments 11-20" thread: Comment #16.  This
also came up in the "BGP-19: Issue 34-35, 40-48" thread.

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

Discussion:

Siva propsosed we replace:

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

with:

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

in Event 19.  Sue agreed to the changes.

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

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

Discussion:

Siva began with observing:

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

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

Sue replied that:

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


Siva also proposed an editorial fix with:

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

 The word event is missing. How about

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

Sue replied with this rewritten text:

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

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

Sive agreed with this new text.

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

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

Discussion:

Siva opened with this question:

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

<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: Consensus
Change: No
Summary: Leave things alone, since it is better to be redundant than to let
 something slip through.

Discussion:

Siva opend with the observation:

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

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

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

Sue replied:

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

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

Tom replied to this:

 I propose we leave it in and close this issue.
      
 1) To take out an action as redundant you need to be supremely
 confident that it really cannot make a difference.  I am not
 (supremely confident); rather, the more I look at the FSM, the more
 places I find where actions are missing, as I have posted to the list,
 from obscure yet possible sequences of events and timing.  And there
 is an outstanding issue of mine which flagged seven places where the
 next state was missing and so I think it impossible for any one to be 
 confident that any particular action is redundant until that is
 cleared up and that is proving complex in some cases.
 So, play safe, keep them in.

 2) The argument for removing them is that the number of possible
 distinct action lists is increased.  True - it will mean that an
 implementor will have to code more code when first implementing BGP.

 For me this is no contest; keeping it safe at the possible cost of
 redundancy outweighs the one-off cost of additional implementation.

 So keep the actions in and close the issue.

Jeff replied that he agreed with Tom on this.

Siva concurred, that this approach was acceptable.

Unless someone objects, this issue is at consensus.

This was discussed in the "Comments 21-30" thread: Comment #21.  This
is also discussed in the "BGP-draft-19: Issue 40 Clear Connect retry timer"
thread.

----------------------------------------------------------------------------
41) Handling of Event 14 in the Connect State
----------------------------------------------------------------------------
Status: 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.

Sue proposed:

	My resolution: Let event 14 be optional.
	Not all BGP implementations support it.

And asked if this let us reach consensus on this issue.

This was discussed in the "Comments 21-30" thread: Comment #22.  This was
also brought up in the "BGP-19: Issue 34-35, 40-48" thread.

----------------------------------------------------------------------------
42) Handling events 20, 21 in the Connect State and Active State
----------------------------------------------------------------------------
Status: 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.  Is Tom's proposed text acceptable?

Discussion:

Siva began this with:

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

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

To which Sue replied:

 Alternative comments:

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

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

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

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

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

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

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

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

Tom opined:

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

 But as ever, what is implemented?

Yakov suggested these modifications to the text to resolve this:

 1. Delete the last sentence in the above paragraph
   
  or

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

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

So the text on the table to resolve this is:

4.2 OPEN Message Format

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

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

Sue replied:

	I suggest we don't send a "NOTIFICATION" when
	Event 20 or Event 21 is received in Conect or Active state.
	
Tom responded to this issue with:

 Issue 42 queries whether or not we can send a NOTIFICATION when we
 have not sucessfully exchanged OPENs.  I propose we should, following
 the suggestions of Jeff and Yakov.

 As Yakov suggested, this requires the removal of the second sentence,
 first paragraph, of 4.2 which implies a NOTIFICATION can only be sent
 after a succesful exchange of OPENs.  I think this fits best with the
 other references to the uses of NOTIFICATION in the draft.

 In terms of the FSM, it means that in Connect and Active states, on
 receipt of events 20 or 21, we should send a NOTIFICATION so that the
 last section starting

 In response to any other event.............

 is replaced by (and noting we have agreed to drop references to MIB
 actions)

 If the BGP message header checking or OPEN message
       checking detect an error (see Section 6.2) [Events 20 or 21],
       the local system:
             - sends a NOTIFICATION message with the appropriate error
               code,
             - resets the connect retry timer (sets to zero),
             - releases all BGP resources,
             - drops the TCP connection
             - increments the ConnectRetryCnt (connect retry count) by
               1,
             - [optionally] performs peer oscillation damping
             - and goes to the Idle state.
     
  In response to any other event (Events 7-8, 10-11,18, 22-27), the
  local system:
              - resets the connect retry timer (sets to zero),
              - releases all BGP resources,
              - drops the TCP connection,
              - increments the ConnectRetryCnt (connect retry count)
                by one,
              - [optionally] performs peer oscillation damping,
              - and goes to the Idle state

 (Note that this text is not quite watertight.  Suppose we are in
 Active state, having been started with CRT running, receive an SYN
 (event 13), send SYN-ACK and then get a malformed message (events  
 20/21).  We have not yet received an ACK and so should not send
 anything over TCP; I would expect TCP to buffer this awaiting the ACK
 except we then take down the TCP connection - or try to; I don't know
 what happens next but regard it as sufficiently obscure not to be
 concerned).
 (My other concern is greater; why do we now not send NOTIFICATIONs for
 other events; in Open Sent, Open Confirm or Established, we send one
 for the 'default event list' so what makes events 20 and 21 in Active
 and Connect so special?  I can justify the absence of a NOTIFICATION
 for events 7, 8, 10, 11, 18, 22 since there is no evidence of a TCP
 connection to send it on; but events 23-27 in Active or Connect say we
 have received an erroneous message, the TCP connection is there so why
 not send a NOTIFICATION?
       Event7:  Automatic stop
       Event8:  Idle hold timer expires
       Event10: Hold timer expires
       Event11: Keepalive timer expires
       Event18: BGPOpen
       Event22: Open collision dump
       Event23: NotifMsgVerErr
       Event24: NotifMsg
       Event25: KeepAliveMsg
       Event26: UpdateMsg
       Event27: UpdateMsgErr

This was discussed in the "Comments 21-30" thread: Comment #23.  This
was also brought up in the "BGP-19: Issue 34-35, 40-48" thread, and
the "Draft bgp19 - issue #42 NOTIFICATION before OPEN" thread.

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

Discussion:

Siva opened this with:

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

 How about adding this:

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

Sue replied that:

 By the default you mean the text:

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

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

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

Sue replied that she accepted Siva's changes with these editorial changes:

	old text:
		- resets the connect retry timer (sets to zero)
		- clears the open delay timer

	new text:
		- if the connect retry timer is running,
			clear the connect retry timer (set to zero).
		- if the open delay timer is running,
			clear the open delay timer (set to zero).

Since the substantive changes have been accepted, unless someone objects,
this issue is at consensus.

This was discussed in the "Comments 21-30" thread: Comment #24.  This
was also brought up in the "BGP-19: Issue 34-35, 40-48"

----------------------------------------------------------------------------
44) Handling Event 23 in Connect and OpenSent
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Is the existing table is sufficent to describe the behavior?
  Is there an additional issue here?

Discussion:

This began with Siva saying:

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

Sue replied:

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

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

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

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

In an exchange between Siva and Sue, this came up:

Siva:

    "Default event handling" was perhaps a poor choice of words.

    What I meant is this

    Event 23 (Notify Message Version error) only indicates a version
 mismatch. By going through action sequence D, we will be performing peer
 oscillation damping. Should we perform damping, since this is not really a
 cause for persistent oscillation ? 

    Also, since we have a distinct event to indicate a version error event,
 can include text indicating that version negotiation processing should take
 place upon receipt of this event ?   

Sue:

 Yes, we can change the "D" in state machine to a "y".

 The issue is what if Connect state occurs and there is not
 a TCP connection.  Should an OPEN with wrong version
 be accepted?  If the Open Delay flag is off, the connection
 state should not be getting an Open.  The "D" action below
 works for "open delay flag off".

 The "y" action you suggest can occur if the open delay
 timer is on.

 If this is the issue, please confirm.

 We could say: if open delay flag is on -> y action
                   if open delay flag is off -> D action

 Please let me know if this is the concern, and suggest
 text.

Prior to this exhange, this issue was at consensus.  The only
thing that is firm in this exchange is changing "D" to "y".  There
seems to be some open discussion still, so we'll reopen it.

This was discussed in the "Comments 21-30" thread: Comment #25. This was
also brought up in the "BGP-19: Issue 34-35, 40-48" thread.

----------------------------------------------------------------------------
45) Event 17 in the Connect state
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Are final edits to changed text acceptable?

Discussion:

This began with Siva asking:

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

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

Sue replied refering to the disussion tracked in issue 13.4.

Jeff responded that:

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

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

Tom replied that he agreed with this.

Tom then proposed this text:

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

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

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

Sue agreed to change the text to reflect the comments. o

Jeff brought out a couple of other concerns, and Tom replied:

 >         If the TCP connection fails [Event17] and the Open Delay
 >         timer is not running, the local system:
 >              - drops the TCP connection,
 >              - releases all BGP resources,

 There are no resources to release while in the connect state. 
 (Unless we're using this as shorthand for something else - I forget.)   

Tom:

 I was unsure about this action.  It is present for Active state event
 17 which is why I put it in, it does include sub-actions such as clear
 Open Delay timer (not running), clear Connect Retry timer (could be
 running) so I think it right to play safe and include it.

Jeff:

 >              - sets ConnectRetryCnt (the connect retry count) to zero

 I'm forgetting if this action is consistant with everything else.
 I don't have a current copy of the FSM and I don't trust -18 to be
 current enough. :-)
        
 This said, why do we go to zero?  I could see not incrementing it
 and letting the normal decay process deal with it.  The same would
 apply for the above.

Tom:

 Again, I was unsure about this so put it in and waited for comment.  I
 have a chart of 27 events and 6 states in which I have colored in the
 connect retry and peer oscillation damping actions and it looks like
 measles; I could not divine the underlying logic.  Incrementing the
 connect retry count would make as much if not more sense to me.  (It
 is zeroed for Manual Stop).

 But the action '[optionally] perform peer oscillation damping' is yet
 more erratic (eg for event 10 - Hold Timer expired - it is performed 
 exiting Connect, Active, Established but not Open Confirm or Open Sent)
 so I left it out.  Again, it might make more sense put it in.

Sue replied to this:

 The connect state could have a few resources
 (minimum peer footprint) as the FSM goes
 from Idle to Connected state.  While this amount
 of BGP resources is not as much as the final
 amount, it still needs to get released.

 2nd - I think the connectretrycount should be removed;
        Thanks for catching that.

 Please confirm that part #1 is OK with you so we can
 put issue 45 into consensus state.

This was discussed in the "Comments 21-30" thread: Comment #26.  This
was also brought up in the "BGP-19: Issue 34-35, 40-48" thread.

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

Discussion:

This began with Siva saying:

 We should now move into Idle state. Can we add

% - Goes to Idle state

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

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

----------------------------------------------------------------------------
47) Handling of Event 19 in Active state
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add the new text in the discussion section.

Discussion:

This began with Siva suggesting:

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

Sue replied that:

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

 Which text do you prefer?

Sue replied that this text would be added to the next draft:

	New text

	- if the hold timer value is non-zero,
		- starts the keepalive timer to initial value,
		- resets the hold timer to the negotiated value,
	- else if the hold timer is zero
		- resets the keepalive timer (set to zero),
		- resets the hold timer to zero.

This seems to address Siva's concerns, this issue is at consensus, if
there are objections, we can reopen it.

This was discussed in the "Comments 21-30" thread: Comment #28.  This
was also brought up in the "BGP-19: Issue 34-35, 40-48" thread.

----------------------------------------------------------------------------
48) Handling of Event 2 in Active state
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Update the draft with the text at the end of the discussion section.

Discussion:

Siva opened with:

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

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

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

Sue counter suggested:

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

Jeff replied:

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

 Going to Idle is fine.

Tom offered this example:

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

Sue asked if there were any additional comments, if not, the text will
be:

	A manual stop event[Event2], the local system:
	  - Sends a NOTIFICATION with a Cease,
	  - releases all BGP resources including
		- stopping the OPen delay timer
	  - drops the TCP connection,
	  - sets ConnectRetryCnt (connect retry count) to zero
	  - resets the connect retry timer (sets to zero),
	  - changes its state to Idle.

There have been no additional comments, we will use the text Sue proposed.

This was discussed in the "Comments 21-30" thread: Comment #29.  This was
also brought up in the "BGP-19: Issue 34-35, 40-48" thread.

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

Discussion:

Siva began with:

 To ensure consistencey with E2 handling, can we add

% - If any BGP Routes exist, delete the routes

Sue replied:

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

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

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

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

Discussion:

This began with Siva stating:

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

Sue replied that:

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

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

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

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

Discussion:

This began with Siva stating:

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

Sue replied that:

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

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

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

----------------------------------------------------------------------------
52) Handling Event 18 in the OpenSent state (Keepalive Timer)
----------------------------------------------------------------------------
Status: 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).

Sue replied, asking more implementors to chime in on what they do for
this part of the FSM.

Curits replied that we should:

 Make it optional.  Timing out in open or open-sent has never been much
 of an issue, so whether one or three keepalive get sent shouldn't be a
 hot topic.

Sue said that this was fine, and she would work on text specifying optional.

Jeff replied regarding GateD's behavior:

 GateD will start its keepalive timer while in this state, so multiple
 keepalives will be sent.

 As someone previously said, this is a "yawn" issue.  But to choose one
 way or the other, we may potentially make someone in non-compliance.

>From the closure of issue 12, we have this text, which discusses Keepalives
to consider in relation to the other keepalive issue here:

 Change 1:  new text

 Active state - event 19

    If an Open is received with the Open Delay timer is
    running [Event 19], the local system
        - clears the connect retry timer (cleared to zero),
        - stops and clears the Open Delay timer
        - completes the BGP initialization,
        - stops and clears the Open Delay timer
        - sends an OPEN message,
        - send a Keepalive message,
        - if the hold timer value is non-zero,
                - starts the keepalive timer to initial value,
                - resets the hold timer to the negotiated value,
          else if the hold timer is zero
                - resets the keepalive timer (set to zero),
                - resets the hold timer to zero.

        - changes its state to OpenConfirm.

    If the value of the autonomous system field is the same as the local
    Autonomous System number, set the connection status to an internal
    connection; otherwise it is "external".
   
This was discussed in the "Comments 30-36" thread: Comment #33.  And
in the "BGP-draft-19: Issue 52 - Event 18 in OpenSent State (Keepalive 
timer set)" thread.

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

Discussion:

This began with Siva asking:

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

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

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

----------------------------------------------------------------------------
54) State impact of not supporting Optional Events
----------------------------------------------------------------------------
Status: 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 21-30" thread: Comment #22.
This was discussed in the "Comments 21-30" thread: Comment #26.
This was discussed in the "Comments 30-36" thread: Comment #36.

--3MwIy2ne0vdjdPXF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="Changelog-v2.txt"

CHANGELOG


----------------------------------------------------------------------------
v2.1 to v2.2
2003-01-30
----------------------------------------------------------------------------

Updated:

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

Moved to Consensus:

12) Entering OpenConfirm / Adding "Stop OpenDelay" action
13) FSM Missing Next States
13.2) FSM Missing Next States - Event 14 (Connect State)
13.4) FSM Missing Next States - Event 13-17 (TCP Connection)
13.6) FSM Missing Next States - Event 18 (Open Confirm)
17) Section 3, Page 8, Paragraph 3 - Obsolete?
34) Event 17 - TCP Connection Fails to TCP Connection Termination
35) Making Definition Style Consistant
40) Clearing the Connection Retry Timer
43) Handling the default events in the Connect state
47) Handling of Event 19 in Active state
48) Handling of Event 2 in Active state

----------------------------------------------------------------------------
v2.0 to v2.1
2003-01-20
----------------------------------------------------------------------------

Updated:

2) MUST/SHOULD Capitalization
13.2) FSM Missing Next States - Event 14 (Connect State)
13.4) FSM Missing Next States - Event 13-17 (TCP Connection)
13.5) FSM Missing Next States - Event 17 (Connect State)
13.6) FSM Missing Next States - Event 18 (Open Confirm)
15) FSM - Consistent FSM Event Names
17) Section 3, Page 8, Paragraph 3 - Obsolete?
21) Session Attributes - IdleHold Timer
22) Specify New Attributes (Accept Connections/Peer Oscillation Damping)
24) Events 3, 5, 6 & 7 Give Examples
26) Event 4 & 5 - bgp_stop_flap option
33) Event 13 & 14 - Valid Addresses & Ports
45) Event 17 in the Connect state

Moved to Consensus:

13.5) FSM Missing Next States - Event 17 (Connect State)
15) FSM - Consistent FSM Event Names
21) Session Attributes - IdleHold Timer
22) Specify New Attributes (Accept Connections/Peer Oscillation Damping)


--3MwIy2ne0vdjdPXF--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA22472 for <[e-mail]>; Thu, 30 Jan 2003 18:07:41 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 872A9912D7; Thu, 30 Jan 2003 18:07:16 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 527F3912E3; Thu, 30 Jan 2003 18:07:16 -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 388C1912D7 for <[e-mail]>; Thu, 30 Jan 2003 18:07:15 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1B4125DE2C; Thu, 30 Jan 2003 18:07:15 -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 B3F9D5DDA6 for <[e-mail]>; Thu, 30 Jan 2003 18:07:14 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id PAA13930; Thu, 30 Jan 2003 15:04:04 -0800 (PST)
Date: Thu, 30 Jan 2003 15:04:04 -0800
From: [e-mail]
To: Susan Hares <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Siva's responses
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, Jan 30, 2003 at 05:46:13PM -0500
Sender: [e-mail]
Precedence: bulk

Sue,

A new issues list is comming out this afternoon.  You open issues geneally
match.  We also have:

24) Events 3, 5, 6 & 7 Give Examples
 ---> Do we add the examples Siva suggested for 3, 4, & 6?

33) Event 13 & 14 - Valid Addresses & Ports
 ---> We are still disagreeing on destination port definition.  Siva 
      was to provide some suggested text.

41) Handling of Event 14 in the Connect State
 ---> Is this really part of 13.4? (Which is resolved), should event 14 
      be optional?

Andrew

On Thu, Jan 30, 2003 at 05:46:13PM -0500, Susan Hares wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
> Subject: RE: Siva's responses
> Date: Thu, 30 Jan 2003 17:46:13 -0500
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: Siva's responses
> Thread-Index: AcLGUr0R6YidyDJcS/GHAAEVOjB1dQBY/D8Q
> From: "Susan Hares" <[e-mail]>
> To: <[e-mail]>
> Cc: <[e-mail]>, <[e-mail]>
> X-Virus-Scanned: by AMaViS perl-11
> Precedence: bulk
> X-Spam-Status: No, hits=0.4 required=5.0
> 	tests=AWL,SPAM_PHRASE_01_02
> 	version=2.43
> X-OriginalArrivalTime: 30 Jan 2003 22:47:11.0277 (UTC) FILETIME=[869985D0:01C2C8B1]
> X-MIME-Autoconverted: from quoted-printable to 8bit by xix-w.bengi.exodus.net id h0UMTMZ03682
> 
> Andrew:
> 
> you should have a copy of all Siva's responses.
> My understanding of open issues from Siva, Jeff and
> Tom are: 
> 
> 18) MED Removal Text
> 	--> Awaiting mrr response
> 
> 26) Event 4 & 5 - bgp_stop_flap option 
> 	---> awaiting siva comments on the 7b event
> 	(Siva - let me know if I missed something)
> 
> 42) Handling events 20, 21 in the Connect State and Active State
>  	--- Siva - I need some help on this one.
> 	    Can you send me more details? 
> 
> 44) Handling Event 23 in Connect and OpenSent
> 	--> Siva, Jeff and Tom need to comment
> 
> 45) Event 17 in the Connect state
> 	--> Jeff asked questions (re-opened 45), need to response
> 
> 52) Handling Event 18 in the OpenSent state (Keepalive Timer)
> 	--> Sue needs to propose text, but consensus is reached.
> 	    Sue will sent out text. 
> 
> 54) State impact of not supporting Optional Events
> 	---> no response from Siva or the list, no change.
> 	     Last chance for consensus.
> 
> Sue
> 
> ==============
> 42- 
> 
> >	Event 20 or Event 21 is received in Connect or Active state.
> 
>     My view is:
> 
>     1) This is inconsistent with the way Header errors and errors in OPEN
> messages are handled when the delay open timer is not running since, we do
> send an NOTIFICATION when such events occur when we are in the OpenSent
> state
>     2) There is no means for the other end to know the cause for our
> terminating the connection. Also, if we find a version number error or find
> the security information unacceptable (in the future, perhaps!), the other
> end should know about this. As things stand, due to a local flag, namely
> delay open, the remote side will miss valid information.
> 
>     If sending out a NOTIFICATION without sending out an OPEN message is
> unacceptable, I would rather send out a OPEN message and an NOTIFICATION
> message when this event occurs.
> 
> Sivanand
> ([e-mail]) 
> 
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Monday, January 27, 2003 5:21 PM
> To: Susan Hares
> Cc: [e-mail]
> Subject: Siva's responses
> 
> 
> Hi Sue,
> 
> Has Siva gotten back to you on with his responses?  I'm looking to get another
> version of the issues list out, and I'd like to make sure it is as up-to-date
> as possible.
> 
> Thanks!
> 
> 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 RAA21850 for <[e-mail]>; Thu, 30 Jan 2003 17:47:06 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 4F6B29127F; Thu, 30 Jan 2003 17:46:40 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5986912D7; Thu, 30 Jan 2003 17:46: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 C9DA59127F for <[e-mail]>; Thu, 30 Jan 2003 17:46:31 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D8EA95DE1D; Thu, 30 Jan 2003 17:46:25 -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 4155F5DDF3 for <[e-mail]>; Thu, 30 Jan 2003 17:46:25 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0UMkOS37102 for [e-mail]; Thu, 30 Jan 2003 17:46: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 h0UMkDC37073 for <[e-mail]>; Thu, 30 Jan 2003 17:46:13 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Siva's responses
Date: Thu, 30 Jan 2003 17:46:13 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Siva's responses
Thread-Index: AcLGUr0R6YidyDJcS/GHAAEVOjB1dQBY/D8Q
From: "Susan Hares" <[e-mail]>
To: <[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 RAA21850

Andrew:

you should have a copy of all Siva's responses.
My understanding of open issues from Siva, Jeff and
Tom are: 

18) MED Removal Text
	--> Awaiting mrr response

26) Event 4 & 5 - bgp_stop_flap option 
	---> awaiting siva comments on the 7b event
	(Siva - let me know if I missed something)

42) Handling events 20, 21 in the Connect State and Active State
 	--- Siva - I need some help on this one.
	    Can you send me more details? 

44) Handling Event 23 in Connect and OpenSent
	--> Siva, Jeff and Tom need to comment

45) Event 17 in the Connect state
	--> Jeff asked questions (re-opened 45), need to response

52) Handling Event 18 in the OpenSent state (Keepalive Timer)
	--> Sue needs to propose text, but consensus is reached.
	    Sue will sent out text. 

54) State impact of not supporting Optional Events
	---> no response from Siva or the list, no change.
	     Last chance for consensus.

Sue

==============
42- 

>	Event 20 or Event 21 is received in Connect or Active state.

    My view is:

    1) This is inconsistent with the way Header errors and errors in OPEN
messages are handled when the delay open timer is not running since, we do
send an NOTIFICATION when such events occur when we are in the OpenSent
state
    2) There is no means for the other end to know the cause for our
terminating the connection. Also, if we find a version number error or find
the security information unacceptable (in the future, perhaps!), the other
end should know about this. As things stand, due to a local flag, namely
delay open, the remote side will miss valid information.

    If sending out a NOTIFICATION without sending out an OPEN message is
unacceptable, I would rather send out a OPEN message and an NOTIFICATION
message when this event occurs.

Sivanand
([e-mail]) 


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
Sent: Monday, January 27, 2003 5:21 PM
To: Susan Hares
Cc: [e-mail]
Subject: Siva's responses


Hi Sue,

Has Siva gotten back to you on with his responses?  I'm looking to get another
version of the issues list out, and I'd like to make sure it is as up-to-date
as possible.

Thanks!

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 QAA20042 for <[e-mail]>; Thu, 30 Jan 2003 16:52:08 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6C9A8912D0; Thu, 30 Jan 2003 16:49:39 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3242912D7; Thu, 30 Jan 2003 16:48: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 E47269124C for <[e-mail]>; Thu, 30 Jan 2003 16:47:02 -0500 (EST)
Received: by segue.merit.edu (Postfix) id CA3545DDF3; Thu, 30 Jan 2003 16:47:02 -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 3C6975DDA6 for <[e-mail]>; Thu, 30 Jan 2003 16:47:02 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id NAA12963; Thu, 30 Jan 2003 13:43:56 -0800 (PST)
Date: Thu, 30 Jan 2003 13:43:56 -0800
From: [e-mail]
To: Tom Petch <[e-mail]>
Cc: Susan Hares <[e-mail]>, [e-mail], [e-mail]
Subject: Re: issues 12 -  consensus & two changes - 2nd message
Message-ID: <[e-mail]>
References: <006001c2c8a4$5b8db300$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: <006001c2c8a4$5b8db300$0301a8c0@tom3>; from [e-mail] on Thu, Jan 30, 2003 at 09:12:13PM -0000
Sender: [e-mail]
Precedence: bulk

Ok, does anyone object, if we move Issue 12 to consensus, with the text
that Sue spelled out in Change 2, as its resolution?  I'll then move
the Keepalive discussion, and the text in Change 1 to issue 52.

Andrew

On Thu, Jan 30, 2003 at 09:12:13PM -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: "Susan Hares" <[e-mail]>, <[e-mail]>
> Cc: <[e-mail]>
> Subject: Re: issues 12 -  consensus & two changes - 2nd message
> Date: Thu, 30 Jan 2003 21:12:13 -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.7 required=5.0
> 	tests=AWL,SPAM_PHRASE_00_01,USER_AGENT_OE
> 	version=2.43
> X-OriginalArrivalTime: 30 Jan 2003 21:14:54.0402 (UTC) FILETIME=[A25D7220:01C2C8A4]
> 
> Sue
> 
> Change 2, stop Open Delay timer in Connect state events 9 and 17,
> fine; that is what I understand to be the real issue 12.
> 
> Change 1, event 19 in Active state, is IMHO issues 47 and 52.  This is
> tangled because the initial paragraphs of Issue 12 in the issue list
> are nothing to to with stopping Open Delay timer and everything to to
> with sending a Keepalive message before entering Open Confirm state
> from Active or Connect state on event 19; which I raised and see as
> issue 52.  Issue 47 was Siva's issue 28 and relates to a different
> action for Active state event 19.
> 
> I agree with change 1 in that it adds in the sending of Keepalive
> which I believe essential; I think Siva needs to respond concerning
> issue 47.  (nb the stop Open Delay action is duplicated)  I wonder if
> we should use a different character for the bullet points under the if
> and else clauses to make it clear where they end ie
> - if the hold timer ....
> + do this
> + and this
>   else if ...
> + do the other
> + and this
> 
> But I still have an issue for Connect state event 19 where I believe,
> as for Active state event 19, we should send a Keepalive and start the
> Keepalive timer.  I will pursue this as part of issue 52 if that suits
> you.  I think the text will be the same as whatever we agree for
> Active state event 19.
> 
> Tom Petch
> [e-mail]
> 
> -----Original Message-----
> From: Susan Hares <[e-mail]>
> To: Tom Petch <[e-mail]>; [e-mail]
> <[e-mail]>
> Cc: [e-mail] <[e-mail]>
> Date: 30 January 2003 10:39
> Subject: issues 12 - consensus & two changes - 2nd message
> 
> 
> Tom and idr:
> 
> I believe issues 12 is in consensus. Please
> ack the new text below.
> 
> Sue
> ==================
> Change 1:  new text
> 
> Active state - event 19
> 
>     If an Open is received with the Open Delay timer is
>     running [Event 19], the local system
>         - clears the connect retry timer (cleared to zero),
>         - stops and clears the Open Delay timer
>         - completes the BGP initialization,
>         - stops and clears the Open Delay timer
>         - sends an OPEN message,
> - send a Keepalive message,
> - if the hold timer value is non-zero,
> - starts the keepalive timer to initial value,
> - resets the hold timer to the negotiated value,
>   else if the hold timer is zero
> - resets the keepalive timer (set to zero),
> - resets the hold timer to zero.
> 
>         - changes its state to OpenConfirm.
> 
>     If the value of the autonomous system field is the same as the
> local
>     Autonomous System number, set the connection status to an internal
>     connection; otherwise it is "external".
> 
> Change 2 -
> Connect state
> event 17 (currently defined as going to Active)
> event 9 (stays in Connect state)
> 
> new Text:
> 
>      In response to the connect retry timer expires event [Event
>      9], the local system:
>         - drops the TCP connection,
>         - restarts the connect retry timer,
> - stops the Open Delay timer and resets the timer to zero,
>         - initiates a TCP connection to the other BGP peer,
>         - continues to listen for a connection that may be
>           initiated by the remote BGP peer, and
>         - stays in Connect state.
> 
> 
>      If the TCP connection fails [Event17], the local system:
>          - restarts the connect retry timer,
> - stops the Open Delay timer and resets value to zero,
>          - continues to listen for a connection that may be
>            initiated by the remote BGP peer, and
>          - changes its state to Active.
> 
> Sue Hares


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA18997 for <[e-mail]>; Thu, 30 Jan 2003 16:15:01 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B557D912C4; Thu, 30 Jan 2003 16:14:38 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88C68912CD; Thu, 30 Jan 2003 16:14:38 -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 69530912C4 for <[e-mail]>; Thu, 30 Jan 2003 16:14:36 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 4B5EA5DE1D; Thu, 30 Jan 2003 16:14:36 -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 F39F65DE03 for <[e-mail]>; Thu, 30 Jan 2003 16:14:35 -0500 (EST)
Received: from tom3 (usercb54.uk.uudial.com [62.188.150.221]) by shockwave.systems.pipex.net (Postfix) with SMTP id A6A5C160010D8; Thu, 30 Jan 2003 21:14:33 +0000 (GMT)
Message-ID: <006001c2c8a4$5b8db300$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Susan Hares" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: issues 12 -  consensus & two changes - 2nd message
Date: Thu, 30 Jan 2003 21:12:13 -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

Change 2, stop Open Delay timer in Connect state events 9 and 17,
fine; that is what I understand to be the real issue 12.

Change 1, event 19 in Active state, is IMHO issues 47 and 52.  This is
tangled because the initial paragraphs of Issue 12 in the issue list
are nothing to to with stopping Open Delay timer and everything to to
with sending a Keepalive message before entering Open Confirm state
from Active or Connect state on event 19; which I raised and see as
issue 52.  Issue 47 was Siva's issue 28 and relates to a different
action for Active state event 19.

I agree with change 1 in that it adds in the sending of Keepalive
which I believe essential; I think Siva needs to respond concerning
issue 47.  (nb the stop Open Delay action is duplicated)  I wonder if
we should use a different character for the bullet points under the if
and else clauses to make it clear where they end ie
- if the hold timer ....
+ do this
+ and this
  else if ...
+ do the other
+ and this

But I still have an issue for Connect state event 19 where I believe,
as for Active state event 19, we should send a Keepalive and start the
Keepalive timer.  I will pursue this as part of issue 52 if that suits
you.  I think the text will be the same as whatever we agree for
Active state event 19.

Tom Petch
[e-mail]

-----Original Message-----
From: Susan Hares <[e-mail]>
To: Tom Petch <[e-mail]>; [e-mail]
<[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: 30 January 2003 10:39
Subject: issues 12 - consensus & two changes - 2nd message


Tom and idr:

I believe issues 12 is in consensus. Please
ack the new text below.

Sue
==================
Change 1:  new text

Active state - event 19

    If an Open is received with the Open Delay timer is
    running [Event 19], the local system
        - clears the connect retry timer (cleared to zero),
        - stops and clears the Open Delay timer
        - completes the BGP initialization,
        - stops and clears the Open Delay timer
        - sends an OPEN message,
- send a Keepalive message,
- if the hold timer value is non-zero,
- starts the keepalive timer to initial value,
- resets the hold timer to the negotiated value,
  else if the hold timer is zero
- resets the keepalive timer (set to zero),
- resets the hold timer to zero.

        - changes its state to OpenConfirm.

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

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

new Text:

     In response to the connect retry timer expires event [Event
     9], the local system:
        - drops the TCP connection,
        - restarts the connect retry timer,
- stops the Open Delay timer and resets the timer to zero,
        - initiates a TCP connection to the other BGP peer,
        - continues to listen for a connection that may be
          initiated by the remote BGP peer, and
        - stays in Connect state.


     If the TCP connection fails [Event17], the local system:
         - restarts the connect retry timer,
- stops the Open Delay timer and resets value to zero,
         - continues to listen for a connection that may be
           initiated by the remote BGP peer, and
         - changes its state to Active.

Sue Hares



Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA06523 for <[e-mail]>; Thu, 30 Jan 2003 10:04:27 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 87DB2913A2; Thu, 30 Jan 2003 09:53:48 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF74D9132E; Thu, 30 Jan 2003 09:51: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 7EBC2912EF for <[e-mail]>; Thu, 30 Jan 2003 09:49:33 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1F6555F2DF; Thu, 30 Jan 2003 09:00: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 5FD965E5EE for <[e-mail]>; Thu, 30 Jan 2003 05:52:10 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0UAq9623434 for [e-mail]; Thu, 30 Jan 2003 05:52: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 h0UAq2C23416 for <[e-mail]>; Thu, 30 Jan 2003 05:52:02 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: Closure on #12 - 1st message 
Date: Thu, 30 Jan 2003 05:52:02 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Closure on #12
Thread-Index: AcLHu8K0ztZgA5RORaqBGeqPn7s0xA==
From: "Susan Hares" <[e-mail]>
To: <[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 KAA06523

I've added stop Open delay timer suggested 
by Tom Petch.  Please close this item

Sue
------------

Connect state: 
----------------------
 
     In response to the connect retry timer expires event [Event 
     9], the local system: 
        - drops the TCP connection, 
        - restarts the connect retry timer,
	- stops the Open Delay timer and resets the timer to zero,  
        - initiates a TCP connection to the other BGP peer, 
        - continues to listen for a connection that may be 
          initiated by the remote BGP peer, and
        - stays in Connect state.
....

     If the TCP connection fails [Event17], the local system:
         - restarts the connect retry timer, 
	 - stops the Open Delay timer and resets value to zero,
         - continues to listen for a connection that may be 
           initiated by the remote BGP peer, and
         - changes its state to Active. 


==========
 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.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA06376 for <[e-mail]>; Thu, 30 Jan 2003 10:01:42 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8D2A8912FD; Thu, 30 Jan 2003 09:52:00 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7AB3D9131D; Thu, 30 Jan 2003 09:51: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 CCBE7912ED for <[e-mail]>; Thu, 30 Jan 2003 09:49:12 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A80A05E510; Thu, 30 Jan 2003 08:57:21 -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 3CDFD5FF8E for <[e-mail]>; Thu, 30 Jan 2003 05:39:20 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0UAdDU23181 for [e-mail]; Thu, 30 Jan 2003 05:39: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 h0UAcPC23003 for <[e-mail]>; Thu, 30 Jan 2003 05:38:25 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Draft 19 - issue #21 
Date: Thu, 30 Jan 2003 05:38:25 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft 19 - issue #21 
Thread-Index: AcLCP9Y/Dd4BowA5QRKLu5xodLiWqAFbOx3w
From: "Susan Hares" <[e-mail]>
To: "Tom Petch" <[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 KAA06376

fixed in text.

Thanks for the editing.

Sue

-----Original Message-----
From: Tom Petch [mailto:[e-mail]]
Sent: Wednesday, January 22, 2003 12:53 PM
To: Susan Hares; [e-mail]
Subject: Re: Draft 19 - issue #21 


Sue
two minor editorial comments inline
Tom Petch

-----Original Message-----
From: Susan Hares <[e-mail]>
To: [e-mail] <[e-mail]>
Date: 20 January 2003 19:39
Subject: Draft 19 - issue #21



I will accept the new text for the following total text:

    Event8: Idle hold timer expires

           Definition: An event generated when the Idle Hold Timer
       expires indicating that the session has completed
       a back-off period to prevent bgp peer oscillation.

       The Idle Hold Timer is only used when the persistent
                       peer oscillation damping function is enabled.

                       Implementations not implementing the presistent
peer

**
persistent
                       oscillation damping functions may not have the
Idle Hold
**                                                       function
** (because we only have function not functions in the previous
sentence)
                    Timer.

           Status:     Optional


Sue Hares



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA04623 for <[e-mail]>; Thu, 30 Jan 2003 09:13:10 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A381D91230; Thu, 30 Jan 2003 09:12:48 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D40691233; Thu, 30 Jan 2003 09:12: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 201E391230 for <[e-mail]>; Thu, 30 Jan 2003 09:12:47 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 65B2D5E640; Thu, 30 Jan 2003 06:54:38 -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 B1E0E627E6 for <[e-mail]>; Thu, 30 Jan 2003 05:58:44 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0UAwhJ23564 for [e-mail]; Thu, 30 Jan 2003 05:58:43 -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 h0UAwWC23534 for <[e-mail]>; Thu, 30 Jan 2003 05:58:32 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: BGP Draft 19 - Close open items 22
Date: Thu, 30 Jan 2003 05:58:31 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: BGP Draft 19 - Close open items 22
Thread-Index: AcLF7JfLcKA3/tVNRKC/4bFxvfqghwBuJd5Q
From: "Susan Hares" <[e-mail]>
To: "Sivananda Ramnath - CTD, Chennai." <[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 JAA04623

Siva:

I'll be glad to

	9) accept connections from un-configured peers
	
% yes - this is the correct text:
	5) BGP stop_peer_flap flag

Sue

-----Original Message-----
From: Sivananda Ramnath - CTD, Chennai. [mailto:[e-mail]]
Sent: Monday, January 27, 2003 5:15 AM
To: Susan Hares
Cc: Sivananda Ramnath (E-mail)
Subject: RE: BGP Draft 19 - Close open items 22


Hello,

    Do you think the following should also be added to this list:

    * Accept connections from un-configured peers


    Also, for item 5:
    >  5) BGP stop_peer_flag flag

    Can I assume you meant
    %  5) BGP stop_peer_flap flag


Siva
([e-mail])


> -----Original Message-----
> From: Susan Hares [mailto:[e-mail]]
> Sent: Tuesday, January 21, 2003 1:17 AM
> To: [e-mail]
> Subject: BGP Draft 19 - Close open items 22
> 
> 
> 
> Please consider items 22 closed with the following final text:
> 
>         
>  Optional parameters that may be supported either per
>  connection or per implementation:
> 
>  1) Delay Open flag
>  2) Delay Open Timer
>  3) Perform automatic start flag
>  4) Passive TCP establishment flag
>  5) BGP stop_peer_flag flag
>  6) Idle Hold timer
>  7) Perform automatic stop flag
>  8) Perform Collision detect in Establish mode flag
> 
> 
> Sue
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA04474 for <[e-mail]>; Thu, 30 Jan 2003 09:09:07 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 05A1691234; Thu, 30 Jan 2003 09:04:44 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A80B91239; Thu, 30 Jan 2003 09:04: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 EF77E9121B for <[e-mail]>; Thu, 30 Jan 2003 09:03:59 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A2D1D606BE; Thu, 30 Jan 2003 06:01:21 -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 79C9C606C4 for <[e-mail]>; Thu, 30 Jan 2003 05:39:23 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0UAdMu23185 for [e-mail]; Thu, 30 Jan 2003 05:39:22 -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 h0UAcQC23014 for <[e-mail]>; Thu, 30 Jan 2003 05:38:26 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Draft 19 - Issue 40
Date: Thu, 30 Jan 2003 05:38:25 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft 19 - Issue 40
Thread-Index: AcLF9/KH2y9c5NyYQeOMj9EqQwlCXwBslCmA
From: "Susan Hares" <[e-mail]>
To: "Sivananda Ramnath - CTD, Chennai." <[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 JAA04474

Siva: 

Thank-you, we'll consider it consensus
with no changes to the text.

Sue

-----Original Message-----
From: Sivananda Ramnath - CTD, Chennai. [mailto:[e-mail]]
Sent: Monday, January 27, 2003 6:36 AM
To: Susan Hares
Cc: Sivananda Ramnath (E-mail)
Subject: Draft 19 - Issue 40


Hello,

    I am ok with this approach. My only observation is that by not doing
these actions where they are not required, it may be easier to spot errors
in an FSM implementation. This, however, can be viewed as a purely
implementation issue. Any resolution you have for this issue is fine by me.

Sivanand
([e-mail])

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

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.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA04455 for <[e-mail]>; Thu, 30 Jan 2003 09:08:46 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 408199121B; Thu, 30 Jan 2003 09:04:42 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8CEEF91230; Thu, 30 Jan 2003 09:04: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 91ED591221 for <[e-mail]>; Thu, 30 Jan 2003 09:04:09 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 686B4606DD; Thu, 30 Jan 2003 06:02: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 4A082606DE for <[e-mail]>; Thu, 30 Jan 2003 05:39:31 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0UAdSh23212 for [e-mail]; Thu, 30 Jan 2003 05:39:28 -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 h0UAcWC23049 for <[e-mail]>; Thu, 30 Jan 2003 05:38:32 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Draft 19 - Issue 21
Date: Thu, 30 Jan 2003 05:38:30 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft 19 - Issue 21
Thread-Index: AcLF63iMBweZMZuhR8a/SkORrPorxABuXjLg
From: "Susan Hares" <[e-mail]>
To: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
Cc: <[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 JAA04455

Siva's response 

-----Original Message-----
From: Sivananda Ramnath - CTD, Chennai. [mailto:[e-mail]]
Sent: Monday, January 27, 2003 5:07 AM
To: Susan Hares
Cc: Sivananda Ramnath (E-mail)
Subject: Draft 19 - Issue 21


Hello,

    Based on revised text, we can move this to consensus.

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 JAA04435 for <[e-mail]>; Thu, 30 Jan 2003 09:08:10 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id EA89691221; Thu, 30 Jan 2003 09:04:39 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66A0691234; Thu, 30 Jan 2003 09:04: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 D552A91230 for <[e-mail]>; Thu, 30 Jan 2003 09:04:11 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8BD14606E8; Thu, 30 Jan 2003 06:02: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 34A8B606E9 for <[e-mail]>; Thu, 30 Jan 2003 05:39:33 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0UAdVi23205 for [e-mail]; Thu, 30 Jan 2003 05:39:31 -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 h0UAcVC23037 for <[e-mail]>; Thu, 30 Jan 2003 05:38:31 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Draft 19 - Issue 24 
Date: Thu, 30 Jan 2003 05:38:29 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft 19 - Issue 24
Thread-Index: AcLF7qVNx5ey8mDDRWe9mqC0lwrxDwBt2B4g
From: "Susan Hares" <[e-mail]>
To: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
Cc: <[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 JAA04435

Siva and idr-list

When I floated example text in these 
3 events on draft-15 through draft-18,
I receive private concerns on the draft-15 to
draft-18 - so I left it out to get consensus. 

Any strong comments on an adding an example
to this item? 

Sue

-----Original Message-----
From: Sivananda Ramnath - CTD, Chennai. [mailto:[e-mail]]
Sent: Monday, January 27, 2003 5:29 AM
To: Susan Hares
Cc: Sivananda Ramnath (E-mail)
Subject: Draft 19 - Issue 24


Hello,

    The revisions you have included are fine.

    Is it within the scope of the text to give examples of when Events 3, 5,
and 6 occur ?
    If not, we can consider this issue closed.

    If you think examples can be included, here is some text:

%  Event 3:
%   Examples of this event are:
%   When a connection is terminated during exchange of Open
%   messages due to version failure

%  Event 5:
%   Examples of this event are:
%   Similar to Event 3

%  Event 6:
%   Examples of this event are:
%   Similar to Event 3 and
%   b) When a Idle Hold timer expires (within local limit)

Siva
([e-mail])


> Siva:
> 
> I believe we have consensus on issue 24.  I've added the
> example for an automatic stop to the event description.
> 
> New text:
> 
>    
>     Event7: Automatic stop
>    
>            Definition: Local system automatically stops the
>                        BGP connection.   
> 
>                        An example of an automatic stop event is
>                        exceeding the number of prefixes for a given
>                        peer and the local system  automatically
>                        disconnecting the peer.
> 
>    	
>            Status:     Optional depending on local system
>    
> Please confirm that we have consensus on this issue.
> 
> 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 HAA26948 for <[e-mail]>; Thu, 30 Jan 2003 07:16:34 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1DCA091218; Thu, 30 Jan 2003 07:16:09 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8212B9121B; Thu, 30 Jan 2003 07:16: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 ABDCA91218 for <[e-mail]>; Thu, 30 Jan 2003 07:15:58 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C15F462A03; Thu, 30 Jan 2003 06:02: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 47FEA606EA for <[e-mail]>; Thu, 30 Jan 2003 05:39:33 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0UAdUd23219 for [e-mail]; Thu, 30 Jan 2003 05:39: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 h0UAcXC23064 for <[e-mail]>; Thu, 30 Jan 2003 05:38:33 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Draft 19 - Issue 44
Date: Thu, 30 Jan 2003 05:38:33 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft 19 - Issue 44
Thread-Index: AcLF/D7zsUJOOknDSomW2q5XJ0RV6gBwRPPA
From: "Susan Hares" <[e-mail]>
To: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>, <[e-mail]>
Cc: "Tom Petch" <[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 HAA26948

Siva:

Yes, we can change the "D" in state machine to a "y".

The issue is what if Connect state occurs and there is not
a TCP connection.  Should an OPEN with wrong version 
be accepted?  If the Open Delay flag is off, the connection
state should not be getting an Open.  The "D" action below
works for "open delay flag off".  

The "y" action you suggest can occur if the open delay
timer is on.  

If this is the issue, please confirm.

We could say: if open delay flag is on -> y action
		  if open delay flag is off -> D action 

Please let me know if this is the concern, and suggest
text.   

Thanks for looking through this state change 1 more Time (1MT).

Sue 


-----Original Message-----
From: Sivananda Ramnath - CTD, Chennai. [mailto:[e-mail]]
Sent: Monday, January 27, 2003 7:07 AM
To: Susan Hares
Cc: Sivananda Ramnath (E-mail)
Subject: Draft 19 - Issue 44


Hello,

    "Default event handling" was perhaps a poor choice of words.

    What I meant is this

    Event 23 (Notify Message Version error) only indicates a version
mismatch. By going through action sequence D, we will be performing peer
oscillation damping. Should we perform damping, since this is not really a
cause for persistent oscillation ?

    Also, since we have a distinct event to indicate a version error event,
can include text indicating that version negotiation processing should take
place upon receipt of this event ?

Siva
([e-mail])


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.

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


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA25944 for <[e-mail]>; Thu, 30 Jan 2003 07:07:53 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DC22491214; Thu, 30 Jan 2003 07:04:38 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA57A91218; Thu, 30 Jan 2003 07:03: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 DA75691214 for <[e-mail]>; Thu, 30 Jan 2003 07:01:39 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0A25B628C7; Thu, 30 Jan 2003 06:00: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 56D6A6068B for <[e-mail]>; Thu, 30 Jan 2003 05:39:09 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0UAd2323147 for [e-mail]; Thu, 30 Jan 2003 05:39:02 -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 h0UAcNC22982 for <[e-mail]>; Thu, 30 Jan 2003 05:38:23 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: issues 12 -  consensus & two changes - 2nd message
Date: Thu, 30 Jan 2003 05:38:22 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: issues 12 -  consensus & two changes
Thread-Index: AcLHvRi10WWaSnUZQsG7wB5GXCAO8A==
From: "Susan Hares" <[e-mail]>
To: "Tom Petch" <[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 HAA25944

Tom and idr: 

I believe issues 12 is in consensus. Please
ack the new text below.

Sue



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


Change 1:  new text

Active state - event 19 
 
    If an Open is received with the Open Delay timer is 
    running [Event 19], the local system 
        - clears the connect retry timer (cleared to zero),
        - stops and clears the Open Delay timer  
        - completes the BGP initialization, 
        - stops and clears the Open Delay timer
        - sends an OPEN message, 
	- send a Keepalive message,
	- if the hold timer value is non-zero,
		- starts the keepalive timer to initial value,  
		- resets the hold timer to the negotiated value,
	  else if the hold timer is zero
		- resets the keepalive timer (set to zero),
		- resets the hold timer to zero.

        - changes its state to OpenConfirm.

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

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

new Text:
    
     In response to the connect retry timer expires event [Event 
     9], the local system: 
        - drops the TCP connection, 
        - restarts the connect retry timer,
	- stops the Open Delay timer and resets the timer to zero,  
        - initiates a TCP connection to the other BGP peer, 
        - continues to listen for a connection that may be 
          initiated by the remote BGP peer, and
        - stays in Connect state.


     If the TCP connection fails [Event17], the local system:
         - restarts the connect retry timer, 
	 - stops the Open Delay timer and resets value to zero,
         - continues to listen for a connection that may be 
           initiated by the remote BGP peer, and
         - changes its state to Active. 
   
Sue Hares  


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA00250 for <[e-mail]>; Wed, 29 Jan 2003 15:44:24 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id EC0A991378; Wed, 29 Jan 2003 15:40:42 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3482D9137A; Wed, 29 Jan 2003 15:40: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 F361B91378 for <[e-mail]>; Wed, 29 Jan 2003 15:40:34 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D06D25DF0F; Wed, 29 Jan 2003 15:40:34 -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 A1A865DE6B for <[e-mail]>; Wed, 29 Jan 2003 15:40:34 -0500 (EST)
Received: by nomad.tcb.net (Postfix, from userid 500) id 309D055F62; Wed, 29 Jan 2003 13:40:34 -0700 (MST)
Received: from nomad.tcb.net (localhost [127.0.0.1]) by nomad.tcb.net (Postfix) with ESMTP id 2FFD33E83; Wed, 29 Jan 2003 13:40:34 -0700 (MST)
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4
To: Mailing List <[e-mail]>, [e-mail], [e-mail], [e-mail]
From: Danny McPherson <[e-mail]>
Reply-To: [e-mail]
Subject: GR/NSF Terminology
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 29 Jan 2003 13:40:29 -0700
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

[Folks, notice the cross-post...  Perhaps [e-mail]
should be the only one to receive replies, please try to respect this].
 
I think it'd be a good thing for all of the GR/NSF protocol extensions 
to employ a common set of terminology, instead of each using your own.
I believe the OSPF *WG* document currently does the best job with defining
terms, etc.., although I'm not sure it's sufficient or accommodates 
everything.  

I'd be willing to work on a "generic document" if need be, or would 
be happy if the current protocol-specific documents (i.e., BGP, IS-IS, 
OSPF, LDP, RSVP (dead?), VPN stuff, other?) would make some attempt to 
use the same terms.

Any comments?

-danny

> This is the start of a Working Group last call for
> draft-ietf-ospf-hitless-restart-05.txt, OSPF Hitless Restart.
> All comments must be sent to the OSPF list by Friday,
> February 8th, 2003.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ospf-hitless-restart-05.txt
> 
> My previous list posting on this WG last call was lost or
> filtering. My apologies if this is a duplicate.
> 
> Thanks,
> Acee & Rohit
> --
> Acee




Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA25793 for <[e-mail]>; Wed, 29 Jan 2003 14:46:37 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 15294913B1; Wed, 29 Jan 2003 14:41:18 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3804C913A8; Wed, 29 Jan 2003 14:40: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 2A2B091367 for <[e-mail]>; Wed, 29 Jan 2003 14:33:39 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 12DC15E01D; Wed, 29 Jan 2003 14:33:39 -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 A8AD45DE0F for <[e-mail]>; Wed, 29 Jan 2003 14:33:38 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0TJXMl10830; Wed, 29 Jan 2003 14:33: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 h0TJXIC10823; Wed, 29 Jan 2003 14:33:18 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h0TJXIL09786; Wed, 29 Jan 2003 14:33:18 -0500 (EST)
Date: Wed, 29 Jan 2003 14:33:18 -0500
From: Jeffrey Haas <[e-mail]>
To: Pedro Roque Marques <[e-mail]>
Cc: "Reddy, Sudhakar" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Question on constructing nexthop in MP_REACH_NLRI attribute
Message-ID: <[e-mail]>
References: <E7E13AAF2F3ED41197C100508BD6A3288E6EBA@india_exch.hyderabad.mindspeed.com> <[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 Wed, Jan 29, 2003 at 11:20:01AM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

To take a perhaps incorrect stab at this:

> Reddy, Sudhakar writes:
> 
> > Hi All, I have a question on constructing the next hop field in
> > MP_REACH_NLRI attributes. Section 3 of the RFC 2545 says that:
> 
> >         "A BGP speaker shall advertise to its peer in the Network
> > Address of NextHop field the global IPv6 address of the next hop,
> > potentially followed by the link-local IPv6 address of the next hop"
> 
> > Now my question is: In a scenario where two IPv6 clouds are
> > connected by a IPv4 network and the edge routers of both clouds
> > Router-A, and Router-B are dual stack routers:
> 
> > If Router A wants to send a MP-BGP update to Router-B, what nexthop
> > it should encode while sending update to its peer?. If it has to be
> > an IPv6 global address, how the intermediate routers in the IPv4
> > network will resolve this nexthop?.

Since they are disconnected IPv6 clouds where the intermediate transport
is ipv4, you need some sort of tunnel connecting the two clouds at
the border router.  The tunnel can be whatever.  If the tunnel tehchnology
presents to the ipv6 layer a normal ipv6 interface, you would send 
your global address of your side of the tunnel as expected.  
Since all routes are extremely likely to be first party routes,
you would also send the link local of your side of the tunnel.

-- 
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 OAA24462 for <[e-mail]>; Wed, 29 Jan 2003 14:22:49 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1C993913D7; Wed, 29 Jan 2003 14:21:55 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A646C913DB; Wed, 29 Jan 2003 14:21:54 -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 DC315913D7 for <[e-mail]>; Wed, 29 Jan 2003 14:20:02 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 49ED55E025; Wed, 29 Jan 2003 14:20:02 -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 D12F95E01D for <[e-mail]>; Wed, 29 Jan 2003 14:20:01 -0500 (EST)
Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h0TJK1S43025; Wed, 29 Jan 2003 11:20:01 -0800 (PST) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h0TJK1h47033; Wed, 29 Jan 2003 11:20:01 -0800 (PST) (envelope-from roque)
Date: Wed, 29 Jan 2003 11:20:01 -0800 (PST)
Message-Id: <[e-mail]>
From: Pedro Roque Marques <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Reddy, Sudhakar" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Question on constructing nexthop in MP_REACH_NLRI attribute
In-Reply-To: <E7E13AAF2F3ED41197C100508BD6A3288E6EBA@india_exch.hyderabad.mindspeed.com>
References: <E7E13AAF2F3ED41197C100508BD6A3288E6EBA@india_exch.hyderabad.mindspeed.com>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: [e-mail]
Precedence: bulk

Reddy, Sudhakar writes:

> Hi All, I have a question on constructing the next hop field in
> MP_REACH_NLRI attributes. Section 3 of the RFC 2545 says that:

>         "A BGP speaker shall advertise to its peer in the Network
> Address of NextHop field the global IPv6 address of the next hop,
> potentially followed by the link-local IPv6 address of the next hop"

> Now my question is: In a scenario where two IPv6 clouds are
> connected by a IPv4 network and the edge routers of both clouds
> Router-A, and Router-B are dual stack routers:

> If Router A wants to send a MP-BGP update to Router-B, what nexthop
> it should encode while sending update to its peer?. If it has to be
> an IPv6 global address, how the intermediate routers in the IPv4
> network will resolve this nexthop?.

The intermediate ipv4 network should be no different than an
intermediate atm or frame network. All these tecnologies can provide
transport for IPv6 packets. On all of them the IPv6 interfaces would
use IPv6 addresses. Addresses which would be then advertised on an
eBGP session...

On point-to-point interfaces the link-local addresses are not required
or useful.

To be more specific, the requirement is that the address used as
non-local nexthio on an eBGP peering is an address that is significant
across the iBGP mesh of the receiving AS, since by default BGP
advertises such an address into iBGP.

Somehow i've the impression i didn't answer the right question
although...

  Pedro.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA21108 for <[e-mail]>; Wed, 29 Jan 2003 12:48:31 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 4AC3A91248; Wed, 29 Jan 2003 12:48:07 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E9779136E; Wed, 29 Jan 2003 12:48: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 3A1AF91383 for <[e-mail]>; Wed, 29 Jan 2003 12:47:55 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 5747F5E273; Wed, 29 Jan 2003 12:47:29 -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 0564D5DE0F for <[e-mail]>; Wed, 29 Jan 2003 12:47:29 -0500 (EST)
Received: from tom3 (userbq48.uk.uudial.com [62.188.146.142]) by colossus.systems.pipex.net (Postfix) with SMTP id 96E3016000943; Wed, 29 Jan 2003 17:47:26 +0000 (GMT)
Message-ID: <00d201c2c7be$42c1b560$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Jeffrey Haas" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: BGP Base Draft - Issue List v2.1 (Draft-19)
Date: Wed, 29 Jan 2003 17:41: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

Comments in line
Tom Petch
[e-mail]

-----Original Message-----
From: Jeffrey Haas <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Date: 28 January 2003 22:29
Subject: Re: BGP Base Draft - Issue List v2.1 (Draft-19)


>> -------------------------------------------------------------------
---------
>> 45) Event 17 in the Connect state
>> -------------------------------------------------------------------
---------
>> Tom then proposed this text:
>>
>>        If the TCP connection fails[Event 17] and the Open Delay
>>        timer is running, the local system:
>>            - restarts the connect retry timer,
>>            - clears the Open Delay timer
>>            - continues to listen for a connection that may be
>>               initiated by the remote BGP peer, and
>>            - changes its state to Active.
>>
>>         If the TCP connection fails [Event17] and the Open Delay
>>         timer is not running, the local system:
>>              - drops the TCP connection,
>>              - releases all BGP resources,
>
>There are no resources to release while in the connect state.
>(Unless we're using this as shorthand for something else - I forget.)


I was unsure about this action.  It is present for Active state event
17 which is why I put it in, it does include sub-actions such as clear
Open Delay timer (not running), clear Connect Retry timer (could be
running) so I think it right to play safe and include it.
>
>>              - sets ConnectRetryCnt (the connect retry count) to
zero
>
>I'm forgetting if this action is consistant with everything else.
>I don't have a current copy of the FSM and I don't trust -18 to be
>current enough. :-)
>
>This said, why do we go to zero?  I could see not incrementing it
>and letting the normal decay process deal with it.  The same would
>apply for the above.


Again, I was unsure about this so put it in and waited for comment.  I
have a chart of 27 events and 6 states in which I have colored in the
connect retry and peer oscillation damping actions and it looks like
measles; I could not divine the underlying logic.  Incrementing the
connect retry count would make as much if not more sense to me.  (It
is zeroed for Manual Stop).

But the action '[optionally] perform peer oscillation damping' is yet
more erratic (eg for
event 10 - Hold Timer expired - it is performed exiting Connect,
Active,
Established but not Open Confirm or Open Sent) so I left it out.
Again, it might make more sense put it in.

>>              - resets the connect retry timer (sets to zero), and
>>              - goes to Idle state.
>
>Sounds otherwise good.
>
>
>--
>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 FAA04906 for <[e-mail]>; Wed, 29 Jan 2003 05:06:56 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id EC83D9135C; Wed, 29 Jan 2003 05:03:48 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61DA69135E; Wed, 29 Jan 2003 05:03: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 CA3239135C for <[e-mail]>; Wed, 29 Jan 2003 05:03:16 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A522C5DF74; Wed, 29 Jan 2003 05:03:16 -0500 (EST)
Delivered-To: [e-mail]
Received: from xover.netplane.com (unknown [12.27.183.253]) by segue.merit.edu (Postfix) with ESMTP id 6AAB05DE39 for <[e-mail]>; Wed, 29 Jan 2003 05:03:16 -0500 (EST)
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <D59K72QM>; Wed, 29 Jan 2003 05:03:16 -0500
Message-ID: <E7E13AAF2F3ED41197C100508BD6A3288E6EBA@india_exch.hyderabad.mindspeed.com>
From: "Reddy, Sudhakar" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "Reddy, Sudhakar" <[e-mail]>
Subject:  Question on constructing nexthop in MP_REACH_NLRI attribute
Date: Wed, 29 Jan 2003 05:04:56 -0500
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

Hi All,
I have a question on constructing the next hop field in MP_REACH_NLRI
attributes. Section 3 
of the RFC 2545 says that:

        "A BGP speaker shall advertise to its peer in the Network Address of
NextHop field 
         the global IPv6 address of the next hop, potentially followed by
the link-local IPv6
         address of the next hop"

Now my question is:
In a scenario where two IPv6 clouds are connected by a IPv4 network and the
edge routers of 
both clouds Router-A, and Router-B are dual stack routers:

If Router A wants to send a MP-BGP update to Router-B, what nexthop it
should encode while 
sending update to its peer?. If it has to be an IPv6 global address, how the
intermediate routers 
in the IPv4 network will resolve this nexthop?.

Thanks,
Sudhakar
----------------------------------------------------------------------------
------------------
Sudhakar Reddy
mailto:[e-mail]
http://www.netplane.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 CAA28845 for <[e-mail]>; Wed, 29 Jan 2003 02:02:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id ACEBB9123F; Wed, 29 Jan 2003 02:01:00 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8891691321; Wed, 29 Jan 2003 02:00: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 4CEC09123F for <[e-mail]>; Wed, 29 Jan 2003 02:00:20 -0500 (EST)
Received: by segue.merit.edu (Postfix) id F3D705DDE3; Wed, 29 Jan 2003 02:00:20 -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 407F35DDD2 for <[e-mail]>; Wed, 29 Jan 2003 02:00:19 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id WAA15050; Tue, 28 Jan 2003 22:57:11 -0800 (PST)
Date: Tue, 28 Jan 2003 22:57:11 -0800
From: [e-mail]
To: Susan Hares <[e-mail]>
Cc: David Meyer <[e-mail]>, Randy Bush <[e-mail]>, [e-mail], [e-mail]
Subject: Re: please post draft-meyer-rfc1266-historic-00.txt
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 Tue, Jan 28, 2003 at 05:18:18PM -0500
Sender: [e-mail]
Precedence: bulk

Sue,

I don't think the status of BGP3 affects our RFP's in the least.  We could
care less if a vendor has BGP3 support, or EGP support for that matter.
And at this point, vendors should know that.  I certainly don't mind the
idea of cleaning up all the old documents, and I would second the suggestion
that we do a cleanup after we get some of the more pressing issues complete.

Andrew


On Tue, Jan 28, 2003 at 05:18:18PM -0500, Susan Hares wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
> Subject: RE: please post draft-meyer-rfc1266-historic-00.txt
> Date: Tue, 28 Jan 2003 17:18:18 -0500
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: please post draft-meyer-rfc1266-historic-00.txt
> Thread-Index: AcLHGNZdpSDt/fOrQCi6V1ep2DNZvQAAMkQQ
> From: "Susan Hares" <[e-mail]>
> To: "David Meyer" <[e-mail]>, "Randy Bush" <[e-mail]>
> Cc: <[e-mail]>, <[e-mail]>
> X-Virus-Scanned: by AMaViS perl-11
> Precedence: bulk
> X-Spam-Status: No, hits=0.3 required=5.0
> 	tests=AWL,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01
> 	version=2.43
> X-OriginalArrivalTime: 28 Jan 2003 22:22:38.0348 (UTC) FILETIME=[C3D6E4C0:01C2C71B]
> X-MIME-Autoconverted: from quoted-printable to 8bit by xix-w.bengi.exodus.net id h0SM4kZ04308
> 
> Dave and Randy: 
> 
> Does historic hurt carrier's and
> RPF process or does it help?  If it is neutral
> do it to as time allows. 
> 
> Dave and other operators...
> let us know if historic helps you in your
> RFPs.  
> 
> Sue
> 
> 
> -----Original Message-----
> From: David Meyer [mailto:[e-mail]]
> Sent: Tuesday, January 28, 2003 5:01 PM
> To: Randy Bush
> Cc: [e-mail]; [e-mail]
> Subject: Re: please post draft-meyer-rfc1266-historic-00.txt
> 
> 
> >> i suspect that if we tried to make historic all unused protocols, the
> >> drafting and administrative load would be larger than that of new
> >> productive work.  then again, i could be talking through my hat as
> >> usual.
> 
> Nah, you make a very good point.
> 
> Dave


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA11329 for <[e-mail]>; Tue, 28 Jan 2003 17:45:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id ECE1491349; Tue, 28 Jan 2003 17:45:07 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B1909134B; Tue, 28 Jan 2003 17:45:06 -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 EA85E91349 for <[e-mail]>; Tue, 28 Jan 2003 17:45:03 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 336B55DF85; Tue, 28 Jan 2003 17:45:03 -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 213D45DF00 for <[e-mail]>; Tue, 28 Jan 2003 17:45:02 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0SMiYx89728; Tue, 28 Jan 2003 17:44:34 -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 h0SMiVC89721; Tue, 28 Jan 2003 17:44:31 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h0SMiUG21849; Tue, 28 Jan 2003 17:44:30 -0500 (EST)
Date: Tue, 28 Jan 2003 17:44:30 -0500
From: Jeffrey Haas <[e-mail]>
To: Curtis Villamizar <[e-mail]>
Cc: Randy Bush <[e-mail]>, [e-mail]
Subject: Re: please post draft-meyer-rfc1266-historic-00.txt
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 Tue, Jan 28, 2003 at 05:31:01PM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Jan 28, 2003 at 05:31:01PM -0500, Curtis Villamizar wrote:
> How about if after we update both rfc1771 and rfc1772, the WG puts
> together a list of considered harmful and should be moved to historic
> prior WG products.  A one time request to the IESG and RFC editor
> should not be overwhelming.  BGP3 is just as historic as EGP.

Fine words of wisdom.

> Curtis

-- 
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 RAA11077 for <[e-mail]>; Tue, 28 Jan 2003 17:37:28 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 677E691356; Tue, 28 Jan 2003 17:34:34 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58CA591349; Tue, 28 Jan 2003 17:34: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 C4ADB91356 for <[e-mail]>; Tue, 28 Jan 2003 17:33:48 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A0A045DE19; Tue, 28 Jan 2003 17:33:48 -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 163145DD9F for <[e-mail]>; Tue, 28 Jan 2003 17:33:48 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0SMXlt89463 for [e-mail]; Tue, 28 Jan 2003 17:33:47 -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 h0SMXiC89456 for <[e-mail]>; Tue, 28 Jan 2003 17:33:44 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h0SMXix20735 for [e-mail]; Tue, 28 Jan 2003 17:33:44 -0500 (EST)
Date: Tue, 28 Jan 2003 17:33:44 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: RE: please post draft-meyer-rfc1266-historic-00.txt
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

A somewhat random observation.

Since we have decided that atomic aggregate is slightly broken in
some circumstances from the original intent (at least for the circumstances
on which we probably should set it), this affects bgp-4's interopability
with bgp-3 where we have:

bgp-4 -> bgp-3 -> bgp-4

As far as I know, no one still runs bgp-3 and connects to the Internet.

Given the potential issue, perhaps a move to historic wouldn't hurt.

And then again, maybe we have better things to do - even though this
shouldn't take much time at the WG level.

-- 
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 RAA10778 for <[e-mail]>; Tue, 28 Jan 2003 17:31:37 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 635869134D; Tue, 28 Jan 2003 17:30:21 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AAF289134B; Tue, 28 Jan 2003 17:30: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 A3A179134D for <[e-mail]>; Tue, 28 Jan 2003 17:30:17 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C2A5B5DF00; Tue, 28 Jan 2003 17:30:16 -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 9601C5DDFD for <[e-mail]>; Tue, 28 Jan 2003 17:30:15 -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 RAA27312; Tue, 28 Jan 2003 17:31:01 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: Randy Bush <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: please post draft-meyer-rfc1266-historic-00.txt 
In-reply-to: Your message of "Tue, 28 Jan 2003 16:56:47 EST." <[e-mail]> 
Date: Tue, 28 Jan 2003 17:31:01 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Jeffrey Haas writes:
> It does, however, prevent someone from writing a "BGP-3 considered harmful"
> draft. 
> 
> 1/2 ;-)
> 
> On Tue, Jan 28, 2003 at 01:54:34PM -0800, Randy Bush wrote:
> > i suspect that if we tried to make historic all unused protocols, the
> > drafting and administrative load would be larger than that of new
> > productive work.  then again, i could be talking through my hat as
> > usual.
> 
> -- 
> Jeff Haas 
> NextHop Technologies


How about if after we update both rfc1771 and rfc1772, the WG puts
together a list of considered harmful and should be moved to historic
prior WG products.  A one time request to the IESG and RFC editor
should not be overwhelming.  BGP3 is just as historic as EGP.

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 RAA10629 for <[e-mail]>; Tue, 28 Jan 2003 17:29:57 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 9A08791348; Tue, 28 Jan 2003 17:29:45 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 630C391349; Tue, 28 Jan 2003 17:29: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 1AB1791348 for <[e-mail]>; Tue, 28 Jan 2003 17:29:44 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 046E35DF00; Tue, 28 Jan 2003 17:29:44 -0500 (EST)
Delivered-To: [e-mail]
Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by segue.merit.edu (Postfix) with ESMTP id 556415DDFD for <[e-mail]>; Tue, 28 Jan 2003 17:29:43 -0500 (EST)
Received: (from dmm@localhost) by sith.maoz.com (8.12.6/8.12.6) id h0SMTLC1011692; Tue, 28 Jan 2003 14:29:21 -0800
Date: Tue, 28 Jan 2003 14:29:21 -0800
From: David Meyer <[e-mail]>
To: Susan Hares <[e-mail]>
Cc: Randy Bush <[e-mail]>, [e-mail], [e-mail]
Subject: Re: please post draft-meyer-rfc1266-historic-00.txt
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.5.1i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Jan 28, 2003 at 05:18:18PM -0500
Sender: [e-mail]
Precedence: bulk

	Sue,

>> Does historic hurt carrier's and
>> RPF process or does it help?  If it is neutral
>> do it to as time allows. 

	I would say historic can help, in the following way: If
	vendor X decides that they have to implement BGP-3
	because it's a possible check box (and implements it),
	then I (as a carrier) am hurt because of the extra,
	potentially unused code that I have to carry. Of course,
	this assumes that vendor X's s/w architecture requires
	that I have to do so. Minimally, I am hurt if vendor X
	put s/w engineering cycles to BGP-3 (or similar), if for
	no other reason that it will ultimately wind up in the 
	cost of X's product (there are, of course, many other
	ways unused code can wind up hurting). 

>> Dave and other operators...
>> let us know if historic helps you in your
>> RFPs.  

	From the point of view of just building an RFP, yes, it
	would help in that it would provide one less possible
	(however optional) check box.

	All of that being said, I can see Randy's point.  

	Dave


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA10603 for <[e-mail]>; Tue, 28 Jan 2003 17:29:21 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 70EA591227; Tue, 28 Jan 2003 17:29:00 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40C8091348; Tue, 28 Jan 2003 17:29:00 -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 2C71491227 for <[e-mail]>; Tue, 28 Jan 2003 17:28:59 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 19F065DF4E; Tue, 28 Jan 2003 17:28:59 -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 B1A0A5DD9F for <[e-mail]>; Tue, 28 Jan 2003 17:28:58 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0SMSqW89279; Tue, 28 Jan 2003 17:28: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 h0SMSmC89271; Tue, 28 Jan 2003 17:28:48 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h0SMSmX20360; Tue, 28 Jan 2003 17:28:48 -0500 (EST)
Date: Tue, 28 Jan 2003 17:28:48 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: BGP Base Draft - Issue List v2.1 (Draft-19)
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 Mon, Jan 20, 2003 at 05:01:14PM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

> ----------------------------------------------------------------------------
> 45) Event 17 in the Connect state
> ----------------------------------------------------------------------------
> Tom then proposed this text:
> 
>        If the TCP connection fails[Event 17] and the Open Delay
>        timer is running, the local system:
>            - restarts the connect retry timer,
>            - clears the Open Delay timer
>            - continues to listen for a connection that may be
>               initiated by the remote BGP peer, and
>            - changes its state to Active.
> 
>         If the TCP connection fails [Event17] and the Open Delay
>         timer is not running, the local system:
>              - drops the TCP connection,
>              - releases all BGP resources,

There are no resources to release while in the connect state.
(Unless we're using this as shorthand for something else - I forget.)

>              - sets ConnectRetryCnt (the connect retry count) to zero

I'm forgetting if this action is consistant with everything else.
I don't have a current copy of the FSM and I don't trust -18 to be
current enough. :-)

This said, why do we go to zero?  I could see not incrementing it
and letting the normal decay process deal with it.  The same would
apply for the above.

>              - resets the connect retry timer (sets to zero), and
>              - goes to Idle state.

Sounds otherwise good.


-- 
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 RAA10393 for <[e-mail]>; Tue, 28 Jan 2003 17:22:46 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D68F69120E; Tue, 28 Jan 2003 17:20:54 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53F659134B; Tue, 28 Jan 2003 17:20:49 -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 F151E9120E for <[e-mail]>; Tue, 28 Jan 2003 17:18:36 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D60D95DDFD; Tue, 28 Jan 2003 17:18:36 -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 00A725DD9F for <[e-mail]>; Tue, 28 Jan 2003 17:18:35 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0SMIYV88980 for [e-mail]; Tue, 28 Jan 2003 17:18:34 -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 h0SMIIC88930 for <[e-mail]>; Tue, 28 Jan 2003 17:18:18 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: please post draft-meyer-rfc1266-historic-00.txt
Date: Tue, 28 Jan 2003 17:18:18 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: please post draft-meyer-rfc1266-historic-00.txt
Thread-Index: AcLHGNZdpSDt/fOrQCi6V1ep2DNZvQAAMkQQ
From: "Susan Hares" <[e-mail]>
To: "David Meyer" <[e-mail]>, "Randy Bush" <[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 RAA10393

Dave and Randy: 

Does historic hurt carrier's and
RPF process or does it help?  If it is neutral
do it to as time allows. 

Dave and other operators...
let us know if historic helps you in your
RFPs.  

Sue


-----Original Message-----
From: David Meyer [mailto:[e-mail]]
Sent: Tuesday, January 28, 2003 5:01 PM
To: Randy Bush
Cc: [e-mail]; [e-mail]
Subject: Re: please post draft-meyer-rfc1266-historic-00.txt


>> i suspect that if we tried to make historic all unused protocols, the
>> drafting and administrative load would be larger than that of new
>> productive work.  then again, i could be talking through my hat as
>> usual.

Nah, you make a very good point.

Dave


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA09893 for <[e-mail]>; Tue, 28 Jan 2003 17:10:48 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BA82F91352; Tue, 28 Jan 2003 17:06:43 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F5749134B; Tue, 28 Jan 2003 17: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 229BD91352 for <[e-mail]>; Tue, 28 Jan 2003 17:06:30 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0A6835DEDD; Tue, 28 Jan 2003 17:06:30 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id D6BCD5DD9E for <[e-mail]>; Tue, 28 Jan 2003 17:06:29 -0500 (EST)
Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 18dds4-000EhI-00; Tue, 28 Jan 2003 14:06:20 -0800
Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18dds2-0001p4-00; Tue, 28 Jan 2003 14:06:18 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Curtis Villamizar <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: please post draft-meyer-rfc1266-historic-00.txt 
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 28 Jan 2003 14:06:18 -0800
Sender: [e-mail]
Precedence: bulk

> Cleanup wouldn't hurt.

productive work would help.  we can choose how we spend our time.



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA09770 for <[e-mail]>; Tue, 28 Jan 2003 17:07:18 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 88F8A9134C; Tue, 28 Jan 2003 17:06:36 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 739269134F; Tue, 28 Jan 2003 17:06: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 D3F5391349 for <[e-mail]>; Tue, 28 Jan 2003 17:05:28 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B9E425DEBA; Tue, 28 Jan 2003 17:05:28 -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 5F2115DE98 for <[e-mail]>; Tue, 28 Jan 2003 17:05:28 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0SM5QC88451; Tue, 28 Jan 2003 17:05:26 -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 h0SM5MC88444; Tue, 28 Jan 2003 17:05:22 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h0SM5M819077; Tue, 28 Jan 2003 17:05:22 -0500 (EST)
Date: Tue, 28 Jan 2003 17:05:22 -0500
From: Jeffrey Haas <[e-mail]>
To: Tom Petch <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 26 BGP Base Draft - Issue List v2.0 (Draft-19)
Message-ID: <[e-mail]>
References: <003901c2aa95$2f143e20$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: <003901c2aa95$2f143e20$0301a8c0@tom3>; from [e-mail] on Mon, Dec 23, 2002 at 03:06:42PM -0000
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Dec 23, 2002 at 03:06:42PM -0000, Tom Petch wrote:
> 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?

>From the current draft:
       The start events [Event 1, 3-6] are ignored in connect
       state.

       The start events [Event1, 3-6] are ignored in the Active
       state.

       The Start events [Event1, 3-6] are ignored in the OpenSent
       state.

       Any start event [Event1, 3-6] is ignored in the OpenConfirm
       state.

       Any start event (Event 1, 3-6) is ignored in the
       Established state.

> 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.

"ignore" means do nothing.  This means don't twiddle with the flags. :-)

-- 
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 RAA09602 for <[e-mail]>; Tue, 28 Jan 2003 17:01:44 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 41A0691351; Tue, 28 Jan 2003 17:01:01 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B88ED91355; Tue, 28 Jan 2003 17:01:00 -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 CEAA791351 for <[e-mail]>; Tue, 28 Jan 2003 17:00:53 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 90D485DD9E; Tue, 28 Jan 2003 17:00:50 -0500 (EST)
Delivered-To: [e-mail]
Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by segue.merit.edu (Postfix) with ESMTP id C15885DEDD for <[e-mail]>; Tue, 28 Jan 2003 17:00:49 -0500 (EST)
Received: (from dmm@localhost) by sith.maoz.com (8.12.6/8.12.6) id h0SM1HVK011342; Tue, 28 Jan 2003 14:01:17 -0800
Date: Tue, 28 Jan 2003 14:01:17 -0800
From: David Meyer <[e-mail]>
To: Randy Bush <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: please post draft-meyer-rfc1266-historic-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Jan 28, 2003 at 01:54:34PM -0800
Sender: [e-mail]
Precedence: bulk

>> i suspect that if we tried to make historic all unused protocols, the
>> drafting and administrative load would be larger than that of new
>> productive work.  then again, i could be talking through my hat as
>> usual.

Nah, you make a very good point.

Dave


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA09394 for <[e-mail]>; Tue, 28 Jan 2003 16:57:19 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6C9499134A; Tue, 28 Jan 2003 16:56:57 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D31091349; Tue, 28 Jan 2003 16:56:57 -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 2EAEA91347 for <[e-mail]>; Tue, 28 Jan 2003 16:56:55 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1F8895DE1E; Tue, 28 Jan 2003 16:56:55 -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 896355DD9E for <[e-mail]>; Tue, 28 Jan 2003 16:56:54 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0SLuqN88149; Tue, 28 Jan 2003 16:56: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 h0SLulC88133; Tue, 28 Jan 2003 16:56:47 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h0SLulM17909; Tue, 28 Jan 2003 16:56:47 -0500 (EST)
Date: Tue, 28 Jan 2003 16:56:47 -0500
From: Jeffrey Haas <[e-mail]>
To: Randy Bush <[e-mail]>
Cc: [e-mail]
Subject: Re: please post draft-meyer-rfc1266-historic-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[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 Tue, Jan 28, 2003 at 01:54:34PM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

It does, however, prevent someone from writing a "BGP-3 considered harmful"
draft. 

1/2 ;-)

On Tue, Jan 28, 2003 at 01:54:34PM -0800, Randy Bush wrote:
> i suspect that if we tried to make historic all unused protocols, the
> drafting and administrative load would be larger than that of new
> productive work.  then again, i could be talking through my hat as
> usual.

-- 
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 QAA09378 for <[e-mail]>; Tue, 28 Jan 2003 16:56:59 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 3B7C491346; Tue, 28 Jan 2003 16:56:39 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0075991347; Tue, 28 Jan 2003 16:56:38 -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 84BA391346 for <[e-mail]>; Tue, 28 Jan 2003 16:56:35 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 71C915DEB0; Tue, 28 Jan 2003 16:56: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 A74945DE1E for <[e-mail]>; Tue, 28 Jan 2003 16:56: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 QAA26739; Tue, 28 Jan 2003 16:57:13 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Randy Bush <[e-mail]>
Cc: David Meyer <[e-mail]>, [e-mail], [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: please post draft-meyer-rfc1266-historic-00.txt 
In-reply-to: Your message of "Tue, 28 Jan 2003 13:32:12 PST." <[e-mail]> 
Date: Tue, 28 Jan 2003 16:57:13 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Randy Bush writes:
> there are many protocols which are no longer used.  there is a feeling
> that they should only be moved to historic if their seeming current
> could lead to damage.
> 
> randy


Cleanup wouldn't hurt.

RFC1772 could be move to historic but it hasn't yet been replaced.  :(

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 QAA09359 for <[e-mail]>; Tue, 28 Jan 2003 16:56:36 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 7197191345; Tue, 28 Jan 2003 16:56:18 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 368B491346; Tue, 28 Jan 2003 16:56: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 1EF0291345 for <[e-mail]>; Tue, 28 Jan 2003 16:56:17 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0D3C75DE1E; Tue, 28 Jan 2003 16:56:17 -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 7154C5DEB0 for <[e-mail]>; Tue, 28 Jan 2003 16:56:16 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0SLuC788049; Tue, 28 Jan 2003 16:56:12 -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 h0SLtvC88014; Tue, 28 Jan 2003 16:55:57 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h0SLtul17762; Tue, 28 Jan 2003 16:55:56 -0500 (EST)
Date: Tue, 28 Jan 2003 16:55:56 -0500
From: Jeffrey Haas <[e-mail]>
To: Tom Petch <[e-mail]>
Cc: Susan Hares <[e-mail]>, idr <[e-mail]>
Subject: Re: BGP-draft-19: Issue 40 Clear Connect retry timer
Message-ID: <[e-mail]>
References: <001e01c2c634$311bcde0$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: <001e01c2c634$311bcde0$0301a8c0@tom3>; from [e-mail] on Mon, Jan 27, 2003 at 06:40:02PM -0000
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

I would tend to agree.

I would suggest, Sue, that when all is said and done that actions that
are commonly taken in a given order be grouped together to make it
obvious that "this cluster of things happens more than once".  This
was present in some of your previous versions I helped you review. :-)

On Mon, Jan 27, 2003 at 06:40:02PM -0000, Tom Petch wrote:
> Issue 40, outstanding, no consensus, suggests removing the action
> 'clear connect retry timer' from many places since the action is not
> needed there.
> 
> I propose we leave it in and close this issue.

-- 
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 QAA09301 for <[e-mail]>; Tue, 28 Jan 2003 16:54:59 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A924C91344; Tue, 28 Jan 2003 16:54:40 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C10391345; Tue, 28 Jan 2003 16:54: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 7D0E691344 for <[e-mail]>; Tue, 28 Jan 2003 16:54:39 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 66FE75DE1E; Tue, 28 Jan 2003 16:54:39 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 3FA025DD9E for <[e-mail]>; Tue, 28 Jan 2003 16:54:39 -0500 (EST)
Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 18ddgh-000E4F-00; Tue, 28 Jan 2003 13:54:36 -0800
Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18ddgg-0001oP-00; Tue, 28 Jan 2003 13:54:34 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: David Meyer <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: please post draft-meyer-rfc1266-historic-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 28 Jan 2003 13:54:34 -0800
Sender: [e-mail]
Precedence: bulk

i suspect that if we tried to make historic all unused protocols, the
drafting and administrative load would be larger than that of new
productive work.  then again, i could be talking through my hat as
usual.

randy



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA09250 for <[e-mail]>; Tue, 28 Jan 2003 16:53:38 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2E60A9133F; Tue, 28 Jan 2003 16:53:16 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFB9191344; Tue, 28 Jan 2003 16:53: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 D7F3F9133F for <[e-mail]>; Tue, 28 Jan 2003 16:53:14 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C994C5DEB0; Tue, 28 Jan 2003 16:53:14 -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 6E6FF5DD9E for <[e-mail]>; Tue, 28 Jan 2003 16:53:14 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0SLr7387862; Tue, 28 Jan 2003 16:53:07 -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 h0SLr4C87855; Tue, 28 Jan 2003 16:53:04 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h0SLr4u17358; Tue, 28 Jan 2003 16:53:04 -0500 (EST)
Date: Tue, 28 Jan 2003 16:53:04 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: BGP-19: Issue 34-35, 40-48
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 Tue, Jan 21, 2003 at 02:11:59PM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Jan 21, 2003 at 02:11:59PM -0800, [e-mail] wrote:
> > Issue 52 - 
> > 	status: non-consensus 
> > 
> > 		<----	Open [Open sent state]
> > 	open ---->  
> > 			[Event 18 in Open Sent 
> > 		<----- Keepalive 
> > 
> > 	Event 18:
> > 		- clears BGP delay timer
> > 		- resets BGP connect timer
> > 		- sends Keepalive message
> > 		- if negotiated hold timer is zero,
> > 			o reset keepalive timer,
> > 			o reset hold timer.
> > 
> > 		- if negotiated hold timer is non-zero
> > 			o set keepalive timer,
> > 			o set hold timer to negotiated value. 
> > 
> > 
> > 	Here the question is, do you want to send a 2nd
> > 	keepalive if the keepalive timer expires in 
> > 	Open Confirm.  
> > 
> >      The current draft allows this until the hold timer 
> >      expires.   The sequence would be:
> > 
> > 			<---- open [open sent]
> > 		open -->  [event 18]
> > 
> > 			<-----keepalive
> > 
> > 				[keepalive timeout [Event 11]
> > 			<---- Keepalive
> > 
> > 				[Keepalive time out [Event 11]
> > 			<--- Keepalive
> > 
> > 				[hold time-out, Event 10]
> > 			<---Notification
> > 			    drop TCP connection
> 
> I think we're waiting for more implementor's responses on this one.

GateD will start its keepalive timer while in this state, so multiple
keepalives will be sent.

As someone previously said, this is a "yawn" issue.  But to choose one
way or the other, we may potentially make someone in non-compliance.

Does anyone else care to respond on their implementation's behavior?

> Andrew

-- 
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 QAA09208 for <[e-mail]>; Tue, 28 Jan 2003 16:52:27 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E4CA091209; Tue, 28 Jan 2003 16:51:24 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B0F39133F; Tue, 28 Jan 2003 16:51:21 -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 6F3F291209 for <[e-mail]>; Tue, 28 Jan 2003 16:51:17 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 55A035DEB0; Tue, 28 Jan 2003 16:51:17 -0500 (EST)
Delivered-To: [e-mail]
Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by segue.merit.edu (Postfix) with ESMTP id 9A3515DE1E for <[e-mail]>; Tue, 28 Jan 2003 16:51:16 -0500 (EST)
Received: (from dmm@localhost) by sith.maoz.com (8.12.6/8.12.6) id h0SLpY9V011205; Tue, 28 Jan 2003 13:51:34 -0800
Date: Tue, 28 Jan 2003 13:51:34 -0800
From: David Meyer <[e-mail]>
To: Randy Bush <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: please post draft-meyer-rfc1266-historic-00.txt
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.5.1i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Jan 28, 2003 at 01:32:12PM -0800
Sender: [e-mail]
Precedence: bulk

Randy,

>> there are many protocols which are no longer used.  there is a feeling
>> that they should only be moved to historic if their seeming current
>> could lead to damage.

Got it, thanks. Maybe it's not worth doing these then. We can
just leave it as is.

Dave


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA08577 for <[e-mail]>; Tue, 28 Jan 2003 16:33:31 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id F18C391342; Tue, 28 Jan 2003 16:32:25 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E6DF91343; Tue, 28 Jan 2003 16:32:21 -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 8BE4291342 for <[e-mail]>; Tue, 28 Jan 2003 16:32:19 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 788825DE74; Tue, 28 Jan 2003 16:32:19 -0500 (EST)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 508B55DE1E for <[e-mail]>; Tue, 28 Jan 2003 16:32:19 -0500 (EST)
Received: from roam.psg.com ([147.28.4.2]) by psg.com with esmtp (Exim 3.36 #1) id 18ddL4-000Czn-00; Tue, 28 Jan 2003 13:32:14 -0800
Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.12) id 18ddL2-0001mA-00; Tue, 28 Jan 2003 13:32:12 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: David Meyer <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: please post draft-meyer-rfc1266-historic-00.txt
References: <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 28 Jan 2003 13:32:12 -0800
Sender: [e-mail]
Precedence: bulk

there are many protocols which are no longer used.  there is a feeling
that they should only be moved to historic if their seeming current
could lead to damage.

randy



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA08239 for <[e-mail]>; Tue, 28 Jan 2003 16:24:50 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 446E59133D; Tue, 28 Jan 2003 16:24:35 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB2B19133F; Tue, 28 Jan 2003 16:24: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 D839A9133C for <[e-mail]>; Tue, 28 Jan 2003 16:24:32 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1173C5DF28; Tue, 28 Jan 2003 16:24:30 -0500 (EST)
Delivered-To: [e-mail]
Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by segue.merit.edu (Postfix) with ESMTP id 87F345DF44 for <[e-mail]>; Tue, 28 Jan 2003 16:24:27 -0500 (EST)
Received: (from dmm@localhost) by sith.maoz.com (8.12.6/8.12.6) id h0SLOml9011040; Tue, 28 Jan 2003 13:24:48 -0800
Date: Tue, 28 Jan 2003 13:24:48 -0800
Message-Id: <[e-mail]>
From: David Meyer <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: please post draft-meyer-rfc1266-historic-00.txt
Sender: [e-mail]
Precedence: bulk

	Thanks,

	Dave

-----
INTERNET-DRAFT                                               David Meyer
draft-meyer-rfc1266-historic-00.txt                          Keyur Patel
2003.07.28                         
 
 
                Request to Move RFC1266 to Historic Status
 
     Copyright (C) The Internet Society (2003).  All Rights Reserved.
 
 
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt
 
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
 0. Abstract

    RFC1266 [RFC1266], "Experience with the BGP Protocol" documents how 
    the requirements for advancing a routing protocol to Draft
    Standard have been satisfied by a BGP-3, a technology which
    is no longer commonly used. This document requests that RFC
    1266 be moved to historic status.   
 
 1. Details
 
    During a review of internet standards relating to BGP, it became
    apparent that the Experience with BGP-3 Protocol, as described in 
    RFC1266, is not common usage (if at all). Since this protocol has not
    been in use in the public internet for many years (it is obsoleted by
    BGP-4 [RFC1774]), it is proposed to reclassify it to historic.
 
 
 Patel, Meyer                Expires 2003.08.08                   [Page 1]     
 
 INTERNET-DRAFT  Request to Move RFC1266 to Historic Status     2003.07.28
 
 
 2. Security Considerations
 
    Moving RFC1266 to historic has no known effect on the security of the
    internet.
 
 3. References
 
    [RFC1774]	P. Traina (Editors) "BGP-4 Protocol Analysis"
                March, 1995.
 		
 
 4. Authors' Addresses
 
    David Meyer
    Email: [e-mail]
 
    Keyur Patel
    Email: [e-mail]

 5. Full Copyright Statement
 
   Copyright (C) The Internet Society (2003).  All Rights Reserved.
 
    This document and translations of it may be copied and furnished to others,
    and derivative works that comment on or otherwise explain it or assist in
    its implementation may be prepared, copied, published and distributed, in
    whole or in part, without restriction of any kind, provided that the above
    copyright notice and this paragraph are included on all such copies and
    derivative works.  However, this document itself may not be modified in any
    way, such as by removing the copyright notice or references to the Internet
    Society or other Internet organizations, except as needed for the purpose of
    developing Internet standards in which case the procedures for copyrights
    defined in the Internet Standards process must be followed, or as required
    to translate it into languages other than English.
 
    The limited permissions granted above are perpetual and will not be revoked
    by the Internet Society or its successors or assigns.
 
    This document and the information contained herein is provided on an "AS IS"
    basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
    DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
    ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
 
 

 Meyer, Patel                Expires 2003.08.08                   [Page 2]
 
 INTERNET-DRAFT  Request to Move RFC1266 to Historic Status     2003.07.28
 
 
    RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
    PARTICULAR PURPOSE.
 
 
 
 
 
 
 

 

 


 
 

 
 

 
 
 

 
 
 




 

 
 
 
 

 
 
 
 
 
 
 
 
 
 
 Patel, Meyer                 Expires 2003.08.08                  [Page 3]    


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA08207 for <[e-mail]>; Tue, 28 Jan 2003 16:24:05 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D3C6C9120D; Tue, 28 Jan 2003 16:23:43 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3ACD91339; Tue, 28 Jan 2003 16:23: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 25BF39120D for <[e-mail]>; Tue, 28 Jan 2003 16:23:42 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0D3475DEC6; Tue, 28 Jan 2003 16:23:42 -0500 (EST)
Delivered-To: [e-mail]
Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by segue.merit.edu (Postfix) with ESMTP id 9EADE5DE74 for <[e-mail]>; Tue, 28 Jan 2003 16:23:41 -0500 (EST)
Received: (from dmm@localhost) by sith.maoz.com (8.12.6/8.12.6) id h0SLNsYv011014; Tue, 28 Jan 2003 13:23:54 -0800
Date: Tue, 28 Jan 2003 13:23:54 -0800
Message-Id: <[e-mail]>
From: David Meyer <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: please post draft-meyer-rfc1265-historic-00.txt
Sender: [e-mail]
Precedence: bulk

	Thanks,

	Dave

-----
INTERNET-DRAFT                                               David Meyer
draft-meyer-rfc1265-historic-00.txt                          Keyur Patel
2003.07.28                         
 
 
                Request to Move RFC1265 to Historic Status
 
     Copyright (C) The Internet Society (2003).  All Rights Reserved.
 
 
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt
 
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.
 
 0. Abstract

    RFC1265 [RFC1265], "BGP protocol Analysis" documents how the 
    requirements for advancing a routing protocl to Draft Standard have 
    been satisfied by a BGP-3, a technology which is no longer commonly 
    used. This document requests that RFC 1265 be moved to historic status.  
 
 1. Details
 
    During a review of internet standards relating to BGP, it became
    apparent that the BGP-3 Protocol Analysis, as described in RFC1265, 
    is not common usage (if at all). Since this protcol has not been in
    use in the public internet for many years (it is obsoleted by
    BGP-4 [RFC1774]), it is proposed to reclassify it to historic.
 
 
 Meyer, Patel                Expires 2003.08.08                   [Page 1]
 
 INTERNET-DRAFT  Request to Move RFC1265 to Historic Status     2003.07.28
 
 
 2. Security Considerations
 
    Moving RFC1265 to historic has no known effect on the security of the
    internet.
 
 3. References
 
    [RFC1774]	P. Traina (Editors) "BGP-4 Protocol Analysis"
                March, 1995.
 		
 
 4. Authors' Addresses
 
    David Meyer
    Email: [e-mail]
 
    Keyur Patel
    Email: [e-mail]

 
 5. Full Copyright Statement
 
   Copyright (C) The Internet Society (2003).  All Rights Reserved.
 
    This document and translations of it may be copied and furnished to others,
    and derivative works that comment on or otherwise explain it or assist in
    its implementation may be prepared, copied, published and distributed, in
    whole or in part, without restriction of any kind, provided that the above
    copyright notice and this paragraph are included on all such copies and
    derivative works.  However, this document itself may not be modified in any
    way, such as by removing the copyright notice or references to the Internet
    Society or other Internet organizations, except as needed for the purpose of
    developing Internet standards in which case the procedures for copyrights
    defined in the Internet Standards process must be followed, or as required
    to translate it into languages other than English.
 
    The limited permissions granted above are perpetual and will not be revoked
    by the Internet Society or its successors or assigns.
 
    This document and the information contained herein is provided on an "AS IS"
    basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
    DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
    ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
 
 

 Meyer, Patel                Expires 2003.08.08                   [Page 2]
 
 INTERNET-DRAFT  Request to Move RFC1265 to Historic Status     2003.07.28
 
 
    RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
    PARTICULAR PURPOSE.
 
 
 
 
 
 
 

 

 


 
 

 
 

 
 
 

 
 
 




 

 
 
 
 

 
 
 
 
 
 
 
 
 
 
 Meyer                       Expires 2003.08.08                   [Page 3]


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA03328 for <[e-mail]>; Tue, 28 Jan 2003 14:07:20 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 9E09191354; Tue, 28 Jan 2003 14:02:49 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F4C391334; Tue, 28 Jan 2003 14:02: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 127D191354 for <[e-mail]>; Tue, 28 Jan 2003 14:02:37 -0500 (EST)
Received: by segue.merit.edu (Postfix) id ED1135DE74; Tue, 28 Jan 2003 14:02:35 -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 9E2825DDBA for <[e-mail]>; Tue, 28 Jan 2003 14:02:35 -0500 (EST)
Received: from tom3 (userca57.uk.uudial.com [62.188.150.125]) by shockwave.systems.pipex.net (Postfix) with SMTP id 7DA911600B775; Tue, 28 Jan 2003 19:02:33 +0000 (GMT)
Message-ID: <001401c2c6ff$97322040$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Susan Hares" <[e-mail]>, "idr" <[e-mail]>
Subject: Re: Draft bgp19 - issue #42 NOTIFICATION before OPEN
Date: Tue, 28 Jan 2003 19:00: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

Isssue 42 queries whether or not we can send a NOTIFICATION when we
have not sucessfully exchanged OPENs.  I propose we should, following
the suggestions of Jeff and Yakov.

As Yakov suggested, this requires the removal of the second sentence,
first paragraph, of 4.2 which implies a NOTIFICATION can only be sent
after a succesful exchange of OPENs.  I think this fits best with the
other references to the uses of NOTIFICATION in the draft.

In terms of the FSM, it means that in Connect and Active states, on
receipt of events 20 or 21, we should send a NOTIFICATION so that the
last section starting

In response to any other event.............

is replaced by (and noting we have agreed to drop references to MIB
actions)

If the BGP message header checking or OPEN message
       checking detect an error (see Section 6.2) [Events 20 or 21],
the local system:
             - sends a NOTIFICATION message with the appropriate error
code,
             - resets the connect retry timer (sets to zero),
             - releases all BGP resources,
             - drops the TCP connection
             - increments the ConnectRetryCnt (connect retry count) by
1,
             - [optionally] performs peer oscillation damping
             - and goes to the Idle state.

  In response to any other event (Events 7-8, 10-11,18, 22-27), the
local system:
              - resets the connect retry timer (sets to zero),
              - releases all BGP resources,
              - drops the TCP connection,
              - increments the ConnectRetryCnt (connect retry count)
by one,
             - [optionally] performs peer oscillation damping,
              - and goes to the Idle state

(Note that this text is not quite watertight.  Suppose we are in
Active state, having been started with CRT running, receive an SYN
(event 13), send SYN-ACK and then get a malformed message (events
20/21).  We have not yet received an ACK and so should not send
anything over TCP; I would expect TCP to buffer this awaiting the ACK
except we then take down the TCP connection - or try to; I don't know
what happens next but regard it as sufficiently obscure not to be
concerned).

(My other concern is greater; why do we now not send NOTIFICATIONs for
other events; in Open Sent, Open Confirm or Established, we send one
for the 'default event list' so what makes events 20 and 21 in Active
and Connect so special?  I can justify the absence of a NOTIFICATION
for events 7, 8, 10, 11, 18, 22 since there is no evidence of a TCP
connection to send it on; but events 23-27 in Active or Connect say we
have received an erroneous message, the TCP connection is there so why
not send a NOTIFICATION?
       Event7:  Automatic stop
       Event8:  Idle hold timer expires
       Event10: Hold timer expires
       Event11: Keepalive timer expires
       Event18: BGPOpen
       Event22: Open collision dump
       Event23: NotifMsgVerErr
       Event24: NotifMsg
       Event25: KeepAliveMsg
       Event26: UpdateMsg
       Event27: UpdateMsgErr

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 PAA12702 for <[e-mail]>; Mon, 27 Jan 2003 15:27:09 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E2933912FC; Mon, 27 Jan 2003 15:21:04 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0ADC091302; Mon, 27 Jan 2003 15:20: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 ED461912FF for <[e-mail]>; Mon, 27 Jan 2003 15:17:13 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B05365DEC2; Mon, 27 Jan 2003 15:17:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from web14104.mail.yahoo.com (web14104.mail.yahoo.com [216.136.172.134]) by segue.merit.edu (Postfix) with SMTP id 12EEE5DDD9 for <[e-mail]>; Mon, 27 Jan 2003 15:17:11 -0500 (EST)
Message-ID: <[e-mail]>
Received: from [47.234.0.51] by web14104.mail.yahoo.com via HTTP; Mon, 27 Jan 2003 12:17:10 PST
Date: Mon, 27 Jan 2003 12:17:10 -0800 (PST)
From: PamSri <[e-mail]>
Subject: Archieves for this mailing list 
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Hi ,
   Can someone point me to the archieves for this
mailing list, so that i can review some of the past
discussions.

Thanks

sri
 

__________________________________________________
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 NAA08315 for <[e-mail]>; Mon, 27 Jan 2003 13:50:03 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2D285912B7; Mon, 27 Jan 2003 13:47:54 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1654912BC; Mon, 27 Jan 2003 13:47: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 BA367912B7 for <[e-mail]>; Mon, 27 Jan 2003 13:46:35 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 9540C5DD91; Mon, 27 Jan 2003 13:46:35 -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 60A995DD8D for <[e-mail]>; Mon, 27 Jan 2003 13:46:35 -0500 (EST)
Received: from tom3 (usercq13.uk.uudial.com [62.188.156.141]) by shockwave.systems.pipex.net (Postfix) with SMTP id 0A04B160018B6; Mon, 27 Jan 2003 18:46:33 +0000 (GMT)
Message-ID: <001e01c2c634$311bcde0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Susan Hares" <[e-mail]>
Cc: "idr" <[e-mail]>
Subject: Re: BGP-draft-19: Issue 40 Clear Connect retry timer
Date: Mon, 27 Jan 2003 18:40:02 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

Issue 40, outstanding, no consensus, suggests removing the action
'clear connect retry timer' from many places since the action is not
needed there.

I propose we leave it in and close this issue.

1) To take out an action as redundant you need to be supremely
confident that it really cannot make a difference.  I am not
(supremely confident); rather, the more I look at the FSM, the more
places I find where actions are missing, as I have posted to the list,
from obscure yet possible sequences of events and timing.  And there
is an outstanding issue of mine which flagged seven places where the
next state was missing and so I think it impossible for any one to be
confident that any particular action is redundant until that is
cleared up and that is proving complex in some cases.

So, play safe, keep them in.

2) The argument for removing them is that the number of possible
distinct action lists is increased.  True - it will mean that an
implementor will have to code more code when first implementing BGP.

For me this is no contest; keeping it safe at the possible cost of
redundancy outweighs the one-off cost of additional implementation.

So keep the actions in and close the issue.

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 SAA15598 for <[e-mail]>; Fri, 24 Jan 2003 18:19:26 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5E79391250; Fri, 24 Jan 2003 18:18:57 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09A9091251; Fri, 24 Jan 2003 18:18: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 4A0F691250 for <[e-mail]>; Fri, 24 Jan 2003 18:18:54 -0500 (EST)
Received: by segue.merit.edu (Postfix) id CE8475E079; Fri, 24 Jan 2003 18:18:53 -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 25B7D5DFD0 for <[e-mail]>; Fri, 24 Jan 2003 18:18:52 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id PAA00482; Fri, 24 Jan 2003 15:15:55 -0800 (PST)
Date: Fri, 24 Jan 2003 15:15:55 -0800
From: [e-mail]
To: [e-mail], [e-mail]
Cc: [e-mail]
Subject: BGP Flexible Communities Draft
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="DIOMP1UsTsWJauNi"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: [e-mail]
Precedence: bulk

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

Greetings,

Attached is my proposal for third-generation BGP communities.  This is
a follow up to my presentation at the Yokohama meeting last summer. 
The draft incorporates some more ideas since that presentation, but the
core idea of having a variable length BGP community is the same. 
Comments are appreceated!  This should also show up in the internet-drafts
repository in a few days.

Andrew

--DIOMP1UsTsWJauNi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="draft-lange-flexible-communities-00.txt"







Internet Engineering Task Force                                 A. Lange
INTERNET DRAFT                                          Cable & Wireless
                                                           December 2002
                                                       Expires June 2003


                        Flexible BGP Communities
             <draft-lange-flexible-bgp-communities-00.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document defines a new attribute for BGP called the Flexible
   Community attribute.  Flexible Communities build on the experience
   and utility of the standard BGP community, and the extended BGP
   community attributes.  This attribute allows operators to associate
   structured information with a route or set of routes.  This
   information can be then be used to execute routing policy.  An
   enhanced version of communities is necessary to accomodate IPv6, 4-
   byte ASN's, and introduce a more extensible and flexible policy
   expression.  This document also introduces the concept of Neighbor
   Classes.  A Neighbor Class is applied to a group of BGP neighbors who
   share certain attributes.  For example, the PEER Neighbor Class could
   be applied to BGP sessions between ASN X and other networks with
   which ASN X has a non-transit peering relationship.





Lange                                                           [Page 1]

INTERNET DRAFT                                             December 2002


Table of Contents
   Status of this Memo.........................................   1
   Abstract....................................................   1
   1.  Introduction............................................   2
   2.  The BGP Flexible Community Attribute....................   3
   2.1  Transitivity Field.....................................   4
   2.2  Structure Field........................................   4
   2.3  Type Field.............................................   5
   2.4  Length Field...........................................   5
   3.  Locally Defined Structures and Types....................   5
   4.  Neighbor Classes........................................   6
   4.1  Locally Defined Neighbor Classes.......................   7
   4.2  Defined Neighbor Classes...............................   7
   5.  Defined Flexible BGP Community Structures...............   8
   6.  Base BGP Flexible Community Type (Opaque Type)..........   9
   7.  Defined Flexible BGP Community Types....................  10
   7.1  NO_EXPORT..............................................  10
   7.2  ONLY_EXPORT............................................  10
   7.3  ANNOUNCE_WITH..........................................  11
   7.4  PREPEND................................................  12
   7.5  The BGP VPN Communities................................  13
   8.  New Capability Code for Flexible Communities............  14
   9.  Aggregation.............................................  14
   10.  Operations.............................................  14
   11.  Security Considerations................................  15
   12.  IANA Considerations....................................  15
   13.  References.............................................  16
   14.  Acknowledgements.......................................  16
   15.  Author's Address.......................................  16

Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1. Introduction

   This attribute represents the third generation of the BGP community
   attribute.  The first generation is documented in RFC1997 [RFC1997].
   The second generation, the extended community, is documented in EX-
   COMM [EX-COMM].

   The Flexible Community Attribute provides a number of important
   enhancements over the existing BGP Community Attribute and BGP
   Extended Community Attribute.  These enhancements are:

     - Support for IPv6.



Lange                                                           [Page 2]

INTERNET DRAFT                                             December 2002


     - More efficent encoding of lists of data, for example, a list of
     ASNs.
     - Clean support for a broad range of future data field structures
     and interpretations.
     - Support for locally defined community structures, and
     interpretations.
     - Easy extensibility for a range of future applications.

   The continuation and expansion of the structure introduced with
   Extended Communities allows for policy based on the application where
   the community is being used.  The separation of structure and
   interpretation allows for easier machine and human parsing of
   community types which do the same thing with slightly different
   input.

   This attribute continues the use of the Transitivity community bit,
   first introduced in the Extended Community Attribute.

   We also define a set of well-known values for this attribute which
   can be used to replicate and extend the functionality of the existing
   well-known community values.

   The concept of Neighbor Classes is introduced.  A Neighbor Class is
   defined on a BGP peering session.  It allows neighbors that share a
   set of administrative attributes to be easily grouped together.
   Policy can then be defined through Flexible Communities in reference
   to these groupings.

2. The BGP Flexible Community Attribute

   The Flexible Community Attribute is a transitive optional BGP
   attribute with a Type Code of <TBD>.  The attribute consists of a
   list of "flexible communities."

   Each Flexible Community is encoded as a variable length quantity.
   The encoding scheme is:

     - Transitivity Field: 1 bit
     - Structure Field: 7 bits
     - Type Field: 2 octets
     - Length Field: 1 octet
     - Value Field: 0-255 octets

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|   Struct.   |             Type              |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Lange                                                           [Page 3]

INTERNET DRAFT                                             December 2002


      |                   Value Field  (0-255 octets)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   2.1. Transitivity Field:

   The Transitivity Field is one bit.  It can take the following values:

     Value 0: The community is transitive across ASes

     Value 1: The community is non-transitive across ASes

     It is important to note that the transitivity defined by this field
     is different from the general transitivity of a BGP attribute.  A
     single Flexible Community Attribute, can contain multiple Flexible
     Communties, each of which may or may not be transitive.  If a route
     originates in an AS with the transitivity bit set, indicating that
     the community is non-transitive, then that AS MUST NOT propagate
     that community to its peers.  However, if a community with the
     transitive bit set is applied on an outbound policy expression (eg,
     a route-map), the community will be conveyed to the immeditely
     adjacent peer.  That peer, in turn, will NOT propagate the
     community to its peers.  The one exception to this is as-
     confederations.  For the purposes of this attribute, confederation
     boundaries should be treated the same as IBGP.  In other words,
     non-transitive flexible communities should be propagated to other
     members of the as-confederation, unless overridden by local policy.

   If the community is transitive, then the Value Field MUST contain the
   originating ASN.  This ASN is encoded as a 4-octet value, occuping
   the first 4 octets of the Value Field.  Two-octet ASN numbers are
   padded out to 4 octets.  Any additional information in the Value
   Field comes after this origin ASN data.

   2.2. Structure Field:

     The Structure Field's contents modify the Type Field.  For example,
     a Flexible Community which specifies SPECIFIC_NO_EXPORT in its Type
     Field, can be modified by the contents of the Structure Field to
     let the receiver know if the list of data on which it must act is a
     list of 2 octet or 4 octet ASNs.  A set of commonly used Structure
     values is defined later in this document.

     The Structure field is the latter 7 bits of the first octet.  It is
     split into two sub-fields.

        0
        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+



Lange                                                           [Page 4]

INTERNET DRAFT                                             December 2002


       |T|L|  Struct.  |
       +-+-+-+-+-+-+-+-+

     L - Local bit

     The Local bit can take two values:

       Value 0: The Structure is Locally Defined.

       Value 1: The Structure is Well Known.

   2.3. Type Field:

     The Type Field is two octets.  This contents of this field are used
     to define an action for the recepient to take on the route, or to
     define and attribute that is related to that route.  An example of
     the former would be a Type which requests that a route be
     ONLY_EXPORTed to a specific set of peers. An example of the latter
     woudl be a Type that defines the LINK_BANDWIDTH associated with a
     certain NLRI.

     Like the Structure Field the Type Field is split into two Sub-
     Fields:

            1                   2
        8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |L|            Type             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Local bit can take two values:

       Value 0: The Type is Locally Defined.

       Value 1: The Type is Well Known.

     An implementation MUST allow an operator to filter out entire Types
     of Flexible Communities from their peering sessions if they so
     choose.

   2.4. Length Field:

     The Length Field specifies the length, in octets, of the Value
     Field.







Lange                                                           [Page 5]

INTERNET DRAFT                                             December 2002


3. Locally Defined Structures and Types

   The Local bit allows the operator of the network to define Structures
   and Types that are relevant only within that ASN's boundaries.  The
   definition the term "local" used throughout this document is: "A
   value used by ad hoc agreement or convention outside the scope of
   standardization, which has meaning only between the parties using the
   Flexible Community in question."  This typically means that the Local
   value only has meaning within an AS or set of ASes controlled by a
   single entity.

   A Locally Defined Structure or Type will have a syntax for
   interpertation defined on the routers that need to interpret it.  If
   a router receives a community with a Locally Defined Structure or
   Type that it does not recognize, then it should ignore the contents
   and process the route based on the information in the route that it
   does understand.  This includes obeying the transitivity bit, in the
   Flexible Community.  If the community is set to non-transitive, even
   if the router does not understand the rest of the Structure or Type
   of the community, that community should not be forwarded outside the
   AS.

   In order to prevent collisions with other operators' Locally Defined
   values, Flexible Communities containing Locally Defined Structures or
   Types MUST be non-transitive (have their Transitivity Field set to
   1).

4. Neighbor Classes

   A Neighbor Class is a value which represents a certain class, or
   group, of BGP neighbors.  Each BGP peering session can be configured
   with zero or more Neighbor Classes.  This value will allow a general
   classification of what sort of relationship the BGP session
   represents.  With the sort of session defined, it becomes easier to
   apply policy to only that class of neighbors.  Neighbor Classes make
   the expression of policy through flexible communities much easier.
   There are a number of examples in the sections on defined values.

   A Neighbor Class is encoded as a 2-octet value with 2 parts:

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |L|       Neighbor Class        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Local bit can take two values:




Lange                                                           [Page 6]

INTERNET DRAFT                                             December 2002


       Value 0: The Neighbor Class is Locally Defined.

       Value 1: The Neighbor Class is Well Known.

4.1. Locally Defined Neighbor Classes

   If a router receives a Flexible Community containing a Neighbor Class
   that it does not recognize, then it should ignore the contents and
   process the route based on the information in the route that it does
   understand.  If the Transitivity Field of the Flexible Community with
   the Locally Defined Structure or Type is set to 1 (the community is
   non-transitive) then the router MUST NOT forward the Flexible
   Community.  Similarly, if the Transitivity Field is set to 0 (the
   community is transitive) the router MUST forward the community along
   with the NLRI.

   Using Locally Defined Neighbor Classes an operator could easily
   define a set that is locally useful.  For example, one could say that
   "31" would be "Asian Public Peers", and "34" would be European
   Private Peers.

   A given BGP Neighbor can be part of multiple Neighbor Classes.  For
   example, it could be part of both "PEER", and locally defined "ASIAN"
   and "PUBLIC PEER" Classes.  The logical matching functionality
   available is left implementation-dependant.  However, the default in
   such as case is logical OR functionality.

4.2. Defined Neighbor Classes

   This document defines Neighbor Class values for common BGP neighbor
   groupings:

   ALL NEIGHBORS

     This class is the default Neighbor Class for all BGP peers.

     This class is represented by a value of 0 (0x8000).

   PEER

     This class is typically applied to sessions where a transit-free
     relationship exists between the two providers.

     This class is represented by a value of 1 (0x8001).

   CUSTOMER

     This class is typically applied to sessions where the remote end of



Lange                                                           [Page 7]

INTERNET DRAFT                                             December 2002


     the session is operated by a customer.

     This class is represented by a value of 2 (0x8002).

   UPSTREAM

     This class is typically applied to sessions where the remote end of
     the session is operated by a network from which you reveive transit
     routes.

     This class is represented by a value of 3 (0x8003).

   CONFEDERATION PEER

     This class is typically applied to sessions where the remote end of
     the session is part of a confederation.

     This class is represented by a value of 4 (0x8004).

5.0. Defined Flexible BGP Community Structures

   This section defines a number of Structure values which different
   Type values can inherit.

   Summay of the Defined Values:

    - opaque/variable (0x40 or 0xC0)
    - list of 2 byte ASN's (0x41 or 0xC1)
    - list of 4 byte ASN's (0x42 or 0xC2)
    - list of IPv4 addresses (0x43 or 0xC3)
    - list of IPv6 addresses (0x44 or OxC4)
    - list of neighbor_classes (0x45 or 0xC5)

   Defined Strucuture can be transitive or non-transitive, they are well
   known.
Opaque/Variable Strucure

   This sort of structure defers interpretation of the community and
   value field to the Type value.  Typically this structure value will
   be used when the Type value does not have a lot of variations, but
   rather one structure for the Value Field.

   This structure is represented by the value 0x00.

List of 2 byte ASN's

   This structure value means that the Type Field's action is qualified
   by a list of 2 byte ASN's, contained in the Value Field.



Lange                                                           [Page 8]

INTERNET DRAFT                                             December 2002


   This structure is represented by the value 0x01.

List of 4 byte ASN's

   This structure value means that the Type Field's action is qualified
   by a list of 4 byte ASN's, contained in the Value Field.

   This structure is represented by the value 0x02.

List of IPv4 Addresses

   This structure value means that the Type Field's action is qualified
   by a list of IPv4 addresses, contained in the Value Field.

   This structure is represented by the value 0x03.

List of IPv6 Addresses

   This structure value means that the Type Field's action is qualified
   by a list of IPv6 addresses, contained in the Value Field.

   This structure is represented by the value 0x04.

List of Neighbor Classes

   This structure value means that the Type Field's action is qualified
   by a list of neighbor classes, contained in the Value Field.

   This structure is represented by the value 0x05.

6. Base BGP Flexible Community Type (Opaque Type)

   This section defines the base BGP community specification.  Since the
   root value of communities is the ability to tag a route with
   arbitrary information, and then create a system to give that
   information meaning, the base extended community type (type 0), is
   very simple.  This base type could also be described as the "opaque
   type."  All actions can be replicated with a well-thought out,
   provider dependant, implementation of a scheme using this opaque
   type.

   Like all extended commnuities, this type can be transitive or non-
   transitive.  This is a well known type.  It can take either 2 or 4
   byte ASN structures if it is transitive.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Lange                                                           [Page 9]

INTERNET DRAFT                                             December 2002


      | 0x41,0x42,0xC0|             0x0000            |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Value Field  (0-255 octets)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If the community is transitive, then the Value Field MUST contain the
   originating ASN.  Typically this would be encoded in the first 2 or 4
   octets, depending on the structure.

7. Defined Flexible BGP Community Types

   The Type Field specifies the subgroup that a set of communities
   belongs to.  Typically this subgroup represents an action to be taken
   on the data.  A variety of well-known Type Values follow.

7.1. NO_EXPORT

   This grouping of well-known communities specify a list of ASNs, Peer
   IPs, or Neighbor Classes NOT to announce a route to.

   Name: NO_EXPORT
   Type Code: 0x0001
   Can Take Structures:
     Ox01 (2 byte ASN) 0x02 (4 byte ASN), 0x03 (IPv4), 0x04 (IPv6) 0x05
     (neighbor-class)
   Transitive: Non-Transitive
   Min Length of Value Field: 2 octets
   Max Length of Value Field: 254 octets
   Behavior:
     All routes received with this community MUST NOT be advertised to
     the list of ASNs, Peer IPs, or Neigbor Classes contained in the
     Value Field.
   Notes:
     GLOBAL_NO_EXPORT is accomplished by sending a NO_EXPORT Flexible
     Community with the Neighbor Class of 0x00 (ALL NEIGHBORS).

     GLOBAL_NO_EXPORT's NO_EXPORT behavior is defined as:
       All routes received with this community MUST NOT be advertised
       outside a BGP confederation boundry (a stand-alone autonomous
       system that is not part of a confederation should be considered a
       confederation itself.)  [RFC1997]

     This is analogous to the NO_EXPORT community defined in [RFC1997].

7.2. ONLY_EXPORT

   This grouping of well-known communities specify a list of ASNs, Peer
   IPs, or Neighbor Classes to announce a route to.



Lange                                                          [Page 10]

INTERNET DRAFT                                             December 2002


   Name: ONLY_EXPORT
   Type Code: 0x0002
   Can Take Strutures:
     Ox01 (2 byte ASN) 0x02 (4 byte ASN), 0x03 (IPv4), 0x04 (IPv6), 0x05
     (neighbor class)
   Transitive: Non-Transitive
   Min Length of Value Field: 0 octets
   Max Length of Value Field: 254 octets
   Behavior:
     The Value Field contains a list of ASNs, neighbor IP addresses, or
     Neighbor Classes to which the route should be advertized.

     The default behavior of a route carrying this community is the same
     as the GLOBAL_NO_EXPORT behavior, except for the ASNs, IPs, or
     Neighbor Classes listed in the Value Field.
   Notes:
     This community can be used to replicate the NO_ADVERTISE
     functionality from [RFC1997].  To do so, simply announce
     ONLY_EXPORT with a Structure of 0x03 or 0x04 (one of the IP address
     Structures), but with no IP address in the list.  This will tell
     the receiving router that you wish to ONLY_EXPORT this route to NO
     peer IPs.

     This community can also be use to replicate the NO_EXPORT_SUBCONFED
     functionality from [RFC1997].  To do so, simply announce
     ONLY_EXPORT with a Neighbor Class of CONFEDERATION PEER (4,
     0x8004).  This will tell the receiving router that you wish to
     ONLY_EXPORT this route to Confederation Peers.

7.3. ANNOUNCE_WITH

   This group of well-known communities allows a network to announce a
   community to an ASN beyond those that it directly peers with,
   assuming its direct peers allow it to transit the community value.
   This community group has a lot of flexibility, and could be used to
   nest another ANNOUNCE_WITH community to gain reach greater than 2
   ASN-hops away.  If this is a good idea or not is unknown and is left
   to further study. The only theoretical restriction to the amount of
   nesting is that the community cannot exceed the maximum size for the
   Value Field.

   Since true transitivity can be obtained by simply setting a bit, this
   community is mainly useful for propegating NO_EXPORT or ONLY_EXPORT
   (which are non-transitive) to your neighbor's neighbors.

   In effect, this community, if allowed by the BGP neighbors in the
   chain, can be used for an originating network to very specifically
   control the distribution of its routes.  This community type does



Lange                                                          [Page 11]

INTERNET DRAFT                                             December 2002


   contain a LOT of rope, and should be used with care.  In the end,
   though, a mistake should only effect the person origninating the
   route.

   Name: ANNOUNCE_WITH
   Type Code: 0x0003
   Can Take Strucures:
     Ox01 (2 byte ASN) 0x02 (4 byte ASN), 0x03 (IPv4), 0x04 (IPv6), 0x05
     (neighbor class)
   Transitive: Non-Transitive
   Min Length of Value Field: 8 octets
   Max Length of Value Field: 254 octets
   Behavior:
     This community's Value Field is split into two sections.
     - The first section is a variable length field that contains the
     full community value that you wish to announce.
     - The second section is a variable length field that contains the
     list of, ASN's, IP addresses, or neighbor_classes you wish to
     propegate this community to.  If you wish to propegate to all
     peers, use the ALL NEIGHBORS neighbor class.

     When a router receives this community value, it should strip the
     ANNOUNCE_WITH community and announce the underlying community value
     to its neighbor.

7.4. PREPEND

   This community can be used to ask a BGP peer to prepend its own ASN
   to its peers.

   Name: PREPEND
   Type Code: 0x0004
   Can Take Structures:
     Ox01 (2 byte ASN) 0x02 (4 byte ASN), 0x03 (IPv4), 0x04 (IPv6), 0x05
     (neighbor class)
   Transitive: Non-Transitive
   Min Length of Value Field: 3 octets
   Max Length of Value Field: 254 octets
   Behavior:
     This community has 2 sections:
     The first section:
       Is a one-octet value which specifies the number of times that the
       ASN should prepend its ASN.  It is recomended that operators
       constrain this value to no more than 3.  Implementations MUST
       offer the ability for an operator to set a maximum bound for this
       field.  The suggested default is also 3.
     The second section:
       Contains a list of ASNs, peer IPs, or Neighbor Classes to which



Lange                                                          [Page 12]

INTERNET DRAFT                                             December 2002


       the originator of this community wishes its peer to prepend its
       ASN.

7.5. The BGP VPN Communities

   These communities are used mostly for BGP MPLS VPN's.  Please see
   RFC2547 [RFC2547] for more detail on how these VPNs are constructed.

   Name: ROUTE_TARGET
   Type Code: 0x0005
   Can Take Structures:
     0x03 (IPv4), 0x04 (IPv6)
   Transitive: Transitive or Non-Transitive
   Min Length of Value Field: 4 octets
   Max Length of Value Field: 254 octets
   Behavior:
     The Value Field of this community represents a list of the IP
     addresses where this route is to be announced.

   Name: ROUTE_ORIGIN
   Type Code: 0x0006
   Can Take Structures:
     0x03 (IPv4), 0x04 (IPv6)
   Transitive: Transitive or Non-Transitive
   Min Length of Value Field: 4 octets
   Max Length of Value Field: 16 octets
   Behavior:
     The Value Field of this community represents a list of the IP
     address where this route is originated.  This community can only
     contain one IP address.

   Name: LINK_BANDWIDTH
   Type Code: 0x0007
   Can Take Structures:
     0x00 (opaque), Ox01 (2 byte ASN), 0x02 (4 byte ASN)
   Transitive: Transitive or Non-Transitive
   Min Length of Value Field: 4 octets
   Max Length of Value Field: 6 octets
   Behavior:
     This community consists of two parts:
     The first part represents the bandwidth of the link in bits-per-
     second, encoded in IEEE floating point format.  This part is 4
     octets long.
     The second part consists of a list of ASNs of the peer whose link
     bandwidth you wish to propegate.  This part is either 2 or 4
     octets, depending on the community structure.





Lange                                                          [Page 13]

INTERNET DRAFT                                             December 2002


8. New Capability Code for Flexible Communities

To ensure compatability between implementations that may or may not
implement this protocol extention, this document defines a new
capability.

     Capability Code: TBD
     Capability Length: 1
     Capability Value: 0x00 for unsupported
                       0x01 for supported

     Capability negotiation is especially important for this attribute
     because we are creating a transitivity action within an optional,
     transitive attribute.  If an implementation sends a flexible
     community with the non-transitive bit set within the community to a
     router that does not support flexible communities, that router will
     send the community on to its peers when it should not do so.

9. Aggregation

   Aggregation behaves the same as with other community types.

   By default if a range of routes is to be aggregated and the resultant
   aggregates path attributes do not carry the ATOMIC_AGGREGATE
   attribute, then the resulting aggregate should have an Flexible Com-
   munities path attribute which contains the set union of all the
   Flexible Communities from all of the aggregated routes. The default
   behavior could be overriden via local configuration, in which case
   handling the Flexible Communities attribute in the presence of route
   aggregation becomes a matter of the local policy of the BGP speaker
   that performs the aggregation.

10. Operations

   Flexible Communities are handled operationally in a manner very
   similar to other community values.

   A BGP speaker may use the Flexible Communities attribute to control
   which routing information it accepts or distributes to its peers.

   The Flexible Community attribute MUST NOT be used to modify the BGP
   best path selection algorithm in a way that leads to forwarding
   loops.

   A BGP speaker receiving a route that doesn't have the Flexible Commu-
   nities attribute MAY append this attribute to the route when propa-
   gating it to its peers.




Lange                                                          [Page 14]

INTERNET DRAFT                                             December 2002


   A BGP speaker receiving a route with the Flexible Communities
   attribute MAY modify this attribute according to the local policy.
   If a route has a non-transitivity extended community, then before
   advertising the route across the Autonomous system boundary the com-
   munity SHOULD be removed from the route. However, the community
   SHOULD NOT be removed when advertising the route across the BGP Con-
   federation boundary.

   A route may carry both the BGP Communities attribute as defined in
   [RFC1997]), the Extended BGP Communities attribute as defined in
   [EX-COMM], and the Flexible Communities attribute. In this case the
   BGP Communities attribute is handled as specified in [RFC1997], the
   Extended BGP Communities attribute is handled as specified in [EX-
   COMM], and the Flexible Communities attribute is handled as specified
   in this document.

11. Security Considerations

   This extention to BGP does not change the underlying security issues.

12. IANA Considerations

   The values for the Transitivity Field (1 or 0) are completely defined
   in this document.

   The assignment policy for the Structure Field is:
     o The "L" bit's usage is completely defined in this document.
     o Values of the Structure Field where the "L" bit is "0" are to be
     assigned in accordance with the Private Use policy outlined in
     RFC2434 [RFC2434].
     o Values of the Structure Field where the "L" bit is "1" defined in
     this document are: 0-5 (0x40-0x45 and 0xC1-0xC5).  Remaining values
     in this range are to be assigned using the IETF Consensus policy
     outlined in RFC2434 [RFC2434].

   The assignment policy for the Type Field is:
     o The "L" bit's usage is completely defined in this document.
     o Values of the Type Field where the "L" bit is "0" are to be
     assigned in accordance with the Private Use policy outlined in
     RFC2434 [RFC2434].
     o Values of the Type Field where the "L" but is "1" defined in this
     document are: 0-7 (0x0000-0x0007).  Remaining values in this range
     are to be assigned using the IETF Consensus policy outlined in
     RFC2434 [RFC2434].

   The assignment policy for Neighbor Classes is:
     o The "L" bit's usage is completely defined in this document.
     o Values of the Type Field where the "L" bit is "0" are to be



Lange                                                          [Page 15]

INTERNET DRAFT                                             December 2002


     assigned in accordance with the Private Use policy outlined in
     RFC2434 [RFC2434].
     o Values of the Type Field where the "L" but is "1" defined in this
     document are: 0-4 (0x8000-0x8004).  Remaining values in this range
     are to be assigned usint the IETF Consensus policy outlined in
     RFC2434 [RFC2434].

13. References

   [RFC1771] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)",
   RFC 1771, March 1995.

   [RFC1997] Chandra, R., Traina, P., Li, T., "BGP Communities
   Attribute", RFC 1997, August 1996.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA
   Considerations Section in RFCs", RFC 2434, October 1998

   [RFC2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March
   1999.

   [RFC2842] Chandra, R., Scudder, J., "Capabilities Advertisement with
   BGP-4", RFC 2842, May 2000.

   [EX-COMM] Sangli, S., Tappan, D., Rekhter, Y., "BGP Extended
   Communities Attribute", draft-ietf-idr-bgp-ext-communities-05.txt,
   work-in-progress, expires November, 2002.

   [NOPEER] Huston, G., "NOPEER community for BGP route scope control",
   draft-ietf-ptomaine-nopeer-00.txt, work-in-progress, expires October,
   2002.

   [REDIST] Bonaventure, O., et. al., "Controlling the redistribution of
   BGP routes", draft-ietf-ptomaine-redistribution-01.txt, work-in-
   progress, expires February, 2003.

14. Acknowledgements
   I would like to thank Tom Barron, Dave Ward and especially Hal
   Peterson for their valuable comments and feedback.

15. Author's  Address:

   Andrew Lange
   Cable & Wireless
   1215 Borregas Ave.



Lange                                                          [Page 16]

INTERNET DRAFT                                             December 2002


   Sunnyvale, CA  95050
   [e-mail]

--DIOMP1UsTsWJauNi--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA08249 for <[e-mail]>; Thu, 23 Jan 2003 19:39:50 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 7CF2F9122B; Thu, 23 Jan 2003 19:39:32 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48C4D91427; Thu, 23 Jan 2003 19:39: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 D55C89122B for <[e-mail]>; Thu, 23 Jan 2003 19:39:30 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B15475DE90; Thu, 23 Jan 2003 19:39:30 -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 56C755DE09 for <[e-mail]>; Thu, 23 Jan 2003 19:39:30 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0O0dT571478 for [e-mail]; Thu, 23 Jan 2003 19:39:29 -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 h0O0dNC71465 for <[e-mail]>; Thu, 23 Jan 2003 19:39:23 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: Draft 19 - issue #21 
Date: Thu, 23 Jan 2003 19:39:23 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft 19 - issue #21 
Thread-Index: AcLCP9Y/Dd4BowA5QRKLu5xodLiWqABAO2LA
From: "Susan Hares" <[e-mail]>
To: "Tom Petch" <[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 TAA08249

Tom:

thanks for the editing.

Could you look at the list of 
non-consensus issues? Can you help
resolve any of these issues by
suggesting something?

Thanks,

Sue

-----Original Message-----
From: Tom Petch [mailto:[e-mail]]
Sent: Wednesday, January 22, 2003 12:53 PM
To: Susan Hares; [e-mail]
Subject: Re: Draft 19 - issue #21 


Sue
two minor editorial comments inline
Tom Petch

-----Original Message-----
From: Susan Hares <[e-mail]>
To: [e-mail] <[e-mail]>
Date: 20 January 2003 19:39
Subject: Draft 19 - issue #21



I will accept the new text for the following total text:

    Event8: Idle hold timer expires

           Definition: An event generated when the Idle Hold Timer
       expires indicating that the session has completed
       a back-off period to prevent bgp peer oscillation.

       The Idle Hold Timer is only used when the persistent
                       peer oscillation damping function is enabled.

                       Implementations not implementing the presistent
peer

**
persistent
                       oscillation damping functions may not have the
Idle Hold
**                                                       function
** (because we only have function not functions in the previous
sentence)
                    Timer.

           Status:     Optional


Sue Hares



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA13312 for <[e-mail]>; Wed, 22 Jan 2003 12:59:08 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 55A589130B; Wed, 22 Jan 2003 12:58:14 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B99AC9138C; Wed, 22 Jan 2003 12:58: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 C762D9130B for <[e-mail]>; Wed, 22 Jan 2003 12:58:10 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A96DD5DE4E; Wed, 22 Jan 2003 12:58:10 -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 78F225DDB7 for <[e-mail]>; Wed, 22 Jan 2003 12:58:10 -0500 (EST)
Received: from tom3 (usermb23.uk.uudial.com [62.188.120.22]) by shockwave.systems.pipex.net (Postfix) with SMTP id 1E5061600B540; Wed, 22 Jan 2003 17:58:08 +0000 (GMT)
Message-ID: <05bf01c2c23f$a1ddefc0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Susan Hares" <[e-mail]>, <[e-mail]>
Subject: Re: BGP Draft 19 - Close open items 22
Date: Wed, 22 Jan 2003 17:55:03 -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
minor editorial comment inline
Tom Petch

-----Original Message-----
From: Susan Hares <[e-mail]>
To: [e-mail] <[e-mail]>
Date: 20 January 2003 19:49
Subject: BGP Draft 19 - Close open items 22



Please consider items 22 closed with the following final text:

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

1) Delay Open flag
2) Delay Open Timer

** Open Delay timer 
** (for which we have consensus in Issue list v2 item 7)
3) Perform automatic start flag
4) Passive TCP establishment flag
5) BGP stop_peer_flag flag
6) Idle Hold timer
7) Perform automatic stop flag
8) Perform Collision detect in Establish mode flag


Sue



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA13279 for <[e-mail]>; Wed, 22 Jan 2003 12:58:43 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5546591309; Wed, 22 Jan 2003 12:58:11 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2270091388; Wed, 22 Jan 2003 12:58: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 ABA2391309 for <[e-mail]>; Wed, 22 Jan 2003 12:58:09 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 81DD05DEBE; Wed, 22 Jan 2003 12:58:09 -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 08CDA5DDB7 for <[e-mail]>; Wed, 22 Jan 2003 12:58:09 -0500 (EST)
Received: from tom3 (usermb23.uk.uudial.com [62.188.120.22]) by shockwave.systems.pipex.net (Postfix) with SMTP id DF20C1600E5EA; Wed, 22 Jan 2003 17:58:06 +0000 (GMT)
Message-ID: <05be01c2c23f$a0c9c0a0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Susan Hares" <[e-mail]>, <[e-mail]>
Subject: Re: Draft 19 - issue #21 
Date: Wed, 22 Jan 2003 17:52:47 -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
two minor editorial comments inline
Tom Petch

-----Original Message-----
From: Susan Hares <[e-mail]>
To: [e-mail] <[e-mail]>
Date: 20 January 2003 19:39
Subject: Draft 19 - issue #21



I will accept the new text for the following total text:

    Event8: Idle hold timer expires

           Definition: An event generated when the Idle Hold Timer
       expires indicating that the session has completed
       a back-off period to prevent bgp peer oscillation.

       The Idle Hold Timer is only used when the persistent
                       peer oscillation damping function is enabled.

                       Implementations not implementing the presistent
peer

**
persistent
                       oscillation damping functions may not have the
Idle Hold
**                                                       function
** (because we only have function not functions in the previous
sentence)
                    Timer.

           Status:     Optional


Sue Hares



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA05244 for <[e-mail]>; Wed, 22 Jan 2003 10:59:29 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A35049137D; Wed, 22 Jan 2003 10:59:14 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 643419137E; Wed, 22 Jan 2003 10:59: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 96CA79137D for <[e-mail]>; Wed, 22 Jan 2003 10:59:11 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 80BCA5DE8A; Wed, 22 Jan 2003 10:59: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 DEA915DE37 for <[e-mail]>; Wed, 22 Jan 2003 10:59:10 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0MFx9W24790 for [e-mail]; Wed, 22 Jan 2003 10:59: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 h0MFwxC24764 for <[e-mail]>; Wed, 22 Jan 2003 10:58:59 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: BGP-draft-19: Issue 52 - Event 18 in OpenSent State (Keepalive timer set) 
Date: Wed, 22 Jan 2003 10:58:59 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: BGP-draft-19: Issue 52 - Event 18 in OpenSent State (Keepalive timer set) 
Thread-Index: AcLBvkQGcvWNIHz+QQiha1cje3m8RAAcNTmA
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>
Cc: "Jeffrey Haas" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[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 KAA05244

Curtis: 

Yawn is fine.  I'll work on text for optional.

Thanks,

sue

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]]
Sent: Tuesday, January 21, 2003 9:28 PM
To: Susan Hares
Cc: Jeffrey Haas; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail]
Subject: Re: BGP-draft-19: Issue 52 - Event 18 in OpenSent State
(Keepalive timer set) 



In message <[e-mail]
m>, "Susan Hares" writes:
> 
> Jeff and Siva:
> 
> 
>   I need to hear from additional implementers
> on the following.  Would you both check your
> implementations? 
> 
> Sue Hares


Yawn...		[not what you wanted to hear?]


> -------------	
> 
> 
> Issue 52 - 
> 	status: non-consensus 
> 
> 		<----	Open [Open sent state]
> 	open ---->  
> 			[Event 18 in Open Sent 
> 		<----- Keepalive 
> 
> 	Event 18:
> 		- clears BGP delay timer
> 		- resets BGP connect timer
> 		- sends Keepalive message
> 		- if negotiated hold timer is zero,
> 			o reset keepalive timer,
> 			o reset hold timer.
> 
> 		- if negotiated hold timer is non-zero
> 			o set keepalive timer,
> 			o set hold timer to negotiated value. 
> 
> 
> 	Here the question is, do you want to send a 2nd
> 	keepalive if the keepalive timer expires in 
> 	Open Confirm.  
> 
>      The current draft allows this until the hold timer 
>      expires.   The sequence would be:
> 
> 
>      The current draft allows this until the hold timer 
>      expires.   The sequence would be:
> 
> 			<---- open [open sent]
> 		open -->  [event 18]
> 
> 			<-----keepalive
> 
> 				[keepalive timeout [Event 11]
> 			<---- Keepalive
> 
> 				[Keepalive time out [Event 11]
> 			<--- Keepalive
> 
> 				[hold time-out, Event 10]
> 			<---Notification
> 			    drop TCP connection
> 			 
> Please confirm that you want to remove these subsequent keepalives in
> Open Confirm.
> 
> 
> Sue


Make it optional.  Timing out in open or open-sent has never been much
of an issue, so whether one or three keepalive get sent shouldn't be a
hot topic.

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 BAA27936 for <[e-mail]>; Wed, 22 Jan 2003 01:49:12 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id C127291206; Wed, 22 Jan 2003 01:48:50 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9122E91271; Wed, 22 Jan 2003 01:48: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 8895F91206 for <[e-mail]>; Wed, 22 Jan 2003 01:47:53 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 6AAE75DDCA; Wed, 22 Jan 2003 01:47:53 -0500 (EST)
Delivered-To: [e-mail]
Received: from web20307.mail.yahoo.com (web20307.mail.yahoo.com [216.136.226.88]) by segue.merit.edu (Postfix) with SMTP id 115E45DD91 for <[e-mail]>; Wed, 22 Jan 2003 01:47:53 -0500 (EST)
Message-ID: <[e-mail]>
Received: from [203.200.20.226] by web20307.mail.yahoo.com via HTTP; Tue, 21 Jan 2003 22:47:52 PST
Date: Tue, 21 Jan 2003 22:47:52 -0800 (PST)
From: Mareline Sheldon <[e-mail]>
Subject: Multiple SNPAs -- When?
To: [e-mail]
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Hello,
I have a doubt in MPBGP. Can anyone give me an example of a scenario when a speaker will be
advertising multiple SNPAs for an entity.

warm 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 VAA13320 for <[e-mail]>; Tue, 21 Jan 2003 21:40:55 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 196979136C; Tue, 21 Jan 2003 21:40:30 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE9959136D; Tue, 21 Jan 2003 21:40:29 -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 924AC9136C for <[e-mail]>; Tue, 21 Jan 2003 21:40:28 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 74DF65DE87; Tue, 21 Jan 2003 21:40:28 -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 DB20C5DE83 for <[e-mail]>; Tue, 21 Jan 2003 21:40:26 -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 VAA62527; Tue, 21 Jan 2003 21:38:10 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 18 
In-reply-to: Your message of "Tue, 21 Jan 2003 08:44:36 PST." <[e-mail]> 
Date: Tue, 21 Jan 2003 21:38:10 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Yakov Rekhter writes
:
> 
> Here is the text that will go in the next version of the draft:
> 
>   If a MULTI_EXIT_DISC attribute is removed before re-advertising a
>   route into IBGP, then comparison based on the MULT_EXIT_DISC
>   attribute MAY be performed only among the EBGP learned routes.
>   This comparison MUST be performed before the removal of the
>   MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute is then
>   removed from those EBGP routes where such removal is required and
>   which are still eligible. This is followed by comparison with
>   IBGP learned routes. 
> 
> Yakov.


Looks good to me.

I see no need to change "This comparison MUST be performed before the
removal of the MULTI_EXIT_DISC attribute".  There is no implication
that MULTI_EXIT_DISC must be removed and the first sentence clearly
indicates that doing so is not required therefore no ambiguity.
Adding a "If a MULTI_EXIT_DISC attribute is removed" to the second
sentence would be redundant.

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 VAA12769 for <[e-mail]>; Tue, 21 Jan 2003 21:32:04 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E57A79136A; Tue, 21 Jan 2003 21:31:35 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E8EB9136D; Tue, 21 Jan 2003 21:31: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 D5E699136A for <[e-mail]>; Tue, 21 Jan 2003 21:31:31 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1D7FA5DDE9; Tue, 21 Jan 2003 21:30:56 -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 D64555DE41 for <[e-mail]>; Tue, 21 Jan 2003 21:30:47 -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 VAA62398; Tue, 21 Jan 2003 21:28:28 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Susan Hares" <[e-mail]>
Cc: "Jeffrey Haas" <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: BGP-draft-19: Issue 52 - Event 18 in OpenSent State (Keepalive timer set) 
In-reply-to: Your message of "Tue, 21 Jan 2003 10:46:26 EST." <[e-mail]> 
Date: Tue, 21 Jan 2003 21:28:28 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
m>, "Susan Hares" writes:
> 
> Jeff and Siva:
> 
> 
>   I need to hear from additional implementers
> on the following.  Would you both check your
> implementations? 
> 
> Sue Hares


Yawn...		[not what you wanted to hear?]


> -------------	
> 
> 
> Issue 52 - 
> 	status: non-consensus 
> 
> 		<----	Open [Open sent state]
> 	open ---->  
> 			[Event 18 in Open Sent 
> 		<----- Keepalive 
> 
> 	Event 18:
> 		- clears BGP delay timer
> 		- resets BGP connect timer
> 		- sends Keepalive message
> 		- if negotiated hold timer is zero,
> 			o reset keepalive timer,
> 			o reset hold timer.
> 
> 		- if negotiated hold timer is non-zero
> 			o set keepalive timer,
> 			o set hold timer to negotiated value. 
> 
> 
> 	Here the question is, do you want to send a 2nd
> 	keepalive if the keepalive timer expires in 
> 	Open Confirm.  
> 
>      The current draft allows this until the hold timer 
>      expires.   The sequence would be:
> 
> 
>      The current draft allows this until the hold timer 
>      expires.   The sequence would be:
> 
> 			<---- open [open sent]
> 		open -->  [event 18]
> 
> 			<-----keepalive
> 
> 				[keepalive timeout [Event 11]
> 			<---- Keepalive
> 
> 				[Keepalive time out [Event 11]
> 			<--- Keepalive
> 
> 				[hold time-out, Event 10]
> 			<---Notification
> 			    drop TCP connection
> 			 
> Please confirm that you want to remove these subsequent keepalives in
> Open Confirm.
> 
> 
> Sue


Make it optional.  Timing out in open or open-sent has never been much
of an issue, so whether one or three keepalive get sent shouldn't be a
hot topic.

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 SAA01722 for <[e-mail]>; Tue, 21 Jan 2003 18:25:06 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 3649791371; Tue, 21 Jan 2003 18:22:16 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 055AF91367; Tue, 21 Jan 2003 18:22: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 8859991371 for <[e-mail]>; Tue, 21 Jan 2003 18:21:45 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 6E1FC5E0A3; Tue, 21 Jan 2003 18:21:45 -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 CB6BA5DDEC for <[e-mail]>; Tue, 21 Jan 2003 18:21:44 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0LNLhf99954 for [e-mail]; Tue, 21 Jan 2003 18:21:43 -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 h0LNLZC99935 for <[e-mail]>; Tue, 21 Jan 2003 18:21:35 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: BGP-19: Issue 34-35, 40-48
Date: Tue, 21 Jan 2003 18:21:34 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: BGP-19: Issue 34-35, 40-48
Thread-Index: AcLBmoxW5Aw0pe7JRSmKYsjhPGRm8gACUMEg
From: "Susan Hares" <[e-mail]>
To: <[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 SAA01722

Andrew:

Looks great!  Thanks.

sue

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
Sent: Tuesday, January 21, 2003 5:12 PM
To: Susan Hares
Cc: [e-mail]; [e-mail]
Subject: Re: BGP-19: Issue 34-35, 40-48


Hi Sue,

Responses are inline.

> Andrew and Siva: 
> 
> summary: 
> 	consensus:  34, 35, 43.47 
> 	possible consensus: 41,44
> 	no consensus, discussion needed: 40, 42, 48, 54 
> 	
>  
> -----------
> 
> Issue 34 -
> 
> I think that Siva and I have consensus on issue 34. 
> I changed the text to "fails" based on other comments.

Done.

> Issue 35 - I accept Siva's changes, please mark 
>            this as consensus. 

Done.

> Issue 40 - Clearing of the Connection Retry timer 
> 
> 	We need to discuss our two points of view
> 	here.  This should be marked as no consensus

Already at No Consensus in 2.1:

----------------------------------------------------------------------------
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?

> Issues 41  -
> 	question: Connect state, event 14 - will this happen? 
> 	
> 	My resolution: Let event 14 be optional. 
>       Not all BGP implementations support it. 
> 
> 	Siva - Does this let us reach consensus?

Updated this issue, waiting Siva's response.

> Issue 42 -  Handling events 20, 21 in Connect and Active states
> 
> 	state: non-consensus
> 
> 	I suggest we don't send a "NOTIFICATION" when
> 	Event 20 or Event 21 is received in Conect or Active state.

Updated the issue.

> Issue 43: 
> 	
> 	state: consensus
> 	focus: editorial 
> 	I'll accept the text change from Siva with small editorial
> 	modification below. 
> 
> 	old text: 
> 		-resets the connect retry timer (sets to zero)
> 		- clears the open delay timer 
> 
> 	new text:
> 		- if the connect retry timer is running, 
> 			clear the connect retry timer (set to zero).
> 		 if the open delay timer is running,
> 			clear the open delay timer (set to zero).
> 
> 	Siva - please confirm that this change is acceptable for
> 	the default case.  

Since you've substantively accepted Siva's suggestion, I'll put this
at consensus, unless someone wants to reopen it.

> Issue 44 
> 
> 	Please reply if you have additional concerns, otherwise
> 	we will leave the text alone.

Sicne there have been on objections, I'll move this to consensus.  We
can reopen it if it is still an issue.

> Issue 45
> 	status: change to consensus
> 	
> 	I'll  agree with Jeff, Tom and you.  Please consider this
> 	item in consensus.  I'll change the text.

Done.

> Issue 47 - Event 19 in Active state 
> 	status: change to consensus 
> 
> 	New text
> 
> 	- if the hold timer value is non-zero,
> 		- starts the keepalive timer to initial value,  
> 		- resets the hold timer to the negotiated value,
> 	- else if the hold timer is zero
> 		- resets the keepalive timer (set to zero),
> 		- resets the hold timer to zero.

This seems to address Siva's concerns, this issue is at consensus, if
there are objections, we can reopen it.

> Issue 48 - 
> 	 status: non-consensus 
> 	
> 	 do you have any further comments.  If not, I'll leave
> 	the text as:
> 
>     state.
>  
>     A manual stop event[Event2], the local system:
>         - Sends a NOTIFICATION with a Cease,
>         - releases all BGP resources including
> 		- stopping the OPen delay timer 
>         - drops the TCP connection, 
>         - sets ConnectRetryCnt (connect retry count) to zero
>         - resets the connect retry timer (sets to zero),
>         - changes its state to Idle.

Updated the issue.

> Issue 52 - 
> 	status: non-consensus 
> 
> 		<----	Open [Open sent state]
> 	open ---->  
> 			[Event 18 in Open Sent 
> 		<----- Keepalive 
> 
> 	Event 18:
> 		- clears BGP delay timer
> 		- resets BGP connect timer
> 		- sends Keepalive message
> 		- if negotiated hold timer is zero,
> 			o reset keepalive timer,
> 			o reset hold timer.
> 
> 		- if negotiated hold timer is non-zero
> 			o set keepalive timer,
> 			o set hold timer to negotiated value. 
> 
> 
> 	Here the question is, do you want to send a 2nd
> 	keepalive if the keepalive timer expires in 
> 	Open Confirm.  
> 
>      The current draft allows this until the hold timer 
>      expires.   The sequence would be:
> 
> 			<---- open [open sent]
> 		open -->  [event 18]
> 
> 			<-----keepalive
> 
> 				[keepalive timeout [Event 11]
> 			<---- Keepalive
> 
> 				[Keepalive time out [Event 11]
> 			<--- Keepalive
> 
> 				[hold time-out, Event 10]
> 			<---Notification
> 			    drop TCP connection

I think we're waiting for more implementor's responses on this one.

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 RAA27469 for <[e-mail]>; Tue, 21 Jan 2003 17:16:24 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E04FD9135A; Tue, 21 Jan 2003 17:15:16 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E53A9135D; Tue, 21 Jan 2003 17:15: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 8D8619135A for <[e-mail]>; Tue, 21 Jan 2003 17:15:11 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 5425A5E0A3; Tue, 21 Jan 2003 17:15:10 -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 4D8E85E05A for <[e-mail]>; Tue, 21 Jan 2003 17:15:09 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id OAA14392; Tue, 21 Jan 2003 14:11:59 -0800 (PST)
Date: Tue, 21 Jan 2003 14:11:59 -0800
From: [e-mail]
To: Susan Hares <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: BGP-19: Issue 34-35, 40-48
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 Tue, Jan 21, 2003 at 10:47:12AM -0500
Sender: [e-mail]
Precedence: bulk

Hi Sue,

Responses are inline.

> Andrew and Siva: 
> 
> summary: 
> 	consensus:  34, 35, 43.47 
> 	possible consensus: 41,44
> 	no consensus, discussion needed: 40, 42, 48, 54 
> 	
>  
> -----------
> 
> Issue 34 -
> 
> I think that Siva and I have consensus on issue 34. 
> I changed the text to "fails" based on other comments.

Done.

> Issue 35 - I accept Siva's changes, please mark 
>            this as consensus. 

Done.

> Issue 40 - Clearing of the Connection Retry timer 
> 
> 	We need to discuss our two points of view
> 	here.  This should be marked as no consensus

Already at No Consensus in 2.1:

----------------------------------------------------------------------------
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?

> Issues 41  -
> 	question: Connect state, event 14 - will this happen? 
> 	
> 	My resolution: Let event 14 be optional. 
>       Not all BGP implementations support it. 
> 
> 	Siva - Does this let us reach consensus?

Updated this issue, waiting Siva's response.

> Issue 42 -  Handling events 20, 21 in Connect and Active states
> 
> 	state: non-consensus
> 
> 	I suggest we don't send a "NOTIFICATION" when
> 	Event 20 or Event 21 is received in Conect or Active state.

Updated the issue.

> Issue 43: 
> 	
> 	state: consensus
> 	focus: editorial 
> 	I'll accept the text change from Siva with small editorial
> 	modification below. 
> 
> 	old text: 
> 		-resets the connect retry timer (sets to zero)
> 		- clears the open delay timer 
> 
> 	new text:
> 		- if the connect retry timer is running, 
> 			clear the connect retry timer (set to zero).
> 		 if the open delay timer is running,
> 			clear the open delay timer (set to zero).
> 
> 	Siva - please confirm that this change is acceptable for
> 	the default case.  

Since you've substantively accepted Siva's suggestion, I'll put this
at consensus, unless someone wants to reopen it.

> Issue 44 
> 
> 	Please reply if you have additional concerns, otherwise
> 	we will leave the text alone.

Sicne there have been on objections, I'll move this to consensus.  We
can reopen it if it is still an issue.

> Issue 45
> 	status: change to consensus
> 	
> 	I'll  agree with Jeff, Tom and you.  Please consider this
> 	item in consensus.  I'll change the text.

Done.

> Issue 47 - Event 19 in Active state 
> 	status: change to consensus 
> 
> 	New text
> 
> 	- if the hold timer value is non-zero,
> 		- starts the keepalive timer to initial value,  
> 		- resets the hold timer to the negotiated value,
> 	- else if the hold timer is zero
> 		- resets the keepalive timer (set to zero),
> 		- resets the hold timer to zero.

This seems to address Siva's concerns, this issue is at consensus, if
there are objections, we can reopen it.

> Issue 48 - 
> 	 status: non-consensus 
> 	
> 	 do you have any further comments.  If not, I'll leave
> 	the text as:
> 
>     state.
>  
>     A manual stop event[Event2], the local system:
>         - Sends a NOTIFICATION with a Cease,
>         - releases all BGP resources including
> 		- stopping the OPen delay timer 
>         - drops the TCP connection, 
>         - sets ConnectRetryCnt (connect retry count) to zero
>         - resets the connect retry timer (sets to zero),
>         - changes its state to Idle.

Updated the issue.

> Issue 52 - 
> 	status: non-consensus 
> 
> 		<----	Open [Open sent state]
> 	open ---->  
> 			[Event 18 in Open Sent 
> 		<----- Keepalive 
> 
> 	Event 18:
> 		- clears BGP delay timer
> 		- resets BGP connect timer
> 		- sends Keepalive message
> 		- if negotiated hold timer is zero,
> 			o reset keepalive timer,
> 			o reset hold timer.
> 
> 		- if negotiated hold timer is non-zero
> 			o set keepalive timer,
> 			o set hold timer to negotiated value. 
> 
> 
> 	Here the question is, do you want to send a 2nd
> 	keepalive if the keepalive timer expires in 
> 	Open Confirm.  
> 
>      The current draft allows this until the hold timer 
>      expires.   The sequence would be:
> 
> 			<---- open [open sent]
> 		open -->  [event 18]
> 
> 			<-----keepalive
> 
> 				[keepalive timeout [Event 11]
> 			<---- Keepalive
> 
> 				[Keepalive time out [Event 11]
> 			<--- Keepalive
> 
> 				[hold time-out, Event 10]
> 			<---Notification
> 			    drop TCP connection

I think we're waiting for more implementor's responses on this one.

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 NAA12208 for <[e-mail]>; Tue, 21 Jan 2003 13:04:54 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 3A94D9134B; Tue, 21 Jan 2003 13:04:35 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2EE1912C4; Tue, 21 Jan 2003 13:04: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 78BA39134A for <[e-mail]>; Tue, 21 Jan 2003 13:02:40 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 52EBA5DE55; Tue, 21 Jan 2003 13:02:40 -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 A20BC5DE13 for <[e-mail]>; Tue, 21 Jan 2003 13:02:38 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0LI2be88224 for [e-mail]; Tue, 21 Jan 2003 13:02:37 -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 h0LI2YC88217 for <[e-mail]>; Tue, 21 Jan 2003 13:02:34 -0500 (EST) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id h0LI2Yg12390 for [e-mail]; Tue, 21 Jan 2003 13:02:34 -0500 (EST)
Date: Tue, 21 Jan 2003 13:02:34 -0500
From: Mathew Richardson <[e-mail]>
To: [e-mail]
Subject: Re: issue 18
Message-ID: <[e-mail]>
References: <[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]> [Tue, Jan 21, 2003 at 08:44:36AM -0800]:

<snip>

I think this new text is ambiguous.

>Here is the text that will go in the next version of the draft:
>
>  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
>  route into IBGP, then comparison based on the MULT_EXIT_DISC
>  attribute MAY be performed only among the EBGP learned routes.

This could be taken to mean either that the comparison may be performed,
and if it's performed it must be performed only between EBGP learned
routes, or that the comparison must be performed, but it may be performed
only between EBGP learned routes.

>  This comparison MUST be performed before the removal of the
>  MULTI_EXIT_DISC attribute.

If doing the comparison is optional, then I think that this sentence
should read "If the comparsion is performed, then it MUST be perfo..."

>                             The MULT_EXIT_DISC attribute is then
>  removed from those EBGP routes where such removal is required and
>  which are still eligible. This is followed by comparison with
>  IBGP learned routes. 

<snip>

I think that it is desirable for an operator to be able to turn off
MED processing entirely (including turning off all MED based
comparisons), so I would suggest the following text:

  If a MULTI_EXIT_DISC attribute is removed before re-advertising a
  route into IBGP, comparison based on the received MULTI_EXIT_DISC
  attribute MAY be performed.  If an implementation chooses to perform
  this comparison, then the comparison MUST be performed only among EBGP
  learned routes, and it MUST be performed before the removal of the
  MULTI_EXIT_DISC attribute.

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 MAA09695 for <[e-mail]>; Tue, 21 Jan 2003 12:20:06 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 772EE91345; Tue, 21 Jan 2003 12:19:34 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 381AF91348; Tue, 21 Jan 2003 12:19: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 442A291345 for <[e-mail]>; Tue, 21 Jan 2003 12:17:09 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1C8125DDB8; Tue, 21 Jan 2003 12:17:09 -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 BCD215DD99 for <[e-mail]>; Tue, 21 Jan 2003 12:17:08 -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 h0LHH7S74632; Tue, 21 Jan 2003 09:17:07 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 17 - final resolution 
In-Reply-To: Your message of "Tue, 21 Jan 2003 12:04:48 EST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 21 Jan 2003 09:17:07 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> On Tue, Jan 21, 2003 at 08:58:19AM -0800, Yakov Rekhter wrote:
> > The current text is just fine. Since the definition of "BGP speaker"
> > makes it quite clear that in the context of this document it means
> > a router, and *not* a non-routing host implementing BGP, it follows
> > that the issue of non-routing hosts implementing BGP is outside
> > the document. 
> > 
> > If there is a sufficient interest to document the issues related
> > to non-routing hosts implementing BGP (including interaction between
> > these hosts and routers), then this should be done in a separate document.
> 
> Normalize the text to read "BGP Speaker" in the few remaining places
> it says router, leave the current definition of BGP Speaker and
> I yield.

Accepted.

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 MAA08844 for <[e-mail]>; Tue, 21 Jan 2003 12:05:16 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id A15BE9133F; Tue, 21 Jan 2003 12:04:55 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 687A091341; Tue, 21 Jan 2003 12:04: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 56CDC9133F for <[e-mail]>; Tue, 21 Jan 2003 12:04:54 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3D4365DDBF; Tue, 21 Jan 2003 12:04: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 A7E235DD99 for <[e-mail]>; Tue, 21 Jan 2003 12:04:53 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0LH4q486254; Tue, 21 Jan 2003 12:04: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 h0LH4mC86247; Tue, 21 Jan 2003 12:04:48 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h0LH4mI00153; Tue, 21 Jan 2003 12:04:48 -0500 (EST)
Date: Tue, 21 Jan 2003 12:04:48 -0500
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 17 - final resolution
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 Tue, Jan 21, 2003 at 08:58:19AM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Jan 21, 2003 at 08:58:19AM -0800, Yakov Rekhter wrote:
> The current text is just fine. Since the definition of "BGP speaker"
> makes it quite clear that in the context of this document it means
> a router, and *not* a non-routing host implementing BGP, it follows
> that the issue of non-routing hosts implementing BGP is outside
> the document. 
> 
> If there is a sufficient interest to document the issues related
> to non-routing hosts implementing BGP (including interaction between
> these hosts and routers), then this should be done in a separate document.

Normalize the text to read "BGP Speaker" in the few remaining places
it says router, leave the current definition of BGP Speaker and
I yield.

> 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 LAA08462 for <[e-mail]>; Tue, 21 Jan 2003 11:58:54 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 7595E9133C; Tue, 21 Jan 2003 11:58:25 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A9709133E; Tue, 21 Jan 2003 11:58: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 E275A9133C for <[e-mail]>; Tue, 21 Jan 2003 11:58:19 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C8C255E00F; Tue, 21 Jan 2003 11:58:19 -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 73B765DDBF for <[e-mail]>; Tue, 21 Jan 2003 11:58:19 -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 h0LGwJS72949 for <[e-mail]>; Tue, 21 Jan 2003 08:58:19 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 17 - final resolution
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 21 Jan 2003 08:58:19 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> 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.
> 
> Jeff replied:
> 
>  To provide context, this paragraph currently reads:
> 
>  :   The hosts executing BGP need not be routers.  A non-routing host
>  :   could exchange routing information with routers via EGP [RFC904] or
>  :   even an interior routing protocol. That non-routing host could then
>  :   use BGP to exchange routing information with a border router in
>  :   another Autonomous System. The implications and applications of this
>  :   architecture are for further study.  
>   
>  There are several deployed entities that could be considered to "exploit"
>  this paragraph.  Route collectors, route servers, bandwidth shapers
>  and other optimizers.  However, the original text may be showing its
>  age a little bit.
> 
>  Perhaps the following might be a bit more appropriate:
> 
>  "The hosts executing BGP need not be routers.  A non-routing host may 
>   exchange routing information with a BGP speaker for reasons
>   that are outside the scope of this document."
>  
>  I would also propose adding to the same paragraph (but could be persuaded
>  to drop it since it is *logically* redundant):
>  "These non-routing hosts should exercise great care not to insert
>   themselves into the forwarding path if they re-announce BGP routes."
> 
> Yakov replied:
> 
>  Since operations of non-routing host are outside the scope of the
>  document, and since the document doesn't preclude non-routing hosts
>  to run BGP, I would prefer just to take the following paragraph out,
>  and not to add any new text.
> 
>    The hosts executing BGP need not be routers.  A non-routing host
>    could exchange routing information with routers via EGP [RFC904] or
>    even an interior routing protocol. That non-routing host could then
>    use BGP to exchange routing information with a border router in
>    another Autonomous System. The implications and applications of this  
>    architecture are for further study.
> 
> Jeff replied that this was ok, and instead suggested:
> 
> At the beginning of the document, we define:
>    BGP speaker
>          A router that implements BGP.
> 
>  This (potentially) restricts a speaker to being a router.
>  Additionally, several spots in the text where we probably should
>  say "BGP speaker", we use router.   
> 
> Yakov agreed to add this definition.
> 
> Jeff replied that there still was a problem with this definition being
> too limiting.  The discussion meandered off list for a couple of 
> exchanges and these additional definitions were proposed:
> 
> First Jeff proposed this:
> 
>  "A router that implements the BGP protocol.
>   Non-routing hosts that also implement BGP are out of scope of this
>   document."
> 
> Then Andrew replied, that we should make sure the definition does not
> opt out entirely from making sure that non-routing hosts are interoperable:
> 
> BGP Speaker
>     A router that implements the BGP protocol.  The internal behavior of
>     non-routing hosts that also implement BGP are out of scope of this
>     document.  However, in their interactions with routers, non-routing hosts
>     must behave as if they were routers.
> 
> And Jeff replied:
> 
> BGP Speaker
>     A router that implements the BGP protocol.  The internal behavior of
>     non-routing hosts that also implement BGP are out of scope of this
>     document.  However, in their interactions with BGP speaking routers, 
>     non-routing hosts that implement BGP should be indistinguishable from 
>     a router on the wire.
> 
>  (or something like that - s/on the wire/ with whatever sounds best.)
> 
>  IOW, look like bgp on the wire - what you do internally is out of scope.
> 
> This was discussed in the "proxy: more comments on draft -18" thread.  
> And in the "Issues list, #17: Section 3, Page 8, Paragraph 3 - Obsolete?"
> thread.

The current text is just fine. Since the definition of "BGP speaker"
makes it quite clear that in the context of this document it means
a router, and *not* a non-routing host implementing BGP, it follows
that the issue of non-routing hosts implementing BGP is outside
the document. 

If there is a sufficient interest to document the issues related
to non-routing hosts implementing BGP (including interaction between
these hosts and routers), then this should be done in a separate document.

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 LAA07728 for <[e-mail]>; Tue, 21 Jan 2003 11:45:06 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DC08091339; Tue, 21 Jan 2003 11:44:38 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A31DC9133A; Tue, 21 Jan 2003 11:44:38 -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 64D2F91339 for <[e-mail]>; Tue, 21 Jan 2003 11:44:37 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 447145E078; Tue, 21 Jan 2003 11:44:37 -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 848EF5DDBF for <[e-mail]>; Tue, 21 Jan 2003 11:44:36 -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 h0LGiaS72117 for <[e-mail]>; Tue, 21 Jan 2003 08:44:36 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 18
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 21 Jan 2003 08:44:36 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> 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.

Here is the text that will go in the next version of the draft:

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

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 KAA04875 for <[e-mail]>; Tue, 21 Jan 2003 10:49:44 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 88C6791331; Tue, 21 Jan 2003 10:49:28 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A0AC91330; Tue, 21 Jan 2003 10:49: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 BDE4191331 for <[e-mail]>; Tue, 21 Jan 2003 10:47:21 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 9F07C5DDDE; Tue, 21 Jan 2003 10:47:21 -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 1B9C35DDB8 for <[e-mail]>; Tue, 21 Jan 2003 10:47:21 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0LFlKR84135 for [e-mail]; Tue, 21 Jan 2003 10:47:20 -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 h0LFlCC84114 for <[e-mail]>; Tue, 21 Jan 2003 10:47:12 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: BGP-19: Issue 34-35, 40-48
Date: Tue, 21 Jan 2003 10:47:12 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: BGP-19: Issue 34-35, 40-48
Thread-Index: AcLBZF1VXAtaPbRNQAe4W6+zjJe5ew==
From: "Susan Hares" <[e-mail]>
To: <[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 KAA04875

Andrew and Siva: 

summary: 
	consensus:  34, 35, 43.47 
	possible consensus: 41,44
	no consensus, discussion needed: 40, 42, 48, 54 
	
 
-----------

Issue 34 -

I think that Siva and I have consensus on issue 34. 
I changed the text to "fails" based on other comments.

Issue 35 - I accept Siva's changes, please mark 
           this as consensus. 

Issue 40 - Clearing of the Connection Retry timer 

	We need to discuss our two points of view
	here.  This should be marked as no consensus
	
Issues 41  -
	question: Connect state, event 14 - will this happen? 
	
	My resolution: Let event 14 be optional. 
      Not all BGP implementations support it. 

	Siva - Does this let us reach consensus?

Issue 42 -  Handling events 20, 21 in Connect and Active states

	state: non-consensus

	I suggest we don't send a "NOTIFICATION" when
	Event 20 or Event 21 is received in Conect or Active state.

Issue 43: 
	
	state: consensus
	focus: editorial 
	I'll accept the text change from Siva with small editorial
	modification below. 

	old text: 
		-resets the connect retry timer (sets to zero)
		- clears the open delay timer 

	new text:
		- if the connect retry timer is running, 
			clear the connect retry timer (set to zero).
		 if the open delay timer is running,
			clear the open delay timer (set to zero).

	Siva - please confirm that this change is acceptable for
	the default case.  
	

Issue 44 

	Please reply if you have additional concerns, otherwise
	we will leave the text alone.

Issue 45
	status: change to consensus
	
	I'll  agree with Jeff, Tom and you.  Please consider this
	item in consensus.  I'll change the text.

Issue 47 - Event 19 in Active state 
	status: change to consensus 

	New text

	- if the hold timer value is non-zero,
		- starts the keepalive timer to initial value,  
		- resets the hold timer to the negotiated value,
	- else if the hold timer is zero
		- resets the keepalive timer (set to zero),
		- resets the hold timer to zero.


Issue 48 - 
	 status: non-consensus 
	
	 do you have any further comments.  If not, I'll leave
	the text as:

    state.
 
    A manual stop event[Event2], the local system:
        - Sends a NOTIFICATION with a Cease,
        - releases all BGP resources including
		- stopping the OPen delay timer 
        - drops the TCP connection, 
        - sets ConnectRetryCnt (connect retry count) to zero
        - resets the connect retry timer (sets to zero),
        - changes its state to Idle.

Issue 52 - 
	status: non-consensus 

		<----	Open [Open sent state]
	open ---->  
			[Event 18 in Open Sent 
		<----- Keepalive 

	Event 18:
		- clears BGP delay timer
		- resets BGP connect timer
		- sends Keepalive message
		- if negotiated hold timer is zero,
			o reset keepalive timer,
			o reset hold timer.

		- if negotiated hold timer is non-zero
			o set keepalive timer,
			o set hold timer to negotiated value. 


	Here the question is, do you want to send a 2nd
	keepalive if the keepalive timer expires in 
	Open Confirm.  

     The current draft allows this until the hold timer 
     expires.   The sequence would be:

			<---- open [open sent]
		open -->  [event 18]

			<-----keepalive

				[keepalive timeout [Event 11]
			<---- Keepalive

				[Keepalive time out [Event 11]
			<--- Keepalive

				[hold time-out, Event 10]
			<---Notification
			    drop TCP connection
			 




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA04741 for <[e-mail]>; Tue, 21 Jan 2003 10:47:02 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D5D9F912CF; Tue, 21 Jan 2003 10:46:39 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D7C291330; Tue, 21 Jan 2003 10:46: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 6D689912CF for <[e-mail]>; Tue, 21 Jan 2003 10:46:37 -0500 (EST)
Received: by segue.merit.edu (Postfix) id F02CA5DDE8; Tue, 21 Jan 2003 10:46:36 -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 90ADC5DDB8 for <[e-mail]>; Tue, 21 Jan 2003 10:46:36 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0LFkZk84047 for [e-mail]; Tue, 21 Jan 2003 10:46:35 -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 h0LFkQC84025 for <[e-mail]>; Tue, 21 Jan 2003 10:46:26 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: BGP-draft-19: Issue 52 - Event 18 in OpenSent State (Keepalive timer set)
Date: Tue, 21 Jan 2003 10:46:26 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: BGP-draft-19: Issue 52 - Event 18 in OpenSent State (Keepalive timer set)
Thread-Index: AcLBZEGcVLqit3RtQBSHDdpvL99E8A==
From: "Susan Hares" <[e-mail]>
To: "Jeffrey Haas" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[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 KAA04741

Jeff and Siva:


  I need to hear from additional implementers
on the following.  Would you both check your
implementations? 

Sue Hares

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


Issue 52 - 
	status: non-consensus 

		<----	Open [Open sent state]
	open ---->  
			[Event 18 in Open Sent 
		<----- Keepalive 

	Event 18:
		- clears BGP delay timer
		- resets BGP connect timer
		- sends Keepalive message
		- if negotiated hold timer is zero,
			o reset keepalive timer,
			o reset hold timer.

		- if negotiated hold timer is non-zero
			o set keepalive timer,
			o set hold timer to negotiated value. 


	Here the question is, do you want to send a 2nd
	keepalive if the keepalive timer expires in 
	Open Confirm.  

     The current draft allows this until the hold timer 
     expires.   The sequence would be:


     The current draft allows this until the hold timer 
     expires.   The sequence would be:

			<---- open [open sent]
		open -->  [event 18]

			<-----keepalive

				[keepalive timeout [Event 11]
			<---- Keepalive

				[Keepalive time out [Event 11]
			<--- Keepalive

				[hold time-out, Event 10]
			<---Notification
			    drop TCP connection
			 
Please confirm that you want to remove these subsequent keepalives in
Open Confirm.


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 UAA28302 for <[e-mail]>; Mon, 20 Jan 2003 20:04:48 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5BC44912B4; Mon, 20 Jan 2003 20:04:24 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02D63912B5; Mon, 20 Jan 2003 20: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 14E3F912B4 for <[e-mail]>; Mon, 20 Jan 2003 20:04:13 -0500 (EST)
Received: by segue.merit.edu (Postfix) id DE5305DF7D; Mon, 20 Jan 2003 20:04:12 -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 508DA5DF31 for <[e-mail]>; Mon, 20 Jan 2003 20:04:11 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id RAA29098; Mon, 20 Jan 2003 17:01:14 -0800 (PST)
Date: Mon, 20 Jan 2003 17:01:14 -0800
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: BGP Base Draft - Issue List v2.1 (Draft-19)
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="4Ckj6UjgE2iN1+kY"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: [e-mail]
Precedence: bulk

--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Attaches is version 2.1 of the issues list.  Since our last iteration,
we have updated 13 issues, and reached consensus on 4.  We're close
on 3 more (13.2, 13.4 and 13.6).  We have 22 issue remaining to clear
up.

Andrew

--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="Issue_List-v2.1.txt"

2003-01-20
v2.1

This is version 2.1 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)
13.5) FSM Missing Next States - Event 17 (Connect State)
14) FSM - Peer Oscillation Damping
15) FSM - Consistent FSM Event Names
16) Many Editorial Comments
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
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.6) FSM Missing Next States - Event 18 (Open Confirm)
17) Section 3, Page 8, Paragraph 3 - Obsolete?
18) MED Removal Text
24) Events 3, 5, 6 & 7 Give Examples
26) Event 4 & 5 - bgp_stop_flap option
33) Event 13 & 14 - Valid Addresses & Ports
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.

Jeff replied with a master diff showing the MUST/SHOULDs, for the entire
document please see the beginning of the thread entitled: 
"Issues list, #2: MUST/SHOULD Capitalization"

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

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

Discussion:

Jeff supplied:

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

Yakov mentioned that this is addressed in Appendix A.

Jeff replied:

 What I would like to see is something like this:

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

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

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

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

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

Discussion:

Jeff proposed an editorial fix.  This is agreed to.

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

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

Discussion:

Jeff proposed:

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

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

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

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

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

Discussion:

John brought this up, and suggested:

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

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

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

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

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

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

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

We are at consensus on this issue.

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

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

Discussion:

Tom proposed:

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

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

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

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

Discussion:

Tom pointed out that:

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

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

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

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

Discussion:

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

        - deletes all routes associated with this connection,

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

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

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

Discussion:

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

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

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

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

Discussion:

Tom pointed out that:

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

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

 OpenSent is for Open sent and not yet received.

 The corresponding section in Connect state I believe is correct.

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

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

----------------------------------------------------------------------------
12) Entering OpenConfirm / Adding "Stop OpenDelay" action
----------------------------------------------------------------------------
Status: 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.

Sue prodded the list saying that:

 Should the peer:
   1) Treat it as a valid response, and enters the active state
      to watch for a another TCP connection with a valid peer.

   2) treat it as an invalid response, reject the connection and see 
      if a valid configured one comes iwthin the connect timer's window.

 Without further input, I will select option 2.

Curtis replied that this was fine with him.

This conversation was started in the "bgp18 WG Last Call fsm missing next
state" thread.  It was also discussed in the "BGP draft-19 - FSM input
needed from developers" thread.

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

Discussion:

Tom pointed out:

      Active State:

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

Sue proposed these changes:

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

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

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

Tom agreeded with this.

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

----------------------------------------------------------------------------
13.4) FSM Missing Next States - Event 13-17 (TCP Connection)
----------------------------------------------------------------------------
Status: 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.

Sue prodded the list with:

 Do the implementors require Events 13 - 17 in the State machine ?

   Event 13 - TCP connection valid indication
   Event 14 - TCP connection invalid indication
   Event 15 - TCP connection request acknowedged
   Event 16 - TCP connection confirmed
   Event 17 - TCP connection fails

   Choice 1:  Events 13 - 17 are mandatory
   Choice 2:  Event 13 and Event 14 be optional, and Events 15 - 17 
              be mandatory.
 
 If no one objects, we will use Choice 2.

Curtis said this was fine with him.
                
This was started in the "bgp18 WG Last Call fsm missing next
state" thread.	And continued in the "fsm missing next state - Events 13-17
and the TCP connection" thread.  It was also discussed in the "BGP draft-19 
- FSM input needed from developers" thread.
 
----------------------------------------------------------------------------
13.5) FSM Missing Next States - Event 17 (Connect State)
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Closed in favor of 13.4

Discussion:


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

Sue replied with this:

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

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

 Alternative 1:


 FSM table new:

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

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

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

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

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

After the issues list came out Tom responded to this issue, saying:

 I think this issue SHOULD be administratively terminated.
     
 It relates to Connect state Event 17 (TCP connection fails) and I am
 credited with raising it; in fact, the issue I raised was missing next
 state for Active state event 17 and this has now been subsumed into
 13.4 (but note that 13.4 does not explicitly say Active state - I know
 it should because I raised that issue too).  I will ensure it does not
 get lost from any resolution of 13.4.
     
 And Connect state event 17 does appear as part of issue 45 which Siva
 raised so I think that either way, 13.5 can go.

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

----------------------------------------------------------------------------
13.6) FSM Missing Next States - Event 18 (Open Confirm)
----------------------------------------------------------------------------
Status: 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.

Sue prodded the list with:

 In the Open Confirm state, a valid Open message [Event 22] is received.
 The BGP Peer connection is check to ee if there is a collision per
 section 6.8.  If this connection is to be dropped due to the call 
 collision, the local system will drop the call by:

   - sending a NOTIFICATION with a CEASE,
   - resets the Connect timer (to zero),
   - releases all BGP resources (this includes stopping the Open Delay Timer 
       and reseting it to zero),
   - increments the ConnectRetryCnt by 1 (connect retry +count), and
   - optionally performs a BGP peer oscilation damping processing, and
   - enters the Idle State.
   
 Implementors need to verify if this text and the text for Event 22
 allows all implementors to perform the necessary Call Collision actions.
 
 If no objects, we will use this text.

Curtis said he had no problem with this.

This conversation was started in the "bgp18 WG Last Call fsm missing next 
state" thread. It was also discussed in the "BGP draft-19 - FSM input needed 
from developers" thread.

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

Discussion:

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

Yakov agreed to fix both of these.

----------------------------------------------------------------------------
15) FSM - Consistent FSM Event Names
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Make FSM names consistent.  Specifics are in the discssion section.

Discussion:

Tom proposed that:

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

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

 8. BGP Finite State machine

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

 8.2.2 Finite State Machine

      Connect State:

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

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

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

      Active State:

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

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

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

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

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

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

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

Sue replied:

 I will accept the text you proposed for the Event names.
 I will update the FSM text to include your changes.
    
 We'll consider issue 15 in consensus.  I've fixed the text.

So we are at consensus here.

This is discussed in the thread: "bgp18 WG Last Call fsm event names."  It
was also discussed in the "Issue 15 - Consistent FSM Event Names" thread.

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

Discussion:

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

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

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

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

 Perhaps we should just take out references to 1772.

Further discussion seemed to indicate that this reference should stay.

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

 I'll take it out.

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

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

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

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

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

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

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

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

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

 fixed.

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

 no.

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

 It is already clarified in 2283bis.

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

 fixed.

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

 the text is fine as it is.

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

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

 the former (the same attribute type).

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

 fixed.

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

 fixed.

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

 think we should keep the text as is.

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

 I think the text is ok as is.

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

 fixed.

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

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

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

 fixed.

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

 the former.

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

 fixed.

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

 fixed.

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

 fixed.

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

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

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

 fixed.

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

 fixed.

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

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

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

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

 I think it is fine where it is now.

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

 deleted.

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

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

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

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

----------------------------------------------------------------------------
17) Section 3, Page 8, Paragraph 3 - Obsolete?
----------------------------------------------------------------------------
Status: 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.

Jeff replied:

 To provide context, this paragraph currently reads:

 :   The hosts executing BGP need not be routers.  A non-routing host
 :   could exchange routing information with routers via EGP [RFC904] or
 :   even an interior routing protocol. That non-routing host could then
 :   use BGP to exchange routing information with a border router in
 :   another Autonomous System. The implications and applications of this
 :   architecture are for further study.  
  
 There are several deployed entities that could be considered to "exploit"
 this paragraph.  Route collectors, route servers, bandwidth shapers
 and other optimizers.  However, the original text may be showing its
 age a little bit.

 Perhaps the following might be a bit more appropriate:

 "The hosts executing BGP need not be routers.  A non-routing host may 
  exchange routing information with a BGP speaker for reasons
  that are outside the scope of this document."
 
 I would also propose adding to the same paragraph (but could be persuaded
 to drop it since it is *logically* redundant):
 "These non-routing hosts should exercise great care not to insert
  themselves into the forwarding path if they re-announce BGP routes."

Yakov replied:

 Since operations of non-routing host are outside the scope of the
 document, and since the document doesn't preclude non-routing hosts
 to run BGP, I would prefer just to take the following paragraph out,
 and not to add any new text.

   The hosts executing BGP need not be routers.  A non-routing host
   could exchange routing information with routers via EGP [RFC904] or
   even an interior routing protocol. That non-routing host could then
   use BGP to exchange routing information with a border router in
   another Autonomous System. The implications and applications of this  
   architecture are for further study.

Jeff replied that this was ok, and instead suggested:

At the beginning of the document, we define:
   BGP speaker
         A router that implements BGP.

 This (potentially) restricts a speaker to being a router.
 Additionally, several spots in the text where we probably should
 say "BGP speaker", we use router.   

Yakov agreed to add this definition.

Jeff replied that there still was a problem with this definition being
too limiting.  The discussion meandered off list for a couple of 
exchanges and these additional definitions were proposed:

First Jeff proposed this:

 "A router that implements the BGP protocol.
  Non-routing hosts that also implement BGP are out of scope of this
  document."

Then Andrew replied, that we should make sure the definition does not
opt out entirely from making sure that non-routing hosts are interoperable:

BGP Speaker
    A router that implements the BGP protocol.  The internal behavior of
    non-routing hosts that also implement BGP are out of scope of this
    document.  However, in their interactions with routers, non-routing hosts
    must behave as if they were routers.

And Jeff replied:

BGP Speaker
    A router that implements the BGP protocol.  The internal behavior of
    non-routing hosts that also implement BGP are out of scope of this
    document.  However, in their interactions with BGP speaking routers, 
    non-routing hosts that implement BGP should be indistinguishable from 
    a router on the wire.

 (or something like that - s/on the wire/ with whatever sounds best.)

 IOW, look like bgp on the wire - what you do internally is out of scope.

This was discussed in the "proxy: more comments on draft -18" thread.  
And in the "Issues list, #17: Section 3, Page 8, Paragraph 3 - Obsolete?"
thread.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
Summary: Add the text in the discussion section.

Discussion:

This discussion began with Siva asking:

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

 Can we also add the following session attributes:

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

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

After some discussion we have this text on the table:

    Event8: Idle hold timer expires

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

 I will accept the new text for the following total text:
     
    Event8: Idle hold timer expires

           Definition: An event generated when the Idle Hold Timer
                       expires indicating that the session has completed
                       a back-off period to prevent bgp peer oscillation.

                       The Idle Hold Timer is only used when the persistent
                       peer oscillation damping function is enabled.

                       Implementations not implementing the presistent peer
                       oscillation damping functions may not have the Idle Hold
                       Timer.

           Status:     Optional

We are at consensus with this.

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

----------------------------------------------------------------------------
22) Specify New Attributes (Accept Connections/Peer Oscillation Damping)
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add the text in the discussion section to section 8.0.

Discussion:

This begain with Siva propsosing:

  Can we call these out as well:

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

After some discussion we have this text on the table:

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

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

Sue accepted these changes, we're at consensus with this.

This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #3.  This was also discussed in the "BGP Draft 19 - Close open
items 22" thread.

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

Discussion:

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

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

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

----------------------------------------------------------------------------
24) Events 3, 5, 6 & 7 Give Examples
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Do we have consensus on the new text?

Discussion:

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

Sue replied that she has made the following changes, and asked if these
worked for Siva.

New text:
 

    Event7: Automatic stop

           Definition: Local system automatically stops the
                       BGP connection.

                       An example of an automatic stop event is
                       exceeding the number of prefixes for a given
                       peer and the local system  automatically
                       disconnecting the peer.


           Status:     Optional depending on local system

This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #5.  This was also in the "Issue 25" thread, and the "Issue 25 -
this is really issue 24" threads.

----------------------------------------------------------------------------
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.

Tom replied:

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

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

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

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.

Sue asked Siva to provide some text.

This was discussed in the "Comments 11-20" thread: Comment #14.  This
was also in the "BGP-19: Issue 33" thread.

----------------------------------------------------------------------------
34) Event 17 - TCP Connection Fails to TCP Connection Termination
----------------------------------------------------------------------------
Status: 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: Is the proposed text acceptable?

Discussion:

This began with Siva asking:

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

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

Sue replied refering to the disussion tracked in issue 13.4.

Jeff responded that:

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

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

Tom replied that he agreed with this.

Tom then proposed this text:

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

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

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

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.

--4Ckj6UjgE2iN1+kY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="Changelog-v2.txt"

CHANGELOG

----------------------------------------------------------------------------
v2.0 to v2.1
2003-01-08
----------------------------------------------------------------------------

Updated:

2) MUST/SHOULD Capitalization
13.2) FSM Missing Next States - Event 14 (Connect State)
13.4) FSM Missing Next States - Event 13-17 (TCP Connection)
13.5) FSM Missing Next States - Event 17 (Connect State)
13.6) FSM Missing Next States - Event 18 (Open Confirm)
15) FSM - Consistent FSM Event Names
17) Section 3, Page 8, Paragraph 3 - Obsolete?
21) Session Attributes - IdleHold Timer
22) Specify New Attributes (Accept Connections/Peer Oscillation Damping)
24) Events 3, 5, 6 & 7 Give Examples
26) Event 4 & 5 - bgp_stop_flap option
33) Event 13 & 14 - Valid Addresses & Ports
45) Event 17 in the Connect state

Moved to Consensus:

13.5) FSM Missing Next States - Event 17 (Connect State)
15) FSM - Consistent FSM Event Names
21) Session Attributes - IdleHold Timer
22) Specify New Attributes (Accept Connections/Peer Oscillation Damping)


--4Ckj6UjgE2iN1+kY--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA26748 for <[e-mail]>; Mon, 20 Jan 2003 19:45:06 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id AB60D912B0; Mon, 20 Jan 2003 19:44:25 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 749DD912B1; Mon, 20 Jan 2003 19:44: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 529F3912B0 for <[e-mail]>; Mon, 20 Jan 2003 19:44:24 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 388855DF7D; Mon, 20 Jan 2003 19:44:24 -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 CCBFD5DF23 for <[e-mail]>; Mon, 20 Jan 2003 19:44:23 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id QAA28843; Mon, 20 Jan 2003 16:40:52 -0800 (PST)
Date: Mon, 20 Jan 2003 16:40:52 -0800
From: [e-mail]
To: Curtis Villamizar <[e-mail]>
Cc: Susan Hares <[e-mail]>, [e-mail], Russ White <[e-mail]>, Matt Richardson <[e-mail]>, [e-mail], [e-mail]
Subject: Re: BGP draft-19 - FSM input needed from developers
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, Jan 20, 2003 at 05:48:27PM -0500
Sender: [e-mail]
Precedence: bulk

Sue, 

I agree with Curtis on this, if someone objects, I'll open an issue and
we can track the discussion.  If you feel strongly that it should be
on the issues list anyway, let me know and I'll put it there.

Andrew

> In message <[e-mail]
> m>, "Susan Hares" writes:
> > Curtis:
> > 
> > Thanks for the input.  It is indeed "connection collision".
> > I've fixed the text.
> > 
> > [I think this is a new issue for Andrew to track]
> > 
> > Sue
> 
> 
> Sue,
> 
> If there is no argument against this maybe we can just call it a minor
> editorial change and not bother tracking it as an issue.
> 
> Curtis
> 
> 
> 
> > All fine except there is no "call collision".  Perhaps you mean
> > "connection collision".  There seem to be 4 instances of "call
> > collision" that should be replaced with "connection collision" in the
> > draft.
> > 
> > 
> > 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 SAA20760 for <[e-mail]>; Mon, 20 Jan 2003 18:26:20 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id AAC9C912A4; Mon, 20 Jan 2003 18:25:58 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E7D7912A5; Mon, 20 Jan 2003 18:25:58 -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 37A65912A4 for <[e-mail]>; Mon, 20 Jan 2003 18:25:57 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1C8085DF1B; Mon, 20 Jan 2003 18:25: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 84F495DF17 for <[e-mail]>; Mon, 20 Jan 2003 18:25:56 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0KNPta67783 for [e-mail]; Mon, 20 Jan 2003 18:25:55 -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 h0KNPnC67770 for <[e-mail]>; Mon, 20 Jan 2003 18:25:49 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: BGP-19: Issue 33
Date: Mon, 20 Jan 2003 18:25:49 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: BGP-19: Issue 33
Thread-Index: AcLA20QoZ+UrLnEsQt6SzQ1Zllj5zA==
From: "Susan Hares" <[e-mail]>
To: <[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 SAA20760

Siva:

Can you sugest some text on the destination port that
needs to be added to Event 13 and 14?

Sue


----------------------------------------------------------------------------
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.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA19810 for <[e-mail]>; Mon, 20 Jan 2003 18:13:48 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 0A78A912A3; Mon, 20 Jan 2003 18:13:29 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0497912A4; Mon, 20 Jan 2003 18:13: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 487D8912A3 for <[e-mail]>; Mon, 20 Jan 2003 18:13:27 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 2ADAA5DF3C; Mon, 20 Jan 2003 18:13:27 -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 6DFA95DDE1 for <[e-mail]>; Mon, 20 Jan 2003 18:13:26 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0KNDPJ67525 for [e-mail]; Mon, 20 Jan 2003 18:13:25 -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 h0KNDJC67511 for <[e-mail]>; Mon, 20 Jan 2003 18:13:19 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: Issue 26 - Do you want me to add 
Date: Mon, 20 Jan 2003 18:13:19 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Issue 26 - Do you want me to add 
Thread-Index: AcLA2YUDv7arZNH7TbGFQj+oNTjGqQ==
From: "Susan Hares" <[e-mail]>
To: "[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 SAA19810

Siva:

At the bottom is the re-cap of issue 26.  
Below is line is the text for adding option 3.
Please confirm if you wish to add option #3.
If you do, we have consensus on this topic.

Sue

===========

Addition Option #3
===============
To add #3, I would add an Event 7b with the following state machine

    Event7b: Automatic start with passive TCP flag and 
		bgp_stop_flap flag set

   
           Definition: Local system automatically starts the BGP 
		  Peer connection with passive TCP flag and
		  BGP Peer oscillation enabled.  The passive TCP 
		  flag indicates that this peer will listen prior to establishing
		  a BGP connection.  The bgp_stop_flag flag indicates
		  that this peer will damp persistent oscillations of peer
		  connections (connect-disconnect-connect). 

		  The exact method of  damping persistent peer
                          oscillations is left up to the  implementation and
                          is outside of the scope of this document. 
   	
           Status:    Optional depending on local system
   
The state machine would be
    
    # Event     Idle    Connect  Active   Open    Open      Estab. 
                                          sent    Confirm   
====================================================================
    7b Auto    See peer  Connect Active    Open    Open      Estab. 
      start &  damp     /Ignore /Ignore    Sent/   Confirm/ /Ignore 
      bgp flap draft/                     Ignore   Ignore    
      stop on   F-2   
      & passive
      [note 1]

	F-2 

	If no bgp flap damping is engaged, the local sytem will: 
	  1) Restart ConnectRetry timer (with initial value)
	  2) Listen for a valid remote TCP connection  
----------------






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.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA18107 for <[e-mail]>; Mon, 20 Jan 2003 17:52:10 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 201779129C; Mon, 20 Jan 2003 17:50:34 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE5079129E; Mon, 20 Jan 2003 17:50:33 -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 6BDAE9129C for <[e-mail]>; Mon, 20 Jan 2003 17:50:25 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 554245DF11; Mon, 20 Jan 2003 17:50:25 -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 538CA5DDE1 for <[e-mail]>; Mon, 20 Jan 2003 17:50:24 -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 RAA57476; Mon, 20 Jan 2003 17:48:27 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Susan Hares" <[e-mail]>
Cc: [e-mail], [e-mail], "Russ White" <[e-mail]>, "Matt Richardson" <[e-mail]>, [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: BGP draft-19 - FSM input needed from developers 
In-reply-to: Your message of "Mon, 20 Jan 2003 17:28:36 EST." <[e-mail]> 
Date: Mon, 20 Jan 2003 17:48:27 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
m>, "Susan Hares" writes:
> Curtis:
> 
> Thanks for the input.  It is indeed "connection collision".
> I've fixed the text.
> 
> [I think this is a new issue for Andrew to track]
> 
> Sue


Sue,

If there is no argument against this maybe we can just call it a minor
editorial change and not bother tracking it as an issue.

Curtis



> All fine except there is no "call collision".  Perhaps you mean
> "connection collision".  There seem to be 4 instances of "call
> collision" that should be replaced with "connection collision" in the
> draft.
> 
> 
> 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 RAA17399 for <[e-mail]>; Mon, 20 Jan 2003 17:43:25 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 417DA9129B; Mon, 20 Jan 2003 17:43:00 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7CC49129C; Mon, 20 Jan 2003 17:42: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 58EE59129A for <[e-mail]>; Mon, 20 Jan 2003 17:42:58 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 44C695DF3C; Mon, 20 Jan 2003 17:42:58 -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 AC0895DF30 for <[e-mail]>; Mon, 20 Jan 2003 17:42:57 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0KMguQ66748 for [e-mail]; Mon, 20 Jan 2003 17:42:56 -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 h0KMglC66722 for <[e-mail]>; Mon, 20 Jan 2003 17:42:47 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: FW: Issue 25 - this is really issue 24
Date: Mon, 20 Jan 2003 17:42:47 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Issue 25 
Thread-Index: AcLA1OdtqT5sRXr4RmKkU46wH4TqzgAACoVQ
From: "Susan Hares" <[e-mail]>
To: <[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 RAA17399

Siva:

This is regarding issue 24 instead of 25. 
25 is closed.

Sue

>  -----Original Message-----
> From: 	Susan Hares  
> Sent:	Monday, January 20, 2003 5:40 PM
> To:	'[e-mail]'
> Cc:	'[e-mail]'
> Subject:	Issue 25 
> 
> Siva:
> 
> I believe we have consensus on issue 25.  I've added the
> example for an automatic stop to the event description.
> 
> New text:
> 
>    
>     Event7: Automatic stop
>    
>            Definition: Local system automatically stops the
>                        BGP connection.   
> 
>                        An example of an automatic stop event is
>                        exceeding the number of prefixes for a given
>                        peer and the local system  automatically
>                        disconnecting the peer.
> 
>    	
>            Status:     Optional depending on local system
>    
> Please confirm that we have consensus on this issue.
> 
> 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 RAA17193 for <[e-mail]>; Mon, 20 Jan 2003 17:40:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id CDFD891299; Mon, 20 Jan 2003 17:40:25 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 957419129A; Mon, 20 Jan 2003 17:40: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 4072C91299 for <[e-mail]>; Mon, 20 Jan 2003 17:40:24 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 309075DF11; Mon, 20 Jan 2003 17:40: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 9AFE65DF07 for <[e-mail]>; Mon, 20 Jan 2003 17:40:23 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0KMeMk66616 for [e-mail]; Mon, 20 Jan 2003 17:40:22 -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 h0KMeHC66602 for <[e-mail]>; Mon, 20 Jan 2003 17:40:17 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: Issue 25 
Date: Mon, 20 Jan 2003 17:40:16 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Issue 25 
Thread-Index: AcLA1OdtqT5sRXr4RmKkU46wH4Tqzg==
From: "Susan Hares" <[e-mail]>
To: <[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 RAA17193

Siva:

I believe we have consensus on issue 25.  I've added the
example for an automatic stop to the event description.

New text:

   
    Event7: Automatic stop
   
           Definition: Local system automatically stops the
                       BGP connection.   

                       An example of an automatic stop event is
                       exceeding the number of prefixes for a given
                       peer and the local system  automatically
                       disconnecting the peer.

   	
           Status:     Optional depending on local system
   
Please confirm that we have consensus on this issue.

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 RAA16124 for <[e-mail]>; Mon, 20 Jan 2003 17:29:26 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 129E291297; Mon, 20 Jan 2003 17:28:59 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D466491299; Mon, 20 Jan 2003 17:28:58 -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 4BDC491297 for <[e-mail]>; Mon, 20 Jan 2003 17:28:51 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 35F0A5DF30; Mon, 20 Jan 2003 17:28: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 CC26F5DF2B for <[e-mail]>; Mon, 20 Jan 2003 17:28:50 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0KMSov66162 for [e-mail]; Mon, 20 Jan 2003 17:28:50 -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 h0KMSaC66127 for <[e-mail]>; Mon, 20 Jan 2003 17:28:36 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: BGP draft-19 - FSM input needed from developers 
Date: Mon, 20 Jan 2003 17:28:36 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: BGP draft-19 - FSM input needed from developers 
Thread-Index: AcLAwC6JAhzRKUkGQque4osClrxuAQAEmM4g
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Russ White" <[e-mail]>, "Matt Richardson" <[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 RAA16124

Curtis:

Thanks for the input.  It is indeed "connection collision".
I've fixed the text.

[I think this is a new issue for Andrew to track]

Sue

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]]
Sent: Monday, January 20, 2003 3:10 PM
To: Susan Hares
Cc: [e-mail]; Russ White; Matt Richardson; [e-mail];
[e-mail]
Subject: Re: BGP draft-19 - FSM input needed from developers 



In message <[e-mail]
m>, "Susan Hares" writes:
> 
> The following state machine issues were queried to the list between 12/2 - 12
> /20 
> 
> The following issues need input from developers:
> 
> 	13.2, 13.4, 13.6 
> 
> ========================================================
> 
> 	13.2 -  Connect state, Event 14th
> 
> 	      Event 14: 
> 		receipt of a valid TCP connection with an invalid or unconfigur
> ed peer
> 	         	
> 
> 	      Should the peer:
> 		1) Treat it as a valid response, and enters the active state
> 		   to watch for a another TCP connection with a valid peer.
> 
> 		2) treat it as an invalid response, reject the connection and s
> ee if a valid
> 		   configured one comes iwthin the connect timer's window.
> 
> 	         Without further input, I will select option 2. 
> 	
> 	13.4 TCP connection events in state machine
> 
> 		Do the implementors require Events 13 - 17 in the State machine
> ?
> 
> 		Event 13 - TCP connection valid indication
> 		Event 14 - TCP connection invalid indication
> 		Event 15 - TCP connection request acknowedged
> 		Event 16 - TCP connection confirmed
> 		Event 17 - TCP connection fails 
> 
> 		Choice 1:  Events 13 - 17 are mandatory
> 		Choice 2:  Event 13 and Event 14 be optional, and Events 15 - 1
> 7 be mandator.
> 
> 		If no one objects, we will use Choice 2.
> 
> 	13.6   FSM Missing Next States
> 
> 		In the Open Confirm state, a valid Open message [Event 22] is r
> eceived.  
> 		The BGP Peer connection is check to ee if there is a collision 
> per 
> 		section 6.8.  If this connection is to be dropped due to the ca
> ll collision,
> 		the local system will drop the call by:
> 
> 			- sending a NOTIFICATION with a CEASE,
> 			- resets the Connect timer (to zero),
> 			- releases all BGP resources 
> 				(this includes stopping the Open Delay Timer an
> d reseting it to zero),
> 			- increments the ConnectRetryCnt by 1 (connect retry co
> unt), and
> 			- optionally performs a BGP peer oscilation damping pro
> cessing, and
> 			- enters the Idle State.
> 
> 		Implementors need to verify if this text and the text for Event
>  22 allows all implementors
> 		to perform the necessary Call Collision actions.
> 
> 		If no objects, we will use this text.
> 
> 
> Thank you for your help.
> 
> Sue Hares



All fine except there is no "call collision".  Perhaps you mean
"connection collision".  There seem to be 4 instances of "call
collision" that should be replaced with "connection collision" in the
draft.


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 PAA05432 for <[e-mail]>; Mon, 20 Jan 2003 15:12:15 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 3A03D9128E; Mon, 20 Jan 2003 15:11:57 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB8609128F; Mon, 20 Jan 2003 15:11: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 8A4CA9128E for <[e-mail]>; Mon, 20 Jan 2003 15:11:55 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 69C175DE5A; Mon, 20 Jan 2003 15:11:55 -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 450345DE3C for <[e-mail]>; Mon, 20 Jan 2003 15:11:54 -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 PAA55902; Mon, 20 Jan 2003 15:09:54 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Susan Hares" <[e-mail]>
Cc: [e-mail], "Russ White" <[e-mail]>, "Matt Richardson" <[e-mail]>, [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: BGP draft-19 - FSM input needed from developers 
In-reply-to: Your message of "Mon, 20 Jan 2003 13:54:16 EST." <[e-mail]> 
Date: Mon, 20 Jan 2003 15:09:53 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
m>, "Susan Hares" writes:
> 
> The following state machine issues were queried to the list between 12/2 - 12
> /20 
> 
> The following issues need input from developers:
> 
> 	13.2, 13.4, 13.6 
> 
> ========================================================
> 
> 	13.2 -  Connect state, Event 14th
> 
> 	      Event 14: 
> 		receipt of a valid TCP connection with an invalid or unconfigur
> ed peer
> 	         	
> 
> 	      Should the peer:
> 		1) Treat it as a valid response, and enters the active state
> 		   to watch for a another TCP connection with a valid peer.
> 
> 		2) treat it as an invalid response, reject the connection and s
> ee if a valid
> 		   configured one comes iwthin the connect timer's window.
> 
> 	         Without further input, I will select option 2. 
> 	
> 	13.4 TCP connection events in state machine
> 
> 		Do the implementors require Events 13 - 17 in the State machine
> ?
> 
> 		Event 13 - TCP connection valid indication
> 		Event 14 - TCP connection invalid indication
> 		Event 15 - TCP connection request acknowedged
> 		Event 16 - TCP connection confirmed
> 		Event 17 - TCP connection fails 
> 
> 		Choice 1:  Events 13 - 17 are mandatory
> 		Choice 2:  Event 13 and Event 14 be optional, and Events 15 - 1
> 7 be mandator.
> 
> 		If no one objects, we will use Choice 2.
> 
> 	13.6   FSM Missing Next States
> 
> 		In the Open Confirm state, a valid Open message [Event 22] is r
> eceived.  
> 		The BGP Peer connection is check to ee if there is a collision 
> per 
> 		section 6.8.  If this connection is to be dropped due to the ca
> ll collision,
> 		the local system will drop the call by:
> 
> 			- sending a NOTIFICATION with a CEASE,
> 			- resets the Connect timer (to zero),
> 			- releases all BGP resources 
> 				(this includes stopping the Open Delay Timer an
> d reseting it to zero),
> 			- increments the ConnectRetryCnt by 1 (connect retry co
> unt), and
> 			- optionally performs a BGP peer oscilation damping pro
> cessing, and
> 			- enters the Idle State.
> 
> 		Implementors need to verify if this text and the text for Event
>  22 allows all implementors
> 		to perform the necessary Call Collision actions.
> 
> 		If no objects, we will use this text.
> 
> 
> Thank you for your help.
> 
> Sue Hares



All fine except there is no "call collision".  Perhaps you mean
"connection collision".  There seem to be 4 instances of "call
collision" that should be replaced with "connection collision" in the
draft.

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 OAA03608 for <[e-mail]>; Mon, 20 Jan 2003 14:49:55 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 4AC9A9128D; Mon, 20 Jan 2003 14:49:22 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A11A9128B; Mon, 20 Jan 2003 14:49:22 -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 96CB09128D for <[e-mail]>; Mon, 20 Jan 2003 14:47:35 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 730725DE3C; Mon, 20 Jan 2003 14:47: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 730795DDA6 for <[e-mail]>; Mon, 20 Jan 2003 14:47:34 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0KJlXv62451 for [e-mail]; Mon, 20 Jan 2003 14:47:33 -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 h0KJlUC62444 for <[e-mail]>; Mon, 20 Jan 2003 14:47:30 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: BGP Draft 19 - Close open items 22
Date: Mon, 20 Jan 2003 14:47:29 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: BGP Draft 19 - Close open items 22
Thread-Index: AcLAvMRXO08fom7eRPWTzlpQ1+ZxLQ==
From: "Susan Hares" <[e-mail]>
To: <[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 OAA03608

Please consider items 22 closed with the following final text:

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

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


Sue


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA02742 for <[e-mail]>; Mon, 20 Jan 2003 14:39:13 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6272A9128A; Mon, 20 Jan 2003 14:38:54 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 300E89128B; Mon, 20 Jan 2003 14:38:54 -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 CF2269128A for <[e-mail]>; Mon, 20 Jan 2003 14:38:52 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B15255DE3C; Mon, 20 Jan 2003 14:38:52 -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 26C7D5DDFA for <[e-mail]>; Mon, 20 Jan 2003 14:38:52 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0KJcpB62291 for [e-mail]; Mon, 20 Jan 2003 14:38:51 -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 h0KJcmC62284 for <[e-mail]>; Mon, 20 Jan 2003 14:38:48 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: Draft 19 - issue #21 
Date: Mon, 20 Jan 2003 14:38:48 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft 19 - issue #21 
Thread-Index: AcLAu41TMYK5qURSQ7ysdVmqNGeneg==
From: "Susan Hares" <[e-mail]>
To: <[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 OAA02742

I will accept the new text for the following total text:

    Event8: Idle hold timer expires 
   
           Definition: An event generated when the Idle Hold Timer
		       expires indicating that the session has completed
		       a back-off period to prevent bgp peer oscillation. 
	
 		       The Idle Hold Timer is only used when the persistent
                       peer oscillation damping function is enabled.  

                       Implementations not implementing the presistent peer 
                       oscillation damping functions may not have the Idle Hold
                       Timer. 
   
           Status:     Optional


Sue Hares


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA01373 for <[e-mail]>; Mon, 20 Jan 2003 14:21:48 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1C70391207; Mon, 20 Jan 2003 14:21:12 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D85AC9128A; Mon, 20 Jan 2003 14:21: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 8104991207 for <[e-mail]>; Mon, 20 Jan 2003 14:21:10 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 643095DDEE; Mon, 20 Jan 2003 14:21: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 CE0F35DD8C for <[e-mail]>; Mon, 20 Jan 2003 14:21:09 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0KJL9561779 for [e-mail]; Mon, 20 Jan 2003 14: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 h0KJL3C61766 for <[e-mail]>; Mon, 20 Jan 2003 14:21:03 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: Issue 15 - Consistent FSM Event Names
Date: Mon, 20 Jan 2003 14:21:03 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Issue 15 - Consistent FSM Event Names
Thread-Index: AcLAuRKETyHBiamWQ4GH8je8Z+cXiQ==
From: "Susan Hares" <[e-mail]>
To: "Tom Petch" <[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 OAA01373

Tom:

I will accept the text you proposed for the Event names.
I will update the FSM text to include your changes.

We'll consider issue 15 in consensus.  I've fixed the text.\

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 NAA29205 for <[e-mail]>; Mon, 20 Jan 2003 13:54:46 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8857091288; Mon, 20 Jan 2003 13:54:28 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57F429128A; Mon, 20 Jan 2003 13:54: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 D28F991288 for <[e-mail]>; Mon, 20 Jan 2003 13:54:26 -0500 (EST)
Received: by segue.merit.edu (Postfix) id B3AB05DDB4; Mon, 20 Jan 2003 13:54: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 222A75DDA6 for <[e-mail]>; Mon, 20 Jan 2003 13:54:26 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0KIsPH61038 for [e-mail]; Mon, 20 Jan 2003 13:54:25 -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 h0KIsHC61018 for <[e-mail]>; Mon, 20 Jan 2003 13:54:17 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: BGP draft-19 - FSM input needed from developers
Date: Mon, 20 Jan 2003 13:54:16 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: BGP draft-19 - FSM input needed from developers
Thread-Index: AcLAtVUjiPCzgrDZRDmaC058A4qPeg==
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>
Cc: "Russ White" <[e-mail]>, "Matt Richardson" <[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 NAA29205

The following state machine issues were queried to the list between 12/2 - 12/20 

The following issues need input from developers:

	13.2, 13.4, 13.6 

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

	13.2 -  Connect state, Event 14th

	      Event 14: 
		receipt of a valid TCP connection with an invalid or unconfigured peer
	         	

	      Should the peer:
		1) Treat it as a valid response, and enters the active state
		   to watch for a another TCP connection with a valid peer.

		2) treat it as an invalid response, reject the connection and see if a valid
		   configured one comes iwthin the connect timer's window.

	         Without further input, I will select option 2. 
	
	13.4 TCP connection events in state machine

		Do the implementors require Events 13 - 17 in the State machine?

		Event 13 - TCP connection valid indication
		Event 14 - TCP connection invalid indication
		Event 15 - TCP connection request acknowedged
		Event 16 - TCP connection confirmed
		Event 17 - TCP connection fails 

		Choice 1:  Events 13 - 17 are mandatory
		Choice 2:  Event 13 and Event 14 be optional, and Events 15 - 17 be mandator.

		If no one objects, we will use Choice 2.

	13.6   FSM Missing Next States

		In the Open Confirm state, a valid Open message [Event 22] is received.  
		The BGP Peer connection is check to ee if there is a collision per 
		section 6.8.  If this connection is to be dropped due to the call collision,
		the local system will drop the call by:

			- sending a NOTIFICATION with a CEASE,
			- resets the Connect timer (to zero),
			- releases all BGP resources 
				(this includes stopping the Open Delay Timer and reseting it to zero),
			- increments the ConnectRetryCnt by 1 (connect retry count), and
			- optionally performs a BGP peer oscilation damping processing, and
			- enters the Idle State.

		Implementors need to verify if this text and the text for Event 22 allows all implementors
		to perform the necessary Call Collision actions.

		If no objects, we will use this text.


Thank you for your help.

Sue Hares

		



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA00615 for <[e-mail]>; Mon, 20 Jan 2003 07:37:11 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2C2699123B; Mon, 20 Jan 2003 07:36:45 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E001C9125C; Mon, 20 Jan 2003 07:36: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 6A2919123B for <[e-mail]>; Mon, 20 Jan 2003 07:36:43 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 4471F5E0CB; Mon, 20 Jan 2003 07:36:43 -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 EDD125DE3A for <[e-mail]>; Mon, 20 Jan 2003 07:36:42 -0500 (EST)
Received: from tom3 (userbl95.uk.uudial.com [62.188.144.202]) by shockwave.systems.pipex.net (Postfix) with SMTP id 7C17116000D3C; Mon, 20 Jan 2003 12:36:39 +0000 (GMT)
Message-ID: <003c01c2c080$6659c020$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Susan Hares" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)
Date: Mon, 20 Jan 2003 12:33:54 -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

Yes I withdraw 13.5

Tom Petch
[e-mail]

-----Original Message-----
From: Susan Hares <[e-mail]>
To: [e-mail] <[e-mail]>;
Tom Petch <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Date: 20 January 2003 04:51
Subject: RE: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)


Tom:

Just to be sure.  You are withdrawing issue 13.5.
Please confirm on the list.  I am trying to settle
FSM issues this week.

Thanks,

Sue

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
Sent: Monday, December 23, 2002 6:19 PM
To: Tom Petch
Cc: [e-mail]; [e-mail]
Subject: Re: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)


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 XAA03449 for <[e-mail]>; Sun, 19 Jan 2003 23:51:27 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D821391268; Sun, 19 Jan 2003 23:51:00 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7D0D91275; Sun, 19 Jan 2003 23:51:00 -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 3C61391268 for <[e-mail]>; Sun, 19 Jan 2003 23:50:59 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 25A675DFC3; Sun, 19 Jan 2003 23:50:59 -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 BD7F35DF7A for <[e-mail]>; Sun, 19 Jan 2003 23:50:58 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0K4ov448837 for [e-mail]; Sun, 19 Jan 2003 23:50:57 -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 h0K4ojC48810 for <[e-mail]>; Sun, 19 Jan 2003 23:50:45 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)
Date: Sun, 19 Jan 2003 23:50:45 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)
Thread-Index: AcKq2jkM8iOXk94YSS29C8rsDReihQVY1Miw
From: "Susan Hares" <[e-mail]>
To: <[e-mail]>, "Tom Petch" <[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 XAA03449

Tom:

Just to be sure.  You are withdrawing issue 13.5.
Please confirm on the list.  I am trying to settle
FSM issues this week.

Thanks,

Sue

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]
Sent: Monday, December 23, 2002 6:19 PM
To: Tom Petch
Cc: [e-mail]; [e-mail]
Subject: Re: 13.5 in BGP Base Draft - Issue List v2.0 (Draft-19)


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 WAA00039 for <[e-mail]>; Sun, 19 Jan 2003 22:52:42 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 04B7491257; Sun, 19 Jan 2003 22:52:06 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE64C91258; Sun, 19 Jan 2003 22:52: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 6332591257 for <[e-mail]>; Sun, 19 Jan 2003 22:52:04 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 4802B5E07F; Sun, 19 Jan 2003 22:52:04 -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 A65465DE2E for <[e-mail]>; Sun, 19 Jan 2003 22:52:03 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h0K3q2p48287 for [e-mail]; Sun, 19 Jan 2003 22:52:02 -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 h0K3pvC48274 for <[e-mail]>; Sun, 19 Jan 2003 22:51:57 -0500 (EST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: draft 19 - Issue 12
Date: Sun, 19 Jan 2003 22:51:57 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft 19 - Issue 12
Thread-Index: AcLAN0dc96/nrCudTZSIDeMfNM4j/g==
From: "Susan Hares" <[e-mail]>
To: <[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 WAA00039

On issue 12:  Entering OpenConfirm/Adding "Stop Opendelay action"

 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.
================
I accept the comments from Tom Petch.  Mark issue 12 has having consensus.

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 QAA28889 for <[e-mail]>; Thu, 16 Jan 2003 16:38:51 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5CB7C91263; Thu, 16 Jan 2003 16:38:28 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2858F91266; Thu, 16 Jan 2003 16:38: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 0E1D591263 for <[e-mail]>; Thu, 16 Jan 2003 16:38:26 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D441F5DE76; Thu, 16 Jan 2003 16:38:26 -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 3E2275DE08 for <[e-mail]>; Thu, 16 Jan 2003 16:38:26 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id NAA17454; Thu, 16 Jan 2003 13:35:13 -0800 (PST)
Date: Thu, 16 Jan 2003 13:35:13 -0800
From: [e-mail]
To: Mireille Shammas <[e-mail]>
Cc: [e-mail]
Subject: Re: Aggregation and MED on the issues list
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 Tue, Jan 14, 2003 at 09:15:05AM -0500
Sender: [e-mail]
Precedence: bulk

Mireille,

I thought this issue was addressed in issue 65 from the v1.x lists.  I've
included the issue listing below.

Andrew

> A while back when draft-18 was being reviewed an issue was raised
> regarding section 9.2.2.2
> 
> "Routes that have different MULTI_EXIT_DISC attribute SHALL NOT be
> aggregated."
> 
> This issue was not tracked down by issues list.
> 
> Many people have argued that this rule could be relaxed to SHOULD NOT
> since many venders don't comply. I understand that this can be harmful
> in some situations. However,  The correct behavior for aggregating
> routes with the same MED was never clarified. For example, what is
> correct behavior if we have 4 prefixes contributing to an aggregate
> address and 2 of them have MED x and the other 2 have MED y. Should we
> aggregate at all in this situations?
> 
> I think this issue needs to be added to the list to get its full
> diligence.
> 
> Mireille

----------------------------------------------------------------------------
65) Rules for Aggregating with MED and NEXT_HOP
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Clear up the text on aggregating with a MED.  See the discussion
for the text.

Discussion:

There is a proposal to relax this statement:

"Routes that have the following attributes shall not be aggregated
unless the corresponding attributes of each route are identical:
MULTI_EXIT_DISC, NEXT_HOP."

In his reply to the original mail, Curtis asserted that we should leave
the MED rules alone, but perhaps we could relax the NEXT_HOP statement.

This was revisited in the "aggregating with MED and NEXT_HOP" thread.

Yakov suggested we replace:

Routes that have the following attributes shall not be aggregated
unless the corresponding attributes of each route are identical:
MULTI_EXIT_DISC, NEXT_HOP.

If the aggregation occurs as part of the update process, routes with
different NEXT_HOP values can be aggregated when announced through an
external BGP session.

Path attributes that have different type codes can not be aggregated
together. Path attributes of the same type code may be aggregated,
according to the following rules:

with:

Routes that have different MULTI_EXIT_DISC attribute SHALL NOT
be aggregated.

Path attributes that have different type codes can not be aggregated
together. Path attributes of the same type code may be aggregated,
according to the following rules:

NEXT_HOP: When aggregating routes that have different NEXT_HOP
attribute, the NEXT_HOP attribute of the aggregated route SHALL
identify an interface on the router that performs the aggregation.

This met with agreement.

Dimitry asked if the "Routes that have different MULTI_EXIT_DESC attribute
SHALL NOT be aggregated." sentance was unnecessary since it should be a
matter of local policy.  Jeff replied that it has been mentioned that
removing this stipulation can cause routing loops.

We are at consensus with this issue.



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA03346 for <[e-mail]>; Tue, 14 Jan 2003 22:52:18 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 22A5D91259; Tue, 14 Jan 2003 22:51:42 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E47AD912A2; Tue, 14 Jan 2003 22:51:41 -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 A5ABA91259 for <[e-mail]>; Tue, 14 Jan 2003 22:51:40 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8B57A5DF8E; Tue, 14 Jan 2003 22:51:40 -0500 (EST)
Delivered-To: [e-mail]
Received: from earthquake.proficient.net (fe0-0-access-1-sfo.proficient.net [65.209.247.5]) by segue.merit.edu (Postfix) with ESMTP id 316385DDB7 for <[e-mail]>; Tue, 14 Jan 2003 22:51:40 -0500 (EST)
Received: from riga ([10.0.0.25]) by earthquake.proficient.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.4905); Tue, 14 Jan 2003 19:51:34 -0800
Date: Tue, 14 Jan 2003 19:51:27 -0800 (PST)
From: Justin Fletcher <[e-mail]>
X-X-Sender: jfletcher@riga
To: "John G. Scudder" <[e-mail]>
Cc: Robert Raszuk <[e-mail]>, <[e-mail]>
Subject: Re: I-D ACTION:draft-fletcher-bgp-inactive-path-00.txt
In-Reply-To: <p05200f0fba4a46a56655@[192.168.42.10]>
Message-ID: <Pine.LNX.4.44.0301141852100.12193-100000@riga>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-OriginalArrivalTime: 15 Jan 2003 03:51:34.0233 (UTC) FILETIME=[658F7490:01C2BC49]
Sender: [e-mail]
Precedence: bulk

On Tue, 14 Jan 2003, John G. Scudder wrote:

John, thank you; I'll embed a few as well.

> Hi Justin,
> 
> Comments in line below.
> 
> >If in draft-walton-bgp-add-paths all nexthops are included with each route
> >adertisement this may result in an increase in the volume of data to
> >transferred and processed during normal operations.
> 
> It was certainly not our intent that all routes ("paths") for a given 
> NLRI be readvertised whenever one single path changes.  I take it 
> this is what you're referring to when you say "nexthops"?

Precisely, and thank you for the clarification.  Semantics can be a little 
tricky :-)

> >If a change in
> >availability of a single undertised nexthop is indicated by setting both
> >the FirstPath and LastPath bits, this isn't an issue.  The statement that
> >"any paths received before this one MUST be removed by the receiver" leads
> >to some questions of interpretation.
> 
> - Our draft (like yours) advertises multiple _routes_, not just nexthops.

Right; just semantics.

> - Any single route may be advertised or withdrawn without affecting the
>    other routes for the same NLRI.
> - The FirstPath flag provides implicit-withdraw semantics for the whole
>    batch of paths for that NLRI.  Sounds like that's what you're concerned
>    about?  Sending FirstPath is optional.

Yes. I belive that ability is required to remove an entire prefix, to 
add or remove a single route for the same NLRI or to change that route 
to/from unadvertised to advertised.

> >The addition of configuration options and a receive capability allows
> >additional flexibility in deployment.
> 
> I don't think there's a deep difference between the two proposals in 
> terms of configurability, which is fundamentally an implementation 
> issue.  Clearly an add-path implementation can (and perhaps should) 
> default to working in plain-old-BGP mode.  Leaving this up to the 
> implementor is more to my taste, though.

I chose to formalize the "perhaps should" but can go either way.

> It's not clear to me what the deployment case is for splitting the 
> capability's semantics into Tx/Rx.  If there is a need, however, we'd 
> be happy to add it to add-path.

I believe that this may simplify both processing and implementation;
it would also allow a router to operate in a limited or test mode
where the additional information is received and processed without being 
required to advertise all paths.

> >Finally, it's a minimalist approach; there are no changes to the protocol
> >format itself.
> 
> Here are a few concerns I have about your approach:
> 
> - I don't see a way to withdraw a path.  Lack of an easy way to withdraw
>    paths is a key reason why we decided not to pursue a similar attribute-
>    based approach when we were coming up with add-path.

Tian noticed this issue as well, and I just realized I didn't send my 
response to the WG as well.

Rather than extending the format for withdrawn routes, this can be handled 
by adding an INACTIVE_WITHDRAW attribute to indicate removal of an 
unadvertised nexthop (path) and including the prefix and nexthop in the 
Network Layer Reachability Information.

> - It doesn't appear to enable multiple active paths.  There may be some
>    use for this in the future, notably for doing multipath in a clean way.

True.  Perhaps this could also be addressed by an additional attribute.

> Regards,
> 
> --John
> 

Best,
Justin



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA12939 for <[e-mail]>; Tue, 14 Jan 2003 18:25:52 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B3D0091298; Tue, 14 Jan 2003 18:25:14 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 832B191299; Tue, 14 Jan 2003 18:25: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 48CA291298 for <[e-mail]>; Tue, 14 Jan 2003 18:25:13 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 22CB25E0E0; Tue, 14 Jan 2003 18:25:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by segue.merit.edu (Postfix) with ESMTP id C9E015DFD6 for <[e-mail]>; Tue, 14 Jan 2003 18:25:12 -0500 (EST)
Received: from cisco.com (router.cisco.com [171.69.182.20]) by sj-msg-core-4.cisco.com (8.12.2/8.12.6) with ESMTP id h0ENPB0E003228; Tue, 14 Jan 2003 15:25:11 -0800 (PST)
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 SAA09734; Tue, 14 Jan 2003 18:25:10 -0500 (EST)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05200f0fba4a46a56655@[192.168.42.10]>
In-Reply-To: <Pine.LNX.4.44.0301141405100.10476-100000@riga>
References: <Pine.LNX.4.44.0301141405100.10476-100000@riga>
Date: Tue, 14 Jan 2003 18:24:53 -0500
To: Justin Fletcher <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: I-D ACTION:draft-fletcher-bgp-inactive-path-00.txt
Cc: Robert Raszuk <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Hi Justin,

Comments in line below.

At 2:31 PM -0800 1/14/03, Justin Fletcher wrote:
>On Tue, 14 Jan 2003, Robert Raszuk wrote:
>
>>  Hi Justin,
>>
>>  Do you see anything not addressed already by: draft-walton-bgp-add-paths
>>  which would support proceeding with your draft any further ?
>>
>>  Thx,
>>  R.
>
>While we definitely have the same goals in mind, I think there are a few
>issues that merit further disucssion.
>
>If in draft-walton-bgp-add-paths all nexthops are included with each route
>adertisement this may result in an increase in the volume of data to
>transferred and processed during normal operations.

It was certainly not our intent that all routes ("paths") for a given 
NLRI be readvertised whenever one single path changes.  I take it 
this is what you're referring to when you say "nexthops"?

>If a change in
>availability of a single undertised nexthop is indicated by setting both
>the FirstPath and LastPath bits, this isn't an issue.  The statement that
>"any paths received before this one MUST be removed by the receiver" leads
>to some questions of interpretation.

We should clean those up then.  Perhaps you can elaborate on the 
required clarification either on this list or off-line.  Just to 
clarify for now:

- Our draft (like yours) advertises multiple _routes_, not just nexthops.
- Any single route may be advertised or withdrawn without affecting the
   other routes for the same NLRI.
- The FirstPath flag provides implicit-withdraw semantics for the whole
   batch of paths for that NLRI.  Sounds like that's what you're concerned
   about?  Sending FirstPath is optional.

Also, note that we plan to remove the LastPath flag in a forthcoming 
revision.  You'll see this mentioned in the minutes of the last IDR 
WG meeting.

>The addition of configuration options and a receive capability allows
>additional flexibility in deployment.

I don't think there's a deep difference between the two proposals in 
terms of configurability, which is fundamentally an implementation 
issue.  Clearly an add-path implementation can (and perhaps should) 
default to working in plain-old-BGP mode.  Leaving this up to the 
implementor is more to my taste, though.

It's not clear to me what the deployment case is for splitting the 
capability's semantics into Tx/Rx.  If there is a need, however, we'd 
be happy to add it to add-path.

>Finally, it's a minimalist approach; there are no changes to the protocol
>format itself.

Here are a few concerns I have about your approach:

- I don't see a way to withdraw a path.  Lack of an easy way to withdraw
   paths is a key reason why we decided not to pursue a similar attribute-
   based approach when we were coming up with add-path.
- It doesn't appear to enable multiple active paths.  There may be some
   use for this in the future, notably for doing multipath in a clean way.

Regards,

--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 RAA09013 for <[e-mail]>; Tue, 14 Jan 2003 17:34:42 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id AF89791258; Tue, 14 Jan 2003 17:34:25 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F40691294; Tue, 14 Jan 2003 17:34: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 CCB2891258 for <[e-mail]>; Tue, 14 Jan 2003 17:32:11 -0500 (EST)
Received: by segue.merit.edu (Postfix) id AA7FA5E0C7; Tue, 14 Jan 2003 17:32:11 -0500 (EST)
Delivered-To: [e-mail]
Received: from earthquake.proficient.net (fe0-0-access-1-sfo.proficient.net [65.209.247.5]) by segue.merit.edu (Postfix) with ESMTP id 5D2255E090 for <[e-mail]>; Tue, 14 Jan 2003 17:32:11 -0500 (EST)
Received: from riga ([10.0.0.25]) by earthquake.proficient.net over TLS secured channel with Microsoft SMTPSVC(5.0.2195.4905); Tue, 14 Jan 2003 14:32:06 -0800
Date: Tue, 14 Jan 2003 14:31:53 -0800 (PST)
From: Justin Fletcher <[e-mail]>
X-X-Sender: jfletcher@riga
To: Robert Raszuk <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-fletcher-bgp-inactive-path-00.txt
In-Reply-To: <[e-mail]>
Message-ID: <Pine.LNX.4.44.0301141405100.10476-100000@riga>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-OriginalArrivalTime: 14 Jan 2003 22:32:06.0958 (UTC) FILETIME=[C4F964E0:01C2BC1C]
Sender: [e-mail]
Precedence: bulk

On Tue, 14 Jan 2003, Robert Raszuk wrote:

> Hi Justin,
> 
> Do you see anything not addressed already by: draft-walton-bgp-add-paths
> which would support proceeding with your draft any further ?
> 
> Thx,
> R.

While we definitely have the same goals in mind, I think there are a few 
issues that merit further disucssion.

If in draft-walton-bgp-add-paths all nexthops are included with each route 
adertisement this may result in an increase in the volume of data to 
transferred and processed during normal operations.  If a change in 
availability of a single undertised nexthop is indicated by setting both
the FirstPath and LastPath bits, this isn't an issue.  The statement that 
"any paths received before this one MUST be removed by the receiver" leads
to some questions of interpretation.

The addition of configuration options and a receive capability allows 
additional flexibility in deployment.

Finally, it's a minimalist approach; there are no changes to the protocol 
format itself.
-- 
Justin Fletcher
Proficient Networks, Inc.



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA10437 for <[e-mail]>; Tue, 14 Jan 2003 11:20:11 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E135091254; Tue, 14 Jan 2003 11:19:52 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2A789127A; Tue, 14 Jan 2003 11:19: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 7A3FA91254 for <[e-mail]>; Tue, 14 Jan 2003 11:19:51 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 623BA5E034; Tue, 14 Jan 2003 11:19:51 -0500 (EST)
Delivered-To: [e-mail]
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id E758B5E06E for <[e-mail]>; Tue, 14 Jan 2003 11:19:50 -0500 (EST)
Received: from mira-sjc5-b.cisco.com (IDENT:[e-mail] [171.71.163.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0EGJEjS002612; Tue, 14 Jan 2003 08:19:14 -0800 (PST)
Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ADD97118; Tue, 14 Jan 2003 08:16:42 -0800 (PST)
Message-ID: <[e-mail]>
Date: Tue, 14 Jan 2003 17:19:46 +0100
From: Robert Raszuk <[e-mail]>
Reply-To: [e-mail]
Organization: Signature: http://www.employees.org/~raszuk/sig/
X-Mailer: Mozilla 4.79 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-fletcher-bgp-inactive-path-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hi Justin,

Do you see anything not addressed already by: draft-walton-bgp-add-paths
which would support proceeding with your draft any further ?

Thx,
R.

PS URL:
http://www.ietf.org/internet-drafts/draft-walton-bgp-add-paths-01.txt


> [e-mail] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
>         Title           : Inactive Path Advertisement in BGP-4
>         Author(s)       : J. Fletcher
>         Filename        : draft-fletcher-bgp-inactive-path-00.txt
>         Pages           : 4
>         Date            : 2003-1-13
> 
> This document defines BGP capabilities and a path attribute to permit
> advertisement of routes other than those selected during the BGP
> decision process.  These extensions would provide additional routing
> information for research, monitoring and policy decisions.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-fletcher-bgp-inactive-path-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-fletcher-bgp-inactive-path-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-fletcher-bgp-inactive-path-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.
> 
>   ------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[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 KAA05588 for <[e-mail]>; Tue, 14 Jan 2003 10:16:53 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id CF6C891252; Tue, 14 Jan 2003 10:16:31 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7AA1491279; Tue, 14 Jan 2003 10:16: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 A5EA291252 for <[e-mail]>; Tue, 14 Jan 2003 10:16:29 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 5A62F5E095; Tue, 14 Jan 2003 10:16:05 -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 3E0BB5E090 for <[e-mail]>; Tue, 14 Jan 2003 10:16:04 -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 KAA26335; Tue, 14 Jan 2003 10:12:42 -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-fletcher-bgp-inactive-path-00.txt
Date: Tue, 14 Jan 2003 10:12:42 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Inactive Path Advertisement in BGP-4
	Author(s)	: J. Fletcher
	Filename	: draft-fletcher-bgp-inactive-path-00.txt
	Pages		: 4
	Date		: 2003-1-13
	
This document defines BGP capabilities and a path attribute to permit
advertisement of routes other than those selected during the BGP
decision process.  These extensions would provide additional routing
information for research, monitoring and policy decisions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-fletcher-bgp-inactive-path-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-fletcher-bgp-inactive-path-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-fletcher-bgp-inactive-path-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-fletcher-bgp-inactive-path-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-fletcher-bgp-inactive-path-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 JAA00802 for <[e-mail]>; Tue, 14 Jan 2003 09:16:07 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 77BAF91278; Tue, 14 Jan 2003 09:15:12 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0163791279; Tue, 14 Jan 2003 09:15: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 C501291278 for <[e-mail]>; Tue, 14 Jan 2003 09:15:08 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A8E9E5E088; Tue, 14 Jan 2003 09:15:07 -0500 (EST)
Delivered-To: [e-mail]
Received: from kanmx1.ca.alcatel.com (unknown [209.202.115.138]) by segue.merit.edu (Postfix) with SMTP id BDD915DFD0 for <[e-mail]>; Tue, 14 Jan 2003 09:15:06 -0500 (EST)
Received: (qmail 28303 invoked from network); 14 Jan 2003 14:21:45 -0000
Received: (ofmipd 138.120.105.202); 14 Jan 2003 14:21:23 -0000
Date: 14 Jan 2003 09:15:05 -0500
Message-ID: <[e-mail]>
From: "Mireille Shammas" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Organization: Alcatel CID
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
Subject: Aggregation and MED on the issues list
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hi,
A while back when draft-18 was being reviewed an issue was raised
regarding section 9.2.2.2

"Routes that have different MULTI_EXIT_DISC attribute SHALL NOT be
aggregated."

This issue was not tracked down by issues list.

Many people have argued that this rule could be relaxed to SHOULD NOT
since many venders don't comply. I understand that this can be harmful
in some situations. However,  The correct behavior for aggregating
routes with the same MED was never clarified. For example, what is
correct behavior if we have 4 prefixes contributing to an aggregate
address and 2 of them have MED x and the other 2 have MED y. Should we
aggregate at all in this situations?

I think this issue needs to be added to the list to get its full
diligence.

Mireille





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA19208 for <[e-mail]>; Thu, 9 Jan 2003 10:53:50 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D7E98912A7; Thu,  9 Jan 2003 10:53:13 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D402912A8; Thu,  9 Jan 2003 10:53: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 7705F912A7 for <[e-mail]>; Thu,  9 Jan 2003 10:53:12 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 5DA225DF8B; Thu,  9 Jan 2003 10:53:12 -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 C727D5DDC2 for <[e-mail]>; Thu,  9 Jan 2003 10:53:11 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h09FrBS54437; Thu, 9 Jan 2003 07:53:11 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: 56th IETF IDR WG meeting
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 09 Jan 2003 07:53:11 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

We will be meeting in San Francisco. Please E-mail Sue
and I potential agenda items.

Sue & 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 MAA17954 for <[e-mail]>; Tue, 7 Jan 2003 12:07:29 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id D76CE91223; Tue,  7 Jan 2003 12:07:04 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2EAF9127F; Tue,  7 Jan 2003 12:07: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 8F3A191223 for <[e-mail]>; Tue,  7 Jan 2003 12:07:02 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3FADE5DF1E; Tue,  7 Jan 2003 12:07:02 -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 A83575DF1D for <[e-mail]>; Tue,  7 Jan 2003 12:07:01 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h07H70w59244; Tue, 7 Jan 2003 12:07:00 -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 h07H6vC59237; Tue, 7 Jan 2003 12:06:57 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h07H6uN19243; Tue, 7 Jan 2003 12:06:56 -0500 (EST)
Date: Tue, 7 Jan 2003 12:06:56 -0500
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: Issues list, #17: Section 3, Page 8, Paragraph 3 - Obsolete?
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 Tue, Jan 07, 2003 at 08:48:26AM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Tue, Jan 07, 2003 at 08:48:26AM -0800, Yakov Rekhter wrote:
> > At the beginning of the document, we define:
> >    BGP speaker
> > 	 A router that implements BGP.
> 
> Seems reasonable.

Which is what I perceive to be a problem.

Were we to substitute all places (where appropriate) within the text
where we say "router" and mean "BGP speaker", and simply define
BGP speaker as "An entity that implements the BGP protocol", we
allow routers and potentially other things.  

The above text requires a BGP speaker to be a router.

-- 
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 LAA17042 for <[e-mail]>; Tue, 7 Jan 2003 11:50:54 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 2C1379121C; Tue,  7 Jan 2003 11:48:30 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3E739127F; Tue,  7 Jan 2003 11:48:29 -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 743C39121C for <[e-mail]>; Tue,  7 Jan 2003 11:48:28 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 564C75DEF1; Tue,  7 Jan 2003 11:48:28 -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 BDF695DE7B for <[e-mail]>; Tue,  7 Jan 2003 11:48:27 -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 h07GmQS76508; Tue, 7 Jan 2003 08:48:26 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: Issues list, #17: Section 3, Page 8, Paragraph 3 - Obsolete? 
In-Reply-To: Your message of "Tue, 07 Jan 2003 11:31:49 EST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 07 Jan 2003 08:48:26 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> Yakov,
> 
> On Tue, Jan 07, 2003 at 08:00:27AM -0800, Yakov Rekhter wrote:
> > Since operations of non-routing host are outside the scope of the
> > document,
> 
> Ok.
> 
> > and since the document doesn't preclude non-routing hosts
> 
> I'll change my suggestion then.
> 
> At the beginning of the document, we define:
>    BGP speaker
> 	 A router that implements BGP.

Seems reasonable.

> This (potentially) restricts a speaker to being a router.
> Additionally, several spots in the text where we probably should
> say "BGP speaker", we use router.

In view of the above change, we could use the term "BGP speaker"
(as in the definition section we restrict BGP speaker to be
a router).

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 LAA16104 for <[e-mail]>; Tue, 7 Jan 2003 11:33:47 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 78DBA9120E; Tue,  7 Jan 2003 11:32:22 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2835E9121C; Tue,  7 Jan 2003 11:32:22 -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 0382D9120E for <[e-mail]>; Tue,  7 Jan 2003 11:32:19 -0500 (EST)
Received: by segue.merit.edu (Postfix) id EE0D85E0FE; Tue,  7 Jan 2003 11:31: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 3907A5E0EB for <[e-mail]>; Tue,  7 Jan 2003 11:31:55 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h07GVri58549; Tue, 7 Jan 2003 11:31:53 -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 h07GVoC58540; Tue, 7 Jan 2003 11:31:50 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h07GVnG19072; Tue, 7 Jan 2003 11:31:49 -0500 (EST)
Date: Tue, 7 Jan 2003 11:31:49 -0500
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: Issues list, #17: Section 3, Page 8, Paragraph 3 - Obsolete?
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 Tue, Jan 07, 2003 at 08:00:27AM -0800
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Tue, Jan 07, 2003 at 08:00:27AM -0800, Yakov Rekhter wrote:
> Since operations of non-routing host are outside the scope of the
> document,

Ok.

> and since the document doesn't preclude non-routing hosts

I'll change my suggestion then.

At the beginning of the document, we define:
   BGP speaker
	 A router that implements BGP.

This (potentially) restricts a speaker to being a router.
Additionally, several spots in the text where we probably should
say "BGP speaker", we use router.

What do you think?

-- 
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 LAA14344 for <[e-mail]>; Tue, 7 Jan 2003 11:02:37 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B986191208; Tue,  7 Jan 2003 11:00:39 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 813DE9120E; Tue,  7 Jan 2003 11:00: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 4865D91208 for <[e-mail]>; Tue,  7 Jan 2003 11:00:38 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 499A25DEF2; Tue,  7 Jan 2003 11:00:30 -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 726055DE08 for <[e-mail]>; Tue,  7 Jan 2003 11:00:29 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h07G0RS72738; Tue, 7 Jan 2003 08:00:27 -0800 (PST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: Issues list, #17: Section 3, Page 8, Paragraph 3 - Obsolete? 
In-Reply-To: Your message of "Mon, 06 Jan 2003 11:45:19 EST." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 07 Jan 2003 08:00:27 -0800
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> > 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.
> 
> To provide context, this paragraph currently reads:
> 
> :   The hosts executing BGP need not be routers.  A non-routing host
> :   could exchange routing information with routers via EGP [RFC904] or
> :   even an interior routing protocol. That non-routing host could then
> :   use BGP to exchange routing information with a border router in
> :   another Autonomous System. The implications and applications of this
> :   architecture are for further study.
> 
> There are several deployed entities that could be considered to "exploit"
> this paragraph.  Route collectors, route servers, bandwidth shapers
> and other optimizers.  However, the original text may be showing its
> age a little bit.
> 
> Perhaps the following might be a bit more appropriate:
> 
> "The hosts executing BGP need not be routers.  A non-routing host may
>  exchange routing information with a BGP speaker for reasons
>  that are outside the scope of this document."
> 
> I would also propose adding to the same paragraph (but could be persuaded
> to drop it since it is *logically* redundant):
> "These non-routing hosts should exercise great care not to insert 
>  themselves into the forwarding path if they re-announce BGP routes."

Since operations of non-routing host are outside the scope of the
document, and since the document doesn't preclude non-routing hosts
to run BGP, I would prefer just to take the following paragraph out,
and not to add any new text.

   The hosts executing BGP need not be routers.  A non-routing host
   could exchange routing information with routers via EGP [RFC904] or
   even an interior routing protocol. That non-routing host could then
   use BGP to exchange routing information with a border router in
   another Autonomous System. The implications and applications of this
   architecture are for further study.

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 OAA24856 for <[e-mail]>; Mon, 6 Jan 2003 14:28:50 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 4372691270; Mon,  6 Jan 2003 14:28:25 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06EBE91272; Mon,  6 Jan 2003 14:28: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 C90E091270 for <[e-mail]>; Mon,  6 Jan 2003 14:28:22 -0500 (EST)
Received: by segue.merit.edu (Postfix) id A707C5DF76; Mon,  6 Jan 2003 14:28: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 8769C5DEA3 for <[e-mail]>; Mon,  6 Jan 2003 14:28:21 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h06JSKm38663 for [e-mail]; Mon, 6 Jan 2003 14:28:20 -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 h06JSFC38651 for <[e-mail]>; Mon, 6 Jan 2003 14:28:15 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h06JSFK14778 for [e-mail]; Mon, 6 Jan 2003 14:28:15 -0500 (EST)
Date: Mon, 6 Jan 2003 14:28:15 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Issues list, #2: MUST/SHOULD Capitalization
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

> 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.

Attached, please find a universal diff containing my recommended changes.
Note that not all instances of our magic words are capitalized, it
is not always appropriate.  As such, I may have failed to capitalize
where it is needed and may have also done so where it is inappropriate.
These changes should go through at least one other thorough reviewer.

Note that as part of these diffs, I found two cases that looked like
a wording change was worth suggesting.  

To explicitly point it out:
    If the NEXT_HOP attribute of a BGP route depicts an address that is
    not resolvable, or it would become unresolvable if the route was
-   installed in the routing table the BGP route should be excluded from
+   installed in the routing table the BGP route MUST be excluded from
    the Phase 2 decision function.

...and...

    the NEXT_HOP attribute of the selected route (see section 5.1.3). If
    either the immediate next hop or the IGP cost to the NEXT_HOP (where
    the NEXT_HOP is resolved through an IGP route) changes, Phase 2:
-   Route Selection should be performed again.
+   Route Selection MUST be performed again.

Other than these, everything else is a capitalization 

--- html/ID.local/draft-ietf-idr-bgp4-18.txt	Mon Nov  4 15:59:08 2002
+++ draft-ietf-idr-bgp4-18.txt	Mon Jan  6 12:46:39 2003
@@ -454,7 +454,7 @@
    BGP uses TCP [RFC793] as its transport protocol. This eliminates the
    need to implement explicit update fragmentation, retransmission,
    acknowledgment, and sequencing. BGP listens on TCP port 179. Any
-   authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may be
+   authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) MAY be
    used. The error notification mechanism used in BGP assumes that TCP
    supports a "graceful" close, i.e., that all outstanding data will be
    delivered before the connection is closed.
@@ -542,7 +542,7 @@
 RFC DRAFT                                                   October 2002
 
 
-   If a BGP speaker chooses to advertise the route, it may add to or
+   If a BGP speaker chooses to advertise the route, it MAY add to or
    modify the path attributes of the route before advertising it to a
    peer.
 
@@ -581,7 +581,7 @@
       that the BGP speaker has selected by applying its local policies
       to the routing information contained in its Adj-RIBs-In. These are
       the routes that will be used by the local BGP speaker. The next
-      hop for each of these routes must be resolvable via the local BGP
+      hop for each of these routes MUST be resolvable via the local BGP
       speaker's Routing Table.
 
       c) Adj-RIBs-Out: The Adj-RIBs-Out store the information that the
@@ -687,7 +687,7 @@
          This 2-octet unsigned integer indicates the total length of the
          message, including the header, in octets. Thus, e.g., it allows
          one to locate in the TCP stream the (Marker field of the) next
-         message. The value of the Length field must always be at least
+         message. The value of the Length field MUST always be at least
          19 and no greater than 4096, and may be further constrained,
          depending on the message type. No "padding" of extra data after
          the message is allowed, so the Length field must have the
@@ -765,7 +765,7 @@
          value of the Hold Timer by using the smaller of its configured
          Hold Time and the Hold Time received in the OPEN message. The
          Hold Time MUST be either zero or at least three seconds.  An
-         implementation may reject connections on the basis of the Hold
+         implementation MAY reject connections on the basis of the Hold
          Time.  The calculated value indicates the maximum number of
          seconds that may elapse between the receipt of successive
          KEEPALIVE, and/or UPDATE messages by the sender.
@@ -798,7 +798,7 @@
 
       Optional Parameters:
 
-         This field may contain a list of optional parameters, where
+         This field MAY contain a list of optional parameters, where
          each parameter is encoded as a <Parameter Type, Parameter
          Length, Parameter Value> triplet.
 
@@ -866,7 +866,7 @@
       Withdrawn Routes Length:
 
          This 2-octets unsigned integer indicates the total length of
-         the Withdrawn Routes field in octets.  Its value must allow the
+         the Withdrawn Routes field in octets.  Its value MUST allow the
          length of the Network Layer Reachability Information field to
          be determined as specified below.
 
@@ -919,7 +919,7 @@
       Total Path Attribute Length:
 
          This 2-octet unsigned integer indicates the total length of the
-         Path Attributes field in octets. Its value must allow the
+         Path Attributes field in octets. Its value MUST allow the
          length of the Network Layer Reachability field to be determined
          as specified below.
 
@@ -963,14 +963,14 @@
 
 
          is transitive (if set to 1) or non-transitive (if set to 0).
-         For well-known attributes, the Transitive bit must be set to 1.
+         For well-known attributes, the Transitive bit MUST be set to 1.
          (See Section 5 for a discussion of transitive attributes.)
 
          The third high-order bit (bit 2) of the Attribute Flags octet
          is the Partial bit. It defines whether the information con-
          tained in the optional transitive attribute is partial (if set
          to 1) or complete (if set to 0). For well-known attributes and
-         for optional non-transitive attributes the Partial bit must be
+         for optional non-transitive attributes the Partial bit MUST be
          set to 0.
 
          The fourth high-order bit (bit 3) of the Attribute Flags octet
@@ -978,7 +978,7 @@
          Length is one octet (if set to 0) or two octets (if set to 1).
 
          The lower-order four bits of the Attribute Flags octet are
-         unused. They must be zero when sent and must be ignored when
+         unused. They MUST be zero when sent and MUST be ignored when
          received.
 
          The Attribute Type Code octet contains the Attribute Type Code.
@@ -1069,7 +1069,7 @@
          d) MULTI_EXIT_DISC (Type Code 4):
 
             This is an optional non-transitive attribute that is a four
-            octet non-negative integer. The value of this attribute may
+            octet non-negative integer. The value of this attribute MAY
 
 
 
@@ -1110,7 +1110,7 @@
             The attribute contains the last AS number that formed the
             aggregate route (encoded as 2 octets), followed by the IP
             address of the BGP speaker that formed the aggregate route
-            (encoded as 4 octets).  This should be the same address as
+            (encoded as 4 octets).  This SHOULD be the same address as
             the one used for the BGP Identifier of the speaker.
 
             Usage of this attribute is defined in 5.1.7.
@@ -1205,10 +1205,10 @@
    feasible route, in which case the WITHDRAWN ROUTES field need not be
    present.
 
-   An UPDATE message should not include the same address prefix in the
+   An UPDATE message SHOULD NOT include the same address prefix in the
    WITHDRAWN ROUTES and Network Layer Reachability Information fields,
    however a BGP speaker MUST be able to process UPDATE messages in this
-   form. A BGP speaker should treat an UPDATE message of this form as if
+   form. A BGP speaker SHOULD treat an UPDATE message of this form as if
    the WITHDRAWN ROUTES doesn't contain the address prefix.
 
 
@@ -1356,12 +1356,12 @@
                3. Optional transitive.
                4. Optional non-transitive.
 
-   Well-known attributes must be recognized by all BGP implementations.
-   Some of these attributes are mandatory and must be included in every
+   Well-known attributes MUST be recognized by all BGP implementations.
+   Some of these attributes are mandatory and MUST be included in every
    UPDATE message that contains NLRI. Others are discretionary and may
    or may not be sent in a particular UPDATE message.
 
-   All well-known attributes must be passed along (after proper updat-
+   All well-known attributes MUST be passed along (after proper updat-
    ing, if necessary) to other BGP peers.
 
    In addition to well-known attributes, each path may contain one or
@@ -1369,7 +1369,7 @@
    implementations support all optional attributes. The handling of an
    unrecognized optional attribute is determined by the setting of the
    Transitive bit in the attribute flags octet. Paths with unrecognized
-   transitive optional attributes should be accepted. If a path with
+   transitive optional attributes SHOULD be accepted. If a path with
 
 
 
@@ -1384,16 +1384,16 @@
 
    unrecognized transitive optional attribute is accepted and passed
    along to other BGP peers, then the unrecognized transitive optional
-   attribute of that path must be passed along with the path to other
+   attribute of that path MUST be passed along with the path to other
    BGP peers with the Partial bit in the Attribute Flags octet set to 1.
    If a path with recognized transitive optional attribute is accepted
    and passed along to other BGP peers and the Partial bit in the
    Attribute Flags octet is set to 1 by some previous AS, it is not set
    back to 0 by the current AS. Unrecognized non-transitive optional
-   attributes must be quietly ignored and not passed along to other BGP
+   attributes MUST be quietly ignored and not passed along to other BGP
    peers.
 
-   New transitive optional attributes may be attached to the path by the
+   New transitive optional attributes MAY be attached to the path by the
    originator or by any other BGP speaker in the path. If they are not
    attached by the originator, the Partial bit in the Attribute Flags
    octet is set to 1. The rules for attaching new non-transitive
@@ -1401,12 +1401,12 @@
    attribute. The documentation of each new non-transitive optional
    attribute will be expected to include such rules. (The description of
    the MULTI_EXIT_DISC attribute gives an example.) All optional
-   attributes (both transitive and non-transitive) may be updated (if
+   attributes (both transitive and non-transitive) MAY be updated (if
    appropriate) by BGP speakers in the path.
 
-   The sender of an UPDATE message should order path attributes within
+   The sender of an UPDATE message SHOULD order path attributes within
    the UPDATE message in ascending order of attribute type. The receiver
-   of an UPDATE message must be prepared to handle path attributes
+   of an UPDATE message MUST be prepared to handle path attributes
    within the UPDATE message that are out of order.
 
    The same attribute can not appear more than once within the Path
@@ -1454,7 +1454,7 @@
 
 
    ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
-   shall be generated by the speaker that originates the associated
+   SHALL be generated by the speaker that originates the associated
    routing information. Its value SHOULD NOT be changed by any other
    speaker.
 
@@ -1468,20 +1468,20 @@
    AS_SETs or AS_SEQUENCEs.
 
    When a BGP speaker propagates a route which it has learned from
-   another BGP speaker's UPDATE message, it shall modify the route's
+   another BGP speaker's UPDATE message, it SHALL modify the route's
    AS_PATH attribute based on the location of the BGP speaker to which
    the route will be sent:
 
       a) When a given BGP speaker advertises the route to an internal
-      peer, the advertising speaker shall not modify the AS_PATH
+      peer, the advertising speaker SHALL NOT modify the AS_PATH
       attribute associated with the route.
 
       b) When a given BGP speaker advertises the route to an external
-      peer, then the advertising speaker shall update the AS_PATH
+      peer, then the advertising speaker SHALL update the AS_PATH
       attribute as follows:
 
          1) if the first path segment of the AS_PATH is of type
-         AS_SEQUENCE, the local system shall prepend its own AS number
+         AS_SEQUENCE, the local system SHALL prepend its own AS number
          as the last element of the sequence (put it in the leftmost
          position). If the act of prepending will cause an overflow in
          the AS_PATH segment, i.e. more than 255 ASs, it shall be legal
@@ -1489,7 +1489,7 @@
          own AS number to this new segment.
 
          2) if the first path segment of the AS_PATH is of type AS_SET,
-         the local system shall prepend a new path segment of type
+         the local system SHALL prepend a new path segment of type
 
 
 
@@ -1507,21 +1507,21 @@
 
    When a BGP speaker originates a route then:
 
-      a) the originating speaker shall include its own AS number in a
+      a) the originating speaker SHALL include its own AS number in a
       path segment of type AS_SEQUENCE in the AS_PATH attribute of all
       UPDATE messages sent to an external peer. (In this case, the AS
       number of the originating speaker's autonomous system will be the
       only entry the path segment, and this path segment will be the
       only segment in the AS_PATH attribute).
 
-      b) the originating speaker shall include an empty AS_PATH
+      b) the originating speaker SHALL include an empty AS_PATH
       attribute in all UPDATE messages sent to internal peers.  (An
       empty AS_PATH attribute is one whose length field contains the
       value zero).
 
    Whenever the modification of the AS_PATH attribute calls for includ-
    ing or prepending the AS number of the local system, the local system
-   may include/prepend more than one instance of its own AS number in
+   MAY include/prepend more than one instance of its own AS number in
    the AS_PATH attribute. This is controlled via local configuration.
 
 
@@ -1534,16 +1534,16 @@
    is calculated as follows.
 
       1) When sending a message to an internal peer, if the route is not
-      locally originated the BGP speaker should not modify the NEXT_HOP
+      locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP
       attribute, unless it has been explicitly configured to announce
       its own IP address as the NEXT_HOP. When announcing a locally
-      originated route to an internal peer, the BGP speaker should use
+      originated route to an internal peer, the BGP speaker SHOULD use
       as the NEXT_HOP the interface address of the router through which
       the announced network is reachable for the speaker; if the route
       is directly connected to the speaker, or the interface address of
       the router through which the announced network is reachable for
       the speaker is the internal peer's address, then the BGP speaker
-      should use for the NEXT_HOP attribute its own IP address (the
+      SHOULD use for the NEXT_HOP attribute its own IP address (the
       address of the interface that is used to reach the peer).
 
       2) When sending a message to an external peer X, and the peer is
@@ -1579,12 +1579,12 @@
 
          - Otherwise, if the external peer to which the route is being
          advertised shares a common subnet with one of the announcing
-         router's own interfaces, the router may use the IP address
+         router's own interfaces, the router MAY use the IP address
          associated with such an interface in the NEXT_HOP attribute.
          This is known as a "first party" NEXT_HOP attribute.
 
          - By default (if none of the above conditions apply), the BGP
-         speaker should use in the NEXT_HOP attribute the IP address of
+         speaker SHOULD use in the NEXT_HOP attribute the IP address of
          the interface that the speaker uses to establish the BGP con-
          nection to peer X.
 
@@ -1598,18 +1598,18 @@
          attribute of the learned route (the speaker just doesn't modify
          the NEXT_HOP attribute).
 
-         - By default, the BGP speaker should use in the NEXT_HOP
+         - By default, the BGP speaker SHOULD use in the NEXT_HOP
          attribute the IP address of the interface that the speaker uses
          to establish the BGP connection to peer X.
 
    Normally the NEXT_HOP attribute is chosen such that the shortest
-   available path will be taken. A BGP speaker must be able to support
+   available path will be taken. A BGP speaker MUST be able to support
    disabling advertisement of third party NEXT_HOP attributes to handle
    imperfectly bridged media.
 
-   A BGP speaker must never advertise an address of a peer to that peer
+   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. A BGP
-   speaker must never install a route with itself as the next hop.
+   speaker MUST NEVER install a route with itself as the next hop.
 
 
 
@@ -1633,9 +1633,9 @@
    entry which resolves the IP address in the NEXT_HOP attribute will
    always specify the outbound interface. If the entry specifies an
    attached subnet, but does not specify a next-hop address, then the
-   address in the NEXT_HOP attribute should be used as the immediate
+   address in the NEXT_HOP attribute SHOULD be used as the immediate
    next-hop address.  If the entry also specifies the next-hop address,
-   this address should be used as the immediate next-hop address for
+   this address SHOULD be used as the immediate next-hop address for
    packet forwarding.
 
 
@@ -1687,7 +1687,7 @@
    each external route based on the locally configured policy, and
    include the degree of preference when advertising a route to its
    internal peers. The higher degree of preference MUST be preferred.  A
-   BGP speaker shall use the degree of preference learned via LOCAL_PREF
+   BGP speaker SHALL use the degree of preference learned via LOCAL_PREF
    in its decision process (see section 9.1.1).
 
    A BGP speaker MUST NOT include this attribute in UPDATE messages that
@@ -1745,11 +1745,11 @@
 5.1.7 AGGREGATOR
 
 
-   AGGREGATOR is an optional transitive attribute which may be included
+   AGGREGATOR is an optional transitive attribute which MAY be included
    in updates which are formed by aggregation (see Section 9.2.2.2). A
-   BGP speaker which performs route aggregation may add the AGGREGATOR
+   BGP speaker which performs route aggregation MAY add the AGGREGATOR
    attribute which shall contain its own AS number and IP address. The
-   IP address should be the same as the BGP Identifier of the speaker.
+   IP address SHOULD be the same as the BGP Identifier of the speaker.
 
 
 6. BGP Error Handling.
@@ -1763,7 +1763,7 @@
    fields is sent, and the BGP connection is closed, unless it is
    explicitly stated that no NOTIFICATION message is to be sent and the
    BGP connection is not to be closed. If no Error Subcode is specified,
-   then a zero must be used.
+   then a zero MUST be used.
 
    The phrase "the BGP connection is closed" means that the TCP connec-
    tion has been closed, the associated Adj-RIB-In has been cleared, and
@@ -1928,17 +1928,17 @@
    The IP address in the NEXT_HOP must meet the following criteria to be
    considered semantically correct:
 
-      a) It must not be the IP address of the receiving speaker
+      a) It MUST NOT be the IP address of the receiving speaker
 
       b) In the case of an EBGP where the sender and receiver are one IP
       hop away from each other, either the IP address in the NEXT_HOP
-      must be the sender's IP address (that is used to establish the BGP
+      MUST be the sender's IP address (that is used to establish the BGP
       connection), or the interface associated with the NEXT_HOP IP
-      address must share a common subnet with the receiving BGP speaker.
+      address MUST share a common subnet with the receiving BGP speaker.
 
-   If the NEXT_HOP attribute is semantically incorrect, the error should
-   be logged, and the route should be ignored. In this case, no NOTIFI-
-   CATION message should be sent, and connection should not be closed.
+   If the NEXT_HOP attribute is semantically incorrect, the error SHOULD
+   be logged, and the route SHOULD be ignored. In this case, no NOTIFI-
+   CATION message should be sent, and connection SHOULD NOT be closed.
 
    The AS_PATH attribute is checked for syntactic correctness. If the
    path is syntactically incorrect, then the Error Subcode is set to
@@ -1963,11 +1963,11 @@
    is set to Invalid Network Field.
 
    If a prefix in the NLRI field is semantically incorrect (e.g., an
-   unexpected multicast IP address), an error should be logged locally,
-   and the prefix should be ignored.
+   unexpected multicast IP address), an error SHOULD be logged locally,
+   and the prefix SHOULD be ignored.
 
    An UPDATE message that contains correct path attributes, but no NLRI,
-   shall be treated as a valid UPDATE message.
+   SHALL be treated as a valid UPDATE message.
 
 
 
@@ -2000,7 +2000,7 @@
    If a system does not receive successive KEEPALIVE and/or UPDATE
    and/or NOTIFICATION messages within the period specified in the Hold
    Time field of the OPEN message, then the NOTIFICATION message with
-   Hold Timer Expired Error Code must be sent and the BGP connection
+   Hold Timer Expired Error Code MUST be sent and the BGP connection
    closed.
 
 
@@ -2016,15 +2016,15 @@
 
 
    In absence of any fatal errors (that are indicated in this section),
-   a BGP peer may choose at any given time to close its BGP connection
+   a BGP peer MAY choose at any given time to close its BGP connection
    by sending the NOTIFICATION message with Error Code Cease. However,
-   the Cease NOTIFICATION message must not be used when a fatal error
+   the Cease NOTIFICATION message MUST NOT be used when a fatal error
    indicated by this section does exist.
 
-   A BGP speaker may support the ability to impose an (locally config-
+   A BGP speaker MAY support the ability to impose an (locally config-
    ured) upper bound on the number of address prefixes the speaker is
    willing to accept from a neighbor. When the upper bound is reached,
-   the speaker (under control of local configuration) may either (a)
+   the speaker (under control of local configuration) MAY either (a)
    discard new address prefixes from the neighbor (while maintaining BGP
    connection with the neighbor), or (b) terminate the BGP connection
    with the neighbor. If the BGP speaker decides to terminate its BGP
@@ -2042,7 +2042,7 @@
 RFC DRAFT                                                   October 2002
 
 
-   bound, then the speaker must send to the neighbor a NOTIFICATION mes-
+   bound, then the speaker MUST send to the neighbor a NOTIFICATION mes-
    sage with the Error Code Cease.
 
 
@@ -2065,8 +2065,8 @@
    the peers involved in the collision and to retain only the connection
    initiated by the BGP speaker with the higher-valued BGP Identifier.
 
-   Upon receipt of an OPEN message, the local system must examine all of
-   its connections that are in the OpenConfirm state. A BGP speaker may
+   Upon receipt of an OPEN message, the local system MUST examine all of
+   its connections that are in the OpenConfirm state. A BGP speaker MAY
    also examine connections in an OpenSent state if it knows the BGP
    Identifier of the peer by means outside of the protocol. If among
    these connections there is a connection to a remote BGP speaker whose
@@ -2127,7 +2127,7 @@
    it supports. If the two peers do support one or more common versions,
    then this will allow them to rapidly determine the highest common
    version. In order to support BGP version negotiation, future versions
-   of BGP must retain the format of the OPEN and NOTIFICATION messages.
+   of BGP MUST retain the format of the OPEN and NOTIFICATION messages.
 
 
 8. BGP Finite State machine
@@ -2171,7 +2171,7 @@
 
    Please note that only Event 1 (manual start) and Event 2 (manual
    stop) are mandatory administrative events. All other administrative
-   events are optional.
+   events are OPTIONAL.
 
        Event1: Manual start
 
@@ -2592,7 +2592,7 @@
 
    There is one FSM per BGP connection.  Prior to determining what peer
    a connection is associated with there may be two connections for a
-   given peer.  There should be no more than one connection per peer.
+   given peer.  There SHOULD be no more than one connection per peer.
    The collision detection identifies the case where there is more than
    one connection per peer and provides guidance for which connection to
    get rid of.  When this occurs, the corresponding FSM for the connec-
@@ -3363,7 +3363,7 @@
 
 
        In response to a TCP connection succeeds [Event 15
-       or Event 16], the 2nd connection shall be tracked until
+       or Event 16], the 2nd connection SHALL be tracked until
        it sends an OPEN message.
 
        If a valid Open message [Event 18] is received, it will be
@@ -3433,28 +3433,28 @@
    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
+   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
+   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.
 
    If the UPDATE message contains a non-empty WITHDRAWN ROUTES field,
    the previously advertised routes whose destinations (expressed as IP
-   prefixes) contained in this field shall be removed from the Adj-RIB-
-   In.  This BGP speaker shall run its Decision Process since the previ-
+   prefixes) contained in this field SHALL be removed from the Adj-RIB-
+   In.  This BGP speaker SHALL run its Decision Process since the previ-
    ously advertised route is no longer available for use.
 
    If the UPDATE message contains a feasible route, the Adj-RIB-In will
    be updated with this route as follows: if the NLRI of the new route
    is identical to the one of the route currently stored in the Adj-RIB-
-   In, then the new route shall replace the older route in the Adj-RIB-
+   In, then the new route SHALL replace the older route in the Adj-RIB-
    In, thus implicitly withdrawing the older route from service. Other-
    wise, if the Adj-RIB-In has no route with NLRI identical to the new
-   route, the new route shall be placed in the Adj-RIB-In.
+   route, the new route SHALL be placed in the Adj-RIB-In.
 
-   Once the BGP speaker updates the Adj-RIB-In, the speaker shall run
+   Once the BGP speaker updates the Adj-RIB-In, the speaker SHALL run
    its Decision Process.
 
 
@@ -3487,7 +3487,7 @@
    selection.
 
    The function that calculates the degree of preference for a given
-   route shall not use as its inputs any of the following: the existence
+   route SHALL NOT use as its inputs any of the following: the existence
    of other routes, the non-existence of other routes, or the path
    attributes of other routes. Route selection then consists of individ-
    ual application of the degree of preference function to each feasible
@@ -3524,7 +3524,7 @@
 9.1.1 Phase 1: Calculation of Degree of Preference
 
 
-   The Phase 1 decision function shall be invoked whenever the local BGP
+   The Phase 1 decision function SHALL be invoked whenever the local BGP
    speaker receives from a peer an UPDATE message that advertises a new
    route, a replacement route, or withdrawn routes.
 
@@ -3542,16 +3542,16 @@
 RFC DRAFT                                                   October 2002
 
 
-   The Phase 1 decision function shall lock an Adj-RIB-In prior to oper-
-   ating on any route contained within it, and shall unlock it after
+   The Phase 1 decision function SHALL lock an Adj-RIB-In prior to oper-
+   ating on any route contained within it, and SHALL unlock it after
    operating on all new or unfeasible routes contained within it.
 
    For each newly received or replacement feasible route, the local BGP
-   speaker shall determine a degree of preference as follows:
+   speaker SHALL determine a degree of preference as follows:
 
       If the route is learned from an internal peer, either the value of
-      the LOCAL_PREF attribute shall be taken as the degree of prefer-
-      ence, or the local system may compute the degree of preference of
+      the LOCAL_PREF attribute SHALL be taken as the degree of prefer-
+      ence, or the local system MAY compute the degree of preference of
       the route based on preconfigured policy information. Note that the
       latter (computing the degree of preference based on preconfigured
       policy information) may result in formation of persistent routing
@@ -3560,7 +3560,7 @@
       If the route is learned from an external peer, then the local BGP
       speaker computes the degree of preference based on preconfigured
       policy information. If the return value indicates that the route
-      is ineligible, the route may not serve as an input to the next
+      is ineligible, the route MAY NOT serve as an input to the next
       phase of route selection; otherwise the return value is used as
       the LOCAL_PREF value in any IBGP readvertisement.
 
@@ -3571,19 +3571,19 @@
 9.1.2 Phase 2: Route Selection
 
 
-   The Phase 2 decision function shall be invoked on completion of Phase
+   The Phase 2 decision function SHALL be invoked on completion of Phase
    1. The Phase 2 function is a separate process which completes when it
-   has no further work to do. The Phase 2 process shall consider all
+   has no further work to do. The Phase 2 process SHALL consider all
    routes that are eligible in the Adj-RIBs-In.
 
-   The Phase 2 decision function shall be blocked from running while the
-   Phase 3 decision function is in process. The Phase 2 function shall
-   lock all Adj-RIBs-In prior to commencing its function, and shall
+   The Phase 2 decision function SHALL be blocked from running while the
+   Phase 3 decision function is in process. The Phase 2 function SHALL
+   lock all Adj-RIBs-In prior to commencing its function, and SHALL
    unlock them on completion.
 
    If the NEXT_HOP attribute of a BGP route depicts an address that is
    not resolvable, or it would become unresolvable if the route was
-   installed in the routing table the BGP route should be excluded from
+   installed in the routing table the BGP route MUST be excluded from
    the Phase 2 decision function.
 
    It is critical that routers within an AS do not make conflicting
@@ -3603,7 +3603,7 @@
 
 
    For each set of destinations for which a feasible route exists in the
-   Adj-RIBs-In, the local BGP speaker shall identify the route that has:
+   Adj-RIBs-In, the local BGP speaker SHALL identify the route that has:
 
       a) the highest degree of preference of any route to the same set
       of destinations, or
@@ -3626,7 +3626,7 @@
    the NEXT_HOP attribute of the selected route (see section 5.1.3). If
    either the immediate next hop or the IGP cost to the NEXT_HOP (where
    the NEXT_HOP is resolved through an IGP route) changes, Phase 2:
-   Route Selection should be performed again.
+   Route Selection MUST be performed again.
 
    Notice that even though BGP routes do not have to be installed in the
    Routing Table with the immediate next hop(s), implementations must
@@ -3643,7 +3643,7 @@
 9.1.2.1 Route Resolvability Condition
 
 
-   As indicated in Section 9.1.2, BGP routers should exclude unresolv-
+   As indicated in Section 9.1.2, BGP routers MUST exclude unresolv-
    able routes from the Phase 2 decision. This ensures that only valid
    routes are installed in Loc-RIB and the Routing Table.
 
@@ -3696,14 +3696,14 @@
    the network.
 
    Whenever a BGP speaker identifies a route that fails the resolvabil-
-   ity check because of mutual recursion, an error message should be
+   ity check because of mutual recursion, an error message SHOULD be
    logged.
 
 
 9.1.2.2 Breaking Ties (Phase 2)
 
 
-   In its Adj-RIBs-In a BGP speaker may have several routes to the same
+   In its Adj-RIBs-In a BGP speaker MAY have several routes to the same
    destination that have the same degree of preference. The local
    speaker can select only one of these routes for inclusion in the
    associated Loc-RIB. The local speaker considers all routes with the
@@ -3731,7 +3731,7 @@
    The tie-breaking algorithm begins by considering all equally prefer-
    able routes to the same destination, and then selects routes to be
    removed from consideration. The algorithm terminates as soon as only
-   one route remains in consideration.  The criteria must be applied in
+   one route remains in consideration.  The criteria MUST be applied in
    the order specified.
 
    Several of the criteria are described using pseudo-code. Note that
@@ -3828,7 +3828,7 @@
 9.1.3 Phase 3: Route Dissemination
 
 
-   The Phase 3 decision function shall be invoked on completion of Phase
+   The Phase 3 decision function SHALL be invoked on completion of Phase
    2, or when any of the following events occur:
 
 
@@ -3852,35 +3852,35 @@
 
    The Phase 3 function is a separate process which completes when it
    has no further work to do. The Phase 3 Routing Decision function
-   shall be blocked from running while the Phase 2 decision function is
+   SHALL be blocked from running while the Phase 2 decision function is
    in process.
 
-   All routes in the Loc-RIB shall be processed into Adj-RIBs-Out
-   according to configured policy. This policy may exclude a route in
+   All routes in the Loc-RIB SHALL be processed into Adj-RIBs-Out
+   according to configured policy. This policy MAY exclude a route in
    the Loc-RIB from being installed in a particular Adj-RIB-Out.  A
-   route shall not be installed in the Adj-Rib-Out unless the destina-
+   route SHALL NOT be installed in the Adj-Rib-Out unless the destina-
    tion and NEXT_HOP described by this route may be forwarded appropri-
    ately by the Routing Table. If a route in Loc-RIB is excluded from a
    particular Adj-RIB-Out the previously advertised route in that Adj-
-   RIB-Out must be withdrawn from service by means of an UPDATE message
+   RIB-Out MUST be withdrawn from service by means of an UPDATE message
    (see 9.2).
 
    Route aggregation and information reduction techniques (see 9.2.2.1)
-   may optionally be applied.
+   MAY optionally be applied.
 
    Any local policy which results in routes being added to an Adj-RIB-
    Out without also being added to the local BGP speaker's forwarding
    table, is outside the scope of this document.
 
    When the updating of the Adj-RIBs-Out and the Routing Table is com-
-   plete, the local BGP speaker shall run the Update-Send process of
+   plete, the local BGP speaker SHALL run the Update-Send process of
    9.2.
 
 
 9.1.4 Overlapping Routes
 
 
-   A BGP speaker may transmit routes with overlapping Network Layer
+   A BGP speaker MAY transmit routes with overlapping Network Layer
    Reachability Information (NLRI) to another BGP speaker. NLRI overlap
    occurs when a set of destinations are identified in non-matching mul-
    tiple routes. Since BGP encodes NLRI using IP prefixes, overlap will
@@ -3913,7 +3913,7 @@
 
 
    When overlapping routes are present in the same Adj-RIB-In, the more
-   specific route shall take precedence, in order from more specific to
+   specific route SHALL take precedence, in order from more specific to
    least specific.
 
    The set of destinations described by the overlap represents a portion
@@ -3965,22 +3965,22 @@
    either the same autonomous system or a neighboring autonomous system.
 
    When a BGP speaker receives an UPDATE message from an internal peer,
-   the receiving BGP speaker shall not re-distribute the routing infor-
+   the receiving BGP speaker SHALL NOT re-distribute the routing infor-
    mation contained in that UPDATE message to other internal peers,
    unless the speaker acts as a BGP Route Reflector [RFC2796].
 
    As part of Phase 3 of the route selection process, the BGP speaker
    has updated its Adj-RIBs-Out. All newly installed routes and all
-   newly unfeasible routes for which there is no replacement route shall
+   newly unfeasible routes for which there is no replacement route SHALL
    be advertised to its peers by means of an UPDATE message.
 
-   A BGP speaker should not advertise a given feasible BGP route from
+   A BGP speaker SHOULD NOT advertise a given feasible BGP route from
    its Adj-RIB-Out if it would produce an UPDATE message containing the
    same BGP route as was previously advertised.
 
-   Any routes in the Loc-RIB marked as unfeasible shall be removed.
+   Any routes in the Loc-RIB marked as unfeasible SHALL be removed.
    Changes to the reachable destinations within its own autonomous sys-
-   tem shall also be advertised in an UPDATE message.
+   tem SHALL also be advertised in an UPDATE message.
 
    If due to the limits on the maximum size of an UPDATE message (see
    Section 4) a single route doesn't fit into the message, the BGP
@@ -4082,7 +4082,7 @@
 RFC DRAFT                                                   October 2002
 
 
-   The Decision Process may optionally reduce the amount of information
+   The Decision Process MAY optionally reduce the amount of information
    that it will place in the Adj-RIBs-Out by any of the following meth-
    ods:
 
@@ -4145,7 +4145,7 @@
    aggregated.
 
    Path attributes that have different type codes can not be aggregated
-   together. Path attributes of the same type code may be aggregated,
+   together. Path attributes of the same type code MAY be aggregated,
    according to the following rules:
 
       NEXT_HOP:
@@ -4155,10 +4155,10 @@
 
       ORIGIN attribute:
          If at least one route among routes that are aggregated has ORI-
-         GIN with the value INCOMPLETE, then the aggregated route must
+         GIN with the value INCOMPLETE, then the aggregated route MUST
          have the ORIGIN attribute with the value INCOMPLETE.  Other-
          wise, if at least one route among routes that are aggregated
-         has ORIGIN with the value EGP, then the aggregated route must
+         has ORIGIN with the value EGP, then the aggregated route MUSt
          have the origin attribute with the value EGP. In all other case
          the value of the ORIGIN attribute of the aggregated route is
          IGP.
@@ -4173,14 +4173,14 @@
          "type" identifies a type of the path segment the AS belongs to
          (e.g.  AS_SEQUENCE, AS_SET), and "value" is the AS number. If
          the routes to be aggregated have different AS_PATH attributes,
-         then the aggregated AS_PATH attribute shall satisfy all of the
+         then the aggregated AS_PATH attribute SHALL satisfy all of the
          following conditions:
 
             - all tuples of type AS_SEQUENCE in the aggregated AS_PATH
-            shall appear in all of the AS_PATH in the initial set of
+            SHALL appear in all of the AS_PATH in the initial set of
             routes to be aggregated.
 
-            - all tuples of type AS_SET in the aggregated AS_PATH shall
+            - all tuples of type AS_SET in the aggregated AS_PATH SHALL
             appear in at least one of the AS_PATH in the initial set
             (they may appear as either AS_SET or AS_SEQUENCE types).
 
@@ -4239,12 +4239,12 @@
       ATOMIC_AGGREGATE:
          If at least one of the routes to be aggregated has
          ATOMIC_AGGREGATE path attribute, then the aggregated route
-         shall have this attribute as well.
+         SHALL have this attribute as well.
 
       AGGREGATOR:
-         All AGGREGATOR attributes of all routes to be aggregated should
+         All AGGREGATOR attributes of all routes to be aggregated SHOULD
          be ignored. The BGP speaker performing the route aggregation
-         may attach a new AGGREGATOR attribute (see Section 5.1.7).
+         MAY attach a new AGGREGATOR attribute (see Section 5.1.7).
 
 
 
@@ -4288,15 +4288,15 @@
 
 9.4 Originating BGP routes
 
-   A BGP speaker may originate BGP routes by injecting routing informa-
+   A BGP speaker MAY originate BGP routes by injecting routing informa-
    tion acquired by some other means (e.g. via an IGP) into BGP. A BGP
-   speaker that originates BGP routes shall assign the degree of prefer-
+   speaker that originates BGP routes SHALL assign the degree of prefer-
    ence to these routes by passing them through the Decision Process
-   (see Section 9.1). These routes may also be distributed to other BGP
+   (see Section 9.1). These routes MAY also be distributed to other BGP
    speakers within the local AS as part of the update process (see Sec-
    tion 9.2). The decision whether to distribute non-BGP acquired routes
    within an AS via BGP or not depends on the environment within the AS
-   (e.g. type of IGP) and should be controlled via configuration.
+   (e.g. type of IGP) and SHOULD be controlled via configuration.
 
 
 10 BGP Timers
@@ -4338,9 +4338,9 @@
    figurable.
 
    To minimize the likelihood that the distribution of BGP messages by a
-   given BGP speaker will contain peaks, jitter should be applied to the
+   given BGP speaker will contain peaks, jitter SHOULD be applied to the
    timers associated with MinASOriginationInterval, KeepAlive, Min-
-   RouteAdvertisementInterval, and ConnectRetry. A given BGP speaker may
+   RouteAdvertisementInterval, and ConnectRetry. A given BGP speaker MAY
    apply the same jitter to each of these quantities regardless of the
    destinations to which the updates are being sent; that is, jitter
    need not be configured on a "per peer" basis.
@@ -4348,7 +4348,7 @@
    The suggested default amount of jitter shall be determined by multi-
    plying the base value of the appropriate timer by a random factor
    which is uniformly distributed in the range from 0.75 to 1.0. A new
-   random value should be picked each time the timer is set. The range
+   random value SHOULD be picked each time the timer is set. The range
    of the jitter random value MAY be configurable.
 
 
@@ -4514,16 +4514,16 @@
 
 
    If a local system TCP user interface supports TCP PUSH function, then
-   each BGP message should be transmitted with PUSH flag set.  Setting
+   each BGP message SHOULD be transmitted with PUSH flag set.  Setting
    PUSH flag forces BGP messages to be transmitted promptly to the
    receiver.
 
    If a local system TCP user interface supports setting precedence for
-   TCP connection, then TCP connection used by BGP should be opened with
+   TCP connection, then TCP connection used by BGP SHOULD be opened with
    precedence set to Internetwork Control (110) value (see also
    [RFC791]).
 
-   A local system may protect its BGP connections by using the TCP MD5
+   A local system MAY protect its BGP connections by using the TCP MD5
    Signature Option [RFC2385].
 
 
@@ -4602,7 +4602,7 @@
    This permits them to quickly identify sets of attributes from differ-
    ent update messages which are semantically identical.  To facilitate
    this, it is a useful optimization to order the path attributes
-   according to type code.  This optimization is entirely optional.
+   according to type code.  This optimization is entirely OPTIONAL.
 
 
 Appendix F.4 AS_SET sorting
@@ -4622,7 +4622,7 @@
 RFC DRAFT                                                   October 2002
 
 
-   is entirely optional.
+   is entirely OPTIONAL.
 
 
 Appendix F.5 Control over version negotiation
@@ -4638,7 +4638,7 @@
 
 
    An implementation which chooses to provide a path aggregation algo-
-   rithm which retains significant amounts of path information may wish
+   rithm which retains significant amounts of path information MAY wish
    to use the following procedure:
 
       For the purpose of aggregating AS_PATH attributes of two routes,
@@ -4692,7 +4692,7 @@
 
       If as a result of the above procedure a given AS number appears
       more than once within the aggregated AS_PATH attribute, all, but
-      the last instance (rightmost occurrence) of that AS number should
+      the last instance (rightmost occurrence) of that AS number SHOULD
       be removed from the aggregated AS_PATH attribute.
 
 

-- 
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 LAA19749 for <[e-mail]>; Mon, 6 Jan 2003 11:49:48 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 501CB91268; Mon,  6 Jan 2003 11:47:21 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA45791267; Mon,  6 Jan 2003 11:47: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 08CA491263 for <[e-mail]>; Mon,  6 Jan 2003 11:45:26 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 558775DF76; Mon,  6 Jan 2003 11:45: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 9B57C5DDB3 for <[e-mail]>; Mon,  6 Jan 2003 11:45:23 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id h06GjM434476 for [e-mail]; Mon, 6 Jan 2003 11:45: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 h06GjJC34468 for <[e-mail]>; Mon, 6 Jan 2003 11:45:19 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id h06GjJp13769 for [e-mail]; Mon, 6 Jan 2003 11:45:19 -0500 (EST)
Date: Mon, 6 Jan 2003 11:45:19 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Issues list, #17: Section 3, Page 8, Paragraph 3 - Obsolete?
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

> 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.

To provide context, this paragraph currently reads:

:   The hosts executing BGP need not be routers.  A non-routing host
:   could exchange routing information with routers via EGP [RFC904] or
:   even an interior routing protocol. That non-routing host could then
:   use BGP to exchange routing information with a border router in
:   another Autonomous System. The implications and applications of this
:   architecture are for further study.

There are several deployed entities that could be considered to "exploit"
this paragraph.  Route collectors, route servers, bandwidth shapers
and other optimizers.  However, the original text may be showing its
age a little bit.

Perhaps the following might be a bit more appropriate:

"The hosts executing BGP need not be routers.  A non-routing host may
 exchange routing information with a BGP speaker for reasons
 that are outside the scope of this document."

I would also propose adding to the same paragraph (but could be persuaded
to drop it since it is *logically* redundant):
"These non-routing hosts should exercise great care not to insert 
 themselves into the forwarding path if they re-announce BGP routes."


-- 
Jeff Haas 
NextHop Technologies