RE: issue 11

[Dimitry Haskin <[e-mail]>]

The following paragraph somewhere in the document may help resolve the
issue:

"If more than a single BGP route to the same destination prefix are
selected to be used locally by a speaker (e.g. for the load sharing
purposes), such a BGP speaker SHOULD form an aggregate of all such routes
for the purpose of advertising this prefix to other BGP peers. Route
aggregation rules are specified in section 9.2.2.2."

Dimitry

> -----Original Message-----
> From: Alex Zinin [mailto:[e-mail]]
> Sent: Monday, September 30, 2002 2:21 PM
> To: Yakov Rekhter
> Cc: [e-mail]
> Subject: Re: issue 11
> 
> 
> Yakov,
> 
> [...]
> >>    Multipath is
> >>   something that is normally in the heart of a routing 
> protocol. There
> >>   should be a good reason to want something like this in a separate
> >>   document. Do we have one in this case?
> 
> > Time. If we are interested in getting the base spec completed within
> > the timeframe outlined in the current charter, we can't add
> > substantial new material to the spec. 
> 
> I share the concern about time. However, the issues related to best
> path calculation, multipath included, seem to me to be quite important
> from the perspective of interoperability and description of further
> extensions. Maybe if we the chairs could get the right people together
> and facilitate the process (ADs would definitely contribute to buying
> the libations), such a design team could come up with solid stuff
> within a month?
> 
> BTW, regarding the part of the spec describing the best path selection
> algo, I remember there was a concern that it didn't really describe
> what vendors actually did. Is it still the case?
> 
> Alex
> 
> 



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA12507 for <[e-mail]>; Mon, 30 Sep 2002 18:39:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E773791289; Mon, 30 Sep 2002 18:39:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0AAC9128A; Mon, 30 Sep 2002 18:39:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AB17691289 for <[e-mail]>; Mon, 30 Sep 2002 18:39:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 960F05DDE2; Mon, 30 Sep 2002 18:39:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from bridge.axiowave.com (unknown [64.115.125.242]) by segue.merit.edu (Postfix) with ESMTP id 3795F5DDCF for <[e-mail]>; Mon, 30 Sep 2002 18:39:20 -0400 (EDT)
Message-ID: <[e-mail]>
From: Dimitry Haskin <[e-mail]>
To: "'Alex Zinin'" <[e-mail]>, Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 11
Date: Mon, 30 Sep 2002 18:39:13 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

The following paragraph somewhere in the document may help resolve the
issue:

"If more than a single BGP route to the same destination prefix are
selected to be used locally by a speaker (e.g. for the load sharing
purposes), such a BGP speaker SHOULD form an aggregate of all such routes
for the purpose of advertising this prefix to other BGP peers. Route
aggregation rules are specified in section 9.2.2.2."

Dimitry

> -----Original Message-----
> From: Alex Zinin [mailto:[e-mail]]
> Sent: Monday, September 30, 2002 2:21 PM
> To: Yakov Rekhter
> Cc: [e-mail]
> Subject: Re: issue 11
> 
> 
> Yakov,
> 
> [...]
> >>    Multipath is
> >>   something that is normally in the heart of a routing 
> protocol. There
> >>   should be a good reason to want something like this in a separate
> >>   document. Do we have one in this case?
> 
> > Time. If we are interested in getting the base spec completed within
> > the timeframe outlined in the current charter, we can't add
> > substantial new material to the spec. 
> 
> I share the concern about time. However, the issues related to best
> path calculation, multipath included, seem to me to be quite important
> from the perspective of interoperability and description of further
> extensions. Maybe if we the chairs could get the right people together
> and facilitate the process (ADs would definitely contribute to buying
> the libations), such a design team could come up with solid stuff
> within a month?
> 
> BTW, regarding the part of the spec describing the best path selection
> algo, I remember there was a concern that it didn't really describe
> what vendors actually did. Is it still the case?
> 
> Alex
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA10668 for <[e-mail]>; Mon, 30 Sep 2002 17:51:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 28B7691283; Mon, 30 Sep 2002 17:50:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7D1091286; Mon, 30 Sep 2002 17:50:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B087191283 for <[e-mail]>; Mon, 30 Sep 2002 17:50:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 991B75DDE1; Mon, 30 Sep 2002 17:50:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 0AE365DDE0 for <[e-mail]>; Mon, 30 Sep 2002 17:50:43 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id OAA08938; Mon, 30 Sep 2002 14:47:42 -0700 (PDT)
Date: Mon, 30 Sep 2002 14:47:42 -0700
From: [e-mail]
To: Yakov Rekhter <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>, [e-mail]
Subject: Re: issue 10
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, Sep 30, 2002 at 10:23:19AM -0700
Sender: [e-mail]
Precedence: bulk

Ok, so to incorporate the proposed changes in one paragraph, the text
we have on the table right now is:

    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 speaker MUST not advertise the route to its peers and
    may choose to log an error locally.

Are we in agreement that this is acceptable?

Andrew

On Mon, Sep 30, 2002 at 10:23:19AM -0700, Yakov Rekhter wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> To: Jeffrey Haas <[e-mail]>
> Cc: [e-mail]
> Subject: Re: issue 10 
> In-Reply-To: Your message of "Mon, 30 Sep 2002 13:20:31 EDT."
>              <[e-mail]> 
> Date: Mon, 30 Sep 2002 10:23:19 -0700
> From: Yakov Rekhter <[e-mail]>
> Precedence: bulk
> X-OriginalArrivalTime: 30 Sep 2002 17:25:42.0467 (UTC) FILETIME=[672D3130:01C268A6]
> 
> Jeff,
> 
> > On Mon, Sep 30, 2002 at 10:15:26AM -0700, Yakov Rekhter wrote:
> > > > > "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 speaker may choose not to advertise the route to its
> > > > > peers and may choose to log an error locally."  
> > >
> > > Perhaps we should replace "may choose not to advertise..." with 
> > > "SHOULD NOT advertise...".
> > 
> > If it going to choose to advertise, and we're in an overflow
> > situation, how do we do it?
> > 
> > I suggest that the words really should be "must not advertise" and
> > "may choose to log an error".
> 
> That would be fine too.
> 
> 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 OAA03479 for <[e-mail]>; Mon, 30 Sep 2002 14:23:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D49369127E; Mon, 30 Sep 2002 14:22:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DA9291283; Mon, 30 Sep 2002 14:22:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 641F49127E for <[e-mail]>; Mon, 30 Sep 2002 14:22:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 23F865DDC5; Mon, 30 Sep 2002 14:22:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id EE9065DDAD for <[e-mail]>; Mon, 30 Sep 2002 14:22:31 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17w5Bf-0005gu-00; Mon, 30 Sep 2002 11:22:31 -0700
Date: Mon, 30 Sep 2002 11:20:34 -0700
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 11
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Yakov,

[...]
>>    Multipath is
>>   something that is normally in the heart of a routing protocol. There
>>   should be a good reason to want something like this in a separate
>>   document. Do we have one in this case?

> Time. If we are interested in getting the base spec completed within
> the timeframe outlined in the current charter, we can't add
> substantial new material to the spec. 

I share the concern about time. However, the issues related to best
path calculation, multipath included, seem to me to be quite important
from the perspective of interoperability and description of further
extensions. Maybe if we the chairs could get the right people together
and facilitate the process (ADs would definitely contribute to buying
the libations), such a design team could come up with solid stuff
within a month?

BTW, regarding the part of the spec describing the best path selection
algo, I remember there was a concern that it didn't really describe
what vendors actually did. Is it still the case?

Alex




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA02221 for <[e-mail]>; Mon, 30 Sep 2002 13:46:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 89C2191276; Mon, 30 Sep 2002 13:45:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5780F91277; Mon, 30 Sep 2002 13:45:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E223991276 for <[e-mail]>; Mon, 30 Sep 2002 13:45:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 974A55DDC5; Mon, 30 Sep 2002 13:45:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 28CFB5DDAD for <[e-mail]>; Mon, 30 Sep 2002 13:45:24 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17w4bf-0004Vv-00; Mon, 30 Sep 2002 10:45:19 -0700
Date: Mon, 30 Sep 2002 10:43:26 -0700
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Curtis Villamizar <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: issue 11
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Curtis,

 I disagree here. In routing, node-local decisions affecting the
 routing and forwarding tables are as important as the algorithms
 describing inter-node routing proto packet exchange. From this
 perspective, multipath definitely belongs in the spec.

Alex

Monday, September 30, 2002, 8:49:17 AM, Curtis Villamizar wrote:
[...]
> Alex,

> Multipath does not meet the criteria we have previously stated for
> adding something bases on the existance of implementations that
> support it.  That criteria was that the added feature was nearly
> universally implemented and deployed among the major parties and that
> implementing it or not affected interoperability.

>   1.  Regardless of whether a particular router has BGP multipath
>       enabled or disabled, its external behaviour from the standpoint
>       of BGP protocol interaction is completely indistinguishable.

>   2.  In the decision process, after IGP cost is considered, some
>       (most) routers are capable of considering BGP routes of equal
>       cost for the purpose of forwarding and capable of putting more
>       than one forwarding entry (typically a small integer number of
>       entries) in the FIB.  This is entirely a local matter.

>   3.  The only external sign that BGP multipath is enabled is that
>       packets are forwarded differently, but still loop free.

> Therefore this feature in particular does not belong in the base spec
> and there is no need to even mention it.

> 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 NAA01623 for <[e-mail]>; Mon, 30 Sep 2002 13:28:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C298D91275; Mon, 30 Sep 2002 13:27:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9450D91276; Mon, 30 Sep 2002 13:27:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F281091275 for <[e-mail]>; Mon, 30 Sep 2002 13:27:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D6D895DDC5; Mon, 30 Sep 2002 13:27:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 6CF9A5DDC1 for <[e-mail]>; Mon, 30 Sep 2002 13:27:28 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12H1V>; Mon, 30 Sep 2002 13:27:27 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 32.1 
Date: Mon, 30 Sep 2002 13:27:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Change:
" propagate this information"
to:
" forward this route"

???

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Monday, September 30, 2002 1:21 PM
To: Abarbanel, Benjamin
Cc: [e-mail]
Subject: Re: issue 32.1 

Ben,

> Natale:
> 
> General Comment below

> > -----Original Message-----
> > From: Natale, Jonathan [mailto:[e-mail]]
> > Sent: Monday, September 30, 2002 12:25 PM
> > To: 'Jeffrey Haas'; [e-mail]
> > Cc: [e-mail]; Natale, Jonathan; 'Yakov Rekhter';
> > [e-mail]
> > Subject: RE: issue 32.1
> > 
> > 
> > SUMMARY:
> > 
> > 1) we all agree that an rfc904 reference is in order.
> > 
> > 
> > 2) EGP is already flagged as historical, and all current 
> > implementations
> > still support ORIGIN=EGP, so deprecating this is not that 
> > important, but I
> > think we already had a consensus to deprecate it.
> > 
> > 
> > 3) I stand by my original assertion the IGP ~= route was explicitly
> > introduced and INCOMPLETE ~= implicitly introduced.  This reflects the
> > network command and the redistribute command.  This reflects a larger
> > percentage of implementations (aka "working code").  The 
> > current definitions
> > leave people scratching there heads.  The current consensus 
> > seems to be to
> > not change these definitions.  :-(
> > 
> > 
> > 4) I almost agree with Curtis that adding ~= "unless 
> > configured to do so" is
> > going to clutter up the doc, but "configured" is already in the doc 19
> > times.  BGP is highly configuration dependant, get over it.  
> > Not sure what
> > the consensus on this is.
> > 
> It seems that everytime we have a problem we can't solve, we add a
> configuration parameter to address it. I am in favour of trying to 
> minimize the configuration parameters and maximize the correctness of 
> the design.

With this in mind would you agree on the following for 5.1.1:

   ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
   is generated by the BGP speaker that originates the associated BGP
   routing information. The attribute shall be included in the UPDATE
   messages of all BGP speakers that choose to propagate this information
   to other BGP speakers. 

Yakov.

> 
> Ben
> > 
> > -----Original Message-----
> > From: Jeffrey Haas [mailto:[e-mail]] 
> > Sent: Monday, September 30, 2002 11:43 AM
> > To: [e-mail]
> > Cc: [e-mail]; Natale, Jonathan; 'Yakov Rekhter'; 
> > [e-mail]
> > Subject: Re: issue 32.1
> > 
> > On Fri, Sep 27, 2002 at 11:51:44AM -0700, 
> > [e-mail]
> > wrote:
> > > 		  1	    EGP - Network Layer Reachability Information
> > > 				learned via the EGP protocol [RFC904]
> > > 
> > > That would clarify that we're talking about the protocol, 
> > and not the
> > > class-of-protocols, or EBGP.  It would leave unstated that 
> > this could
> > > theoretically be used to muck with route selection.  I think that is
> > > ok.  If operators want to override ORIGIN to affect some hoho magic,
> > > they are welcome to do so, but I don't think it needs to be 
> > documented
> > > in the base spec.
> > 
> > I'm cool with this.
> > 
> > > 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 NAA01605 for <[e-mail]>; Mon, 30 Sep 2002 13:27:36 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F316391274; Mon, 30 Sep 2002 13:27:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8E4691275; Mon, 30 Sep 2002 13:27:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AA90C91274 for <[e-mail]>; Mon, 30 Sep 2002 13:27:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 90B155DDC5; Mon, 30 Sep 2002 13:27:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 148085DDC1 for <[e-mail]>; Mon, 30 Sep 2002 13:27:11 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA02015; Mon, 30 Sep 2002 13:27:08 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA26300; Mon, 30 Sep 2002 13:27:10 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7MPBF>; Mon, 30 Sep 2002 13:27:09 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 32.1 
Date: Mon, 30 Sep 2002 13:27:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov,

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Monday, September 30, 2002 1:21 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: issue 32.1 
> 
> 
> Ben,
> 
> > Natale:
> > 
> > General Comment below
> 
> > > -----Original Message-----
> > > From: Natale, Jonathan [mailto:[e-mail]]
> > > Sent: Monday, September 30, 2002 12:25 PM
> > > To: 'Jeffrey Haas'; [e-mail]
> > > Cc: [e-mail]; Natale, Jonathan; 'Yakov Rekhter';
> > > [e-mail]
> > > Subject: RE: issue 32.1
> > > 
> > > 
> > > SUMMARY:
> > > 
> > > 1) we all agree that an rfc904 reference is in order.
> > > 
> > > 
> > > 2) EGP is already flagged as historical, and all current 
> > > implementations
> > > still support ORIGIN=EGP, so deprecating this is not that 
> > > important, but I
> > > think we already had a consensus to deprecate it.
> > > 
> > > 
> > > 3) I stand by my original assertion the IGP ~= route was 
> explicitly
> > > introduced and INCOMPLETE ~= implicitly introduced.  This 
> reflects the
> > > network command and the redistribute command.  This 
> reflects a larger
> > > percentage of implementations (aka "working code").  The 
> > > current definitions
> > > leave people scratching there heads.  The current consensus 
> > > seems to be to
> > > not change these definitions.  :-(
> > > 
> > > 
> > > 4) I almost agree with Curtis that adding ~= "unless 
> > > configured to do so" is
> > > going to clutter up the doc, but "configured" is already 
> in the doc 19
> > > times.  BGP is highly configuration dependant, get over it.  
> > > Not sure what
> > > the consensus on this is.
> > > 
> > It seems that everytime we have a problem we can't solve, we add a
> > configuration parameter to address it. I am in favour of trying to 
> > minimize the configuration parameters and maximize the 
> correctness of 
> > the design.
> 
> With this in mind would you agree on the following for 5.1.1:
> 
>    ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
>    is generated by the BGP speaker that originates the associated BGP
>    routing information. The attribute shall be included in the UPDATE
>    messages of all BGP speakers that choose to propagate this 
> information
>    to other BGP speakers. 
> 
> Yakov.
> 

I never disagreed on this point with the original text. I only disagreed 
with adding configuration dependency anywhere there was a questionable 
area.

Ben

> > 
> > Ben
> > > 
> > > -----Original Message-----
> > > From: Jeffrey Haas [mailto:[e-mail]] 
> > > Sent: Monday, September 30, 2002 11:43 AM
> > > To: [e-mail]
> > > Cc: [e-mail]; Natale, Jonathan; 'Yakov Rekhter'; 
> > > [e-mail]
> > > Subject: Re: issue 32.1
> > > 
> > > On Fri, Sep 27, 2002 at 11:51:44AM -0700, 
> > > [e-mail]
> > > wrote:
> > > > 		  1	    EGP - Network Layer 
> Reachability Information
> > > > 				learned via the EGP 
> protocol [RFC904]
> > > > 
> > > > That would clarify that we're talking about the protocol, 
> > > and not the
> > > > class-of-protocols, or EBGP.  It would leave unstated that 
> > > this could
> > > > theoretically be used to muck with route selection.  I 
> think that is
> > > > ok.  If operators want to override ORIGIN to affect 
> some hoho magic,
> > > > they are welcome to do so, but I don't think it needs to be 
> > > documented
> > > > in the base spec.
> > > 
> > > I'm cool with this.
> > > 
> > > > 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 NAA01483 for <[e-mail]>; Mon, 30 Sep 2002 13:23:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E624191272; Mon, 30 Sep 2002 13:23:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABB4D91274; Mon, 30 Sep 2002 13:23:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 853E091272 for <[e-mail]>; Mon, 30 Sep 2002 13:23:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6B7F05DDC7; Mon, 30 Sep 2002 13:23:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id CFE9A5DDC9 for <[e-mail]>; Mon, 30 Sep 2002 13:23:20 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8UHNJm50459; Mon, 30 Sep 2002 10:23:19 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 10 
In-Reply-To: Your message of "Mon, 30 Sep 2002 13:20:31 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 30 Sep 2002 10:23:19 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> On Mon, Sep 30, 2002 at 10:15:26AM -0700, Yakov Rekhter wrote:
> > > > "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 speaker may choose not to advertise the route to its
> > > > peers and may choose to log an error locally."  
> >
> > Perhaps we should replace "may choose not to advertise..." with 
> > "SHOULD NOT advertise...".
> 
> If it going to choose to advertise, and we're in an overflow
> situation, how do we do it?
> 
> I suggest that the words really should be "must not advertise" and
> "may choose to log an error".

That would be fine too.

Yakov.


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 NAA01399 for <[e-mail]>; Mon, 30 Sep 2002 13:21:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D6FE291270; Mon, 30 Sep 2002 13:20:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E94B91272; Mon, 30 Sep 2002 13:20:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E58691270 for <[e-mail]>; Mon, 30 Sep 2002 13:20:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6C0275DDCA; Mon, 30 Sep 2002 13:20:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 7B8435DDC7 for <[e-mail]>; Mon, 30 Sep 2002 13:20:52 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8UHKmm49543; Mon, 30 Sep 2002 10:20:48 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 32.1 
In-Reply-To: Your message of "Mon, 30 Sep 2002 12:30:29 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 30 Sep 2002 10:20:48 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> Natale:
> 
> General Comment below

> > -----Original Message-----
> > From: Natale, Jonathan [mailto:[e-mail]]
> > Sent: Monday, September 30, 2002 12:25 PM
> > To: 'Jeffrey Haas'; [e-mail]
> > Cc: [e-mail]; Natale, Jonathan; 'Yakov Rekhter';
> > [e-mail]
> > Subject: RE: issue 32.1
> > 
> > 
> > SUMMARY:
> > 
> > 1) we all agree that an rfc904 reference is in order.
> > 
> > 
> > 2) EGP is already flagged as historical, and all current 
> > implementations
> > still support ORIGIN=EGP, so deprecating this is not that 
> > important, but I
> > think we already had a consensus to deprecate it.
> > 
> > 
> > 3) I stand by my original assertion the IGP ~= route was explicitly
> > introduced and INCOMPLETE ~= implicitly introduced.  This reflects the
> > network command and the redistribute command.  This reflects a larger
> > percentage of implementations (aka "working code").  The 
> > current definitions
> > leave people scratching there heads.  The current consensus 
> > seems to be to
> > not change these definitions.  :-(
> > 
> > 
> > 4) I almost agree with Curtis that adding ~= "unless 
> > configured to do so" is
> > going to clutter up the doc, but "configured" is already in the doc 19
> > times.  BGP is highly configuration dependant, get over it.  
> > Not sure what
> > the consensus on this is.
> > 
> It seems that everytime we have a problem we can't solve, we add a
> configuration parameter to address it. I am in favour of trying to 
> minimize the configuration parameters and maximize the correctness of 
> the design.

With this in mind would you agree on the following for 5.1.1:

   ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
   is generated by the BGP speaker that originates the associated BGP
   routing information. The attribute shall be included in the UPDATE
   messages of all BGP speakers that choose to propagate this information
   to other BGP speakers. 

Yakov.

> 
> Ben
> > 
> > -----Original Message-----
> > From: Jeffrey Haas [mailto:[e-mail]] 
> > Sent: Monday, September 30, 2002 11:43 AM
> > To: [e-mail]
> > Cc: [e-mail]; Natale, Jonathan; 'Yakov Rekhter'; 
> > [e-mail]
> > Subject: Re: issue 32.1
> > 
> > On Fri, Sep 27, 2002 at 11:51:44AM -0700, 
> > [e-mail]
> > wrote:
> > > 		  1	    EGP - Network Layer Reachability Information
> > > 				learned via the EGP protocol [RFC904]
> > > 
> > > That would clarify that we're talking about the protocol, 
> > and not the
> > > class-of-protocols, or EBGP.  It would leave unstated that 
> > this could
> > > theoretically be used to muck with route selection.  I think that is
> > > ok.  If operators want to override ORIGIN to affect some hoho magic,
> > > they are welcome to do so, but I don't think it needs to be 
> > documented
> > > in the base spec.
> > 
> > I'm cool with this.
> > 
> > > 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 NAA01405 for <[e-mail]>; Mon, 30 Sep 2002 13:21:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0146291227; Mon, 30 Sep 2002 13:20:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C34DE91270; Mon, 30 Sep 2002 13:20:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3903991272 for <[e-mail]>; Mon, 30 Sep 2002 13:20:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 19F1A5DDCB; Mon, 30 Sep 2002 13:20:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 4B0645DDC7 for <[e-mail]>; Mon, 30 Sep 2002 13:20:36 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8UHKYa58916; Mon, 30 Sep 2002 13:20:34 -0400 (EDT) (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 g8UHKVG58909; Mon, 30 Sep 2002 13:20:31 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8UHKVl26585; Mon, 30 Sep 2002 13:20:31 -0400 (EDT)
Date: Mon, 30 Sep 2002 13:20:31 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 10
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, Sep 30, 2002 at 10:15:26AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Mon, Sep 30, 2002 at 10:15:26AM -0700, Yakov Rekhter wrote:
> > > "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 speaker may choose not to advertise the route to its
> > > peers and may choose to log an error locally."  
>
> Perhaps we should replace "may choose not to advertise..." with 
> "SHOULD NOT advertise...".

If it going to choose to advertise, and we're in an overflow
situation, how do we do it?

I suggest that the words really should be "must not advertise" and
"may choose to log an error".

> 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 NAA01241 for <[e-mail]>; Mon, 30 Sep 2002 13:17:24 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3F51C91273; Mon, 30 Sep 2002 13:15:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D40CE91270; Mon, 30 Sep 2002 13:15:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CE95491270 for <[e-mail]>; Mon, 30 Sep 2002 13:15:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 579CA5DDC5; Mon, 30 Sep 2002 13:15:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 91C215DD95 for <[e-mail]>; Mon, 30 Sep 2002 13:15:26 -0400 (EDT)
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 NAA33307; Mon, 30 Sep 2002 13:15:13 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 8 
In-reply-to: Your message of "Mon, 30 Sep 2002 21:50:09 +0530." <[e-mail]> 
Date: Mon, 30 Sep 2002 13:15:13 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, "Sivanand
a Ramnath - CTD, Chennai." writes:
> Hello,
> 
>     I still don't quite understand how applying jitter (as currently defined
> would help). Jitter, as per draft-17, is to be applied on a per speaker
> basis, and not on a per peer basis.
> 
>     Given this, how does applying jitter on ConnectRetry timer help ?
> 
> Siva
> ([e-mail])


Applying it on a per speaker basis means selecting a range on a per
speaker basis from which the random number is selected on a per timer
usage basis.

You can't possibly think that a BGP speaker selects a timer value with
jitter at boot up and uses the same value all the timer.  (I hope).
Jitter within some range is added for each use of a timer.

Curtis


> > -----Original Message-----
> > From: Natale, Jonathan [mailto:[e-mail]]
> > Sent: Monday, September 30, 2002 8:17 PM
> > To: '[e-mail]'; Natale, Jonathan
> > Cc: [e-mail]
> > Subject: RE: issue 8 
> > 
> > 
> > Curtis,
> > 
> > So you are agreeing with the proposed change which is to add 
> > ~= "jitter may
> > be applied to the ConnectRetry".  I thought we already had 
> > consensus on
> > this.  Anyway, my email was merely to answer Sivananda's questions: Is
> > adding a jitter to the ConnectRetry timer a standard 
> > practice? -AND-  What
> > benefit does this provide?
> > 
> > Also, I am not sure that I agree with your statement: "does not pose
> > interoperability problems".  Bringing up all the peers at once would
> possible cause a network load spike.
> > 
> > I also find it interesting that it is recommend to add jitter 
> > all the timers
> > except 1--the only 1 that actually has jitter (in most of the 
> > real world)!
> > In my mind, this is the one that needs jitter the most.  
> > Admittedly, I do
> > not have sufficient empirical evidence to support this.  But 
> > the one entity
> > that does, seems to have conveyed the result in the form of 
> > working code.
> > 
> > Jonathan
> > :-) 
> > 
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:[e-mail]] 
> > Sent: Monday, September 30, 2002 9:55 AM
> > To: Natale, Jonathan
> > Cc: [e-mail]
> > Subject: Re: issue 8 
> > 
> > 
> > Jonathan,
> > 
> > As far as the BGP spec is concerned it is fine to just say that jitter
> > should be applied to all timers.  Whether a particular vendor does so
> > for a particular timer does not pose interoperability problems, at
> > worst is very minor deficiency in an implementation, and therefore is
> > irrelevant to the discussion of what should be recommended in the
> > protocol spec.
> > 
> > Curtis
> > 
> > 
> > In message
> > <[e-mail]
> > ks.com>, "Natale, Jonathan" writes:
> > > It seems to me that if you bring up all bgp peers at once it
> > > may lead to load spikes on the network.  Cisco seems to wait
> > > 27.5 +/- 2.5 seconds for IBGP, and 40 +/- 5 seconds for
> > > EBGP--20 sec. from config time to the "open active, delay"
> > > jittered delay assignment plus the jittered delay (5 to 10
> > > sec. for IBGP, and 15 to 25 sec. for EBGP).  This would also
> > > apply for "no neighbor x.x.x.x shutdown".  Their value of
> > > ConnectRetry is 60sec.  though, not sure how this value is used
> > > (based on above).  Maybe some Cisco folks can chime in on
> > > this one???
> > > 
> > > I did not check Juniper.
> > > 
> > > Also, interestingly, they do not apply jitter to
> > > the other timers (as far as I can tell), but I don't see
> > > a problem with this.
> > > 
> > > Another timer that they use that is not mentioned in
> > > the draft/rfc is the next hop resolution timer which is 30
> > > seconds.  Although it would be nice to have this in the spec,
> > > I will concede that it is out of scope and/or
> > > implementation dependent.
> > > 
> > > -----Original Message-----
> > > From: Curtis Villamizar [mailto:[e-mail]] 
> > > Sent: Thursday, September 26, 2002 12:34 PM
> > > To: Yakov Rekhter
> > > Cc: [e-mail]; Sivananda Ramnath - CTD, Chennai.
> > > Subject: Re: issue 8 
> > > 
> > > 
> > > The TCP connection establishment timer is 75 seconds (sysctl yield
> > > "net.inet.tcp.keepinit: 75000" in BSD-oids).
> > > 
> > > The ConnectRetry determines when to make a second attempt after a
> > > prior attempt to connect has failed.  It is to avoid a rapid
> > > succession of retries on immediate failures (for example "Connection
> > > refused" if the peer was in the middle of a reboot, Network
> > > Unreachable if you can't get there from here, etc) but also 
> > covers the
> > > case where the TCP SYN goes off and is never heard from again.
> > > 
> > > 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 NAA01212 for <[e-mail]>; Mon, 30 Sep 2002 13:16:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E450F91271; Mon, 30 Sep 2002 13:15:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91AD291272; Mon, 30 Sep 2002 13:15:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 942E791271 for <[e-mail]>; Mon, 30 Sep 2002 13:15:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DD85A5DD95; Mon, 30 Sep 2002 13:15:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id B2AFF5DDC1 for <[e-mail]>; Mon, 30 Sep 2002 13:15:27 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8UHFQm47610; Mon, 30 Sep 2002 10:15:26 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 10 
In-Reply-To: Your message of "Mon, 30 Sep 2002 10:53:38 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 30 Sep 2002 10:15:26 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> On Mon, Sep 30, 2002 at 08:57:43AM -0400, Natale, Jonathan wrote:
> > Ok.  So we have consensus on:
> > "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 speaker may choose not to advertise the route to its
> > peers and may choose to log an error locally."  
> 
> If it *may* choosen not to advertise, that doesn't mean *must*.
> 
> If its going to advertise things, how is it going to behave?

Perhaps we should replace "may choose not to advertise..." with 
"SHOULD NOT advertise...".

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 NAA01077 for <[e-mail]>; Mon, 30 Sep 2002 13:12:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C51469126E; Mon, 30 Sep 2002 13:11:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90BB89126F; Mon, 30 Sep 2002 13:11:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E8AF09126E for <[e-mail]>; Mon, 30 Sep 2002 13:11:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CC2AE5DDC5; Mon, 30 Sep 2002 13:11:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id E55EA5DD95 for <[e-mail]>; Mon, 30 Sep 2002 13:11:37 -0400 (EDT)
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 NAA33217; Mon, 30 Sep 2002 13:11:20 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, Alex Zinin <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 11 
In-reply-to: Your message of "Mon, 30 Sep 2002 12:10:25 EDT." <[e-mail]> 
Date: Mon, 30 Sep 2002 13:11:20 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> Curtis:
> See below
> 
> Ben
> 
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:[e-mail]]
> > Sent: Monday, September 30, 2002 11:49 AM
> > To: Alex Zinin
> > Cc: Yakov Rekhter; [e-mail]
> > Subject: Re: issue 11 
> > 
> > 
> > 
> > In message <[e-mail]>, Alex Zinin writes:
> > > Yakov,
> > > 
> > >   If we default to putting things in different drafts, we'll have a
> > >   bunch of separate docs describing a single protocol. Multipath is
> > >   something that is normally in the heart of a routing 
> > protocol. There
> > >   should be a good reason to want something like this in a separate
> > >   document. Do we have one in this case?
> > >   Thanks.
> > > 
> > > -- 
> > > Alex
> > 
> > 
> > Alex,
> > 
> > Multipath does not meet the criteria we have previously stated for
> > adding something bases on the existance of implementations that
> > support it.  That criteria was that the added feature was nearly
> > universally implemented and deployed among the major parties and that
> > implementing it or not affected interoperability.
> > 
> >   1.  Regardless of whether a particular router has BGP multipath
> >       enabled or disabled, its external behaviour from the standpoint
> >       of BGP protocol interaction is completely indistinguishable.
> > 
>     As a peer to a router that has multipath routing enabled, I would like
>     to know that this route has a twin sister route when making my decision
>     on whether to pick this route in my decision process. If I did not I
>     would bet the farm on a inconsistent route (implying the AS-PATH and
> other
>     attributes are not always used by this route-prefix. 
>     
>     I disagree on this point.
> 
>     As a personnal opinion, a smart peer should stay away from Multi-path 
>     routes if all rules are equal with other non-multipath routes. 
>     Reasons explained in 3 below.

That is not how multipath works.  The same tie breaking takes place
and advertisements are indistinguishable even though the forwarding
entry is slightly different.

Please confine the dicsussion to how multipath currently works, not
how you would like it to work if we could change it.

> >   2.  In the decision process, after IGP cost is considered, some
> >       (most) routers are capable of considering BGP routes of equal
> >       cost for the purpose of forwarding and capable of putting more
> >       than one forwarding entry (typically a small integer number of
> >       entries) in the FIB.  This is entirely a local matter.
> > 
> >   3.  The only external sign that BGP multipath is enabled is that
> >       packets are forwarded differently, but still loop free.
> > 
>   If packets from the same source and destination are forwarded differently
>   via different Next Hops, intermittently, does'nt this opens such problems
>   as sequence errors and non-deterministics forwarding behaviors. Creating 
>   more confusion and latency problems at the end points? I realize this is
>   a forwarding issue, but BGP is creating the issue for forwarding
>   to solve.

This has been discussed extensively for longer than BGP-4 has existed.
It has been discussed over and over again in OSPF, IDR, and MPLS lists
and certainly in other WGs.

[FYI - there are multiple way to do multipath, some that work well and
most that don't.  Common are, per packet, per some other attribute, or
per a hash on src/dst.  Per packet is terrible for performance.
Src/dst hash works fine.  If there are N ways to go, just hash the
src/dst and modulo N and pick that interface.  Any given src/dst pair
always takes the same next hop.]

All routers either do src/dst hashing or the ISP (with any clue at
all) will turn off the feature and voice angry words with their router
vendor.

>   Because there are potential issues with multipath routing. We either add
>   a dedicated section for multipath, or leave it out for now as Yakov  
>   suggested.
> 
> Ben

I'll take choice two.  We should leave it out.

So we are in agreement after all, but for different reasons.

Lets end this thread now.

Curtis


> > Therefore this feature in particular does not belong in the base spec
> > and there is no need to even mention it.
> > 
> > Curtis
> > 
> > 
> > > Friday, September 27, 2002, 1:34:00 PM, Yakov Rekhter wrote:
> > > > Alex,
> > > 
> > > >> Jeff, et al
> > > >> 
> > > >>  I'm a little lost here. Considering that BGP multipath:
> > > >> 
> > > >>   - is implemented by at least two (major) vendors
> > > >> 
> > > >>   - affects core protocol mechanisms
> > > >> 
> > > >>   - is important enough to be thoroughly described
> > > >>     to avoid implementation bugs
> > > >> 
> > > >>  why would we not want it in the base spec?
> > > 
> > > > Why not in a separate draft ?
> > > 
> > > > After all, there are quite a few *optional* BGP features that are
> > > > implemented by multiple vendors, affect core protocol mechanisms,
> > > > and are important enough to be thoroughly described to avoid
> > > > implementation bugs, and are not in the base spec, but are in
> > > > separate RFCs.
> > > 
> > > > Yakov.
> > > 
> > > >>     
> > > >> -- 
> > > >> Alex
> > > >> 
> > > >> Friday, September 27, 2002, 7:25:28 AM, Jeffrey Haas wrote:
> > > >> > On Fri, Sep 27, 2002 at 07:50:10PM +0530, Sivananda 
> > Ramnath - CTD, Chenn
> > > ai.
> > > >  wrote:
> > > >> >> % The Loc-RIB SHOULD contain only one route per destination.
> > > >> >> % An implementation may choose to install multiple routes to
> > > >> >> % a destination (for the purposes of load balancing).
> > > >> >> % An implementation doing this MUST ensure that it is
> > > >> >> % interoperable with versions that do not, and MUST
> > > >> >> % ensure that no routing loops or inconsistent routing
> > > >> >> % information is propagated as result of this action. The
> > > >> >> % handling of such a configuration, however, is outside the
> > > >> >> % scope of this RFC.
> > > >> >> 
> > > >> >>    It does seem a little too detailed, though!
> > > >> 
> > > >> > My concern is not that this is rope to allow operators 
> > to hang themselve
> > > s
> > > >> > with - this is a gatling gun that allows implementers to try to
> > > >> > guess at useful rules and hose the Internet.  BGP, as 
> > a protocol,
> > > >> > is already prone to long-lived loops.  Lets not make 
> > it easier to
> > > >> > do this in a way thats harder to troubleshoot.
> > > >> 
> > > >> > I haven't thought about this in large amounts of 
> > detail, but some
> > > >> > quick observations on what could be done to actually implement
> > > >> > this:
> > > >> 
> > > >> > o The routes should be equally preferable - i.e. they 
> > need to enter
> > > >> >   the tie-breaking process.
> > > >> > o They should have the same AS_PATH
> > > >> > o Perhaps the path attributes should only be allowed 
> > to differ on
> > > >> >   NEXT_HOP.
> > > >> 
> > > >> > *If* the above are true, then re-announcing any of the 
> > routes used
> > > >> > in the load-balancing should work fine as long as the 
> > re-announcement
> > > >> > is going to be a first-party nexthop.  If you have a 
> > third-party
> > > >> > nexthop, then you might end up with inconsistant forwarding.
> > > >> 
> > > >> > I would propose that this might be something worth 
> > investing some
> > > >> > time over, but it shouldn't be mentioned in the base spec.
> > > >> 
> > > >> >> Sivanand
> > > >> 
> > > >> 
> > > 
> > > 
> > > 
> > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA00911 for <[e-mail]>; Mon, 30 Sep 2002 13:07:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D04809126D; Mon, 30 Sep 2002 13:06:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A20549126E; Mon, 30 Sep 2002 13:06:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 83B579126D for <[e-mail]>; Mon, 30 Sep 2002 13:06:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 63C0A5DDBF; Mon, 30 Sep 2002 13:06:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id E6AF25DD95 for <[e-mail]>; Mon, 30 Sep 2002 13:06:42 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA00744; Mon, 30 Sep 2002 13:06:40 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA22197; Mon, 30 Sep 2002 13:06:42 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7MN7K>; Mon, 30 Sep 2002 13:06:41 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Mathew Richardson'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, Alex Zinin <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Subject: RE: issue 11
Date: Mon, 30 Sep 2002 13:06:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

See below

> -----Original Message-----
> From: Mathew Richardson [mailto:[e-mail]]
> Sent: Monday, September 30, 2002 12:57 PM
> To: Abarbanel, Benjamin
> Cc: '[e-mail]'; Alex Zinin; Yakov Rekhter; [e-mail]
> Subject: Re: issue 11
> 
> 
> > Abarbanel, Benjamin <[e-mail]> [Mon, 
> Sep 30, 2002 at 12:10:25PM -0400]:
> >Curtis:
> >See below
> >
> >Ben
> >
> >> -----Original Message-----
> >> From: Curtis Villamizar [mailto:[e-mail]]
> >> Sent: Monday, September 30, 2002 11:49 AM
> >> To: Alex Zinin
> >> Cc: Yakov Rekhter; [e-mail]
> >> Subject: Re: issue 11 
> >> 
> >> 
> >> 
> >> In message <[e-mail]>, Alex Zinin writes:
> >> > Yakov,
> >> > 
> >> >   If we default to putting things in different drafts, 
> we'll have a
> >> >   bunch of separate docs describing a single protocol. 
> Multipath is
> >> >   something that is normally in the heart of a routing 
> >> protocol. There
> >> >   should be a good reason to want something like this in 
> a separate
> >> >   document. Do we have one in this case?
> >> >   Thanks.
> >> > 
> >> > -- 
> >> > Alex
> >> 
> >> 
> >> Alex,
> >> 
> >> Multipath does not meet the criteria we have previously stated for
> >> adding something bases on the existance of implementations that
> >> support it.  That criteria was that the added feature was nearly
> >> universally implemented and deployed among the major 
> parties and that
> >> implementing it or not affected interoperability.
> >> 
> >>   1.  Regardless of whether a particular router has BGP multipath
> >>       enabled or disabled, its external behaviour from the 
> standpoint
> >>       of BGP protocol interaction is completely indistinguishable.
> >> 
> >    As a peer to a router that has multipath routing 
> enabled, I would like
> >    to know that this route has a twin sister route when 
> making my decision
> >    on whether to pick this route in my decision process. If 
> I did not I
> >    would bet the farm on a inconsistent route (implying the 
> AS-PATH and
> >other
> >    attributes are not always used by this route-prefix. 
> 
> <snip>
> 
> You may wish to know that, but the protocol _as deployed_ provides
> no means for that information to be conveyed.  If you call up your
> peer, and find that they are, indeed, using multipath, then you
> can make the appropriate policy decision; however, such decisions
> can't be made based on information contained within the protocol.
> 

<snip>
OK, yeah, I missed the point if we send the same destination prefix 
for two routes the receiving peer will treat the 2nd route as an update
to the first route and thus never tell that the two routes must be 
present for multi-path. OOPs, we have a hole with multi-path. 
Again we violate BGP rule 1 of "advertise to your peer what you use".

Sounds like we have a serious issue with BGP rule 1 not be honored all the
time by BGP.

> <snip>
> 
> >  If packets from the same source and destination are 
> forwarded differently
> >  via different Next Hops, intermittently, does'nt this 
> opens such problems
> >  as sequence errors and non-deterministics forwarding 
> behaviors. Creating 
> >  more confusion and latency problems at the end points? I 
> realize this is
> >  a forwarding issue, but BGP is creating the issue for forwarding
> >  to solve.
> 
> <snip>
> 
> As currently written, and deployed, the BGP protocol is not 
> creating this
> problem.  Rather, nonstandard extensions to the base spec are 
> (potentially)
> creating this problem.
> 
> >  Because there are potential issues with multipath routing. 
> We either add
> >  a dedicated section for multipath, or leave it out for now 
> as Yakov  
> >  suggested.
> 
> I'm for leaving it out now, and forever.  If we wish to document it,
> it should be in a new draft.
> 

You have my total agreement.

Ben 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA00707 for <[e-mail]>; Mon, 30 Sep 2002 13:01:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A39859126A; Mon, 30 Sep 2002 13:01:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 630919126D; Mon, 30 Sep 2002 13:01:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DD8609126A for <[e-mail]>; Mon, 30 Sep 2002 13:01:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3ACDE5DDC5; Mon, 30 Sep 2002 13:01:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 550045DDBF for <[e-mail]>; Mon, 30 Sep 2002 13:01:01 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8UH0xm45869; Mon, 30 Sep 2002 10:00:59 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 32.1 
In-Reply-To: Your message of "Mon, 30 Sep 2002 11:43:04 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 30 Sep 2002 10:00:59 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> On Fri, Sep 27, 2002 at 11:51:44AM -0700, [e-mail] wrot
e:
> > 		  1	    EGP - Network Layer Reachability Information
> > 				learned via the EGP protocol [RFC904]
> > 
> > That would clarify that we're talking about the protocol, and not the
> > class-of-protocols, or EBGP.  It would leave unstated that this could
> > theoretically be used to muck with route selection.  I think that is
> > ok.  If operators want to override ORIGIN to affect some hoho magic,
> > they are welcome to do so, but I don't think it needs to be documented
> > in the base spec.
> 
> I'm cool with this.

that would be fine with me too.

Yakov.

> 
> > 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 MAA00564 for <[e-mail]>; Mon, 30 Sep 2002 12:57:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 62E169126C; Mon, 30 Sep 2002 12:57:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 225A19126D; Mon, 30 Sep 2002 12:57:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C36069126C for <[e-mail]>; Mon, 30 Sep 2002 12:56:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 967565DDC2; Mon, 30 Sep 2002 12:56:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id D28A35DDBF for <[e-mail]>; Mon, 30 Sep 2002 12:56:58 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8UGuge57800; Mon, 30 Sep 2002 12:56:42 -0400 (EDT) (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 g8UGudG57792; Mon, 30 Sep 2002 12:56:39 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g8UGudB26172; Mon, 30 Sep 2002 12:56:39 -0400 (EDT)
Date: Mon, 30 Sep 2002 12:56:39 -0400
From: Mathew Richardson <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, Alex Zinin <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: issue 11
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

> Abarbanel, Benjamin <[e-mail]> [Mon, Sep 30, 2002 at 12:10:25PM -0400]:
>Curtis:
>See below
>
>Ben
>
>> -----Original Message-----
>> From: Curtis Villamizar [mailto:[e-mail]]
>> Sent: Monday, September 30, 2002 11:49 AM
>> To: Alex Zinin
>> Cc: Yakov Rekhter; [e-mail]
>> Subject: Re: issue 11 
>> 
>> 
>> 
>> In message <[e-mail]>, Alex Zinin writes:
>> > Yakov,
>> > 
>> >   If we default to putting things in different drafts, we'll have a
>> >   bunch of separate docs describing a single protocol. Multipath is
>> >   something that is normally in the heart of a routing 
>> protocol. There
>> >   should be a good reason to want something like this in a separate
>> >   document. Do we have one in this case?
>> >   Thanks.
>> > 
>> > -- 
>> > Alex
>> 
>> 
>> Alex,
>> 
>> Multipath does not meet the criteria we have previously stated for
>> adding something bases on the existance of implementations that
>> support it.  That criteria was that the added feature was nearly
>> universally implemented and deployed among the major parties and that
>> implementing it or not affected interoperability.
>> 
>>   1.  Regardless of whether a particular router has BGP multipath
>>       enabled or disabled, its external behaviour from the standpoint
>>       of BGP protocol interaction is completely indistinguishable.
>> 
>    As a peer to a router that has multipath routing enabled, I would like
>    to know that this route has a twin sister route when making my decision
>    on whether to pick this route in my decision process. If I did not I
>    would bet the farm on a inconsistent route (implying the AS-PATH and
>other
>    attributes are not always used by this route-prefix. 

<snip>

You may wish to know that, but the protocol _as deployed_ provides
no means for that information to be conveyed.  If you call up your
peer, and find that they are, indeed, using multipath, then you
can make the appropriate policy decision; however, such decisions
can't be made based on information contained within the protocol.

<snip>

>  If packets from the same source and destination are forwarded differently
>  via different Next Hops, intermittently, does'nt this opens such problems
>  as sequence errors and non-deterministics forwarding behaviors. Creating 
>  more confusion and latency problems at the end points? I realize this is
>  a forwarding issue, but BGP is creating the issue for forwarding
>  to solve.

<snip>

As currently written, and deployed, the BGP protocol is not creating this
problem.  Rather, nonstandard extensions to the base spec are (potentially)
creating this problem.

>  Because there are potential issues with multipath routing. We either add
>  a dedicated section for multipath, or leave it out for now as Yakov  
>  suggested.

I'm for leaving it out now, and forever.  If we wish to document it,
it should be in a new draft.

<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 MAA00349 for <[e-mail]>; Mon, 30 Sep 2002 12:51:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 07CC791269; Mon, 30 Sep 2002 12:50:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CDAE89126C; Mon, 30 Sep 2002 12:50:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 80A7991269 for <[e-mail]>; Mon, 30 Sep 2002 12:50:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6BE695DDBF; Mon, 30 Sep 2002 12:50:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 947CA5DDC0 for <[e-mail]>; Mon, 30 Sep 2002 12:50:48 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8UGoN357549; Mon, 30 Sep 2002 12:50:23 -0400 (EDT) (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 g8UGoLG57540; Mon, 30 Sep 2002 12:50:21 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g8UGoKf26145; Mon, 30 Sep 2002 12:50:20 -0400 (EDT)
Date: Mon, 30 Sep 2002 12:50:20 -0400
From: Mathew Richardson <[e-mail]>
To: [e-mail]
Cc: "Abarbanel, Benjamin" <[e-mail]>, "'[e-mail]'" <[e-mail]>, Kunihiro Ishiguro <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: issue 37
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4i
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

> Curtis Villamizar <[e-mail]> [Mon, Sep 30, 2002 at 11:01:15AM -0400]:
>
>In message <[e-mail]>, 

<snip>

>Suggested definitions for discussion:
>
>   Unfeasible route: A route which has been withdrawn can no longer be
>     used for forwarding is referred to as an infeasible route.
>
>   Withdrawn route: A route which was advertised but has more recently
>     appeared in the unreachable section of an UPDATE message is
>     referred to as a withdrawn route.
>
>   Withdrawing a route: Putting a prefix into the unreachable section
>     is referred to as "withdrawing" a route.
>
>The normal rules for use of a verb apply resulting in valid phrases
>such as "after a route is withdrawn" or "the route must then be
>withdrawn".  I hope we don't have to add them to the glossary as well.
>
>My personal preference is that we omit these definitions on the
>grounds that our usage conforms exactly to normal usage of the english
>language words "unfeasible", "withdrawn" and "withdrawing" when
>applied to the noun "route" and therefore need not be defined.  The
>mechanism of withdrawing routes is very clearly stated elsewhere.

<snip>

So, I was all set to send a message agreeing that there was no point
in defining these terms, but decided to check the spec before doing so ;)

It turns out there there is an inconsistancy in the usage of the word
withdrawn.

Section 3.1:

  There are three methods by which a given BGP speaker can indicate
  that a route has been withdrawn from service:

	...
      
    b) a replacement route with the same NLRI can be advertised, or

	...

Later, in the definition of Withdrawn Routes Length, we have:

  A value of 0 indicates that no routes are being withdrawn from
  service,

Taken together, this could be construed as meaning that a Withdrawn
Routes Length of 0 indicates that all routes included in the UPDATE
represent newly feasible routes... not replacement routes.

Now, it's possible that this problem has been removed by changes
to the text that have not yet been incorporated in to a new draft;
however, it arose because the text, for the most part, does _not_
use "withdrawn" in the standard way.  Instead, it refers to
routes included in the WITHDRAWN ROUTES field of an UPDATE
message.  Consequenty, I propose defining a "withdrawn route"
as follows:

  Withdrawn route: a route included in the WITHDRAW ROUTES field of
  an UPDATE message.

Regardless of whether or not this definition is included, Section 3.1
shold be changed from:

  There are three methods by which a given BGP speaker can indicate
  that a route has been withdrawn from service:

to:

  There are three methods by which a given BGP speaker can indicate
  that a route has been removed from service:

or:

  There are three methods by which a given BGP speaker can indicate
  that a route is now unfeasible:

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 MAA00303 for <[e-mail]>; Mon, 30 Sep 2002 12:50:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6DDEC9126B; Mon, 30 Sep 2002 12:49:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30EF69126C; Mon, 30 Sep 2002 12:49:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F0FBF9126B for <[e-mail]>; Mon, 30 Sep 2002 12:49:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DD39A5DDC0; Mon, 30 Sep 2002 12:49:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 4D1775DDBF for <[e-mail]>; Mon, 30 Sep 2002 12:49:48 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8UGnem44585; Mon, 30 Sep 2002 09:49:40 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: issue 58 
In-Reply-To: Your message of "Mon, 30 Sep 2002 10:19:10 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 30 Sep 2002 09:49:40 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Curtis,

> > Curtis,
> > 
> > > >   58) Deprication of ATOMIC_AGGREGATE
> > > >   ---------------------------------------------------------------------
--
> > --
> > > >   Status: No Consensus
> > > >   Change: Potentially
> > > >   Summary: It is proposed that ATOMIC_AGGREGATE be depricated.  There h
as
> >  
> > > >    not yet been any discussion on the proposed changes.
> > > > 
> > > > Comments on this issue would be appreciated.
> > > > 
> > > > In the absence of any objections to the changes proposed by Jeff, the
> > > > changes would be accepted. 
> > > > 
> > > > Yakov.
> > > 
> > > 
> > > We used to add ATOMIC_AGGREGATE whenever the AS_PATH was truncated
> > > rather than replaced with an AS_SET.  It was always purely
> > > informational since no one intentionally deaggregated and reannounced.
> > > Don't implementations still support this?
> > > 
> > > If reality is that it is informational only, then just remove the
> > > MUSTs and indicate that it is informational.
> > 
> > Could you please propose the text.
> > 
> > Yakov.
> 
> 
> This existing text is fine:
> 
>          f) ATOMIC_AGGREGATE (Type Code 6)
> 
>             ATOMIC_AGGREGATE is a well-known discretionary attribute of
>             length 0. Usage of this attribute is described in 5.1.6.
> 
> This is the existing text that we are considering changing:
> 
>   5.1.6 ATOMIC_AGGREGATE
> 
>    ATOMIC_AGGREGATE is a well-known discretionary attribute.
> 
>    When a router aggregates several routes for the purpose of
>    advertisement to a particular peer, and the AS_PATH of the aggregated
>    route excludes at least some of the AS numbers present in the AS_PATH
>    of the routes that are aggregated, the aggregated route, when
>    advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.
> 
>    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
>    attribute MUST NOT remove the attribute from the route when
>    propagating it to other speakers.
> 
>    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
>    attribute MUST NOT make any NLRI of that route more specific (as
>    defined in 9.1.4) when advertising this route to other BGP speakers.
> 
>    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
>    attribute needs to be cognizant of the fact that the actual path to
>    destinations, as specified in the NLRI of the route, while having the
>    loop-free property, may not be the path specified in the AS_PATH
>    attribute of the route.
> 
> Suuggested new text:
> 
>   5.1.6 ATOMIC_AGGREGATE
> 
>    ATOMIC_AGGREGATE is a well-known discretionary attribute.
> 
>    When a router aggregates several routes for the purpose of
>    advertisement to a particular peer, the AS_PATH of the
>    aggregated route normally includes an AS_SET formed from the set of
>    AS from which the aggregate was formed.  In many cases the network
>    administrator can determine that the aggregate can safely be
>    advertised without the AS_SET and not form route loops.
> 
>    If an aggregate excludes at least some of the AS numbers present in
>    the AS_PATH of the routes that are aggregated as a result of
>    dropping the AS_SET, the aggregated route, when advertised to the
>    peer, SHOULD include the ATOMIC_AGGREGATE attribute.
> 
>    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
>    attribute SHOULD NOT remove the attribute from the route when
>    propagating it to other speakers.
> 
>    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
>    attribute MUST NOT make any NLRI of that route more specific (as
>    defined in 9.1.4) when advertising this route to other BGP speakers.
> 
>    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
>    attribute needs to be cognizant of the fact that the actual path to
>    destinations, as specified in the NLRI of the route, while having the
>    loop-free property, may not be the path specified in the AS_PATH
>    attribute of the route.
> 
> Diffs (for reader convenience):
> 
> @@ -4,13 +4,19 @@
>     ATOMIC_AGGREGATE is a well-known discretionary attribute.
>  
>     When a router aggregates several routes for the purpose of
> -   advertisement to a particular peer, and the AS_PATH of the aggregated
> -   route excludes at least some of the AS numbers present in the AS_PATH
> -   of the routes that are aggregated, the aggregated route, when
> -   advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.
> +   advertisement to a particular peer, the AS_PATH of the
> +   aggregated route normally includes an AS_SET formed from the set of
> +   AS from which the aggregate was formed.  In many cases the network
> +   administrator can determine that the aggregate can safely be
> +   advertised without the AS_SET and not form route loops.
> +
> +   If an aggregate excludes at least some of the AS numbers present in
> +   the AS_PATH of the routes that are aggregated as a result of
> +   dropping the AS_SET, the aggregated route, when advertised to the
> +   peer, SHOULD include the ATOMIC_AGGREGATE attribute.
>  
>     A BGP speaker that receives a route with the ATOMIC_AGGREGATE
> -   attribute MUST NOT remove the attribute from the route when
> +   attribute SHOULD NOT remove the attribute from the route when
>     propagating it to other speakers.
>  
>     A BGP speaker that receives a route with the ATOMIC_AGGREGATE
> 
> 
> Current text in 9.1.4:
> 
>    If a BGP speaker chooses to aggregate, then it MUST add
>    ATOMIC_AGGREGATE attribute to the route. A route that carries
>    ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the
>    NLRI of this route can not be made more specific. Forwarding along
>    such a route does not guarantee that IP packets will actually
>    traverse only ASs listed in the AS_PATH attribute of the route.
> 
> Change to:
> 
>    If a BGP speaker chooses to aggregate, then it SHOULD either
>    include all AS used to form the aggreagate in an AS_SET or add the
>    ATOMIC_AGGREGATE attribute to the route.  This attribute is now
>    primarily informational.  With the elimination of IP routing
>    protocols that do not support classless routing and the elimination
>    of router and host implementations that do not support classless
>    routing, there is no longer a need to deaggregate.  Routes should
>    not be de-aggregated.  A route that carries ATOMIC_AGGREGATE
>    attribute in particular can not be de-aggregated. That is, the NLRI
>    of this route can not be made more specific. Forwarding along such
>    a route does not guarantee that IP packets will actually traverse
>    only ASs listed in the AS_PATH attribute of the route.
> 
> This text in 9.2.2.2 need not change.
> 
>       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.
> 
> The appendix need not change:
> 
>   Appendix 1. Comparison with RFC1771
> 
>       [...]
> 
>       Clarifications to the use of the ATOMIC_AGGREGATE attribute.
> 
> This might be a bit more wordy that is necessary.  It does address the
> objections to keeping ATOMIC_AGGREGATE by making the MUST into SHOULD,
> and explaining that ATOMIC_AGGREGATE is now primarily informational.

That would be fine.

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 MAA00296 for <[e-mail]>; Mon, 30 Sep 2002 12:50:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B38DF91267; Mon, 30 Sep 2002 12:49:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 814009126B; Mon, 30 Sep 2002 12:49:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D49991267 for <[e-mail]>; Mon, 30 Sep 2002 12:49:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 694E55DDC0; Mon, 30 Sep 2002 12:49:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 8DDB95DDBF for <[e-mail]>; Mon, 30 Sep 2002 12:49:32 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8UGnSK57443; Mon, 30 Sep 2002 12:49:28 -0400 (EDT) (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 g8UGnPG57436; Mon, 30 Sep 2002 12:49:25 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8UGnPJ26132; Mon, 30 Sep 2002 12:49:25 -0400 (EDT)
Date: Mon, 30 Sep 2002 12:49:25 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 37
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, Sep 30, 2002 at 12:45:42PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Sep 30, 2002 at 12:45:42PM -0400, Abarbanel, Benjamin wrote:
> So now we have Unfeasible routes, Infeasible routes, Withdrawn routes.
> Sounds like we need some definitions pretty badly. :)

Much like the comments on Sue's FSM document, we don't need definitions
quite so much as we need consitancy.

-- 
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 MAA00124 for <[e-mail]>; Mon, 30 Sep 2002 12:46:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2271C91268; Mon, 30 Sep 2002 12:45:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1F7591269; Mon, 30 Sep 2002 12:45:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C7F4891268 for <[e-mail]>; Mon, 30 Sep 2002 12:45:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5D5495DDBF; Mon, 30 Sep 2002 12:45:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 4E6925DD95 for <[e-mail]>; Mon, 30 Sep 2002 12:45:45 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA29677; Mon, 30 Sep 2002 12:45:43 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA18930; Mon, 30 Sep 2002 12:45:44 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7MNBY>; Mon, 30 Sep 2002 12:45:43 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, Kunihiro Ishiguro <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Subject: RE: issue 37 
Date: Mon, 30 Sep 2002 12:45:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Monday, September 30, 2002 12:31 PM
> To: Abarbanel, Benjamin
> Cc: '[e-mail]'; 
> '[e-mail]'; Kunihiro
> Ishiguro; Yakov Rekhter; [e-mail]
> Subject: Re: issue 37 
> 
> 
> 
> In message 
> <[e-mail]>, 
> "Abarbanel, Benjamin" writes:
> > > 
> > > Suggested definitions for discussion:
> > > 
> > >    Unfeasible route: A route which has been withdrawn can 
> no longer be
> > >      used for forwarding is referred to as an infeasible route.
> > > 
> >      Then why not call it withdrawn route? 
> > 
> >      BTW did you really mean "infeasible"?
> 
> Duh... yeah, that's what I meant.  :-}
>

The word "infeasible" is mentioned 0 times in this spec,
The word "unfeasible" is mentioned 6 times in this spec.

So now we have Unfeasible routes, Infeasible routes, Withdrawn routes.
Sounds like we need some definitions pretty badly. :)
 
> >      Also when one says a route is unfeasible, what does it mean. 
> >        a. The route is no longer reachable? 
> >        b. The route has some attributes that are not usefull?
> >        c. The route is temporarily put out of service with 
> the anticipation
> > it
> >           will be put back in service, later? 
> >        d. Also, why have it hanging around taking up space, 
> if its not 
> >           feasible?
> >        e. The route is to be removed from the active routes list?
> > 
> >      Personnally I would use the adjective "withdrawn 
> route" in place of
> >      "unfeasible route". Keeps content simple and precise 
> and based on the
> >      (verb) action that was performed.
> 
>    1.  Storage allocation is entirely out of scope.
> 
>    2.  It may take up space if route flap damping is used to
>        "remember" that the thing went up and down a lot, but that is
>        out of scope.
> 
>    3.  The router might use a garbage collecting memory allocator and
>        so take up space, but that is out of scope.
> 
>    4.  The definition need not enumerate all implication of the
>        concept of infeasible routes.
> 
>    5.  This conversation is now bordering on the ridiculous.
> 

  I agree, it started as a minor issue and grew to this. So if no one
is interested in defining this I will agree to drop this issue.

Matter Closed, court adjurned on issue 37.

Ben 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA00029 for <[e-mail]>; Mon, 30 Sep 2002 12:43:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 09FAD91266; Mon, 30 Sep 2002 12:43:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CDD7091267; Mon, 30 Sep 2002 12:43:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7EC9791266 for <[e-mail]>; Mon, 30 Sep 2002 12:43:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 637385DDBF; Mon, 30 Sep 2002 12:43:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 1374C5DD95 for <[e-mail]>; Mon, 30 Sep 2002 12:43:17 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12G93>; Mon, 30 Sep 2002 12:43:16 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: issue 32.1 - tail end of SUMMARY
Date: Mon, 30 Sep 2002 12:43:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

5) Removing " well-known mandatory attribute" in 5.1.1.  Consensus was to
not remove it, but rather specify attribute flavor for all attributes in
5.1.x's sections (for consistency).


6) Change " generated by the autonomous system" to " generated by the
speaker".  Consensus was to make this change.


7) Add ~= "other speakers do not change the ORIGIN value".  This was
because:
" It shall be included in the UPDATE messages of all BGP speakers that
choose to propagate this information to other BGP speakers"

...did not clearly say this.  Consensus was to make this change.



-----Original Message-----
From: Natale, Jonathan 
Sent: Monday, September 30, 2002 12:25 PM
To: 'Jeffrey Haas'; [e-mail]
Cc: [e-mail]; Natale, Jonathan; 'Yakov Rekhter'; [e-mail]
Subject: RE: issue 32.1

SUMMARY:

1) we all agree that an rfc904 reference is in order.


2) EGP is already flagged as historical, and all current implementations
still support ORIGIN=EGP, so deprecating this is not that important, but I
think we already had a consensus to deprecate it.


3) I stand by my original assertion the IGP ~= route was explicitly
introduced and INCOMPLETE ~= implicitly introduced.  This reflects the
network command and the redistribute command.  This reflects a larger
percentage of implementations (aka "working code").  The current definitions
leave people scratching there heads.  The current consensus seems to be to
not change these definitions.  :-(


4) I almost agree with Curtis that adding ~= "unless configured to do so" is
going to clutter up the doc, but "configured" is already in the doc 19
times.  BGP is highly configuration dependant, get over it.  Not sure what
the consensus on this is.


-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Monday, September 30, 2002 11:43 AM
To: [e-mail]
Cc: [e-mail]; Natale, Jonathan; 'Yakov Rekhter'; [e-mail]
Subject: Re: issue 32.1

On Fri, Sep 27, 2002 at 11:51:44AM -0700, [e-mail]
wrote:
> 		  1	    EGP - Network Layer Reachability Information
> 				learned via the EGP protocol [RFC904]
> 
> That would clarify that we're talking about the protocol, and not the
> class-of-protocols, or EBGP.  It would leave unstated that this could
> theoretically be used to muck with route selection.  I think that is
> ok.  If operators want to override ORIGIN to affect some hoho magic,
> they are welcome to do so, but I don't think it needs to be documented
> in the base spec.

I'm cool with this.

> 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 MAA29696 for <[e-mail]>; Mon, 30 Sep 2002 12:33:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F133191265; Mon, 30 Sep 2002 12:33:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6D1A91266; Mon, 30 Sep 2002 12:33:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74D0B91265 for <[e-mail]>; Mon, 30 Sep 2002 12:33:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 544CB5DDBC; Mon, 30 Sep 2002 12:33:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 31A595DD95 for <[e-mail]>; Mon, 30 Sep 2002 12:33:10 -0400 (EDT)
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 MAA32344; Mon, 30 Sep 2002 12:31:23 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, Kunihiro Ishiguro <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 37 
In-reply-to: Your message of "Mon, 30 Sep 2002 11:27:56 EDT." <[e-mail]> 
Date: Mon, 30 Sep 2002 12:31:23 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> > 
> > Suggested definitions for discussion:
> > 
> >    Unfeasible route: A route which has been withdrawn can no longer be
> >      used for forwarding is referred to as an infeasible route.
> > 
>      Then why not call it withdrawn route? 
> 
>      BTW did you really mean "infeasible"?

Duh... yeah, that's what I meant.  :-}

>      Also when one says a route is unfeasible, what does it mean. 
>        a. The route is no longer reachable? 
>        b. The route has some attributes that are not usefull?
>        c. The route is temporarily put out of service with the anticipation
> it
>           will be put back in service, later? 
>        d. Also, why have it hanging around taking up space, if its not 
>           feasible?
>        e. The route is to be removed from the active routes list?
> 
>      Personnally I would use the adjective "withdrawn route" in place of
>      "unfeasible route". Keeps content simple and precise and based on the
>      (verb) action that was performed.

   1.  Storage allocation is entirely out of scope.

   2.  It may take up space if route flap damping is used to
       "remember" that the thing went up and down a lot, but that is
       out of scope.

   3.  The router might use a garbage collecting memory allocator and
       so take up space, but that is out of scope.

   4.  The definition need not enumerate all implication of the
       concept of infeasible routes.

   5.  This conversation is now bordering on the ridiculous.

> >    Withdrawn route: A route which was advertised but has more recently
> >      appeared in the unreachable section of an UPDATE message is
> >      referred to as a withdrawn route.
>      
>      This definition does not tell me anything.
> 
> >    Withdrawing a route: Putting a prefix into the unreachable section
> >      is referred to as "withdrawing" a route.
> > 
>      This definition does not tell me anything.
>  
> Ben

I'd like to ask for consensus on whether these or any definitions of
infeasible and withdrawn are needed at all.  I proposed short
definitions for discussion with the statement that I thought they were
sufficiently obvious that we don't need them.  If someone does think
we need them and that definitions I proposed are deficient, please
offer a set of definitions and we can see if there is consensus to add
them.  The consensus so far seems to be that we don't need them so
objectors please step forward with proposed definitions.

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 MAA29644 for <[e-mail]>; Mon, 30 Sep 2002 12:31:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4423F91264; Mon, 30 Sep 2002 12:30:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DCAA91266; Mon, 30 Sep 2002 12:30:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E59A091264 for <[e-mail]>; Mon, 30 Sep 2002 12:30:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 96E815DDBC; Mon, 30 Sep 2002 12:30:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id BA0285DD95 for <[e-mail]>; Mon, 30 Sep 2002 12:30:32 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA28952; Mon, 30 Sep 2002 12:30:30 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA16484; Mon, 30 Sep 2002 12:30:31 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7MMMT>; Mon, 30 Sep 2002 12:30:30 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Cc: [e-mail], "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 32.1
Date: Mon, 30 Sep 2002 12:30:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Natale:

General Comment below

> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Monday, September 30, 2002 12:25 PM
> To: 'Jeffrey Haas'; [e-mail]
> Cc: [e-mail]; Natale, Jonathan; 'Yakov Rekhter';
> [e-mail]
> Subject: RE: issue 32.1
> 
> 
> SUMMARY:
> 
> 1) we all agree that an rfc904 reference is in order.
> 
> 
> 2) EGP is already flagged as historical, and all current 
> implementations
> still support ORIGIN=EGP, so deprecating this is not that 
> important, but I
> think we already had a consensus to deprecate it.
> 
> 
> 3) I stand by my original assertion the IGP ~= route was explicitly
> introduced and INCOMPLETE ~= implicitly introduced.  This reflects the
> network command and the redistribute command.  This reflects a larger
> percentage of implementations (aka "working code").  The 
> current definitions
> leave people scratching there heads.  The current consensus 
> seems to be to
> not change these definitions.  :-(
> 
> 
> 4) I almost agree with Curtis that adding ~= "unless 
> configured to do so" is
> going to clutter up the doc, but "configured" is already in the doc 19
> times.  BGP is highly configuration dependant, get over it.  
> Not sure what
> the consensus on this is.
> 
It seems that everytime we have a problem we can't solve, we add a
configuration parameter to address it. I am in favour of trying to 
minimize the configuration parameters and maximize the correctness of 
the design.

Ben
> 
> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]] 
> Sent: Monday, September 30, 2002 11:43 AM
> To: [e-mail]
> Cc: [e-mail]; Natale, Jonathan; 'Yakov Rekhter'; 
> [e-mail]
> Subject: Re: issue 32.1
> 
> On Fri, Sep 27, 2002 at 11:51:44AM -0700, 
> [e-mail]
> wrote:
> > 		  1	    EGP - Network Layer Reachability Information
> > 				learned via the EGP protocol [RFC904]
> > 
> > That would clarify that we're talking about the protocol, 
> and not the
> > class-of-protocols, or EBGP.  It would leave unstated that 
> this could
> > theoretically be used to muck with route selection.  I think that is
> > ok.  If operators want to override ORIGIN to affect some hoho magic,
> > they are welcome to do so, but I don't think it needs to be 
> documented
> > in the base spec.
> 
> I'm cool with this.
> 
> > 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 MAA29480 for <[e-mail]>; Mon, 30 Sep 2002 12:25:06 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EC0E291263; Mon, 30 Sep 2002 12:24:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5AE691264; Mon, 30 Sep 2002 12:24:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74D5E91263 for <[e-mail]>; Mon, 30 Sep 2002 12:24:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5D6535DDB4; Mon, 30 Sep 2002 12:24:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 180C25DD95 for <[e-mail]>; Mon, 30 Sep 2002 12:24:37 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12G7C>; Mon, 30 Sep 2002 12:24:36 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Cc: [e-mail], "Natale, Jonathan" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 32.1
Date: Mon, 30 Sep 2002 12:24:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

SUMMARY:

1) we all agree that an rfc904 reference is in order.


2) EGP is already flagged as historical, and all current implementations
still support ORIGIN=EGP, so deprecating this is not that important, but I
think we already had a consensus to deprecate it.


3) I stand by my original assertion the IGP ~= route was explicitly
introduced and INCOMPLETE ~= implicitly introduced.  This reflects the
network command and the redistribute command.  This reflects a larger
percentage of implementations (aka "working code").  The current definitions
leave people scratching there heads.  The current consensus seems to be to
not change these definitions.  :-(


4) I almost agree with Curtis that adding ~= "unless configured to do so" is
going to clutter up the doc, but "configured" is already in the doc 19
times.  BGP is highly configuration dependant, get over it.  Not sure what
the consensus on this is.


-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Monday, September 30, 2002 11:43 AM
To: [e-mail]
Cc: [e-mail]; Natale, Jonathan; 'Yakov Rekhter'; [e-mail]
Subject: Re: issue 32.1

On Fri, Sep 27, 2002 at 11:51:44AM -0700, [e-mail]
wrote:
> 		  1	    EGP - Network Layer Reachability Information
> 				learned via the EGP protocol [RFC904]
> 
> That would clarify that we're talking about the protocol, and not the
> class-of-protocols, or EBGP.  It would leave unstated that this could
> theoretically be used to muck with route selection.  I think that is
> ok.  If operators want to override ORIGIN to affect some hoho magic,
> they are welcome to do so, but I don't think it needs to be documented
> in the base spec.

I'm cool with this.

> 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 MAA29328 for <[e-mail]>; Mon, 30 Sep 2002 12:20:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3AF3191262; Mon, 30 Sep 2002 12:20:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08A8D91263; Mon, 30 Sep 2002 12:20:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D858D91262 for <[e-mail]>; Mon, 30 Sep 2002 12:20:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C03235DDB9; Mon, 30 Sep 2002 12:20:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id E16775DDB4 for <[e-mail]>; Mon, 30 Sep 2002 12:20:07 -0400 (EDT)
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 MAA32266; Mon, 30 Sep 2002 12:20:01 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 8 
In-reply-to: Your message of "Mon, 30 Sep 2002 10:47:26 EDT." <[e-mail]> 
Date: Mon, 30 Sep 2002 12:20:01 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> Curtis,
> 
> So you are agreeing with the proposed change which is to add ~= "jitter may
> be applied to the ConnectRetry".  I thought we already had consensus on
> this.  Anyway, my email was merely to answer Sivananda's questions: Is
> adding a jitter to the ConnectRetry timer a standard practice? -AND-  What
> benefit does this provide?


Yes.  We agree.  Jitter should be applied to all timers.

End of discussion I hope.  Please save the discussion of who actually
implements jitter on which timer for later.

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 MAA29228 for <[e-mail]>; Mon, 30 Sep 2002 12:18:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BCABF9125C; Mon, 30 Sep 2002 12:18:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3079991262; Mon, 30 Sep 2002 12:18:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2A9E69125C for <[e-mail]>; Mon, 30 Sep 2002 12:18:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EB76B5DDBD; Mon, 30 Sep 2002 12:18:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id BB8C45DDB4 for <[e-mail]>; Mon, 30 Sep 2002 12:18:00 -0400 (EDT)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <TXPHRST8>; Mon, 30 Sep 2002 21:53:22 +0530
Message-ID: <[e-mail]>
From: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 8 
Date: Mon, 30 Sep 2002 21:50:09 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hello,

    I still don't quite understand how applying jitter (as currently defined
would help). Jitter, as per draft-17, is to be applied on a per speaker
basis, and not on a per peer basis.

    Given this, how does applying jitter on ConnectRetry timer help ?

Siva
([e-mail])


> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Monday, September 30, 2002 8:17 PM
> To: '[e-mail]'; Natale, Jonathan
> Cc: [e-mail]
> Subject: RE: issue 8 
> 
> 
> Curtis,
> 
> So you are agreeing with the proposed change which is to add 
> ~= "jitter may
> be applied to the ConnectRetry".  I thought we already had 
> consensus on
> this.  Anyway, my email was merely to answer Sivananda's questions: Is
> adding a jitter to the ConnectRetry timer a standard 
> practice? -AND-  What
> benefit does this provide?
> 
> Also, I am not sure that I agree with your statement: "does not pose
> interoperability problems".  Bringing up all the peers at once would
> possible cause a network load spike.
> 
> I also find it interesting that it is recommend to add jitter 
> all the timers
> except 1--the only 1 that actually has jitter (in most of the 
> real world)!
> In my mind, this is the one that needs jitter the most.  
> Admittedly, I do
> not have sufficient empirical evidence to support this.  But 
> the one entity
> that does, seems to have conveyed the result in the form of 
> working code.
> 
> Jonathan
> :-) 
> 
> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]] 
> Sent: Monday, September 30, 2002 9:55 AM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: issue 8 
> 
> 
> Jonathan,
> 
> As far as the BGP spec is concerned it is fine to just say that jitter
> should be applied to all timers.  Whether a particular vendor does so
> for a particular timer does not pose interoperability problems, at
> worst is very minor deficiency in an implementation, and therefore is
> irrelevant to the discussion of what should be recommended in the
> protocol spec.
> 
> Curtis
> 
> 
> In message
> <[e-mail]
> ks.com>, "Natale, Jonathan" writes:
> > It seems to me that if you bring up all bgp peers at once it
> > may lead to load spikes on the network.  Cisco seems to wait
> > 27.5 +/- 2.5 seconds for IBGP, and 40 +/- 5 seconds for
> > EBGP--20 sec. from config time to the "open active, delay"
> > jittered delay assignment plus the jittered delay (5 to 10
> > sec. for IBGP, and 15 to 25 sec. for EBGP).  This would also
> > apply for "no neighbor x.x.x.x shutdown".  Their value of
> > ConnectRetry is 60sec.  though, not sure how this value is used
> > (based on above).  Maybe some Cisco folks can chime in on
> > this one???
> > 
> > I did not check Juniper.
> > 
> > Also, interestingly, they do not apply jitter to
> > the other timers (as far as I can tell), but I don't see
> > a problem with this.
> > 
> > Another timer that they use that is not mentioned in
> > the draft/rfc is the next hop resolution timer which is 30
> > seconds.  Although it would be nice to have this in the spec,
> > I will concede that it is out of scope and/or
> > implementation dependent.
> > 
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:[e-mail]] 
> > Sent: Thursday, September 26, 2002 12:34 PM
> > To: Yakov Rekhter
> > Cc: [e-mail]; Sivananda Ramnath - CTD, Chennai.
> > Subject: Re: issue 8 
> > 
> > 
> > The TCP connection establishment timer is 75 seconds (sysctl yield
> > "net.inet.tcp.keepinit: 75000" in BSD-oids).
> > 
> > The ConnectRetry determines when to make a second attempt after a
> > prior attempt to connect has failed.  It is to avoid a rapid
> > succession of retries on immediate failures (for example "Connection
> > refused" if the peer was in the middle of a reboot, Network
> > Unreachable if you can't get there from here, etc) but also 
> covers the
> > case where the TCP SYN goes off and is never heard from again.
> > 
> > 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 MAA29050 for <[e-mail]>; Mon, 30 Sep 2002 12:12:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C9CF291260; Mon, 30 Sep 2002 12:11:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9067B91265; Mon, 30 Sep 2002 12:11:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DF56B91260 for <[e-mail]>; Mon, 30 Sep 2002 12:11:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C3B5D5DDBE; Mon, 30 Sep 2002 12:11:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 4AFFB5DDBD for <[e-mail]>; Mon, 30 Sep 2002 12:11:24 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA27880; Mon, 30 Sep 2002 12:11:18 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA11950; Mon, 30 Sep 2002 12:10:28 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7MLC1>; Mon, 30 Sep 2002 12:10:27 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Alex Zinin <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: RE: issue 11 
Date: Mon, 30 Sep 2002 12:10:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Curtis:
See below

Ben

> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Monday, September 30, 2002 11:49 AM
> To: Alex Zinin
> Cc: Yakov Rekhter; [e-mail]
> Subject: Re: issue 11 
> 
> 
> 
> In message <[e-mail]>, Alex Zinin writes:
> > Yakov,
> > 
> >   If we default to putting things in different drafts, we'll have a
> >   bunch of separate docs describing a single protocol. Multipath is
> >   something that is normally in the heart of a routing 
> protocol. There
> >   should be a good reason to want something like this in a separate
> >   document. Do we have one in this case?
> >   Thanks.
> > 
> > -- 
> > Alex
> 
> 
> Alex,
> 
> Multipath does not meet the criteria we have previously stated for
> adding something bases on the existance of implementations that
> support it.  That criteria was that the added feature was nearly
> universally implemented and deployed among the major parties and that
> implementing it or not affected interoperability.
> 
>   1.  Regardless of whether a particular router has BGP multipath
>       enabled or disabled, its external behaviour from the standpoint
>       of BGP protocol interaction is completely indistinguishable.
> 
    As a peer to a router that has multipath routing enabled, I would like
    to know that this route has a twin sister route when making my decision
    on whether to pick this route in my decision process. If I did not I
    would bet the farm on a inconsistent route (implying the AS-PATH and
other
    attributes are not always used by this route-prefix. 
    
    I disagree on this point.

    As a personnal opinion, a smart peer should stay away from Multi-path 
    routes if all rules are equal with other non-multipath routes. 
    Reasons explained in 3 below.

>   2.  In the decision process, after IGP cost is considered, some
>       (most) routers are capable of considering BGP routes of equal
>       cost for the purpose of forwarding and capable of putting more
>       than one forwarding entry (typically a small integer number of
>       entries) in the FIB.  This is entirely a local matter.
> 
>   3.  The only external sign that BGP multipath is enabled is that
>       packets are forwarded differently, but still loop free.
> 
  If packets from the same source and destination are forwarded differently
  via different Next Hops, intermittently, does'nt this opens such problems
  as sequence errors and non-deterministics forwarding behaviors. Creating 
  more confusion and latency problems at the end points? I realize this is
  a forwarding issue, but BGP is creating the issue for forwarding
  to solve.

  Because there are potential issues with multipath routing. We either add
  a dedicated section for multipath, or leave it out for now as Yakov  
  suggested.

Ben

> Therefore this feature in particular does not belong in the base spec
> and there is no need to even mention it.
> 
> Curtis
> 
> 
> > Friday, September 27, 2002, 1:34:00 PM, Yakov Rekhter wrote:
> > > Alex,
> > 
> > >> Jeff, et al
> > >> 
> > >>  I'm a little lost here. Considering that BGP multipath:
> > >> 
> > >>   - is implemented by at least two (major) vendors
> > >> 
> > >>   - affects core protocol mechanisms
> > >> 
> > >>   - is important enough to be thoroughly described
> > >>     to avoid implementation bugs
> > >> 
> > >>  why would we not want it in the base spec?
> > 
> > > Why not in a separate draft ?
> > 
> > > After all, there are quite a few *optional* BGP features that are
> > > implemented by multiple vendors, affect core protocol mechanisms,
> > > and are important enough to be thoroughly described to avoid
> > > implementation bugs, and are not in the base spec, but are in
> > > separate RFCs.
> > 
> > > Yakov.
> > 
> > >>     
> > >> -- 
> > >> Alex
> > >> 
> > >> Friday, September 27, 2002, 7:25:28 AM, Jeffrey Haas wrote:
> > >> > On Fri, Sep 27, 2002 at 07:50:10PM +0530, Sivananda 
> Ramnath - CTD, Chenn
> > ai.
> > >  wrote:
> > >> >> % The Loc-RIB SHOULD contain only one route per destination.
> > >> >> % An implementation may choose to install multiple routes to
> > >> >> % a destination (for the purposes of load balancing).
> > >> >> % An implementation doing this MUST ensure that it is
> > >> >> % interoperable with versions that do not, and MUST
> > >> >> % ensure that no routing loops or inconsistent routing
> > >> >> % information is propagated as result of this action. The
> > >> >> % handling of such a configuration, however, is outside the
> > >> >> % scope of this RFC.
> > >> >> 
> > >> >>    It does seem a little too detailed, though!
> > >> 
> > >> > My concern is not that this is rope to allow operators 
> to hang themselve
> > s
> > >> > with - this is a gatling gun that allows implementers to try to
> > >> > guess at useful rules and hose the Internet.  BGP, as 
> a protocol,
> > >> > is already prone to long-lived loops.  Lets not make 
> it easier to
> > >> > do this in a way thats harder to troubleshoot.
> > >> 
> > >> > I haven't thought about this in large amounts of 
> detail, but some
> > >> > quick observations on what could be done to actually implement
> > >> > this:
> > >> 
> > >> > o The routes should be equally preferable - i.e. they 
> need to enter
> > >> >   the tie-breaking process.
> > >> > o They should have the same AS_PATH
> > >> > o Perhaps the path attributes should only be allowed 
> to differ on
> > >> >   NEXT_HOP.
> > >> 
> > >> > *If* the above are true, then re-announcing any of the 
> routes used
> > >> > in the load-balancing should work fine as long as the 
> re-announcement
> > >> > is going to be a first-party nexthop.  If you have a 
> third-party
> > >> > nexthop, then you might end up with inconsistant forwarding.
> > >> 
> > >> > I would propose that this might be something worth 
> investing some
> > >> > time over, but it shouldn't be mentioned in the base spec.
> > >> 
> > >> >> Sivanand
> > >> 
> > >> 
> > 
> > 
> > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA28936 for <[e-mail]>; Mon, 30 Sep 2002 12:09:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5AF3591259; Mon, 30 Sep 2002 12:09:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E7339125C; Mon, 30 Sep 2002 12:09:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BA6A291259 for <[e-mail]>; Mon, 30 Sep 2002 12:09:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9AAF05DDB5; Mon, 30 Sep 2002 12:09:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 5D9275DD95 for <[e-mail]>; Mon, 30 Sep 2002 12:09:13 -0400 (EDT)
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 MAA32168; Mon, 30 Sep 2002 12:09:01 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 58 
In-reply-to: Your message of "Mon, 30 Sep 2002 10:30:25 EDT." <[e-mail]> 
Date: Mon, 30 Sep 2002 12:09:01 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Gray, Eric" writes:
> Curtis,
> 
> 	Is there any reason why "should" is not capitalized in 
> the (fourth sentence of) proposed text for 9.1.4? Also, why
> use "can not" instead of MUST NOT in the fifth and sixth 
> sentences in this proposed text (again, 9.1.4)?  I believe 
> it is not your intent to make this part non-normative, is it? 
> 
> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> [e-mail]
> 508 305 7214


Eric,

Thanks.  I missed the "should not" and the "can not".  The second
instance of "can not" just clarifies the prior sentence, in effect
providing some justification, but is not intended as a further
normative statement so I think its OK as is.  I just left that
sentence untouched.

> >    If a BGP speaker chooses to aggregate, then it SHOULD either
> >    include all AS used to form the aggreagate in an AS_SET or add the
> >    ATOMIC_AGGREGATE attribute to the route.  This attribute is now
> >    primarily informational.  With the elimination of IP routing
> >    protocols that do not support classless routing and the elimination
> >    of router and host implementations that do not support classless
> >    routing, there is no longer a need to deaggregate.  Routes should
                                                                  ^^^^^^ SHOULD
> >    not be de-aggregated.  A route that carries ATOMIC_AGGREGATE
       ^^^ NOT
> >    attribute in particular can not be de-aggregated. That is, the NLRI
                               ^^^^^^^ MUST NOT
> >    of this route can not be made more specific. Forwarding along such
> >    a route does not guarantee that IP packets will actually traverse
> >    only ASs listed in the AS_PATH attribute of the route.

Its safe to say the the only thing we want to remain normative is
"don't de-aggregate" and we've strengthenned that statement a bit to
mean "don't de-aggregate BGP under any circumstances".

Curtis



> > -----Original Message-----
> > From: Curtis Villamizar [mailto:[e-mail]]
> > Sent: Monday, September 30, 2002 10:19 AM
> > To: Yakov Rekhter
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: issue 58
> > 
> > 
> > In message <[e-mail]>, Yakov Rekhter
> > writes
> > :
> > > Curtis,
> > >
> > > > >   58) Deprication of ATOMIC_AGGREGATE
> > > > >   ------------------------------------------------------------------
> > -----
> > > --
> > > > >   Status: No Consensus
> > > > >   Change: Potentially
> > > > >   Summary: It is proposed that ATOMIC_AGGREGATE be depricated.
> > There has
> > >
> > > > >    not yet been any discussion on the proposed changes.
> > > > >
> > > > > Comments on this issue would be appreciated.
> > > > >
> > > > > In the absence of any objections to the changes proposed by Jeff,
> > the
> > > > > changes would be accepted.
> > > > >
> > > > > Yakov.
> > > >
> > > >
> > > > We used to add ATOMIC_AGGREGATE whenever the AS_PATH was truncated
> > > > rather than replaced with an AS_SET.  It was always purely
> > > > informational since no one intentionally deaggregated and reannounced.
> > > > Don't implementations still support this?
> > > >
> > > > If reality is that it is informational only, then just remove the
> > > > MUSTs and indicate that it is informational.
> > >
> > > Could you please propose the text.
> > >
> > > Yakov.
> > 
> > 
> > This existing text is fine:
> > 
> >          f) ATOMIC_AGGREGATE (Type Code 6)
> > 
> >             ATOMIC_AGGREGATE is a well-known discretionary attribute of
> >             length 0. Usage of this attribute is described in 5.1.6.
> > 
> > This is the existing text that we are considering changing:
> > 
> >   5.1.6 ATOMIC_AGGREGATE
> > 
> >    ATOMIC_AGGREGATE is a well-known discretionary attribute.
> > 
> >    When a router aggregates several routes for the purpose of
> >    advertisement to a particular peer, and the AS_PATH of the aggregated
> >    route excludes at least some of the AS numbers present in the AS_PATH
> >    of the routes that are aggregated, the aggregated route, when
> >    advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.
> > 
> >    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
> >    attribute MUST NOT remove the attribute from the route when
> >    propagating it to other speakers.
> > 
> >    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
> >    attribute MUST NOT make any NLRI of that route more specific (as
> >    defined in 9.1.4) when advertising this route to other BGP speakers.
> > 
> >    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
> >    attribute needs to be cognizant of the fact that the actual path to
> >    destinations, as specified in the NLRI of the route, while having the
> >    loop-free property, may not be the path specified in the AS_PATH
> >    attribute of the route.
> > 
> > Suuggested new text:
> > 
> >   5.1.6 ATOMIC_AGGREGATE
> > 
> >    ATOMIC_AGGREGATE is a well-known discretionary attribute.
> > 
> >    When a router aggregates several routes for the purpose of
> >    advertisement to a particular peer, the AS_PATH of the
> >    aggregated route normally includes an AS_SET formed from the set of
> >    AS from which the aggregate was formed.  In many cases the network
> >    administrator can determine that the aggregate can safely be
> >    advertised without the AS_SET and not form route loops.
> > 
> >    If an aggregate excludes at least some of the AS numbers present in
> >    the AS_PATH of the routes that are aggregated as a result of
> >    dropping the AS_SET, the aggregated route, when advertised to the
> >    peer, SHOULD include the ATOMIC_AGGREGATE attribute.
> > 
> >    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
> >    attribute SHOULD NOT remove the attribute from the route when
> >    propagating it to other speakers.
> > 
> >    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
> >    attribute MUST NOT make any NLRI of that route more specific (as
> >    defined in 9.1.4) when advertising this route to other BGP speakers.
> > 
> >    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
> >    attribute needs to be cognizant of the fact that the actual path to
> >    destinations, as specified in the NLRI of the route, while having the
> >    loop-free property, may not be the path specified in the AS_PATH
> >    attribute of the route.
> > 
> > Diffs (for reader convenience):
> > 
> > @@ -4,13 +4,19 @@
> >     ATOMIC_AGGREGATE is a well-known discretionary attribute.
> > 
> >     When a router aggregates several routes for the purpose of
> > -   advertisement to a particular peer, and the AS_PATH of the aggregated
> > -   route excludes at least some of the AS numbers present in the AS_PATH
> > -   of the routes that are aggregated, the aggregated route, when
> > -   advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.
> > +   advertisement to a particular peer, the AS_PATH of the
> > +   aggregated route normally includes an AS_SET formed from the set of
> > +   AS from which the aggregate was formed.  In many cases the network
> > +   administrator can determine that the aggregate can safely be
> > +   advertised without the AS_SET and not form route loops.
> > +
> > +   If an aggregate excludes at least some of the AS numbers present in
> > +   the AS_PATH of the routes that are aggregated as a result of
> > +   dropping the AS_SET, the aggregated route, when advertised to the
> > +   peer, SHOULD include the ATOMIC_AGGREGATE attribute.
> > 
> >     A BGP speaker that receives a route with the ATOMIC_AGGREGATE
> > -   attribute MUST NOT remove the attribute from the route when
> > +   attribute SHOULD NOT remove the attribute from the route when
> >     propagating it to other speakers.
> > 
> >     A BGP speaker that receives a route with the ATOMIC_AGGREGATE
> > 
> > 
> > Current text in 9.1.4:
> > 
> >    If a BGP speaker chooses to aggregate, then it MUST add
> >    ATOMIC_AGGREGATE attribute to the route. A route that carries
> >    ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the
> >    NLRI of this route can not be made more specific. Forwarding along
> >    such a route does not guarantee that IP packets will actually
> >    traverse only ASs listed in the AS_PATH attribute of the route.
> > 
> > Change to:
> > 
> >    If a BGP speaker chooses to aggregate, then it SHOULD either
> >    include all AS used to form the aggreagate in an AS_SET or add the
> >    ATOMIC_AGGREGATE attribute to the route.  This attribute is now
> >    primarily informational.  With the elimination of IP routing
> >    protocols that do not support classless routing and the elimination
> >    of router and host implementations that do not support classless
> >    routing, there is no longer a need to deaggregate.  Routes should
> >    not be de-aggregated.  A route that carries ATOMIC_AGGREGATE
> >    attribute in particular can not be de-aggregated. That is, the NLRI
> >    of this route can not be made more specific. Forwarding along such
> >    a route does not guarantee that IP packets will actually traverse
> >    only ASs listed in the AS_PATH attribute of the route.
> > 
> > This text in 9.2.2.2 need not change.
> > 
> >       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.
> > 
> > The appendix need not change:
> > 
> >   Appendix 1. Comparison with RFC1771
> > 
> >       [...]
> > 
> >       Clarifications to the use of the ATOMIC_AGGREGATE attribute.
> > 
> > This might be a bit more wordy that is necessary.  It does address the
> > objections to keeping ATOMIC_AGGREGATE by making the MUST into SHOULD,
> > and explaining that ATOMIC_AGGREGATE is now primarily informational.
> > 
> > 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 LAA28331 for <[e-mail]>; Mon, 30 Sep 2002 11:51:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6E8BB91261; Mon, 30 Sep 2002 11:49:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C39991262; Mon, 30 Sep 2002 11:49:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DFF7A91261 for <[e-mail]>; Mon, 30 Sep 2002 11:49:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C2D2D5DDB4; Mon, 30 Sep 2002 11:49:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 67C8B5DD95 for <[e-mail]>; Mon, 30 Sep 2002 11:49:27 -0400 (EDT)
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 LAA31775; Mon, 30 Sep 2002 11:49:17 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 11 
In-reply-to: Your message of "Fri, 27 Sep 2002 13:53:38 PDT." <[e-mail]> 
Date: Mon, 30 Sep 2002 11:49:17 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Alex Zinin writes:
> Yakov,
> 
>   If we default to putting things in different drafts, we'll have a
>   bunch of separate docs describing a single protocol. Multipath is
>   something that is normally in the heart of a routing protocol. There
>   should be a good reason to want something like this in a separate
>   document. Do we have one in this case?
>   Thanks.
> 
> -- 
> Alex


Alex,

Multipath does not meet the criteria we have previously stated for
adding something bases on the existance of implementations that
support it.  That criteria was that the added feature was nearly
universally implemented and deployed among the major parties and that
implementing it or not affected interoperability.

  1.  Regardless of whether a particular router has BGP multipath
      enabled or disabled, its external behaviour from the standpoint
      of BGP protocol interaction is completely indistinguishable.

  2.  In the decision process, after IGP cost is considered, some
      (most) routers are capable of considering BGP routes of equal
      cost for the purpose of forwarding and capable of putting more
      than one forwarding entry (typically a small integer number of
      entries) in the FIB.  This is entirely a local matter.

  3.  The only external sign that BGP multipath is enabled is that
      packets are forwarded differently, but still loop free.

Therefore this feature in particular does not belong in the base spec
and there is no need to even mention it.

Curtis


> Friday, September 27, 2002, 1:34:00 PM, Yakov Rekhter wrote:
> > Alex,
> 
> >> Jeff, et al
> >> 
> >>  I'm a little lost here. Considering that BGP multipath:
> >> 
> >>   - is implemented by at least two (major) vendors
> >> 
> >>   - affects core protocol mechanisms
> >> 
> >>   - is important enough to be thoroughly described
> >>     to avoid implementation bugs
> >> 
> >>  why would we not want it in the base spec?
> 
> > Why not in a separate draft ?
> 
> > After all, there are quite a few *optional* BGP features that are
> > implemented by multiple vendors, affect core protocol mechanisms,
> > and are important enough to be thoroughly described to avoid
> > implementation bugs, and are not in the base spec, but are in
> > separate RFCs.
> 
> > Yakov.
> 
> >>     
> >> -- 
> >> Alex
> >> 
> >> Friday, September 27, 2002, 7:25:28 AM, Jeffrey Haas wrote:
> >> > On Fri, Sep 27, 2002 at 07:50:10PM +0530, Sivananda Ramnath - CTD, Chenn
> ai.
> >  wrote:
> >> >> % The Loc-RIB SHOULD contain only one route per destination.
> >> >> % An implementation may choose to install multiple routes to
> >> >> % a destination (for the purposes of load balancing).
> >> >> % An implementation doing this MUST ensure that it is
> >> >> % interoperable with versions that do not, and MUST
> >> >> % ensure that no routing loops or inconsistent routing
> >> >> % information is propagated as result of this action. The
> >> >> % handling of such a configuration, however, is outside the
> >> >> % scope of this RFC.
> >> >> 
> >> >>    It does seem a little too detailed, though!
> >> 
> >> > My concern is not that this is rope to allow operators to hang themselve
> s
> >> > with - this is a gatling gun that allows implementers to try to
> >> > guess at useful rules and hose the Internet.  BGP, as a protocol,
> >> > is already prone to long-lived loops.  Lets not make it easier to
> >> > do this in a way thats harder to troubleshoot.
> >> 
> >> > I haven't thought about this in large amounts of detail, but some
> >> > quick observations on what could be done to actually implement
> >> > this:
> >> 
> >> > o The routes should be equally preferable - i.e. they need to enter
> >> >   the tie-breaking process.
> >> > o They should have the same AS_PATH
> >> > o Perhaps the path attributes should only be allowed to differ on
> >> >   NEXT_HOP.
> >> 
> >> > *If* the above are true, then re-announcing any of the routes used
> >> > in the load-balancing should work fine as long as the re-announcement
> >> > is going to be a first-party nexthop.  If you have a third-party
> >> > nexthop, then you might end up with inconsistant forwarding.
> >> 
> >> > I would propose that this might be something worth investing some
> >> > time over, but it shouldn't be mentioned in the base spec.
> >> 
> >> >> Sivanand
> >> 
> >> 
> 
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA28157 for <[e-mail]>; Mon, 30 Sep 2002 11:47:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 36D5991255; Mon, 30 Sep 2002 11:46:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D9B1591256; Mon, 30 Sep 2002 11:46:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 459AE91255 for <[e-mail]>; Mon, 30 Sep 2002 11:46:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4E5385DDB5; Mon, 30 Sep 2002 11:46:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 7F57C5DDB4 for <[e-mail]>; Mon, 30 Sep 2002 11:46:18 -0400 (EDT)
Received: by sentry.gw.tislabs.com; id LAA10348; Mon, 30 Sep 2002 11:46:08 -0400 (EDT)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma010336; Mon, 30 Sep 02 15:45:17 GMT
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g8UFjQk01047; Mon, 30 Sep 2002 11:45:26 -0400 (EDT)
Date: Mon, 30 Sep 2002 11:45:26 -0400 (EDT)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: Re: issue 32.1
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

I've stayed out of the fray for the most part, but I just have to ask
about one change Jonathan suggested:

> Also, change:
> "5.1.1 ORIGIN
> 
> 
>    ORIGIN is a well-known mandatory attribute.        The ORIGIN attribute
>    shall be generated by the autonomous system that originates the
>    associated routing information. It shall be included in the UPDATE
>    messages of all BGP speakers that choose to propagate this
>    information to other BGP speakers."
> 
> to:
> "5.1.1 ORIGIN
> 
>    The value of the ORIGIN attribute shall be set by the speaker
>    that originates the associated NLRI.        Its value shall not be
>    changed by any other speaker unless the other speaker is
>    administratively configured to do so to affect policy
>    decisions."

I imagine that features in a spec should be subject to compliance testing,
that is, it should be possible to externally test an implementation to
see if it followed the spec.

So what sort of compliance testing could verify that an implementation
that changed the ORIGIN did so because it was "administratively configured
to do so", much less "administratively configured to do so to affect policy
decisions"?

--Sandy


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA28067 for <[e-mail]>; Mon, 30 Sep 2002 11:44:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E8E6E9125F; Mon, 30 Sep 2002 11:43:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B21BD91256; Mon, 30 Sep 2002 11:43:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9650F91255 for <[e-mail]>; Mon, 30 Sep 2002 11:43:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6B7525DDB5; Mon, 30 Sep 2002 11:43:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id A68575DD95 for <[e-mail]>; Mon, 30 Sep 2002 11:43:30 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8UFhF954963; Mon, 30 Sep 2002 11:43:15 -0400 (EDT) (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 g8UFh4G54927; Mon, 30 Sep 2002 11:43:04 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8UFh4u25667; Mon, 30 Sep 2002 11:43:04 -0400 (EDT)
Date: Mon, 30 Sep 2002 11:43:04 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail], "Natale, Jonathan" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: Re: issue 32.1
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
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Sep 27, 2002 at 11:51:44AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Sep 27, 2002 at 11:51:44AM -0700, [e-mail] wrote:
> 		  1	    EGP - Network Layer Reachability Information
> 				learned via the EGP protocol [RFC904]
> 
> That would clarify that we're talking about the protocol, and not the
> class-of-protocols, or EBGP.  It would leave unstated that this could
> theoretically be used to muck with route selection.  I think that is
> ok.  If operators want to override ORIGIN to affect some hoho magic,
> they are welcome to do so, but I don't think it needs to be documented
> in the base spec.

I'm cool with this.

> 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 LAA27503 for <[e-mail]>; Mon, 30 Sep 2002 11:28:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 880DB91250; Mon, 30 Sep 2002 11:28:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57BD891253; Mon, 30 Sep 2002 11:28:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 418C491250 for <[e-mail]>; Mon, 30 Sep 2002 11:28:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 277C35DDB8; Mon, 30 Sep 2002 11:28:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id A92245DDB5 for <[e-mail]>; Mon, 30 Sep 2002 11:28:00 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25034; Mon, 30 Sep 2002 11:27:58 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03923; Mon, 30 Sep 2002 11:27:59 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7MJDM>; Mon, 30 Sep 2002 11:27:58 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, Kunihiro Ishiguro <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Subject: RE: issue 37 
Date: Mon, 30 Sep 2002 11:27:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Curtis,

see below

> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Monday, September 30, 2002 11:01 AM
> To: Abarbanel, Benjamin
> Cc: '[e-mail]'; Kunihiro Ishiguro; 
> Yakov Rekhter;
> [e-mail]
> Subject: Re: issue 37 
> 
> 
> 
> In message 
> <[e-mail]>, 
> "Abarbanel, Benjamin" writes:
> > My opinion to this question, if such terms as "withdrawn routes" and
> > "unfeasable routes" are used multiple times as either 
> verbs, adjectives, and
> > nouns interchangeably, then it would be wise to define them 
> in the "commonly
> > used terms" section. If they are used only in one mode in a 
> few places, then
> > as Yakov stated its OK to let the local useage define the meaning.
> > 
> > Ben
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]
> > > Sent: Friday, September 27, 2002 3:28 PM
> > > To: Kunihiro Ishiguro
> > > Cc: Yakov Rekhter; [e-mail]
> > > Subject: Re: issue 37
> > > 
> > > 
> > > To address the concern in the original post:  Do we want to add a 
> > > definition of "Unfeasable Routes" to the glossary/list of 
> frequently
> > > used terms?
> > > 
> > > Andrew
> > > 
> > > On Thu, Sep 26, 2002 at 10:05:53AM -0700, Kunihiro Ishiguro wrote:
> > > > Delivered-To: [e-mail]
> > > > Delivered-To: [e-mail]
> > > > Delivered-To: [e-mail]
> > > > Date: Thu, 26 Sep 2002 10:05:53 -0700
> > > > From: Kunihiro Ishiguro <[e-mail]>
> > > > To: Yakov Rekhter <[e-mail]>
> > > > Cc: [e-mail]
> > > > Subject: Re: issue 37 
> > > > In-Reply-To: <[e-mail]>
> > > > User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 
> > > (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 
> > > Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI)
> > > > Precedence: bulk
> > > > X-OriginalArrivalTime: 26 Sep 2002 17:06:04.0179 (UTC) 
> > > FILETIME=[FF35B630:01C2657E]
> > > > 
> > > > Thanks for clear explanation.  I'm convinced.
> > > > 
> > > > >> 
> > > >-------------------------------------------------------------
> > > ---------------
> > > > >> >37) Combine "Unfeasable Routes" and "Withdrawn Routes"
> > > > >> 
> > > >-------------------------------------------------------------
> > > ---------------
> > > > >> >Status: No Consensus
> > > > >> >Change: Potentially
> > > > >> >Summary: No definition extant for "Unfeasable Routes". 
> > > > >> >
> > > > >> >Discussion:
> > > > >> >
> > > > >> >3. P. 45, Phase I, There is no definition of what are 
> > > unfeasible routes? Are
> > > > >> >they the same as withdrawn routes? If so, the two 
> > > should be combined to one
> > > > >> >name.
> > > > >> 
> > > > >> >From implementation stand point there is no 
> difference between
> > > > >> "Unfeasible Routes" and "Withdrawn Routes".  When 
> the route is
> > > > >> unfeasible, BGP withdraw the route.  I think combining 
> > > two name to one
> > > > >> name make sense.
> > > > >
> > > > >The routes are withdrawn from service because they are 
> unfeasible,
> > > > >not because they are "withdrawn". So, we need to keep the term
> > > > >"unfeasible" to indicate the *reason* why a route could be 
> > > withdrawn.
> > > > >On the other hand, "withdrawn" is used as a verb, and 
> to the best
> > > > >of my knowledge "unfeasible" can't be used as a verb.  
> With this
> > > > >in mind, I don't think that we can combine the two 
> into a single
> > > > >term.
> > > 
> > 
> 
> 
> 
> Suggested definitions for discussion:
> 
>    Unfeasible route: A route which has been withdrawn can no longer be
>      used for forwarding is referred to as an infeasible route.
> 
     Then why not call it withdrawn route? 

     BTW did you really mean "infeasible"?

     Also when one says a route is unfeasible, what does it mean. 
       a. The route is no longer reachable? 
       b. The route has some attributes that are not usefull?
       c. The route is temporarily put out of service with the anticipation
it
          will be put back in service, later? 
       d. Also, why have it hanging around taking up space, if its not 
          feasible?
       e. The route is to be removed from the active routes list?

     Personnally I would use the adjective "withdrawn route" in place of
     "unfeasible route". Keeps content simple and precise and based on the
     (verb) action that was performed.

>    Withdrawn route: A route which was advertised but has more recently
>      appeared in the unreachable section of an UPDATE message is
>      referred to as a withdrawn route.
     
     This definition does not tell me anything.

>    Withdrawing a route: Putting a prefix into the unreachable section
>      is referred to as "withdrawing" a route.
> 
     This definition does not tell me anything.
 
Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA27404 for <[e-mail]>; Mon, 30 Sep 2002 11:25:25 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 94D979122C; Mon, 30 Sep 2002 11:25:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5EA6591250; Mon, 30 Sep 2002 11:25:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E10E09122C for <[e-mail]>; Mon, 30 Sep 2002 11:25:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B54385DDBA; Mon, 30 Sep 2002 11:25:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id F042D5DDB9 for <[e-mail]>; Mon, 30 Sep 2002 11:25:01 -0400 (EDT)
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 LAA31572; Mon, 30 Sep 2002 11:24:50 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 32.1 
In-reply-to: Your message of "Wed, 25 Sep 2002 14:28:03 EDT." <[e-mail]> 
Date: Mon, 30 Sep 2002 11:24:50 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> 1) It is wrong because Network Layer Reachability Information is ALWAYS
> interior to the originating AS.  What would be the "other means"???  Anyway,
> this is certainly not the current use.
> 
> 2) "network cmd" nor "redistribute" is mentioned in the proposed change
> 
> 3) 32.1 is not significantly related to 32.2
> 
> 4) I have personally witnessed many people confusing EGP with EBGP.
> 
> I stand by my proposal (which was supported by at least one other as I
> recall):
> 
> Old:
> 
>             "ORIGIN is a well-known mandatory attribute that defines the
>             origin of the path information.  The data octet can assume
>             the following values:
> 
>                   Value		Meaning
> 
>                   0	    IGP - Network Layer Reachability Information
>                                is interior to the originating AS
> 
>                   1	    EGP - Network Layer Reachability Information
>                                learned via the EGP protocol
> 
>                   2	    INCOMPLETE - Network Layer Reachability
>                                Information learned by some other means"
> New:
> 
>             "ORIGIN is a well-known mandatory attribute that defines the
>             origin of the path information.  The data octet can assume
>             the following values:
> 
>                   Value		Meaning
> 
>                   0	    IGP - NLRI was explicitly introduced into bgp
> 
>                   1	    EGP - this value was administratively
>                                configured to affect policy decisions or
>                                NLRI was learned via the EGP protocol [1]
> 
>                   2	    INCOMPLETE - NLRI was implicitly introduced
>                                       into bgp"
> ...
> "[1] RFC904
> since:
> 1) The network command sets the origin to IGP and I remember seeing
> somewhere that only static routes should be set to IGP.
> 2) The primary use of EGP value is policy
> 3) EGP seems to still exist, anyway even if it does not it is
> not worth re-writing the world.
> 
> Also, change:
> "5.1.1 ORIGIN
> 
> 
>    ORIGIN is a well-known mandatory attribute.	The ORIGIN attribute
>    shall be generated by the autonomous system that originates the
>    associated routing information. It shall be included in the UPDATE
>    messages of all BGP speakers that choose to propagate this
>    information to other BGP speakers."
> 
> to:
> "5.1.1 ORIGIN
> 
>    The value of the ORIGIN attribute shall be set by the speaker
>    that originates the associated NLRI.	 Its value shall not be
>    changed by any other speaker unless the other speaker is
>    administratively configured to do so to affect policy
>    decisions."
> 
> since:
> 1) It is already defined as well-known mandatory attribute.
> 2) It may be set differently within the same AS (not saying this is good).
> 3) It is commonly used for policy, but by default does not get changed.
> 4) Speakers have no choice, it is mandatory.
> 
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Wednesday, September 25, 2002 1:43 PM
> To: [e-mail]
> Subject: issue 32
> 
>   32) Clarify EGP Reference
>  
> ----------------------------------------------------------------------------
>   Status: No Consensus
>   Change: Potentially
>   Summary: Need to clarify the EGP Reference, since there seems to be some
>     confusion on the issue.
>   
>   Discussion:
>   
>   3. P. 13, EGP, are there other EGP protocols other than BGP that are in
> use?
>   If not, change EGP to BGP.
>   
>   A response to this suggested that we add a reference to [1] (the EGP
>   spec) here.
> 
> This will be address as part of the response to issue 9
>   
>   Another reponse clarified that this refers to EGP-the-protocol and
>   NOT the class.
>   
>   Another response disagreed, but suggested that:
>   
>   IGP = network was explicitly introduced into bgp (network cmd)
>   INCOMPLETE = network was implicitly introduced into bgp (redistribute)
>   EGP = other
> 
> I've yet to understand what is incorrect with the current text.
> I also think that talking about "network cmd" and "redistribute"
> makes it a bit vendor specific. Therefore, I think we should keep
> the current text.
>   
>   The original commentor thought that this refered to EGP-the-class of
>   protocols.   And why not use BGP therefore, as the only EGP.
>   
>   There was some disucssion over whether or not we should mention something
>   that is historical.
> 
> I don't think that the BGP base spec needs to talk about the status
> of EGP spec [RFC904].
>   
>   Jeff suggested a footnote in the Origin section about EGP.
>   
>   Curtis suggested that we state that the EGP in ORIGIN is depricated,
>   but retain the value to document what it used to mean.
>   
>   This reviewer thinks a statement about whether this "EGP" origin refers
>   to the protocol or the class or protocols would be useful.
> 
> >From the context it should be clear that we are talking about "the EGP"
> (means [RFC904]).
> 
> Yakov.
> 


How about if we just make the simple change:

                  1         EGP - Network Layer Reachability Information
                               learned via the EGP protocol

to

                  1         EGP - Network Layer Reachability Information
                               learned via the EGP protocol [1]

Administratively setting the ORIGIN is a "preference of last resort"
hack.  This won't encourage the practice but it won't prevent anyone
from allowing this deviation from the protocol or using it.

[btw - Jonathan's suggestion completely changes the meaning of this
ORIGIN code.  If we wanted to change the meaning because there was a
need, we should just make up a new attribute which fits into the route
selection where ORIGIN goes and make it an integer value to allow
degrees of "preference of last resort" rather than just one "less
prefered" value but we are not changing BGP in this way.  This of
course opens the "inconsistent route selection between implementations
of different vintage" can-o-worms.]

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 LAA26598 for <[e-mail]>; Mon, 30 Sep 2002 11:01:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 41B089124C; Mon, 30 Sep 2002 11:01:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EEF0C9122C; Mon, 30 Sep 2002 11:01:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DD4579124C for <[e-mail]>; Mon, 30 Sep 2002 11:01:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 60A215DDB2; Mon, 30 Sep 2002 11:01:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 588865DDB3 for <[e-mail]>; Mon, 30 Sep 2002 11:01:30 -0400 (EDT)
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 LAA31298; Mon, 30 Sep 2002 11:01:15 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, Kunihiro Ishiguro <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 37 
In-reply-to: Your message of "Fri, 27 Sep 2002 15:50:00 EDT." <[e-mail]> 
Date: Mon, 30 Sep 2002 11:01:15 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> My opinion to this question, if such terms as "withdrawn routes" and
> "unfeasable routes" are used multiple times as either verbs, adjectives, and
> nouns interchangeably, then it would be wise to define them in the "commonly
> used terms" section. If they are used only in one mode in a few places, then
> as Yakov stated its OK to let the local useage define the meaning.
> 
> Ben
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > Sent: Friday, September 27, 2002 3:28 PM
> > To: Kunihiro Ishiguro
> > Cc: Yakov Rekhter; [e-mail]
> > Subject: Re: issue 37
> > 
> > 
> > To address the concern in the original post:  Do we want to add a 
> > definition of "Unfeasable Routes" to the glossary/list of frequently
> > used terms?
> > 
> > Andrew
> > 
> > On Thu, Sep 26, 2002 at 10:05:53AM -0700, Kunihiro Ishiguro wrote:
> > > Delivered-To: [e-mail]
> > > Delivered-To: [e-mail]
> > > Delivered-To: [e-mail]
> > > Date: Thu, 26 Sep 2002 10:05:53 -0700
> > > From: Kunihiro Ishiguro <[e-mail]>
> > > To: Yakov Rekhter <[e-mail]>
> > > Cc: [e-mail]
> > > Subject: Re: issue 37 
> > > In-Reply-To: <[e-mail]>
> > > User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 
> > (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 
> > Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI)
> > > Precedence: bulk
> > > X-OriginalArrivalTime: 26 Sep 2002 17:06:04.0179 (UTC) 
> > FILETIME=[FF35B630:01C2657E]
> > > 
> > > Thanks for clear explanation.  I'm convinced.
> > > 
> > > >> 
> > >-------------------------------------------------------------
> > ---------------
> > > >> >37) Combine "Unfeasable Routes" and "Withdrawn Routes"
> > > >> 
> > >-------------------------------------------------------------
> > ---------------
> > > >> >Status: No Consensus
> > > >> >Change: Potentially
> > > >> >Summary: No definition extant for "Unfeasable Routes". 
> > > >> >
> > > >> >Discussion:
> > > >> >
> > > >> >3. P. 45, Phase I, There is no definition of what are 
> > unfeasible routes? Are
> > > >> >they the same as withdrawn routes? If so, the two 
> > should be combined to one
> > > >> >name.
> > > >> 
> > > >> >From implementation stand point there is no difference between
> > > >> "Unfeasible Routes" and "Withdrawn Routes".  When the route is
> > > >> unfeasible, BGP withdraw the route.  I think combining 
> > two name to one
> > > >> name make sense.
> > > >
> > > >The routes are withdrawn from service because they are unfeasible,
> > > >not because they are "withdrawn". So, we need to keep the term
> > > >"unfeasible" to indicate the *reason* why a route could be 
> > withdrawn.
> > > >On the other hand, "withdrawn" is used as a verb, and to the best
> > > >of my knowledge "unfeasible" can't be used as a verb.  With this
> > > >in mind, I don't think that we can combine the two into a single
> > > >term.
> > 
> 



Suggested definitions for discussion:

   Unfeasible route: A route which has been withdrawn can no longer be
     used for forwarding is referred to as an infeasible route.

   Withdrawn route: A route which was advertised but has more recently
     appeared in the unreachable section of an UPDATE message is
     referred to as a withdrawn route.

   Withdrawing a route: Putting a prefix into the unreachable section
     is referred to as "withdrawing" a route.

The normal rules for use of a verb apply resulting in valid phrases
such as "after a route is withdrawn" or "the route must then be
withdrawn".  I hope we don't have to add them to the glossary as well.

My personal preference is that we omit these definitions on the
grounds that our usage conforms exactly to normal usage of the english
language words "unfeasible", "withdrawn" and "withdrawing" when
applied to the noun "route" and therefore need not be defined.  The
mechanism of withdrawing routes is very clearly stated elsewhere.

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 KAA26329 for <[e-mail]>; Mon, 30 Sep 2002 10:54:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 670529124A; Mon, 30 Sep 2002 10:53:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 34B349124C; Mon, 30 Sep 2002 10:53:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2CB369124A for <[e-mail]>; Mon, 30 Sep 2002 10:53:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 070285DDB2; Mon, 30 Sep 2002 10:53:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 439E95DDA2 for <[e-mail]>; Mon, 30 Sep 2002 10:53:44 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8UErfx53510; Mon, 30 Sep 2002 10:53:41 -0400 (EDT) (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 g8UErcG53503; Mon, 30 Sep 2002 10:53:38 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8UErcj25103; Mon, 30 Sep 2002 10:53:38 -0400 (EDT)
Date: Mon, 30 Sep 2002 10:53:38 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: Re: issue 10
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, Sep 30, 2002 at 08:57:43AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Sep 30, 2002 at 08:57:43AM -0400, Natale, Jonathan wrote:
> Ok.  So we have consensus on:
> "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 speaker may choose not to advertise the route to its
> peers and may choose to log an error locally."  

If it *may* choosen not to advertise, that doesn't mean *must*.

If its going to advertise things, how is it going to behave?

-- 
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 KAA26171 for <[e-mail]>; Mon, 30 Sep 2002 10:48:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 68ED291226; Mon, 30 Sep 2002 10:48:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B87E9124A; Mon, 30 Sep 2002 10:48:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 22BCF91226 for <[e-mail]>; Mon, 30 Sep 2002 10:47:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E62FC5DDA2; Mon, 30 Sep 2002 10:47:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 091DA5DD9B for <[e-mail]>; Mon, 30 Sep 2002 10:47:35 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12GNZ>; Mon, 30 Sep 2002 10:47:34 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 8 
Date: Mon, 30 Sep 2002 10:47:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Curtis,

So you are agreeing with the proposed change which is to add ~= "jitter may
be applied to the ConnectRetry".  I thought we already had consensus on
this.  Anyway, my email was merely to answer Sivananda's questions: Is
adding a jitter to the ConnectRetry timer a standard practice? -AND-  What
benefit does this provide?

Also, I am not sure that I agree with your statement: "does not pose
interoperability problems".  Bringing up all the peers at once would
possible cause a network load spike.

I also find it interesting that it is recommend to add jitter all the timers
except 1--the only 1 that actually has jitter (in most of the real world)!
In my mind, this is the one that needs jitter the most.  Admittedly, I do
not have sufficient empirical evidence to support this.  But the one entity
that does, seems to have conveyed the result in the form of working code.

Jonathan
:-) 

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Monday, September 30, 2002 9:55 AM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: issue 8 


Jonathan,

As far as the BGP spec is concerned it is fine to just say that jitter
should be applied to all timers.  Whether a particular vendor does so
for a particular timer does not pose interoperability problems, at
worst is very minor deficiency in an implementation, and therefore is
irrelevant to the discussion of what should be recommended in the
protocol spec.

Curtis


In message
<[e-mail]
ks.com>, "Natale, Jonathan" writes:
> It seems to me that if you bring up all bgp peers at once it
> may lead to load spikes on the network.  Cisco seems to wait
> 27.5 +/- 2.5 seconds for IBGP, and 40 +/- 5 seconds for
> EBGP--20 sec. from config time to the "open active, delay"
> jittered delay assignment plus the jittered delay (5 to 10
> sec. for IBGP, and 15 to 25 sec. for EBGP).  This would also
> apply for "no neighbor x.x.x.x shutdown".  Their value of
> ConnectRetry is 60sec.  though, not sure how this value is used
> (based on above).  Maybe some Cisco folks can chime in on
> this one???
> 
> I did not check Juniper.
> 
> Also, interestingly, they do not apply jitter to
> the other timers (as far as I can tell), but I don't see
> a problem with this.
> 
> Another timer that they use that is not mentioned in
> the draft/rfc is the next hop resolution timer which is 30
> seconds.  Although it would be nice to have this in the spec,
> I will concede that it is out of scope and/or
> implementation dependent.
> 
> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]] 
> Sent: Thursday, September 26, 2002 12:34 PM
> To: Yakov Rekhter
> Cc: [e-mail]; Sivananda Ramnath - CTD, Chennai.
> Subject: Re: issue 8 
> 
> 
> In message <[e-mail]>, Yakov Rekhter
> writes
> :
> > forwarding...
> > ------- Forwarded Message
> > 
> > Date:    Thu, 26 Sep 2002 16:58:19 +0530
> > From:    "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
> > To:      Yakov Rekhter <[e-mail]>
> > Subject: FW: issue 8
> > 
> > Hello,
> > 
> >     My mail does not seem to have made it to the list. Could you please
> > forward it ?
> > 
> > Thanks,
> > Siva
> > ([e-mail])
> > 
> > - -----Original Message-----
> > From: Sivananda Ramnath - CTD, Chennai. 
> > Sent: Thursday, September 26, 2002 3:21 PM
> > To: [e-mail]
> > Subject: RE: issue 8
> > 
> > 
> > Hello,
> > 
> >     The ConnectRetry timer is should have a value that is 'sufficiently
> > large to allow TCP initialization. Application of jitter can reduce the
> this
> > value (by up to 25%). A configuration which the ConnectRetry timer has
> been
> > pegged at a value close to TCP connection time may cause a connection to
> be
> > terminated as a result of this jitter. Is this a cause for concern ? 
> > 
> >     The default value suggested for ConnectRetry (120 seconds) is
> > sufficiently large that event with a jitter of 0.75, it will be greater
> than
> TCP'c connection establishment timer.
> > 
> >     Is adding a jitter to the ConnectRetry timer a standard practice ?
> What
> > benefit does this provide ?
> > 
> > Sivanand
> > ([e-mail])
> 
> 
> The TCP connection establishment timer is 75 seconds (sysctl yield
> "net.inet.tcp.keepinit: 75000" in BSD-oids).
> 
> The ConnectRetry determines when to make a second attempt after a
> prior attempt to connect has failed.  It is to avoid a rapid
> succession of retries on immediate failures (for example "Connection
> refused" if the peer was in the middle of a reboot, Network
> Unreachable if you can't get there from here, etc) but also covers the
> case where the TCP SYN goes off and is never heard from again.
> 
> 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 KAA25666 for <[e-mail]>; Mon, 30 Sep 2002 10:33:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1BA3091254; Mon, 30 Sep 2002 10:32:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD85891256; Mon, 30 Sep 2002 10:32:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B69B91254 for <[e-mail]>; Mon, 30 Sep 2002 10:32:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 309635DDA2; Mon, 30 Sep 2002 10:32:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 1F5605DD9B for <[e-mail]>; Mon, 30 Sep 2002 10:32:14 -0400 (EDT)
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 KAA30997; Mon, 30 Sep 2002 10:31:45 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Tom Petch" <[e-mail]>
Cc: [e-mail], "Natale,     Jonathan" <[e-mail]>, "Yakov Rekhter" <[e-mail]>, "Alex Zinin" <[e-mail]>, "Abarbanel,     Benjamin" <[e-mail]>, "idr" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Generial Editorial Comment 
In-reply-to: Your message of "Thu, 26 Sep 2002 19:50:11 BST." <030b01c2658d$b538fc40$0301a8c0@tom3> 
Date: Mon, 30 Sep 2002 10:31:45 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <030b01c2658d$b538fc40$0301a8c0@tom3>, "Tom Petch" writes:
> I take issue with the 'will attempt to connect' which goes too far.
> 
> The FSM defines events 4 and 5, 'with passive Transport
> establishment', so the system may wait and not attempt to connect.
> The exit from this state is either the receipt of an incoming TCP
> connection (SYN) or timer expiry.
> 
> So we may have a FSM attempting to transport connect for a given
> source/destination IP pair or we may have an FSM not attempting to
> connect.  (In the latter case, I do not think we can get a collision).
> In the latter case, an incoming connection should not generate an
> additional FSM.
> 
> I do not believe the concept of active and passive is helpful since a
> given system can flip from one to the other and it does not help us to
> clarify the number of FSM involved..
> 
> Tom Petch
> [e-mail]


Could this be corrected by replacing "will attempt to connect" with
"unless configured to remain in the idle state, or configured to
remain passive, will attempt to connect".  We could also shorten that
to "will attempt to connect unless configured otherwise".

Clarification (perhaps an item for a glossary entry):

  The terms active and passive have been in our vocabulary for almost
  a decade and have proven useful.  The words active and passive have
  slightly different meanings applied to a TCP connection or applied
  to a peer.  There is only one active side and one passive side to
  any one TCP connection as per the definition below.  When a BGP
  speaker is configured passive it will never attempt to connect.  If
  a BGP speaker is configured active it may end up on either the
  active or passive side of the connection that eventually gets
  established.  Once the TCP connection is completed, it doesn't
  matter which end was active and which end was passive and the only
  difference is which side of the TCP connection has port number 179.

We're going to make this a very long document if we add "unless
configured otherwise" to hundreds of places in the document just to
make it absolutely correct.  Maybe we should issue a moritorium on
"unless configured otherwise" changes.  :-)

Curtis


> -----Original Message-----
> From: Curtis Villamizar <[e-mail]>
> To: Natale, Jonathan <[e-mail]>
> Cc: '[e-mail]' <[e-mail]>; Yakov Rekhter
> <[e-mail]>; Alex Zinin <[e-mail]>; Abarbanel, Benjamin
> <[e-mail]>; [e-mail] <[e-mail]>
> Date: 26 September 2002 18:27
> Subject: Re: Generial Editorial Comment
> 
> 
> >
> >In message
> <[e-mail]
> >ks.com>, "Natale, Jonathan" writes:
> >> Wrong.
> >>
> >> " If the source IP address used
> >>    by one of these connections is the same as the destination IP
> address
> >>    used by the other, and the destination IP address used by the
> first
> >>    connection is the same as the source IP address used by the
> other, we
> >>    refer to this situation as connection collision."
> >> - draft-ietf-idr-bgp4-17
> >
> >You're correct in that you must have a collision of IP addresses on
> >the TCP connections and that the BGP Identifier is used only to
> >resolve which gets dropped.
> >
> >The FSM stays around as long as "BGP Identifier" is not known.
> >Replace "not known with certainty" with "known but the BGP identifier
> >is not known" and replace "for the same peer" with "for the same
>configured peering".
> >
> >The first paragraph is unchanged:
> >
> >   BGP must maintain separate FSM for each configured peer.  Each BGP
> >   peer paired in a potential connection will atempt to connect to
> the
> >   other.  For the purpose of this discussions, the active or connect
> >   side of a TCP connection (the side sending the first TCP SYN
> packet)
> >   is called outgoing.  The passive or listenning side (the sender of
> >   the first SYN ACK) is called the an incoming connection.
> >
> >The second paragraph becomes:
> >
> >   A BGP implementation must connect to and listen on TCP port 179
> for
> >   incoming connections in addition to trying to connect to peers.
> >   For each incoming connection, a state machine must be
> instantiated.
> >   There exists a period in which the identity of the peer on the
> >   other end of an incoming connection is known but the BGP
> identifier
> >   is not known.  During this time, both an incoming and outgoing
> >   connection for the same configured peering may exist.  This is
> >   referred to as a connection collision (see Section x.x, was 6.8).
> >
> >The next paragraph then needs to get fixed.  Changed "for each peer"
> >to "for each configured peering".
> >
> >   A BGP implementation will have at most one FSM for each configured
> >   peering plus one FSM for each incoming TCP connection for which
> the
> >   peer has not yet been identified.  Each FSM corresponds to exactly
> >   one TCP connection.
> >
> >Add a paragraph to further clarify the point you made.
> >
> >   There may be more than one connection between a pair of peers if
> >   the connections are configured to use a different pair of IP
> >   addresses.  This is referred to as multiple "configured peerings"
> >   to the same peer.
> >
> >> So multiple simultaneous BGP connection are allowed between the
> same two
> >> peers, and this behavior is implemented, for example to do load
> balancing.
> >
> >Good point.
> >
> >I hope the corrections above cover your (entirely valid) objections.
> >If you see any more errors please let me know.
> >
> >Curtis
> >
> >
> >> -----Original Message-----
> >> From: Curtis Villamizar [mailto:[e-mail]]
> >> Sent: Thursday, September 26, 2002 11:34 AM
> >> To: Yakov Rekhter
> >> Cc: Alex Zinin; Abarbanel, Benjamin; [e-mail]
> >> Subject: Re: Generial Editorial Comment
> >>
> >>
> >> In message <[e-mail]>, Yakov
> Rekhter
> >> writes
> >> :
> >> > Alex,
> >> >
> >> > > Defining terms like this in a separate section would be really
> nice.
> >> > > (BTW, I personally think using "BGP session" which works over a
> "TCP
> >> > > connection" would be closer to the terminology we're actually
> using
> >> > > now and would avoid possible confusions when people read terms
> like
> >> > > "Connection collision") It would also be great if we had
> descriptions
> >> > > for all data structures that are not explicitly defined (e.g.,
> the
> >> > > current spec has no notion of a peer data structure), timers,
> etc.
> >> > >
> >> > > Two other things that I think would make sense to explicitly
> >> > > define are
> >> > >
> >> > >    - processing of incoming TCP connections (peer lookup,
> acceptance,
> >> > >      FSM creation, collision control,)
> >> > >
> >> > >    - generation of events while processing BGP messages, i.e.,
> >> > >      the text describing message processing should say where
> >> > >      needed that a specific event for the BGP session should
> >> > >      be generated.
> >> >
> >> > Please suggest the appropriate text.
> >> >
> >> > yakov.
> >>
> >>
> >>
> >> Yakov,
> >>
> >> Here is some suggestion.  I don't know where in the document you'd
> >> like to put this or whether you would prefer to omit it.  That's up
> to
> >> you.
> >>
> >>   BGP must maintain separate FSM for each configured peer.  Each
> BGP
> >>   peer paired in a potential connection will atempt to connect to
> the
> >>   other.  For the purpose of this discussions, the active or
> connect
> >>   side of a TCP connection (the side sending the first TCP SYN
> packet)
> >>   is called outgoing.  The passive or listenning side (the sender
> of
> >>   the first SYN ACK) is called the an incoming connection.
> >>
> >>   A BGP implementation must connect to and listen on TCP port 179
> for
> >>   incoming connections in addition to trying to connect to peers.
> For
> >>   each incoming connection, a state machine must be instantiated.
> >>   There exists a period in which the identity of the peer on the
> other
> >>   end of an incoming connection is not known with certainty.
> During
> >>   this time, both an incoming and outgoing connection for the same
> >>   peer may exist.  This is referred to as a connection collision
> (see
> >>   Section x.x, was 6.8).
> >>
> >>   A BGP implementation will have at most one FSM for each peer plus
> >>   one FSM for each incoming TCP connection for which the peer has
> not
> >>   yet been identified.  Each FSM corresponds to exactly one TCP
> >>   connection.
> >>
> >> The above covers Alex's first request only.
> >>
> >> 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 KAA25560 for <[e-mail]>; Mon, 30 Sep 2002 10:31:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2D5D891249; Mon, 30 Sep 2002 10:30:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1DCA9124C; Mon, 30 Sep 2002 10:30:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8058691249 for <[e-mail]>; Mon, 30 Sep 2002 10:30:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 34CA65DDA2; Mon, 30 Sep 2002 10:30:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 384305DD9B for <[e-mail]>; Mon, 30 Sep 2002 10:30:34 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12GLS>; Mon, 30 Sep 2002 10:30:33 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 58 
Date: Mon, 30 Sep 2002 10:30:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Curtis,

	Is there any reason why "should" is not capitalized in 
the (fourth sentence of) proposed text for 9.1.4? Also, why
use "can not" instead of MUST NOT in the fifth and sixth 
sentences in this proposed text (again, 9.1.4)?  I believe 
it is not your intent to make this part non-normative, is it? 

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Monday, September 30, 2002 10:19 AM
> To: Yakov Rekhter
> Cc: [e-mail]; [e-mail]
> Subject: Re: issue 58
> 
> 
> In message <[e-mail]>, Yakov Rekhter
> writes
> :
> > Curtis,
> >
> > > >   58) Deprication of ATOMIC_AGGREGATE
> > > >   ------------------------------------------------------------------
> -----
> > --
> > > >   Status: No Consensus
> > > >   Change: Potentially
> > > >   Summary: It is proposed that ATOMIC_AGGREGATE be depricated.
> There has
> >
> > > >    not yet been any discussion on the proposed changes.
> > > >
> > > > Comments on this issue would be appreciated.
> > > >
> > > > In the absence of any objections to the changes proposed by Jeff,
> the
> > > > changes would be accepted.
> > > >
> > > > Yakov.
> > >
> > >
> > > We used to add ATOMIC_AGGREGATE whenever the AS_PATH was truncated
> > > rather than replaced with an AS_SET.  It was always purely
> > > informational since no one intentionally deaggregated and reannounced.
> > > Don't implementations still support this?
> > >
> > > If reality is that it is informational only, then just remove the
> > > MUSTs and indicate that it is informational.
> >
> > Could you please propose the text.
> >
> > Yakov.
> 
> 
> This existing text is fine:
> 
>          f) ATOMIC_AGGREGATE (Type Code 6)
> 
>             ATOMIC_AGGREGATE is a well-known discretionary attribute of
>             length 0. Usage of this attribute is described in 5.1.6.
> 
> This is the existing text that we are considering changing:
> 
>   5.1.6 ATOMIC_AGGREGATE
> 
>    ATOMIC_AGGREGATE is a well-known discretionary attribute.
> 
>    When a router aggregates several routes for the purpose of
>    advertisement to a particular peer, and the AS_PATH of the aggregated
>    route excludes at least some of the AS numbers present in the AS_PATH
>    of the routes that are aggregated, the aggregated route, when
>    advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.
> 
>    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
>    attribute MUST NOT remove the attribute from the route when
>    propagating it to other speakers.
> 
>    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
>    attribute MUST NOT make any NLRI of that route more specific (as
>    defined in 9.1.4) when advertising this route to other BGP speakers.
> 
>    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
>    attribute needs to be cognizant of the fact that the actual path to
>    destinations, as specified in the NLRI of the route, while having the
>    loop-free property, may not be the path specified in the AS_PATH
>    attribute of the route.
> 
> Suuggested new text:
> 
>   5.1.6 ATOMIC_AGGREGATE
> 
>    ATOMIC_AGGREGATE is a well-known discretionary attribute.
> 
>    When a router aggregates several routes for the purpose of
>    advertisement to a particular peer, the AS_PATH of the
>    aggregated route normally includes an AS_SET formed from the set of
>    AS from which the aggregate was formed.  In many cases the network
>    administrator can determine that the aggregate can safely be
>    advertised without the AS_SET and not form route loops.
> 
>    If an aggregate excludes at least some of the AS numbers present in
>    the AS_PATH of the routes that are aggregated as a result of
>    dropping the AS_SET, the aggregated route, when advertised to the
>    peer, SHOULD include the ATOMIC_AGGREGATE attribute.
> 
>    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
>    attribute SHOULD NOT remove the attribute from the route when
>    propagating it to other speakers.
> 
>    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
>    attribute MUST NOT make any NLRI of that route more specific (as
>    defined in 9.1.4) when advertising this route to other BGP speakers.
> 
>    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
>    attribute needs to be cognizant of the fact that the actual path to
>    destinations, as specified in the NLRI of the route, while having the
>    loop-free property, may not be the path specified in the AS_PATH
>    attribute of the route.
> 
> Diffs (for reader convenience):
> 
> @@ -4,13 +4,19 @@
>     ATOMIC_AGGREGATE is a well-known discretionary attribute.
> 
>     When a router aggregates several routes for the purpose of
> -   advertisement to a particular peer, and the AS_PATH of the aggregated
> -   route excludes at least some of the AS numbers present in the AS_PATH
> -   of the routes that are aggregated, the aggregated route, when
> -   advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.
> +   advertisement to a particular peer, the AS_PATH of the
> +   aggregated route normally includes an AS_SET formed from the set of
> +   AS from which the aggregate was formed.  In many cases the network
> +   administrator can determine that the aggregate can safely be
> +   advertised without the AS_SET and not form route loops.
> +
> +   If an aggregate excludes at least some of the AS numbers present in
> +   the AS_PATH of the routes that are aggregated as a result of
> +   dropping the AS_SET, the aggregated route, when advertised to the
> +   peer, SHOULD include the ATOMIC_AGGREGATE attribute.
> 
>     A BGP speaker that receives a route with the ATOMIC_AGGREGATE
> -   attribute MUST NOT remove the attribute from the route when
> +   attribute SHOULD NOT remove the attribute from the route when
>     propagating it to other speakers.
> 
>     A BGP speaker that receives a route with the ATOMIC_AGGREGATE
> 
> 
> Current text in 9.1.4:
> 
>    If a BGP speaker chooses to aggregate, then it MUST add
>    ATOMIC_AGGREGATE attribute to the route. A route that carries
>    ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the
>    NLRI of this route can not be made more specific. Forwarding along
>    such a route does not guarantee that IP packets will actually
>    traverse only ASs listed in the AS_PATH attribute of the route.
> 
> Change to:
> 
>    If a BGP speaker chooses to aggregate, then it SHOULD either
>    include all AS used to form the aggreagate in an AS_SET or add the
>    ATOMIC_AGGREGATE attribute to the route.  This attribute is now
>    primarily informational.  With the elimination of IP routing
>    protocols that do not support classless routing and the elimination
>    of router and host implementations that do not support classless
>    routing, there is no longer a need to deaggregate.  Routes should
>    not be de-aggregated.  A route that carries ATOMIC_AGGREGATE
>    attribute in particular can not be de-aggregated. That is, the NLRI
>    of this route can not be made more specific. Forwarding along such
>    a route does not guarantee that IP packets will actually traverse
>    only ASs listed in the AS_PATH attribute of the route.
> 
> This text in 9.2.2.2 need not change.
> 
>       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.
> 
> The appendix need not change:
> 
>   Appendix 1. Comparison with RFC1771
> 
>       [...]
> 
>       Clarifications to the use of the ATOMIC_AGGREGATE attribute.
> 
> This might be a bit more wordy that is necessary.  It does address the
> objections to keeping ATOMIC_AGGREGATE by making the MUST into SHOULD,
> and explaining that ATOMIC_AGGREGATE is now primarily informational.
> 
> 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 KAA25157 for <[e-mail]>; Mon, 30 Sep 2002 10:19:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 84F6E91239; Mon, 30 Sep 2002 10:19:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46A5691247; Mon, 30 Sep 2002 10:19:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B6C5E91239 for <[e-mail]>; Mon, 30 Sep 2002 10:19:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 960E65DDB2; Mon, 30 Sep 2002 10:19:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id C05525DDA2 for <[e-mail]>; Mon, 30 Sep 2002 10:19:17 -0400 (EDT)
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 KAA30828; Mon, 30 Sep 2002 10:19:10 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 58 
In-reply-to: Your message of "Thu, 26 Sep 2002 10:56:55 PDT." <[e-mail]> 
Date: Mon, 30 Sep 2002 10:19:10 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Yakov Rekhter writes
:
> Curtis,
> 
> > >   58) Deprication of ATOMIC_AGGREGATE
> > >   -----------------------------------------------------------------------
> --
> > >   Status: No Consensus
> > >   Change: Potentially
> > >   Summary: It is proposed that ATOMIC_AGGREGATE be depricated.  There has
>  
> > >    not yet been any discussion on the proposed changes.
> > > 
> > > Comments on this issue would be appreciated.
> > > 
> > > In the absence of any objections to the changes proposed by Jeff, the
> > > changes would be accepted. 
> > > 
> > > Yakov.
> > 
> > 
> > We used to add ATOMIC_AGGREGATE whenever the AS_PATH was truncated
> > rather than replaced with an AS_SET.  It was always purely
> > informational since no one intentionally deaggregated and reannounced.
> > Don't implementations still support this?
> > 
> > If reality is that it is informational only, then just remove the
> > MUSTs and indicate that it is informational.
> 
> Could you please propose the text.
> 
> Yakov.


This existing text is fine:

         f) ATOMIC_AGGREGATE (Type Code 6)

            ATOMIC_AGGREGATE is a well-known discretionary attribute of
            length 0. Usage of this attribute is described in 5.1.6.

This is the existing text that we are considering changing:

  5.1.6 ATOMIC_AGGREGATE

   ATOMIC_AGGREGATE is a well-known discretionary attribute.

   When a router aggregates several routes for the purpose of
   advertisement to a particular peer, and the AS_PATH of the aggregated
   route excludes at least some of the AS numbers present in the AS_PATH
   of the routes that are aggregated, the aggregated route, when
   advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.

   A BGP speaker that receives a route with the ATOMIC_AGGREGATE
   attribute MUST NOT remove the attribute from the route when
   propagating it to other speakers.

   A BGP speaker that receives a route with the ATOMIC_AGGREGATE
   attribute MUST NOT make any NLRI of that route more specific (as
   defined in 9.1.4) when advertising this route to other BGP speakers.

   A BGP speaker that receives a route with the ATOMIC_AGGREGATE
   attribute needs to be cognizant of the fact that the actual path to
   destinations, as specified in the NLRI of the route, while having the
   loop-free property, may not be the path specified in the AS_PATH
   attribute of the route.

Suuggested new text:

  5.1.6 ATOMIC_AGGREGATE

   ATOMIC_AGGREGATE is a well-known discretionary attribute.

   When a router aggregates several routes for the purpose of
   advertisement to a particular peer, the AS_PATH of the
   aggregated route normally includes an AS_SET formed from the set of
   AS from which the aggregate was formed.  In many cases the network
   administrator can determine that the aggregate can safely be
   advertised without the AS_SET and not form route loops.

   If an aggregate excludes at least some of the AS numbers present in
   the AS_PATH of the routes that are aggregated as a result of
   dropping the AS_SET, the aggregated route, when advertised to the
   peer, SHOULD include the ATOMIC_AGGREGATE attribute.

   A BGP speaker that receives a route with the ATOMIC_AGGREGATE
   attribute SHOULD NOT remove the attribute from the route when
   propagating it to other speakers.

   A BGP speaker that receives a route with the ATOMIC_AGGREGATE
   attribute MUST NOT make any NLRI of that route more specific (as
   defined in 9.1.4) when advertising this route to other BGP speakers.

   A BGP speaker that receives a route with the ATOMIC_AGGREGATE
   attribute needs to be cognizant of the fact that the actual path to
   destinations, as specified in the NLRI of the route, while having the
   loop-free property, may not be the path specified in the AS_PATH
   attribute of the route.

Diffs (for reader convenience):

@@ -4,13 +4,19 @@
    ATOMIC_AGGREGATE is a well-known discretionary attribute.
 
    When a router aggregates several routes for the purpose of
-   advertisement to a particular peer, and the AS_PATH of the aggregated
-   route excludes at least some of the AS numbers present in the AS_PATH
-   of the routes that are aggregated, the aggregated route, when
-   advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.
+   advertisement to a particular peer, the AS_PATH of the
+   aggregated route normally includes an AS_SET formed from the set of
+   AS from which the aggregate was formed.  In many cases the network
+   administrator can determine that the aggregate can safely be
+   advertised without the AS_SET and not form route loops.
+
+   If an aggregate excludes at least some of the AS numbers present in
+   the AS_PATH of the routes that are aggregated as a result of
+   dropping the AS_SET, the aggregated route, when advertised to the
+   peer, SHOULD include the ATOMIC_AGGREGATE attribute.
 
    A BGP speaker that receives a route with the ATOMIC_AGGREGATE
-   attribute MUST NOT remove the attribute from the route when
+   attribute SHOULD NOT remove the attribute from the route when
    propagating it to other speakers.
 
    A BGP speaker that receives a route with the ATOMIC_AGGREGATE


Current text in 9.1.4:

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

Change to:

   If a BGP speaker chooses to aggregate, then it SHOULD either
   include all AS used to form the aggreagate in an AS_SET or add the
   ATOMIC_AGGREGATE attribute to the route.  This attribute is now
   primarily informational.  With the elimination of IP routing
   protocols that do not support classless routing and the elimination
   of router and host implementations that do not support classless
   routing, there is no longer a need to deaggregate.  Routes should
   not be de-aggregated.  A route that carries ATOMIC_AGGREGATE
   attribute in particular can not be de-aggregated. That is, the NLRI
   of this route can not be made more specific. Forwarding along such
   a route does not guarantee that IP packets will actually traverse
   only ASs listed in the AS_PATH attribute of the route.

This text in 9.2.2.2 need not change.

      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.

The appendix need not change:

  Appendix 1. Comparison with RFC1771

      [...]

      Clarifications to the use of the ATOMIC_AGGREGATE attribute.

This might be a bit more wordy that is necessary.  It does address the
objections to keeping ATOMIC_AGGREGATE by making the MUST into SHOULD,
and explaining that ATOMIC_AGGREGATE is now primarily informational.

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 JAA24009 for <[e-mail]>; Mon, 30 Sep 2002 09:55:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6966891221; Mon, 30 Sep 2002 09:54:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3749F91229; Mon, 30 Sep 2002 09:54:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C1C7F91221 for <[e-mail]>; Mon, 30 Sep 2002 09:54:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9E7B35DDB2; Mon, 30 Sep 2002 09:54:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 59BBF5DDAE for <[e-mail]>; Mon, 30 Sep 2002 09:54:42 -0400 (EDT)
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 JAA30600; Mon, 30 Sep 2002 09:54:36 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 8 
In-reply-to: Your message of "Thu, 26 Sep 2002 12:45:58 EDT." <[e-mail]> 
Date: Mon, 30 Sep 2002 09:54:35 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

As far as the BGP spec is concerned it is fine to just say that jitter
should be applied to all timers.  Whether a particular vendor does so
for a particular timer does not pose interoperability problems, at
worst is very minor deficiency in an implementation, and therefore is
irrelevant to the discussion of what should be recommended in the
protocol spec.

Curtis


In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> It seems to me that if you bring up all bgp peers at once it
> may lead to load spikes on the network.  Cisco seems to wait
> 27.5 +/- 2.5 seconds for IBGP, and 40 +/- 5 seconds for
> EBGP--20 sec. from config time to the "open active, delay"
> jittered delay assignment plus the jittered delay (5 to 10
> sec. for IBGP, and 15 to 25 sec. for EBGP).  This would also
> apply for "no neighbor x.x.x.x shutdown".  Their value of
> ConnectRetry is 60sec.  though, not sure how this value is used
> (based on above).  Maybe some Cisco folks can chime in on
> this one???
> 
> I did not check Juniper.
> 
> Also, interestingly, they do not apply jitter to
> the other timers (as far as I can tell), but I don't see
> a problem with this.
> 
> Another timer that they use that is not mentioned in
> the draft/rfc is the next hop resolution timer which is 30
> seconds.  Although it would be nice to have this in the spec,
> I will concede that it is out of scope and/or
> implementation dependent.
> 
> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]] 
> Sent: Thursday, September 26, 2002 12:34 PM
> To: Yakov Rekhter
> Cc: [e-mail]; Sivananda Ramnath - CTD, Chennai.
> Subject: Re: issue 8 
> 
> 
> In message <[e-mail]>, Yakov Rekhter
> writes
> :
> > forwarding...
> > ------- Forwarded Message
> > 
> > Date:    Thu, 26 Sep 2002 16:58:19 +0530
> > From:    "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
> > To:      Yakov Rekhter <[e-mail]>
> > Subject: FW: issue 8
> > 
> > Hello,
> > 
> >     My mail does not seem to have made it to the list. Could you please
> > forward it ?
> > 
> > Thanks,
> > Siva
> > ([e-mail])
> > 
> > - -----Original Message-----
> > From: Sivananda Ramnath - CTD, Chennai. 
> > Sent: Thursday, September 26, 2002 3:21 PM
> > To: [e-mail]
> > Subject: RE: issue 8
> > 
> > 
> > Hello,
> > 
> >     The ConnectRetry timer is should have a value that is 'sufficiently
> > large to allow TCP initialization. Application of jitter can reduce the
> this
> > value (by up to 25%). A configuration which the ConnectRetry timer has
> been
> > pegged at a value close to TCP connection time may cause a connection to
> be
> > terminated as a result of this jitter. Is this a cause for concern ? 
> > 
> >     The default value suggested for ConnectRetry (120 seconds) is
> > sufficiently large that event with a jitter of 0.75, it will be greater
> than
> TCP'c connection establishment timer.
> > 
> >     Is adding a jitter to the ConnectRetry timer a standard practice ?
> What
> > benefit does this provide ?
> > 
> > Sivanand
> > ([e-mail])
> 
> 
> The TCP connection establishment timer is 75 seconds (sysctl yield
> "net.inet.tcp.keepinit: 75000" in BSD-oids).
> 
> The ConnectRetry determines when to make a second attempt after a
> prior attempt to connect has failed.  It is to avoid a rapid
> succession of retries on immediate failures (for example "Connection
> refused" if the peer was in the middle of a reboot, Network
> Unreachable if you can't get there from here, etc) but also covers the
> case where the TCP SYN goes off and is never heard from again.
> 
> 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 IAA21932 for <[e-mail]>; Mon, 30 Sep 2002 08:58:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C787191220; Mon, 30 Sep 2002 08:57:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9772E91221; Mon, 30 Sep 2002 08:57:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4A38D91220 for <[e-mail]>; Mon, 30 Sep 2002 08:57:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2BF7F5DDB6; Mon, 30 Sep 2002 08:57:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id C91385DDB5 for <[e-mail]>; Mon, 30 Sep 2002 08:57:52 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12F6N>; Mon, 30 Sep 2002 08:57:52 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 10 
Date: Mon, 30 Sep 2002 08:57:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Ok.  So we have consensus on:
"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 speaker may choose not to advertise the route to its
peers and may choose to log an error locally."  

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Monday, September 30, 2002 8:24 AM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: issue 10 

Jonathan,

> I think we should change:
> "   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 speaker may choose not to advertise the route to its
>    peers.  Other alternatives of handling this situation are outside
>    the scope of this document."
> To:
>    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 speaker may choose not to advertise the route to its
>    peers and may choose to log an error locally.  Other alternatives of
>    handling this situation are outside the scope of this document."

That would be fine with me, although I am not sure we need the
last sentence ("Other alternatives....").

Yakov.

> 1) Does this happen in real life?
> 2) Candidate for INFORM?
> 3) Maybe add ~= "rate limit these error logs"?
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Wednesday, September 25, 2002 2:47 PM
> To: [e-mail]
> Subject: issue 10
> 
>   10) Extending AS_PATH Attribute
>  
>
----------------------------------------------------------------------------
>   Status: No Consensus
>   Change: Potentially
>   Summary: Specific text required to delimit behavior when AS_PATH length
>    is exceeded.
>   
>   Discussion:
>   
>   The "Extending AS_PATH attribute length en route" thread brought up
>   the issue of what action should we specify when we receive a route
>   with an AS_PATH that exceeds the defined maximum length.  There was
>   some discussion, and it was suggested that, after logging the error,
>   the route not be propegated.  No text was proposed.  This issue needs
>   consensus:  Do we specify the behavior?  If so what with what text?
> 
> The real issue here is how to handle the case when a route
> (a single address prefix + path attributes) doesn't fit into
> 4K bytes (as the max BGP message size is 4 K). To address
> this issue I would suggest to add the following to 9.2:
> 
>    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 speaker may choose not to advertise the route to its
>    peers.  Other alternatives of handling this situation are outside
>    the scope of this 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 IAA20858 for <[e-mail]>; Mon, 30 Sep 2002 08:25:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C7A309120F; Mon, 30 Sep 2002 08:24:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 978099121E; Mon, 30 Sep 2002 08:24:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C9AD9120F for <[e-mail]>; Mon, 30 Sep 2002 08:24:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3A2DE5DDB0; Mon, 30 Sep 2002 08:24:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 9D6765DDA8 for <[e-mail]>; Mon, 30 Sep 2002 08:24:33 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8UCOSm00614; Mon, 30 Sep 2002 05:24:28 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 10 
In-Reply-To: Your message of "Mon, 30 Sep 2002 06:34:47 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 30 Sep 2002 05:24:28 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> I think we should change:
> "   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 speaker may choose not to advertise the route to its
>    peers.  Other alternatives of handling this situation are outside
>    the scope of this document."
> To:
>    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 speaker may choose not to advertise the route to its
>    peers and may choose to log an error locally.  Other alternatives of
>    handling this situation are outside the scope of this document."

That would be fine with me, although I am not sure we need the
last sentence ("Other alternatives....").

Yakov.

> 1) Does this happen in real life?
> 2) Candidate for INFORM?
> 3) Maybe add ~= "rate limit these error logs"?
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Wednesday, September 25, 2002 2:47 PM
> To: [e-mail]
> Subject: issue 10
> 
>   10) Extending AS_PATH Attribute
>  
> ----------------------------------------------------------------------------
>   Status: No Consensus
>   Change: Potentially
>   Summary: Specific text required to delimit behavior when AS_PATH length
>    is exceeded.
>   
>   Discussion:
>   
>   The "Extending AS_PATH attribute length en route" thread brought up
>   the issue of what action should we specify when we receive a route
>   with an AS_PATH that exceeds the defined maximum length.  There was
>   some discussion, and it was suggested that, after logging the error,
>   the route not be propegated.  No text was proposed.  This issue needs
>   consensus:  Do we specify the behavior?  If so what with what text?
> 
> The real issue here is how to handle the case when a route
> (a single address prefix + path attributes) doesn't fit into
> 4K bytes (as the max BGP message size is 4 K). To address
> this issue I would suggest to add the following to 9.2:
> 
>    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 speaker may choose not to advertise the route to its
>    peers.  Other alternatives of handling this situation are outside
>    the scope of this 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 GAA17162 for <[e-mail]>; Mon, 30 Sep 2002 06:35:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 95C959120D; Mon, 30 Sep 2002 06:34:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 69B529121B; Mon, 30 Sep 2002 06:34:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2ABCD9120D for <[e-mail]>; Mon, 30 Sep 2002 06:34:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 06ACB5DD98; Mon, 30 Sep 2002 06:34:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id B99895DD8C for <[e-mail]>; Mon, 30 Sep 2002 06:34:48 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12FJA>; Mon, 30 Sep 2002 06:34:48 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 10
Date: Mon, 30 Sep 2002 06:34:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I think we should change:
"   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 speaker may choose not to advertise the route to its
   peers.  Other alternatives of handling this situation are outside
   the scope of this document."
To:
   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 speaker may choose not to advertise the route to its
   peers and may choose to log an error locally.  Other alternatives of
handling this situation are outside
   the scope of this document."

1) Does this happen in real life?
2) Candidate for INFORM?
3) Maybe add ~= "rate limit these error logs"?

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 2:47 PM
To: [e-mail]
Subject: issue 10

  10) Extending AS_PATH Attribute
 
----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Specific text required to delimit behavior when AS_PATH length
   is exceeded.
  
  Discussion:
  
  The "Extending AS_PATH attribute length en route" thread brought up
  the issue of what action should we specify when we receive a route
  with an AS_PATH that exceeds the defined maximum length.  There was
  some discussion, and it was suggested that, after logging the error,
  the route not be propegated.  No text was proposed.  This issue needs
  consensus:  Do we specify the behavior?  If so what with what text?

The real issue here is how to handle the case when a route
(a single address prefix + path attributes) doesn't fit into
4K bytes (as the max BGP message size is 4 K). To address
this issue I would suggest to add the following to 9.2:

   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 speaker may choose not to advertise the route to its
   peers.  Other alternatives of handling this situation are outside
   the scope of this 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 WAA01220 for <[e-mail]>; Sun, 29 Sep 2002 22:11:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9773291211; Sun, 29 Sep 2002 22:11:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F3FF9121A; Sun, 29 Sep 2002 22:11:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D572191211 for <[e-mail]>; Sun, 29 Sep 2002 22:11:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B21175E049; Sun, 29 Sep 2002 22:11:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 4D15F5E290 for <[e-mail]>; Sun, 29 Sep 2002 22:11:22 -0400 (EDT)
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 WAA21427; Sun, 29 Sep 2002 22:11:14 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: "Natale, Jonathan" <[e-mail]>, "'[e-mail]'" <[e-mail]>, Jeffrey Haas <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 10 
In-reply-to: Your message of "Fri, 27 Sep 2002 12:23:14 PDT." <[e-mail]> 
Date: Sun, 29 Sep 2002 22:11:14 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, [e-mail]
dus.net writes:
> Ok, so we are at consensus to add this to 9.2:
> 
>     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 speaker may choose not to advertise the route to its
>     peers.
> 
> Do we want to:
> 
> 1) Make any more general statement that "if you can't send all of something
> don't send any"?
> 
> 2) Say something about encoding AS_PATH as multiple segements?
> 
> Both of these came up during the discussion, and I'm trying to tie up
> loose ends.
> 
> Andrew


Andrew,

That isn't quite the meaning that we had consensus for.

Wording would be more like:

   If the attributes for a specific prefix becomes too large to fit
   the prefix into the maximum sized BGP UPDATE message, the prefix
   should not be advertised further.  Truncation or ommision of
   attributes should not occur unless policies for such modifications
   are specifically configured.  Such policies may contribute to the
   formation of route loops and are not within the scope of this
   protocol specification.

I couldn't find the existing text so if its already there or if Yakov
suggested something already, then please ignore my suggestion.

btw - Something like not being able to handle an AS path with a
extended size over 255 bytes would be just a bug and we should not
have to change the spec for this.  The practical thing to do is ISPs
configure policy to simply block export of the problem routes and put
pressure on to get the non-conformant routers fixed quickly.

Curtis



> On Thu, Sep 26, 2002 at 12:35:17PM -0400, Natale, Jonathan wrote:
> > Delivered-To: [e-mail]
> > Delivered-To: [e-mail]
> > Delivered-To: [e-mail]
> > From: "Natale, Jonathan" <[e-mail]>
> > To: "'[e-mail]'" <[e-mail]>
> > Cc: Jeffrey Haas <[e-mail]>, Yakov Rekhter <[e-mail]>,
> >    [e-mail]
> > Subject: RE: issue 10 
> > Date: Thu, 26 Sep 2002 12:35:17 -0400
> > X-Mailer: Internet Mail Service (5.5.2653.19)
> > Precedence: bulk
> > X-OriginalArrivalTime: 26 Sep 2002 16:37:37.0257 (UTC) FILETIME=[05CE1590:0
> 1C2657B]
> > 
> > I agree, what non-conforming implementations do to limit the bad effects of
> > non-conforming is out of scope.
> > 
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:[e-mail]] 
> > Sent: Thursday, September 26, 2002 12:16 PM
> > To: [e-mail]
> > Cc: Jeffrey Haas; Yakov Rekhter; [e-mail]
> > Subject: Re: issue 10 
> > 
> > 
> > In message <[e-mail]>, Curtis
> > Villamizar 
> > writes:
> > > 
> > > In message <[e-mail]>, Curtis
> > Villamiza
> > > r 
> > > writes:
> > > > 
> > > > In message <[e-mail]>, Jeffrey Haas writes:
> > > > > 
> > > > > If I might suggest that although this is the most "valid" 
> > > > > (for some value judgement of "valid") case for this problem,
> > > > > implementations may choose for whatever reason to deal with
> > > > > attribute overflows differently.  For example, if a certain vendor
> > > > > didn't want to support AS_PATHS over 256 AS's, that's their
> > > > > prerogative.
> > > > 
> > > > I'd call it marginally broken rather than their prerogative.  AS path
> > > > padding has gotten out of hand but not this bad so it shouldn't be an
> > > > issue if such a route was dropped, but it is technically wrong unless
> > > > policy was configured to do so.
> > > > 
> > > > Curtis
> > > 
> > > 
> > > Actually the length is one octet so ignore the above.
> > > 
> > > Never mind,
> > > 
> > > Curtis
> > 
> > But the AS_PATH can have multiple AS_SEQMENTs each with 255 AS ....
> > 
> > In any case, I like Yakov's suggestion to leave the text as is "don't
> > advertise, if you do truncate somehow its outside the scope of the
> > spec" (paraphrased).
> > 
> > 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 RAA22996 for <[e-mail]>; Fri, 27 Sep 2002 17:53:01 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1346991239; Fri, 27 Sep 2002 17:52:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D33F5912D4; Fri, 27 Sep 2002 17:52:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 75CCF91239 for <[e-mail]>; Fri, 27 Sep 2002 17:52:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 592D85E1CD; Fri, 27 Sep 2002 17:52:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id F25CC5DF52 for <[e-mail]>; Fri, 27 Sep 2002 17:52:35 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8RLqZm66954; Fri, 27 Sep 2002 14:52:35 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 11 
In-Reply-To: Your message of "Fri, 27 Sep 2002 13:53:38 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 27 Sep 2002 14:52:35 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Alex,

>   If we default to putting things in different drafts, we'll have a
>   bunch of separate docs describing a single protocol. 

Please note that I am not making any assertion on what the default
should be. Neither on whether it should apply to this particular
case. So, let's focus on how we should handle multipath, and have
a separate discussion (if desired) on what the default should be.

>    Multipath is
>   something that is normally in the heart of a routing protocol. There
>   should be a good reason to want something like this in a separate
>   document. Do we have one in this case?

Time. If we are interested in getting the base spec completed within
the timeframe outlined in the current charter, we can't add
substantial new material to the spec. 

Yakov.

>   Thanks.
> 
> -- 
> Alex
> 
> Friday, September 27, 2002, 1:34:00 PM, Yakov Rekhter wrote:
> > Alex,
> 
> >> Jeff, et al
> >> 
> >>  I'm a little lost here. Considering that BGP multipath:
> >> 
> >>   - is implemented by at least two (major) vendors
> >> 
> >>   - affects core protocol mechanisms
> >> 
> >>   - is important enough to be thoroughly described
> >>     to avoid implementation bugs
> >> 
> >>  why would we not want it in the base spec?
> 
> > Why not in a separate draft ?
> 
> > After all, there are quite a few *optional* BGP features that are
> > implemented by multiple vendors, affect core protocol mechanisms,
> > and are important enough to be thoroughly described to avoid
> > implementation bugs, and are not in the base spec, but are in
> > separate RFCs.
> 
> > Yakov.
> 
> >>     
> >> -- 
> >> Alex
> >> 
> >> Friday, September 27, 2002, 7:25:28 AM, Jeffrey Haas wrote:
> >> > On Fri, Sep 27, 2002 at 07:50:10PM +0530, Sivananda Ramnath - CTD, Chenn
ai.
> >  wrote:
> >> >> % The Loc-RIB SHOULD contain only one route per destination.
> >> >> % An implementation may choose to install multiple routes to
> >> >> % a destination (for the purposes of load balancing).
> >> >> % An implementation doing this MUST ensure that it is
> >> >> % interoperable with versions that do not, and MUST
> >> >> % ensure that no routing loops or inconsistent routing
> >> >> % information is propagated as result of this action. The
> >> >> % handling of such a configuration, however, is outside the
> >> >> % scope of this RFC.
> >> >> 
> >> >>    It does seem a little too detailed, though!
> >> 
> >> > My concern is not that this is rope to allow operators to hang themselve
s
> >> > with - this is a gatling gun that allows implementers to try to
> >> > guess at useful rules and hose the Internet.  BGP, as a protocol,
> >> > is already prone to long-lived loops.  Lets not make it easier to
> >> > do this in a way thats harder to troubleshoot.
> >> 
> >> > I haven't thought about this in large amounts of detail, but some
> >> > quick observations on what could be done to actually implement
> >> > this:
> >> 
> >> > o The routes should be equally preferable - i.e. they need to enter
> >> >   the tie-breaking process.
> >> > o They should have the same AS_PATH
> >> > o Perhaps the path attributes should only be allowed to differ on
> >> >   NEXT_HOP.
> >> 
> >> > *If* the above are true, then re-announcing any of the routes used
> >> > in the load-balancing should work fine as long as the re-announcement
> >> > is going to be a first-party nexthop.  If you have a third-party
> >> > nexthop, then you might end up with inconsistant forwarding.
> >> 
> >> > I would propose that this might be something worth investing some
> >> > time over, but it shouldn't be mentioned in the base spec.
> >> 
> >> >> Sivanand
> >> 
> >> 
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA21263 for <[e-mail]>; Fri, 27 Sep 2002 16:56:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 45BC2912EE; Fri, 27 Sep 2002 16:55:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F078912EF; Fri, 27 Sep 2002 16:55:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98013912EE for <[e-mail]>; Fri, 27 Sep 2002 16:55:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 76D0C5E1D3; Fri, 27 Sep 2002 16:55:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 4AC8A5E1BD for <[e-mail]>; Fri, 27 Sep 2002 16:55:36 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17v299-000HSO-00; Fri, 27 Sep 2002 13:55:35 -0700
Date: Fri, 27 Sep 2002 13:53:38 -0700
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 11
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Yakov,

  If we default to putting things in different drafts, we'll have a
  bunch of separate docs describing a single protocol. Multipath is
  something that is normally in the heart of a routing protocol. There
  should be a good reason to want something like this in a separate
  document. Do we have one in this case?
  Thanks.

-- 
Alex

Friday, September 27, 2002, 1:34:00 PM, Yakov Rekhter wrote:
> Alex,

>> Jeff, et al
>> 
>>  I'm a little lost here. Considering that BGP multipath:
>> 
>>   - is implemented by at least two (major) vendors
>> 
>>   - affects core protocol mechanisms
>> 
>>   - is important enough to be thoroughly described
>>     to avoid implementation bugs
>> 
>>  why would we not want it in the base spec?

> Why not in a separate draft ?

> After all, there are quite a few *optional* BGP features that are
> implemented by multiple vendors, affect core protocol mechanisms,
> and are important enough to be thoroughly described to avoid
> implementation bugs, and are not in the base spec, but are in
> separate RFCs.

> Yakov.

>>     
>> -- 
>> Alex
>> 
>> Friday, September 27, 2002, 7:25:28 AM, Jeffrey Haas wrote:
>> > On Fri, Sep 27, 2002 at 07:50:10PM +0530, Sivananda Ramnath - CTD, Chennai.
>  wrote:
>> >> % The Loc-RIB SHOULD contain only one route per destination.
>> >> % An implementation may choose to install multiple routes to
>> >> % a destination (for the purposes of load balancing).
>> >> % An implementation doing this MUST ensure that it is
>> >> % interoperable with versions that do not, and MUST
>> >> % ensure that no routing loops or inconsistent routing
>> >> % information is propagated as result of this action. The
>> >> % handling of such a configuration, however, is outside the
>> >> % scope of this RFC.
>> >> 
>> >>    It does seem a little too detailed, though!
>> 
>> > My concern is not that this is rope to allow operators to hang themselves
>> > with - this is a gatling gun that allows implementers to try to
>> > guess at useful rules and hose the Internet.  BGP, as a protocol,
>> > is already prone to long-lived loops.  Lets not make it easier to
>> > do this in a way thats harder to troubleshoot.
>> 
>> > I haven't thought about this in large amounts of detail, but some
>> > quick observations on what could be done to actually implement
>> > this:
>> 
>> > o The routes should be equally preferable - i.e. they need to enter
>> >   the tie-breaking process.
>> > o They should have the same AS_PATH
>> > o Perhaps the path attributes should only be allowed to differ on
>> >   NEXT_HOP.
>> 
>> > *If* the above are true, then re-announcing any of the routes used
>> > in the load-balancing should work fine as long as the re-announcement
>> > is going to be a first-party nexthop.  If you have a third-party
>> > nexthop, then you might end up with inconsistant forwarding.
>> 
>> > I would propose that this might be something worth investing some
>> > time over, but it shouldn't be mentioned in the base spec.
>> 
>> >> Sivanand
>> 
>> 




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA21137 for <[e-mail]>; Fri, 27 Sep 2002 16:51:54 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E38A3912E9; Fri, 27 Sep 2002 16:49:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE72F912EE; Fri, 27 Sep 2002 16:49:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2B7F0912E9 for <[e-mail]>; Fri, 27 Sep 2002 16:49:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 17D495E1D3; Fri, 27 Sep 2002 16:49:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 95C6A5E1D2 for <[e-mail]>; Fri, 27 Sep 2002 16:49:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA08547; Fri, 27 Sep 2002 16:49:49 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25607; Fri, 27 Sep 2002 16:49:51 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7K0FL>; Fri, 27 Sep 2002 16:49:50 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, Alex Zinin <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 11 
Date: Fri, 27 Sep 2002 16:49:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Alex:
  If we mention BGP Multipath, either dedicate a whole section to it or
mention it and provide a reference document that is dedicated to it. Just
saying the details are out of scope is unreasonable.

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Friday, September 27, 2002 4:34 PM
> To: Alex Zinin
> Cc: [e-mail]
> Subject: Re: issue 11 
> 
> 
> Alex,
> 
> > Jeff, et al
> > 
> >  I'm a little lost here. Considering that BGP multipath:
> > 
> >   - is implemented by at least two (major) vendors
> > 
> >   - affects core protocol mechanisms
> > 
> >   - is important enough to be thoroughly described
> >     to avoid implementation bugs
> > 
> >  why would we not want it in the base spec?
> 
> Why not in a separate draft ?
> 
> After all, there are quite a few *optional* BGP features that are
> implemented by multiple vendors, affect core protocol mechanisms,
> and are important enough to be thoroughly described to avoid
> implementation bugs, and are not in the base spec, but are in
> separate RFCs.
> 
> Yakov.
> 
> >     
> > -- 
> > Alex
> > 
> > Friday, September 27, 2002, 7:25:28 AM, Jeffrey Haas wrote:
> > > On Fri, Sep 27, 2002 at 07:50:10PM +0530, Sivananda 
> Ramnath - CTD, Chennai.
>  wrote:
> > >> % The Loc-RIB SHOULD contain only one route per destination.
> > >> % An implementation may choose to install multiple routes to
> > >> % a destination (for the purposes of load balancing).
> > >> % An implementation doing this MUST ensure that it is
> > >> % interoperable with versions that do not, and MUST
> > >> % ensure that no routing loops or inconsistent routing
> > >> % information is propagated as result of this action. The
> > >> % handling of such a configuration, however, is outside the
> > >> % scope of this RFC.
> > >> 
> > >>    It does seem a little too detailed, though!
> > 
> > > My concern is not that this is rope to allow operators to 
> hang themselves
> > > with - this is a gatling gun that allows implementers to try to
> > > guess at useful rules and hose the Internet.  BGP, as a protocol,
> > > is already prone to long-lived loops.  Lets not make it easier to
> > > do this in a way thats harder to troubleshoot.
> > 
> > > I haven't thought about this in large amounts of detail, but some
> > > quick observations on what could be done to actually implement
> > > this:
> > 
> > > o The routes should be equally preferable - i.e. they 
> need to enter
> > >   the tie-breaking process.
> > > o They should have the same AS_PATH
> > > o Perhaps the path attributes should only be allowed to differ on
> > >   NEXT_HOP.
> > 
> > > *If* the above are true, then re-announcing any of the routes used
> > > in the load-balancing should work fine as long as the 
> re-announcement
> > > is going to be a first-party nexthop.  If you have a third-party
> > > nexthop, then you might end up with inconsistant forwarding.
> > 
> > > I would propose that this might be something worth investing some
> > > time over, but it shouldn't be mentioned in the base spec.
> > 
> > >> Sivanand
> > 
> > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA20638 for <[e-mail]>; Fri, 27 Sep 2002 16:34:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1B9A3912DF; Fri, 27 Sep 2002 16:34:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D6D73912E0; Fri, 27 Sep 2002 16:34:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9EE0B912DF for <[e-mail]>; Fri, 27 Sep 2002 16:34:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 75EA95E1CF; Fri, 27 Sep 2002 16:34:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id D95E85E1CD for <[e-mail]>; Fri, 27 Sep 2002 16:34:00 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8RKY0m59952; Fri, 27 Sep 2002 13:34:00 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 11 
In-Reply-To: Your message of "Fri, 27 Sep 2002 13:22:42 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 27 Sep 2002 13:34:00 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Alex,

> Jeff, et al
> 
>  I'm a little lost here. Considering that BGP multipath:
> 
>   - is implemented by at least two (major) vendors
> 
>   - affects core protocol mechanisms
> 
>   - is important enough to be thoroughly described
>     to avoid implementation bugs
> 
>  why would we not want it in the base spec?

Why not in a separate draft ?

After all, there are quite a few *optional* BGP features that are
implemented by multiple vendors, affect core protocol mechanisms,
and are important enough to be thoroughly described to avoid
implementation bugs, and are not in the base spec, but are in
separate RFCs.

Yakov.

>     
> -- 
> Alex
> 
> Friday, September 27, 2002, 7:25:28 AM, Jeffrey Haas wrote:
> > On Fri, Sep 27, 2002 at 07:50:10PM +0530, Sivananda Ramnath - CTD, Chennai.
 wrote:
> >> % The Loc-RIB SHOULD contain only one route per destination.
> >> % An implementation may choose to install multiple routes to
> >> % a destination (for the purposes of load balancing).
> >> % An implementation doing this MUST ensure that it is
> >> % interoperable with versions that do not, and MUST
> >> % ensure that no routing loops or inconsistent routing
> >> % information is propagated as result of this action. The
> >> % handling of such a configuration, however, is outside the
> >> % scope of this RFC.
> >> 
> >>    It does seem a little too detailed, though!
> 
> > My concern is not that this is rope to allow operators to hang themselves
> > with - this is a gatling gun that allows implementers to try to
> > guess at useful rules and hose the Internet.  BGP, as a protocol,
> > is already prone to long-lived loops.  Lets not make it easier to
> > do this in a way thats harder to troubleshoot.
> 
> > I haven't thought about this in large amounts of detail, but some
> > quick observations on what could be done to actually implement
> > this:
> 
> > o The routes should be equally preferable - i.e. they need to enter
> >   the tie-breaking process.
> > o They should have the same AS_PATH
> > o Perhaps the path attributes should only be allowed to differ on
> >   NEXT_HOP.
> 
> > *If* the above are true, then re-announcing any of the routes used
> > in the load-balancing should work fine as long as the re-announcement
> > is going to be a first-party nexthop.  If you have a third-party
> > nexthop, then you might end up with inconsistant forwarding.
> 
> > I would propose that this might be something worth investing some
> > time over, but it shouldn't be mentioned in the base spec.
> 
> >> Sivanand
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA20343 for <[e-mail]>; Fri, 27 Sep 2002 16:25:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BA018912DD; Fri, 27 Sep 2002 16:25:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D7A1912DF; Fri, 27 Sep 2002 16:25:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 18258912DD for <[e-mail]>; Fri, 27 Sep 2002 16:25:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F06825E1CF; Fri, 27 Sep 2002 16:25:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id C1BFB5E1C2 for <[e-mail]>; Fri, 27 Sep 2002 16:25:17 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17v1fD-000Geu-00; Fri, 27 Sep 2002 13:24:39 -0700
Date: Fri, 27 Sep 2002 13:22:42 -0700
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, <[e-mail]>
Subject: Re: issue 11
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Jeff, et al

 I'm a little lost here. Considering that BGP multipath:

  - is implemented by at least two (major) vendors

  - affects core protocol mechanisms

  - is important enough to be thoroughly described
    to avoid implementation bugs

 why would we not want it in the base spec?
    
-- 
Alex

Friday, September 27, 2002, 7:25:28 AM, Jeffrey Haas wrote:
> On Fri, Sep 27, 2002 at 07:50:10PM +0530, Sivananda Ramnath - CTD, Chennai. wrote:
>> % The Loc-RIB SHOULD contain only one route per destination.
>> % An implementation may choose to install multiple routes to
>> % a destination (for the purposes of load balancing).
>> % An implementation doing this MUST ensure that it is
>> % interoperable with versions that do not, and MUST
>> % ensure that no routing loops or inconsistent routing
>> % information is propagated as result of this action. The
>> % handling of such a configuration, however, is outside the
>> % scope of this RFC.
>> 
>>    It does seem a little too detailed, though!

> My concern is not that this is rope to allow operators to hang themselves
> with - this is a gatling gun that allows implementers to try to
> guess at useful rules and hose the Internet.  BGP, as a protocol,
> is already prone to long-lived loops.  Lets not make it easier to
> do this in a way thats harder to troubleshoot.

> I haven't thought about this in large amounts of detail, but some
> quick observations on what could be done to actually implement
> this:

> o The routes should be equally preferable - i.e. they need to enter
>   the tie-breaking process.
> o They should have the same AS_PATH
> o Perhaps the path attributes should only be allowed to differ on
>   NEXT_HOP.

> *If* the above are true, then re-announcing any of the routes used
> in the load-balancing should work fine as long as the re-announcement
> is going to be a first-party nexthop.  If you have a third-party
> nexthop, then you might end up with inconsistant forwarding.

> I would propose that this might be something worth investing some
> time over, but it shouldn't be mentioned in the base spec.

>> Sivanand




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA19281 for <[e-mail]>; Fri, 27 Sep 2002 15:50:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BDAAF91259; Fri, 27 Sep 2002 15:50:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F791912D9; Fri, 27 Sep 2002 15:50:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 855DF91259 for <[e-mail]>; Fri, 27 Sep 2002 15:50:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 705505E1C1; Fri, 27 Sep 2002 15:50:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id F03155E1B4 for <[e-mail]>; Fri, 27 Sep 2002 15:50:04 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA05390; Fri, 27 Sep 2002 15:50:02 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA16301; Fri, 27 Sep 2002 15:50:04 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7K783>; Fri, 27 Sep 2002 15:50:03 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Kunihiro Ishiguro <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: RE: issue 37
Date: Fri, 27 Sep 2002 15:50:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

My opinion to this question, if such terms as "withdrawn routes" and
"unfeasable routes" are used multiple times as either verbs, adjectives, and
nouns interchangeably, then it would be wise to define them in the "commonly
used terms" section. If they are used only in one mode in a few places, then
as Yakov stated its OK to let the local useage define the meaning.

Ben

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Friday, September 27, 2002 3:28 PM
> To: Kunihiro Ishiguro
> Cc: Yakov Rekhter; [e-mail]
> Subject: Re: issue 37
> 
> 
> To address the concern in the original post:  Do we want to add a 
> definition of "Unfeasable Routes" to the glossary/list of frequently
> used terms?
> 
> Andrew
> 
> On Thu, Sep 26, 2002 at 10:05:53AM -0700, Kunihiro Ishiguro wrote:
> > Delivered-To: [e-mail]
> > Delivered-To: [e-mail]
> > Delivered-To: [e-mail]
> > Date: Thu, 26 Sep 2002 10:05:53 -0700
> > From: Kunihiro Ishiguro <[e-mail]>
> > To: Yakov Rekhter <[e-mail]>
> > Cc: [e-mail]
> > Subject: Re: issue 37 
> > In-Reply-To: <[e-mail]>
> > User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 
> (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 
> Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI)
> > Precedence: bulk
> > X-OriginalArrivalTime: 26 Sep 2002 17:06:04.0179 (UTC) 
> FILETIME=[FF35B630:01C2657E]
> > 
> > Thanks for clear explanation.  I'm convinced.
> > 
> > >> 
> >-------------------------------------------------------------
> ---------------
> > >> >37) Combine "Unfeasable Routes" and "Withdrawn Routes"
> > >> 
> >-------------------------------------------------------------
> ---------------
> > >> >Status: No Consensus
> > >> >Change: Potentially
> > >> >Summary: No definition extant for "Unfeasable Routes". 
> > >> >
> > >> >Discussion:
> > >> >
> > >> >3. P. 45, Phase I, There is no definition of what are 
> unfeasible routes? Are
> > >> >they the same as withdrawn routes? If so, the two 
> should be combined to one
> > >> >name.
> > >> 
> > >> >From implementation stand point there is no difference between
> > >> "Unfeasible Routes" and "Withdrawn Routes".  When the route is
> > >> unfeasible, BGP withdraw the route.  I think combining 
> two name to one
> > >> name make sense.
> > >
> > >The routes are withdrawn from service because they are unfeasible,
> > >not because they are "withdrawn". So, we need to keep the term
> > >"unfeasible" to indicate the *reason* why a route could be 
> withdrawn.
> > >On the other hand, "withdrawn" is used as a verb, and to the best
> > >of my knowledge "unfeasible" can't be used as a verb.  With this
> > >in mind, I don't think that we can combine the two into a single
> > >term.
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA18737 for <[e-mail]>; Fri, 27 Sep 2002 15:32:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D254A912D4; Fri, 27 Sep 2002 15:31:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9BADC912D9; Fri, 27 Sep 2002 15:31:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8BD13912D4 for <[e-mail]>; Fri, 27 Sep 2002 15:31:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DCDDA5E1CE; Fri, 27 Sep 2002 15:31:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id B71F85E1CD for <[e-mail]>; Fri, 27 Sep 2002 15:31:15 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id MAA15480; Fri, 27 Sep 2002 12:28:19 -0700 (PDT)
Date: Fri, 27 Sep 2002 12:28:19 -0700
From: [e-mail]
To: Kunihiro Ishiguro <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: issue 37
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
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Sep 26, 2002 at 10:05:53AM -0700
Sender: [e-mail]
Precedence: bulk

To address the concern in the original post:  Do we want to add a 
definition of "Unfeasable Routes" to the glossary/list of frequently
used terms?

Andrew

On Thu, Sep 26, 2002 at 10:05:53AM -0700, Kunihiro Ishiguro wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Date: Thu, 26 Sep 2002 10:05:53 -0700
> From: Kunihiro Ishiguro <[e-mail]>
> To: Yakov Rekhter <[e-mail]>
> Cc: [e-mail]
> Subject: Re: issue 37 
> In-Reply-To: <[e-mail]>
> User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI)
> Precedence: bulk
> X-OriginalArrivalTime: 26 Sep 2002 17:06:04.0179 (UTC) FILETIME=[FF35B630:01C2657E]
> 
> Thanks for clear explanation.  I'm convinced.
> 
> >> >----------------------------------------------------------------------------
> >> >37) Combine "Unfeasable Routes" and "Withdrawn Routes"
> >> >----------------------------------------------------------------------------
> >> >Status: No Consensus
> >> >Change: Potentially
> >> >Summary: No definition extant for "Unfeasable Routes". 
> >> >
> >> >Discussion:
> >> >
> >> >3. P. 45, Phase I, There is no definition of what are unfeasible routes? Are
> >> >they the same as withdrawn routes? If so, the two should be combined to one
> >> >name.
> >> 
> >> >From implementation stand point there is no difference between
> >> "Unfeasible Routes" and "Withdrawn Routes".  When the route is
> >> unfeasible, BGP withdraw the route.  I think combining two name to one
> >> name make sense.
> >
> >The routes are withdrawn from service because they are unfeasible,
> >not because they are "withdrawn". So, we need to keep the term
> >"unfeasible" to indicate the *reason* why a route could be withdrawn.
> >On the other hand, "withdrawn" is used as a verb, and to the best
> >of my knowledge "unfeasible" can't be used as a verb.  With this
> >in mind, I don't think that we can combine the two into a single
> >term.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA18539 for <[e-mail]>; Fri, 27 Sep 2002 15:26:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8EAB0912DB; Fri, 27 Sep 2002 15:26:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E1D6912DD; Fri, 27 Sep 2002 15:26:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 35E42912DB for <[e-mail]>; Fri, 27 Sep 2002 15:26:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0FB3A5E1CB; Fri, 27 Sep 2002 15:26:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 76FDF5E1C9 for <[e-mail]>; Fri, 27 Sep 2002 15:26:14 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id MAA15413; Fri, 27 Sep 2002 12:23:14 -0700 (PDT)
Date: Fri, 27 Sep 2002 12:23:14 -0700
From: [e-mail]
To: "Natale, Jonathan" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, Jeffrey Haas <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: issue 10
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, Sep 26, 2002 at 12:35:17PM -0400
Sender: [e-mail]
Precedence: bulk

Ok, so we are at consensus to add this to 9.2:

    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 speaker may choose not to advertise the route to its
    peers.

Do we want to:

1) Make any more general statement that "if you can't send all of something
don't send any"?

2) Say something about encoding AS_PATH as multiple segements?

Both of these came up during the discussion, and I'm trying to tie up
loose ends.

Andrew

On Thu, Sep 26, 2002 at 12:35:17PM -0400, Natale, Jonathan wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> From: "Natale, Jonathan" <[e-mail]>
> To: "'[e-mail]'" <[e-mail]>
> Cc: Jeffrey Haas <[e-mail]>, Yakov Rekhter <[e-mail]>,
>    [e-mail]
> Subject: RE: issue 10 
> Date: Thu, 26 Sep 2002 12:35:17 -0400
> X-Mailer: Internet Mail Service (5.5.2653.19)
> Precedence: bulk
> X-OriginalArrivalTime: 26 Sep 2002 16:37:37.0257 (UTC) FILETIME=[05CE1590:01C2657B]
> 
> I agree, what non-conforming implementations do to limit the bad effects of
> non-conforming is out of scope.
> 
> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]] 
> Sent: Thursday, September 26, 2002 12:16 PM
> To: [e-mail]
> Cc: Jeffrey Haas; Yakov Rekhter; [e-mail]
> Subject: Re: issue 10 
> 
> 
> In message <[e-mail]>, Curtis
> Villamizar 
> writes:
> > 
> > In message <[e-mail]>, Curtis
> Villamiza
> > r 
> > writes:
> > > 
> > > In message <[e-mail]>, Jeffrey Haas writes:
> > > > 
> > > > If I might suggest that although this is the most "valid" 
> > > > (for some value judgement of "valid") case for this problem,
> > > > implementations may choose for whatever reason to deal with
> > > > attribute overflows differently.  For example, if a certain vendor
> > > > didn't want to support AS_PATHS over 256 AS's, that's their
> > > > prerogative.
> > > 
> > > I'd call it marginally broken rather than their prerogative.  AS path
> > > padding has gotten out of hand but not this bad so it shouldn't be an
> > > issue if such a route was dropped, but it is technically wrong unless
> > > policy was configured to do so.
> > > 
> > > Curtis
> > 
> > 
> > Actually the length is one octet so ignore the above.
> > 
> > Never mind,
> > 
> > Curtis
> 
> But the AS_PATH can have multiple AS_SEQMENTs each with 255 AS ....
> 
> In any case, I like Yakov's suggestion to leave the text as is "don't
> advertise, if you do truncate somehow its outside the scope of the
> spec" (paraphrased).
> 
> 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 OAA17438 for <[e-mail]>; Fri, 27 Sep 2002 14:55:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 799C1912D9; Fri, 27 Sep 2002 14:55:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49055912DA; Fri, 27 Sep 2002 14:55:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3933B912D9 for <[e-mail]>; Fri, 27 Sep 2002 14:55:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 20FC05E1BE; Fri, 27 Sep 2002 14:55:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 890F85E19A for <[e-mail]>; Fri, 27 Sep 2002 14:55:05 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id LAA15027; Fri, 27 Sep 2002 11:51:44 -0700 (PDT)
Date: Fri, 27 Sep 2002 11:51:44 -0700
From: [e-mail]
To: [e-mail]
Cc: "Natale, Jonathan" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: Re: issue 32.1
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 Thu, Sep 26, 2002 at 11:48:35AM -0400
Sender: [e-mail]
Precedence: bulk

This is the text that it seems from the discussion that we are settled on
for section 5.1.1:

----

After much continued discussion on this in the "issue 32.1" thread, we seem
to have come to a consensus that section 5.1.1 should read:

	ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
	shall be generated by the speaker that originates the
	associated routing information. Its value should not be
	changed by any other speaker unless the other speaker is
	administratively configured to do so to affect policy
	decisions."

This text met with a number of agreements, and one disagreement stating
that we shouldn't have the "unless administratively configured" portion.

----

We would still appear to be undecided on any modifications to the ORIGIN
listing.  To me, there seems to be sufficent confusion around the "EGP"
reference to merit some sort of clarification.  The simplest modification
would be to change:

		  1	    EGP - Network Layer Reachability Information
				learned via the EGP protocol

to:

		  1	    EGP - Network Layer Reachability Information
				learned via the EGP protocol [RFC904]

That would clarify that we're talking about the protocol, and not the
class-of-protocols, or EBGP.  It would leave unstated that this could
theoretically be used to muck with route selection.  I think that is
ok.  If operators want to override ORIGIN to affect some hoho magic,
they are welcome to do so, but I don't think it needs to be documented
in the base spec.

Andrew

On Thu, Sep 26, 2002 at 11:48:35AM -0400, Curtis Villamizar wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> To: "Natale, Jonathan" <[e-mail]>
> Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
> Reply-To: [e-mail]
> Subject: Re: issue 32.1 
> In-reply-to: Your message of "Wed, 25 Sep 2002 14:35:03 EDT."
>              <[e-mail]> 
> Date: Thu, 26 Sep 2002 11:48:35 -0400
> From: Curtis Villamizar <[e-mail]>
> Precedence: bulk
> X-OriginalArrivalTime: 26 Sep 2002 15:50:38.0014 (UTC) FILETIME=[7567BDE0:01C26574]
> 
> 
> In message <[e-mail]
> ks.com>, "Natale, Jonathan" writes:
> > How about:
> > "5.1.1 ORIGIN
> >   
> >      ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
> >      shall be generated by the autonomous system that originates the
> >      associated routing information. Its value shall not be
> >      changed by any other speaker unless the other speaker is
> >      administratively configured to do so to affect policy
> >      decisions."
> 
> 
> 
> How about if we save time and in the definitions section we just state
> that MUST means manditory except if configured to do otherwise.  That
> should cover many of the objections in our list.  :-)
> 
> Or maybe we should just leave things as is and not go around adding
> "unless administratively configured to do otherwise" ["to affect
> policy decisions" being the most common reason for the otherwise].
> 
> Mannually changing the origin code should not be encouraged.
> 
> 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 OAA17373 for <[e-mail]>; Fri, 27 Sep 2002 14:53:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C8064912D4; Fri, 27 Sep 2002 14:53:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93204912D9; Fri, 27 Sep 2002 14:53:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 79294912D4 for <[e-mail]>; Fri, 27 Sep 2002 14:53:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 59D2E5E1B7; Fri, 27 Sep 2002 14:53:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id D9B7B5E19A for <[e-mail]>; Fri, 27 Sep 2002 14:53:18 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA02189; Fri, 27 Sep 2002 14:53:16 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA04210; Fri, 27 Sep 2002 14:53:18 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7KZAJ>; Fri, 27 Sep 2002 14:53:17 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 11
Date: Fri, 27 Sep 2002 14:53:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I have somewhat of an issue with the paragraph after item c section 9.1.2
as discussed.

which is =>

  "The local speaker SHALL then install that route in the Loc-RIB,
   replacing any route to the same destination that is currently being
   held in the Loc-RIB. If the new BGP route is installed in the Routing
   Table (as a result of the local policy decision), care must be taken
   to ensure that invalid BGP routes to the same destination are removed
   from the Routing Table. Whether or not the new route replaces an
   already existing non-BGP route in the routing table depends on the
   policy configured on the BGP speaker."

Can we assume that its OK to have a route present in the Loc-RIB and
possibly in the adj-RIB-Out but not in the Routing table due to some policy.
Won't we violate rule number 1? Only advertise what you use.

As conversly implied in this sentence => 

"If the new BGP route is installed in the Routing Table (as a result of the
local policy decision), care must be taken to ensure that invalid BGP routes
to the same destination are removed from the Routing Table"

I would rephrase the paragraph as follows =>

  "The local speaker SHALL then install that route in the Loc-RIB,
   replacing any route to the same destination that is currently being
   held in the Loc-RIB. When the new BGP route is installed in the Routing
   Table, care must be taken to ensure that existing routes to the same 
   destination that are now considered invalid are removed from the 
   Routing Table. Whether or not the new BGP route replaces an existing  
   non-BGP route in the routing table depends on the policy configured 
   on the BGP speaker."

Thanks,
Ben

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Friday, September 27, 2002 2:14 PM
> To: Yakov Rekhter
> Cc: [e-mail]
> Subject: Re: issue 11
> 
> 
> To take this discussion back to the text proposed in the 
> original 9.1, do
> we have consensus on Yakov's response?  Or is there more discussion on
> this topic?
> 
> Andrew
> 
> On Wed, Sep 25, 2002 at 08:30:57AM -0700, Yakov Rekhter wrote:
> > Delivered-To: [e-mail]
> > Delivered-To: [e-mail]
> > Delivered-To: [e-mail]
> > To: [e-mail]
> > Subject: issue 11
> > Date: Wed, 25 Sep 2002 08:30:57 -0700
> > From: Yakov Rekhter <[e-mail]>
> > Precedence: bulk
> > X-OriginalArrivalTime: 25 Sep 2002 15:33:33.0343 (UTC) 
> FILETIME=[E83D9AF0:01C264A8]
> > 
> >   11) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1
> >   
> --------------------------------------------------------------
> --------------
> >   Status: No Consensus
> >   Change: Potentially
> >   Summary: Variety of texts proposed to help clear up the 
> rules for moving
> >    routes from Loc-RIB into Adj-RIB-Out.
> >   
> >   Discussion:
> >   
> >   The "Proxy: comments on section 9.1.3" thread brought up 
> some lack of
> >   clarity in the section discussing the rules for which 
> routes get propegated
> >   from the Loc-RIB into the Adj-RIB-Out.	These 
> discussions resulted in
> >   a number of suggestions for new text.
> >   
> >   The first new text was proposed to clarify the issue that 
> the thread
> >   first brought up:
> >   
> >   I agree that this could use some clarification. How about adding
> >   to b) in section 9.1:
> >   
> >     The Loc-RIB must contain only one route per 
> destination; further, it
> >     must include all routes that the BGP speaker is using.
> >   
> >   changing c) in section 9.1.2 to:
> >   
> >     c) is selected as a result of the Phase 2 tie breaking 
> rules specified
> >     in 9.1.2.2, or
> >   
> >   and adding
> >   
> >     d) when routing protocols other than BGP are in use, is 
> determined by
> >     some other local means to be the route that will 
> actually be used to
> >     reach a particular destination.
> >   
> >   This text was never discussed or a consensus formed on 
> putting it in the
> >   document.
> >   
> >   This modification to 9.1.2 was also proposed to address 
> the same concern:
> >   
> >   How about changing the paragraph after c) in 9.1.2 to:
> >   
> >     The local speaker SHALL then install that route in the Loc-RIB,
> >     replacing any route to the same destination that is 
> currently being
> >     held in the Loc-RIB.	This route SHALL then also be 
> installed in
> >     the BGP speakers forwarding table.
> >   
> >   There was one response in the negative to this change, 
> arguing that is
> >   is not necessary.
> >   
> > Wrt "adding to b) in section 9.1", the second part (after ";") is
> > redundant as this point is already stated in 3.2. Wrt the first
> > point about Loc-RIB containing just one route per destination, I
> > would suggest to add it to section 3.2, where Loc-RIB is first
> > introduced, rather than adding it to 9.1.
> > 
> > Wrt "changing c)... and adding...", I have no objections to 
> add/modify
> > the text, as suggested above.
> > 
> > I am not sure though that changing the paragraph after c) in 9.1.2
> > is really necessary though, so I would prefer to keep it as is. 
> > 
> > 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 OAA16325 for <[e-mail]>; Fri, 27 Sep 2002 14:19:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3CAE391259; Fri, 27 Sep 2002 14:17:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E633C912D1; Fri, 27 Sep 2002 14:17:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C5C5991259 for <[e-mail]>; Fri, 27 Sep 2002 14:17:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A1BFE5E19E; Fri, 27 Sep 2002 14:17:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 133C15E14E for <[e-mail]>; Fri, 27 Sep 2002 14:17:10 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id LAA14571; Fri, 27 Sep 2002 11:14:14 -0700 (PDT)
Date: Fri, 27 Sep 2002 11:14:14 -0700
From: [e-mail]
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 11
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 Wed, Sep 25, 2002 at 08:30:57AM -0700
Sender: [e-mail]
Precedence: bulk

To take this discussion back to the text proposed in the original 9.1, do
we have consensus on Yakov's response?  Or is there more discussion on
this topic?

Andrew

On Wed, Sep 25, 2002 at 08:30:57AM -0700, Yakov Rekhter wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> To: [e-mail]
> Subject: issue 11
> Date: Wed, 25 Sep 2002 08:30:57 -0700
> From: Yakov Rekhter <[e-mail]>
> Precedence: bulk
> X-OriginalArrivalTime: 25 Sep 2002 15:33:33.0343 (UTC) FILETIME=[E83D9AF0:01C264A8]
> 
>   11) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1
>   ----------------------------------------------------------------------------
>   Status: No Consensus
>   Change: Potentially
>   Summary: Variety of texts proposed to help clear up the rules for moving
>    routes from Loc-RIB into Adj-RIB-Out.
>   
>   Discussion:
>   
>   The "Proxy: comments on section 9.1.3" thread brought up some lack of
>   clarity in the section discussing the rules for which routes get propegated
>   from the Loc-RIB into the Adj-RIB-Out.	These discussions resulted in
>   a number of suggestions for new text.
>   
>   The first new text was proposed to clarify the issue that the thread
>   first brought up:
>   
>   I agree that this could use some clarification. How about adding
>   to b) in section 9.1:
>   
>     The Loc-RIB must contain only one route per destination; further, it
>     must include all routes that the BGP speaker is using.
>   
>   changing c) in section 9.1.2 to:
>   
>     c) is selected as a result of the Phase 2 tie breaking rules specified
>     in 9.1.2.2, or
>   
>   and adding
>   
>     d) when routing protocols other than BGP are in use, is determined by
>     some other local means to be the route that will actually be used to
>     reach a particular destination.
>   
>   This text was never discussed or a consensus formed on putting it in the
>   document.
>   
>   This modification to 9.1.2 was also proposed to address the same concern:
>   
>   How about changing the paragraph after c) in 9.1.2 to:
>   
>     The local speaker SHALL then install that route in the Loc-RIB,
>     replacing any route to the same destination that is currently being
>     held in the Loc-RIB.	This route SHALL then also be installed in
>     the BGP speakers forwarding table.
>   
>   There was one response in the negative to this change, arguing that is
>   is not necessary.
>   
> Wrt "adding to b) in section 9.1", the second part (after ";") is
> redundant as this point is already stated in 3.2. Wrt the first
> point about Loc-RIB containing just one route per destination, I
> would suggest to add it to section 3.2, where Loc-RIB is first
> introduced, rather than adding it to 9.1.
> 
> Wrt "changing c)... and adding...", I have no objections to add/modify
> the text, as suggested above.
> 
> I am not sure though that changing the paragraph after c) in 9.1.2
> is really necessary though, so I would prefer to keep it as is. 
> 
> 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 NAA15408 for <[e-mail]>; Fri, 27 Sep 2002 13:53:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 737BE91259; Fri, 27 Sep 2002 13:53:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 453A89125A; Fri, 27 Sep 2002 13:53:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4F7D691259 for <[e-mail]>; Fri, 27 Sep 2002 13:53:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3B2725E1BB; Fri, 27 Sep 2002 13:53:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id D33595E1BA for <[e-mail]>; Fri, 27 Sep 2002 13:53:14 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id KAA14271; Fri, 27 Sep 2002 10:50:11 -0700 (PDT)
Date: Fri, 27 Sep 2002 10:50:11 -0700
From: [e-mail]
To: Yakov Rekhter <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>, [e-mail]
Subject: Re: issue 55
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 Wed, Sep 25, 2002 at 09:17:13AM -0700
Sender: [e-mail]
Precedence: bulk

I also prefer the "but-less" version of Yakov's text. If there are
no objections/more input, I'll move this issue into the consensus
category.

Andrew

On Wed, Sep 25, 2002 at 09:17:13AM -0700, Yakov Rekhter wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> To: Jeffrey Haas <[e-mail]>
> Cc: [e-mail]
> Subject: Re: issue 55 
> In-Reply-To: Your message of "Wed, 25 Sep 2002 11:58:11 EDT."
>              <[e-mail]> 
> Date: Wed, 25 Sep 2002 09:17:13 -0700
> From: Yakov Rekhter <[e-mail]>
> Precedence: bulk
> X-OriginalArrivalTime: 25 Sep 2002 16:20:24.0826 (UTC) FILETIME=[7403DDA0:01C264AF]
> 
> Jeff,
> 
> > On Wed, Sep 25, 2002 at 11:19:13AM -0400, Natale, Jonathan wrote:
> > > "Path segment length is a 1-octet long field containing
> > > the number of ASs (which is half the number of octets
> > > since each AS is 2 octets) in the path segment value
> > > field (also note that the path may contain more than 1
> > > segment).
> > 
> > I prefer Yakov's text:
> > 
> > >    Path segment length is a 1-octet long field containing
> > >    the number of ASs (but not the number of octets) in the path 
> > >    segment value field.
> > 
> > with the clarification of deleting the word "but".
> 
> That would be fine.
> 
> 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 KAA08632 for <[e-mail]>; Fri, 27 Sep 2002 10:50:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 98453912F1; Fri, 27 Sep 2002 10:49:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61A7B912F3; Fri, 27 Sep 2002 10:49:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 49A94912F1 for <[e-mail]>; Fri, 27 Sep 2002 10:49:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 29DCF5E18E; Fri, 27 Sep 2002 10:49:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id A877A5E16F for <[e-mail]>; Fri, 27 Sep 2002 10:49:30 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA17898; Fri, 27 Sep 2002 10:49:28 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21271; Fri, 27 Sep 2002 10:49:29 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7KNC6>; Fri, 27 Sep 2002 10:49:28 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Sivananda Ramnath - CTD, Chennai.'" <[e-mail]>, Jeffrey Haas <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 11
Date: Fri, 27 Sep 2002 10:49:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Sivanda:
  Actually you raise an interesting point. If we assume that every item
mentioned in a spec requires compliancy, then if you add this feature
to the spec there might be someone out there that did not implement it
mainly because they felt it was not needed. Thus, all of a sudden they
will fail the compliancy test and will have to do more work to be approved.
That is another big reason why you should not add this kind of stuff, unless
you are sure that everyone out there has it in their software.

Personnally, I dont think every item in an RFC must be implemented for the
vendor to be compliant. But thats a personal opinion.

Regards,
Ben

> -----Original Message-----
> From: Sivananda Ramnath - CTD, Chennai. [mailto:[e-mail]]
> Sent: Friday, September 27, 2002 10:41 AM
> To: Jeffrey Haas; Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: RE: issue 11
> 
> 
> Hello,
> 
>    There are implementers today who have already implemented 
> this. It's not
> a new concept I am proposing here, merely stating the 
> existence of a current
> practice. Failing this, many large vendors would be considered
> non-compliant.
> 
>    I completely agree with you on the potential hazards of doing this
> incorrectly; that said how do we resolve this issue while 
> taking care not to
> declare existing implementations to be non-compliant ?
> 
> Sivanand
> ([e-mail])
> 
> 
> > -----Original Message-----
> > From: Jeffrey Haas [mailto:[e-mail]]
> > Sent: Friday, September 27, 2002 7:55 PM
> > To: Sivananda Ramnath - CTD, Chennai.
> > Cc: Abarbanel, Benjamin; [e-mail]
> > Subject: Re: issue 11
> > 
> > 
> > On Fri, Sep 27, 2002 at 07:50:10PM +0530, Sivananda Ramnath - 
> > CTD, Chennai. wrote:
> > > % The Loc-RIB SHOULD contain only one route per destination.
> > > % An implementation may choose to install multiple routes to
> > > % a destination (for the purposes of load balancing).
> > > % An implementation doing this MUST ensure that it is
> > > % interoperable with versions that do not, and MUST
> > > % ensure that no routing loops or inconsistent routing
> > > % information is propagated as result of this action. The
> > > % handling of such a configuration, however, is outside the
> > > % scope of this RFC.
> > > 
> > >    It does seem a little too detailed, though!
> > 
> > My concern is not that this is rope to allow operators to 
> > hang themselves
> > with - this is a gatling gun that allows implementers to try to
> > guess at useful rules and hose the Internet.  BGP, as a protocol,
> > is already prone to long-lived loops.  Lets not make it easier to
> > do this in a way thats harder to troubleshoot.
> > 
> > I haven't thought about this in large amounts of detail, but some
> > quick observations on what could be done to actually implement
> > this:
> > 
> > o The routes should be equally preferable - i.e. they need to enter
> >   the tie-breaking process.
> > o They should have the same AS_PATH
> > o Perhaps the path attributes should only be allowed to differ on
> >   NEXT_HOP.
> > 
> > *If* the above are true, then re-announcing any of the routes used
> > in the load-balancing should work fine as long as the 
> re-announcement
> > is going to be a first-party nexthop.  If you have a third-party
> > nexthop, then you might end up with inconsistant forwarding.
> > 
> > I would propose that this might be something worth investing some
> > time over, but it shouldn't be mentioned in the base spec.
> > 
> > > Sivanand
> > 
> > -- 
> > 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 KAA08558 for <[e-mail]>; Fri, 27 Sep 2002 10:47:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B5E2B912F0; Fri, 27 Sep 2002 10:46:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 89550912F1; Fri, 27 Sep 2002 10:46:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6FA15912F0 for <[e-mail]>; Fri, 27 Sep 2002 10:46:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3D5925E190; Fri, 27 Sep 2002 10:46:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id B0D235E16F for <[e-mail]>; Fri, 27 Sep 2002 10:46:39 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8REkY589765; Fri, 27 Sep 2002 10:46:34 -0400 (EDT) (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 g8REkLG89702; Fri, 27 Sep 2002 10:46:21 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8REkLq03137; Fri, 27 Sep 2002 10:46:21 -0400 (EDT)
Date: Fri, 27 Sep 2002 10:46:21 -0400
From: Jeffrey Haas <[e-mail]>
To: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 11
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 Fri, Sep 27, 2002 at 08:11:05PM +0530
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Sep 27, 2002 at 08:11:05PM +0530, Sivananda Ramnath - CTD, Chennai. wrote:
>    There are implementers today who have already implemented this. It's not
> a new concept I am proposing here, merely stating the existence of a current
> practice. Failing this, many large vendors would be considered
> non-compliant.

They aren't non-compliant.  They implement the base specification and
probably can shut off their multipath extensions.

Documents outside of the base specification can and do extend the
base specification.  Consider Confederations - it changes the
AS_PATH and the behavior of route selection.  Technically, someone
who implements confederations isn't compliant with the base spec.
But similarly, you can shut off confederations and still interoperate.

With this in mind, would you be happy documenting the base specification
and save documenting the multipath extension until later?

And also note that vendor-specific extensions aren't also compliant
with the spec.  However, if their implementation *can* be compliant
by shutting off those features, thats good enough.

-- 
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 KAA08304 for <[e-mail]>; Fri, 27 Sep 2002 10:39:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 19D70912EF; Fri, 27 Sep 2002 10:39:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E17D5912F0; Fri, 27 Sep 2002 10:39:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8EA37912EF for <[e-mail]>; Fri, 27 Sep 2002 10:39:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7D2F05E18C; Fri, 27 Sep 2002 10:39:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id 2D3595E18E for <[e-mail]>; Fri, 27 Sep 2002 10:38:56 -0400 (EDT)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <TXPHPV2K>; Fri, 27 Sep 2002 20:14:31 +0530
Message-ID: <[e-mail]>
From: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
To: Jeffrey Haas <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 11
Date: Fri, 27 Sep 2002 20:11:05 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hello,

   There are implementers today who have already implemented this. It's not
a new concept I am proposing here, merely stating the existence of a current
practice. Failing this, many large vendors would be considered
non-compliant.

   I completely agree with you on the potential hazards of doing this
incorrectly; that said how do we resolve this issue while taking care not to
declare existing implementations to be non-compliant ?

Sivanand
([e-mail])


> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Friday, September 27, 2002 7:55 PM
> To: Sivananda Ramnath - CTD, Chennai.
> Cc: Abarbanel, Benjamin; [e-mail]
> Subject: Re: issue 11
> 
> 
> On Fri, Sep 27, 2002 at 07:50:10PM +0530, Sivananda Ramnath - 
> CTD, Chennai. wrote:
> > % The Loc-RIB SHOULD contain only one route per destination.
> > % An implementation may choose to install multiple routes to
> > % a destination (for the purposes of load balancing).
> > % An implementation doing this MUST ensure that it is
> > % interoperable with versions that do not, and MUST
> > % ensure that no routing loops or inconsistent routing
> > % information is propagated as result of this action. The
> > % handling of such a configuration, however, is outside the
> > % scope of this RFC.
> > 
> >    It does seem a little too detailed, though!
> 
> My concern is not that this is rope to allow operators to 
> hang themselves
> with - this is a gatling gun that allows implementers to try to
> guess at useful rules and hose the Internet.  BGP, as a protocol,
> is already prone to long-lived loops.  Lets not make it easier to
> do this in a way thats harder to troubleshoot.
> 
> I haven't thought about this in large amounts of detail, but some
> quick observations on what could be done to actually implement
> this:
> 
> o The routes should be equally preferable - i.e. they need to enter
>   the tie-breaking process.
> o They should have the same AS_PATH
> o Perhaps the path attributes should only be allowed to differ on
>   NEXT_HOP.
> 
> *If* the above are true, then re-announcing any of the routes used
> in the load-balancing should work fine as long as the re-announcement
> is going to be a first-party nexthop.  If you have a third-party
> nexthop, then you might end up with inconsistant forwarding.
> 
> I would propose that this might be something worth investing some
> time over, but it shouldn't be mentioned in the base spec.
> 
> > Sivanand
> 
> -- 
> 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 KAA08197 for <[e-mail]>; Fri, 27 Sep 2002 10:37:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B8775912EE; Fri, 27 Sep 2002 10:35:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6904D912EF; Fri, 27 Sep 2002 10:35:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 183A3912EE for <[e-mail]>; Fri, 27 Sep 2002 10:35:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F40385E18C; Fri, 27 Sep 2002 10:35:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id BD9745E101 for <[e-mail]>; Fri, 27 Sep 2002 10:35:23 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16901; Fri, 27 Sep 2002 10:35:20 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA17492; Fri, 27 Sep 2002 10:35:21 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7KL85>; Fri, 27 Sep 2002 10:35:20 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: RE: issue 11
Date: Fri, 27 Sep 2002 10:35:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I think adding this feature in a future version of this base draft with a
reference to a new draft that covers the subject well will be a reasonable 
thing to do.

So I vote, that we dont add now, but leave it for future upgrades with
supporting draft.

Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Friday, September 27, 2002 10:25 AM
> To: Sivananda Ramnath - CTD, Chennai.
> Cc: Abarbanel, Benjamin; [e-mail]
> Subject: Re: issue 11
> 
> 
> On Fri, Sep 27, 2002 at 07:50:10PM +0530, Sivananda Ramnath - 
> CTD, Chennai. wrote:
> > % The Loc-RIB SHOULD contain only one route per destination.
> > % An implementation may choose to install multiple routes to
> > % a destination (for the purposes of load balancing).
> > % An implementation doing this MUST ensure that it is
> > % interoperable with versions that do not, and MUST
> > % ensure that no routing loops or inconsistent routing
> > % information is propagated as result of this action. The
> > % handling of such a configuration, however, is outside the
> > % scope of this RFC.
> > 
> >    It does seem a little too detailed, though!
> 
> My concern is not that this is rope to allow operators to 
> hang themselves
> with - this is a gatling gun that allows implementers to try to
> guess at useful rules and hose the Internet.  BGP, as a protocol,
> is already prone to long-lived loops.  Lets not make it easier to
> do this in a way thats harder to troubleshoot.
> 
> I haven't thought about this in large amounts of detail, but some
> quick observations on what could be done to actually implement
> this:
> 
> o The routes should be equally preferable - i.e. they need to enter
>   the tie-breaking process.
> o They should have the same AS_PATH
> o Perhaps the path attributes should only be allowed to differ on
>   NEXT_HOP.
> 
> *If* the above are true, then re-announcing any of the routes used
> in the load-balancing should work fine as long as the re-announcement
> is going to be a first-party nexthop.  If you have a third-party
> nexthop, then you might end up with inconsistant forwarding.
> 
> I would propose that this might be something worth investing some
> time over, but it shouldn't be mentioned in the base spec.
> 
> > Sivanand
> 
> -- 
> 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 KAA07871 for <[e-mail]>; Fri, 27 Sep 2002 10:27:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F1189912E9; Fri, 27 Sep 2002 10:26:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA73B912EB; Fri, 27 Sep 2002 10:26:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A4802912E9 for <[e-mail]>; Fri, 27 Sep 2002 10:26:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 961465E18B; Fri, 27 Sep 2002 10:26:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id D77E05E101 for <[e-mail]>; Fri, 27 Sep 2002 10:26:38 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8REPWt88531; Fri, 27 Sep 2002 10:25:32 -0400 (EDT) (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 g8REPSG88520; Fri, 27 Sep 2002 10:25:28 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8REPS502976; Fri, 27 Sep 2002 10:25:28 -0400 (EDT)
Date: Fri, 27 Sep 2002 10:25:28 -0400
From: Jeffrey Haas <[e-mail]>
To: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: Re: issue 11
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 Fri, Sep 27, 2002 at 07:50:10PM +0530
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Sep 27, 2002 at 07:50:10PM +0530, Sivananda Ramnath - CTD, Chennai. wrote:
> % The Loc-RIB SHOULD contain only one route per destination.
> % An implementation may choose to install multiple routes to
> % a destination (for the purposes of load balancing).
> % An implementation doing this MUST ensure that it is
> % interoperable with versions that do not, and MUST
> % ensure that no routing loops or inconsistent routing
> % information is propagated as result of this action. The
> % handling of such a configuration, however, is outside the
> % scope of this RFC.
> 
>    It does seem a little too detailed, though!

My concern is not that this is rope to allow operators to hang themselves
with - this is a gatling gun that allows implementers to try to
guess at useful rules and hose the Internet.  BGP, as a protocol,
is already prone to long-lived loops.  Lets not make it easier to
do this in a way thats harder to troubleshoot.

I haven't thought about this in large amounts of detail, but some
quick observations on what could be done to actually implement
this:

o The routes should be equally preferable - i.e. they need to enter
  the tie-breaking process.
o They should have the same AS_PATH
o Perhaps the path attributes should only be allowed to differ on
  NEXT_HOP.

*If* the above are true, then re-announcing any of the routes used
in the load-balancing should work fine as long as the re-announcement
is going to be a first-party nexthop.  If you have a third-party
nexthop, then you might end up with inconsistant forwarding.

I would propose that this might be something worth investing some
time over, but it shouldn't be mentioned in the base spec.

> Sivanand

-- 
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 KAA07847 for <[e-mail]>; Fri, 27 Sep 2002 10:26:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 07A5E912E0; Fri, 27 Sep 2002 10:26:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C31DC912E9; Fri, 27 Sep 2002 10:26:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98E03912E0 for <[e-mail]>; Fri, 27 Sep 2002 10:26:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7CD495E18B; Fri, 27 Sep 2002 10:26:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 0B19B5E101 for <[e-mail]>; Fri, 27 Sep 2002 10:26:08 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16187; Fri, 27 Sep 2002 10:26:05 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14613; Fri, 27 Sep 2002 10:26:06 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7KK90>; Fri, 27 Sep 2002 10:26:05 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Sivananda Ramnath - CTD, Chennai.'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 11
Date: Fri, 27 Sep 2002 10:26:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

My comment was not based on whether its a new or old feature, but whether we
do a proper job of discribing the consequences of this feature. 

My only point is, saying here is the feature but everything else about it is
outside scope, is not a fair thing to do to a reader.

Thats all,

Regards,
Ben

> -----Original Message-----
> From: Sivananda Ramnath - CTD, Chennai. [mailto:[e-mail]]
> Sent: Friday, September 27, 2002 10:23 AM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: RE: issue 11
> 
> 
> Hello,
> 
>     If it were something new, then we should not get into it 
> only half-way.
> However, there already is support for this feature amongst 
> router vendors,
> and they should not be considered non-compliant on the basis 
> of this issue.
> 
>     After all, we are only documenting current practice, not 
> standardizing
> on new features (in the base spec).
> 
> Sivanand
> ([e-mail])
> 
> 
> > -----Original Message-----
> > From: Abarbanel, Benjamin [mailto:[e-mail]]
> > Sent: Friday, September 27, 2002 7:47 PM
> > To: 'Jeffrey Haas'; Sivananda Ramnath - CTD, Chennai.
> > Cc: [e-mail]
> > Subject: RE: issue 11
> > 
> > 
> > Another observation to this suggestion. Is, OK they are 
> > telling me that I
> > can
> > do load balancing with BGP routes. Well, fine, what kind of 
> > issues will I
> > encounter with BGP if I do that? The answer to this question 
> > should not be
> > out of scope with the spec.
> > 
> > Impacts to other protocols or the forwarding paradigm can be 
> > out of scope
> > with
> > the spec.
> > 
> > Therefore, if we are prepared to cover the subject well, 
> than add it.
> > Otherwise,
> > lets not go there.
> > 
> > IMHO,
> > Ben
> > 
> > > -----Original Message-----
> > > From: Jeffrey Haas [mailto:[e-mail]]
> > > Sent: Friday, September 27, 2002 9:50 AM
> > > To: Sivananda Ramnath - CTD, Chennai.
> > > Cc: [e-mail]
> > > Subject: Re: issue 11
> > > 
> > > 
> > > On Fri, Sep 27, 2002 at 06:06:22PM +0530, Sivananda Ramnath - 
> > > CTD, Chennai. wrote:
> > > >     There is support in some router vendors to allow more 
> > > than one BGP route
> > > > to be installed, for the purpose for load balancing. Given 
> > > that this is a
> > > > current practice, and seems to be a useful feature as well, 
> > > should we insist
> > > > that only one route be installed in the Loc-RIB ? 
> > > 
> > > When more than one instance is installed in the LocRib, how
> > > many instances are distributed to the Adj-Ribs-Out?  Is it 
> > > deterministic?
> > > Does more than one vendor support this mechanism in an 
> interoperable
> > > fashion?
> > > 
> > > >     I would like to suggest that all sections which use 
> > > MUST in the context
> > > > of only one route in Loc-RIB be relaxed a little to a 
> > > SHOULD, and a section
> > > > added that states that it is possible for a n 
> > > implementation to add more
> > > > than one route to the Loc-RIB for the purposes of load 
> balancing.
> > > 
> > > Is it truly adding more than one route to the LocRib or 
> > just the FIB?
> > > 
> > > -- 
> > > 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 KAA07818 for <[e-mail]>; Fri, 27 Sep 2002 10:25:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 36D81912DF; Fri, 27 Sep 2002 10:25:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04038912E0; Fri, 27 Sep 2002 10:25:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C7D00912DF for <[e-mail]>; Fri, 27 Sep 2002 10:25:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9CAA85E18C; Fri, 27 Sep 2002 10:25:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 1349A5E18B for <[e-mail]>; Fri, 27 Sep 2002 10:25:00 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8REOwm29637; Fri, 27 Sep 2002 07:24:58 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 11 
In-Reply-To: Your message of "Fri, 27 Sep 2002 10:08:04 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 27 Sep 2002 07:24:58 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> On Fri, Sep 27, 2002 at 06:56:31AM -0700, Yakov Rekhter wrote:
> >  The handling of such a configuration, however, is outside the
> >  scope of this RFC.
> 
> As far as I know, vendors who support this do some sanity checking
> to make sure that the routes they install will not cause loops.
> 
> If we mention the possibility we shouldn't abrogate the responsibility
> of telling people how to do this without doing Bad Things.

That doesn't mean that we need to tell this in the base spec. A separate
Internet Draft on BGP multipath may be a good place to document this.

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 KAA07635 for <[e-mail]>; Fri, 27 Sep 2002 10:21:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DDF17912DD; Fri, 27 Sep 2002 10:21:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF30A912DF; Fri, 27 Sep 2002 10:21:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C916912DD for <[e-mail]>; Fri, 27 Sep 2002 10:21:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4A4825E180; Fri, 27 Sep 2002 10:21:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id 3E2D05E101 for <[e-mail]>; Fri, 27 Sep 2002 10:21:06 -0400 (EDT)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <TXPHP46V>; Fri, 27 Sep 2002 19:56:42 +0530
Message-ID: <[e-mail]>
From: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 11
Date: Fri, 27 Sep 2002 19:53:17 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hello,

    If it were something new, then we should not get into it only half-way.
However, there already is support for this feature amongst router vendors,
and they should not be considered non-compliant on the basis of this issue.

    After all, we are only documenting current practice, not standardizing
on new features (in the base spec).

Sivanand
([e-mail])


> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]]
> Sent: Friday, September 27, 2002 7:47 PM
> To: 'Jeffrey Haas'; Sivananda Ramnath - CTD, Chennai.
> Cc: [e-mail]
> Subject: RE: issue 11
> 
> 
> Another observation to this suggestion. Is, OK they are 
> telling me that I
> can
> do load balancing with BGP routes. Well, fine, what kind of 
> issues will I
> encounter with BGP if I do that? The answer to this question 
> should not be
> out of scope with the spec.
> 
> Impacts to other protocols or the forwarding paradigm can be 
> out of scope
> with
> the spec.
> 
> Therefore, if we are prepared to cover the subject well, than add it.
> Otherwise,
> lets not go there.
> 
> IMHO,
> Ben
> 
> > -----Original Message-----
> > From: Jeffrey Haas [mailto:[e-mail]]
> > Sent: Friday, September 27, 2002 9:50 AM
> > To: Sivananda Ramnath - CTD, Chennai.
> > Cc: [e-mail]
> > Subject: Re: issue 11
> > 
> > 
> > On Fri, Sep 27, 2002 at 06:06:22PM +0530, Sivananda Ramnath - 
> > CTD, Chennai. wrote:
> > >     There is support in some router vendors to allow more 
> > than one BGP route
> > > to be installed, for the purpose for load balancing. Given 
> > that this is a
> > > current practice, and seems to be a useful feature as well, 
> > should we insist
> > > that only one route be installed in the Loc-RIB ? 
> > 
> > When more than one instance is installed in the LocRib, how
> > many instances are distributed to the Adj-Ribs-Out?  Is it 
> > deterministic?
> > Does more than one vendor support this mechanism in an interoperable
> > fashion?
> > 
> > >     I would like to suggest that all sections which use 
> > MUST in the context
> > > of only one route in Loc-RIB be relaxed a little to a 
> > SHOULD, and a section
> > > added that states that it is possible for a n 
> > implementation to add more
> > > than one route to the Loc-RIB for the purposes of load balancing.
> > 
> > Is it truly adding more than one route to the LocRib or 
> just the FIB?
> > 
> > -- 
> > 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 KAA07585 for <[e-mail]>; Fri, 27 Sep 2002 10:19:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8B949912DA; Fri, 27 Sep 2002 10:19:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC891912DF; Fri, 27 Sep 2002 10:19:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 234F0912DA for <[e-mail]>; Fri, 27 Sep 2002 10:18:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 067765E177; Fri, 27 Sep 2002 10:18:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id E9BCB5E101 for <[e-mail]>; Fri, 27 Sep 2002 10:17:59 -0400 (EDT)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <TXPHP4WV>; Fri, 27 Sep 2002 19:53:35 +0530
Message-ID: <[e-mail]>
From: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>, Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 11 
Date: Fri, 27 Sep 2002 19:50:10 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hello,

    My understanding is that multiple routes would be installed in Loc-RIB
for doing load-balancing, and so would support forwarding using all of these
next-hops.

    That said, specifying what to advertise to other routers also means we
should specify completely the full behavior of this action.

    Perhaps, we can make the comment a bit stronger by saying:

% The Loc-RIB SHOULD contain only one route per destination.
% An implementation may choose to install multiple routes to
% a destination (for the purposes of load balancing).
% An implementation doing this MUST ensure that it is
% interoperable with versions that do not, and MUST
% ensure that no routing loops or inconsistent routing
% information is propagated as result of this action. The
% handling of such a configuration, however, is outside the
% scope of this RFC.

   It does seem a little too detailed, though!

Sivanand
([e-mail])


> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]]
> Sent: Friday, September 27, 2002 7:38 PM
> To: 'Yakov Rekhter'; Jeffrey Haas
> Cc: Sivananda Ramnath - CTD, Chennai.; [e-mail]
> Subject: RE: issue 11 
> 
> 
> My only issue with this is. If we have the multiplicity of 
> several routes
> for the same destination with different next hops in the Loc-RIB, then
> we should state that we must maintain that consistency in 
> each Adj-RIB-out
> that is not policy filtered (DENY) for this destination. 
> Otherwise, we don't
> always advertise to our peers what we really use for forwarding. 
> 
> Ben
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Friday, September 27, 2002 9:57 AM
> > To: Jeffrey Haas
> > Cc: Sivananda Ramnath - CTD, Chennai.; [e-mail]
> > Subject: Re: issue 11 
> > 
> > 
> > Jeff,
> > 
> > > On Fri, Sep 27, 2002 at 06:06:22PM +0530, Sivananda Ramnath 
> > - CTD, Chennai. w
> > rote:
> > > >   There is support in some router vendors to allow more 
> > than one BGP route
> > > > to be installed, for the purpose for load balancing. 
> > Given that this is a
> > > > current practice, and seems to be a useful feature as 
> > well, should we insist
> > > > that only one route be installed in the Loc-RIB ? 
> > > 
> > > When more than one instance is installed in the LocRib, how
> > > many instances are distributed to the Adj-Ribs-Out?  Is it 
> > deterministic?
> > > Does more than one vendor support this mechanism in an 
> interoperable
> > > fashion?
> > 
> > As Sivanand mentioned in his e-mail:
> > 
> >  The handling of such a configuration, however, is outside the
> >  scope of this RFC.
> > 
> > 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 KAA07557 for <[e-mail]>; Fri, 27 Sep 2002 10:19:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CCAA4912DB; Fri, 27 Sep 2002 10:16:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98147912DD; Fri, 27 Sep 2002 10:16:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9A75A912DB for <[e-mail]>; Fri, 27 Sep 2002 10:16:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 86BF25E177; Fri, 27 Sep 2002 10:16:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 0CCE25E101 for <[e-mail]>; Fri, 27 Sep 2002 10:16:57 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15453; Fri, 27 Sep 2002 10:16:54 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10945; Fri, 27 Sep 2002 10:16:55 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7KJ4K>; Fri, 27 Sep 2002 10:16:54 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 11
Date: Fri, 27 Sep 2002 10:16:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Another observation to this suggestion. Is, OK they are telling me that I
can
do load balancing with BGP routes. Well, fine, what kind of issues will I
encounter with BGP if I do that? The answer to this question should not be
out of scope with the spec.

Impacts to other protocols or the forwarding paradigm can be out of scope
with
the spec.

Therefore, if we are prepared to cover the subject well, than add it.
Otherwise,
lets not go there.

IMHO,
Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Friday, September 27, 2002 9:50 AM
> To: Sivananda Ramnath - CTD, Chennai.
> Cc: [e-mail]
> Subject: Re: issue 11
> 
> 
> On Fri, Sep 27, 2002 at 06:06:22PM +0530, Sivananda Ramnath - 
> CTD, Chennai. wrote:
> >     There is support in some router vendors to allow more 
> than one BGP route
> > to be installed, for the purpose for load balancing. Given 
> that this is a
> > current practice, and seems to be a useful feature as well, 
> should we insist
> > that only one route be installed in the Loc-RIB ? 
> 
> When more than one instance is installed in the LocRib, how
> many instances are distributed to the Adj-Ribs-Out?  Is it 
> deterministic?
> Does more than one vendor support this mechanism in an interoperable
> fashion?
> 
> >     I would like to suggest that all sections which use 
> MUST in the context
> > of only one route in Loc-RIB be relaxed a little to a 
> SHOULD, and a section
> > added that states that it is possible for a n 
> implementation to add more
> > than one route to the Loc-RIB for the purposes of load balancing.
> 
> Is it truly adding more than one route to the LocRib or just the FIB?
> 
> -- 
> 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 KAA07166 for <[e-mail]>; Fri, 27 Sep 2002 10:11:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 32CF0912D9; Fri, 27 Sep 2002 10:10:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F03FC912DA; Fri, 27 Sep 2002 10:10:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ADB3C912D9 for <[e-mail]>; Fri, 27 Sep 2002 10:10:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 904795E188; Fri, 27 Sep 2002 10:10:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id 8BBF45E177 for <[e-mail]>; Fri, 27 Sep 2002 10:10:51 -0400 (EDT)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <TXPHP44G>; Fri, 27 Sep 2002 19:46:23 +0530
Message-ID: <[e-mail]>
From: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 11
Date: Fri, 27 Sep 2002 19:42:58 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hello,

    If there is any interest in making this behavior deterministic, this
might be a good candidate for an internet-draft. Is there any WG interest in
working on this ?

Sivanand
([e-mail])


> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Friday, September 27, 2002 7:20 PM
> To: Sivananda Ramnath - CTD, Chennai.
> Cc: [e-mail]
> Subject: Re: issue 11
> 
> 
> On Fri, Sep 27, 2002 at 06:06:22PM +0530, Sivananda Ramnath - 
> CTD, Chennai. wrote:
> >     There is support in some router vendors to allow more 
> than one BGP route
> > to be installed, for the purpose for load balancing. Given 
> that this is a
> > current practice, and seems to be a useful feature as well, 
> should we insist
> > that only one route be installed in the Loc-RIB ? 
> 
> When more than one instance is installed in the LocRib, how
> many instances are distributed to the Adj-Ribs-Out?  Is it 
> deterministic?
> Does more than one vendor support this mechanism in an interoperable
> fashion?
> 
> >     I would like to suggest that all sections which use 
> MUST in the context
> > of only one route in Loc-RIB be relaxed a little to a 
> SHOULD, and a section
> > added that states that it is possible for a n 
> implementation to add more
> > than one route to the Loc-RIB for the purposes of load balancing.
> 
> Is it truly adding more than one route to the LocRib or just the FIB?
> 
> -- 
> 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 KAA07108 for <[e-mail]>; Fri, 27 Sep 2002 10:10:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9B95C912D8; Fri, 27 Sep 2002 10:10:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62E8E912D9; Fri, 27 Sep 2002 10:10:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 799C4912D8 for <[e-mail]>; Fri, 27 Sep 2002 10:10:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5D0505E189; Fri, 27 Sep 2002 10:10:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id D4B3C5E188 for <[e-mail]>; Fri, 27 Sep 2002 10:10:01 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14875; Fri, 27 Sep 2002 10:09:46 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA09473; Fri, 27 Sep 2002 10:08:32 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7KJHY>; Fri, 27 Sep 2002 10:08:32 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, Jeffrey Haas <[e-mail]>
Cc: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>, [e-mail]
Subject: RE: issue 11 
Date: Fri, 27 Sep 2002 10:08:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

My only issue with this is. If we have the multiplicity of several routes
for the same destination with different next hops in the Loc-RIB, then
we should state that we must maintain that consistency in each Adj-RIB-out
that is not policy filtered (DENY) for this destination. Otherwise, we don't
always advertise to our peers what we really use for forwarding. 

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Friday, September 27, 2002 9:57 AM
> To: Jeffrey Haas
> Cc: Sivananda Ramnath - CTD, Chennai.; [e-mail]
> Subject: Re: issue 11 
> 
> 
> Jeff,
> 
> > On Fri, Sep 27, 2002 at 06:06:22PM +0530, Sivananda Ramnath 
> - CTD, Chennai. w
> rote:
> > >   There is support in some router vendors to allow more 
> than one BGP route
> > > to be installed, for the purpose for load balancing. 
> Given that this is a
> > > current practice, and seems to be a useful feature as 
> well, should we insist
> > > that only one route be installed in the Loc-RIB ? 
> > 
> > When more than one instance is installed in the LocRib, how
> > many instances are distributed to the Adj-Ribs-Out?  Is it 
> deterministic?
> > Does more than one vendor support this mechanism in an interoperable
> > fashion?
> 
> As Sivanand mentioned in his e-mail:
> 
>  The handling of such a configuration, however, is outside the
>  scope of this RFC.
> 
> 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 KAA07051 for <[e-mail]>; Fri, 27 Sep 2002 10:08:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 11B2F912D4; Fri, 27 Sep 2002 10:08:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5493912D8; Fri, 27 Sep 2002 10:08:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BD4DB912D4 for <[e-mail]>; Fri, 27 Sep 2002 10:08:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 99F565E188; Fri, 27 Sep 2002 10:08:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id D4C655E177 for <[e-mail]>; Fri, 27 Sep 2002 10:08:11 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8RE88j86686; Fri, 27 Sep 2002 10:08:08 -0400 (EDT) (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 g8RE85G86679; Fri, 27 Sep 2002 10:08:05 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8RE85X02803; Fri, 27 Sep 2002 10:08:05 -0400 (EDT)
Date: Fri, 27 Sep 2002 10:08:04 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>, [e-mail]
Subject: Re: issue 11
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, Sep 27, 2002 at 06:56:31AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Sep 27, 2002 at 06:56:31AM -0700, Yakov Rekhter wrote:
>  The handling of such a configuration, however, is outside the
>  scope of this RFC.

As far as I know, vendors who support this do some sanity checking
to make sure that the routes they install will not cause loops.

If we mention the possibility we shouldn't abrogate the responsibility
of telling people how to do this without doing Bad Things.

> 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 JAA06667 for <[e-mail]>; Fri, 27 Sep 2002 09:58:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4763C912D1; Fri, 27 Sep 2002 09:56:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 025BE912D8; Fri, 27 Sep 2002 09:56:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1BB1B912D1 for <[e-mail]>; Fri, 27 Sep 2002 09:56:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E314C5E186; Fri, 27 Sep 2002 09:56:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 87B715E17C for <[e-mail]>; Fri, 27 Sep 2002 09:56:36 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8RDuVm28203; Fri, 27 Sep 2002 06:56:31 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>, [e-mail]
Subject: Re: issue 11 
In-Reply-To: Your message of "Fri, 27 Sep 2002 09:50:09 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 27 Sep 2002 06:56:31 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> On Fri, Sep 27, 2002 at 06:06:22PM +0530, Sivananda Ramnath - CTD, Chennai. w
rote:
> >   There is support in some router vendors to allow more than one BGP route
> > to be installed, for the purpose for load balancing. Given that this is a
> > current practice, and seems to be a useful feature as well, should we insist
> > that only one route be installed in the Loc-RIB ? 
> 
> When more than one instance is installed in the LocRib, how
> many instances are distributed to the Adj-Ribs-Out?  Is it deterministic?
> Does more than one vendor support this mechanism in an interoperable
> fashion?

As Sivanand mentioned in his e-mail:

 The handling of such a configuration, however, is outside the
 scope of this RFC.

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 JAA06364 for <[e-mail]>; Fri, 27 Sep 2002 09:50:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 890DF912D0; Fri, 27 Sep 2002 09:50:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C8F7912D1; Fri, 27 Sep 2002 09:50:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 51023912D0 for <[e-mail]>; Fri, 27 Sep 2002 09:50:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 27C6E5E184; Fri, 27 Sep 2002 09:50:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 9BAE75E183 for <[e-mail]>; Fri, 27 Sep 2002 09:50:17 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8RDoCN85486; Fri, 27 Sep 2002 09:50:12 -0400 (EDT) (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 g8RDo9G85479; Fri, 27 Sep 2002 09:50:09 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8RDo9302591; Fri, 27 Sep 2002 09:50:09 -0400 (EDT)
Date: Fri, 27 Sep 2002 09:50:09 -0400
From: Jeffrey Haas <[e-mail]>
To: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 11
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 Fri, Sep 27, 2002 at 06:06:22PM +0530
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Sep 27, 2002 at 06:06:22PM +0530, Sivananda Ramnath - CTD, Chennai. wrote:
>     There is support in some router vendors to allow more than one BGP route
> to be installed, for the purpose for load balancing. Given that this is a
> current practice, and seems to be a useful feature as well, should we insist
> that only one route be installed in the Loc-RIB ? 

When more than one instance is installed in the LocRib, how
many instances are distributed to the Adj-Ribs-Out?  Is it deterministic?
Does more than one vendor support this mechanism in an interoperable
fashion?

>     I would like to suggest that all sections which use MUST in the context
> of only one route in Loc-RIB be relaxed a little to a SHOULD, and a section
> added that states that it is possible for a n implementation to add more
> than one route to the Loc-RIB for the purposes of load balancing.

Is it truly adding more than one route to the LocRib or just the FIB?

-- 
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 JAA05549 for <[e-mail]>; Fri, 27 Sep 2002 09:25:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1FEB49125A; Fri, 27 Sep 2002 09:25:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DBB6A9125E; Fri, 27 Sep 2002 09:25:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A1679125A for <[e-mail]>; Fri, 27 Sep 2002 09:25:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4EC8D5E177; Fri, 27 Sep 2002 09:25:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 0FD725E16B for <[e-mail]>; Fri, 27 Sep 2002 09:25:05 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HY72>; Fri, 27 Sep 2002 09:25:04 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Sivananda Ramnath - CTD, Chennai.'" <[e-mail]>, [e-mail]
Cc: Yakov Rekhter <[e-mail]>
Subject: RE: issue 11
Date: Fri, 27 Sep 2002 09:25:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I agree.

-----Original Message-----
From: Sivananda Ramnath - CTD, Chennai. [mailto:[e-mail]] 
Sent: Friday, September 27, 2002 8:36 AM
To: [e-mail]
Cc: Yakov Rekhter
Subject: RE: issue 11

Hello,

    There is support in some router vendors to allow more than one BGP route
to be installed, for the purpose for load balancing. Given that this is a
current practice, and seems to be a useful feature as well, should we insist
that only one route be installed in the Loc-RIB ? 

    I would like to suggest that all sections which use MUST in the context
of only one route in Loc-RIB be relaxed a little to a SHOULD, and a section
added that states that it is possible for a n implementation to add more
than one route to the Loc-RIB for the purposes of load balancing.

    While it will be useful to describe how this situation is the handler,
it is perhaps sufficient to even state that handling of this situation is
outside the scope of this RFC.

   I am including some proposed text for this purpose:

For the part:

>     The Loc-RIB must contain only one route per destination; 

consider instead,

% The Loc-RIB SHOULD contain only one route per destination.
% An implementation may choose to install multiple routes to
% a destination (for the purposes of load balancing). The
% handling of such a configuration, however, is outside the
% scope of this RFC.

Perhaps, this can be in section 3.2 instead.

Sivanand
([e-mail])


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 9:01 PM
> To: [e-mail]
> Subject: issue 11
> 
> 
>   11) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1
>   
> --------------------------------------------------------------
> --------------
>   Status: No Consensus
>   Change: Potentially
>   Summary: Variety of texts proposed to help clear up the 
> rules for moving
>    routes from Loc-RIB into Adj-RIB-Out.
>   
>   Discussion:
>   
>   The "Proxy: comments on section 9.1.3" thread brought up 
> some lack of
>   clarity in the section discussing the rules for which 
> routes get propegated
>   from the Loc-RIB into the Adj-RIB-Out.	These 
> discussions resulted in
>   a number of suggestions for new text.
>   
>   The first new text was proposed to clarify the issue that the thread
>   first brought up:
>   
>   I agree that this could use some clarification. How about adding
>   to b) in section 9.1:
>   
>     The Loc-RIB must contain only one route per destination; 
> further, it
>     must include all routes that the BGP speaker is using.
>   
>   changing c) in section 9.1.2 to:
>   
>     c) is selected as a result of the Phase 2 tie breaking 
> rules specified
>     in 9.1.2.2, or
>   
>   and adding
>   
>     d) when routing protocols other than BGP are in use, is 
> determined by
>     some other local means to be the route that will actually 
> be used to
>     reach a particular destination.
>   
>   This text was never discussed or a consensus formed on 
> putting it in the
>   document.
>   
>   This modification to 9.1.2 was also proposed to address the 
> same concern:
>   
>   How about changing the paragraph after c) in 9.1.2 to:
>   
>     The local speaker SHALL then install that route in the Loc-RIB,
>     replacing any route to the same destination that is 
> currently being
>     held in the Loc-RIB.	This route SHALL then also be 
> installed in
>     the BGP speakers forwarding table.
>   
>   There was one response in the negative to this change, 
> arguing that is
>   is not necessary.
>   
> Wrt "adding to b) in section 9.1", the second part (after ";") is
> redundant as this point is already stated in 3.2. Wrt the first
> point about Loc-RIB containing just one route per destination, I
> would suggest to add it to section 3.2, where Loc-RIB is first
> introduced, rather than adding it to 9.1.
> 
> Wrt "changing c)... and adding...", I have no objections to add/modify
> the text, as suggested above.
> 
> I am not sure though that changing the paragraph after c) in 9.1.2
> is really necessary though, so I would prefer to keep it as is. 
> 
> 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 IAA04548 for <[e-mail]>; Fri, 27 Sep 2002 08:57:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8855591259; Fri, 27 Sep 2002 08:57:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5613B9125D; Fri, 27 Sep 2002 08:57:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2158891259 for <[e-mail]>; Fri, 27 Sep 2002 08:57:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 020765E177; Fri, 27 Sep 2002 08:57:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id D601E5E164 for <[e-mail]>; Fri, 27 Sep 2002 08:57:26 -0400 (EDT)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <TXNL4SHT>; Fri, 27 Sep 2002 18:32:59 +0530
Message-ID: <[e-mail]>
From: "Kaliraj - CTD, Chennai." <[e-mail]>
To: [e-mail]
Subject: ping idr
Date: Fri, 27 Sep 2002 18:29:34 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

TEST_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 IAA03612 for <[e-mail]>; Fri, 27 Sep 2002 08:34:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4832191257; Fri, 27 Sep 2002 08:34:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09C3591259; Fri, 27 Sep 2002 08:34:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9464C91257 for <[e-mail]>; Fri, 27 Sep 2002 08:34:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6F40D5E175; Fri, 27 Sep 2002 08:34:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from ganesh.ctd.hctech.com (unknown [202.54.64.2]) by segue.merit.edu (Postfix) with ESMTP id 84E2D5E06A for <[e-mail]>; Fri, 27 Sep 2002 08:34:13 -0400 (EDT)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <TXNL4R4N>; Fri, 27 Sep 2002 18:09:48 +0530
Message-ID: <[e-mail]>
From: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
To: [e-mail]
Cc: Yakov Rekhter <[e-mail]>
Subject: RE: issue 11
Date: Fri, 27 Sep 2002 18:06:22 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hello,

    There is support in some router vendors to allow more than one BGP route
to be installed, for the purpose for load balancing. Given that this is a
current practice, and seems to be a useful feature as well, should we insist
that only one route be installed in the Loc-RIB ? 

    I would like to suggest that all sections which use MUST in the context
of only one route in Loc-RIB be relaxed a little to a SHOULD, and a section
added that states that it is possible for a n implementation to add more
than one route to the Loc-RIB for the purposes of load balancing.

    While it will be useful to describe how this situation is the handler,
it is perhaps sufficient to even state that handling of this situation is
outside the scope of this RFC.

   I am including some proposed text for this purpose:

For the part:

>     The Loc-RIB must contain only one route per destination; 

consider instead,

% The Loc-RIB SHOULD contain only one route per destination.
% An implementation may choose to install multiple routes to
% a destination (for the purposes of load balancing). The
% handling of such a configuration, however, is outside the
% scope of this RFC.

Perhaps, this can be in section 3.2 instead.

Sivanand
([e-mail])


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 9:01 PM
> To: [e-mail]
> Subject: issue 11
> 
> 
>   11) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1
>   
> --------------------------------------------------------------
> --------------
>   Status: No Consensus
>   Change: Potentially
>   Summary: Variety of texts proposed to help clear up the 
> rules for moving
>    routes from Loc-RIB into Adj-RIB-Out.
>   
>   Discussion:
>   
>   The "Proxy: comments on section 9.1.3" thread brought up 
> some lack of
>   clarity in the section discussing the rules for which 
> routes get propegated
>   from the Loc-RIB into the Adj-RIB-Out.	These 
> discussions resulted in
>   a number of suggestions for new text.
>   
>   The first new text was proposed to clarify the issue that the thread
>   first brought up:
>   
>   I agree that this could use some clarification. How about adding
>   to b) in section 9.1:
>   
>     The Loc-RIB must contain only one route per destination; 
> further, it
>     must include all routes that the BGP speaker is using.
>   
>   changing c) in section 9.1.2 to:
>   
>     c) is selected as a result of the Phase 2 tie breaking 
> rules specified
>     in 9.1.2.2, or
>   
>   and adding
>   
>     d) when routing protocols other than BGP are in use, is 
> determined by
>     some other local means to be the route that will actually 
> be used to
>     reach a particular destination.
>   
>   This text was never discussed or a consensus formed on 
> putting it in the
>   document.
>   
>   This modification to 9.1.2 was also proposed to address the 
> same concern:
>   
>   How about changing the paragraph after c) in 9.1.2 to:
>   
>     The local speaker SHALL then install that route in the Loc-RIB,
>     replacing any route to the same destination that is 
> currently being
>     held in the Loc-RIB.	This route SHALL then also be 
> installed in
>     the BGP speakers forwarding table.
>   
>   There was one response in the negative to this change, 
> arguing that is
>   is not necessary.
>   
> Wrt "adding to b) in section 9.1", the second part (after ";") is
> redundant as this point is already stated in 3.2. Wrt the first
> point about Loc-RIB containing just one route per destination, I
> would suggest to add it to section 3.2, where Loc-RIB is first
> introduced, rather than adding it to 9.1.
> 
> Wrt "changing c)... and adding...", I have no objections to add/modify
> the text, as suggested above.
> 
> I am not sure though that changing the paragraph after c) in 9.1.2
> is really necessary though, so I would prefer to keep it as is. 
> 
> 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 UAA03863 for <[e-mail]>; Thu, 26 Sep 2002 20:07:24 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5A16A91230; Thu, 26 Sep 2002 20:06:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27EB691231; Thu, 26 Sep 2002 20:06:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 05A7891230 for <[e-mail]>; Thu, 26 Sep 2002 20:06:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E0FA85E082; Thu, 26 Sep 2002 20:06:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 6CFB75E020 for <[e-mail]>; Thu, 26 Sep 2002 20:06:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA26155; Thu, 26 Sep 2002 20:06:40 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA23615; Thu, 26 Sep 2002 20:06:42 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7JY1M>; Thu, 26 Sep 2002 20:06:41 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Curtis Villamizar '" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "''Yakov Rekhter' '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: issue 24 
Date: Thu, 26 Sep 2002 20:06:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Curtis:

Comment below

-----Original Message-----
From: Curtis Villamizar
To: Abarbanel, Benjamin
Cc: 'Yakov Rekhter'; [e-mail]
Sent: 9/26/02 12:20 PM
Subject: Re: issue 24 


In message
<[e-mail]>, 
"Abarbanel, Benjamin" writes:
> Yakov,
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Wednesday, September 25, 2002 5:02 PM
> > To: Abarbanel, Benjamin
> > Cc: [e-mail]
> > Subject: Re: issue 24 
> > 
> > 
> > Ben,
> > 
> > > Jeff:
> > > 
> > >   I was just responding to Yakove comment:
> > > 
> > > "By *definition* a route is a <path attribute, NLRI> pair. From
that
> > > definition it follows that changing one or more path attributes of
> > > a route means changing a route, which means withdrawing the old
> > > route (route with the old attributes) from service and advertising
> > > a new route (route with the new attributes)."
> > > 
> > > I think we are playing with words here, 3.1a and 3.1b do not
address
> > > the point as I have argued. Therefore, I am still not satisfied 
> > > we nailed it down in the spec. 
> > > 
> > > As you can see I dont care for assumptions very much.
> > > 
> > > I would like to see this statement added somewhere in section 3.1:
> > > 
> > > "A route's attributes can be added, modified, or deleted by 
> > sending another
> > >  UPDATE message with the same route and the new attributes, or by
> > > withdrawing
> > >  the route (route with the old attributes) from service and 
> > advertising
> > >  a new route (same route with the new attributes)."
> > 
> > If it is "the same route", then *by definition* of a route it 
> > has to be
> > the same attributes. And if the attributes changed, then it 
> > is no longer
> > "the same route". With this in mind how about adding the 
> > following to 3.1:
> > 
> >   Changing attribute of a route means that the route is withdrawn
> >   from service, and a replacement route is advertised. The
replacement
> >   route carries new (changed) attributes and has the same NLRI as
the 
> >   route that was withdrawn.
> > 
> > Yakov.
> > 
> 
>   Can we change the current route's attribute without taking it out of
> service
>   (implying no possible network outage)? 
> 
>   If the answer is yes, than you will need an extra sentence. 
> 
>   If the answer is no, then I am happy with your statement.
> 
> Ben



>>> Ben,

>>> It is an atomic operation.  Text stays the same.  No outage.

>>> Curtis

According to Yakov's email quote:

"  Changing attribute of a route means that the route is withdrawn 
   from service, and a replacement route is advertised. The replacement 
   route carries new (changed) attributes and has the same NLRI as the 
   route that was withdrawn. 

The way I interpret this, is that one message is sent with the route being
withdrawn, followed by another message with the same route being
added with new attributes. The transitions between the two messages could
cause a temporary network outage. Thus the operation is not atomic.

Various implementations could interpret what the spec says and perform
the change with either two messages, or one atomic (replace) message. 
 
Even though its obvious to everyone what is meant stating the specifics is
more helpfull than leaving up to your imagination.

BTW, Yakov's latest response in adding a small paragraph text describing  
     this point, covers this point.

I think we can close this issue with that.

Thanks,
Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA03326 for <[e-mail]>; Thu, 26 Sep 2002 19:57:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DDC409122F; Thu, 26 Sep 2002 19:56:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3AF791230; Thu, 26 Sep 2002 19:56:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B3AE19122F for <[e-mail]>; Thu, 26 Sep 2002 19:56:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9A21E5E080; Thu, 26 Sep 2002 19:56:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 3F7F05E06B for <[e-mail]>; Thu, 26 Sep 2002 19:56:38 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id QAA01302; Thu, 26 Sep 2002 16:53:19 -0700 (PDT)
Date: Thu, 26 Sep 2002 16:53:19 -0700
From: [e-mail]
To: Jeffrey Haas <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: Re: issue 24
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
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Sep 26, 2002 at 11:18:13AM -0400
Sender: [e-mail]
Precedence: bulk

Jeff,

Actually, I think that the proposed text is ok.  If we replace "route"
with "path attribute, NLRI pair" (which is how it is defined) we have
this:

Changing the attributes of a path attribute, NLRI pair is accomplished
by advertising a replacement path attribute, NLRI pair.  The replacement
path attribute, NLRI pair carries new (changed) attributes and has the
same NLRI as the original path attribute, NLRI pair.

Now, I am NOT suggesting we replace "route" in the the text that goes
in the draft, it is too cumbersome.  But, if we look at the substitution
it helps unpack the terms.

Andrew

On Thu, Sep 26, 2002 at 11:18:13AM -0400, Jeffrey Haas wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Date: Thu, 26 Sep 2002 11:18:13 -0400
> From: Jeffrey Haas <[e-mail]>
> To: Yakov Rekhter <[e-mail]>
> Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
> Subject: Re: issue 24
> User-Agent: Mutt/1.2.5i
> In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Sep 25, 2002 at 02:19:28PM -0700
> X-Virus-Scanned: by AMaViS perl-11
> Precedence: bulk
> X-OriginalArrivalTime: 26 Sep 2002 15:20:42.0468 (UTC) FILETIME=[472D2A40:01C26570]
> 
> Yakov, Ben,
> 
> On Wed, Sep 25, 2002 at 02:19:28PM -0700, Yakov Rekhter wrote:
> >    Changing attribute of a route is accomplished by advertising a
> >    replacement route. The replacement route carries new (changed)
> >    attributes and has the same NLRI as the original route.
> 
> My issue with this is that we're defining a route as a path attributes set
> keyed on an NLRI.  In the case of MP-BGP, its also keyed on the AFI/SAFI.
> 
> So, to say that we're "changing attributes" is really saying that we're
> changing the route.
> 
> So, to say that we are withdrawing the previous route (by our
> definition of a route) from service is indeed correct.  Its just the
> fact that we can do so by sending a new path attributes set with
> an existing NLRI key to atomically update it that makes it a "change".
> 
> However, the notion of it being a "change" is probably an implementation
> detail, although one that has strong ties with the MRAI and MAOI times
> and WRD.
> 
> > 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 PAA20059 for <[e-mail]>; Thu, 26 Sep 2002 15:14:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 86907912EB; Thu, 26 Sep 2002 15:13:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F9B091304; Thu, 26 Sep 2002 15:13:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E9165912EB for <[e-mail]>; Thu, 26 Sep 2002 15:13:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C57775E05D; Thu, 26 Sep 2002 15:13:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 54CC85E05B for <[e-mail]>; Thu, 26 Sep 2002 15:13:57 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8QJDum66128 for <[e-mail]>; Thu, 26 Sep 2002 12:13:56 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 32.2
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 12:13:56 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  
  32.2) BGP Desitnation-based Forwarding Paradigm
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Proposal to clarify BGP's support for the destination-based
    forwarding paradigm.  There seems to be consensus that some sort of 
    updated text is good, but there is not yet consensus on which text
    that should be.
  
  Discussion:
  
  In response to these proposals, Yakov proposed that the real problem is that
  it is not clear that BGP is build to support the destination-based
  forwarding paradigm.  To fix this, it was propsed that:
  
  <OLD>
  
     To characterize the set of policy decisions that can be enforced
     using BGP, one must focus on the rule that a BGP speaker advertises
     to its peers (other BGP speakers which it communicates with) in
     neighboring ASs only those routes that it itself uses. This rule
     reflects the "hop-by-hop" routing paradigm generally used
     throughout the current Internet. Note that some policies cannot
     be supported by the "hop-by-hop" routing paradigm and thus
     require techniques such as source routing (aka explicit routing)
     to enforce. For example, BGP does not enable one AS to send
     traffic to a neighboring AS intending that the traffic take a
     different route from that taken by traffic originating in the
     neighboring AS. On the other hand, BGP can support any policy
     conforming to the "hop-by-hop" routing paradigm. Since the
     current Internet uses only the "hop-by-hop" inter-AS routing
     paradigm and since BGP can support any policy that conforms to
     that paradigm, BGP is highly applicable as an inter-AS routing
     protocol for the current Internet.
  
  <NEW>
  
     Routing information exchanged via BGP supports only the
     destination-based forwarding paradigm, which assumes that a
     router forwards a packet based solely on the destination address
     carried in the IP header of the packet. This, in turn reflects
     the set of policy decisions that can (and can not) be enforced
     using BGP. Note that some policies cannot be supported by the
     destination-based forwarding paradigm and thus require techniques
     such as source routing (aka explicit routing) to enforce. Such
     policies can not be enforced using BGP either. For example, BGP
     does not enable one AS to send traffic to a neighboring AS
     intending that the traffic take a different route from that
     taken by traffic originating in the neighboring AS.	On the
     other hand, BGP can support any policy conforming to the
     destination-based forwarding paradigm.
  
  Curtis thinks the newer text here is more clear.
  
  In reponse to the new text, Christian Martin propsed a slightly different
  new text:
  
     Routing information exchanged via BGP supports only the
     destination-based forwarding paradigm, which assumes that a
     router forwards a packet based solely on the destination address
     carried in the IP header of the packet. This, in turn reflects
     the set of policy decisions that can (and can not) be enforces
     using BGP. Note that some policies cannot be supported by the
     destination-based forwarding paradigm and thus require techniques
     such as source routing (aka explicit routing) to enforce. Such
     policies can not be enforced using BGP either. For example, BGP
     does not enable one AS to send traffic to a neighboring AS
     based on prefixes originating from the local AS.  On the
     other hand, BGP can support any policy conforming to the
     destination-based forwarding paradigm.
  
  To which Yakov replied:
  
      Routing information exchanged via BGP supports only the
      destination-based forwarding paradigm, which assumes that a
      router forwards a packet based solely on the destination address
      carried in the IP header of the packet. This, in turn, reflects
      the set of policy decisions that can (and can not) be enforces
      using BGP. Note that some policies cannot be supported by the
      destination-based forwarding paradigm, and thus require techniques
      such as source routing (aka explicit routing) to enforce. Such
      policies can not be enforced using BGP either. For example,
      BGP does not enable one AS to send traffic through a neighboring
      AS to some destination (which is outside of the neighboring
      AS, but is reachable through the neighboring AS) intending that
      the traffic take a different route from that taken by the traffic
      to the same destination that originating in the neighboring AS.
      On the other hand, BGP can support any policy conforming to
      the destination-based forwarding paradigm.
  
  And Chris reponsed:
  
      Routing information exchanged via BGP supports only the
      destination-based forwarding paradigm, which assumes that a
      router forwards a packet based solely on the destination address
      carried in the IP header of the packet. This, in turn, reflects
      the set of policy decisions that can (and can not) be enforces
      using BGP. Note that some policies cannot be supported by the
      destination-based forwarding paradigm, and thus require techniques
      such as source routing (aka explicit routing) to enforce. Such
      policies can not be enforced using BGP either. For example,
      BGP does not enable one AS to send traffic through a neighboring
      AS to some destination beyond the neighboring AS intending that
      the traffic take a different route from that taken by traffic
      to the same destination which originates in the neighboring AS.
      In other words, the BGP policy of a local AS cannot affect the
      downstream (aka, away from the local AS) forwarding policy of a
      remote AS.	On the other hand, BGP can support any policy conforming
      to the destination-based forwarding paradigm.
  
  Tom Petch prefered Yakov's second formulation, with these changes:
  
       policies can not be enforced using BGP either. For example,
       BGP does not enable one AS to send traffic
  !    to a neighboring AS for forwarding to some destination (reachable
  through but) beyond
  !    that neighboring AS intending that
  !    the traffic take a different route to that taken by the traffic
  !    originating in the neighboring AS (for that same destination).
  
       On the other hand, BGP can support any policy conforming to
       the destination-based forwarding paradigm.
  
  Yakov agreed to Tom's suggested changes.

I would suggest we change the status of this item to Consensus
and indicate that the following paragraph

     To characterize the set of policy decisions that can be enforced
     using BGP, one must focus on the rule that a BGP speaker advertises
     to its peers (other BGP speakers which it communicates with) in
     neighboring ASs only those routes that it itself uses. This rule
     reflects the "hop-by-hop" routing paradigm generally used 
     throughout the current Internet. Note that some policies cannot
     be supported by the "hop-by-hop" routing paradigm and thus
     require techniques such as source routing (aka explicit routing)
     to enforce. For example, BGP does not enable one AS to send
     traffic to a neighboring AS intending that the traffic take a
     different route from that taken by traffic originating in the
     neighboring AS. On the other hand, BGP can support any policy
     conforming to the "hop-by-hop" routing paradigm. Since the
     current Internet uses only the "hop-by-hop" inter-AS routing
     paradigm and since BGP can support any policy that conforms to
     that paradigm, BGP is highly applicable as an inter-AS routing
     protocol for the current Internet.


will be replaced in -18 with the following text:

   Routing information exchanged via BGP supports only the
   destination-based forwarding paradigm, which assumes that a
   router forwards a packet based solely on the destination address
   carried in the IP header of the packet. This, in turn, reflects
   the set of policy decisions that can (and can not) be enforced
   using BGP. Note that some policies cannot be supported by the
   destination-based forwarding paradigm, and thus require techniques
   such as source routing (aka explicit routing) to be enforced*.
   Such policies can not be enforced using BGP either. For example,
   BGP does not enable one AS to send traffic to a neighboring AS
   for forwarding to some destination (reachable through but) beyond
   that neighboring AS intending that the traffic take a different
   route to that taken by the traffic originating in the neighboring
   AS (for that same destination).  On the other hand, BGP can
   support any policy conforming to the destination-based forwarding
   paradigm.

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 OAA19068 for <[e-mail]>; Thu, 26 Sep 2002 14:55:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D8DA891302; Thu, 26 Sep 2002 14:55:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA17B91303; Thu, 26 Sep 2002 14:55:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8016691302 for <[e-mail]>; Thu, 26 Sep 2002 14:55:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6180F5E058; Thu, 26 Sep 2002 14:55:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 05D735E057 for <[e-mail]>; Thu, 26 Sep 2002 14:55:26 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8QItPm64300 for <[e-mail]>; Thu, 26 Sep 2002 11:55:25 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 59
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 11:55:25 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  59) Section 4.3 - Move text 
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Proposal to move text around in Section 4.3 has met with one
   agreement and one disagreement.
  
  Discussion:
  
  This began with this suggestion:
  
  The text about the mimimum length, at first look, gives the impression
  that it is still part of the NLRI field description and/or the Path
  Attributes section.  A new "subsection" or heading of some sort would be
  helpfull in switching context back to the UPDATE message as a whole and
  not the path attributes field anymore.

I'll change the indentation to fix this.
  
  Jonathan agreed, and suggested this text:
  
  " The minimum length of the UPDATE message is 23 octets -- 19 octets
     for the fixed header + 2 octets for the Withdrawn Routes Length + 2
     octets for the Total Path Attribute Length (the value of Withdrawn
     Routes Length is 0 and the value of Total Path Attribute Length is
     0)."
  
  Should be moved up to just after
  
  "... the Total Path Attribute Length field and the
           Withdrawn Routes Length field."
  
  Yakov responded to this with:
  
  Disagree, as "... the Total Path Attribute Length field and the
  Withdrawn Routes Length field." explains how to calculate the length
  of NLRI field (and therefore is part of the NLRI field description),
  while "The minimum length of the UPDATE message is 23 octets...."
  has to do with the length of the UPDATE message.
  
  Jonathan also suggested:
  
  " the value of Withdrawn
     Routes Length is 0 and the value of Total Path Attribute Length is
     0)."
   
  Should be changed to
  
  " the min. value of Withdrawn
     Routes Length is 0 and the min. value of Total Path Attribute Length is
     0)."
  
  And Yakov responded with:
  
  Disagree, as the text doesn't talk about what is the minimum value
  of the Withdrawn Routes Length and Total Path Attribute Length
  fields, but talks about the value of these fields in the case of
  a min length UPDATE message. 
  
  There is no consensus.

I would suggest we change the status on this issue to Consensus.

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 OAA19018 for <[e-mail]>; Thu, 26 Sep 2002 14:54:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9ED1C91300; Thu, 26 Sep 2002 14:54:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63EF791302; Thu, 26 Sep 2002 14:54:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D2A5691300 for <[e-mail]>; Thu, 26 Sep 2002 14:54:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C21B75E058; Thu, 26 Sep 2002 14:54:27 -0400 (EDT)
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 5E9FE5E057 for <[e-mail]>; Thu, 26 Sep 2002 14:54:27 -0400 (EDT)
Received: from tom3 (userat01.uk.uudial.com [62.188.137.104]) by shockwave.systems.pipex.net (Postfix) with SMTP id D618E160019F7; Thu, 26 Sep 2002 19:54:21 +0100 (BST)
Message-ID: <030b01c2658d$b538fc40$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: <[e-mail]>, "Yakov Rekhter" <[e-mail]>, "Alex Zinin" <[e-mail]>, "Abarbanel,     Benjamin" <[e-mail]>, "idr" <[e-mail]>
Subject: Re: Generial Editorial Comment 
Date: Thu, 26 Sep 2002 19:50:11 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

I take issue with the 'will attempt to connect' which goes too far.

The FSM defines events 4 and 5, 'with passive Transport
establishment', so the system may wait and not attempt to connect.
The exit from this state is either the receipt of an incoming TCP
connection (SYN) or timer expiry.

So we may have a FSM attempting to transport connect for a given
source/destination IP pair or we may have an FSM not attempting to
connect.  (In the latter case, I do not think we can get a collision).
In the latter case, an incoming connection should not generate an
additional FSM.

I do not believe the concept of active and passive is helpful since a
given system can flip from one to the other and it does not help us to
clarify the number of FSM involved..

Tom Petch
[e-mail]
-----Original Message-----
From: Curtis Villamizar <[e-mail]>
To: Natale, Jonathan <[e-mail]>
Cc: '[e-mail]' <[e-mail]>; Yakov Rekhter
<[e-mail]>; Alex Zinin <[e-mail]>; Abarbanel, Benjamin
<[e-mail]>; [e-mail] <[e-mail]>
Date: 26 September 2002 18:27
Subject: Re: Generial Editorial Comment


>
>In message
<[e-mail]
>ks.com>, "Natale, Jonathan" writes:
>> Wrong.
>>
>> " If the source IP address used
>>    by one of these connections is the same as the destination IP
address
>>    used by the other, and the destination IP address used by the
first
>>    connection is the same as the source IP address used by the
other, we
>>    refer to this situation as connection collision."
>> - draft-ietf-idr-bgp4-17
>
>You're correct in that you must have a collision of IP addresses on
>the TCP connections and that the BGP Identifier is used only to
>resolve which gets dropped.
>
>The FSM stays around as long as "BGP Identifier" is not known.
>Replace "not known with certainty" with "known but the BGP identifier
>is not known" and replace "for the same peer" with "for the same
>configured peering".
>
>The first paragraph is unchanged:
>
>   BGP must maintain separate FSM for each configured peer.  Each BGP
>   peer paired in a potential connection will atempt to connect to
the
>   other.  For the purpose of this discussions, the active or connect
>   side of a TCP connection (the side sending the first TCP SYN
packet)
>   is called outgoing.  The passive or listenning side (the sender of
>   the first SYN ACK) is called the an incoming connection.
>
>The second paragraph becomes:
>
>   A BGP implementation must connect to and listen on TCP port 179
for
>   incoming connections in addition to trying to connect to peers.
>   For each incoming connection, a state machine must be
instantiated.
>   There exists a period in which the identity of the peer on the
>   other end of an incoming connection is known but the BGP
identifier
>   is not known.  During this time, both an incoming and outgoing
>   connection for the same configured peering may exist.  This is
>   referred to as a connection collision (see Section x.x, was 6.8).
>
>The next paragraph then needs to get fixed.  Changed "for each peer"
>to "for each configured peering".
>
>   A BGP implementation will have at most one FSM for each configured
>   peering plus one FSM for each incoming TCP connection for which
the
>   peer has not yet been identified.  Each FSM corresponds to exactly
>   one TCP connection.
>
>Add a paragraph to further clarify the point you made.
>
>   There may be more than one connection between a pair of peers if
>   the connections are configured to use a different pair of IP
>   addresses.  This is referred to as multiple "configured peerings"
>   to the same peer.
>
>> So multiple simultaneous BGP connection are allowed between the
same two
>> peers, and this behavior is implemented, for example to do load
balancing.
>
>Good point.
>
>I hope the corrections above cover your (entirely valid) objections.
>If you see any more errors please let me know.
>
>Curtis
>
>
>> -----Original Message-----
>> From: Curtis Villamizar [mailto:[e-mail]]
>> Sent: Thursday, September 26, 2002 11:34 AM
>> To: Yakov Rekhter
>> Cc: Alex Zinin; Abarbanel, Benjamin; [e-mail]
>> Subject: Re: Generial Editorial Comment
>>
>>
>> In message <[e-mail]>, Yakov
Rekhter
>> writes
>> :
>> > Alex,
>> >
>> > > Defining terms like this in a separate section would be really
nice.
>> > > (BTW, I personally think using "BGP session" which works over a
"TCP
>> > > connection" would be closer to the terminology we're actually
using
>> > > now and would avoid possible confusions when people read terms
like
>> > > "Connection collision") It would also be great if we had
descriptions
>> > > for all data structures that are not explicitly defined (e.g.,
the
>> > > current spec has no notion of a peer data structure), timers,
etc.
>> > >
>> > > Two other things that I think would make sense to explicitly
>> > > define are
>> > >
>> > >    - processing of incoming TCP connections (peer lookup,
acceptance,
>> > >      FSM creation, collision control,)
>> > >
>> > >    - generation of events while processing BGP messages, i.e.,
>> > >      the text describing message processing should say where
>> > >      needed that a specific event for the BGP session should
>> > >      be generated.
>> >
>> > Please suggest the appropriate text.
>> >
>> > yakov.
>>
>>
>>
>> Yakov,
>>
>> Here is some suggestion.  I don't know where in the document you'd
>> like to put this or whether you would prefer to omit it.  That's up
to
>> you.
>>
>>   BGP must maintain separate FSM for each configured peer.  Each
BGP
>>   peer paired in a potential connection will atempt to connect to
the
>>   other.  For the purpose of this discussions, the active or
connect
>>   side of a TCP connection (the side sending the first TCP SYN
packet)
>>   is called outgoing.  The passive or listenning side (the sender
of
>>   the first SYN ACK) is called the an incoming connection.
>>
>>   A BGP implementation must connect to and listen on TCP port 179
for
>>   incoming connections in addition to trying to connect to peers.
For
>>   each incoming connection, a state machine must be instantiated.
>>   There exists a period in which the identity of the peer on the
other
>>   end of an incoming connection is not known with certainty.
During
>>   this time, both an incoming and outgoing connection for the same
>>   peer may exist.  This is referred to as a connection collision
(see
>>   Section x.x, was 6.8).
>>
>>   A BGP implementation will have at most one FSM for each peer plus
>>   one FSM for each incoming TCP connection for which the peer has
not
>>   yet been identified.  Each FSM corresponds to exactly one TCP
>>   connection.
>>
>> The above covers Alex's first request only.
>>
>> 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 OAA18987 for <[e-mail]>; Thu, 26 Sep 2002 14:54:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E7E8B912CE; Thu, 26 Sep 2002 14:53:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 973DB91300; Thu, 26 Sep 2002 14:53:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E23F9912CE for <[e-mail]>; Thu, 26 Sep 2002 14:52:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CABCA5E057; Thu, 26 Sep 2002 14:52:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 6CBBA5DFEF for <[e-mail]>; Thu, 26 Sep 2002 14:52:33 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8QIqXm64105 for <[e-mail]>; Thu, 26 Sep 2002 11:52:33 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 19
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 11:52:33 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

19) Appendix Section 6.2: Processing Messages on a Stream Protocol   
----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: This is a hotly debated issue.  The choices are outlined in
    the discussion.  We can: 1) Leave things the way they are 2)
    Take Curtis's suggestion for change 3) Remove the section entirely.
  
  Discussion:
  
  This first came up in reponse to Issue 17:
  
  There was one comment suggesting that section 6.2 (Processing Messages
  on a Stream Protocol" mentioned this.
  
  The original reviewer reponsed that the out-of-scope comment was out-of-place
  and refered the reponder to section 6.2 (appendix 6)
  
  The original reviewer stated that he is happy with just adding a
  reference to section 6.2 in appendix 6 and leaving it at that.
  
  Curtis suggested we just add a reference to Stevens in appendix 6. 6.2
  and be done with it.  Specifically:
  
    6.2  Processing Messages on a Stream Protocol
  
       BGP uses TCP as a transport mechanism.  If you are unsure as to
       how to handle asynchronous reads and writes on TCP sockets please
       refer to Unix Network Programming [RWStevens] or other
       introductory text for programming techniques for the operating
       system and TCP implementation that you are using.
  
  There were further suggestions to remove the section entirely as out-of-scope.
  At least 3 people agreed with this.
  
  Alex responded that he sees no reason to remove it, but wouldn't have a
  problem if the WG decides to do so.

Since there was no objections to removing Appendix 6.2, I would suggest
we change the status to "Consensus" and indicate that Appendix 6.2
will be removed in the -18 version.

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 OAA18818 for <[e-mail]>; Thu, 26 Sep 2002 14:51:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 63D2891312; Thu, 26 Sep 2002 14:50:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 331CB9130D; Thu, 26 Sep 2002 14:50:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ABADA91312 for <[e-mail]>; Thu, 26 Sep 2002 14:50:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 926D75E055; Thu, 26 Sep 2002 14:50:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 087FD5DFEF for <[e-mail]>; Thu, 26 Sep 2002 14:50:01 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8QInwm63885 for <[e-mail]>; Thu, 26 Sep 2002 11:49:58 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 11.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 11:49:58 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  11.1) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Variety of texts proposed to help clear up the rules for moving
   routes from Loc-RIB into Adj-RIB-Out.
  
  Discussion:
  
  In further discussions around this issue, this text was also proposed:
  
  How about adding to section 9.1.3, at the end:
  
    Any local-policy which results in reachability being added to an
    Adj-RIB-Out without also being added to the local BGP speaker's
    forwarding table is beyond the scope of this document.
  
  This suggestion received one response that agreed to this change.

I think that the Status should be changed to Consensus, and indicate
that the text proposed above will be added to -18 version.

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 OAA18645 for <[e-mail]>; Thu, 26 Sep 2002 14:47:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BB12791307; Thu, 26 Sep 2002 14:44:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 370A291303; Thu, 26 Sep 2002 14:44:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6884491307 for <[e-mail]>; Thu, 26 Sep 2002 14:44:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 516845E057; Thu, 26 Sep 2002 14:44:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id EAAA55E04D for <[e-mail]>; Thu, 26 Sep 2002 14:44:22 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8QIiMm63196 for <[e-mail]>; Thu, 26 Sep 2002 11:44:22 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 27
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 11:44:22 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  27) Allow All Non-Destructive Messages to Refresh Hold Timer
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: It is agreed that this is a change that exceeds the original
    goal of this draft revision.  This goal is to document existing
    practice in an interoperable way.  If we should do it anyway has not
    been decided.
  
  Discussion:
  
  3. P. 29, Section 6.5, Please rewrite this sentence from:
      "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 ..."
  
   To This:
      "If a system does not receive successive KEEPALIVE and/or UPDATE
          and/or any other BGP message within the period specified in the Hold
          Time field of the OPEN message ..."
  
  There is disagreement on this change. It has been discussed in other
  threads.
  
  The original commentor acknowledged that this is something that would
  be "adding a new feature" as opposed to the stated goal of "documenting
  what exists."  He suggested that the ADs decide if we should open the
  door for new features or not.

Folks, I would suggest we keep the text as is, as the purpose of the
document is to specify what is implemented. 

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 OAA17143 for <[e-mail]>; Thu, 26 Sep 2002 14:16:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 03A3D912FF; Thu, 26 Sep 2002 14:15:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC8BF91302; Thu, 26 Sep 2002 14:15:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A02C912FF for <[e-mail]>; Thu, 26 Sep 2002 14:15:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2D6945E038; Thu, 26 Sep 2002 14:15:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from monet.titania.net (enter.titania.net [192.133.102.254]) by segue.merit.edu (Postfix) with ESMTP id 4EE155DFE1 for <[e-mail]>; Thu, 26 Sep 2002 14:15:44 -0400 (EDT)
Received: from morisot.titania.net (morisot [192.133.102.10]) (authenticated bits=0) by monet.titania.net (8.12.5/8.12.3) with ESMTP id g8QIIuTg042104 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 Sep 2002 18:18:57 GMT (envelope-from [e-mail])
Date: Thu, 26 Sep 2002 18:16:17 -0000
From: "Joseph T. Klein" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "'Randy Bush'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 21
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/2.2.0 (Mac OS X)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========40629931=========="
Sender: [e-mail]
Precedence: bulk

--==========40629931==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Eric,

It is RFC2385 and it is frequently used between vendor C and
vendor J. I suspect others will be happy to correct me if I am wrong.

I apologize if my comment was ambiguous and furthered confusion.

I agree with Yakov on the text.

--On Thursday, 26 September 2002 13:36 -0400 "Gray, Eric" <[e-mail]> wrote:

> Joseph,
>
> 	Thanks, but this does not actually answer my question.
>
> 	The question is not whether MD5 authentication is used,
> it is how is it implemented in real BGP implementations or -
> more importantly - where is the authentication information
> located in the packets sent between two BGP peers?  This is
> not strictly an implementation issue because authentication
> information is located in different places depending on which
> version of MD5 authentication is in use.
>
> 	As is generally known, options are not necessarily good.
> Currently, between RFC 1771 and RFC 2385, there are two very
> distinct ways to accomplish a semantically identical function.
> If the mechanism defined in RFC 1771 is not supported by a
> number of interoperable implementations, it must be deprecated
> per RFC 2026 prior to advancing the specification to Draft
> Standard.  If it is not implemented and actually in use, it
> should be deprecated if for no other reason than to make the
> operator's life easier.
>
> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> [e-mail]
> 508 305 7214
>
>
>> -----Original Message-----
>> From: Joseph T. Klein [mailto:[e-mail]]
>> Sent: Thursday, September 26, 2002 1:16 PM
>> To: Gray, Eric; 'Randy Bush'; Natale, Jonathan
>> Cc: 'Yakov Rekhter'; [e-mail]
>> Subject: RE: issue 21
>>
>> An operators 2 cents.
>>
>> In the case of AS19548, almost all inter domain peers are configured
>> using MD5 authentication-key. We have found only a few organizations
>> that have issue with using an authetication key.
>>
>> --On Thursday, 26 September 2002 13:01 -0400 "Gray, Eric"
>> <[e-mail]> wrote:
>>
>> > Randy,
>> >
>> > 	Operators use which form of BGP Authentication?   TCP
>> > native (RFC 2385) or BGP's 'own' authentication?  It would
>> > be nice if we could be precise...
>> >
>> > Eric W. Gray
>> > Systems Architect
>> > Celox Networks, Inc.
>> > [e-mail]
>> > 508 305 7214
>> >
>> >
>> >> -----Original Message-----
>> >> From: Randy Bush [mailto:[e-mail]]
>> >> Sent: Thursday, September 26, 2002 12:48 PM
>> >> To: Natale, Jonathan
>> >> Cc: 'Yakov Rekhter'; [e-mail]
>> >> Subject: RE: issue 21
>> >>
>> >> > Who uses bgp authentication?  I though it was nobody.
>> >>
>> >> you were incorrect in that thought.  prudent operators do use it,
>> >> and some large ones have for some years now.
>> >>
>> >> randy
>> >
>>
>>
>>
>> --
>> Joseph T. Klein                                         [e-mail]
>>
>>                         "g/Class C/s//\/24/g"
>



--
Joseph T. Klein                                         [e-mail]

                        "g/Class C/s//\/24/g"
--==========40629931==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iD8DBQE9k08GhAQUND5rRrMRAs5DAJ4k85uWGLeSqLXVVpnYR8DJ3P1qgwCcDuSM
clF3T//naA2xVqwsNEnR3Ck=
=u0GC
-----END PGP SIGNATURE-----

--==========40629931==========--



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA16988 for <[e-mail]>; Thu, 26 Sep 2002 14:13:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DAB81912FE; Thu, 26 Sep 2002 14:12:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7D23912FF; Thu, 26 Sep 2002 14:12:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A63A3912FE for <[e-mail]>; Thu, 26 Sep 2002 14:12:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 851E35E035; Thu, 26 Sep 2002 14:12:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id C85765DFE1 for <[e-mail]>; Thu, 26 Sep 2002 14:12:56 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8QICiP63327; Thu, 26 Sep 2002 14:12:44 -0400 (EDT) (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 g8QICfG63316; Thu, 26 Sep 2002 14:12:41 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8QICfd25227; Thu, 26 Sep 2002 14:12:41 -0400 (EDT)
Date: Thu, 26 Sep 2002 14:12:41 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: issue 58
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 Thu, Sep 26, 2002 at 10:56:55AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Sep 26, 2002 at 10:56:55AM -0700, Yakov Rekhter wrote:
> > If reality is that it is informational only, then just remove the
> > MUSTs and indicate that it is informational.
> 
> Could you please propose the text.

FWIW, I believe my suggested changes might already cover this.

> 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 OAA16452 for <[e-mail]>; Thu, 26 Sep 2002 14:03:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0484391303; Thu, 26 Sep 2002 14:01:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B2E791300; Thu, 26 Sep 2002 14:01:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 05AB3912FA for <[e-mail]>; Thu, 26 Sep 2002 14:01:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E49F45DFF1; Thu, 26 Sep 2002 14:01:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 9019B5DFE1 for <[e-mail]>; Thu, 26 Sep 2002 14:01:44 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HVGD>; Thu, 26 Sep 2002 14:01:44 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Randy Bush'" <[e-mail]>, "Gray, Eric" <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 21
Date: Thu, 26 Sep 2002 14:01:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

In reference to issue 21, I agree with Yakov that it does not need to be
added since there was already a reference to MD5.  If we start repeating
ourselves, the doc will be huge--it is already 66 pages!

I still feel strongly that the bgp auth. opt. should be depreciated.

:-)

-----Original Message-----
From: Randy Bush [mailto:[e-mail]] 
Sent: Thursday, September 26, 2002 1:32 PM
To: Gray, Eric
Cc: Natale, Jonathan; 'Yakov Rekhter'; [e-mail]
Subject: RE: issue 21

> 	Operators use which form of BGP Authentication?   TCP
> native (RFC 2385) or BGP's 'own' authentication?

we are precise.  look at issue 21.

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 NAA16214 for <[e-mail]>; Thu, 26 Sep 2002 13:58:21 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F2124912F9; Thu, 26 Sep 2002 13:57:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8B31912FD; Thu, 26 Sep 2002 13:57:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 263DB912F9 for <[e-mail]>; Thu, 26 Sep 2002 13:57:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0F90B5E02F; Thu, 26 Sep 2002 13:57:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id A62955E013 for <[e-mail]>; Thu, 26 Sep 2002 13:57:03 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8QHutm57918; Thu, 26 Sep 2002 10:56:56 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: issue 58 
In-Reply-To: Your message of "Thu, 26 Sep 2002 12:46:11 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 10:56:55 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Curtis,

> >   58) Deprication of ATOMIC_AGGREGATE
> >   -------------------------------------------------------------------------
> >   Status: No Consensus
> >   Change: Potentially
> >   Summary: It is proposed that ATOMIC_AGGREGATE be depricated.  There has 
> >    not yet been any discussion on the proposed changes.
> > 
> > Comments on this issue would be appreciated.
> > 
> > In the absence of any objections to the changes proposed by Jeff, the
> > changes would be accepted. 
> > 
> > Yakov.
> 
> 
> We used to add ATOMIC_AGGREGATE whenever the AS_PATH was truncated
> rather than replaced with an AS_SET.  It was always purely
> informational since no one intentionally deaggregated and reannounced.
> Don't implementations still support this?
> 
> If reality is that it is informational only, then just remove the
> MUSTs and indicate that it is informational.

Could you please propose 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 NAA15884 for <[e-mail]>; Thu, 26 Sep 2002 13:52:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DC6029122B; Thu, 26 Sep 2002 13:51:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A634E912E5; Thu, 26 Sep 2002 13:51:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 818FB9122B for <[e-mail]>; Thu, 26 Sep 2002 13:51:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 68BCD5E02B; Thu, 26 Sep 2002 13:51:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id E5F4A5E013 for <[e-mail]>; Thu, 26 Sep 2002 13:51:31 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8QHpUm57276; Thu, 26 Sep 2002 10:51:30 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Cc: [e-mail]
Subject: deprecating rfc1771 authentication
In-Reply-To: Your message of "Thu, 26 Sep 2002 13:36:28 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 10:51:30 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Eric,

[changed subject, as to avoid confusion with issue 21].

> Joseph,
> 
> 	Thanks, but this does not actually answer my question.
> 
> 	The question is not whether MD5 authentication is used,
> it is how is it implemented in real BGP implementations or -
> more importantly - where is the authentication information 
> located in the packets sent between two BGP peers?  This is
> not strictly an implementation issue because authentication
> information is located in different places depending on which
> version of MD5 authentication is in use.
> 
> 	As is generally known, options are not necessarily good.
> Currently, between RFC 1771 and RFC 2385, there are two very
> distinct ways to accomplish a semantically identical function.
> If the mechanism defined in RFC 1771 is not supported by a
> number of interoperable implementations, it must be deprecated
> per RFC 2026 prior to advancing the specification to Draft
> Standard.  

To be more precise, 

   In cases in which one or more options or features have not been
   demonstrated in at least two interoperable implementations, the
   specification may advance to the Draft Standard level only if 
   those options or features are removed.

So, the relevant question is whether we have at least two implementations
that support authentication as described in rfc1771.

Folks who implemented authentication, as described in rfc1771,
please speak up.

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 NAA15328 for <[e-mail]>; Thu, 26 Sep 2002 13:39:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C2263912F6; Thu, 26 Sep 2002 13:39:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 934D1912F7; Thu, 26 Sep 2002 13:39:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 24334912F6 for <[e-mail]>; Thu, 26 Sep 2002 13:39:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1254A5E028; Thu, 26 Sep 2002 13:39:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 951F35E026 for <[e-mail]>; Thu, 26 Sep 2002 13:39:23 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HVDH>; Thu, 26 Sep 2002 13:39:23 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Randy Bush'" <[e-mail]>, "Gray, Eric" <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 21
Date: Thu, 26 Sep 2002 13:39:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Randy,

	I have - as would be obvious, if you read my other comments
on this thread.  Please do that.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Randy Bush [mailto:[e-mail]]
> Sent: Thursday, September 26, 2002 1:32 PM
> To: Gray, Eric
> Cc: Natale, Jonathan; 'Yakov Rekhter'; [e-mail]
> Subject: RE: issue 21
> 
> > 	Operators use which form of BGP Authentication?   TCP
> > native (RFC 2385) or BGP's 'own' authentication?
> 
> we are precise.  look at issue 21.
> 
> 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 NAA15308 for <[e-mail]>; Thu, 26 Sep 2002 13:39:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B1602912F3; Thu, 26 Sep 2002 13:36:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C1A0912F7; Thu, 26 Sep 2002 13:36:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3D623912F3 for <[e-mail]>; Thu, 26 Sep 2002 13:36:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2B5A75E015; Thu, 26 Sep 2002 13:36:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id B711E5DFEA for <[e-mail]>; Thu, 26 Sep 2002 13:36:33 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HVC8>; Thu, 26 Sep 2002 13:36:33 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Joseph T. Klein'" <[e-mail]>, "Gray, Eric" <[e-mail]>, "'Randy Bush'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 21
Date: Thu, 26 Sep 2002 13:36:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Joseph,

	Thanks, but this does not actually answer my question.

	The question is not whether MD5 authentication is used,
it is how is it implemented in real BGP implementations or -
more importantly - where is the authentication information 
located in the packets sent between two BGP peers?  This is
not strictly an implementation issue because authentication
information is located in different places depending on which
version of MD5 authentication is in use.

	As is generally known, options are not necessarily good.
Currently, between RFC 1771 and RFC 2385, there are two very
distinct ways to accomplish a semantically identical function.
If the mechanism defined in RFC 1771 is not supported by a
number of interoperable implementations, it must be deprecated
per RFC 2026 prior to advancing the specification to Draft
Standard.  If it is not implemented and actually in use, it
should be deprecated if for no other reason than to make the
operator's life easier.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Joseph T. Klein [mailto:[e-mail]]
> Sent: Thursday, September 26, 2002 1:16 PM
> To: Gray, Eric; 'Randy Bush'; Natale, Jonathan
> Cc: 'Yakov Rekhter'; [e-mail]
> Subject: RE: issue 21
> 
> An operators 2 cents.
> 
> In the case of AS19548, almost all inter domain peers are configured
> using MD5 authentication-key. We have found only a few organizations
> that have issue with using an authetication key.
> 
> --On Thursday, 26 September 2002 13:01 -0400 "Gray, Eric"
> <[e-mail]> wrote:
> 
> > Randy,
> >
> > 	Operators use which form of BGP Authentication?   TCP
> > native (RFC 2385) or BGP's 'own' authentication?  It would
> > be nice if we could be precise...
> >
> > Eric W. Gray
> > Systems Architect
> > Celox Networks, Inc.
> > [e-mail]
> > 508 305 7214
> >
> >
> >> -----Original Message-----
> >> From: Randy Bush [mailto:[e-mail]]
> >> Sent: Thursday, September 26, 2002 12:48 PM
> >> To: Natale, Jonathan
> >> Cc: 'Yakov Rekhter'; [e-mail]
> >> Subject: RE: issue 21
> >>
> >> > Who uses bgp authentication?  I though it was nobody.
> >>
> >> you were incorrect in that thought.  prudent operators do use it,
> >> and some large ones have for some years now.
> >>
> >> randy
> >
> 
> 
> 
> --
> Joseph T. Klein                                         [e-mail]
> 
>                         "g/Class C/s//\/24/g"


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA15033 for <[e-mail]>; Thu, 26 Sep 2002 13:32:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A2927912F5; Thu, 26 Sep 2002 13:31:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65842912F6; Thu, 26 Sep 2002 13:31:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E86B6912F5 for <[e-mail]>; Thu, 26 Sep 2002 13:31:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D007E5E015; Thu, 26 Sep 2002 13:31:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id A247D5DFEA for <[e-mail]>; Thu, 26 Sep 2002 13:31:47 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17ucUN-0006fM-00; Thu, 26 Sep 2002 10:31:47 -0700
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Gray, Eric" <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 21
References: <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 26 Sep 2002 10:31:47 -0700
Sender: [e-mail]
Precedence: bulk

> 	Operators use which form of BGP Authentication?   TCP
> native (RFC 2385) or BGP's 'own' authentication?

we are precise.  look at issue 21.

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 NAA14895 for <[e-mail]>; Thu, 26 Sep 2002 13:28:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A9A75912CD; Thu, 26 Sep 2002 13:27:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74B9C912E7; Thu, 26 Sep 2002 13:27:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 268A3912CD for <[e-mail]>; Thu, 26 Sep 2002 13:27:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0474B5E013; Thu, 26 Sep 2002 13:27:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 681715DFEA for <[e-mail]>; Thu, 26 Sep 2002 13:27:43 -0400 (EDT)
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 NAA91126; Thu, 26 Sep 2002 13:27:22 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, Yakov Rekhter <[e-mail]>, Alex Zinin <[e-mail]>, "Abarbanel,     Benjamin" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Generial Editorial Comment 
In-reply-to: Your message of "Thu, 26 Sep 2002 12:11:55 EDT." <[e-mail]> 
Date: Thu, 26 Sep 2002 13:27:21 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> Wrong.
> 
> " If the source IP address used
>    by one of these connections is the same as the destination IP address
>    used by the other, and the destination IP address used by the first
>    connection is the same as the source IP address used by the other, we
>    refer to this situation as connection collision."
> - draft-ietf-idr-bgp4-17

You're correct in that you must have a collision of IP addresses on
the TCP connections and that the BGP Identifier is used only to
resolve which gets dropped.

The FSM stays around as long as "BGP Identifier" is not known.
Replace "not known with certainty" with "known but the BGP identifier
is not known" and replace "for the same peer" with "for the same
configured peering".

The first paragraph is unchanged:

   BGP must maintain separate FSM for each configured peer.  Each BGP
   peer paired in a potential connection will atempt to connect to the
   other.  For the purpose of this discussions, the active or connect
   side of a TCP connection (the side sending the first TCP SYN packet)
   is called outgoing.  The passive or listenning side (the sender of
   the first SYN ACK) is called the an incoming connection.

The second paragraph becomes:

   A BGP implementation must connect to and listen on TCP port 179 for
   incoming connections in addition to trying to connect to peers.
   For each incoming connection, a state machine must be instantiated.
   There exists a period in which the identity of the peer on the
   other end of an incoming connection is known but the BGP identifier
   is not known.  During this time, both an incoming and outgoing
   connection for the same configured peering may exist.  This is
   referred to as a connection collision (see Section x.x, was 6.8).

The next paragraph then needs to get fixed.  Changed "for each peer"
to "for each configured peering".

   A BGP implementation will have at most one FSM for each configured
   peering plus one FSM for each incoming TCP connection for which the
   peer has not yet been identified.  Each FSM corresponds to exactly
   one TCP connection.

Add a paragraph to further clarify the point you made.

   There may be more than one connection between a pair of peers if
   the connections are configured to use a different pair of IP
   addresses.  This is referred to as multiple "configured peerings"
   to the same peer.

> So multiple simultaneous BGP connection are allowed between the same two
> peers, and this behavior is implemented, for example to do load balancing.

Good point.

I hope the corrections above cover your (entirely valid) objections.
If you see any more errors please let me know.

Curtis


> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]] 
> Sent: Thursday, September 26, 2002 11:34 AM
> To: Yakov Rekhter
> Cc: Alex Zinin; Abarbanel, Benjamin; [e-mail]
> Subject: Re: Generial Editorial Comment 
> 
> 
> In message <[e-mail]>, Yakov Rekhter
> writes
> :
> > Alex,
> > 
> > > Defining terms like this in a separate section would be really nice.
> > > (BTW, I personally think using "BGP session" which works over a "TCP
> > > connection" would be closer to the terminology we're actually using
> > > now and would avoid possible confusions when people read terms like
> > > "Connection collision") It would also be great if we had descriptions
> > > for all data structures that are not explicitly defined (e.g., the
> > > current spec has no notion of a peer data structure), timers, etc.
> > > 
> > > Two other things that I think would make sense to explicitly
> > > define are
> > > 
> > >    - processing of incoming TCP connections (peer lookup, acceptance,
> > >      FSM creation, collision control,)
> > > 
> > >    - generation of events while processing BGP messages, i.e.,
> > >      the text describing message processing should say where
> > >      needed that a specific event for the BGP session should
> > >      be generated.
> > 
> > Please suggest the appropriate text.
> > 
> > yakov.
> 
> 
> 
> Yakov,
> 
> Here is some suggestion.  I don't know where in the document you'd
> like to put this or whether you would prefer to omit it.  That's up to
> you.
> 
>   BGP must maintain separate FSM for each configured peer.  Each BGP
>   peer paired in a potential connection will atempt to connect to the
>   other.  For the purpose of this discussions, the active or connect
>   side of a TCP connection (the side sending the first TCP SYN packet)
>   is called outgoing.  The passive or listenning side (the sender of
>   the first SYN ACK) is called the an incoming connection.
> 
>   A BGP implementation must connect to and listen on TCP port 179 for
>   incoming connections in addition to trying to connect to peers.  For
>   each incoming connection, a state machine must be instantiated.
>   There exists a period in which the identity of the peer on the other
>   end of an incoming connection is not known with certainty.  During
>   this time, both an incoming and outgoing connection for the same
>   peer may exist.  This is referred to as a connection collision (see
>   Section x.x, was 6.8).
> 
>   A BGP implementation will have at most one FSM for each peer plus
>   one FSM for each incoming TCP connection for which the peer has not
>   yet been identified.  Each FSM corresponds to exactly one TCP
>   connection.
> 
> The above covers Alex's first request only.
> 
> 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 NAA14374 for <[e-mail]>; Thu, 26 Sep 2002 13:16:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 95F47912F4; Thu, 26 Sep 2002 13:14:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58CBF912F7; Thu, 26 Sep 2002 13:14:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B1D55912F4 for <[e-mail]>; Thu, 26 Sep 2002 13:14:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A008F5E025; Thu, 26 Sep 2002 13:14:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from monet.titania.net (enter.titania.net [192.133.102.254]) by segue.merit.edu (Postfix) with ESMTP id 11C3D5E021 for <[e-mail]>; Thu, 26 Sep 2002 13:14:40 -0400 (EDT)
Received: from morisot.titania.net (morisot [192.133.102.10]) (authenticated bits=0) by monet.titania.net (8.12.5/8.12.3) with ESMTP id g8QHHoTg041868 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 Sep 2002 17:17:51 GMT (envelope-from [e-mail])
Date: Thu, 26 Sep 2002 17:15:31 -0000
From: "Joseph T. Klein" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "'Randy Bush'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 21
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: Mulberry/2.2.0 (Mac OS X)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========40416163=========="
Sender: [e-mail]
Precedence: bulk

--==========40416163==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

An operators 2 cents.

In the case of AS19548, almost all inter domain peers are configured
using MD5 authentication-key. We have found only a few organizations
that have issue with using an authetication key.

--On Thursday, 26 September 2002 13:01 -0400 "Gray, Eric" <[e-mail]> wrote:

> Randy,
>
> 	Operators use which form of BGP Authentication?   TCP
> native (RFC 2385) or BGP's 'own' authentication?  It would
> be nice if we could be precise...
>
> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> [e-mail]
> 508 305 7214
>
>
>> -----Original Message-----
>> From: Randy Bush [mailto:[e-mail]]
>> Sent: Thursday, September 26, 2002 12:48 PM
>> To: Natale, Jonathan
>> Cc: 'Yakov Rekhter'; [e-mail]
>> Subject: RE: issue 21
>>
>> > Who uses bgp authentication?  I though it was nobody.
>>
>> you were incorrect in that thought.  prudent operators do use it,
>> and some large ones have for some years now.
>>
>> randy
>



--
Joseph T. Klein                                         [e-mail]

                        "g/Class C/s//\/24/g"
--==========40416163==========
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see http://www.gnupg.org

iD8DBQE9k0C0hAQUND5rRrMRAmvUAJ9tjB8AtzIwVkhtr8dFMy1BRXkvuQCcDywZ
53dSJzL30UCsOTJbBKL/fEA=
=FHjk
-----END PGP SIGNATURE-----

--==========40416163==========--



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA13873 for <[e-mail]>; Thu, 26 Sep 2002 13:06:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 73DFE912ED; Thu, 26 Sep 2002 13:06:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43366912F2; Thu, 26 Sep 2002 13:06:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3B97B912ED for <[e-mail]>; Thu, 26 Sep 2002 13:06:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2598A5E022; Thu, 26 Sep 2002 13:06:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 9844B5E021 for <[e-mail]>; Thu, 26 Sep 2002 13:06:19 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8QH6IL61383; Thu, 26 Sep 2002 13:06:18 -0400 (EDT) (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 g8QH6EG61373; Thu, 26 Sep 2002 13:06:14 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8QH6EK24880; Thu, 26 Sep 2002 13:06:14 -0400 (EDT)
Date: Thu, 26 Sep 2002 13:06:14 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: issue 58
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, Sep 26, 2002 at 01:00:57PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Sep 26, 2002 at 01:00:57PM -0400, Natale, Jonathan wrote:
> AFAIK, yes, that is what IOS does--which does not match the draft.

It does:
   When a router aggregates several routes for the purpose of
   advertisement to a particular peer, and the AS_PATH of the aggregated
   route excludes at least some of the AS numbers present in the AS_PATH
   of the routes that are aggregated, the aggregated route, when
   advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.

> I agree with Curtis, changing the wording to indicate that it is
> informational and/or to match current implementations (what does Juniper
> do?) is better than depreciating it.

See their "brief" option.

> I don't think to actually does anything other than let the administrator
> know it was truncated, but I am not 100% sure on this.

What it does is causes aggregate routes to potentially be candidates
for causing loops.  In practice, this isn't too much of
an issue since the more specific components are usually present
everywhere that they are necessary.


-- 
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 NAA13771 for <[e-mail]>; Thu, 26 Sep 2002 13:04:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DD97C912EE; Thu, 26 Sep 2002 13:03:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D091912F2; Thu, 26 Sep 2002 13:03:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BFA60912EE for <[e-mail]>; Thu, 26 Sep 2002 13:02:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A42665E010; Thu, 26 Sep 2002 13:02:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 64E1C5DFEF for <[e-mail]>; Thu, 26 Sep 2002 13:02:42 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1H49G>; Thu, 26 Sep 2002 13:02:42 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: Depeciate BGP Authentication 
Date: Thu, 26 Sep 2002 13:02:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Yakov,

	Yes, but as I already pointed out, this comment was made.

	If you want to list this as a separate issue, that's fine
but it should be included because the comment was made numerous
times before the dead-line.

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Thursday, September 26, 2002 12:52 PM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: Depeciate BGP Authentication
> 
> Jonathan,
> 
> > Ok, sorry.  Do we have an item to depreciate bgp auth.?  Can we add one
> > please?
> 
> The (extended) deadline for comments was Sep 23.
> 
> Yakov.
> 
> >
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Thursday, September 26, 2002 12:37 PM
> > To: Natale, Jonathan
> > Cc: [e-mail]
> > Subject: Re: issue 21
> >
> > Jonathan,
> >
> > > Yes, you are wrong.  Of course there could be a special build that
> does
> > it.
> > >
> > > I still think the bgp auth. option should be depreciated.
> >
> > Please note that the subject of the discussion is issue 21. This issue
> > has *nothing to do* with deprecating the bgp auth option - it has
> > to do with adding a sentence pointing that one could use rfc2385.
> >
> > Yakov.
> >
> > >
> > > -----Original Message-----
> > > From: Kunihiro Ishiguro [mailto:[e-mail]]
> > > Sent: Thursday, September 26, 2002 12:29 PM
> > > To: Natale, Jonathan
> > > Cc: 'Yakov Rekhter'; [e-mail]
> > > Subject: Re: issue 21
> > >
> > > >Issue 21's main point is mentioning MD5 authentication along with BGP
> > > >own password auth.  I agree with it and current text is enough for
> the
> > > >purpose.  I know people actually uses BGP own auth (just a few
> though)
> > > >so I hesitate to say that deprecating BGP own auth.
> > >
> > > I may be wrong.  I was told that Cisco does Open Message parameter's
> > > optional simple password auth by 'neighbor password 7 LINE' but it
> > > does not.  Jeff, how about GateD?
> > >
> > > My opinion about this issue is keep current text then investigate
> > > current best practice.
> > > --
> > > Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA13776 for <[e-mail]>; Thu, 26 Sep 2002 13:04:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D105C912F0; Thu, 26 Sep 2002 13:03:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8D4F912ED; Thu, 26 Sep 2002 13:03:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A4C86912F0 for <[e-mail]>; Thu, 26 Sep 2002 13:02:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7F4EB5E010; Thu, 26 Sep 2002 13:02:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from titanium.zebra.org (eAc1Abh015.tky.mesh.ad.jp [61.193.80.15]) by segue.merit.edu (Postfix) with ESMTP id 72C8F5DFEF for <[e-mail]>; Thu, 26 Sep 2002 13:02:54 -0400 (EDT)
Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id NAA01385; Thu, 26 Sep 2002 13:05:54 -0400
Date: Thu, 26 Sep 2002 10:05:53 -0700
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 37 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Thanks for clear explanation.  I'm convinced.

>> >----------------------------------------------------------------------------
>> >37) Combine "Unfeasable Routes" and "Withdrawn Routes"
>> >----------------------------------------------------------------------------
>> >Status: No Consensus
>> >Change: Potentially
>> >Summary: No definition extant for "Unfeasable Routes". 
>> >
>> >Discussion:
>> >
>> >3. P. 45, Phase I, There is no definition of what are unfeasible routes? Are
>> >they the same as withdrawn routes? If so, the two should be combined to one
>> >name.
>> 
>> >From implementation stand point there is no difference between
>> "Unfeasible Routes" and "Withdrawn Routes".  When the route is
>> unfeasible, BGP withdraw the route.  I think combining two name to one
>> name make sense.
>
>The routes are withdrawn from service because they are unfeasible,
>not because they are "withdrawn". So, we need to keep the term
>"unfeasible" to indicate the *reason* why a route could be withdrawn.
>On the other hand, "withdrawn" is used as a verb, and to the best
>of my knowledge "unfeasible" can't be used as a verb.  With this
>in mind, I don't think that we can combine the two into a single
>term.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA13726 for <[e-mail]>; Thu, 26 Sep 2002 13:03:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 92F2691208; Thu, 26 Sep 2002 13:02:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A7DE912ED; Thu, 26 Sep 2002 13:02:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B712B91208 for <[e-mail]>; Thu, 26 Sep 2002 13:01:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 98F035E01F; Thu, 26 Sep 2002 13:01:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 538EA5E010 for <[e-mail]>; Thu, 26 Sep 2002 13:01:52 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1H49D>; Thu, 26 Sep 2002 13:01:52 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Randy Bush'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 21
Date: Thu, 26 Sep 2002 13:01:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

What code? 

-----Original Message-----
From: Randy Bush [mailto:[e-mail]] 
Sent: Thursday, September 26, 2002 12:48 PM
To: Natale, Jonathan
Cc: 'Yakov Rekhter'; [e-mail]
Subject: RE: issue 21

> Who uses bgp authentication?  I though it was nobody.

you were incorrect in that thought.  prudent operators do use it,
and some large ones have for some years now.

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 NAA13678 for <[e-mail]>; Thu, 26 Sep 2002 13:02:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5A0B8912EF; Thu, 26 Sep 2002 13:01:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14014912ED; Thu, 26 Sep 2002 13:01:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD55D912EF for <[e-mail]>; Thu, 26 Sep 2002 13:01:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C7A8B5E021; Thu, 26 Sep 2002 13:01:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 5F9B35E01F for <[e-mail]>; Thu, 26 Sep 2002 13:01:02 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1H489>; Thu, 26 Sep 2002 13:01:02 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Randy Bush'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 21
Date: Thu, 26 Sep 2002 13:01:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Randy,

	Operators use which form of BGP Authentication?   TCP
native (RFC 2385) or BGP's 'own' authentication?  It would
be nice if we could be precise...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Randy Bush [mailto:[e-mail]]
> Sent: Thursday, September 26, 2002 12:48 PM
> To: Natale, Jonathan
> Cc: 'Yakov Rekhter'; [e-mail]
> Subject: RE: issue 21
> 
> > Who uses bgp authentication?  I though it was nobody.
> 
> you were incorrect in that thought.  prudent operators do use it,
> and some large ones have for some years now.
> 
> 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 NAA13635 for <[e-mail]>; Thu, 26 Sep 2002 13:01:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2589E912F1; Thu, 26 Sep 2002 13:01:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AFA6A912F0; Thu, 26 Sep 2002 13:01:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74602912ED for <[e-mail]>; Thu, 26 Sep 2002 13:01:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CB38D5E022; Thu, 26 Sep 2002 13:01:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 5D77B5E010 for <[e-mail]>; Thu, 26 Sep 2002 13:01:02 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1H488>; Thu, 26 Sep 2002 13:01:02 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: issue 58 
Date: Thu, 26 Sep 2002 13:00:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

In reference to

"We used to add ATOMIC_AGGREGATE whenever the AS_PATH was truncated rather
than replaced with an AS_SET.  It was always purely informational since no
one intentionally deaggregated and reannounced. Don't implementations still
support this?" (Curtis)

AFAIK, yes, that is what IOS does--which does not match the draft.

I agree with Curtis, changing the wording to indicate that it is
informational and/or to match current implementations (what does Juniper
do?) is better than depreciating it.

I don't think to actually does anything other than let the administrator
know it was truncated, but I am not 100% sure on this.

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Thursday, September 26, 2002 12:46 PM
To: Yakov Rekhter
Cc: [e-mail]
Subject: Re: issue 58 


In message <[e-mail]>, Yakov Rekhter
writes
:
>   58) Deprication of ATOMIC_AGGREGATE
>
---------------------------------------------------------------------------
> -
>   Status: No Consensus
>   Change: Potentially
>   Summary: It is proposed that ATOMIC_AGGREGATE be depricated.  There has 
>    not yet been any discussion on the proposed changes.
> 
> Comments on this issue would be appreciated.
> 
> In the absence of any objections to the changes proposed by Jeff, the
> changes would be accepted. 
> 
> Yakov.


We used to add ATOMIC_AGGREGATE whenever the AS_PATH was truncated
rather than replaced with an AS_SET.  It was always purely
informational since no one intentionally deaggregated and reannounced.
Don't implementations still support this?

If reality is that it is informational only, then just remove the
MUSTs and indicate that it is informational.

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 MAA13442 for <[e-mail]>; Thu, 26 Sep 2002 12:57:54 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8D793912EC; Thu, 26 Sep 2002 12:57:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5883A912ED; Thu, 26 Sep 2002 12:57:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 122D8912EC for <[e-mail]>; Thu, 26 Sep 2002 12:57:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EF87E5E020; Thu, 26 Sep 2002 12:57:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 8746D5E01F for <[e-mail]>; Thu, 26 Sep 2002 12:57:22 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1H478>; Thu, 26 Sep 2002 12:57:22 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 21 
Date: Thu, 26 Sep 2002 12:57:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Yakov,

	The fact that this issue does not include discussion 
of removing/deprecating text related to possibly unsupported
authentication may be an artifact of the fact that it is a
summary issue statement.  While the summarization Andrew put
together is excellent and much appreciated, it is not perfect.
The discussion on this particular issue _did_ include the
possibility of deprecating BGP authentication mechanisms that
are not used.

	It does not take very long to find examples of this in
the IDR mailing list archive.

	As only one of many examples, I enclose the following
from the IDR mailing list archive:

=============================================================
>From [e-mail]  Wed Jul 17 11:19:26 2002
Received: from trapdoor.merit.edu ([e-mail]
[198.108.1.26])
	by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA28965
	for <[e-mail]>; Wed, 17 Jul 2002 11:19:26 -0400
(EDT)
Received: by trapdoor.merit.edu (Postfix)
	id B4081912B2; Wed, 17 Jul 2002 11:18:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 879C0912B4; Wed, 17 Jul 2002 11:18:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 57360912B2
	for <[e-mail]>; Wed, 17 Jul 2002 11:18:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 397A75DE6C; Wed, 17 Jul 2002 11:18:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from hotmail.com (f79.law4.hotmail.com [216.33.149.79])
	by segue.merit.edu (Postfix) with ESMTP id EF84B5DE33
	for <[e-mail]>; Wed, 17 Jul 2002 11:18:48 -0400 (EDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Wed, 17 Jul 2002 08:18:48 -0700
Received: from 65.194.140.2 by lw4fd.law4.hotmail.msn.com with HTTP;
	Wed, 17 Jul 2002 15:18:48 GMT
X-Originating-IP: [65.194.140.2]
From: "Bruno Rijsman" <[e-mail]>
To: [e-mail]
Subject: Questions about the "Authentication Information" optional parameter
Date: Wed, 17 Jul 2002 11:18:48 -0400
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 17 Jul 2002 15:18:48.0477 (UTC)
FILETIME=[3FE744D0:01C22DA5]
Sender: [e-mail]
Precedence: bulk

I have some questions about the "Authentication Information" optional 
parameter in the BGP OPEN message.

Have any authentication codes been defined anywhere?

Does any implementation actually support this method of authentication (as 
far as I know everyone uses RFC 2385 which uses a TCP MD5 signature 
instead)?

If it is not used in real life should we remove the "Authentication 
Information" optional parameter from the draft (or at least deprecate it)?

If no "Authentication Information" parameter was exchanged, it seems that 
the 16 marker bytes are a complete waste of space. Would it make sense to 
define a capability (or maybe an authentication code) which means 
"subsequent messages after the OPEN message will not contain the marker 
bytes".
=============================================================

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Thursday, September 26, 2002 12:37 PM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: issue 21
> 
> Jonathan,
> 
> > Yes, you are wrong.  Of course there could be a special build that does
> it.
> >
> > I still think the bgp auth. option should be depreciated.
> 
> Please note that the subject of the discussion is issue 21. This issue
> has *nothing to do* with deprecating the bgp auth option - it has
> to do with adding a sentence pointing that one could use rfc2385.
> 
> Yakov.
> 
> >
> > -----Original Message-----
> > From: Kunihiro Ishiguro [mailto:[e-mail]]
> > Sent: Thursday, September 26, 2002 12:29 PM
> > To: Natale, Jonathan
> > Cc: 'Yakov Rekhter'; [e-mail]
> > Subject: Re: issue 21
> >
> > >Issue 21's main point is mentioning MD5 authentication along with BGP
> > >own password auth.  I agree with it and current text is enough for the
> > >purpose.  I know people actually uses BGP own auth (just a few though)
> > >so I hesitate to say that deprecating BGP own auth.
> >
> > I may be wrong.  I was told that Cisco does Open Message parameter's
> > optional simple password auth by 'neighbor password 7 LINE' but it
> > does not.  Jeff, how about GateD?
> >
> > My opinion about this issue is keep current text then investigate
> > current best practice.
> > --
> > Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA13176 for <[e-mail]>; Thu, 26 Sep 2002 12:52:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 71026912EB; Thu, 26 Sep 2002 12:52:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 405D5912EC; Thu, 26 Sep 2002 12:52:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 18382912EB for <[e-mail]>; Thu, 26 Sep 2002 12:52:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 047D35E01B; Thu, 26 Sep 2002 12:52:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 9AFCD5E010 for <[e-mail]>; Thu, 26 Sep 2002 12:52:08 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8QGq7m50379; Thu, 26 Sep 2002 09:52:07 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: Depeciate BGP Authentication 
In-Reply-To: Your message of "Thu, 26 Sep 2002 12:48:45 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 09:52:07 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> Ok, sorry.  Do we have an item to depreciate bgp auth.?  Can we add one
> please?

The (extended) deadline for comments was Sep 23.

Yakov.

> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Thursday, September 26, 2002 12:37 PM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: issue 21 
> 
> Jonathan,
> 
> > Yes, you are wrong.  Of course there could be a special build that does
> it.
> > 
> > I still think the bgp auth. option should be depreciated.
> 
> Please note that the subject of the discussion is issue 21. This issue
> has *nothing to do* with deprecating the bgp auth option - it has
> to do with adding a sentence pointing that one could use rfc2385.
> 
> Yakov.
> 
> > 
> > -----Original Message-----
> > From: Kunihiro Ishiguro [mailto:[e-mail]] 
> > Sent: Thursday, September 26, 2002 12:29 PM
> > To: Natale, Jonathan
> > Cc: 'Yakov Rekhter'; [e-mail]
> > Subject: Re: issue 21
> > 
> > >Issue 21's main point is mentioning MD5 authentication along with BGP
> > >own password auth.  I agree with it and current text is enough for the
> > >purpose.  I know people actually uses BGP own auth (just a few though)
> > >so I hesitate to say that deprecating BGP own auth.
> > 
> > I may be wrong.  I was told that Cisco does Open Message parameter's
> > optional simple password auth by 'neighbor password 7 LINE' but it
> > does not.  Jeff, how about GateD?
> > 
> > My opinion about this issue is keep current text then investigate
> > current best practice.
> > -- 
> > Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA13078 for <[e-mail]>; Thu, 26 Sep 2002 12:51:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 10253912E9; Thu, 26 Sep 2002 12:50:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF527912EA; Thu, 26 Sep 2002 12:50:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B76BC912E9 for <[e-mail]>; Thu, 26 Sep 2002 12:50:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A201C5E01B; Thu, 26 Sep 2002 12:50:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 167D85E01A for <[e-mail]>; Thu, 26 Sep 2002 12:50:29 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8QGo9760627; Thu, 26 Sep 2002 12:50:09 -0400 (EDT) (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 g8QGo6G60620; Thu, 26 Sep 2002 12:50:06 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8QGo6824714; Thu, 26 Sep 2002 12:50:06 -0400 (EDT)
Date: Thu, 26 Sep 2002 12:50:06 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: issue 58
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 Thu, Sep 26, 2002 at 12:46:11PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Sep 26, 2002 at 12:46:11PM -0400, Curtis Villamizar wrote:
> We used to add ATOMIC_AGGREGATE whenever the AS_PATH was truncated
> rather than replaced with an AS_SET.  It was always purely
> informational since no one intentionally deaggregated and reannounced.
> Don't implementations still support this?

They do.
Please see my original long e-mail on the subject.
(I can resend it to you if need be.)

> If reality is that it is informational only, then just remove the
> MUSTs and indicate that it is informational.

The point is that by definition of the attribute, anywhere that policy
is used (and some places where it may not be), ATOMIC_AGGREGATE
*should* be there.  Since its not, and it would generally be
everwhere, you just shouldn't de-aggregate.

At best, leaving it as a method of informationally signalling truncation
of a AS_PATH is the best we'll get out of it - and it matches
current implementations.

> 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 MAA13005 for <[e-mail]>; Thu, 26 Sep 2002 12:49:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4359F912E8; Thu, 26 Sep 2002 12:49:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C0AE912E9; Thu, 26 Sep 2002 12:48:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C5618912E8 for <[e-mail]>; Thu, 26 Sep 2002 12:48:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A9AC65E01B; Thu, 26 Sep 2002 12:48:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 5B6465E01A for <[e-mail]>; Thu, 26 Sep 2002 12:48:51 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1H46Z>; Thu, 26 Sep 2002 12:48:51 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: Depeciate BGP Authentication
Date: Thu, 26 Sep 2002 12:48:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Ok, sorry.  Do we have an item to depreciate bgp auth.?  Can we add one
please?

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Thursday, September 26, 2002 12:37 PM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: issue 21 

Jonathan,

> Yes, you are wrong.  Of course there could be a special build that does
it.
> 
> I still think the bgp auth. option should be depreciated.

Please note that the subject of the discussion is issue 21. This issue
has *nothing to do* with deprecating the bgp auth option - it has
to do with adding a sentence pointing that one could use rfc2385.

Yakov.

> 
> -----Original Message-----
> From: Kunihiro Ishiguro [mailto:[e-mail]] 
> Sent: Thursday, September 26, 2002 12:29 PM
> To: Natale, Jonathan
> Cc: 'Yakov Rekhter'; [e-mail]
> Subject: Re: issue 21
> 
> >Issue 21's main point is mentioning MD5 authentication along with BGP
> >own password auth.  I agree with it and current text is enough for the
> >purpose.  I know people actually uses BGP own auth (just a few though)
> >so I hesitate to say that deprecating BGP own auth.
> 
> I may be wrong.  I was told that Cisco does Open Message parameter's
> optional simple password auth by 'neighbor password 7 LINE' but it
> does not.  Jeff, how about GateD?
> 
> My opinion about this issue is keep current text then investigate
> current best practice.
> -- 
> Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA12982 for <[e-mail]>; Thu, 26 Sep 2002 12:49:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B723D912E0; Thu, 26 Sep 2002 12:48:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6A18F912E9; Thu, 26 Sep 2002 12:48:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C3649912E0 for <[e-mail]>; Thu, 26 Sep 2002 12:48:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A76855E01C; Thu, 26 Sep 2002 12:48:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 810C65E01B for <[e-mail]>; Thu, 26 Sep 2002 12:48:18 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17uboH-0005UD-00; Thu, 26 Sep 2002 09:48:17 -0700
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 21
References: <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 26 Sep 2002 09:48:17 -0700
Sender: [e-mail]
Precedence: bulk

> Who uses bgp authentication?  I though it was nobody.

you were incorrect in that thought.  prudent operators do use it,
and some large ones have for some years now.

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 MAA12909 for <[e-mail]>; Thu, 26 Sep 2002 12:47:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F157A912DF; Thu, 26 Sep 2002 12:46:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6D2B912E0; Thu, 26 Sep 2002 12:46:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2D3D2912DF for <[e-mail]>; Thu, 26 Sep 2002 12:46:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1ADC65E01A; Thu, 26 Sep 2002 12:46:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from titanium.zebra.org (eAc1Abh015.tky.mesh.ad.jp [61.193.80.15]) by segue.merit.edu (Postfix) with ESMTP id ED41F5E010 for <[e-mail]>; Thu, 26 Sep 2002 12:46:06 -0400 (EDT)
Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id MAA01311; Thu, 26 Sep 2002 12:49:02 -0400
Date: Thu, 26 Sep 2002 09:49:00 -0700
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: Re: issue 21
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>As best I understand it, no one supports the AUTH optional parameter.
>Deprecating it may make sense.  However, some people (see the
>recent submission by the people at Huawei) seem to think that this
>might be still useful.

Understood.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA12888 for <[e-mail]>; Thu, 26 Sep 2002 12:47:21 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2F5F6912DB; Thu, 26 Sep 2002 12:46:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E35E5912DF; Thu, 26 Sep 2002 12:46:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD523912DB for <[e-mail]>; Thu, 26 Sep 2002 12:46:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B84895E018; Thu, 26 Sep 2002 12:46:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 66F185E010 for <[e-mail]>; Thu, 26 Sep 2002 12:46:01 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1H46S>; Thu, 26 Sep 2002 12:46:01 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: issue 8 
Date: Thu, 26 Sep 2002 12:45:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

It seems to me that if you bring up all bgp peers at once it
may lead to load spikes on the network.  Cisco seems to wait
27.5 +/- 2.5 seconds for IBGP, and 40 +/- 5 seconds for
EBGP--20 sec. from config time to the "open active, delay"
jittered delay assignment plus the jittered delay (5 to 10
sec. for IBGP, and 15 to 25 sec. for EBGP).  This would also
apply for "no neighbor x.x.x.x shutdown".  Their value of
ConnectRetry is 60sec.  though, not sure how this value is used
(based on above).  Maybe some Cisco folks can chime in on
this one???

I did not check Juniper.

Also, interestingly, they do not apply jitter to
the other timers (as far as I can tell), but I don't see
a problem with this.

Another timer that they use that is not mentioned in
the draft/rfc is the next hop resolution timer which is 30
seconds.  Although it would be nice to have this in the spec,
I will concede that it is out of scope and/or
implementation dependent.

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Thursday, September 26, 2002 12:34 PM
To: Yakov Rekhter
Cc: [e-mail]; Sivananda Ramnath - CTD, Chennai.
Subject: Re: issue 8 


In message <[e-mail]>, Yakov Rekhter
writes
:
> forwarding...
> ------- Forwarded Message
> 
> Date:    Thu, 26 Sep 2002 16:58:19 +0530
> From:    "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
> To:      Yakov Rekhter <[e-mail]>
> Subject: FW: issue 8
> 
> Hello,
> 
>     My mail does not seem to have made it to the list. Could you please
> forward it ?
> 
> Thanks,
> Siva
> ([e-mail])
> 
> - -----Original Message-----
> From: Sivananda Ramnath - CTD, Chennai. 
> Sent: Thursday, September 26, 2002 3:21 PM
> To: [e-mail]
> Subject: RE: issue 8
> 
> 
> Hello,
> 
>     The ConnectRetry timer is should have a value that is 'sufficiently
> large to allow TCP initialization. Application of jitter can reduce the
this
> value (by up to 25%). A configuration which the ConnectRetry timer has
been
> pegged at a value close to TCP connection time may cause a connection to
be
> terminated as a result of this jitter. Is this a cause for concern ? 
> 
>     The default value suggested for ConnectRetry (120 seconds) is
> sufficiently large that event with a jitter of 0.75, it will be greater
than
TCP'c connection establishment timer.
> 
>     Is adding a jitter to the ConnectRetry timer a standard practice ?
What
> benefit does this provide ?
> 
> Sivanand
> ([e-mail])


The TCP connection establishment timer is 75 seconds (sysctl yield
"net.inet.tcp.keepinit: 75000" in BSD-oids).

The ConnectRetry determines when to make a second attempt after a
prior attempt to connect has failed.  It is to avoid a rapid
succession of retries on immediate failures (for example "Connection
refused" if the peer was in the middle of a reboot, Network
Unreachable if you can't get there from here, etc) but also covers the
case where the TCP SYN goes off and is never heard from again.

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 MAA12866 for <[e-mail]>; Thu, 26 Sep 2002 12:46:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 13E5F912DA; Thu, 26 Sep 2002 12:45:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1647912DB; Thu, 26 Sep 2002 12:45:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 86A88912DA for <[e-mail]>; Thu, 26 Sep 2002 12:45:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 32B715E01A; Thu, 26 Sep 2002 12:45:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id E62FF5E010 for <[e-mail]>; Thu, 26 Sep 2002 12:45:28 -0400 (EDT)
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 MAA90840; Thu, 26 Sep 2002 12:46:11 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 58 
In-reply-to: Your message of "Thu, 26 Sep 2002 06:17:41 PDT." <[e-mail]> 
Date: Thu, 26 Sep 2002 12:46:11 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Yakov Rekhter writes
:
>   58) Deprication of ATOMIC_AGGREGATE
>   ---------------------------------------------------------------------------
> -
>   Status: No Consensus
>   Change: Potentially
>   Summary: It is proposed that ATOMIC_AGGREGATE be depricated.  There has 
>    not yet been any discussion on the proposed changes.
> 
> Comments on this issue would be appreciated.
> 
> In the absence of any objections to the changes proposed by Jeff, the
> changes would be accepted. 
> 
> Yakov.


We used to add ATOMIC_AGGREGATE whenever the AS_PATH was truncated
rather than replaced with an AS_SET.  It was always purely
informational since no one intentionally deaggregated and reannounced.
Don't implementations still support this?

If reality is that it is informational only, then just remove the
MUSTs and indicate that it is informational.

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 MAA12432 for <[e-mail]>; Thu, 26 Sep 2002 12:37:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CA4EE912D9; Thu, 26 Sep 2002 12:37:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99B10912DA; Thu, 26 Sep 2002 12:37:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 71CA4912D9 for <[e-mail]>; Thu, 26 Sep 2002 12:37:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5B4B45E016; Thu, 26 Sep 2002 12:37:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id F1E2E5E010 for <[e-mail]>; Thu, 26 Sep 2002 12:37:10 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8QGb9m49173; Thu, 26 Sep 2002 09:37:09 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 21 
In-Reply-To: Your message of "Thu, 26 Sep 2002 12:29:32 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 09:37:09 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> Yes, you are wrong.  Of course there could be a special build that does it.
> 
> I still think the bgp auth. option should be depreciated.

Please note that the subject of the discussion is issue 21. This issue
has *nothing to do* with deprecating the bgp auth option - it has
to do with adding a sentence pointing that one could use rfc2385.

Yakov.

> 
> -----Original Message-----
> From: Kunihiro Ishiguro [mailto:[e-mail]] 
> Sent: Thursday, September 26, 2002 12:29 PM
> To: Natale, Jonathan
> Cc: 'Yakov Rekhter'; [e-mail]
> Subject: Re: issue 21
> 
> >Issue 21's main point is mentioning MD5 authentication along with BGP
> >own password auth.  I agree with it and current text is enough for the
> >purpose.  I know people actually uses BGP own auth (just a few though)
> >so I hesitate to say that deprecating BGP own auth.
> 
> I may be wrong.  I was told that Cisco does Open Message parameter's
> optional simple password auth by 'neighbor password 7 LINE' but it
> does not.  Jeff, how about GateD?
> 
> My opinion about this issue is keep current text then investigate
> current best practice.
> -- 
> Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA12345 for <[e-mail]>; Thu, 26 Sep 2002 12:36:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 411E7912D7; Thu, 26 Sep 2002 12:36:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C722912D9; Thu, 26 Sep 2002 12:36:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 00B04912D7 for <[e-mail]>; Thu, 26 Sep 2002 12:36:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E036B5E013; Thu, 26 Sep 2002 12:36:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 2CB3F5E010 for <[e-mail]>; Thu, 26 Sep 2002 12:36:19 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8QGa8960047; Thu, 26 Sep 2002 12:36:08 -0400 (EDT) (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 g8QGa5G60040; Thu, 26 Sep 2002 12:36:05 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8QGa5624573; Thu, 26 Sep 2002 12:36:05 -0400 (EDT)
Date: Thu, 26 Sep 2002 12:36:05 -0400
From: Jeffrey Haas <[e-mail]>
To: Kunihiro Ishiguro <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: Re: issue 21
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
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Sep 26, 2002 at 09:29:21AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Sep 26, 2002 at 09:29:21AM -0700, Kunihiro Ishiguro wrote:
> I may be wrong.  I was told that Cisco does Open Message parameter's
> optional simple password auth by 'neighbor password 7 LINE' but it
> does not.  Jeff, how about GateD?

According to Cisco's 12.2 documentation, "neigbor password" appears
to turn on tcp+md5 rather than the bgp optional parameters auth.

GateD has a spot for the tcp+md5 option in the code, but the implementation
is left to integration with a tcp stack that supports this feature.
It likely would be a socket option.

> My opinion about this issue is keep current text then investigate
> current best practice.

As best I understand it, no one supports the AUTH optional parameter.
Deprecating it may make sense.  However, some people (see the
recent submission by the people at Huawei) seem to think that this
might be still useful.

> Kunihiro Ishiguro

-- 
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 MAA12311 for <[e-mail]>; Thu, 26 Sep 2002 12:35:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 969B5912D8; Thu, 26 Sep 2002 12:35:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5FA50912D7; Thu, 26 Sep 2002 12:35:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CAB40912D8 for <[e-mail]>; Thu, 26 Sep 2002 12:35:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9AB5C5E015; Thu, 26 Sep 2002 12:35:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 421F25E013 for <[e-mail]>; Thu, 26 Sep 2002 12:35:21 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1H45A>; Thu, 26 Sep 2002 12:35:20 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Subject: RE: issue 10 
Date: Thu, 26 Sep 2002 12:35:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I agree, what non-conforming implementations do to limit the bad effects of
non-conforming is out of scope.

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Thursday, September 26, 2002 12:16 PM
To: [e-mail]
Cc: Jeffrey Haas; Yakov Rekhter; [e-mail]
Subject: Re: issue 10 


In message <[e-mail]>, Curtis
Villamizar 
writes:
> 
> In message <[e-mail]>, Curtis
Villamiza
> r 
> writes:
> > 
> > In message <[e-mail]>, Jeffrey Haas writes:
> > > 
> > > If I might suggest that although this is the most "valid" 
> > > (for some value judgement of "valid") case for this problem,
> > > implementations may choose for whatever reason to deal with
> > > attribute overflows differently.  For example, if a certain vendor
> > > didn't want to support AS_PATHS over 256 AS's, that's their
> > > prerogative.
> > 
> > I'd call it marginally broken rather than their prerogative.  AS path
> > padding has gotten out of hand but not this bad so it shouldn't be an
> > issue if such a route was dropped, but it is technically wrong unless
> > policy was configured to do so.
> > 
> > Curtis
> 
> 
> Actually the length is one octet so ignore the above.
> 
> Never mind,
> 
> Curtis

But the AS_PATH can have multiple AS_SEQMENTs each with 255 AS ....

In any case, I like Yakov's suggestion to leave the text as is "don't
advertise, if you do truncate somehow its outside the scope of the
spec" (paraphrased).

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 MAA12225 for <[e-mail]>; Thu, 26 Sep 2002 12:34:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 54312912D4; Thu, 26 Sep 2002 12:34:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2977C912D7; Thu, 26 Sep 2002 12:34:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E5758912D4 for <[e-mail]>; Thu, 26 Sep 2002 12:32:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CF98E5E013; Thu, 26 Sep 2002 12:32:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 0FA555E010 for <[e-mail]>; Thu, 26 Sep 2002 12:32:57 -0400 (EDT)
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 MAA90808; Thu, 26 Sep 2002 12:33:40 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail], "Sivananda Ramnath - CTD,     Chennai." <[e-mail]>
Reply-To: [e-mail]
Subject: Re: issue 8 
In-reply-to: Your message of "Thu, 26 Sep 2002 05:52:10 PDT." <[e-mail]> 
Date: Thu, 26 Sep 2002 12:33:39 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Yakov Rekhter writes
:
> forwarding...
> ------- Forwarded Message
> 
> Date:    Thu, 26 Sep 2002 16:58:19 +0530
> From:    "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
> To:      Yakov Rekhter <[e-mail]>
> Subject: FW: issue 8
> 
> Hello,
> 
>     My mail does not seem to have made it to the list. Could you please
> forward it ?
> 
> Thanks,
> Siva
> ([e-mail])
> 
> - -----Original Message-----
> From: Sivananda Ramnath - CTD, Chennai. 
> Sent: Thursday, September 26, 2002 3:21 PM
> To: [e-mail]
> Subject: RE: issue 8
> 
> 
> Hello,
> 
>     The ConnectRetry timer is should have a value that is 'sufficiently
> large to allow TCP initialization. Application of jitter can reduce the this
> value (by up to 25%). A configuration which the ConnectRetry timer has been
> pegged at a value close to TCP connection time may cause a connection to be
> terminated as a result of this jitter. Is this a cause for concern ? 
> 
>     The default value suggested for ConnectRetry (120 seconds) is
> sufficiently large that event with a jitter of 0.75, it will be greater than
TCP'c connection establishment timer.
> 
>     Is adding a jitter to the ConnectRetry timer a standard practice ? What
> benefit does this provide ?
> 
> Sivanand
> ([e-mail])


The TCP connection establishment timer is 75 seconds (sysctl yield
"net.inet.tcp.keepinit: 75000" in BSD-oids).

The ConnectRetry determines when to make a second attempt after a
prior attempt to connect has failed.  It is to avoid a rapid
succession of retries on immediate failures (for example "Connection
refused" if the peer was in the middle of a reboot, Network
Unreachable if you can't get there from here, etc) but also covers the
case where the TCP SYN goes off and is never heard from again.

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 MAA12162 for <[e-mail]>; Thu, 26 Sep 2002 12:32:54 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A6B8C912D2; Thu, 26 Sep 2002 12:32:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70037912D4; Thu, 26 Sep 2002 12:32:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 37996912D2 for <[e-mail]>; Thu, 26 Sep 2002 12:32:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 256E05E013; Thu, 26 Sep 2002 12:32:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id BDB805E010 for <[e-mail]>; Thu, 26 Sep 2002 12:32:23 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8QGWIm48805; Thu, 26 Sep 2002 09:32:18 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Kunihiro Ishiguro <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 37 
In-Reply-To: Your message of "Thu, 26 Sep 2002 07:50:27 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 09:32:18 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Kunihiro,

> >----------------------------------------------------------------------------
> >37) Combine "Unfeasable Routes" and "Withdrawn Routes"
> >----------------------------------------------------------------------------
> >Status: No Consensus
> >Change: Potentially
> >Summary: No definition extant for "Unfeasable Routes". 
> >
> >Discussion:
> >
> >3. P. 45, Phase I, There is no definition of what are unfeasible routes? Are
> >they the same as withdrawn routes? If so, the two should be combined to one
> >name.
> 
> >From implementation stand point there is no difference between
> "Unfeasible Routes" and "Withdrawn Routes".  When the route is
> unfeasible, BGP withdraw the route.  I think combining two name to one
> name make sense.

The routes are withdrawn from service because they are unfeasible,
not because they are "withdrawn". So, we need to keep the term
"unfeasible" to indicate the *reason* why a route could be withdrawn.
On the other hand, "withdrawn" is used as a verb, and to the best
of my knowledge "unfeasible" can't be used as a verb.  With this
in mind, I don't think that we can combine the two into a single
term.

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 MAA12125 for <[e-mail]>; Thu, 26 Sep 2002 12:32:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1D056912D1; Thu, 26 Sep 2002 12:30:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA70C912D2; Thu, 26 Sep 2002 12:30:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 755DF912D1 for <[e-mail]>; Thu, 26 Sep 2002 12:30:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2B7085E013; Thu, 26 Sep 2002 12:30:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 3026C5E014 for <[e-mail]>; Thu, 26 Sep 2002 12:30:53 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1H4ZV>; Thu, 26 Sep 2002 12:30:52 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail], "'Kunihiro Ishiguro'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Subject: RE: issue 21
Date: Thu, 26 Sep 2002 12:30:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Yakov,

	Since part of the first charter item (both new and old
charters) was to determine whether the BGP specification can 
be advanced, shouldn't we have done a recent implementation
survey?  If we had, then we should know answers to questions
like these.

	It would make sense to have this information before we
close on modifications to the BGP specification anyway, both
to give substance to the intent that the new specification
reflects actual implementations and to avoid having to do
another round to remove features that are not implemented
or have not been interoperability tested in the field.

	If we have done such a survey recently, where are the
results posted?

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Kunihiro Ishiguro [mailto:[e-mail]]
> Sent: Thursday, September 26, 2002 11:23 AM
> To: Natale, Jonathan
> Cc: 'Yakov Rekhter'; [e-mail]
> Subject: Re: issue 21
> 
> I also thought nobody uses BGP own simple password auth.  It is not
> secure.  It is just a better than nothing kind of thing.  But MD5 auth
> is not supported by all of vendors.  Still there are vendors only can
> do simple password auth due to the limitation of TCP/IP stack
> capability (Zebra also suffer from it).  In that case BGP own simple
> password can be a only way.
> 
> Issue 21's main point is mentioning MD5 authentication along with BGP
> own password auth.  I agree with it and current text is enough for the
> purpose.  I know people actually uses BGP own auth (just a few though)
> so I hesitate to say that deprecating BGP own auth.
> 
> >Let me be more exact:
> >Who uses *BGP's own* authentication mechanisms???
> >
> >-----Original Message-----
> >From: Kunihiro Ishiguro [mailto:[e-mail]]
> >Sent: Thursday, September 26, 2002 10:46 AM
> >To: Natale, Jonathan
> >Cc: 'Yakov Rekhter'; [e-mail]
> >Subject: Re: issue 21
> >
> >>Who uses bgp authentication?  I though it was nobody. I thought the goal
> >was
> >>to document existing practice.
> >
> >Many people are using BGP authentication both simple text and MD5
> >authentication.  I've got many requests to implement it in
> >Zebra/ZebOS.  So I believe let the current text as it is will achieve
> >existing practice.
> >--
> >Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA12033 for <[e-mail]>; Thu, 26 Sep 2002 12:30:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 19DD8912D0; Thu, 26 Sep 2002 12:29:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D74FF912D1; Thu, 26 Sep 2002 12:29:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9CDFC912D0 for <[e-mail]>; Thu, 26 Sep 2002 12:29:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8B3CF5E014; Thu, 26 Sep 2002 12:29:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 47B1B5E013 for <[e-mail]>; Thu, 26 Sep 2002 12:29:41 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1H4ZF>; Thu, 26 Sep 2002 12:29:40 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Kunihiro Ishiguro'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 21
Date: Thu, 26 Sep 2002 12:29:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Yes, you are wrong.  Of course there could be a special build that does it.

I still think the bgp auth. option should be depreciated.

-----Original Message-----
From: Kunihiro Ishiguro [mailto:[e-mail]] 
Sent: Thursday, September 26, 2002 12:29 PM
To: Natale, Jonathan
Cc: 'Yakov Rekhter'; [e-mail]
Subject: Re: issue 21

>Issue 21's main point is mentioning MD5 authentication along with BGP
>own password auth.  I agree with it and current text is enough for the
>purpose.  I know people actually uses BGP own auth (just a few though)
>so I hesitate to say that deprecating BGP own auth.

I may be wrong.  I was told that Cisco does Open Message parameter's
optional simple password auth by 'neighbor password 7 LINE' but it
does not.  Jeff, how about GateD?

My opinion about this issue is keep current text then investigate
current best practice.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA11888 for <[e-mail]>; Thu, 26 Sep 2002 12:27:06 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 16E3491230; Thu, 26 Sep 2002 12:26:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DCF6A912D0; Thu, 26 Sep 2002 12:26:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CCA5091230 for <[e-mail]>; Thu, 26 Sep 2002 12:26:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B1B055E010; Thu, 26 Sep 2002 12:26:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from titanium.zebra.org (eAc1Abh015.tky.mesh.ad.jp [61.193.80.15]) by segue.merit.edu (Postfix) with ESMTP id A56645DFEA for <[e-mail]>; Thu, 26 Sep 2002 12:26:23 -0400 (EDT)
Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id MAA01123; Thu, 26 Sep 2002 12:29:21 -0400
Date: Thu, 26 Sep 2002 09:29:21 -0700
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: Re: issue 21
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>Issue 21's main point is mentioning MD5 authentication along with BGP
>own password auth.  I agree with it and current text is enough for the
>purpose.  I know people actually uses BGP own auth (just a few though)
>so I hesitate to say that deprecating BGP own auth.

I may be wrong.  I was told that Cisco does Open Message parameter's
optional simple password auth by 'neighbor password 7 LINE' but it
does not.  Jeff, how about GateD?

My opinion about this issue is keep current text then investigate
current best practice.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA11545 for <[e-mail]>; Thu, 26 Sep 2002 12:20:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BE0939122B; Thu, 26 Sep 2002 12:20:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9200591230; Thu, 26 Sep 2002 12:20:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4CE629122B for <[e-mail]>; Thu, 26 Sep 2002 12:20:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3BF9E5E00E; Thu, 26 Sep 2002 12:20:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 2ABCC5DFEA for <[e-mail]>; Thu, 26 Sep 2002 12:20:21 -0400 (EDT)
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 MAA90756; Thu, 26 Sep 2002 12:20:59 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 24 
In-reply-to: Your message of "Wed, 25 Sep 2002 17:08:50 EDT." <[e-mail]> 
Date: Thu, 26 Sep 2002 12:20:59 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> Yakov,
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Wednesday, September 25, 2002 5:02 PM
> > To: Abarbanel, Benjamin
> > Cc: [e-mail]
> > Subject: Re: issue 24 
> > 
> > 
> > Ben,
> > 
> > > Jeff:
> > > 
> > >   I was just responding to Yakove comment:
> > > 
> > > "By *definition* a route is a <path attribute, NLRI> pair. From that
> > > definition it follows that changing one or more path attributes of
> > > a route means changing a route, which means withdrawing the old
> > > route (route with the old attributes) from service and advertising
> > > a new route (route with the new attributes)."
> > > 
> > > I think we are playing with words here, 3.1a and 3.1b do not address
> > > the point as I have argued. Therefore, I am still not satisfied 
> > > we nailed it down in the spec. 
> > > 
> > > As you can see I dont care for assumptions very much.
> > > 
> > > I would like to see this statement added somewhere in section 3.1:
> > > 
> > > "A route's attributes can be added, modified, or deleted by 
> > sending another
> > >  UPDATE message with the same route and the new attributes, or by
> > > withdrawing
> > >  the route (route with the old attributes) from service and 
> > advertising
> > >  a new route (same route with the new attributes)."
> > 
> > If it is "the same route", then *by definition* of a route it 
> > has to be
> > the same attributes. And if the attributes changed, then it 
> > is no longer
> > "the same route". With this in mind how about adding the 
> > following to 3.1:
> > 
> >   Changing attribute of a route means that the route is withdrawn
> >   from service, and a replacement route is advertised. The replacement
> >   route carries new (changed) attributes and has the same NLRI as the 
> >   route that was withdrawn.
> > 
> > Yakov.
> > 
> 
>   Can we change the current route's attribute without taking it out of
> service
>   (implying no possible network outage)? 
> 
>   If the answer is yes, than you will need an extra sentence. 
> 
>   If the answer is no, then I am happy with your statement.
> 
> Ben



Ben,

It is an atomic operation.  Text stays the same.  No outage.

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 MAA11270 for <[e-mail]>; Thu, 26 Sep 2002 12:15:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id AC631912CE; Thu, 26 Sep 2002 12:14:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7DD3F912D0; Thu, 26 Sep 2002 12:14:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 39371912CE for <[e-mail]>; Thu, 26 Sep 2002 12:14:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1FD125E00E; Thu, 26 Sep 2002 12:14:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 3C1A75DFEF for <[e-mail]>; Thu, 26 Sep 2002 12:14:50 -0400 (EDT)
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 MAA90718; Thu, 26 Sep 2002 12:15:31 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: Jeffrey Haas <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 10 
In-reply-to: Your message of "Thu, 26 Sep 2002 11:58:41 EDT." <[e-mail]> 
Date: Thu, 26 Sep 2002 12:15:31 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Curtis Villamizar 
writes:
> 
> In message <[e-mail]>, Curtis Villamiza
> r 
> writes:
> > 
> > In message <[e-mail]>, Jeffrey Haas writes:
> > > 
> > > If I might suggest that although this is the most "valid" 
> > > (for some value judgement of "valid") case for this problem,
> > > implementations may choose for whatever reason to deal with
> > > attribute overflows differently.  For example, if a certain vendor
> > > didn't want to support AS_PATHS over 256 AS's, that's their
> > > prerogative.
> > 
> > I'd call it marginally broken rather than their prerogative.  AS path
> > padding has gotten out of hand but not this bad so it shouldn't be an
> > issue if such a route was dropped, but it is technically wrong unless
> > policy was configured to do so.
> > 
> > Curtis
> 
> 
> Actually the length is one octet so ignore the above.
> 
> Never mind,
> 
> Curtis

But the AS_PATH can have multiple AS_SEQMENTs each with 255 AS ....

In any case, I like Yakov's suggestion to leave the text as is "don't
advertise, if you do truncate somehow its outside the scope of the
spec" (paraphrased).

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 MAA11177 for <[e-mail]>; Thu, 26 Sep 2002 12:12:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9D6A0912CD; Thu, 26 Sep 2002 12:12:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 03D57912CE; Thu, 26 Sep 2002 12:12:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 90B99912CD for <[e-mail]>; Thu, 26 Sep 2002 12:12:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6ED255E00F; Thu, 26 Sep 2002 12:12:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 30BDF5DFEF for <[e-mail]>; Thu, 26 Sep 2002 12:12:00 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1H4XQ>; Thu, 26 Sep 2002 12:11:59 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Yakov Rekhter <[e-mail]>
Cc: Alex Zinin <[e-mail]>, "Abarbanel,     Benjamin" <[e-mail]>, [e-mail]
Subject: RE: Generial Editorial Comment 
Date: Thu, 26 Sep 2002 12:11:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Wrong.

" If the source IP address used
   by one of these connections is the same as the destination IP address
   used by the other, and the destination IP address used by the first
   connection is the same as the source IP address used by the other, we
   refer to this situation as connection collision."
- draft-ietf-idr-bgp4-17

So multiple simultaneous BGP connection are allowed between the same two
peers, and this behavior is implemented, for example to do load balancing.


-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Thursday, September 26, 2002 11:34 AM
To: Yakov Rekhter
Cc: Alex Zinin; Abarbanel, Benjamin; [e-mail]
Subject: Re: Generial Editorial Comment 


In message <[e-mail]>, Yakov Rekhter
writes
:
> Alex,
> 
> > Defining terms like this in a separate section would be really nice.
> > (BTW, I personally think using "BGP session" which works over a "TCP
> > connection" would be closer to the terminology we're actually using
> > now and would avoid possible confusions when people read terms like
> > "Connection collision") It would also be great if we had descriptions
> > for all data structures that are not explicitly defined (e.g., the
> > current spec has no notion of a peer data structure), timers, etc.
> > 
> > Two other things that I think would make sense to explicitly
> > define are
> > 
> >    - processing of incoming TCP connections (peer lookup, acceptance,
> >      FSM creation, collision control,)
> > 
> >    - generation of events while processing BGP messages, i.e.,
> >      the text describing message processing should say where
> >      needed that a specific event for the BGP session should
> >      be generated.
> 
> Please suggest the appropriate text.
> 
> yakov.



Yakov,

Here is some suggestion.  I don't know where in the document you'd
like to put this or whether you would prefer to omit it.  That's up to
you.

  BGP must maintain separate FSM for each configured peer.  Each BGP
  peer paired in a potential connection will atempt to connect to the
  other.  For the purpose of this discussions, the active or connect
  side of a TCP connection (the side sending the first TCP SYN packet)
  is called outgoing.  The passive or listenning side (the sender of
  the first SYN ACK) is called the an incoming connection.

  A BGP implementation must connect to and listen on TCP port 179 for
  incoming connections in addition to trying to connect to peers.  For
  each incoming connection, a state machine must be instantiated.
  There exists a period in which the identity of the peer on the other
  end of an incoming connection is not known with certainty.  During
  this time, both an incoming and outgoing connection for the same
  peer may exist.  This is referred to as a connection collision (see
  Section x.x, was 6.8).

  A BGP implementation will have at most one FSM for each peer plus
  one FSM for each incoming TCP connection for which the peer has not
  yet been identified.  Each FSM corresponds to exactly one TCP
  connection.

The above covers Alex's first request only.

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 LAA10595 for <[e-mail]>; Thu, 26 Sep 2002 11:58:27 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B7196912E7; Thu, 26 Sep 2002 11:58:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86835912E8; Thu, 26 Sep 2002 11:58:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3DD82912E7 for <[e-mail]>; Thu, 26 Sep 2002 11:58:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1F0B45E00D; Thu, 26 Sep 2002 11:58:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 461965DFEF for <[e-mail]>; Thu, 26 Sep 2002 11:57:59 -0400 (EDT)
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 LAA90542; Thu, 26 Sep 2002 11:58:41 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: Jeffrey Haas <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 10 
In-reply-to: Your message of "Thu, 26 Sep 2002 11:53:48 EDT." <[e-mail]> 
Date: Thu, 26 Sep 2002 11:58:41 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Curtis Villamizar 
writes:
> 
> In message <[e-mail]>, Jeffrey Haas writes:
> > 
> > If I might suggest that although this is the most "valid" 
> > (for some value judgement of "valid") case for this problem,
> > implementations may choose for whatever reason to deal with
> > attribute overflows differently.  For example, if a certain vendor
> > didn't want to support AS_PATHS over 256 AS's, that's their
> > prerogative.
> 
> I'd call it marginally broken rather than their prerogative.  AS path
> padding has gotten out of hand but not this bad so it shouldn't be an
> issue if such a route was dropped, but it is technically wrong unless
> policy was configured to do so.
> 
> Curtis


Actually the length is one octet so ignore the above.

Never mind,

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 LAA10369 for <[e-mail]>; Thu, 26 Sep 2002 11:53:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 47719912E6; Thu, 26 Sep 2002 11:53:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10916912E7; Thu, 26 Sep 2002 11:53:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E0C2A912E6 for <[e-mail]>; Thu, 26 Sep 2002 11:53:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D29735E00D; Thu, 26 Sep 2002 11:53:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 060CB5DFEF for <[e-mail]>; Thu, 26 Sep 2002 11:53:10 -0400 (EDT)
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 LAA90353; Thu, 26 Sep 2002 11:53:48 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 10 
In-reply-to: Your message of "Wed, 25 Sep 2002 14:54:20 EDT." <[e-mail]> 
Date: Thu, 26 Sep 2002 11:53:48 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Jeffrey Haas writes:
> 
> If I might suggest that although this is the most "valid" 
> (for some value judgement of "valid") case for this problem,
> implementations may choose for whatever reason to deal with
> attribute overflows differently.  For example, if a certain vendor
> didn't want to support AS_PATHS over 256 AS's, that's their
> prerogative.

I'd call it marginally broken rather than their prerogative.  AS path
padding has gotten out of hand but not this bad so it shouldn't be an
issue if such a route was dropped, but it is technically wrong unless
policy was configured to do so.

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 LAA10290 for <[e-mail]>; Thu, 26 Sep 2002 11:51:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3D14B912E5; Thu, 26 Sep 2002 11:51:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0866D912E6; Thu, 26 Sep 2002 11:51:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A5B21912E5 for <[e-mail]>; Thu, 26 Sep 2002 11:51:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8589F5E00B; Thu, 26 Sep 2002 11:51:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id 0CD925DFEF for <[e-mail]>; Thu, 26 Sep 2002 11:51:16 -0400 (EDT)
Received: from fid4.com (mcambria3.avayactc.com [199.93.238.136]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g8QFmqlJ008072 for <[e-mail]>; Thu, 26 Sep 2002 11:48:52 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 11:33:49 -0400
From: "Michael C. Cambria" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020819
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: issues 13, 14, 61
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Yakov Rekhter wrote:
> Folks,
> 
> I think that issue 13, 14 and 61 essentially cover the same topic,

I brough up item 14

>   
>   ----------------------------------------------------------------------------
>   14) NEXT_HOP to Internal Peer
>   ----------------------------------------------------------------------------
>   Status: No Consensus
>   Change: Potentially
>   Summary: One concuring reponse, no text proposed.
>   
>   Discussion:
>   
>   The thread entitled "NEXT_HOP to internal peer" starts with this question:
>   
>   When sending a locally originated route to an internal peer, what should
>   NEXT_HOP be set to?
>   
>   One response suggested that we add a line stating that the NEXT_HOP address
>   originates from the IGP.

Section 5.1.3 explictly states what to do when originating to an 
etternal peer.  #2 covers one hop away, #3 covers more than on hop away. 
  #1 talks about sending to an iBGP peer, but only when propergating a 
route received from an eBGP peer.

       1) When sending a message to an internal peer, 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.


Text similar to #2 shoud be added, in their own bullit items to #1 such 
as what was suggested by Jonathan Natale and quoted below:


 > I propose adding:
 >
 > "When announcing a locally 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 address of the interface 
that is
 > used to reach the peer)."
 >
 > AFTER

 > "When sending a message to an internal peer, 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."




MikeC



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA10133 for <[e-mail]>; Thu, 26 Sep 2002 11:48:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 53686912E3; Thu, 26 Sep 2002 11:48:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24A75912E5; Thu, 26 Sep 2002 11:48:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5BDF5912E3 for <[e-mail]>; Thu, 26 Sep 2002 11:47:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 409135E00D; Thu, 26 Sep 2002 11:47:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 635CC5DFEF for <[e-mail]>; Thu, 26 Sep 2002 11:47:53 -0400 (EDT)
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 LAA90325; Thu, 26 Sep 2002 11:48:35 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 32.1 
In-reply-to: Your message of "Wed, 25 Sep 2002 14:35:03 EDT." <[e-mail]> 
Date: Thu, 26 Sep 2002 11:48:35 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> How about:
> "5.1.1 ORIGIN
>   
>      ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
>      shall be generated by the autonomous system that originates the
>      associated routing information. Its value shall not be
>      changed by any other speaker unless the other speaker is
>      administratively configured to do so to affect policy
>      decisions."



How about if we save time and in the definitions section we just state
that MUST means manditory except if configured to do otherwise.  That
should cover many of the objections in our list.  :-)

Or maybe we should just leave things as is and not go around adding
"unless administratively configured to do otherwise" ["to affect
policy decisions" being the most common reason for the otherwise].

Mannually changing the origin code should not be encouraged.

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 LAA09576 for <[e-mail]>; Thu, 26 Sep 2002 11:33:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E9A59912E3; Thu, 26 Sep 2002 11:33:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9085912E4; Thu, 26 Sep 2002 11:33:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 64335912E3 for <[e-mail]>; Thu, 26 Sep 2002 11:33:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4A3965E00B; Thu, 26 Sep 2002 11:33:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 339F25DFF5 for <[e-mail]>; Thu, 26 Sep 2002 11:33:03 -0400 (EDT)
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 LAA90231; Thu, 26 Sep 2002 11:33:41 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: Alex Zinin <[e-mail]>, "Abarbanel,     Benjamin" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Generial Editorial Comment 
In-reply-to: Your message of "Sun, 22 Sep 2002 18:09:28 PDT." <[e-mail]> 
Date: Thu, 26 Sep 2002 11:33:41 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Yakov Rekhter writes
:
> Alex,
> 
> > Defining terms like this in a separate section would be really nice.
> > (BTW, I personally think using "BGP session" which works over a "TCP
> > connection" would be closer to the terminology we're actually using
> > now and would avoid possible confusions when people read terms like
> > "Connection collision") It would also be great if we had descriptions
> > for all data structures that are not explicitly defined (e.g., the
> > current spec has no notion of a peer data structure), timers, etc.
> > 
> > Two other things that I think would make sense to explicitly
> > define are
> > 
> >    - processing of incoming TCP connections (peer lookup, acceptance,
> >      FSM creation, collision control,)
> > 
> >    - generation of events while processing BGP messages, i.e.,
> >      the text describing message processing should say where
> >      needed that a specific event for the BGP session should
> >      be generated.
> 
> Please suggest the appropriate text.
> 
> yakov.



Yakov,

Here is some suggestion.  I don't know where in the document you'd
like to put this or whether you would prefer to omit it.  That's up to
you.

  BGP must maintain separate FSM for each configured peer.  Each BGP
  peer paired in a potential connection will atempt to connect to the
  other.  For the purpose of this discussions, the active or connect
  side of a TCP connection (the side sending the first TCP SYN packet)
  is called outgoing.  The passive or listenning side (the sender of
  the first SYN ACK) is called the an incoming connection.

  A BGP implementation must connect to and listen on TCP port 179 for
  incoming connections in addition to trying to connect to peers.  For
  each incoming connection, a state machine must be instantiated.
  There exists a period in which the identity of the peer on the other
  end of an incoming connection is not known with certainty.  During
  this time, both an incoming and outgoing connection for the same
  peer may exist.  This is referred to as a connection collision (see
  Section x.x, was 6.8).

  A BGP implementation will have at most one FSM for each peer plus
  one FSM for each incoming TCP connection for which the peer has not
  yet been identified.  Each FSM corresponds to exactly one TCP
  connection.

The above covers Alex's first request only.

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 LAA08914 for <[e-mail]>; Thu, 26 Sep 2002 11:20:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4E55E912DF; Thu, 26 Sep 2002 11:19:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 101DD912E1; Thu, 26 Sep 2002 11:19:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1AAAE912DF for <[e-mail]>; Thu, 26 Sep 2002 11:19:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 05E555DFF5; Thu, 26 Sep 2002 11:19:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from titanium.zebra.org (eAc1Abh015.tky.mesh.ad.jp [61.193.80.15]) by segue.merit.edu (Postfix) with ESMTP id EB0ED5DE83 for <[e-mail]>; Thu, 26 Sep 2002 11:19:38 -0400 (EDT)
Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id LAA00989; Thu, 26 Sep 2002 11:22:36 -0400
Date: Thu, 26 Sep 2002 08:22:36 -0700
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: Re: issue 21
In-Reply-To: <[e-mail]>
References: <[e-mail]>
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

I also thought nobody uses BGP own simple password auth.  It is not
secure.  It is just a better than nothing kind of thing.  But MD5 auth
is not supported by all of vendors.  Still there are vendors only can
do simple password auth due to the limitation of TCP/IP stack
capability (Zebra also suffer from it).  In that case BGP own simple
password can be a only way.

Issue 21's main point is mentioning MD5 authentication along with BGP
own password auth.  I agree with it and current text is enough for the
purpose.  I know people actually uses BGP own auth (just a few though)
so I hesitate to say that deprecating BGP own auth.

>Let me be more exact:
>Who uses *BGP's own* authentication mechanisms???
>
>-----Original Message-----
>From: Kunihiro Ishiguro [mailto:[e-mail]] 
>Sent: Thursday, September 26, 2002 10:46 AM
>To: Natale, Jonathan
>Cc: 'Yakov Rekhter'; [e-mail]
>Subject: Re: issue 21
>
>>Who uses bgp authentication?  I though it was nobody. I thought the goal
>was
>>to document existing practice.
>
>Many people are using BGP authentication both simple text and MD5
>authentication.  I've got many requests to implement it in
>Zebra/ZebOS.  So I believe let the current text as it is will achieve
>existing practice.
>-- 
>Kunihiro Ishiguro


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 LAA08879 for <[e-mail]>; Thu, 26 Sep 2002 11:19:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CECFF912E0; Thu, 26 Sep 2002 11:18:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F5AC9122B; Thu, 26 Sep 2002 11:18:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 72171912DF for <[e-mail]>; Thu, 26 Sep 2002 11:18:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 52BA15DFF5; Thu, 26 Sep 2002 11:18:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id C66085DE83 for <[e-mail]>; Thu, 26 Sep 2002 11:18:19 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8QFIGa57341; Thu, 26 Sep 2002 11:18:16 -0400 (EDT) (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 g8QFIDG57334; Thu, 26 Sep 2002 11:18:13 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8QFIDJ23925; Thu, 26 Sep 2002 11:18:13 -0400 (EDT)
Date: Thu, 26 Sep 2002 11:18:13 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: Re: issue 24
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 Wed, Sep 25, 2002 at 02:19:28PM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov, Ben,

On Wed, Sep 25, 2002 at 02:19:28PM -0700, Yakov Rekhter wrote:
>    Changing attribute of a route is accomplished by advertising a
>    replacement route. The replacement route carries new (changed)
>    attributes and has the same NLRI as the original route.

My issue with this is that we're defining a route as a path attributes set
keyed on an NLRI.  In the case of MP-BGP, its also keyed on the AFI/SAFI.

So, to say that we're "changing attributes" is really saying that we're
changing the route.

So, to say that we are withdrawing the previous route (by our
definition of a route) from service is indeed correct.  Its just the
fact that we can do so by sending a new path attributes set with
an existing NLRI key to atomically update it that makes it a "change".

However, the notion of it being a "change" is probably an implementation
detail, although one that has strong ties with the MRAI and MAOI times
and WRD.

> 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 LAA08873 for <[e-mail]>; Thu, 26 Sep 2002 11:19:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3EE919122B; Thu, 26 Sep 2002 11:18:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08B5F912DF; Thu, 26 Sep 2002 11:18:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0E6FA9122B for <[e-mail]>; Thu, 26 Sep 2002 11:18:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DB7305E009; Thu, 26 Sep 2002 11:18:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by segue.merit.edu (Postfix) with ESMTP id B8D1E5DE83 for <[e-mail]>; Thu, 26 Sep 2002 11:18:34 -0400 (EDT)
Received: from pmismtp05.wcomnet.com ([166.38.62.53]) by firewall.wcom.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 26 Sep 2002 15:17:06 +0000 (GMT)
Received: from pmismtp05.wcomnet.com by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May  7 2002)) with SMTP id <[e-mail]>; Thu, 26 Sep 2002 15:17:05 +0000 (GMT)
Received: from rbonica ([166.60.14.53]) by pmismtp05.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <[e-mail]>; Thu, 26 Sep 2002 15:17:05 +0000 (GMT)
Date: Thu, 26 Sep 2002 11:03:17 -0400
From: Ron Bonica <[e-mail]>
Subject: RE: issue 21
In-reply-to:  <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Sender: [e-mail]
Precedence: bulk

Jonathan,

We authenticate BGP peering sessions.

For rationale, see
http://www.ietf.org/internet-drafts/draft-murphy-bgp-vuln-00.txt, and
http://www.ietf.org/internet-drafts/draft-murphy-bgp-protect-00.txt.

                          Ron

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of
> Natale, Jonathan
> Sent: Thursday, September 26, 2002 10:34 AM
> To: 'Yakov Rekhter'; [e-mail]
> Subject: RE: issue 21
>
>
> Disagree.
>
> Who uses bgp authentication?  I though it was nobody. I thought
> the goal was
> to document existing practice.
>
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Thursday, September 26, 2002 10:04 AM
> To: [e-mail]
> Subject: issue 21
>
>   21) Authentication Text Update
>
> ------------------------------------------------------------------
> ----------
>   Status: No Consensus
>   Change: Potentially
>   Summary: A small change to the "Authentication Data:" section to mention
>     well established MD5 support.
>
>   Discussion:
>
>     P. 10, "Authentication Data:" section you might want to add this,
>     It is also possible to use MD5 (RFC2385) at the transport layer to
> validate
>     the entire BGP message.
>
>   There was no discussion on this issue.
>
> There is already text that covers this:
>
>   "Any authentication scheme used by TCP (e.g., RFC2385 [RFC2385])
>    may be used in addition to BGP's own authentication mechanisms."
>
>    ....
>
>   "In addition, BGP supports the ability to authenticate its data
>    stream by using [RFC2385]."
>
> So, I see no need to add the text proposed above.
>
> 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 LAA08306 for <[e-mail]>; Thu, 26 Sep 2002 11:06:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CFA77912DD; Thu, 26 Sep 2002 11:06:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98EB6912DE; Thu, 26 Sep 2002 11:06:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 99628912DD for <[e-mail]>; Thu, 26 Sep 2002 11:05:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 892B45E007; Thu, 26 Sep 2002 11:05:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id D219F5DE83 for <[e-mail]>; Thu, 26 Sep 2002 11:05:58 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8QF5va56941; Thu, 26 Sep 2002 11:05:57 -0400 (EDT) (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 g8QF5sG56934; Thu, 26 Sep 2002 11:05:54 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8QF5sM23773; Thu, 26 Sep 2002 11:05:54 -0400 (EDT)
Date: Thu, 26 Sep 2002 11:05:54 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 10
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 Thu, Sep 26, 2002 at 06:06:16AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Sep 26, 2002 at 06:06:16AM -0700, Yakov Rekhter wrote:
> Lets say an implementation can't support BGP_COMMUNITY with more
> than 2 communities. Or lets say an implementation can't support
> path attributes with more than 255 octets (the implementation
> can't support extended length). All these are examples of a
> deficient implementation. Specifying operations of a deficient
> implementation is certainly outside the scope of the spec.

I would agree.  But specifying general overflow behavior is *not*
out of scope.

In any case, I don't object to leaving this behavior implementation
specific, so I wont argue the point too strongly.

Its probably sufficient to say "If you can't do the mandatory things
you need to do while propagating a route, don't propagate the route".

> 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 KAA07581 for <[e-mail]>; Thu, 26 Sep 2002 10:51:16 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E8EF8912DB; Thu, 26 Sep 2002 10:50:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B23BB912DC; Thu, 26 Sep 2002 10:50:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 79D34912DB for <[e-mail]>; Thu, 26 Sep 2002 10:50:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 643475DFE9; Thu, 26 Sep 2002 10:50:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 29D825DD93 for <[e-mail]>; Thu, 26 Sep 2002 10:50:48 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1H4JV>; Thu, 26 Sep 2002 10:50:47 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Kunihiro Ishiguro'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 21
Date: Thu, 26 Sep 2002 10:50:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Let me be more exact:
Who uses *BGP's own* authentication mechanisms???

-----Original Message-----
From: Kunihiro Ishiguro [mailto:[e-mail]] 
Sent: Thursday, September 26, 2002 10:46 AM
To: Natale, Jonathan
Cc: 'Yakov Rekhter'; [e-mail]
Subject: Re: issue 21

>Who uses bgp authentication?  I though it was nobody. I thought the goal
was
>to document existing practice.

Many people are using BGP authentication both simple text and MD5
authentication.  I've got many requests to implement it in
Zebra/ZebOS.  So I believe let the current text as it is will achieve
existing practice.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA07441 for <[e-mail]>; Thu, 26 Sep 2002 10:48:36 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B6920912CE; Thu, 26 Sep 2002 10:48:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0BFBD912DB; Thu, 26 Sep 2002 10:47:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C6D3A912CE for <[e-mail]>; Thu, 26 Sep 2002 10:47:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 86AAD5DFA9; Thu, 26 Sep 2002 10:47:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from titanium.zebra.org (eAc1Abh015.tky.mesh.ad.jp [61.193.80.15]) by segue.merit.edu (Postfix) with ESMTP id 786875DD93 for <[e-mail]>; Thu, 26 Sep 2002 10:47:26 -0400 (EDT)
Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id KAA00942 for <[e-mail]>; Thu, 26 Sep 2002 10:50:28 -0400
Date: Thu, 26 Sep 2002 07:50:27 -0700
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: [e-mail]
Subject: issue 37
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id KAA07441

>----------------------------------------------------------------------------
>37) Combine "Unfeasable Routes" and "Withdrawn Routes"
>----------------------------------------------------------------------------
>Status: No Consensus
>Change: Potentially
>Summary: No definition extant for "Unfeasable Routes". 
>
>Discussion:
>
>3. P. 45, Phase I, There is no definition of what are unfeasible routes? Are
>they the same as withdrawn routes? If so, the two should be combined to one
>name.

>From implementation stand point there is no difference between
"Unfeasible Routes" and "Withdrawn Routes".  When the route is
unfeasible, BGP withdraw the route.  I think combining two name to one
name make sense.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA07271 for <[e-mail]>; Thu, 26 Sep 2002 10:43:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BDCBC912DA; Thu, 26 Sep 2002 10:42:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F3DF912DB; Thu, 26 Sep 2002 10:42:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 898E5912DA for <[e-mail]>; Thu, 26 Sep 2002 10:42:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 787E55DFBE; Thu, 26 Sep 2002 10:42:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from titanium.zebra.org (eAc1Abh015.tky.mesh.ad.jp [61.193.80.15]) by segue.merit.edu (Postfix) with ESMTP id 6D42E5DD93 for <[e-mail]>; Thu, 26 Sep 2002 10:42:36 -0400 (EDT)
Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id KAA00935; Thu, 26 Sep 2002 10:45:33 -0400
Date: Thu, 26 Sep 2002 07:45:33 -0700
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: Re: issue 21
In-Reply-To: <[e-mail]>
References: <[e-mail]>
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>Who uses bgp authentication?  I though it was nobody. I thought the goal was
>to document existing practice.

Many people are using BGP authentication both simple text and MD5
authentication.  I've got many requests to implement it in
Zebra/ZebOS.  So I believe let the current text as it is will achieve
existing practice.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA06921 for <[e-mail]>; Thu, 26 Sep 2002 10:35:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EDF34912D9; Thu, 26 Sep 2002 10:34:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B93F3912DA; Thu, 26 Sep 2002 10:34:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7ED90912D9 for <[e-mail]>; Thu, 26 Sep 2002 10:34:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6931E5DF39; Thu, 26 Sep 2002 10:34:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 2CC8A5DD93 for <[e-mail]>; Thu, 26 Sep 2002 10:34:27 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1H4HT>; Thu, 26 Sep 2002 10:34:26 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 21
Date: Thu, 26 Sep 2002 10:34:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Disagree.

Who uses bgp authentication?  I though it was nobody. I thought the goal was
to document existing practice.

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Thursday, September 26, 2002 10:04 AM
To: [e-mail]
Subject: issue 21

  21) Authentication Text Update
 
----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: A small change to the "Authentication Data:" section to mention
    well established MD5 support.
  
  Discussion:
  
    P. 10, "Authentication Data:" section you might want to add this,
    It is also possible to use MD5 (RFC2385) at the transport layer to
validate
    the entire BGP message.
  
  There was no discussion on this issue.

There is already text that covers this:

  "Any authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) 
   may be used in addition to BGP's own authentication mechanisms."
  
   ....

  "In addition, BGP supports the ability to authenticate its data 
   stream by using [RFC2385]."

So, I see no need to add the text proposed above.

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 KAA06260 for <[e-mail]>; Thu, 26 Sep 2002 10:16:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F2173912D8; Thu, 26 Sep 2002 10:15:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7579912D9; Thu, 26 Sep 2002 10:15:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 62871912D8 for <[e-mail]>; Thu, 26 Sep 2002 10:15:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 96D995E00A; Thu, 26 Sep 2002 10:15:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 982415E007 for <[e-mail]>; Thu, 26 Sep 2002 10:15:40 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8QEFem39154 for <[e-mail]>; Thu, 26 Sep 2002 07:15:40 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issues 13, 14, 61
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 07:15:40 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

I think that issue 13, 14 and 61 essentially cover the same topic,
namely when a BGP speaker originates a route, what should be the value
of the NEXT_HOP carried by the route. Comments on this issue (including
proposed text, if needed) would be appreciated.

Yakov.

  13) Next Hop for Originated Route
  ----------------------------------------------------------------------------
  Status: Consensus
  Change: No
  Summary: No reponses, assumed consensus to keep things the same.
  
  Discussion:
  
  There was a one-message thread entitled "next hop for originated route".
  This message received no reponse, so the assumption is that there is
  a consensus to keep things as they are.
  
  ----------------------------------------------------------------------------
  14) NEXT_HOP to Internal Peer
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: One concuring reponse, no text proposed.
  
  Discussion:
  
  The thread entitled "NEXT_HOP to internal peer" starts with this question:
  
  When sending a locally originated route to an internal peer, what should
  NEXT_HOP be set to?
  
  One response suggested that we add a line stating that the NEXT_HOP address
  originates from the IGP.
  
  ----------------------------------------------------------------------------
  61) Next Hop for Redistributed Routes
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: There was text suggested, but no discussion.
  
  Discussion:
  
  Jonathan began this thread with:
  
  I propose adding:
       
  "When announcing a locally 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 address of the interface that is
  used to reach the peer)."
       
  AFTER
  
  "When sending a message to an internal peer, 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."
  
  There has been no discussion on this.
  
  This is discussed in the "Next hop for redistributed routes" 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 KAA05968 for <[e-mail]>; Thu, 26 Sep 2002 10:12:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 60944912D7; Thu, 26 Sep 2002 10:11:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2DA60912D8; Thu, 26 Sep 2002 10:11:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 280BA912D7 for <[e-mail]>; Thu, 26 Sep 2002 10:11:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 086905DD93; Thu, 26 Sep 2002 10:11:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from titanium.zebra.org (eAc1Abh015.tky.mesh.ad.jp [61.193.80.15]) by segue.merit.edu (Postfix) with ESMTP id F08B95E007 for <[e-mail]>; Thu, 26 Sep 2002 10:11:31 -0400 (EDT)
Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id KAA00919; Thu, 26 Sep 2002 10:14:31 -0400
Date: Thu, 26 Sep 2002 07:14:31 -0700
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 21
In-Reply-To: <[e-mail]>
References: <[e-mail]>
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

agreed.

>  21) Authentication Text Update
>  ----------------------------------------------------------------------------
>  Status: No Consensus
>  Change: Potentially
>  Summary: A small change to the "Authentication Data:" section to mention
>    well established MD5 support.
>  
>  Discussion:
>  
>    P. 10, "Authentication Data:" section you might want to add this,
>    It is also possible to use MD5 (RFC2385) at the transport layer to validate
>    the entire BGP message.
>  
>  There was no discussion on this issue.
>
>There is already text that covers this:
>
>  "Any authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) 
>   may be used in addition to BGP's own authentication mechanisms."
>  
>   ....
>
>  "In addition, BGP supports the ability to authenticate its data 
>   stream by using [RFC2385]."
>
>So, I see no need to add the text proposed above.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA05503 for <[e-mail]>; Thu, 26 Sep 2002 10:04:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A7EC1912D4; Thu, 26 Sep 2002 10:04:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D293912D7; Thu, 26 Sep 2002 10:04:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF2D0912D4 for <[e-mail]>; Thu, 26 Sep 2002 10:03:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C27225DFB8; Thu, 26 Sep 2002 10:03:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 34BB15DD93 for <[e-mail]>; Thu, 26 Sep 2002 10:03:53 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8QE3qm38661 for <[e-mail]>; Thu, 26 Sep 2002 07:03:52 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 21
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 07:03:52 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  21) Authentication Text Update
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: A small change to the "Authentication Data:" section to mention
    well established MD5 support.
  
  Discussion:
  
    P. 10, "Authentication Data:" section you might want to add this,
    It is also possible to use MD5 (RFC2385) at the transport layer to validate
    the entire BGP message.
  
  There was no discussion on this issue.

There is already text that covers this:

  "Any authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) 
   may be used in addition to BGP's own authentication mechanisms."
  
   ....

  "In addition, BGP supports the ability to authenticate its data 
   stream by using [RFC2385]."

So, I see no need to add the text proposed above.

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 JAA04852 for <[e-mail]>; Thu, 26 Sep 2002 09:48:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F356A912D2; Thu, 26 Sep 2002 09:48:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BCA34912D4; Thu, 26 Sep 2002 09:48:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B49B5912D2 for <[e-mail]>; Thu, 26 Sep 2002 09:48:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 981995DFFB; Thu, 26 Sep 2002 09:48:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from titanium.zebra.org (eAc1Abh015.tky.mesh.ad.jp [61.193.80.15]) by segue.merit.edu (Postfix) with ESMTP id 762AD5E00C for <[e-mail]>; Thu, 26 Sep 2002 09:48:07 -0400 (EDT)
Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id JAA00876; Thu, 26 Sep 2002 09:50:42 -0400
Date: Thu, 26 Sep 2002 06:50:42 -0700
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Gargi Nalawade'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, "'Martin, Christian'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: Re: issue 40
In-Reply-To: <[e-mail]>
References: <[e-mail]>
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>I guess the problem was that the Cisco search tool comes up with some
>specific release first and its not obvious where the mainline release
>is. Thus, I assumed it was the case for all the other releases. 
>
>My mistake, it would have been nicer if their/your search tools found
>the mainline release first. I used just a generic term for the command

Well, so for issue 40.  Please let it be.  Actually Zebra has per peer
MinRouteAdvertisementInterval configuration as same as Cisco.

router bgp ANS
 neighbor A.B.C.D advertisement-interval <0-600>
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA04101 for <[e-mail]>; Thu, 26 Sep 2002 09:29:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 286B8912D0; Thu, 26 Sep 2002 09:28:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC018912D2; Thu, 26 Sep 2002 09:28:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BC370912D0 for <[e-mail]>; Thu, 26 Sep 2002 09:28:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id AD7D05E002; Thu, 26 Sep 2002 09:28:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from titanium.zebra.org (eAc1Abh015.tky.mesh.ad.jp [61.193.80.15]) by segue.merit.edu (Postfix) with ESMTP id 9192D5DFFB for <[e-mail]>; Thu, 26 Sep 2002 09:28:40 -0400 (EDT)
Received: from titanium.zebra.org (IDENT:kunihiro@titanium [127.0.0.1]) by titanium.zebra.org (8.9.3/8.9.3) with ESMTP id JAA00832; Thu, 26 Sep 2002 09:31:38 -0400
Date: Thu, 26 Sep 2002 06:31:38 -0700
Message-ID: <[e-mail]>
From: Kunihiro Ishiguro <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 58
In-Reply-To: <[e-mail]>
References: <[e-mail]>
User-Agent: Wanderlust/2.8.1 (Something) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.2.50 (powerpc-unknown-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

>  58) Deprication of ATOMIC_AGGREGATE
>  ----------------------------------------------------------------------------
>  Status: No Consensus
>  Change: Potentially
>  Summary: It is proposed that ATOMIC_AGGREGATE be depricated.  There has 
>   not yet been any discussion on the proposed changes.
>
>Comments on this issue would be appreciated.
>
>In the absence of any objections to the changes proposed by Jeff, the
>changes would be accepted. 

I strongly agree with Jeff to deprecate ATOMIC_AGGREGATE.  The network
situation which ATOMIC_AGGREGATE aimed to resolve is not realistic.
-- 
Kunihiro Ishiguro


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA03584 for <[e-mail]>; Thu, 26 Sep 2002 09:18:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5ADEB912CD; Thu, 26 Sep 2002 09:18:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A171912D0; Thu, 26 Sep 2002 09:18:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 265CB912CD for <[e-mail]>; Thu, 26 Sep 2002 09:17:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0D0355DFFB; Thu, 26 Sep 2002 09:17:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 764C35DF20 for <[e-mail]>; Thu, 26 Sep 2002 09:17:41 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8QDHfm36344 for <[e-mail]>; Thu, 26 Sep 2002 06:17:41 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 58
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 06:17:41 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  58) Deprication of ATOMIC_AGGREGATE
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: It is proposed that ATOMIC_AGGREGATE be depricated.  There has 
   not yet been any discussion on the proposed changes.

Comments on this issue would be appreciated.

In the absence of any objections to the changes proposed by Jeff, the
changes would be 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 JAA03042 for <[e-mail]>; Thu, 26 Sep 2002 09:07:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 25F13912D1; Thu, 26 Sep 2002 09:06:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0437912D2; Thu, 26 Sep 2002 09:06:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B2CC912D1 for <[e-mail]>; Thu, 26 Sep 2002 09:06:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 448A95DF20; Thu, 26 Sep 2002 09:06:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id DC2F25DFD7 for <[e-mail]>; Thu, 26 Sep 2002 09:06:37 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8QD6Gm35869; Thu, 26 Sep 2002 06:06:25 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: Re: issue 10 
In-Reply-To: Your message of "Wed, 25 Sep 2002 15:21:31 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 06:06:16 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> Ben,
> 
> On Wed, Sep 25, 2002 at 03:10:32PM -0400, Abarbanel, Benjamin wrote:
> > AS_PATH attribute is a well known mandatory attribute. All vendors that
> > support the standard RFC1771 BGP protocol must have this attribute in the
> > payload of the UPDATE message. Your point is not valid.
> 
> I may be discussing the wrong issue in context of this particular
> thread.  Let me tackle the one I was trying to bring up first.
> 
> Lets say an implementation can't support an AS_PATH with more than
> 256 AS's.  Since it can't support it, it MUST NOT propagate that
> route if it cannot add on the 257th AS to the AS_PATH.

Lets say an implementation can't support BGP_COMMUNITY with more
than 2 communities. Or lets say an implementation can't support
path attributes with more than 255 octets (the implementation
can't support extended length). All these are examples of a
deficient implementation. Specifying operations of a deficient
implementation is certainly outside the scope of the spec.

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 IAA02360 for <[e-mail]>; Thu, 26 Sep 2002 08:52:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 97AB3912ED; Thu, 26 Sep 2002 08:52:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C736912EC; Thu, 26 Sep 2002 08:52:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C87B912E0 for <[e-mail]>; Thu, 26 Sep 2002 08:52:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CAD805DFF8; Thu, 26 Sep 2002 08:52:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 260405DFFA for <[e-mail]>; Thu, 26 Sep 2002 08:52:11 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8QCqAm34980; Thu, 26 Sep 2002 05:52:10 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
Subject: Re: issue 8
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 26 Sep 2002 05:52:10 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

forwarding...
------- Forwarded Message

Date:    Thu, 26 Sep 2002 16:58:19 +0530
From:    "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
To:      Yakov Rekhter <[e-mail]>
Subject: FW: issue 8

Hello,

    My mail does not seem to have made it to the list. Could you please
forward it ?

Thanks,
Siva
([e-mail])

- -----Original Message-----
From: Sivananda Ramnath - CTD, Chennai. 
Sent: Thursday, September 26, 2002 3:21 PM
To: [e-mail]
Subject: RE: issue 8


Hello,

    The ConnectRetry timer is should have a value that is 'sufficiently
large to allow TCP initialization. Application of jitter can reduce the this
value (by up to 25%). A configuration which the ConnectRetry timer has been
pegged at a value close to TCP connection time may cause a connection to be
terminated as a result of this jitter. Is this a cause for concern ? 

    The default value suggested for ConnectRetry (120 seconds) is
sufficiently large that event with a jitter of 0.75, it will be greater than
TCP'c connection establishment timer.

    Is adding a jitter to the ConnectRetry timer a standard practice ? What
benefit does this provide ?

Sivanand
([e-mail])


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 7:08 AM
> To: [e-mail]
> Subject: issue 8
> 
> 
>    8) Jitter Text
>    
> --------------------------------------------------------------
> --------------
>    Status: No Consensus
>    Change: Potentially 
>    Summary:
>     Change:
>      "jitter should be applied to the
>       timers associated with MinASOriginationInterval, Keepalive, and
>       MinRouteAdvertisementInterval"
>     To:
>      "jitter should be applied to the timers associated with 
> ConnectRetry timer"
>    
>    Discussion:
>    
>    In the tread entitled "bgp draft review":
>    The thread also proposed:
>    
>    "jitter should be applied to the
>       timers associated with MinASOriginationInterval, Keepalive, and
>       MinRouteAdvertisementInterval"
>    
>    Be changed to:
>    
>    "jitter should be applied to the
>       timers associated with ConnectRetry timer"
>    
>    - There was limited discussion on this issue.  Implementions will
>    add jitter to all of these.  There is no consensus on changing this
>    text.
> 
> I would suggest that we'll change the text to make sure that jitter
> is applied to all the timers. To make this change I would suggest
> to get rid of section 9.2.1.3 ("Jitter"), move the text of this
> section into Appendix "BGP Timers", and expand the text to indicate
> that jitter applies to ConnectRetry timer as well.
> 
> Yakov.
> 

------- End of Forwarded Message



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id HAA28918 for <[e-mail]>; Thu, 26 Sep 2002 07:40:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 05FB191225; Thu, 26 Sep 2002 07:39:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3E58912A9; Thu, 26 Sep 2002 07:39:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76BCF91225 for <[e-mail]>; Thu, 26 Sep 2002 07:39:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5E4E35DFDD; Thu, 26 Sep 2002 07:39:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from fsnt.future.futsoft.com (unknown [203.197.140.35]) by segue.merit.edu (Postfix) with ESMTP id 538945DFDC for <[e-mail]>; Thu, 26 Sep 2002 07:39:45 -0400 (EDT)
Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id <[e-mail]> for <[e-mail]>; Thu, 26 Sep 2002 17:10:22 +0530
Received: from amudha (amudha.future.futsoft.com [10.6.12.9]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id g8QBdV78010520 for <[e-mail]>; Thu, 26 Sep 2002 17:09:31 +0530
Reply-To: <[e-mail]>
From: "Amudhavalli  Narayanan" <[e-mail]>
To: <[e-mail]>
Subject: Use of SNPA field in MBGP
Date: Thu, 26 Sep 2002 17:06:36 +0530
Message-Id: <002f01c26550$f94a9980$[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hi,
I am not clear with the usage of SNPA field in the MP_UNREACH_NLRI attribute
. Can someone please clarify on this?

Thanks,
Amudha

***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA22629 for <[e-mail]>; Wed, 25 Sep 2002 17:33:54 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 35E32912D0; Wed, 25 Sep 2002 17:33:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 89649912BC; Wed, 25 Sep 2002 17:33:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A67F5912D1 for <[e-mail]>; Wed, 25 Sep 2002 17:33:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3D8B55DE92; Wed, 25 Sep 2002 17:33:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 98CD35DE8F for <[e-mail]>; Wed, 25 Sep 2002 17:33:06 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PLX4m77632; Wed, 25 Sep 2002 14:33:04 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 10 
In-Reply-To: Your message of "Wed, 25 Sep 2002 17:30:04 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 14:33:04 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

>   If nobody objects, lets remove the last line.

ok.

yakov.

> 
> Thanks,
> Ben
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Wednesday, September 25, 2002 5:24 PM
> > To: Abarbanel, Benjamin
> > Cc: [e-mail]
> > Subject: Re: issue 10 
> > 
> > 
> > Ben,
> > 
> > > > -----Original Message-----
> > > > From: Yakov Rekhter [mailto:[e-mail]]
> > > > Sent: Wednesday, September 25, 2002 2:47 PM
> > > > To: [e-mail]
> > > > Subject: issue 10
> > > > 
> > > > 
> > > >   10) Extending AS_PATH Attribute
> > > >   
> > > > --------------------------------------------------------------
> > > > --------------
> > > >   Status: No Consensus
> > > >   Change: Potentially
> > > >   Summary: Specific text required to delimit behavior when 
> > > > AS_PATH length
> > > >    is exceeded.
> > > >   
> > > >   Discussion:
> > > >   
> > > >   The "Extending AS_PATH attribute length en route" 
> > thread brought up
> > > >   the issue of what action should we specify when we 
> > receive a route
> > > >   with an AS_PATH that exceeds the defined maximum 
> > length.  There was
> > > >   some discussion, and it was suggested that, after 
> > logging the error,
> > > >   the route not be propegated.  No text was proposed.  This 
> > > > issue needs
> > > >   consensus:  Do we specify the behavior?  If so what 
> > with what text?
> > > > 
> > > > The real issue here is how to handle the case when a route
> > > > (a single address prefix + path attributes) doesn't fit into
> > > > 4K bytes (as the max BGP message size is 4 K). To address
> > > > this issue I would suggest to add the following to 9.2:
> > > > 
> > > >    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 speaker may choose not to advertise the route to its
> > > >    peers.  Other alternatives of handling this situation 
> > are outside
> > > >    the scope of this document.
> > > > 
> > > 
> > > I think to leave this wide open is a mistake. If the 
> > AS-PATH field makes
> > > the "single" route UPDATE message too long (> 4k bytes). 
> > Its no different
> > > than having an IP packet expire (decrement to zero) the TTL field.
> > > Therefore,
> > > we should consider the packet invalid and take whatever 
> > course of action
> > > is appropriate for a route that cannot be transported in 
> > the given BGP
> > > protocol. There is no need to say that "Other alternatives 
> > of handling this
> > > situation are outside the scope of this document".
> > > 
> > > In summary, I vote to delete the last line starting with 
> > "Other alternatives
> > > ..."
> > 
> > I have no objections to this.
> > 
> > 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 RAA22516 for <[e-mail]>; Wed, 25 Sep 2002 17:31:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 87D1C912CF; Wed, 25 Sep 2002 17:30:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2144A912D1; Wed, 25 Sep 2002 17:30:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4BB54912CF for <[e-mail]>; Wed, 25 Sep 2002 17:30:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 049F35DE9C; Wed, 25 Sep 2002 17:30:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 36F1B5DE93 for <[e-mail]>; Wed, 25 Sep 2002 17:30:07 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA24870; Wed, 25 Sep 2002 17:30:04 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA21096; Wed, 25 Sep 2002 17:30:06 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R72DF4>; Wed, 25 Sep 2002 17:30:05 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 10 
Date: Wed, 25 Sep 2002 17:30:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov,

  If nobody objects, lets remove the last line.

Thanks,
Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 5:24 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: issue 10 
> 
> 
> Ben,
> 
> > > -----Original Message-----
> > > From: Yakov Rekhter [mailto:[e-mail]]
> > > Sent: Wednesday, September 25, 2002 2:47 PM
> > > To: [e-mail]
> > > Subject: issue 10
> > > 
> > > 
> > >   10) Extending AS_PATH Attribute
> > >   
> > > --------------------------------------------------------------
> > > --------------
> > >   Status: No Consensus
> > >   Change: Potentially
> > >   Summary: Specific text required to delimit behavior when 
> > > AS_PATH length
> > >    is exceeded.
> > >   
> > >   Discussion:
> > >   
> > >   The "Extending AS_PATH attribute length en route" 
> thread brought up
> > >   the issue of what action should we specify when we 
> receive a route
> > >   with an AS_PATH that exceeds the defined maximum 
> length.  There was
> > >   some discussion, and it was suggested that, after 
> logging the error,
> > >   the route not be propegated.  No text was proposed.  This 
> > > issue needs
> > >   consensus:  Do we specify the behavior?  If so what 
> with what text?
> > > 
> > > The real issue here is how to handle the case when a route
> > > (a single address prefix + path attributes) doesn't fit into
> > > 4K bytes (as the max BGP message size is 4 K). To address
> > > this issue I would suggest to add the following to 9.2:
> > > 
> > >    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 speaker may choose not to advertise the route to its
> > >    peers.  Other alternatives of handling this situation 
> are outside
> > >    the scope of this document.
> > > 
> > 
> > I think to leave this wide open is a mistake. If the 
> AS-PATH field makes
> > the "single" route UPDATE message too long (> 4k bytes). 
> Its no different
> > than having an IP packet expire (decrement to zero) the TTL field.
> > Therefore,
> > we should consider the packet invalid and take whatever 
> course of action
> > is appropriate for a route that cannot be transported in 
> the given BGP
> > protocol. There is no need to say that "Other alternatives 
> of handling this
> > situation are outside the scope of this document".
> > 
> > In summary, I vote to delete the last line starting with 
> "Other alternatives
> > ..."
> 
> I have no objections to this.
> 
> 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 RAA22338 for <[e-mail]>; Wed, 25 Sep 2002 17:27:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BF868912CE; Wed, 25 Sep 2002 17:26:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8EA82912CF; Wed, 25 Sep 2002 17:26:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9F58B912CE for <[e-mail]>; Wed, 25 Sep 2002 17:26:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8C1075DE9C; Wed, 25 Sep 2002 17:26:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 1566C5DE9A for <[e-mail]>; Wed, 25 Sep 2002 17:26:45 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA24735; Wed, 25 Sep 2002 17:26:42 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA20503; Wed, 25 Sep 2002 17:26:43 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R72C02>; Wed, 25 Sep 2002 17:26:42 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 24 
Date: Wed, 25 Sep 2002 17:26:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov,

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 5:19 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: issue 24 
> 
> 
> Ben,
>  
> > > > "By *definition* a route is a <path attribute, NLRI> 
> pair. From that
> > > > definition it follows that changing one or more path 
> attributes of
> > > > a route means changing a route, which means withdrawing the old
> > > > route (route with the old attributes) from service and 
> advertising
> > > > a new route (route with the new attributes)."
> > > > 
> > > > I think we are playing with words here, 3.1a and 3.1b 
> do not address
> > > > the point as I have argued. Therefore, I am still not satisfied 
> > > > we nailed it down in the spec. 
> > > > 
> > > > As you can see I dont care for assumptions very much.
> > > > 
> > > > I would like to see this statement added somewhere in 
> section 3.1:
> > > > 
> > > > "A route's attributes can be added, modified, or deleted by 
> > > sending another
> > > >  UPDATE message with the same route and the new 
> attributes, or by
> > > > withdrawing
> > > >  the route (route with the old attributes) from service and 
> > > advertising
> > > >  a new route (same route with the new attributes)."
> > > 
> > > If it is "the same route", then *by definition* of a route it 
> > > has to be
> > > the same attributes. And if the attributes changed, then it 
> > > is no longer
> > > "the same route". With this in mind how about adding the 
> > > following to 3.1:
> > > 
> > >   Changing attribute of a route means that the route is withdrawn
> > >   from service, and a replacement route is advertised. 
> The replacement
> > >   route carries new (changed) attributes and has the same 
> NLRI as the 
> > >   route that was withdrawn.
> > > 
> > > Yakov.
> > > 
> > 
> >   Can we change the current route's attribute without 
> taking it out of
> > service (implying no possible network outage)? 
> > 
> >   If the answer is yes, than you will need an extra sentence. 
> > 
> >   If the answer is no, then I am happy with your statement.
> 
> How about the following replacement for the text I proposed above:
> 
>    Changing attribute of a route is accomplished by advertising a
>    replacement route. The replacement route carries new (changed)
>    attributes and has the same NLRI as the original route.
> 

Bingo, I think we have a winner. Sounds good.

Thanks,
Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA22204 for <[e-mail]>; Wed, 25 Sep 2002 17:24:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A27A7912C8; Wed, 25 Sep 2002 17:24:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77F5E912CE; Wed, 25 Sep 2002 17:24:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 49FF6912C8 for <[e-mail]>; Wed, 25 Sep 2002 17:24:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 370DD5DE9A; Wed, 25 Sep 2002 17:24:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 8CC775DE93 for <[e-mail]>; Wed, 25 Sep 2002 17:24:02 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PLNxm76854; Wed, 25 Sep 2002 14:23:59 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 10 
In-Reply-To: Your message of "Wed, 25 Sep 2002 15:01:44 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 14:23:59 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Wednesday, September 25, 2002 2:47 PM
> > To: [e-mail]
> > Subject: issue 10
> > 
> > 
> >   10) Extending AS_PATH Attribute
> >   
> > --------------------------------------------------------------
> > --------------
> >   Status: No Consensus
> >   Change: Potentially
> >   Summary: Specific text required to delimit behavior when 
> > AS_PATH length
> >    is exceeded.
> >   
> >   Discussion:
> >   
> >   The "Extending AS_PATH attribute length en route" thread brought up
> >   the issue of what action should we specify when we receive a route
> >   with an AS_PATH that exceeds the defined maximum length.  There was
> >   some discussion, and it was suggested that, after logging the error,
> >   the route not be propegated.  No text was proposed.  This 
> > issue needs
> >   consensus:  Do we specify the behavior?  If so what with what text?
> > 
> > The real issue here is how to handle the case when a route
> > (a single address prefix + path attributes) doesn't fit into
> > 4K bytes (as the max BGP message size is 4 K). To address
> > this issue I would suggest to add the following to 9.2:
> > 
> >    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 speaker may choose not to advertise the route to its
> >    peers.  Other alternatives of handling this situation are outside
> >    the scope of this document.
> > 
> 
> I think to leave this wide open is a mistake. If the AS-PATH field makes
> the "single" route UPDATE message too long (> 4k bytes). Its no different
> than having an IP packet expire (decrement to zero) the TTL field.
> Therefore,
> we should consider the packet invalid and take whatever course of action
> is appropriate for a route that cannot be transported in the given BGP
> protocol. There is no need to say that "Other alternatives of handling this
> situation are outside the scope of this document".
> 
> In summary, I vote to delete the last line starting with "Other alternatives
> ..."

I have no objections to this.

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 RAA21965 for <[e-mail]>; Wed, 25 Sep 2002 17:19:58 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 06B9F91217; Wed, 25 Sep 2002 17:19:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CAB9A912C7; Wed, 25 Sep 2002 17:19:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A00CB91217 for <[e-mail]>; Wed, 25 Sep 2002 17:19:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 866655DE98; Wed, 25 Sep 2002 17:19:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 1BB835DE94 for <[e-mail]>; Wed, 25 Sep 2002 17:19:30 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PLJSm76304; Wed, 25 Sep 2002 14:19:28 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 24 
In-Reply-To: Your message of "Wed, 25 Sep 2002 17:08:50 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 14:19:28 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,
 
> > > "By *definition* a route is a <path attribute, NLRI> pair. From that
> > > definition it follows that changing one or more path attributes of
> > > a route means changing a route, which means withdrawing the old
> > > route (route with the old attributes) from service and advertising
> > > a new route (route with the new attributes)."
> > > 
> > > I think we are playing with words here, 3.1a and 3.1b do not address
> > > the point as I have argued. Therefore, I am still not satisfied 
> > > we nailed it down in the spec. 
> > > 
> > > As you can see I dont care for assumptions very much.
> > > 
> > > I would like to see this statement added somewhere in section 3.1:
> > > 
> > > "A route's attributes can be added, modified, or deleted by 
> > sending another
> > >  UPDATE message with the same route and the new attributes, or by
> > > withdrawing
> > >  the route (route with the old attributes) from service and 
> > advertising
> > >  a new route (same route with the new attributes)."
> > 
> > If it is "the same route", then *by definition* of a route it 
> > has to be
> > the same attributes. And if the attributes changed, then it 
> > is no longer
> > "the same route". With this in mind how about adding the 
> > following to 3.1:
> > 
> >   Changing attribute of a route means that the route is withdrawn
> >   from service, and a replacement route is advertised. The replacement
> >   route carries new (changed) attributes and has the same NLRI as the 
> >   route that was withdrawn.
> > 
> > Yakov.
> > 
> 
>   Can we change the current route's attribute without taking it out of
> service (implying no possible network outage)? 
> 
>   If the answer is yes, than you will need an extra sentence. 
> 
>   If the answer is no, then I am happy with your statement.

How about the following replacement for the text I proposed above:

   Changing attribute of a route is accomplished by advertising a
   replacement route. The replacement route carries new (changed)
   attributes and has the same NLRI as the original route.

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 RAA21523 for <[e-mail]>; Wed, 25 Sep 2002 17:09:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 159C8912B8; Wed, 25 Sep 2002 17:08:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D94D4912C7; Wed, 25 Sep 2002 17:08:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BD23F912B8 for <[e-mail]>; Wed, 25 Sep 2002 17:08:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A9CB25DE94; Wed, 25 Sep 2002 17:08:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 341245DE98 for <[e-mail]>; Wed, 25 Sep 2002 17:08:53 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA23966; Wed, 25 Sep 2002 17:08:50 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA17769; Wed, 25 Sep 2002 17:08:52 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R72CHD>; Wed, 25 Sep 2002 17:08:51 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 24 
Date: Wed, 25 Sep 2002 17:08:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov,

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 5:02 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: issue 24 
> 
> 
> Ben,
> 
> > Jeff:
> > 
> >   I was just responding to Yakove comment:
> > 
> > "By *definition* a route is a <path attribute, NLRI> pair. From that
> > definition it follows that changing one or more path attributes of
> > a route means changing a route, which means withdrawing the old
> > route (route with the old attributes) from service and advertising
> > a new route (route with the new attributes)."
> > 
> > I think we are playing with words here, 3.1a and 3.1b do not address
> > the point as I have argued. Therefore, I am still not satisfied 
> > we nailed it down in the spec. 
> > 
> > As you can see I dont care for assumptions very much.
> > 
> > I would like to see this statement added somewhere in section 3.1:
> > 
> > "A route's attributes can be added, modified, or deleted by 
> sending another
> >  UPDATE message with the same route and the new attributes, or by
> > withdrawing
> >  the route (route with the old attributes) from service and 
> advertising
> >  a new route (same route with the new attributes)."
> 
> If it is "the same route", then *by definition* of a route it 
> has to be
> the same attributes. And if the attributes changed, then it 
> is no longer
> "the same route". With this in mind how about adding the 
> following to 3.1:
> 
>   Changing attribute of a route means that the route is withdrawn
>   from service, and a replacement route is advertised. The replacement
>   route carries new (changed) attributes and has the same NLRI as the 
>   route that was withdrawn.
> 
> Yakov.
> 

  Can we change the current route's attribute without taking it out of
service
  (implying no possible network outage)? 

  If the answer is yes, than you will need an extra sentence. 

  If the answer is no, then I am happy with your statement.

Ben



> > 
> > 
> > Ben
> > 
> > > -----Original Message-----
> > > From: Jeffrey Haas [mailto:[e-mail]]
> > > Sent: Wednesday, September 25, 2002 4:35 PM
> > > To: Abarbanel, Benjamin
> > > Cc: 'Yakov Rekhter'; [e-mail]
> > > Subject: Re: issue 24
> > > 
> > > 
> > > Ben,
> > > 
> > > On Wed, Sep 25, 2002 at 04:28:07PM -0400, Abarbanel, 
> Benjamin wrote:
> > > > Why withdraw and add the same route if one of the optional 
> > > attributes
> > > > changes from value A to value B.
> > > 
> > > If you're just changing an attribute, the withdrawal is implicit
> > > rather than explicit.  You wouldn't want to explicitly withdraw
> > > a route if you just want to change the attributes because that
> > > has consequences for route damping and also for the MRAI and 
> > > MAOI timers.
> > > 
> > > 3.1a covers the explicit withdrawal
> > > 3.1b covers an implicit withdrawal
> > > 
> > > -- 
> > > 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 RAA21268 for <[e-mail]>; Wed, 25 Sep 2002 17:04:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D7FE8912C9; Wed, 25 Sep 2002 17:02:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A010912B8; Wed, 25 Sep 2002 17:02:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A12DE912C9 for <[e-mail]>; Wed, 25 Sep 2002 17:02:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 897CD5DE93; Wed, 25 Sep 2002 17:02:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id DA4135DE72 for <[e-mail]>; Wed, 25 Sep 2002 17:02:18 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PL2Gm74587; Wed, 25 Sep 2002 14:02:16 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 24 
In-Reply-To: Your message of "Wed, 25 Sep 2002 16:48:01 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 14:02:16 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> Jeff:
> 
>   I was just responding to Yakove comment:
> 
> "By *definition* a route is a <path attribute, NLRI> pair. From that
> definition it follows that changing one or more path attributes of
> a route means changing a route, which means withdrawing the old
> route (route with the old attributes) from service and advertising
> a new route (route with the new attributes)."
> 
> I think we are playing with words here, 3.1a and 3.1b do not address
> the point as I have argued. Therefore, I am still not satisfied 
> we nailed it down in the spec. 
> 
> As you can see I dont care for assumptions very much.
> 
> I would like to see this statement added somewhere in section 3.1:
> 
> "A route's attributes can be added, modified, or deleted by sending another
>  UPDATE message with the same route and the new attributes, or by
> withdrawing
>  the route (route with the old attributes) from service and advertising
>  a new route (same route with the new attributes)."

If it is "the same route", then *by definition* of a route it has to be
the same attributes. And if the attributes changed, then it is no longer
"the same route". With this in mind how about adding the following to 3.1:

  Changing attribute of a route means that the route is withdrawn
  from service, and a replacement route is advertised. The replacement
  route carries new (changed) attributes and has the same NLRI as the 
  route that was withdrawn.

Yakov.

> 
> 
> Ben
> 
> > -----Original Message-----
> > From: Jeffrey Haas [mailto:[e-mail]]
> > Sent: Wednesday, September 25, 2002 4:35 PM
> > To: Abarbanel, Benjamin
> > Cc: 'Yakov Rekhter'; [e-mail]
> > Subject: Re: issue 24
> > 
> > 
> > Ben,
> > 
> > On Wed, Sep 25, 2002 at 04:28:07PM -0400, Abarbanel, Benjamin wrote:
> > > Why withdraw and add the same route if one of the optional 
> > attributes
> > > changes from value A to value B.
> > 
> > If you're just changing an attribute, the withdrawal is implicit
> > rather than explicit.  You wouldn't want to explicitly withdraw
> > a route if you just want to change the attributes because that
> > has consequences for route damping and also for the MRAI and 
> > MAOI timers.
> > 
> > 3.1a covers the explicit withdrawal
> > 3.1b covers an implicit withdrawal
> > 
> > -- 
> > 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 QAA20581 for <[e-mail]>; Wed, 25 Sep 2002 16:48:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 80848912C6; Wed, 25 Sep 2002 16:48:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55AD4912BB; Wed, 25 Sep 2002 16:48:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 97538912C6 for <[e-mail]>; Wed, 25 Sep 2002 16:48:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 80AEB5DE90; Wed, 25 Sep 2002 16:48:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 07E225DE72 for <[e-mail]>; Wed, 25 Sep 2002 16:48:04 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA22995; Wed, 25 Sep 2002 16:48:01 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA14891; Wed, 25 Sep 2002 16:48:03 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R72BPJ>; Wed, 25 Sep 2002 16:48:02 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 24
Date: Wed, 25 Sep 2002 16:48:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Jeff:

  I was just responding to Yakove comment:

"By *definition* a route is a <path attribute, NLRI> pair. From that
definition it follows that changing one or more path attributes of
a route means changing a route, which means withdrawing the old
route (route with the old attributes) from service and advertising
a new route (route with the new attributes)."

I think we are playing with words here, 3.1a and 3.1b do not address
the point as I have argued. Therefore, I am still not satisfied 
we nailed it down in the spec. 

As you can see I dont care for assumptions very much.

I would like to see this statement added somewhere in section 3.1:

"A route's attributes can be added, modified, or deleted by sending another
 UPDATE message with the same route and the new attributes, or by
withdrawing
 the route (route with the old attributes) from service and advertising
 a new route (same route with the new attributes)."


Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 4:35 PM
> To: Abarbanel, Benjamin
> Cc: 'Yakov Rekhter'; [e-mail]
> Subject: Re: issue 24
> 
> 
> Ben,
> 
> On Wed, Sep 25, 2002 at 04:28:07PM -0400, Abarbanel, Benjamin wrote:
> > Why withdraw and add the same route if one of the optional 
> attributes
> > changes from value A to value B.
> 
> If you're just changing an attribute, the withdrawal is implicit
> rather than explicit.  You wouldn't want to explicitly withdraw
> a route if you just want to change the attributes because that
> has consequences for route damping and also for the MRAI and 
> MAOI timers.
> 
> 3.1a covers the explicit withdrawal
> 3.1b covers an implicit withdrawal
> 
> -- 
> 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 QAA20050 for <[e-mail]>; Wed, 25 Sep 2002 16:36:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8FD5F912C1; Wed, 25 Sep 2002 16:35:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D31E912C3; Wed, 25 Sep 2002 16:35:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5992F912C1 for <[e-mail]>; Wed, 25 Sep 2002 16:35:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 47DA85DE8E; Wed, 25 Sep 2002 16:35:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id E35FB5DE8C for <[e-mail]>; Wed, 25 Sep 2002 16:35:32 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8PKYeX36232; Wed, 25 Sep 2002 16:34:40 -0400 (EDT) (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 g8PKYZG36221; Wed, 25 Sep 2002 16:34:35 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8PKYZw19378; Wed, 25 Sep 2002 16:34:35 -0400 (EDT)
Date: Wed, 25 Sep 2002 16:34:35 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: Re: issue 24
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 Wed, Sep 25, 2002 at 04:28:07PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Ben,

On Wed, Sep 25, 2002 at 04:28:07PM -0400, Abarbanel, Benjamin wrote:
> Why withdraw and add the same route if one of the optional attributes
> changes from value A to value B.

If you're just changing an attribute, the withdrawal is implicit
rather than explicit.  You wouldn't want to explicitly withdraw
a route if you just want to change the attributes because that
has consequences for route damping and also for the MRAI and MAOI timers.

3.1a covers the explicit withdrawal
3.1b covers an implicit withdrawal

-- 
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 QAA19759 for <[e-mail]>; Wed, 25 Sep 2002 16:28:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6AE39912BC; Wed, 25 Sep 2002 16:28:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E805912C1; Wed, 25 Sep 2002 16:28:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B2A8912BC for <[e-mail]>; Wed, 25 Sep 2002 16:28:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4695E5DE90; Wed, 25 Sep 2002 16:28:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id C7E665DE46 for <[e-mail]>; Wed, 25 Sep 2002 16:28:10 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA21929; Wed, 25 Sep 2002 16:28:08 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA11020; Wed, 25 Sep 2002 16:28:09 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R72AKF>; Wed, 25 Sep 2002 16:28:08 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 24
Date: Wed, 25 Sep 2002 16:28:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov,

> 
> By *definition* a route is a <path attribute, NLRI> pair. From that
> definition it follows that changing one or more path attributes of
> a route means changing a route, which means withdrawing the old
> route (route with the old attributes) from service and advertising
> a new route (route with the new attributes). Procedures for doing
> this are well-defined (see section 3.1), and therefore no new text
> to cover this is needed.
> 

Why withdraw and add the same route if one of the optional attributes
changes from value A to value B. In other words why take down the route if
some minor attribute changes its value. I contend that not all attributes
are equal in 
their impact to the route and could be added/modified/deleted with different
behavioral characteristics.

In secton 3.1 the text is vague aboute attribute changes.

I think a description of an attribute change impact to the overall route
will 
go a long way.

I still disagree.

Sorry,
Ben



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA19625 for <[e-mail]>; Wed, 25 Sep 2002 16:25:01 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A8762912BB; Wed, 25 Sep 2002 16:24:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73AC7912BC; Wed, 25 Sep 2002 16:24:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2AE90912BB for <[e-mail]>; Wed, 25 Sep 2002 16:24:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 08FA75DE8B; Wed, 25 Sep 2002 16:24:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 971C65DE46 for <[e-mail]>; Wed, 25 Sep 2002 16:24:31 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HQYS>; Wed, 25 Sep 2002 16:24:31 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 24
Date: Wed, 25 Sep 2002 16:24:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

agreed

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 4:09 PM
To: [e-mail]
Subject: issue 24

  24) Addition or Deletion of Path Attributes
 
----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: There are two views here.  One argues that the mechanism for
   adding and deleting path attributes should be explicitly stated in the
   draft.  The other argues that this is tied to the definition of "route"
   and additional specification is unnecessary.
  
  Discussion:
  
  5. P. 20 Its not stated how we delete or modify Path Attributes associated
  with NLRI prefixes.
  
  A response to this comment said that this is implicit in the definition
  of "route" and the general withdraw/replace behavior and therefore doesn't
  need to be repeated.
  
  Ben responded saying that, while there was an assumption, there was
  no well defined mechanism, and this leads to ambiguity.
  
  John reponded, no need to define everything explicity, or we'll be here
  forever.

By *definition* a route is a <path attribute, NLRI> pair. From that
definition it follows that changing one or more path attributes of
a route means changing a route, which means withdrawing the old
route (route with the old attributes) from service and advertising
a new route (route with the new attributes). Procedures for doing
this are well-defined (see section 3.1), and therefore no new text
to cover this is needed.

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 QAA18975 for <[e-mail]>; Wed, 25 Sep 2002 16:09:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5387A912B8; Wed, 25 Sep 2002 16:09:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1EFB9912BB; Wed, 25 Sep 2002 16:09:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E6CED912B8 for <[e-mail]>; Wed, 25 Sep 2002 16:09:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CCF655DE7B; Wed, 25 Sep 2002 16:09:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 7184D5DE46 for <[e-mail]>; Wed, 25 Sep 2002 16:09:27 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PK9Rm69274 for <[e-mail]>; Wed, 25 Sep 2002 13:09:27 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 24
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 13:09:27 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  24) Addition or Deletion of Path Attributes
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: There are two views here.  One argues that the mechanism for
   adding and deleting path attributes should be explicitly stated in the
   draft.  The other argues that this is tied to the definition of "route"
   and additional specification is unnecessary.
  
  Discussion:
  
  5. P. 20 Its not stated how we delete or modify Path Attributes associated
  with NLRI prefixes.
  
  A response to this comment said that this is implicit in the definition
  of "route" and the general withdraw/replace behavior and therefore doesn't
  need to be repeated.
  
  Ben responded saying that, while there was an assumption, there was
  no well defined mechanism, and this leads to ambiguity.
  
  John reponded, no need to define everything explicity, or we'll be here
  forever.

By *definition* a route is a <path attribute, NLRI> pair. From that
definition it follows that changing one or more path attributes of
a route means changing a route, which means withdrawing the old
route (route with the old attributes) from service and advertising
a new route (route with the new attributes). Procedures for doing
this are well-defined (see section 3.1), and therefore no new text
to cover this is needed.

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 PAA17835 for <[e-mail]>; Wed, 25 Sep 2002 15:45:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8E5BA9123D; Wed, 25 Sep 2002 15:44:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 56217912B5; Wed, 25 Sep 2002 15:44:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 06E899123D for <[e-mail]>; Wed, 25 Sep 2002 15:44:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E09375DE83; Wed, 25 Sep 2002 15:44:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id 64D405DE46 for <[e-mail]>; Wed, 25 Sep 2002 15:44:43 -0400 (EDT)
Received: from fid4.com (mcambria3.avayactc.com [199.93.238.136]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g8PJgNlJ006609 for <[e-mail]>; Wed, 25 Sep 2002 15:42:23 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 15:27:18 -0400
From: "Michael C. Cambria" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020819
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: issue 10
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Jeffrey Haas wrote:
> On Wed, Sep 25, 2002 at 03:06:17PM -0400, Michael C. Cambria wrote:
> 
>>I thought the total AS_PATH attribute length could be just 1 octet? 
> 
> 
> Total path attr length is 2 octets.

Understood.

> A given path attribute may have a size of one or two octets depending on the
> flags.

Assume a one octet flag for the AS_PATH attribute.

> Maximum aspath SEGMENT size is one octet.

This would be less than the one octet size of the remaining AS_PATH 
attribute (i.e. segment type and segment length take 2 of the 255 bytes, 
leaving only 253.)

> You can have more than one segment.

Understood.

But can you have more than one AS_PATH attribute?  My understanding is 
no, only one AS_PATH attribute per UPDATE.  Thus, if this attribute has 
an "unextended", one octet length, the fact that the UPDATE can be 4K is 
a different problem.

If more than one AS_PATH attribute is allowed per UPDATE, I 
mis-understood, withdraw the question, but do point out that this wasn't 
clear in the draft :-)

Thanks,
MikeC




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA17274 for <[e-mail]>; Wed, 25 Sep 2002 15:33:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B51A691217; Wed, 25 Sep 2002 15:32:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B15F9123D; Wed, 25 Sep 2002 15:32:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF8EB91217 for <[e-mail]>; Wed, 25 Sep 2002 15:32:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D57945DE46; Wed, 25 Sep 2002 15:32:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 40D825DE6E for <[e-mail]>; Wed, 25 Sep 2002 15:32:08 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PJVwm66672; Wed, 25 Sep 2002 12:31:58 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Michael C. Cambria" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 10 
In-Reply-To: Your message of "Wed, 25 Sep 2002 15:06:17 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 12:31:58 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Mike,

> Yakov Rekhter wrote:
> >   10) Extending AS_PATH Attribute
> >   -------------------------------------------------------------------------
> >   Status: No Consensus
> >   Change: Potentially
> >   Summary: Specific text required to delimit behavior when AS_PATH length
> >    is exceeded.
> >   
> >   Discussion:
> >   
> >   The "Extending AS_PATH attribute length en route" thread brought up
> >   the issue of what action should we specify when we receive a route
> >   with an AS_PATH that exceeds the defined maximum length.  There was
> >   some discussion, and it was suggested that, after logging the error,
> >   the route not be propegated.  No text was proposed.  This issue needs
> >   consensus:  Do we specify the behavior?  If so what with what text?
> > 
> > The real issue here is how to handle the case when a route
> > (a single address prefix + path attributes) doesn't fit into
> > 4K bytes (as the max BGP message size is 4 K). To address
> > this issue I would suggest to add the following to 9.2:
> > 
> >    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 speaker may choose not to advertise the route to its
> >    peers.  Other alternatives of handling this situation are outside
> >    the scope of this document.
> 
> Perhaps I'm missing something.
> 
> I thought the total AS_PATH attribute length could be just 1 octet? 

Or it could be 2 octets - it depends on the length of the attribute.

> Thus, in the case of extended length = 0, the sequence of path segments 
> had to fit in 255 octets, the total length of the path attribute, less 
> type & length fields of each path segment.

and if it doesn't fit then you need to use extended length.

> On a related note, "i.e. more than 255 elements" on page 22 should be 
> removed, or changed to e.g. as extended length can contain more than 255 
> elements (where element means octets?  2-octet AS field?)

While the extended length can contain the value field that carries
more than 255 AS numbers, the path segment lenght field is just *1*
octet, and thus can not contain more than 255 elements. So, the text
is correct.

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 PAA17067 for <[e-mail]>; Wed, 25 Sep 2002 15:28:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id ED79B912D4; Wed, 25 Sep 2002 15:28:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8B6A912D5; Wed, 25 Sep 2002 15:28:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A9014912D4 for <[e-mail]>; Wed, 25 Sep 2002 15:28:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 98CE25DE7F; Wed, 25 Sep 2002 15:28:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id DEACA5DE6E for <[e-mail]>; Wed, 25 Sep 2002 15:28:25 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8PJSJP34321; Wed, 25 Sep 2002 15:28:19 -0400 (EDT) (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 g8PJSFG34307; Wed, 25 Sep 2002 15:28:15 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8PJSEu18234; Wed, 25 Sep 2002 15:28:14 -0400 (EDT)
Date: Wed, 25 Sep 2002 15:28:14 -0400
From: Jeffrey Haas <[e-mail]>
To: "Michael C. Cambria" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 10
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 Wed, Sep 25, 2002 at 03:06:17PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 25, 2002 at 03:06:17PM -0400, Michael C. Cambria wrote:
> I thought the total AS_PATH attribute length could be just 1 octet? 

Total path attr length is 2 octets.
A given path attribute may have a size of one or two octets depending on the
flags.
Maximum aspath SEGMENT size is one octet.
You can have more than one segment.

Segments don't NEED to be optimally packed - the same information
is conveyed if they aren't.
So, if I have an AS_PATH of 1 2 3 4 5, I can have 5 segments if I
wanted to.  It'd just be inefficient.

> On a related note, "i.e. more than 255 elements" on page 22 should be 
> removed, or changed to e.g. as extended length can contain more than 255 
> elements (where element means octets?  2-octet AS field?)

This refers to the fact that when a given segment needs to overflow,
the proper behavior is create a new segment.

> MikeC

-- 
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 PAA17041 for <[e-mail]>; Wed, 25 Sep 2002 15:28:15 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CA444912D3; Wed, 25 Sep 2002 15:27:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9187A912D4; Wed, 25 Sep 2002 15:27:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 556B3912D3 for <[e-mail]>; Wed, 25 Sep 2002 15:27:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 918085DE7F; Wed, 25 Sep 2002 15:27:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 529485DE6E for <[e-mail]>; Wed, 25 Sep 2002 15:27:42 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HQQY>; Wed, 25 Sep 2002 15:27:42 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Mathew Richardson'" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 32.1
Date: Wed, 25 Sep 2002 15:27:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Aaaahhhh....

Ok, I agree to that.

Thnx!


-----Original Message-----
From: Mathew Richardson [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 3:24 PM
To: Natale, Jonathan
Cc: 'Yakov Rekhter'; [e-mail]
Subject: Re: issue 32.1

> Natale, Jonathan <[e-mail]> [Wed, Sep 25, 2002 at
03:19:21PM -0400]:
>1) this is a required attribute, "shall" is too weak if anything.  I must
>have missed something here.

<snip>

I suspect they're referring to the shall not:

>> >      associated routing information. Its value shall not be
>> >      changed by any other speaker unless the other speaker is

<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 PAA17000 for <[e-mail]>; Wed, 25 Sep 2002 15:27:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9E615912D1; Wed, 25 Sep 2002 15:27:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 638DB912D3; Wed, 25 Sep 2002 15:27:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A631912D1 for <[e-mail]>; Wed, 25 Sep 2002 15:27:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 658205DE7E; Wed, 25 Sep 2002 15:27:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id E13445DE6E for <[e-mail]>; Wed, 25 Sep 2002 15:27:00 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17829; Wed, 25 Sep 2002 15:26:58 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA27918; Wed, 25 Sep 2002 15:27:00 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7H7S6>; Wed, 25 Sep 2002 15:26:59 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: RE: issue 10
Date: Wed, 25 Sep 2002 15:26:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Jeff:

 
> 
> If we're at a point where we need to modify a BGP PDU to do some
> sort of mandatory behavior (add an AS to the PATH, append to a
> cluster-list, etc.) and we are at an overflow situation, we may
> have two options:
> 
> 1. Is there something that isn't mandatory that we *might* be able to
>    discard?  If so, thats a value judgement.  Encoding that value
>    judgement in an implementation may be tricky and possibly not
>    worth doing.

I implied only mandatory things. All other attributes can be eliminated if
the implemenatation feels it will not detract from the routes behavior.

> 2. If we can't append, we should not propagate the PDU.
>

agree.

Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA16912 for <[e-mail]>; Wed, 25 Sep 2002 15:25:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BE385912D2; Wed, 25 Sep 2002 15:25:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B91D912D1; Wed, 25 Sep 2002 15:25:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C5F68912D2 for <[e-mail]>; Wed, 25 Sep 2002 15:25:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B49685DE7C; Wed, 25 Sep 2002 15:25:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 240F65DE6E for <[e-mail]>; Wed, 25 Sep 2002 15:25:02 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PJP1m65793; Wed, 25 Sep 2002 12:25:01 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 32.1 
In-Reply-To: Your message of "Wed, 25 Sep 2002 15:19:21 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 12:25:01 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> 1) this is a required attribute, "shall" is too weak if anything.  I must
> have missed something here.

There are two "shall" in the text. Jeff suggested to replace the second
"shall" with "should".

> 2) Also, I think "by the autonomous system that originates"
> should be changed to "by the speaker that originates"

Agreed.

Yakov.
> 
>  
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Wednesday, September 25, 2002 2:52 PM
> To: Jeffrey Haas
> Cc: Natale, Jonathan; [e-mail]
> Subject: Re: issue 32.1 
> 
> Jeff,
> 
> > On Wed, Sep 25, 2002 at 02:35:03PM -0400, Natale, Jonathan wrote:
> > >      ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
> > >      shall be generated by the autonomous system that originates the
> > >      associated routing information. Its value shall not be
> > >      changed by any other speaker unless the other speaker is
> > >      administratively configured to do so to affect policy
> > >      decisions."
> > 
> > "shall" may be a bit strong.
> 
> Agreed. So, how about if we'll use the text suggested by Jonathan,
> but replace "shall" with "should".
> 
> 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 PAA16890 for <[e-mail]>; Wed, 25 Sep 2002 15:25:01 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 89E16912D0; Wed, 25 Sep 2002 15:24:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B572912D1; Wed, 25 Sep 2002 15:24:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D8B2912D0 for <[e-mail]>; Wed, 25 Sep 2002 15:24:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 38D055DE6E; Wed, 25 Sep 2002 15:24:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id A80925DE7C for <[e-mail]>; Wed, 25 Sep 2002 15:24:40 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8PJOc834053; Wed, 25 Sep 2002 15:24:38 -0400 (EDT) (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 g8PJOXG34037; Wed, 25 Sep 2002 15:24:33 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8PJOXJ18211; Wed, 25 Sep 2002 15:24:33 -0400 (EDT)
Date: Wed, 25 Sep 2002 15:24:33 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: Re: issue 32.1
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 Wed, Sep 25, 2002 at 03:19:21PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 25, 2002 at 03:19:21PM -0400, Natale, Jonathan wrote:
> 1) this is a required attribute, "shall" is too weak if anything.  I must
> have missed something here.

As to changing the value of the attribute:
If there was some historic reason that having it set to EGP aside
from biasing route selection (and I don't know the answer to that),
then it may have been important for BGP<->EGP interaction.

In any case, EGP is historic.  Thus, the value is only used to
bias route selection and changing it should be No Big Deal, so
long as its done with the idea in mind that you're using rope
and here's the gallows.

At worst, this allows you to say that a route learned via an IGP
is better than a route learned by static configuration.  This will
generally give you the results you expect.

> 2) Also, I think "by the autonomous system that originates"
> should be changed to "by the speaker that originates"

I agree.

-- 
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 PAA16843 for <[e-mail]>; Wed, 25 Sep 2002 15:24:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7F452912CF; Wed, 25 Sep 2002 15:23:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 463FA912D0; Wed, 25 Sep 2002 15:23:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 194D6912CF for <[e-mail]>; Wed, 25 Sep 2002 15:23:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 42BC75DE7B; Wed, 25 Sep 2002 15:23:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 889D65DE6E for <[e-mail]>; Wed, 25 Sep 2002 15:23:50 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8PJNmB33913; Wed, 25 Sep 2002 15:23:48 -0400 (EDT) (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 g8PJNjG33906; Wed, 25 Sep 2002 15:23:45 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g8PJNjq10017; Wed, 25 Sep 2002 15:23:45 -0400 (EDT)
Date: Wed, 25 Sep 2002 15:23:45 -0400
From: Mathew Richardson <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: Re: issue 32.1
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

> Natale, Jonathan <[e-mail]> [Wed, Sep 25, 2002 at 03:19:21PM -0400]:
>1) this is a required attribute, "shall" is too weak if anything.  I must
>have missed something here.

<snip>

I suspect they're referring to the shall not:

>> >      associated routing information. Its value shall not be
>> >      changed by any other speaker unless the other speaker is

<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 PAA16821 for <[e-mail]>; Wed, 25 Sep 2002 15:24:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 015D2912CE; Wed, 25 Sep 2002 15:23:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2935912CF; Wed, 25 Sep 2002 15:23:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 77F09912CE for <[e-mail]>; Wed, 25 Sep 2002 15:23:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 676CD5DE6E; Wed, 25 Sep 2002 15:23:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id E25A05DE7C for <[e-mail]>; Wed, 25 Sep 2002 15:23:45 -0400 (EDT)
Received: from fid4.com (mcambria3.avayactc.com [199.93.238.136]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g8PJLMlJ006548 for <[e-mail]>; Wed, 25 Sep 2002 15:21:26 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 15:06:17 -0400
From: "Michael C. Cambria" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020819
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: issue 10
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Yakov Rekhter wrote:
>   10) Extending AS_PATH Attribute
>   ----------------------------------------------------------------------------
>   Status: No Consensus
>   Change: Potentially
>   Summary: Specific text required to delimit behavior when AS_PATH length
>    is exceeded.
>   
>   Discussion:
>   
>   The "Extending AS_PATH attribute length en route" thread brought up
>   the issue of what action should we specify when we receive a route
>   with an AS_PATH that exceeds the defined maximum length.  There was
>   some discussion, and it was suggested that, after logging the error,
>   the route not be propegated.  No text was proposed.  This issue needs
>   consensus:  Do we specify the behavior?  If so what with what text?
> 
> The real issue here is how to handle the case when a route
> (a single address prefix + path attributes) doesn't fit into
> 4K bytes (as the max BGP message size is 4 K). To address
> this issue I would suggest to add the following to 9.2:
> 
>    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 speaker may choose not to advertise the route to its
>    peers.  Other alternatives of handling this situation are outside
>    the scope of this document.

Perhaps I'm missing something.

I thought the total AS_PATH attribute length could be just 1 octet? 
Thus, in the case of extended length = 0, the sequence of path segments 
had to fit in 255 octets, the total length of the path attribute, less 
type & length fields of each path segment.

On a related note, "i.e. more than 255 elements" on page 22 should be 
removed, or changed to e.g. as extended length can contain more than 255 
elements (where element means octets?  2-octet AS field?)

MikeC



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA16763 for <[e-mail]>; Wed, 25 Sep 2002 15:22:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 55D11912C9; Wed, 25 Sep 2002 15:22:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2534A912CE; Wed, 25 Sep 2002 15:22:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7FC41912C9 for <[e-mail]>; Wed, 25 Sep 2002 15:22:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 699A95DE7B; Wed, 25 Sep 2002 15:22:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id CDE245DE6E for <[e-mail]>; Wed, 25 Sep 2002 15:22:21 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PJMKm65594; Wed, 25 Sep 2002 12:22:20 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 32.1 
In-Reply-To: Your message of "Wed, 25 Sep 2002 14:28:03 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 12:22:20 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> 1) It is wrong because Network Layer Reachability Information is ALWAYS
> interior to the originating AS.  

Not really, as ASs can exchange their NLRI in a variety of ways other
than BGP (or for than matter EGP[RFC904]). So, NLRI that is injected
into BGP could easily be external to the AS that originates this injection.

> What would be the "other means"???  

Anything other than IGP or EGP[RFC904].

> Anyway, this is certainly not the current use.
> 
> 2) "network cmd" nor "redistribute" is mentioned in the proposed change
> 
> 3) 32.1 is not significantly related to 32.2

I certainly agree with you on that.

> 4) I have personally witnessed many people confusing EGP with EBGP.

We can't change the term "the EGP", as it refers to the protocol defined
in [RFC904]. Neither can we change the term "EBGP".

> I stand by my proposal (which was supported by at least one other as I
> recall):

As I mentioned to you in my previous e-mail, your proposal introduces
two terms "implicitly introduced into BGP" and "explicitly introduced 
into BGP" that aren't really well-defined.

Yakov.

> 
> Old:
> 
>             "ORIGIN is a well-known mandatory attribute that defines the
>             origin of the path information.  The data octet can assume
>             the following values:
> 
>                   Value		Meaning
> 
>                   0	    IGP - Network Layer Reachability Information
>                                is interior to the originating AS
> 
>                   1	    EGP - Network Layer Reachability Information
>                                learned via the EGP protocol
> 
>                   2	    INCOMPLETE - Network Layer Reachability
>                                Information learned by some other means"
> New:
> 
>             "ORIGIN is a well-known mandatory attribute that defines the
>             origin of the path information.  The data octet can assume
>             the following values:
> 
>                   Value		Meaning
> 
>                   0	    IGP - NLRI was explicitly introduced into bgp
> 
>                   1	    EGP - this value was administratively
>                                configured to affect policy decisions or
>                                NLRI was learned via the EGP protocol [1]
> 
>                   2	    INCOMPLETE - NLRI was implicitly introduced
>                                       into bgp"
> ...
> "[1] RFC904
> since:
> 1) The network command sets the origin to IGP and I remember seeing
> somewhere that only static routes should be set to IGP.
> 2) The primary use of EGP value is policy
> 3) EGP seems to still exist, anyway even if it does not it is
> not worth re-writing the world.
> 
> Also, change:
> "5.1.1 ORIGIN
> 
> 
>    ORIGIN is a well-known mandatory attribute.	The ORIGIN attribute
>    shall be generated by the autonomous system that originates the
>    associated routing information. It shall be included in the UPDATE
>    messages of all BGP speakers that choose to propagate this
>    information to other BGP speakers."
> 
> to:
> "5.1.1 ORIGIN
> 
>    The value of the ORIGIN attribute shall be set by the speaker
>    that originates the associated NLRI.	 Its value shall not be
>    changed by any other speaker unless the other speaker is
>    administratively configured to do so to affect policy
>    decisions."
> 
> since:
> 1) It is already defined as well-known mandatory attribute.
> 2) It may be set differently within the same AS (not saying this is good).
> 3) It is commonly used for policy, but by default does not get changed.
> 4) Speakers have no choice, it is mandatory.
> 
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Wednesday, September 25, 2002 1:43 PM
> To: [e-mail]
> Subject: issue 32
> 
>   32) Clarify EGP Reference
>  
> ----------------------------------------------------------------------------
>   Status: No Consensus
>   Change: Potentially
>   Summary: Need to clarify the EGP Reference, since there seems to be some
>     confusion on the issue.
>   
>   Discussion:
>   
>   3. P. 13, EGP, are there other EGP protocols other than BGP that are in
> use?
>   If not, change EGP to BGP.
>   
>   A response to this suggested that we add a reference to [1] (the EGP
>   spec) here.
> 
> This will be address as part of the response to issue 9
>   
>   Another reponse clarified that this refers to EGP-the-protocol and
>   NOT the class.
>   
>   Another response disagreed, but suggested that:
>   
>   IGP = network was explicitly introduced into bgp (network cmd)
>   INCOMPLETE = network was implicitly introduced into bgp (redistribute)
>   EGP = other
> 
> I've yet to understand what is incorrect with the current text.
> I also think that talking about "network cmd" and "redistribute"
> makes it a bit vendor specific. Therefore, I think we should keep
> the current text.
>   
>   The original commentor thought that this refered to EGP-the-class of
>   protocols.   And why not use BGP therefore, as the only EGP.
>   
>   There was some disucssion over whether or not we should mention something
>   that is historical.
> 
> I don't think that the BGP base spec needs to talk about the status
> of EGP spec [RFC904].
>   
>   Jeff suggested a footnote in the Origin section about EGP.
>   
>   Curtis suggested that we state that the EGP in ORIGIN is depricated,
>   but retain the value to document what it used to mean.
>   
>   This reviewer thinks a statement about whether this "EGP" origin refers
>   to the protocol or the class or protocols would be useful.
> 
> >From the context it should be clear that we are talking about "the EGP"
> (means [RFC904]).
> 
> 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 PAA16739 for <[e-mail]>; Wed, 25 Sep 2002 15:22:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 85F74912BC; Wed, 25 Sep 2002 15:21:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F846912C9; Wed, 25 Sep 2002 15:21:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 47D68912BC for <[e-mail]>; Wed, 25 Sep 2002 15:21:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 369225DE7B; Wed, 25 Sep 2002 15:21:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id AB4F15DE6E for <[e-mail]>; Wed, 25 Sep 2002 15:21:42 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8PJLYC33819; Wed, 25 Sep 2002 15:21:34 -0400 (EDT) (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 g8PJLVG33812; Wed, 25 Sep 2002 15:21:31 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8PJLVm18201; Wed, 25 Sep 2002 15:21:31 -0400 (EDT)
Date: Wed, 25 Sep 2002 15:21:31 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: issue 10
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 Wed, Sep 25, 2002 at 03:10:32PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Ben,

On Wed, Sep 25, 2002 at 03:10:32PM -0400, Abarbanel, Benjamin wrote:
> AS_PATH attribute is a well known mandatory attribute. All vendors that
> support the standard RFC1771 BGP protocol must have this attribute in the
> payload of the UPDATE message. Your point is not valid.

I may be discussing the wrong issue in context of this particular
thread.  Let me tackle the one I was trying to bring up first.

Lets say an implementation can't support an AS_PATH with more than
256 AS's.  Since it can't support it, it MUST NOT propagate that
route if it cannot add on the 257th AS to the AS_PATH.

This is a case where some mandatory behavior causes an overflow
situation - in this case it happens to be an implementation overflow
rather than getting to the point where we're going to overflow the 
BGP PDU.

You acknowledge this situation to some extent later:

> My suggestion, is if one prefix with all its mandatory attributes cannot be

note mandatory.
[intentionally skipping the rest since its out of scope for what I
was trying to bring up]

If we're at a point where we need to modify a BGP PDU to do some
sort of mandatory behavior (add an AS to the PATH, append to a
cluster-list, etc.) and we are at an overflow situation, we may
have two options:

1. Is there something that isn't mandatory that we *might* be able to
   discard?  If so, thats a value judgement.  Encoding that value
   judgement in an implementation may be tricky and possibly not
   worth doing.
2. If we can't append, we should not propagate the PDU.

-- 
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 PAA16583 for <[e-mail]>; Wed, 25 Sep 2002 15:19:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8FD09912BB; Wed, 25 Sep 2002 15:19:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D5DA912BC; Wed, 25 Sep 2002 15:19:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 28D54912BB for <[e-mail]>; Wed, 25 Sep 2002 15:19:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 183875DE7B; Wed, 25 Sep 2002 15:19:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id D0F135DE6E for <[e-mail]>; Wed, 25 Sep 2002 15:19:22 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HQPC>; Wed, 25 Sep 2002 15:19:22 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 32.1 
Date: Wed, 25 Sep 2002 15:19:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

1) this is a required attribute, "shall" is too weak if anything.  I must
have missed something here.

2) Also, I think "by the autonomous system that originates"
should be changed to "by the speaker that originates"

 
-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 2:52 PM
To: Jeffrey Haas
Cc: Natale, Jonathan; [e-mail]
Subject: Re: issue 32.1 

Jeff,

> On Wed, Sep 25, 2002 at 02:35:03PM -0400, Natale, Jonathan wrote:
> >      ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
> >      shall be generated by the autonomous system that originates the
> >      associated routing information. Its value shall not be
> >      changed by any other speaker unless the other speaker is
> >      administratively configured to do so to affect policy
> >      decisions."
> 
> "shall" may be a bit strong.

Agreed. So, how about if we'll use the text suggested by Jonathan,
but replace "shall" with "should".

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 PAA16222 for <[e-mail]>; Wed, 25 Sep 2002 15:11:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0C402912B8; Wed, 25 Sep 2002 15:10:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5D9D912BC; Wed, 25 Sep 2002 15:10:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CE388912B8 for <[e-mail]>; Wed, 25 Sep 2002 15:10:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B1B705DE7B; Wed, 25 Sep 2002 15:10:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 30B125DE6E for <[e-mail]>; Wed, 25 Sep 2002 15:10:37 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA16667; Wed, 25 Sep 2002 15:10:34 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA23778; Wed, 25 Sep 2002 15:10:35 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7H62X>; Wed, 25 Sep 2002 15:10:34 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 10
Date: Wed, 25 Sep 2002 15:10:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Jeff:

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 2:54 PM
> To: Yakov Rekhter
> Cc: [e-mail]
> Subject: Re: issue 10
> 
> 
> Yakov,
> 
> On Wed, Sep 25, 2002 at 11:46:45AM -0700, Yakov Rekhter wrote:
> > The real issue here is how to handle the case when a route
> > (a single address prefix + path attributes) doesn't fit into
> > 4K bytes (as the max BGP message size is 4 K). To address
> > this issue I would suggest to add the following to 9.2:
> 
> If I might suggest that although this is the most "valid" 
> (for some value judgement of "valid") case for this problem,
> implementations may choose for whatever reason to deal with
> attribute overflows differently.  For example, if a certain vendor
> didn't want to support AS_PATHS over 256 AS's, that's their
> prerogative.
> 
AS_PATH attribute is a well known mandatory attribute. All vendors that
support the standard RFC1771 BGP protocol must have this attribute in the
payload of the UPDATE message. Your point is not valid.

> Thus, we might want to just say something about "If you can't
> send an update that properly contains all required information,
> do not send the update".  I apologize for not having the proper
> wording for it, but this also covers the case where a packet
> is almost full and you can discard communities (for example)
> to make AS_PATH fit.
> 
My suggestion, is if one prefix with all its mandatory attributes cannot be
sent in a 4K block message. Our network has expanded beyond its original
conception and we need a fast extention to the BGP protocol. 

On the other hand, if we have some abnormal network configuration that cause
this problem or the UPDATE packet is malformed than the proper error 
processing should be done as I mentioned earlier.

Ben
> > 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 PAA16125 for <[e-mail]>; Wed, 25 Sep 2002 15:09:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0294D91235; Wed, 25 Sep 2002 15:08:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2929912B8; Wed, 25 Sep 2002 15:08:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 93D4091235 for <[e-mail]>; Wed, 25 Sep 2002 15:08:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 740085DE7B; Wed, 25 Sep 2002 15:08:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 18E6B5DE75 for <[e-mail]>; Wed, 25 Sep 2002 15:08:41 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PJ8dm64299; Wed, 25 Sep 2002 12:08:39 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 10 
In-Reply-To: Your message of "Wed, 25 Sep 2002 14:54:20 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 12:08:39 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> On Wed, Sep 25, 2002 at 11:46:45AM -0700, Yakov Rekhter wrote:
> > The real issue here is how to handle the case when a route
> > (a single address prefix + path attributes) doesn't fit into
> > 4K bytes (as the max BGP message size is 4 K). To address
> > this issue I would suggest to add the following to 9.2:
> 
> If I might suggest that although this is the most "valid" 
> (for some value judgement of "valid") case for this problem,
> implementations may choose for whatever reason to deal with
> attribute overflows differently.  For example, if a certain vendor
> didn't want to support AS_PATHS over 256 AS's, that's their
> prerogative.
> 
> Thus, we might want to just say something about "If you can't
> send an update that properly contains all required information,
> do not send the update".  I apologize for not having the proper
> wording for it, but this also covers the case where a packet
> is almost full and you can discard communities (for example)
> to make AS_PATH fit.

Please propose the proper wording...

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 PAA15743 for <[e-mail]>; Wed, 25 Sep 2002 15:02:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E860791217; Wed, 25 Sep 2002 15:01:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC23E91235; Wed, 25 Sep 2002 15:01:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B21FB91217 for <[e-mail]>; Wed, 25 Sep 2002 15:01:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A11605DE75; Wed, 25 Sep 2002 15:01:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 085505DE6E for <[e-mail]>; Wed, 25 Sep 2002 15:01:47 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA16109; Wed, 25 Sep 2002 15:01:44 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA21848; Wed, 25 Sep 2002 15:01:46 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7H5V6>; Wed, 25 Sep 2002 15:01:45 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 10
Date: Wed, 25 Sep 2002 15:01:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Comment below

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 2:47 PM
> To: [e-mail]
> Subject: issue 10
> 
> 
>   10) Extending AS_PATH Attribute
>   
> --------------------------------------------------------------
> --------------
>   Status: No Consensus
>   Change: Potentially
>   Summary: Specific text required to delimit behavior when 
> AS_PATH length
>    is exceeded.
>   
>   Discussion:
>   
>   The "Extending AS_PATH attribute length en route" thread brought up
>   the issue of what action should we specify when we receive a route
>   with an AS_PATH that exceeds the defined maximum length.  There was
>   some discussion, and it was suggested that, after logging the error,
>   the route not be propegated.  No text was proposed.  This 
> issue needs
>   consensus:  Do we specify the behavior?  If so what with what text?
> 
> The real issue here is how to handle the case when a route
> (a single address prefix + path attributes) doesn't fit into
> 4K bytes (as the max BGP message size is 4 K). To address
> this issue I would suggest to add the following to 9.2:
> 
>    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 speaker may choose not to advertise the route to its
>    peers.  Other alternatives of handling this situation are outside
>    the scope of this document.
> 

I think to leave this wide open is a mistake. If the AS-PATH field makes
the "single" route UPDATE message too long (> 4k bytes). Its no different
than having an IP packet expire (decrement to zero) the TTL field.
Therefore,
we should consider the packet invalid and take whatever course of action
is appropriate for a route that cannot be transported in the given BGP
protocol. There is no need to say that "Other alternatives of handling this
situation are outside the scope of this document".

In summary, I vote to delete the last line starting with "Other alternatives
..."


Ben

> 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 OAA15584 for <[e-mail]>; Wed, 25 Sep 2002 14:59:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5F690912BB; Wed, 25 Sep 2002 14:59:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26961912C9; Wed, 25 Sep 2002 14:59:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 22CE5912BB for <[e-mail]>; Wed, 25 Sep 2002 14:59:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 12A405DE75; Wed, 25 Sep 2002 14:59:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 5934D5DE6E for <[e-mail]>; Wed, 25 Sep 2002 14:58:59 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8PIwvC33007; Wed, 25 Sep 2002 14:58:57 -0400 (EDT) (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 g8PIwsG32999; Wed, 25 Sep 2002 14:58:54 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8PIwso18020; Wed, 25 Sep 2002 14:58:54 -0400 (EDT)
Date: Wed, 25 Sep 2002 14:58:54 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: Re: issue 32.1
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 Wed, Sep 25, 2002 at 11:52:01AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 25, 2002 at 11:52:01AM -0700, Yakov Rekhter wrote:
> Agreed. So, how about if we'll use the text suggested by Jonathan,
> but replace "shall" with "should".

I'd be happy with that, but what about the other part of my post?

> 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 OAA15390 for <[e-mail]>; Wed, 25 Sep 2002 14:54:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8F346912B8; Wed, 25 Sep 2002 14:54:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 56A31912BB; Wed, 25 Sep 2002 14:54:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 46AE5912B8 for <[e-mail]>; Wed, 25 Sep 2002 14:54:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 428905DE75; Wed, 25 Sep 2002 14:54:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 9EE955DE6E for <[e-mail]>; Wed, 25 Sep 2002 14:54:25 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8PIsNI32811; Wed, 25 Sep 2002 14:54:23 -0400 (EDT) (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 g8PIsKG32804; Wed, 25 Sep 2002 14:54:20 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8PIsKM17995; Wed, 25 Sep 2002 14:54:20 -0400 (EDT)
Date: Wed, 25 Sep 2002 14:54:20 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 10
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 Wed, Sep 25, 2002 at 11:46:45AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Wed, Sep 25, 2002 at 11:46:45AM -0700, Yakov Rekhter wrote:
> The real issue here is how to handle the case when a route
> (a single address prefix + path attributes) doesn't fit into
> 4K bytes (as the max BGP message size is 4 K). To address
> this issue I would suggest to add the following to 9.2:

If I might suggest that although this is the most "valid" 
(for some value judgement of "valid") case for this problem,
implementations may choose for whatever reason to deal with
attribute overflows differently.  For example, if a certain vendor
didn't want to support AS_PATHS over 256 AS's, that's their
prerogative.

Thus, we might want to just say something about "If you can't
send an update that properly contains all required information,
do not send the update".  I apologize for not having the proper
wording for it, but this also covers the case where a packet
is almost full and you can discard communities (for example)
to make AS_PATH fit.

> 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 OAA15320 for <[e-mail]>; Wed, 25 Sep 2002 14:53:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3BB27912B5; Wed, 25 Sep 2002 14:52:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 07305912B8; Wed, 25 Sep 2002 14:52:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DD2CA912B5 for <[e-mail]>; Wed, 25 Sep 2002 14:52:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C9CFC5DE75; Wed, 25 Sep 2002 14:52:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 3B7565DE6E for <[e-mail]>; Wed, 25 Sep 2002 14:52:44 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PIq1m62518; Wed, 25 Sep 2002 11:52:21 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: Re: issue 32.1 
In-Reply-To: Your message of "Wed, 25 Sep 2002 14:43:56 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 11:52:01 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> On Wed, Sep 25, 2002 at 02:35:03PM -0400, Natale, Jonathan wrote:
> >      ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
> >      shall be generated by the autonomous system that originates the
> >      associated routing information. Its value shall not be
> >      changed by any other speaker unless the other speaker is
> >      administratively configured to do so to affect policy
> >      decisions."
> 
> "shall" may be a bit strong.

Agreed. So, how about if we'll use the text suggested by Jonathan,
but replace "shall" with "should".

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 OAA15002 for <[e-mail]>; Wed, 25 Sep 2002 14:47:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BD78D912AD; Wed, 25 Sep 2002 14:46:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E7D6D912B3; Wed, 25 Sep 2002 14:46:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 730D6912AD for <[e-mail]>; Wed, 25 Sep 2002 14:46:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5682D5DE6E; Wed, 25 Sep 2002 14:46:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id EF0405DE74 for <[e-mail]>; Wed, 25 Sep 2002 14:46:45 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PIkjm62151 for <[e-mail]>; Wed, 25 Sep 2002 11:46:45 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 10
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 11:46:45 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  10) Extending AS_PATH Attribute
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Specific text required to delimit behavior when AS_PATH length
   is exceeded.
  
  Discussion:
  
  The "Extending AS_PATH attribute length en route" thread brought up
  the issue of what action should we specify when we receive a route
  with an AS_PATH that exceeds the defined maximum length.  There was
  some discussion, and it was suggested that, after logging the error,
  the route not be propegated.  No text was proposed.  This issue needs
  consensus:  Do we specify the behavior?  If so what with what text?

The real issue here is how to handle the case when a route
(a single address prefix + path attributes) doesn't fit into
4K bytes (as the max BGP message size is 4 K). To address
this issue I would suggest to add the following to 9.2:

   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 speaker may choose not to advertise the route to its
   peers.  Other alternatives of handling this situation are outside
   the scope of this 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 OAA14883 for <[e-mail]>; Wed, 25 Sep 2002 14:44:30 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8B5ED9123D; Wed, 25 Sep 2002 14:44:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B3CB912A7; Wed, 25 Sep 2002 14:44:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 48ED79123D for <[e-mail]>; Wed, 25 Sep 2002 14:44:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 27BCB5DE74; Wed, 25 Sep 2002 14:44:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 9D9385DE6E for <[e-mail]>; Wed, 25 Sep 2002 14:44:01 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8PIhxo32395; Wed, 25 Sep 2002 14:43:59 -0400 (EDT) (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 g8PIhuG32388; Wed, 25 Sep 2002 14:43:56 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8PIhuf17943; Wed, 25 Sep 2002 14:43:56 -0400 (EDT)
Date: Wed, 25 Sep 2002 14:43:56 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: Re: issue 32.1
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 Wed, Sep 25, 2002 at 02:35:03PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 25, 2002 at 02:35:03PM -0400, Natale, Jonathan wrote:
>      ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
>      shall be generated by the autonomous system that originates the
>      associated routing information. Its value shall not be
>      changed by any other speaker unless the other speaker is
>      administratively configured to do so to affect policy
>      decisions."

"shall" may be a bit strong.

A quick question to those who have "been there, done that".
The primary purpose of ORIGIN seems to have been to bias routing
towards routes that actually came from IGP's as opposed to some
other means.  

Was there any other usage of the ORIGIN in interactions with EGP?

If not, we probably should explicitly mention its purpose in
biasing route selection.

-- 
Jeff Haas 
NextHop Technologies


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 OAA14491 for <[e-mail]>; Wed, 25 Sep 2002 14:35:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3C7FE91217; Wed, 25 Sep 2002 14:34:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0236691235; Wed, 25 Sep 2002 14:34:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E206F91217 for <[e-mail]>; Wed, 25 Sep 2002 14:34:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CCBBB5DE74; Wed, 25 Sep 2002 14:34:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 1F0F15DE6E for <[e-mail]>; Wed, 25 Sep 2002 14:34:46 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8PIYir32036; Wed, 25 Sep 2002 14:34:44 -0400 (EDT) (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 g8PIYfG32029; Wed, 25 Sep 2002 14:34:41 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8PIYfg17860; Wed, 25 Sep 2002 14:34:41 -0400 (EDT)
Date: Wed, 25 Sep 2002 14:34:41 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP Base Draft - Issue List v1.0 2002-09-24
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 Wed, Sep 25, 2002 at 01:31:54PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 25, 2002 at 01:31:54PM -0400, Abarbanel, Benjamin wrote:
>  You did an excellent job in keeping track of all the issues.

Goes double for me.
Track me down at NANOG or IETF.  I owe you your libations of choice.

> Ben

-- 
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 OAA14438 for <[e-mail]>; Wed, 25 Sep 2002 14:35:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 384BE91235; Wed, 25 Sep 2002 14:35:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0134F9123D; Wed, 25 Sep 2002 14:35:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A6D491235 for <[e-mail]>; Wed, 25 Sep 2002 14:35:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 667DD5DE74; Wed, 25 Sep 2002 14:35:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 204D45DE6E for <[e-mail]>; Wed, 25 Sep 2002 14:35:05 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HQJC>; Wed, 25 Sep 2002 14:35:04 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 32.1
Date: Wed, 25 Sep 2002 14:35:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

How about:
"5.1.1 ORIGIN
  
     ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
     shall be generated by the autonomous system that originates the
     associated routing information. Its value shall not be
     changed by any other speaker unless the other speaker is
     administratively configured to do so to affect policy
     decisions."


-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 1:50 PM
To: [e-mail]
Subject: issue 32.1

  32.1) EGP ORIGIN Clarification
 
----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Proposal to update the EGP ORIGIN section.
  
  Discussion:
  
  This discussion is picked up again in the "Review of
draft-ietf-idr-bgp4-17"
  thread, where specific text is proposed:
  
  Old:
  
              "ORIGIN is a well-known mandatory attribute that defines the
              origin of the path information.  The data octet can assume
              the following values:
  
                    Value		Meaning
  
                    0	    IGP - Network Layer Reachability Information
                                 is interior to the originating AS
  
                    1	    EGP - Network Layer Reachability Information
                                 learned via the EGP protocol
  
                    2	    INCOMPLETE - Network Layer Reachability
                                 Information learned by some other means"
  New:
  
              "ORIGIN is a well-known mandatory attribute that defines the
              origin of the path information.  The data octet can assume
              the following values:
  
                    Value		Meaning
  
                    0	    IGP - NLRI was explicitly introduced into bgp
  
                    1	    EGP - this value was administratively
                                 configured to affect policy decisions or
                                 NLRI was learned via the EGP protocol [1]
  
                    2	    INCOMPLETE - NLRI was implicitly introduced
                                        into bgp"
  
  since:
  1) The network command sets the origin to IGP and I remember seeing
  somewhere that only static routes should be set to IGP.
  2) The primary use of EGP value is policy
  3) EGP seems to still exist, anyway even if it does not it is
  not worth re-writing the world.

Since the current text is technically correct, and since the terms
"implicitly introduced" and "explicitly introduced" aren't really
well-defined I think we should just keep the current text.
  
  Also, change:
  "5.1.1 ORIGIN
  
  
     ORIGIN is a well-known mandatory attribute.	The ORIGIN attribute
     shall be generated by the autonomous system that originates the
     associated routing information. It shall be included in the UPDATE
     messages of all BGP speakers that choose to propagate this
     information to other BGP speakers."
  
  to:
  "5.1.1 ORIGIN
  
     The value of the ORIGIN attribute shall be set by the speaker
     that originates the associated NLRI.	 Its value shall not be
     changed by any other speaker unless the other speaker is
     administratively configured to do so to affect policy
     decisions."
  
  since:
  1) It is already defined as well-known mandatory attribute.
  2) It may be set differently within the same AS (not saying this is good).
  3) It is commonly used for policy, but by default does not get changed.
  4) Speakers have no choice, it is mandatory.

Please note that issue 33 asks for exactly the opposite. For the
sake of consistency I suggest we keep 5.1.1 as is.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA14146 for <[e-mail]>; Wed, 25 Sep 2002 14:28:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4011F9123D; Wed, 25 Sep 2002 14:28:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FF72912B3; Wed, 25 Sep 2002 14:28:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A095F9123D for <[e-mail]>; Wed, 25 Sep 2002 14:28:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7729B5DE73; Wed, 25 Sep 2002 14:28:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 2A28A5DE71 for <[e-mail]>; Wed, 25 Sep 2002 14:28:04 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HQ23>; Wed, 25 Sep 2002 14:28:03 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 32.1
Date: Wed, 25 Sep 2002 14:28:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

1) It is wrong because Network Layer Reachability Information is ALWAYS
interior to the originating AS.  What would be the "other means"???  Anyway,
this is certainly not the current use.

2) "network cmd" nor "redistribute" is mentioned in the proposed change

3) 32.1 is not significantly related to 32.2

4) I have personally witnessed many people confusing EGP with EBGP.

I stand by my proposal (which was supported by at least one other as I
recall):

Old:

            "ORIGIN is a well-known mandatory attribute that defines the
            origin of the path information.  The data octet can assume
            the following values:

                  Value		Meaning

                  0	    IGP - Network Layer Reachability Information
                               is interior to the originating AS

                  1	    EGP - Network Layer Reachability Information
                               learned via the EGP protocol

                  2	    INCOMPLETE - Network Layer Reachability
                               Information learned by some other means"
New:

            "ORIGIN is a well-known mandatory attribute that defines the
            origin of the path information.  The data octet can assume
            the following values:

                  Value		Meaning

                  0	    IGP - NLRI was explicitly introduced into bgp

                  1	    EGP - this value was administratively
                               configured to affect policy decisions or
                               NLRI was learned via the EGP protocol [1]

                  2	    INCOMPLETE - NLRI was implicitly introduced
                                      into bgp"
...
"[1] RFC904
since:
1) The network command sets the origin to IGP and I remember seeing
somewhere that only static routes should be set to IGP.
2) The primary use of EGP value is policy
3) EGP seems to still exist, anyway even if it does not it is
not worth re-writing the world.

Also, change:
"5.1.1 ORIGIN


   ORIGIN is a well-known mandatory attribute.	The ORIGIN attribute
   shall be generated by the autonomous system that originates the
   associated routing information. It shall be included in the UPDATE
   messages of all BGP speakers that choose to propagate this
   information to other BGP speakers."

to:
"5.1.1 ORIGIN

   The value of the ORIGIN attribute shall be set by the speaker
   that originates the associated NLRI.	 Its value shall not be
   changed by any other speaker unless the other speaker is
   administratively configured to do so to affect policy
   decisions."

since:
1) It is already defined as well-known mandatory attribute.
2) It may be set differently within the same AS (not saying this is good).
3) It is commonly used for policy, but by default does not get changed.
4) Speakers have no choice, it is mandatory.


-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 1:43 PM
To: [e-mail]
Subject: issue 32

  32) Clarify EGP Reference
 
----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Need to clarify the EGP Reference, since there seems to be some
    confusion on the issue.
  
  Discussion:
  
  3. P. 13, EGP, are there other EGP protocols other than BGP that are in
use?
  If not, change EGP to BGP.
  
  A response to this suggested that we add a reference to [1] (the EGP
  spec) here.

This will be address as part of the response to issue 9
  
  Another reponse clarified that this refers to EGP-the-protocol and
  NOT the class.
  
  Another response disagreed, but suggested that:
  
  IGP = network was explicitly introduced into bgp (network cmd)
  INCOMPLETE = network was implicitly introduced into bgp (redistribute)
  EGP = other

I've yet to understand what is incorrect with the current text.
I also think that talking about "network cmd" and "redistribute"
makes it a bit vendor specific. Therefore, I think we should keep
the current text.
  
  The original commentor thought that this refered to EGP-the-class of
  protocols.   And why not use BGP therefore, as the only EGP.
  
  There was some disucssion over whether or not we should mention something
  that is historical.

I don't think that the BGP base spec needs to talk about the status
of EGP spec [RFC904].
  
  Jeff suggested a footnote in the Origin section about EGP.
  
  Curtis suggested that we state that the EGP in ORIGIN is depricated,
  but retain the value to document what it used to mean.
  
  This reviewer thinks a statement about whether this "EGP" origin refers
  to the protocol or the class or protocols would be useful.

>From the context it should be clear that we are talking about "the EGP"
(means [RFC904]).

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 OAA13354 for <[e-mail]>; Wed, 25 Sep 2002 14:06:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 854B491235; Wed, 25 Sep 2002 14:05:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 552F5912B1; Wed, 25 Sep 2002 14:05:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 07FBD91235 for <[e-mail]>; Wed, 25 Sep 2002 14:05:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DD5CC5DE66; Wed, 25 Sep 2002 14:05:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id CD5E95DE61 for <[e-mail]>; Wed, 25 Sep 2002 14:05:48 -0400 (EDT)
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 OAA86096; Wed, 25 Sep 2002 14:04:21 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Manav Bhatia <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, "'Alexei Roudnev'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: BGP - IGP Redistribution Issue 
In-reply-to: Your message of "Wed, 25 Sep 2002 10:08:50 +0530." <010a01c2644d$72ecdbe0$[e-mail]> 
Date: Wed, 25 Sep 2002 14:04:21 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <010a01c2644d$72ecdbe0$[e-mail]>, Manav Bhatia writes
:
> some more things which could be pondered upon.
> 
> - Bringing down all the EBGP connections immediately when the interface
> over which they run goes down (without waiting for the HoldTimer to
> expire!).
> 
> - router id [hope am not opening a can of worms :-)]
> 
> - A discussion on multiple views/instances/processes of BGP (many ISPs are
> using it) and their possible interaction amongst themselves/IGPs.
> 
> - Using communities
> 
> - Limited interaction with IGPs
> 
> - Hierarchical peering using Route Reflectors
> 
> Manav
> ----- Original Message -----
> From: "Abarbanel, Benjamin" <[e-mail]>
> To: "'Alexei Roudnev'" <[e-mail]>; "Abarbanel, Benjamin"
> <[e-mail]>; "'Jeffrey Haas'" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Tuesday, September 24, 2002 9:53 PM
> Subject: RE: BGP - IGP Redistribution Issue
> 
> 
> | Agreed, are there other "good practice" issues that can be added to this
> | spec?
> |
> | Ben
> |
> | > -----Original Message-----
> | > From: Alexei Roudnev [mailto:[e-mail]]
> | > Sent: Tuesday, September 24, 2002 12:11 PM
> | > To: Abarbanel, Benjamin; 'Jeffrey Haas'
> | > Cc: [e-mail]
> | > Subject: Re: BGP - IGP Redistribution Issue
> | >
> | >
> | > > > As much as I would really like to incorporate some of the
> | > best current
> | > > > practices that network operators have in operating BGP networks in
> | > > > a 1772 replacement, we shouldn't try to reproduce works such as
> | > > > Halabi's book in a RFC.
> | > > >
> | > >
> | > > I thought Halabi's book was derived from IETF Specs and Cisco field
> | > > experience.
> | > It was re-written 2 years ago, without sugnificant changes.
> | >
> | > Anyway, it is a good idea to have some statement preventing
> | > people from bad
> | > practices (such as injecting bgp routes into IGP, even in
> | > small network).



People responding should keep in mind that configuration advice is
still out of scope for the base BGP protocol spec which is what we are
disussing.

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 NAA12591 for <[e-mail]>; Wed, 25 Sep 2002 13:50:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 01562912AD; Wed, 25 Sep 2002 13:49:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BCE73912B1; Wed, 25 Sep 2002 13:49:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 745E2912AD for <[e-mail]>; Wed, 25 Sep 2002 13:49:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 53F3F5DE66; Wed, 25 Sep 2002 13:49:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id B5ACE5DE65 for <[e-mail]>; Wed, 25 Sep 2002 13:49:51 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PHnpm56083 for <[e-mail]>; Wed, 25 Sep 2002 10:49:51 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 32.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 10:49:51 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  32.1) EGP ORIGIN Clarification
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Proposal to update the EGP ORIGIN section.
  
  Discussion:
  
  This discussion is picked up again in the "Review of draft-ietf-idr-bgp4-17"
  thread, where specific text is proposed:
  
  Old:
  
              "ORIGIN is a well-known mandatory attribute that defines the
              origin of the path information.  The data octet can assume
              the following values:
  
                    Value		Meaning
  
                    0	    IGP - Network Layer Reachability Information
                                 is interior to the originating AS
  
                    1	    EGP - Network Layer Reachability Information
                                 learned via the EGP protocol
  
                    2	    INCOMPLETE - Network Layer Reachability
                                 Information learned by some other means"
  New:
  
              "ORIGIN is a well-known mandatory attribute that defines the
              origin of the path information.  The data octet can assume
              the following values:
  
                    Value		Meaning
  
                    0	    IGP - NLRI was explicitly introduced into bgp
  
                    1	    EGP - this value was administratively
                                 configured to affect policy decisions or
                                 NLRI was learned via the EGP protocol [1]
  
                    2	    INCOMPLETE - NLRI was implicitly introduced
                                        into bgp"
  
  since:
  1) The network command sets the origin to IGP and I remember seeing
  somewhere that only static routes should be set to IGP.
  2) The primary use of EGP value is policy
  3) EGP seems to still exist, anyway even if it does not it is
  not worth re-writing the world.

Since the current text is technically correct, and since the terms
"implicitly introduced" and "explicitly introduced" aren't really
well-defined I think we should just keep the current text.
  
  Also, change:
  "5.1.1 ORIGIN
  
  
     ORIGIN is a well-known mandatory attribute.	The ORIGIN attribute
     shall be generated by the autonomous system that originates the
     associated routing information. It shall be included in the UPDATE
     messages of all BGP speakers that choose to propagate this
     information to other BGP speakers."
  
  to:
  "5.1.1 ORIGIN
  
     The value of the ORIGIN attribute shall be set by the speaker
     that originates the associated NLRI.	 Its value shall not be
     changed by any other speaker unless the other speaker is
     administratively configured to do so to affect policy
     decisions."
  
  since:
  1) It is already defined as well-known mandatory attribute.
  2) It may be set differently within the same AS (not saying this is good).
  3) It is commonly used for policy, but by default does not get changed.
  4) Speakers have no choice, it is mandatory.

Please note that issue 33 asks for exactly the opposite. For the
sake of consistency I suggest we keep 5.1.1 as is.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA12263 for <[e-mail]>; Wed, 25 Sep 2002 13:43:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B4E07912DD; Wed, 25 Sep 2002 13:43:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A193912DE; Wed, 25 Sep 2002 13:43:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 57CE8912DD for <[e-mail]>; Wed, 25 Sep 2002 13:43:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2CE655DE63; Wed, 25 Sep 2002 13:43:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id C51D75DE61 for <[e-mail]>; Wed, 25 Sep 2002 13:43:23 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PHhNm55388 for <[e-mail]>; Wed, 25 Sep 2002 10:43:23 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 32
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 10:43:23 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  32) Clarify EGP Reference
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Need to clarify the EGP Reference, since there seems to be some
    confusion on the issue.
  
  Discussion:
  
  3. P. 13, EGP, are there other EGP protocols other than BGP that are in use?
  If not, change EGP to BGP.
  
  A response to this suggested that we add a reference to [1] (the EGP
  spec) here.

This will be address as part of the response to issue 9
  
  Another reponse clarified that this refers to EGP-the-protocol and
  NOT the class.
  
  Another response disagreed, but suggested that:
  
  IGP = network was explicitly introduced into bgp (network cmd)
  INCOMPLETE = network was implicitly introduced into bgp (redistribute)
  EGP = other

I've yet to understand what is incorrect with the current text.
I also think that talking about "network cmd" and "redistribute"
makes it a bit vendor specific. Therefore, I think we should keep
the current text.
  
  The original commentor thought that this refered to EGP-the-class of
  protocols.   And why not use BGP therefore, as the only EGP.
  
  There was some disucssion over whether or not we should mention something
  that is historical.

I don't think that the BGP base spec needs to talk about the status
of EGP spec [RFC904].
  
  Jeff suggested a footnote in the Origin section about EGP.
  
  Curtis suggested that we state that the EGP in ORIGIN is depricated,
  but retain the value to document what it used to mean.
  
  This reviewer thinks a statement about whether this "EGP" origin refers
  to the protocol or the class or protocols would be useful.

>From the context it should be clear that we are talking about "the EGP"
(means [RFC904]).

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 NAA12057 for <[e-mail]>; Wed, 25 Sep 2002 13:38:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EA3D2912DC; Wed, 25 Sep 2002 13:38:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B598B912DD; Wed, 25 Sep 2002 13:38:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A1B95912DC for <[e-mail]>; Wed, 25 Sep 2002 13:38:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8BC9A5DE63; Wed, 25 Sep 2002 13:38:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 15E355DE61 for <[e-mail]>; Wed, 25 Sep 2002 13:38:38 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA09238; Wed, 25 Sep 2002 13:38:35 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04256; Wed, 25 Sep 2002 13:38:37 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7HWGB>; Wed, 25 Sep 2002 13:38:36 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Gargi Nalawade'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, "'Martin, Christian'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: RE: issue 40
Date: Wed, 25 Sep 2002 13:38:35 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I guess the problem was that the Cisco search tool comes up with some
specific release first and its not obvious where the mainline release
is. Thus, I assumed it was the case for all the other releases. 

My mistake, it would have been nicer if their/your search tools found
the mainline release first. I used just a generic term for the command

Ben

> -----Original Message-----
> From: Gargi Nalawade [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 1:34 PM
> To: Natale, Jonathan
> Cc: 'Abarbanel, Benjamin'; 'Martin, Christian'; 'Jeffrey Haas';
> [e-mail]
> Subject: Re: issue 40
> 
> 
> Thanks Jonathan!
> 
> The non-mainline releases are meant for specific products 
> which may not
> need all teh feature-sets of mainline. So to see whether a command is
> supported or not, tha mainline releases would be the place to 
> refer to.
> 
> -Gargi
> 
> "Natale, Jonathan" wrote:
> > 
> > Where all the cmds are:
> > 
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios12
> 2/122cgcr/fipr
> > rp_r/bgp_r/1rfbgp1.htm#xtocid44
> > 
> > did I miss something???
> > 
> > -----Original Message-----
> > From: Abarbanel, Benjamin [mailto:[e-mail]]
> > Sent: Wednesday, September 25, 2002 12:45 PM
> > To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Gargi Nalawade'
> > Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
> > Subject: RE: issue 40
> > 
> > Please give me another link, that says the base release 
> supports this.
> > 
> > Thanks,
> > Ben
> > 
> > > -----Original Message-----
> > > From: Natale, Jonathan [mailto:[e-mail]]
> > > Sent: Wednesday, September 25, 2002 12:43 PM
> > > To: 'Abarbanel, Benjamin'; 'Gargi Nalawade'
> > > Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
> > > Subject: RE: issue 40
> > >
> > >
> > > Looks like that applies to Catalyst 3550 Multilayer 
> Switch Software
> > > Configuration Guide, Release 12.1(11)EA1,  right?
> > >
> > > The cmd is in the online cmd docs AND the CLI help--so 
> I'd say it IS
> > > supported.
> > >
> > > :-)
> > >
> > > -----Original Message-----
> > > From: Abarbanel, Benjamin [mailto:[e-mail]]
> > > Sent: Wednesday, September 25, 2002 12:22 PM
> > > To: 'Gargi Nalawade'; Abarbanel, Benjamin
> > > Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
> > > Subject: RE: issue 40
> > >
> > > Here is the HTML page for this:
> > >
> > > http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/1211
> > > 1ea1/3550scg/s
> > > wuncli.htm
> > >
> > > Look for:
> > >
> > > "Unsupported BGP Router Configuration Commands"
> > >
> > > Ben
> > >
> > > > -----Original Message-----
> > > > From: Gargi Nalawade [mailto:[e-mail]]
> > > > Sent: Wednesday, September 25, 2002 12:19 PM
> > > > To: Abarbanel, Benjamin
> > > > Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
> > > > Subject: Re: issue 40
> > > >
> > > >
> > > > Ben,
> > > >
> > > > When, where does Cisco say that this command is unsupported?
> > > > Not that I know
> > > > of ;) This command very much exists today and is supported.
> > > >
> > > > -Gargi
> > > >
> > > > "Abarbanel, Benjamin" wrote:
> > > > >
> > > > > Cisco says this is one of the unsupported BGP Router
> > > > Configuration commands.
> > > > > I dont know if they are in Beta test now, or plan to become
> > > > obsolete?
> > > > >
> > > > > Ben
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Martin, Christian [mailto:[e-mail]]
> > > > > > Sent: Wednesday, September 25, 2002 12:04 PM
> > > > > > To: 'Jeffrey Haas'; Abarbanel, Benjamin
> > > > > > Cc: [e-mail]
> > > > > > Subject: RE: issue 40
> > > > > >
> > > > > >
> > > > > > Cisco
> > > > > >
> > > > > > 
http://www.cisco.com/univercd/cc/td/doc/product/software/ios12
> > > > > 1/121cgcr/ip_r
> > > > > /iprprt2/1rdbgp.htm#xtocid41
> > > > >
> > > > >  !
> > > > >  router bgp x
> > > > >   neighbor x.x.x.x advertisement-interval <0-600>
> > > > >  !
> > > > >
> > > > > -chris
> > > > >
> > > > > >-----Original Message-----
> > > > > >From: Jeffrey Haas [mailto:[e-mail]]
> > > > > >Sent: Wednesday, September 25, 2002 11:53 AM
> > > > > >To: Abarbanel, Benjamin
> > > > > >Cc: [e-mail]
> > > > > >Subject: Re: issue 40
> > > > > >
> > > > > >
> > > > > >On Wed, Sep 25, 2002 at 11:50:26AM -0400, Abarbanel,
> > > Benjamin wrote:
> > > > > >> The MinRouteAdvertisementInterval although maybe
> > > defined per peer
> > > > > >> basis. Cisco IOS and other vendors, do not allow you to
> > > > > configure it
> > > > > >> at all, and
> > > > > >
> > > > > >GateD and Juniper: Outdelay.
> > > > > >(Note - I'm not aware of how Juniper may have caused this
> > > > > >behavior to diverge from GateD's) Admittedly, its not a
> > > > > >separate MAOI and MRAI value, but it lets you do the job.
> > > > > >
> > > > > >> Ben
> > > > > >
> > > > > >--
> > > > > >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 NAA11867 for <[e-mail]>; Wed, 25 Sep 2002 13:34:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A7D53912DB; Wed, 25 Sep 2002 13:34:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 792BC912DC; Wed, 25 Sep 2002 13:34:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2ACDA912DB for <[e-mail]>; Wed, 25 Sep 2002 13:34:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 171015DE62; Wed, 25 Sep 2002 13:34:18 -0400 (EDT)
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 B0CB95DE61 for <[e-mail]>; Wed, 25 Sep 2002 13:34:12 -0400 (EDT)
Received: from mira-sjcm-2.cisco.com (IDENT:[e-mail] [171.69.24.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8PHXw3x028124; Wed, 25 Sep 2002 10:33:58 -0700 (PDT)
Received: from cisco.com (dhcp-10-24-17-134.cisco.com [10.24.17.134]) by mira-sjcm-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG49084; Wed, 25 Sep 2002 10:34:02 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 10:34:02 -0700
From: Gargi Nalawade <[e-mail]>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Abarbanel, Benjamin'" <[e-mail]>, "'Martin, Christian'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: Re: issue 40
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Thanks Jonathan!

The non-mainline releases are meant for specific products which may not
need all teh feature-sets of mainline. So to see whether a command is
supported or not, tha mainline releases would be the place to refer to.

-Gargi

"Natale, Jonathan" wrote:
> 
> Where all the cmds are:
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr
> rp_r/bgp_r/1rfbgp1.htm#xtocid44
> 
> did I miss something???
> 
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 12:45 PM
> To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Gargi Nalawade'
> Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
> Subject: RE: issue 40
> 
> Please give me another link, that says the base release supports this.
> 
> Thanks,
> Ben
> 
> > -----Original Message-----
> > From: Natale, Jonathan [mailto:[e-mail]]
> > Sent: Wednesday, September 25, 2002 12:43 PM
> > To: 'Abarbanel, Benjamin'; 'Gargi Nalawade'
> > Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
> > Subject: RE: issue 40
> >
> >
> > Looks like that applies to Catalyst 3550 Multilayer Switch Software
> > Configuration Guide, Release 12.1(11)EA1,  right?
> >
> > The cmd is in the online cmd docs AND the CLI help--so I'd say it IS
> > supported.
> >
> > :-)
> >
> > -----Original Message-----
> > From: Abarbanel, Benjamin [mailto:[e-mail]]
> > Sent: Wednesday, September 25, 2002 12:22 PM
> > To: 'Gargi Nalawade'; Abarbanel, Benjamin
> > Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
> > Subject: RE: issue 40
> >
> > Here is the HTML page for this:
> >
> > http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/1211
> > 1ea1/3550scg/s
> > wuncli.htm
> >
> > Look for:
> >
> > "Unsupported BGP Router Configuration Commands"
> >
> > Ben
> >
> > > -----Original Message-----
> > > From: Gargi Nalawade [mailto:[e-mail]]
> > > Sent: Wednesday, September 25, 2002 12:19 PM
> > > To: Abarbanel, Benjamin
> > > Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
> > > Subject: Re: issue 40
> > >
> > >
> > > Ben,
> > >
> > > When, where does Cisco say that this command is unsupported?
> > > Not that I know
> > > of ;) This command very much exists today and is supported.
> > >
> > > -Gargi
> > >
> > > "Abarbanel, Benjamin" wrote:
> > > >
> > > > Cisco says this is one of the unsupported BGP Router
> > > Configuration commands.
> > > > I dont know if they are in Beta test now, or plan to become
> > > obsolete?
> > > >
> > > > Ben
> > > >
> > > > > -----Original Message-----
> > > > > From: Martin, Christian [mailto:[e-mail]]
> > > > > Sent: Wednesday, September 25, 2002 12:04 PM
> > > > > To: 'Jeffrey Haas'; Abarbanel, Benjamin
> > > > > Cc: [e-mail]
> > > > > Subject: RE: issue 40
> > > > >
> > > > >
> > > > > Cisco
> > > > >
> > > > > http://www.cisco.com/univercd/cc/td/doc/product/software/ios12
> > > > > 1/121cgcr/ip_r
> > > > > /iprprt2/1rdbgp.htm#xtocid41
> > > > >
> > > > >  !
> > > > >  router bgp x
> > > > >   neighbor x.x.x.x advertisement-interval <0-600>
> > > > >  !
> > > > >
> > > > > -chris
> > > > >
> > > > > >-----Original Message-----
> > > > > >From: Jeffrey Haas [mailto:[e-mail]]
> > > > > >Sent: Wednesday, September 25, 2002 11:53 AM
> > > > > >To: Abarbanel, Benjamin
> > > > > >Cc: [e-mail]
> > > > > >Subject: Re: issue 40
> > > > > >
> > > > > >
> > > > > >On Wed, Sep 25, 2002 at 11:50:26AM -0400, Abarbanel,
> > > Benjamin wrote:
> > > > > >> The MinRouteAdvertisementInterval although maybe
> > > defined per peer
> > > > > >> basis. Cisco IOS and other vendors, do not allow you to
> > > > > configure it
> > > > > >> at all, and
> > > > > >
> > > > > >GateD and Juniper: Outdelay.
> > > > > >(Note - I'm not aware of how Juniper may have caused this
> > > > > >behavior to diverge from GateD's) Admittedly, its not a
> > > > > >separate MAOI and MRAI value, but it lets you do the job.
> > > > > >
> > > > > >> Ben
> > > > > >
> > > > > >--
> > > > > >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 NAA11756 for <[e-mail]>; Wed, 25 Sep 2002 13:33:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D66D0912DA; Wed, 25 Sep 2002 13:32:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93893912DB; Wed, 25 Sep 2002 13:32:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9F5C3912DA for <[e-mail]>; Wed, 25 Sep 2002 13:32:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 89EA25DE61; Wed, 25 Sep 2002 13:32:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 0A1B95DE3E for <[e-mail]>; Wed, 25 Sep 2002 13:32:05 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08734; Wed, 25 Sep 2002 13:32:01 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA02572; Wed, 25 Sep 2002 13:32:02 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7HV4K>; Wed, 25 Sep 2002 13:31:55 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: BGP Base Draft - Issue List v1.0 2002-09-24
Date: Wed, 25 Sep 2002 13:31:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Andrew:
 You did an excellent job in keeping track of all the issues.

Thanks,
Ben

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, September 24, 2002 7:14 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: BGP Base Draft - Issue List v1.0 2002-09-24
> 
> 
> Greetings,
> 
> Attached, as text, is a list of the issues that we have been 
> discussing.
> 
> 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 NAA11705 for <[e-mail]>; Wed, 25 Sep 2002 13:31:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 01E9E912D8; Wed, 25 Sep 2002 13:31:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7B9E912DA; Wed, 25 Sep 2002 13:31:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8F2D4912D8 for <[e-mail]>; Wed, 25 Sep 2002 13:31:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5CA145DE61; Wed, 25 Sep 2002 13:31:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 0FD925DE3E for <[e-mail]>; Wed, 25 Sep 2002 13:31:13 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HQB1>; Wed, 25 Sep 2002 13:31:12 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 30
Date: Wed, 25 Sep 2002 13:31:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

agreed

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 1:27 PM
To: [e-mail]
Subject: issue 30

  30) Mention Other Message Types
 
----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Do we add this explicity?  If so when?  With what text?
  
  Discussion:
  
  1. P. 7 Type: Need to add the new message types such as, Capability
  Negotiations (RFC2842), Route Refresh, etc.
  
  One reponse argued that these are out-of-scope of the base document.
  One reponse agreed, but thought that it should be capability and not
  message type. The original commentor reponsed about Message type
  from the capability draft.

The only new message type that is covered by an RFC (rather than
just an Internet Draft) is the Refresh message. With this in mind
how about replacing the following:

  The following type codes are defined:
  
                                    1 - OPEN
                                    2 - UPDATE
                                    3 - NOTIFICATION
                                    4 - KEEPALIVE

with

  This document defines the following type codes:
  
                                    1 - OPEN
                                    2 - UPDATE
                                    3 - NOTIFICATION
                                    4 - KEEPALIVE

  [RFC2918] defines one more type code.

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 NAA11495 for <[e-mail]>; Wed, 25 Sep 2002 13:27:15 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6945F912C9; Wed, 25 Sep 2002 13:26:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36A8F912D8; Wed, 25 Sep 2002 13:26:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 10C24912C9 for <[e-mail]>; Wed, 25 Sep 2002 13:26:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E7A7A5DE61; Wed, 25 Sep 2002 13:26:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 8C0045DE3E for <[e-mail]>; Wed, 25 Sep 2002 13:26:53 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PHQrm53617 for <[e-mail]>; Wed, 25 Sep 2002 10:26:53 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 30
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 10:26:53 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  30) Mention Other Message Types
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Do we add this explicity?  If so when?  With what text?
  
  Discussion:
  
  1. P. 7 Type: Need to add the new message types such as, Capability
  Negotiations (RFC2842), Route Refresh, etc.
  
  One reponse argued that these are out-of-scope of the base document.
  One reponse agreed, but thought that it should be capability and not
  message type. The original commentor reponsed about Message type
  from the capability draft.

The only new message type that is covered by an RFC (rather than
just an Internet Draft) is the Refresh message. With this in mind
how about replacing the following:

  The following type codes are defined:
  
                                    1 - OPEN
                                    2 - UPDATE
                                    3 - NOTIFICATION
                                    4 - KEEPALIVE

with

  This document defines the following type codes:
  
                                    1 - OPEN
                                    2 - UPDATE
                                    3 - NOTIFICATION
                                    4 - KEEPALIVE

  [RFC2918] defines one more type code.

Yakov.



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 NAA11229 for <[e-mail]>; Wed, 25 Sep 2002 13:20:58 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 449CF912A7; Wed, 25 Sep 2002 13:20:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10122912C9; Wed, 25 Sep 2002 13:20:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 90D27912A7 for <[e-mail]>; Wed, 25 Sep 2002 13:20:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7421B5DE60; Wed, 25 Sep 2002 13:20:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 1CC1F5DE3E for <[e-mail]>; Wed, 25 Sep 2002 13:20:28 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HP08>; Wed, 25 Sep 2002 13:20:27 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, "'Gargi Nalawade'" <[e-mail]>
Cc: "'Martin, Christian'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: RE: issue 40
Date: Wed, 25 Sep 2002 13:20:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Where all the cmds are:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr
rp_r/bgp_r/1rfbgp1.htm#xtocid44

did I miss something???

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 12:45 PM
To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Gargi Nalawade'
Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
Subject: RE: issue 40

Please give me another link, that says the base release supports this.

Thanks,
Ben

> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 12:43 PM
> To: 'Abarbanel, Benjamin'; 'Gargi Nalawade'
> Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
> Subject: RE: issue 40
> 
> 
> Looks like that applies to Catalyst 3550 Multilayer Switch Software
> Configuration Guide, Release 12.1(11)EA1,  right?
> 
> The cmd is in the online cmd docs AND the CLI help--so I'd say it IS
> supported.
> 
> :-)
> 
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Wednesday, September 25, 2002 12:22 PM
> To: 'Gargi Nalawade'; Abarbanel, Benjamin
> Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
> Subject: RE: issue 40
> 
> Here is the HTML page for this:
> 
> http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/1211
> 1ea1/3550scg/s
> wuncli.htm
> 
> Look for:
> 
> "Unsupported BGP Router Configuration Commands"
> 
> Ben
> 
> > -----Original Message-----
> > From: Gargi Nalawade [mailto:[e-mail]]
> > Sent: Wednesday, September 25, 2002 12:19 PM
> > To: Abarbanel, Benjamin
> > Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
> > Subject: Re: issue 40
> > 
> > 
> > Ben,
> > 
> > When, where does Cisco say that this command is unsupported? 
> > Not that I know
> > of ;) This command very much exists today and is supported.
> > 
> > -Gargi
> > 
> > "Abarbanel, Benjamin" wrote:
> > > 
> > > Cisco says this is one of the unsupported BGP Router 
> > Configuration commands.
> > > I dont know if they are in Beta test now, or plan to become 
> > obsolete?
> > > 
> > > Ben
> > > 
> > > > -----Original Message-----
> > > > From: Martin, Christian [mailto:[e-mail]]
> > > > Sent: Wednesday, September 25, 2002 12:04 PM
> > > > To: 'Jeffrey Haas'; Abarbanel, Benjamin
> > > > Cc: [e-mail]
> > > > Subject: RE: issue 40
> > > >
> > > >
> > > > Cisco
> > > >
> > > > http://www.cisco.com/univercd/cc/td/doc/product/software/ios12
> > > > 1/121cgcr/ip_r
> > > > /iprprt2/1rdbgp.htm#xtocid41
> > > >
> > > >  !
> > > >  router bgp x
> > > >   neighbor x.x.x.x advertisement-interval <0-600>
> > > >  !
> > > >
> > > > -chris
> > > >
> > > > >-----Original Message-----
> > > > >From: Jeffrey Haas [mailto:[e-mail]]
> > > > >Sent: Wednesday, September 25, 2002 11:53 AM
> > > > >To: Abarbanel, Benjamin
> > > > >Cc: [e-mail]
> > > > >Subject: Re: issue 40
> > > > >
> > > > >
> > > > >On Wed, Sep 25, 2002 at 11:50:26AM -0400, Abarbanel, 
> > Benjamin wrote:
> > > > >> The MinRouteAdvertisementInterval although maybe 
> > defined per peer
> > > > >> basis. Cisco IOS and other vendors, do not allow you to
> > > > configure it
> > > > >> at all, and
> > > > >
> > > > >GateD and Juniper: Outdelay.
> > > > >(Note - I'm not aware of how Juniper may have caused this
> > > > >behavior to diverge from GateD's) Admittedly, its not a
> > > > >separate MAOI and MRAI value, but it lets you do the job.
> > > > >
> > > > >> Ben
> > > > >
> > > > >--
> > > > >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 NAA10998 for <[e-mail]>; Wed, 25 Sep 2002 13:16:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D5AE8912B8; Wed, 25 Sep 2002 13:16:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 28C8E912C9; Wed, 25 Sep 2002 13:16:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ACB42912B8 for <[e-mail]>; Wed, 25 Sep 2002 13:16:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8F8525DE60; Wed, 25 Sep 2002 13:16:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 330BA5DE3E for <[e-mail]>; Wed, 25 Sep 2002 13:16:12 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PHGBm52490 for <[e-mail]>; Wed, 25 Sep 2002 10:16:11 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 22
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 10:16:11 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  22) Scope of Path Attribute Field
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Add a sentance to clarify that all attributes in the Path Attribute
    field beling to all prefixes in the NLRI.
  
  Discussion:
  
    P. 12, right after "Path Attributes". The following sentence should be
    added to this section to clarify the scope of the Path Attribute field.   
    "All attributes in the Path Attribute field represent the characteristics of
    all the route prefixes defined in the NLRI field of the message".
  
This will be covered by the following text in 3.1 that will be in the
-18 version (see also issue 54).

   Routes are advertised between BGP speakers in UPDATE messages.
   Multiple routes that have the same path attributes can be
   advertised in a single UPDATE message by including multiple
   prefixes in the NLRI field of the UPDATE message.

Therefore there is no need to add the sentence proposed above.

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 MAA09608 for <[e-mail]>; Wed, 25 Sep 2002 12:46:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 39F4C912BB; Wed, 25 Sep 2002 12:45:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 035CD912DA; Wed, 25 Sep 2002 12:45:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4284B912BB for <[e-mail]>; Wed, 25 Sep 2002 12:45:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E83B05DE53; Wed, 25 Sep 2002 12:45:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id D6AA45DE50 for <[e-mail]>; Wed, 25 Sep 2002 12:45:15 -0400 (EDT)
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 MAA85781; Wed, 25 Sep 2002 12:43:53 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, "'Manav Bhatia'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Generial Editorial Comment 
In-reply-to: Your message of "Tue, 24 Sep 2002 10:27:48 EDT." <[e-mail]> 
Date: Wed, 25 Sep 2002 12:43:53 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> 
> While we are on the subject of BGP interworking with other protocols. If its
> a bad idea to redistribute the massive BGP tables into IGP protocols such as
> OSPF/ISIS, should we not have a rule in some spec forbidding it from being
> done
> to avoid an IGP meltdown?
> 
> Ben


Its always been considered a usage issue, not an implementation issue.
The protocol spec doesn't give configuration advise.

I suppose we could change anything, but there is a place for this sort
of thing and it is in the replacement for rfc1772.

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 MAA09573 for <[e-mail]>; Wed, 25 Sep 2002 12:45:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A1631912D7; Wed, 25 Sep 2002 12:45:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39DDA912BB; Wed, 25 Sep 2002 12:45:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3CBDA912D7 for <[e-mail]>; Wed, 25 Sep 2002 12:45:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DEFC95DE53; Wed, 25 Sep 2002 12:45:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 190BF5DE50 for <[e-mail]>; Wed, 25 Sep 2002 12:45:08 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA06022; Wed, 25 Sep 2002 12:45:05 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA24518; Wed, 25 Sep 2002 12:45:06 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7HTTA>; Wed, 25 Sep 2002 12:45:05 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, "'Gargi Nalawade'" <[e-mail]>
Cc: "'Martin, Christian'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: RE: issue 40
Date: Wed, 25 Sep 2002 12:45:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Please give me another link, that says the base release supports this.

Thanks,
Ben

> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 12:43 PM
> To: 'Abarbanel, Benjamin'; 'Gargi Nalawade'
> Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
> Subject: RE: issue 40
> 
> 
> Looks like that applies to Catalyst 3550 Multilayer Switch Software
> Configuration Guide, Release 12.1(11)EA1,  right?
> 
> The cmd is in the online cmd docs AND the CLI help--so I'd say it IS
> supported.
> 
> :-)
> 
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Wednesday, September 25, 2002 12:22 PM
> To: 'Gargi Nalawade'; Abarbanel, Benjamin
> Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
> Subject: RE: issue 40
> 
> Here is the HTML page for this:
> 
> http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/1211
> 1ea1/3550scg/s
> wuncli.htm
> 
> Look for:
> 
> "Unsupported BGP Router Configuration Commands"
> 
> Ben
> 
> > -----Original Message-----
> > From: Gargi Nalawade [mailto:[e-mail]]
> > Sent: Wednesday, September 25, 2002 12:19 PM
> > To: Abarbanel, Benjamin
> > Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
> > Subject: Re: issue 40
> > 
> > 
> > Ben,
> > 
> > When, where does Cisco say that this command is unsupported? 
> > Not that I know
> > of ;) This command very much exists today and is supported.
> > 
> > -Gargi
> > 
> > "Abarbanel, Benjamin" wrote:
> > > 
> > > Cisco says this is one of the unsupported BGP Router 
> > Configuration commands.
> > > I dont know if they are in Beta test now, or plan to become 
> > obsolete?
> > > 
> > > Ben
> > > 
> > > > -----Original Message-----
> > > > From: Martin, Christian [mailto:[e-mail]]
> > > > Sent: Wednesday, September 25, 2002 12:04 PM
> > > > To: 'Jeffrey Haas'; Abarbanel, Benjamin
> > > > Cc: [e-mail]
> > > > Subject: RE: issue 40
> > > >
> > > >
> > > > Cisco
> > > >
> > > > http://www.cisco.com/univercd/cc/td/doc/product/software/ios12
> > > > 1/121cgcr/ip_r
> > > > /iprprt2/1rdbgp.htm#xtocid41
> > > >
> > > >  !
> > > >  router bgp x
> > > >   neighbor x.x.x.x advertisement-interval <0-600>
> > > >  !
> > > >
> > > > -chris
> > > >
> > > > >-----Original Message-----
> > > > >From: Jeffrey Haas [mailto:[e-mail]]
> > > > >Sent: Wednesday, September 25, 2002 11:53 AM
> > > > >To: Abarbanel, Benjamin
> > > > >Cc: [e-mail]
> > > > >Subject: Re: issue 40
> > > > >
> > > > >
> > > > >On Wed, Sep 25, 2002 at 11:50:26AM -0400, Abarbanel, 
> > Benjamin wrote:
> > > > >> The MinRouteAdvertisementInterval although maybe 
> > defined per peer
> > > > >> basis. Cisco IOS and other vendors, do not allow you to
> > > > configure it
> > > > >> at all, and
> > > > >
> > > > >GateD and Juniper: Outdelay.
> > > > >(Note - I'm not aware of how Juniper may have caused this
> > > > >behavior to diverge from GateD's) Admittedly, its not a
> > > > >separate MAOI and MRAI value, but it lets you do the job.
> > > > >
> > > > >> Ben
> > > > >
> > > > >--
> > > > >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 MAA09488 for <[e-mail]>; Wed, 25 Sep 2002 12:44:15 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C4C2D912D9; Wed, 25 Sep 2002 12:42:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95D68912D8; Wed, 25 Sep 2002 12:42:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 34284912D7 for <[e-mail]>; Wed, 25 Sep 2002 12:42:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 234135DE53; Wed, 25 Sep 2002 12:42:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id D98415DE50 for <[e-mail]>; Wed, 25 Sep 2002 12:42:35 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HP6D>; Wed, 25 Sep 2002 12:42:35 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>, "'Gargi Nalawade'" <[e-mail]>
Cc: "'Martin, Christian'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: RE: issue 40
Date: Wed, 25 Sep 2002 12:42:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Looks like that applies to Catalyst 3550 Multilayer Switch Software
Configuration Guide, Release 12.1(11)EA1,  right?

The cmd is in the online cmd docs AND the CLI help--so I'd say it IS
supported.

:-)

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 12:22 PM
To: 'Gargi Nalawade'; Abarbanel, Benjamin
Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
Subject: RE: issue 40

Here is the HTML page for this:

http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12111ea1/3550scg/s
wuncli.htm

Look for:

"Unsupported BGP Router Configuration Commands"

Ben

> -----Original Message-----
> From: Gargi Nalawade [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 12:19 PM
> To: Abarbanel, Benjamin
> Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
> Subject: Re: issue 40
> 
> 
> Ben,
> 
> When, where does Cisco say that this command is unsupported? 
> Not that I know
> of ;) This command very much exists today and is supported.
> 
> -Gargi
> 
> "Abarbanel, Benjamin" wrote:
> > 
> > Cisco says this is one of the unsupported BGP Router 
> Configuration commands.
> > I dont know if they are in Beta test now, or plan to become 
> obsolete?
> > 
> > Ben
> > 
> > > -----Original Message-----
> > > From: Martin, Christian [mailto:[e-mail]]
> > > Sent: Wednesday, September 25, 2002 12:04 PM
> > > To: 'Jeffrey Haas'; Abarbanel, Benjamin
> > > Cc: [e-mail]
> > > Subject: RE: issue 40
> > >
> > >
> > > Cisco
> > >
> > > http://www.cisco.com/univercd/cc/td/doc/product/software/ios12
> > > 1/121cgcr/ip_r
> > > /iprprt2/1rdbgp.htm#xtocid41
> > >
> > >  !
> > >  router bgp x
> > >   neighbor x.x.x.x advertisement-interval <0-600>
> > >  !
> > >
> > > -chris
> > >
> > > >-----Original Message-----
> > > >From: Jeffrey Haas [mailto:[e-mail]]
> > > >Sent: Wednesday, September 25, 2002 11:53 AM
> > > >To: Abarbanel, Benjamin
> > > >Cc: [e-mail]
> > > >Subject: Re: issue 40
> > > >
> > > >
> > > >On Wed, Sep 25, 2002 at 11:50:26AM -0400, Abarbanel, 
> Benjamin wrote:
> > > >> The MinRouteAdvertisementInterval although maybe 
> defined per peer
> > > >> basis. Cisco IOS and other vendors, do not allow you to
> > > configure it
> > > >> at all, and
> > > >
> > > >GateD and Juniper: Outdelay.
> > > >(Note - I'm not aware of how Juniper may have caused this
> > > >behavior to diverge from GateD's) Admittedly, its not a
> > > >separate MAOI and MRAI value, but it lets you do the job.
> > > >
> > > >> Ben
> > > >
> > > >--
> > > >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 MAA09323 for <[e-mail]>; Wed, 25 Sep 2002 12:39:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4F98D912D5; Wed, 25 Sep 2002 12:39:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16E45912D6; Wed, 25 Sep 2002 12:39:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 21761912D5 for <[e-mail]>; Wed, 25 Sep 2002 12:39:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 101565DE50; Wed, 25 Sep 2002 12:39:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 900CD5DE4F for <[e-mail]>; Wed, 25 Sep 2002 12:39:09 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA05658; Wed, 25 Sep 2002 12:39:06 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA23468; Wed, 25 Sep 2002 12:39:07 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7HTLA>; Wed, 25 Sep 2002 12:39:06 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, "'Martin, Christian'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 40
Date: Wed, 25 Sep 2002 12:39:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Jonatha:

> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 12:37 PM
> To: 'Abarbanel, Benjamin'; 'Martin, Christian'; 'Jeffrey Haas'
> Cc: [e-mail]
> Subject: RE: issue 40
> 
> 
> Usually that means it is in beta/user docs are not done.  As 
> a general rule
> you don't want to change timers--so that could be what it means too.
> 
So does that mean the parameter is applied the same for all resources of BGP
instance/router level?

Ben
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Wednesday, September 25, 2002 12:11 PM
> To: 'Martin, Christian'; 'Jeffrey Haas'; Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: RE: issue 40
> 
> Cisco says this is one of the unsupported BGP Router 
> Configuration commands.
> I dont know if they are in Beta test now, or plan to become obsolete?
> 
> Ben
> 
> > -----Original Message-----
> > From: Martin, Christian [mailto:[e-mail]]
> > Sent: Wednesday, September 25, 2002 12:04 PM
> > To: 'Jeffrey Haas'; Abarbanel, Benjamin
> > Cc: [e-mail]
> > Subject: RE: issue 40
> > 
> > 
> > Cisco
> > 
> > http://www.cisco.com/univercd/cc/td/doc/product/software/ios12
> > 1/121cgcr/ip_r
> > /iprprt2/1rdbgp.htm#xtocid41
> > 
> >  !
> >  router bgp x
> >   neighbor x.x.x.x advertisement-interval <0-600>
> >  !
> > 
> > -chris
> > 
> > >-----Original Message-----
> > >From: Jeffrey Haas [mailto:[e-mail]] 
> > >Sent: Wednesday, September 25, 2002 11:53 AM
> > >To: Abarbanel, Benjamin
> > >Cc: [e-mail]
> > >Subject: Re: issue 40
> > >
> > >
> > >On Wed, Sep 25, 2002 at 11:50:26AM -0400, Abarbanel, 
> Benjamin wrote:
> > >> The MinRouteAdvertisementInterval although maybe defined 
> per peer 
> > >> basis. Cisco IOS and other vendors, do not allow you to 
> > configure it 
> > >> at all, and
> > >
> > >GateD and Juniper: Outdelay.
> > >(Note - I'm not aware of how Juniper may have caused this 
> > >behavior to diverge from GateD's) Admittedly, its not a 
> > >separate MAOI and MRAI value, but it lets you do the job.
> > >
> > >> Ben
> > >
> > >-- 
> > >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 MAA09232 for <[e-mail]>; Wed, 25 Sep 2002 12:37:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CE40B912D3; Wed, 25 Sep 2002 12:36:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99972912D5; Wed, 25 Sep 2002 12:36:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 59566912D3 for <[e-mail]>; Wed, 25 Sep 2002 12:36:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1C4265DE50; Wed, 25 Sep 2002 12:36:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id CEFA55DE4F for <[e-mail]>; Wed, 25 Sep 2002 12:36:47 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HP5L>; Wed, 25 Sep 2002 12:36:47 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>, "'Martin, Christian'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 40
Date: Wed, 25 Sep 2002 12:36:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Usually that means it is in beta/user docs are not done.  As a general rule
you don't want to change timers--so that could be what it means too.

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 12:11 PM
To: 'Martin, Christian'; 'Jeffrey Haas'; Abarbanel, Benjamin
Cc: [e-mail]
Subject: RE: issue 40

Cisco says this is one of the unsupported BGP Router Configuration commands.
I dont know if they are in Beta test now, or plan to become obsolete?

Ben

> -----Original Message-----
> From: Martin, Christian [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 12:04 PM
> To: 'Jeffrey Haas'; Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: RE: issue 40
> 
> 
> Cisco
> 
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios12
> 1/121cgcr/ip_r
> /iprprt2/1rdbgp.htm#xtocid41
> 
>  !
>  router bgp x
>   neighbor x.x.x.x advertisement-interval <0-600>
>  !
> 
> -chris
> 
> >-----Original Message-----
> >From: Jeffrey Haas [mailto:[e-mail]] 
> >Sent: Wednesday, September 25, 2002 11:53 AM
> >To: Abarbanel, Benjamin
> >Cc: [e-mail]
> >Subject: Re: issue 40
> >
> >
> >On Wed, Sep 25, 2002 at 11:50:26AM -0400, Abarbanel, Benjamin wrote:
> >> The MinRouteAdvertisementInterval although maybe defined per peer 
> >> basis. Cisco IOS and other vendors, do not allow you to 
> configure it 
> >> at all, and
> >
> >GateD and Juniper: Outdelay.
> >(Note - I'm not aware of how Juniper may have caused this 
> >behavior to diverge from GateD's) Admittedly, its not a 
> >separate MAOI and MRAI value, but it lets you do the job.
> >
> >> Ben
> >
> >-- 
> >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 MAA09129 for <[e-mail]>; Wed, 25 Sep 2002 12:34:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B408C91235; Wed, 25 Sep 2002 12:34:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81D68912D3; Wed, 25 Sep 2002 12:34:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42E7391235 for <[e-mail]>; Wed, 25 Sep 2002 12:34:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2E8215DE54; Wed, 25 Sep 2002 12:34:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id E162F5DE4F for <[e-mail]>; Wed, 25 Sep 2002 12:34:14 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HP5B>; Wed, 25 Sep 2002 12:34:14 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 40
Date: Wed, 25 Sep 2002 12:34:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I think outdelay is different from MinRouteAdvertisementInterval, and is not
in the spec.  But I forget what it actually does.

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 12:07 PM
To: 'Jeffrey Haas'; Abarbanel, Benjamin
Cc: [e-mail]
Subject: RE: issue 40

The Juniper configuration allows you to configure outdelay on a all groups
level
(implying router level), individual group level, or individual peer level.
The
default is all groups level, I believe. 

Hence, I think the configuration parameter will be best served if it was
stated that it can be applied at all levels to cover all possibilities. 
I think other vendors used the Juniper way. Although, I have not seen a
Cisco
option (outdelay) for this. 

Regards,
Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 11:53 AM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: issue 40
> 
> 
> On Wed, Sep 25, 2002 at 11:50:26AM -0400, Abarbanel, Benjamin wrote:
> > The MinRouteAdvertisementInterval although maybe defined 
> per peer basis.
> > Cisco IOS and other vendors, do not allow you to configure 
> it at all, and
> 
> GateD and Juniper: Outdelay.
> (Note - I'm not aware of how Juniper may have caused this behavior
> to diverge from GateD's)
> Admittedly, its not a separate MAOI and MRAI value, but it lets
> you do the job.
> 
> > Ben
> 
> -- 
> 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 MAA08569 for <[e-mail]>; Wed, 25 Sep 2002 12:22:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9A264912D4; Wed, 25 Sep 2002 12:22:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65788912D3; Wed, 25 Sep 2002 12:22:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE324912D5 for <[e-mail]>; Wed, 25 Sep 2002 12:22:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C69AA5DE4B; Wed, 25 Sep 2002 12:22:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 3D6FD5DE4A for <[e-mail]>; Wed, 25 Sep 2002 12:22:13 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA04713; Wed, 25 Sep 2002 12:22:02 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA20525; Wed, 25 Sep 2002 12:21:57 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7HSTJ>; Wed, 25 Sep 2002 12:21:56 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Gargi Nalawade'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Martin, Christian'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: RE: issue 40
Date: Wed, 25 Sep 2002 12:21:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Here is the HTML page for this:

http://www.cisco.com/univercd/cc/td/doc/product/lan/c3550/12111ea1/3550scg/s
wuncli.htm

Look for:

"Unsupported BGP Router Configuration Commands"

Ben

> -----Original Message-----
> From: Gargi Nalawade [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 12:19 PM
> To: Abarbanel, Benjamin
> Cc: 'Martin, Christian'; 'Jeffrey Haas'; [e-mail]
> Subject: Re: issue 40
> 
> 
> Ben,
> 
> When, where does Cisco say that this command is unsupported? 
> Not that I know
> of ;) This command very much exists today and is supported.
> 
> -Gargi
> 
> "Abarbanel, Benjamin" wrote:
> > 
> > Cisco says this is one of the unsupported BGP Router 
> Configuration commands.
> > I dont know if they are in Beta test now, or plan to become 
> obsolete?
> > 
> > Ben
> > 
> > > -----Original Message-----
> > > From: Martin, Christian [mailto:[e-mail]]
> > > Sent: Wednesday, September 25, 2002 12:04 PM
> > > To: 'Jeffrey Haas'; Abarbanel, Benjamin
> > > Cc: [e-mail]
> > > Subject: RE: issue 40
> > >
> > >
> > > Cisco
> > >
> > > http://www.cisco.com/univercd/cc/td/doc/product/software/ios12
> > > 1/121cgcr/ip_r
> > > /iprprt2/1rdbgp.htm#xtocid41
> > >
> > >  !
> > >  router bgp x
> > >   neighbor x.x.x.x advertisement-interval <0-600>
> > >  !
> > >
> > > -chris
> > >
> > > >-----Original Message-----
> > > >From: Jeffrey Haas [mailto:[e-mail]]
> > > >Sent: Wednesday, September 25, 2002 11:53 AM
> > > >To: Abarbanel, Benjamin
> > > >Cc: [e-mail]
> > > >Subject: Re: issue 40
> > > >
> > > >
> > > >On Wed, Sep 25, 2002 at 11:50:26AM -0400, Abarbanel, 
> Benjamin wrote:
> > > >> The MinRouteAdvertisementInterval although maybe 
> defined per peer
> > > >> basis. Cisco IOS and other vendors, do not allow you to
> > > configure it
> > > >> at all, and
> > > >
> > > >GateD and Juniper: Outdelay.
> > > >(Note - I'm not aware of how Juniper may have caused this
> > > >behavior to diverge from GateD's) Admittedly, its not a
> > > >separate MAOI and MRAI value, but it lets you do the job.
> > > >
> > > >> Ben
> > > >
> > > >--
> > > >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 MAA08440 for <[e-mail]>; Wed, 25 Sep 2002 12:19:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9A189912D1; Wed, 25 Sep 2002 12:19:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B72C912D3; Wed, 25 Sep 2002 12:19:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0E96E912D1 for <[e-mail]>; Wed, 25 Sep 2002 12:19:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EDE395DE4D; Wed, 25 Sep 2002 12:19:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 79D7E5DE4B for <[e-mail]>; Wed, 25 Sep 2002 12:19:19 -0400 (EDT)
Received: from mira-sjcm-2.cisco.com (IDENT:[e-mail] [171.69.24.14]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8PGJ91X024684; Wed, 25 Sep 2002 09:19:09 -0700 (PDT)
Received: from cisco.com (dhcp-10-24-17-134.cisco.com [10.24.17.134]) by mira-sjcm-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAG47092; Wed, 25 Sep 2002 09:19:08 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 09:19:07 -0700
From: Gargi Nalawade <[e-mail]>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD   (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Martin, Christian'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: Re: issue 40
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Ben,

When, where does Cisco say that this command is unsupported? Not that I know
of ;) This command very much exists today and is supported.

-Gargi

"Abarbanel, Benjamin" wrote:
> 
> Cisco says this is one of the unsupported BGP Router Configuration commands.
> I dont know if they are in Beta test now, or plan to become obsolete?
> 
> Ben
> 
> > -----Original Message-----
> > From: Martin, Christian [mailto:[e-mail]]
> > Sent: Wednesday, September 25, 2002 12:04 PM
> > To: 'Jeffrey Haas'; Abarbanel, Benjamin
> > Cc: [e-mail]
> > Subject: RE: issue 40
> >
> >
> > Cisco
> >
> > http://www.cisco.com/univercd/cc/td/doc/product/software/ios12
> > 1/121cgcr/ip_r
> > /iprprt2/1rdbgp.htm#xtocid41
> >
> >  !
> >  router bgp x
> >   neighbor x.x.x.x advertisement-interval <0-600>
> >  !
> >
> > -chris
> >
> > >-----Original Message-----
> > >From: Jeffrey Haas [mailto:[e-mail]]
> > >Sent: Wednesday, September 25, 2002 11:53 AM
> > >To: Abarbanel, Benjamin
> > >Cc: [e-mail]
> > >Subject: Re: issue 40
> > >
> > >
> > >On Wed, Sep 25, 2002 at 11:50:26AM -0400, Abarbanel, Benjamin wrote:
> > >> The MinRouteAdvertisementInterval although maybe defined per peer
> > >> basis. Cisco IOS and other vendors, do not allow you to
> > configure it
> > >> at all, and
> > >
> > >GateD and Juniper: Outdelay.
> > >(Note - I'm not aware of how Juniper may have caused this
> > >behavior to diverge from GateD's) Admittedly, its not a
> > >separate MAOI and MRAI value, but it lets you do the job.
> > >
> > >> Ben
> > >
> > >--
> > >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 MAA08310 for <[e-mail]>; Wed, 25 Sep 2002 12:18:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 05EF7912D0; Wed, 25 Sep 2002 12:18:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8BD8912D4; Wed, 25 Sep 2002 12:18:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A0661912D3 for <[e-mail]>; Wed, 25 Sep 2002 12:17:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 882295DE4B; Wed, 25 Sep 2002 12:17:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id F093E5DE4A for <[e-mail]>; Wed, 25 Sep 2002 12:17:34 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PGHDm46132; Wed, 25 Sep 2002 09:17:13 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 55 
In-Reply-To: Your message of "Wed, 25 Sep 2002 11:58:11 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 09:17:13 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> On Wed, Sep 25, 2002 at 11:19:13AM -0400, Natale, Jonathan wrote:
> > "Path segment length is a 1-octet long field containing
> > the number of ASs (which is half the number of octets
> > since each AS is 2 octets) in the path segment value
> > field (also note that the path may contain more than 1
> > segment).
> 
> I prefer Yakov's text:
> 
> >    Path segment length is a 1-octet long field containing
> >    the number of ASs (but not the number of octets) in the path 
> >    segment value field.
> 
> with the clarification of deleting the word "but".

That would be fine.

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 MAA07949 for <[e-mail]>; Wed, 25 Sep 2002 12:11:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 52CE7912D2; Wed, 25 Sep 2002 12:10:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 086EF912D3; Wed, 25 Sep 2002 12:10:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 021CD912D0 for <[e-mail]>; Wed, 25 Sep 2002 12:10:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E1EF15DE4A; Wed, 25 Sep 2002 12:10:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 4A5345DE4C for <[e-mail]>; Wed, 25 Sep 2002 12:10:49 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA04170; Wed, 25 Sep 2002 12:10:47 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA18632; Wed, 25 Sep 2002 12:10:48 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7HSC7>; Wed, 25 Sep 2002 12:10:47 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Martin, Christian'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 40
Date: Wed, 25 Sep 2002 12:10:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Cisco says this is one of the unsupported BGP Router Configuration commands.
I dont know if they are in Beta test now, or plan to become obsolete?

Ben

> -----Original Message-----
> From: Martin, Christian [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 12:04 PM
> To: 'Jeffrey Haas'; Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: RE: issue 40
> 
> 
> Cisco
> 
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios12
> 1/121cgcr/ip_r
> /iprprt2/1rdbgp.htm#xtocid41
> 
>  !
>  router bgp x
>   neighbor x.x.x.x advertisement-interval <0-600>
>  !
> 
> -chris
> 
> >-----Original Message-----
> >From: Jeffrey Haas [mailto:[e-mail]] 
> >Sent: Wednesday, September 25, 2002 11:53 AM
> >To: Abarbanel, Benjamin
> >Cc: [e-mail]
> >Subject: Re: issue 40
> >
> >
> >On Wed, Sep 25, 2002 at 11:50:26AM -0400, Abarbanel, Benjamin wrote:
> >> The MinRouteAdvertisementInterval although maybe defined per peer 
> >> basis. Cisco IOS and other vendors, do not allow you to 
> configure it 
> >> at all, and
> >
> >GateD and Juniper: Outdelay.
> >(Note - I'm not aware of how Juniper may have caused this 
> >behavior to diverge from GateD's) Admittedly, its not a 
> >separate MAOI and MRAI value, but it lets you do the job.
> >
> >> Ben
> >
> >-- 
> >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 MAA07793 for <[e-mail]>; Wed, 25 Sep 2002 12:07:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CA166912CF; Wed, 25 Sep 2002 12:07:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B87B912D0; Wed, 25 Sep 2002 12:07:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B0418912CF for <[e-mail]>; Wed, 25 Sep 2002 12:07:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9CCF65DE4C; Wed, 25 Sep 2002 12:07:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 1CE845DE4A for <[e-mail]>; Wed, 25 Sep 2002 12:07:20 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA03903; Wed, 25 Sep 2002 12:07:12 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA17785; Wed, 25 Sep 2002 12:06:41 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7HR5X>; Wed, 25 Sep 2002 12:06:40 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 40
Date: Wed, 25 Sep 2002 12:06:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

The Juniper configuration allows you to configure outdelay on a all groups
level
(implying router level), individual group level, or individual peer level.
The
default is all groups level, I believe. 

Hence, I think the configuration parameter will be best served if it was
stated that it can be applied at all levels to cover all possibilities. 
I think other vendors used the Juniper way. Although, I have not seen a
Cisco
option (outdelay) for this. 

Regards,
Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 11:53 AM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: issue 40
> 
> 
> On Wed, Sep 25, 2002 at 11:50:26AM -0400, Abarbanel, Benjamin wrote:
> > The MinRouteAdvertisementInterval although maybe defined 
> per peer basis.
> > Cisco IOS and other vendors, do not allow you to configure 
> it at all, and
> 
> GateD and Juniper: Outdelay.
> (Note - I'm not aware of how Juniper may have caused this behavior
> to diverge from GateD's)
> Admittedly, its not a separate MAOI and MRAI value, but it lets
> you do the job.
> 
> > Ben
> 
> -- 
> 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 MAA07669 for <[e-mail]>; Wed, 25 Sep 2002 12:04:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DFFBB912B5; Wed, 25 Sep 2002 12:04:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD792912CF; Wed, 25 Sep 2002 12:04:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B7F0C912B5 for <[e-mail]>; Wed, 25 Sep 2002 12:04:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A3D4A5DE49; Wed, 25 Sep 2002 12:04:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by segue.merit.edu (Postfix) with ESMTP id 72C9A5DDFC for <[e-mail]>; Wed, 25 Sep 2002 12:04:15 -0400 (EDT)
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2656.59) id <TRPKP2Q6>; Wed, 25 Sep 2002 12:04:15 -0400
Message-ID: <[e-mail]>
From: "Martin, Christian" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 40
Date: Wed, 25 Sep 2002 12:04:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Cisco

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_r
/iprprt2/1rdbgp.htm#xtocid41

 !
 router bgp x
  neighbor x.x.x.x advertisement-interval <0-600>
 !

-chris

>-----Original Message-----
>From: Jeffrey Haas [mailto:[e-mail]] 
>Sent: Wednesday, September 25, 2002 11:53 AM
>To: Abarbanel, Benjamin
>Cc: [e-mail]
>Subject: Re: issue 40
>
>
>On Wed, Sep 25, 2002 at 11:50:26AM -0400, Abarbanel, Benjamin wrote:
>> The MinRouteAdvertisementInterval although maybe defined per peer 
>> basis. Cisco IOS and other vendors, do not allow you to configure it 
>> at all, and
>
>GateD and Juniper: Outdelay.
>(Note - I'm not aware of how Juniper may have caused this 
>behavior to diverge from GateD's) Admittedly, its not a 
>separate MAOI and MRAI value, but it lets you do the job.
>
>> Ben
>
>-- 
>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 LAA07338 for <[e-mail]>; Wed, 25 Sep 2002 11:58:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DDB6B912CE; Wed, 25 Sep 2002 11:58:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AAD0C912CF; Wed, 25 Sep 2002 11:58:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B912912CE for <[e-mail]>; Wed, 25 Sep 2002 11:58:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8A63F5DE49; Wed, 25 Sep 2002 11:58:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id B715B5DDFC for <[e-mail]>; Wed, 25 Sep 2002 11:58:15 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8PFwEa26508; Wed, 25 Sep 2002 11:58:14 -0400 (EDT) (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 g8PFwBG26501; Wed, 25 Sep 2002 11:58:11 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8PFwBe15604; Wed, 25 Sep 2002 11:58:11 -0400 (EDT)
Date: Wed, 25 Sep 2002 11:58:11 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 55
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 Wed, Sep 25, 2002 at 11:19:13AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 25, 2002 at 11:19:13AM -0400, Natale, Jonathan wrote:
> "Path segment length is a 1-octet long field containing
> the number of ASs (which is half the number of octets
> since each AS is 2 octets) in the path segment value
> field (also note that the path may contain more than 1
> segment).

I prefer Yakov's text:

>    Path segment length is a 1-octet long field containing
>    the number of ASs (but not the number of octets) in the path 
>    segment value field.

with the clarification of deleting the word "but".

-- 
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 LAA07161 for <[e-mail]>; Wed, 25 Sep 2002 11:54:30 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0A6F6912C9; Wed, 25 Sep 2002 11:54:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0091912CE; Wed, 25 Sep 2002 11:54:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA9F7912C9 for <[e-mail]>; Wed, 25 Sep 2002 11:54:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B82565DE44; Wed, 25 Sep 2002 11:54:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id E7C3B5DDFC for <[e-mail]>; Wed, 25 Sep 2002 11:54:00 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8PFrPb26396; Wed, 25 Sep 2002 11:53:25 -0400 (EDT) (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 g8PFrMG26389; Wed, 25 Sep 2002 11:53:22 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8PFrM215454; Wed, 25 Sep 2002 11:53:22 -0400 (EDT)
Date: Wed, 25 Sep 2002 11:53:22 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 40
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 Wed, Sep 25, 2002 at 11:50:26AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 25, 2002 at 11:50:26AM -0400, Abarbanel, Benjamin wrote:
> The MinRouteAdvertisementInterval although maybe defined per peer basis.
> Cisco IOS and other vendors, do not allow you to configure it at all, and

GateD and Juniper: Outdelay.
(Note - I'm not aware of how Juniper may have caused this behavior
to diverge from GateD's)
Admittedly, its not a separate MAOI and MRAI value, but it lets
you do the job.

> Ben

-- 
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 LAA07006 for <[e-mail]>; Wed, 25 Sep 2002 11:50:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 049B3912B8; Wed, 25 Sep 2002 11:50:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C81F3912C5; Wed, 25 Sep 2002 11:50:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D693C912B8 for <[e-mail]>; Wed, 25 Sep 2002 11:50:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C5DA05DE31; Wed, 25 Sep 2002 11:50:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 4F57B5DDFC for <[e-mail]>; Wed, 25 Sep 2002 11:50:30 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA02909 for <[e-mail]>; Wed, 25 Sep 2002 11:50:28 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14650 for <[e-mail]>; Wed, 25 Sep 2002 11:50:29 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7HQ94>; Wed, 25 Sep 2002 11:50:28 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: [e-mail]
Subject: RE: issue 40
Date: Wed, 25 Sep 2002 11:50:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

The MinRouteAdvertisementInterval although maybe defined per peer basis.
Cisco IOS and other vendors, do not allow you to configure it at all, and
therefore the default values are used. This in essence causes the parameter
to be applied on a BGP router/instance basis. Therefore, my original
conclusion was correct.

Ben

> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 11:13 AM
> To: [e-mail]
> Subject: RE: issue 39
> 
> 
> Disagree, the text if fine the way it is, except you need to change
> "shorted" to "shorter".
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Wednesday, September 25, 2002 10:55 AM
> To: [e-mail]
> Subject: issue 39
> 
>   39) Redundant Sentance Fragments
>  
> --------------------------------------------------------------
> --------------
>   Status: No Consensus
>   Change: Potentially
>   Summary: Redundant definitions, clarity requested.  
> Possible solution
> below.
>   
>   Discussion:
>   
>   5. P. 50, section 9.1.4, The two fragments of this sentence 
> are redundant
> 
>   and don't say anything new or simplify the content. Just keep one
> fragment.
>   
>   "A route describing a smaller set of destinations (a longer 
> prefix) is
> said
>   to be more specific than a route describing a larger set of 
> destinations
> (a
>   shorted prefix); similarly, a route describing a larger set of
> destinations
>   (a shorter prefix) is said to be less specific than a route 
> describing a
>   smaller set of destinations (a longer prefix)."
>   
>   There was a comment that disagreed, thinking that both 
> "more specific"
>   and "less specific" need to be defined.  And suggested that only the
>   third and forth parentheses need to be dropped.
>   
>   The original commentor agreed with the parentheses changes.
> 
> The third and forth parentheses will be dropped in the -18 version.
> 
> 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 LAA06634 for <[e-mail]>; Wed, 25 Sep 2002 11:43:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 73D11912BB; Wed, 25 Sep 2002 11:43:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 456C6912C2; Wed, 25 Sep 2002 11:43:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3D919912BB for <[e-mail]>; Wed, 25 Sep 2002 11:43:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 229785DE46; Wed, 25 Sep 2002 11:43:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 6B3325DE44 for <[e-mail]>; Wed, 25 Sep 2002 11:43:00 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8PFgwK25946; Wed, 25 Sep 2002 11:42:58 -0400 (EDT) (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 g8PFgrG25931; Wed, 25 Sep 2002 11:42:53 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8PFgrc15296; Wed, 25 Sep 2002 11:42:53 -0400 (EDT)
Date: Wed, 25 Sep 2002 11:42:53 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: your mail
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 Wed, Sep 25, 2002 at 10:27:33AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 25, 2002 at 10:27:33AM -0400, Jeffrey Haas wrote:
> Upon reading this further, 0x0e is correct for 2,3,4.  I made
> the mistake of thinking binary rather than hex as shown below.
> 
> My apologies.

And I'm batting zero this morning.
(No more bgp mail until after lunch... :-)

The comment in the MIB is quite plain about bit zero being the MSB of
the octet.

-- 
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 LAA06097 for <[e-mail]>; Wed, 25 Sep 2002 11:31:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E6BE3912B0; Wed, 25 Sep 2002 11:30:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8167912C4; Wed, 25 Sep 2002 11:30:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6D837912B0 for <[e-mail]>; Wed, 25 Sep 2002 11:30:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 512575DE41; Wed, 25 Sep 2002 11:30:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id B9D3A5DDB4 for <[e-mail]>; Wed, 25 Sep 2002 11:30:57 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PFUvm42226 for <[e-mail]>; Wed, 25 Sep 2002 08:30:57 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 11
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 08:30:57 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  11) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Variety of texts proposed to help clear up the rules for moving
   routes from Loc-RIB into Adj-RIB-Out.
  
  Discussion:
  
  The "Proxy: comments on section 9.1.3" thread brought up some lack of
  clarity in the section discussing the rules for which routes get propegated
  from the Loc-RIB into the Adj-RIB-Out.	These discussions resulted in
  a number of suggestions for new text.
  
  The first new text was proposed to clarify the issue that the thread
  first brought up:
  
  I agree that this could use some clarification. How about adding
  to b) in section 9.1:
  
    The Loc-RIB must contain only one route per destination; further, it
    must include all routes that the BGP speaker is using.
  
  changing c) in section 9.1.2 to:
  
    c) is selected as a result of the Phase 2 tie breaking rules specified
    in 9.1.2.2, or
  
  and adding
  
    d) when routing protocols other than BGP are in use, is determined by
    some other local means to be the route that will actually be used to
    reach a particular destination.
  
  This text was never discussed or a consensus formed on putting it in the
  document.
  
  This modification to 9.1.2 was also proposed to address the same concern:
  
  How about changing the paragraph after c) in 9.1.2 to:
  
    The local speaker SHALL then install that route in the Loc-RIB,
    replacing any route to the same destination that is currently being
    held in the Loc-RIB.	This route SHALL then also be installed in
    the BGP speakers forwarding table.
  
  There was one response in the negative to this change, arguing that is
  is not necessary.
  
Wrt "adding to b) in section 9.1", the second part (after ";") is
redundant as this point is already stated in 3.2. Wrt the first
point about Loc-RIB containing just one route per destination, I
would suggest to add it to section 3.2, where Loc-RIB is first
introduced, rather than adding it to 9.1.

Wrt "changing c)... and adding...", I have no objections to add/modify
the text, as suggested above.

I am not sure though that changing the paragraph after c) in 9.1.2
is really necessary though, so I would prefer to keep it as is. 

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 LAA05579 for <[e-mail]>; Wed, 25 Sep 2002 11:19:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8F0C4912BB; Wed, 25 Sep 2002 11:19:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B2C4912B0; Wed, 25 Sep 2002 11:19:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B7B9F912CF for <[e-mail]>; Wed, 25 Sep 2002 11:19:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 928D25DE43; Wed, 25 Sep 2002 11:19:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 165895DE42 for <[e-mail]>; Wed, 25 Sep 2002 11:19:14 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HPP3>; Wed, 25 Sep 2002 11:19:13 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: issue 55
Date: Wed, 25 Sep 2002 11:19:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

How about:
"Path segment length is a 1-octet long field containing
the number of ASs (which is half the number of octets
since each AS is 2 octets) in the path segment value
field (also note that the path may contain more than 1
segment).

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 11:05 AM
To: [e-mail]
Subject: issue 55

  55) Section 4.3 - Description of AS_PATH length
 
----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Should we clarify, such as adding an ASCII diagram, the
description
   of AS_PATH length?  No diagram or text has been proposed.
  
  Discussion:
  
  This question was raised:
  
  Length fields elsewhere in the draft specify the number of bytes that a
  variable length field uses.  For AS_PATH, length is used as the number
  of 2 byte AS numbers.  In the interest of not having to check other
  sources to be sure, should the descripton of path segment value:
  
  "The path segment value field contains one or more AS numbers, each
  encoded as a 2-octets long field."
  
  explicitly mention the number of bytes used by the variable length field?
  
  Or, make the description of length explicitly mention that it is not the
  length of the variable length field as is the case with other length
fields?
  
  One respone to this agreed that some more clarification would be good,
  specifically an ASCII art diagram.  No diagram was proposed.

How about replacing 

   Path segment length is a 1-octet long field containing
   the number of ASs in the path segment value field.

with the following

   Path segment length is a 1-octet long field containing
   the number of ASs (but not the number of octets) in the path 
   segment value field.

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 LAA05370 for <[e-mail]>; Wed, 25 Sep 2002 11:16:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D0BDD912B8; Wed, 25 Sep 2002 11:13:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 818E8912BB; Wed, 25 Sep 2002 11:13:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C391912B8 for <[e-mail]>; Wed, 25 Sep 2002 11:13:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0D8B45DE3D; Wed, 25 Sep 2002 11:13:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 4911A5DE3C for <[e-mail]>; Wed, 25 Sep 2002 11:13:11 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HP34>; Wed, 25 Sep 2002 11:13:10 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: issue 39
Date: Wed, 25 Sep 2002 11:13:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Disagree, the text if fine the way it is, except you need to change
"shorted" to "shorter".

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 10:55 AM
To: [e-mail]
Subject: issue 39

  39) Redundant Sentance Fragments
 
----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Redundant definitions, clarity requested.  Possible solution
below.
  
  Discussion:
  
  5. P. 50, section 9.1.4, The two fragments of this sentence are redundant

  and don't say anything new or simplify the content. Just keep one
fragment.
  
  "A route describing a smaller set of destinations (a longer prefix) is
said
  to be more specific than a route describing a larger set of destinations
(a
  shorted prefix); similarly, a route describing a larger set of
destinations
  (a shorter prefix) is said to be less specific than a route describing a
  smaller set of destinations (a longer prefix)."
  
  There was a comment that disagreed, thinking that both "more specific"
  and "less specific" need to be defined.  And suggested that only the
  third and forth parentheses need to be dropped.
  
  The original commentor agreed with the parentheses changes.

The third and forth parentheses will be dropped in the -18 version.

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 LAA04928 for <[e-mail]>; Wed, 25 Sep 2002 11:05:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2B0A1912B5; Wed, 25 Sep 2002 11:05:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0558912B6; Wed, 25 Sep 2002 11:05:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE11F912B5 for <[e-mail]>; Wed, 25 Sep 2002 11:05:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id AED405DDB4; Wed, 25 Sep 2002 11:05:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 1E6BA5DE31 for <[e-mail]>; Wed, 25 Sep 2002 11:05:17 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PF5Gm40457 for <[e-mail]>; Wed, 25 Sep 2002 08:05:16 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 55
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 08:05:16 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  55) Section 4.3 - Description of AS_PATH length
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Should we clarify, such as adding an ASCII diagram, the description
   of AS_PATH length?  No diagram or text has been proposed.
  
  Discussion:
  
  This question was raised:
  
  Length fields elsewhere in the draft specify the number of bytes that a
  variable length field uses.  For AS_PATH, length is used as the number
  of 2 byte AS numbers.  In the interest of not having to check other
  sources to be sure, should the descripton of path segment value:
  
  "The path segment value field contains one or more AS numbers, each
  encoded as a 2-octets long field."
  
  explicitly mention the number of bytes used by the variable length field?
  
  Or, make the description of length explicitly mention that it is not the
  length of the variable length field as is the case with other length fields?
  
  One respone to this agreed that some more clarification would be good,
  specifically an ASCII art diagram.  No diagram was proposed.

How about replacing 

   Path segment length is a 1-octet long field containing
   the number of ASs in the path segment value field.

with the following

   Path segment length is a 1-octet long field containing
   the number of ASs (but not the number of octets) in the path 
   segment value field.

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 LAA04887 for <[e-mail]>; Wed, 25 Sep 2002 11:04:58 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 89A6A912B0; Wed, 25 Sep 2002 11:04:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46F68912B5; Wed, 25 Sep 2002 11:04:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE371912B0 for <[e-mail]>; Wed, 25 Sep 2002 11:04:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D45DB5DE31; Wed, 25 Sep 2002 11:04:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 2E73F5DDB4 for <[e-mail]>; Wed, 25 Sep 2002 11:04:30 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HPM6>; Wed, 25 Sep 2002 11:04:29 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 31
Date: Wed, 25 Sep 2002 11:04:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

agreed

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 10:50 AM
To: [e-mail]
Subject: issue 31

  31) Add References to Additional Options
 
----------------------------------------------------------------------------
  Status: Consensus, but no text
  Change: Yes
  Summary: Consensus that we should add the references.  No text proposed.
  
  Discussion:
  
  2. P. 9, right after "This document defines the following optional
  parameters:"
  Need to mention possible options, such as: Capabilitites (RFC2842),
  Multiprotocol extensions (RFC2858), Route Refresh (RFC2918).
  
  One reponse agreed that adding references would be fine.
  A second reponse agreed.
  
Please note that only rfc2842 defines an OPEN optional parameter.
Neither rfc2858 nor rfc2918 defines an OPEN optional parameter.

With this in mind I would suggest to add the following text:

   [RFC2842] defines another Optional Parameter.

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 KAA04418 for <[e-mail]>; Wed, 25 Sep 2002 10:55:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 802B1912B0; Wed, 25 Sep 2002 10:54:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51C7D912B5; Wed, 25 Sep 2002 10:54:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 318D4912B0 for <[e-mail]>; Wed, 25 Sep 2002 10:54:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 17C065DE0D; Wed, 25 Sep 2002 10:54:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id A88025DDFC for <[e-mail]>; Wed, 25 Sep 2002 10:54:46 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PEskm39591 for <[e-mail]>; Wed, 25 Sep 2002 07:54:46 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 39
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 07:54:46 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  39) Redundant Sentance Fragments
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Redundant definitions, clarity requested.  Possible solution below.
  
  Discussion:
  
  5. P. 50, section 9.1.4, The two fragments of this sentence are redundant   
  and don't say anything new or simplify the content. Just keep one fragment.
  
  "A route describing a smaller set of destinations (a longer prefix) is said
  to be more specific than a route describing a larger set of destinations (a
  shorted prefix); similarly, a route describing a larger set of destinations
  (a shorter prefix) is said to be less specific than a route describing a
  smaller set of destinations (a longer prefix)."
  
  There was a comment that disagreed, thinking that both "more specific"
  and "less specific" need to be defined.  And suggested that only the
  third and forth parentheses need to be dropped.
  
  The original commentor agreed with the parentheses changes.

The third and forth parentheses will be dropped in the -18 version.

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 KAA04204 for <[e-mail]>; Wed, 25 Sep 2002 10:50:27 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7BB269122C; Wed, 25 Sep 2002 10:49:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 41627912B0; Wed, 25 Sep 2002 10:49:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 22ED19122C for <[e-mail]>; Wed, 25 Sep 2002 10:49:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F3B6D5DDFC; Wed, 25 Sep 2002 10:49:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 654285DDB4 for <[e-mail]>; Wed, 25 Sep 2002 10:49:47 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PEnlm39234 for <[e-mail]>; Wed, 25 Sep 2002 07:49:47 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 31
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 07:49:47 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  31) Add References to Additional Options
  ----------------------------------------------------------------------------
  Status: Consensus, but no text
  Change: Yes
  Summary: Consensus that we should add the references.  No text proposed.
  
  Discussion:
  
  2. P. 9, right after "This document defines the following optional
  parameters:"
  Need to mention possible options, such as: Capabilitites (RFC2842),
  Multiprotocol extensions (RFC2858), Route Refresh (RFC2918).
  
  One reponse agreed that adding references would be fine.
  A second reponse agreed.
  
Please note that only rfc2842 defines an OPEN optional parameter.
Neither rfc2858 nor rfc2918 defines an OPEN optional parameter.

With this in mind I would suggest to add the following text:

   [RFC2842] defines another Optional Parameter.

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 KAA03550 for <[e-mail]>; Wed, 25 Sep 2002 10:36:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 71800912B0; Wed, 25 Sep 2002 10:35:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3AF51912B4; Wed, 25 Sep 2002 10:35:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 16B8E912B0 for <[e-mail]>; Wed, 25 Sep 2002 10:35:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 058695DE35; Wed, 25 Sep 2002 10:35:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 9B58C5DE20 for <[e-mail]>; Wed, 25 Sep 2002 10:35:57 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PEZum38233; Wed, 25 Sep 2002 07:35:56 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 33 
In-Reply-To: Your message of "Wed, 25 Sep 2002 10:18:42 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 07:35:56 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> 5.1.3 NEXT_HOP also, it is missing " well-known mandatory".

Agreed. Will be fixed in -18.

yakov.
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Wednesday, September 25, 2002 9:25 AM
> To: [e-mail]
> Subject: issue 33
> 
>   33) Add "Optional Non-Transitive" to the MED Section
>  
> ----------------------------------------------------------------------------
>   Status: No Consensus
>   Change: Potentially
>   Summary: Do we add this text, or no?
>   
>   Discussion:
>   
>   4. P.23, change the following:
>   
>   "The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
>    links to discriminate among multiple exit or entry points to the same
>    neighboring AS ..."
>   
>    To the following:
>   
>   "The MULTI_EXIT_DISC is an optional non-transitive attribute which may be
>   used on external (inter-AS) links to discriminate among multiple exit or
>   entry points to the same neighboring AS ..."
> 
> The change is 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 KAA03220 for <[e-mail]>; Wed, 25 Sep 2002 10:29:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A6E5D912BB; Wed, 25 Sep 2002 10:29:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C4C7912C4; Wed, 25 Sep 2002 10:29:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 31B54912BB for <[e-mail]>; Wed, 25 Sep 2002 10:29:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 182715DE31; Wed, 25 Sep 2002 10:29:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 9C14F5DE20 for <[e-mail]>; Wed, 25 Sep 2002 10:29:17 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HPGB>; Wed, 25 Sep 2002 10:29:17 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: BGP - IGP Redistribution Issue
Date: Wed, 25 Sep 2002 10:29:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Agreed, it is out of scope.  Could be in a BCP--most folks turn this feature
off, right?

-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 10:23 AM
To: Manav Bhatia
Cc: [e-mail]
Subject: Re: BGP - IGP Redistribution Issue

On Wed, Sep 25, 2002 at 10:08:50AM +0530, Manav Bhatia wrote:
> - Bringing down all the EBGP connections immediately when the interface
> over which they run goes down (without waiting for the HoldTimer to
> expire!).

If your interface hiccups once due to a framing error on your
circuit that causes a flap, do you really want to bring it down?

This can be addressed out of scope from the BGP document by
having the local TCP stack be aware of sessions over a given
interface and decreasing the session timeouts when the interface
goes down.  This means you shouldn't have to wait for the full
length of time for the session to go down.

-- 
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 KAA03193 for <[e-mail]>; Wed, 25 Sep 2002 10:28:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 77861912BE; Wed, 25 Sep 2002 10:28:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D2E8912BB; Wed, 25 Sep 2002 10:28:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EEDFE912BE for <[e-mail]>; Wed, 25 Sep 2002 10:28:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D0C185DE35; Wed, 25 Sep 2002 10:28:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 5B4925DE36 for <[e-mail]>; Wed, 25 Sep 2002 10:28:34 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26412; Wed, 25 Sep 2002 10:28:31 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23864; Wed, 25 Sep 2002 10:28:32 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7HLNG>; Wed, 25 Sep 2002 10:28:31 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, Manav Bhatia <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, "'Alexei Roudnev'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: RE: BGP - IGP Redistribution Issue 
Date: Wed, 25 Sep 2002 10:28:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov, 

  Well do. I think these new discussions are interesting. Can you we proceed
on
some other list that you can recommend?

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 8:40 AM
> To: Manav Bhatia
> Cc: Abarbanel, Benjamin; 'Alexei Roudnev'; 'Jeffrey Haas'; 
> [e-mail]
> Subject: Re: BGP - IGP Redistribution Issue 
> 
> 
> Manav,
> 
> > some more things which could be pondered upon.
> > 
> > - Bringing down all the EBGP connections immediately when 
> the interface
> > over which they run goes down (without waiting for the HoldTimer to
> > expire!).
> > 
> > - router id [hope am not opening a can of worms :-)]
> 
> We've been through this discussion before... 
> 
> > - A discussion on multiple views/instances/processes of BGP 
> (many ISPs are
> > using it) and their possible interaction amongst themselves/IGPs.
> 
> outside the scope of the base spec. 
> 
> > - Using communities
> 
> Ditto.
> 
> > - Limited interaction with IGPs
> 
> Ditto.
> 
> > - Hierarchical peering using Route Reflectors
> 
> Ditto (although may be well within the scope of the Route 
> Reflectors spec).
> 
> Yakov.
> 
> P.S. Folks, the WG chairs would reallly appreciate if (at 
> least for now)
> we stay focused on discussing just the *base* spec, and defering
> issues that do not belong to the base spec till some later point...
> 
> > 
> > Manav
> > ----- Original Message -----
> > From: "Abarbanel, Benjamin" <[e-mail]>
> > To: "'Alexei Roudnev'" <[e-mail]>; "Abarbanel, Benjamin"
> > <[e-mail]>; "'Jeffrey Haas'" 
> <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Tuesday, September 24, 2002 9:53 PM
> > Subject: RE: BGP - IGP Redistribution Issue
> > 
> > 
> > | Agreed, are there other "good practice" issues that can 
> be added to this
> > | spec?
> > |
> > | Ben
> > |
> > | > -----Original Message-----
> > | > From: Alexei Roudnev [mailto:[e-mail]]
> > | > Sent: Tuesday, September 24, 2002 12:11 PM
> > | > To: Abarbanel, Benjamin; 'Jeffrey Haas'
> > | > Cc: [e-mail]
> > | > Subject: Re: BGP - IGP Redistribution Issue
> > | >
> > | >
> > | > > > As much as I would really like to incorporate some of the
> > | > best current
> > | > > > practices that network operators have in operating 
> BGP networks in
> > | > > > a 1772 replacement, we shouldn't try to reproduce 
> works such as
> > | > > > Halabi's book in a RFC.
> > | > > >
> > | > >
> > | > > I thought Halabi's book was derived from IETF Specs 
> and Cisco field
> > | > > experience.
> > | > It was re-written 2 years ago, without sugnificant changes.
> > | >
> > | > Anyway, it is a good idea to have some statement preventing
> > | > people from bad
> > | > practices (such as injecting bgp routes into IGP, even in
> > | > small network).
> > | >
> > | >
> > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA03158 for <[e-mail]>; Wed, 25 Sep 2002 10:28:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5A37C912C2; Wed, 25 Sep 2002 10:27:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F7D9912BE; Wed, 25 Sep 2002 10:27:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76E67912C4 for <[e-mail]>; Wed, 25 Sep 2002 10:27:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 598FC5DE31; Wed, 25 Sep 2002 10:27:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id A65835DE35 for <[e-mail]>; Wed, 25 Sep 2002 10:27:38 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8PERav23310; Wed, 25 Sep 2002 10:27:36 -0400 (EDT) (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 g8PERXG23301; Wed, 25 Sep 2002 10:27:33 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8PERXY14217; Wed, 25 Sep 2002 10:27:33 -0400 (EDT)
Date: Wed, 25 Sep 2002 10:27:33 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: your mail
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, Sep 24, 2002 at 05:58:55PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Sep 24, 2002 at 05:58:55PM -0400, Natale, Jonathan wrote:
> Thanks for the prompt reply.  A major vendor sets it to 0x0E for v2,3,4.
> Another vendor sets it to 0x10 for v1.  These are 2 other ways to interpret
> this (both incorrect).  Interesting.

Upon reading this further, 0x0e is correct for 2,3,4.  I made
the mistake of thinking binary rather than hex as shown below.

My apologies.

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]] 
> Sent: Tuesday, September 24, 2002 5:46 PM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: your mail
> 
> On Tue, Sep 24, 2002 at 05:38:52PM -0400, Natale, Jonathan wrote:
> > The way I read the bgpVersion SNMP object description, it should be set to
> > 0x7000 if you support versions 2, 3, and 4; 0x1000 if you support version
> 4.
> > Is this correct?
> 
> According to the MIB, yes.
> 
> > Thank you.
> 
> -- 
> Jeff Haas 
> NextHop Technologies
> 

-- 
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 KAA03124 for <[e-mail]>; Wed, 25 Sep 2002 10:27:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1D93F912BD; Wed, 25 Sep 2002 10:27:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB3C4912BE; Wed, 25 Sep 2002 10:27:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CF488912BD for <[e-mail]>; Wed, 25 Sep 2002 10:27:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B4CF65DE32; Wed, 25 Sep 2002 10:27:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 3E9D95DE31 for <[e-mail]>; Wed, 25 Sep 2002 10:27:14 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26302; Wed, 25 Sep 2002 10:27:11 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23560; Wed, 25 Sep 2002 10:27:12 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7HLK4>; Wed, 25 Sep 2002 10:27:11 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, Mareline Sheldon <[e-mail]>
Cc: Misha Dovek <[e-mail]>, [e-mail], "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: RE: BGP - IGP Redistribution Issue 
Date: Wed, 25 Sep 2002 10:27:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov, 

This thread was created for new work on other specs. I am sorry if we are
confusing you. Is it OK to discuss these topics on the list at this time?

Regards,
Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 25, 2002 8:37 AM
> To: Mareline Sheldon
> Cc: Misha Dovek; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: BGP - IGP Redistribution Issue 
> 
> 
> Mareline,
> 
> > Misha,
> > 
> > > |
> > > | - A discussion on multiple views/instances/processes of 
> BGP (many ISPs ar
> e
> > > | using it) and their possible interaction amongst 
> themselves/IGPs.
> > > 
> > > That *might* prove interesting.
> > 
> > my votes on this too.
> 
> This seems to be clearly outside the scope of the *base* 
> spec. And what we 
> are discussing right now is the base spec.
> 
> > 
> > > 
> > > |
> > > | - Limited interaction with IGPs
> > > 
> > > Why limited? I gathered that redistributing BGP info into 
> IGP is a strict N
> o
> > > No!
> > 
> > interaction with IGP does not necessarily mean redistributing routes
> > to and f ro the IGPs.  There are other ways also by which BGP could
> > interact with the IGPs e.g. Traffic Engineering
> 
> The interaction with IGP (including interaction with TE) is outside
> the scope of the base spec. 
> 
> Yakov.
> 
> > 
> > mareline s.
> > 
> > > 
> > > |
> > > | - Hierarchical peering using Route Reflectors
> > > 
> > > Yes, i am aware of certain ISPs doing that.
> > > 
> > > Misha
> > > 
> > 
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > New DSL Internet Access from SBC & Yahoo!
> > http://sbc.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 KAA03075 for <[e-mail]>; Wed, 25 Sep 2002 10:26:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7DE39912C0; Wed, 25 Sep 2002 10:26:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 350F4912BD; Wed, 25 Sep 2002 10:26:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 308BE912C0 for <[e-mail]>; Wed, 25 Sep 2002 10:26:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1AAD95DE35; Wed, 25 Sep 2002 10:26:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id A0DD35DE36 for <[e-mail]>; Wed, 25 Sep 2002 10:26:04 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HPFR>; Wed, 25 Sep 2002 10:26:04 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: issue 44
Date: Wed, 25 Sep 2002 10:26:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I agree.
(maybe an unrecognized capability could be ignored, but this is out of
scope)

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 10:18 AM
To: [e-mail]
Subject: issue 44

  44) Section 6.2: OPEN message error handling
 
----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: One commentor observed that the spec seems to specify behavior
    that doesn't seem to be observed by extant implementations, and
suggested
    modifications to the spec.  There is no consensus as to if this
observation
    holds across implementations, or if it does, if we should change the
spec.
  
  Discussion:   
  
  The "BGP4 draft ; section 6.2" thread began with a discussion of
  section 6.2: OPEN message error handling.  Specifically:
  
  "If one of the optional parameters in the Open mesage is not recognized,
  then the error subcode is set to 'unsupported optional parameters"
  
  We have hit on this line when we were testing a BGP connection between
  a speaker that supported capability negotiation and a speaker that did
  not.
  
  The speaker that did not support the neogotiation closed down the peering

  session using the error clause mentioned above. Sometimes this lead
  to the other router to repeat the OPEN message with the Capability
optional
  parameter; a game that went on for minutes.
  
  This router manufacturer stated in a reply to this that :
  "One should not close down the connection if an optional parameter
  is unrecognised. That would make this parameter basically mandatory.
  This is an well known error in the BGP spec. Neither Cisco or Juniper
  do this"
  
  If this is true it might be good to adapt the text.
  
  The response to this quoted RFC2842, Capabilities Advertisement with
BGP-4:
  
     A BGP speaker determines that its peer doesn't support capabilities
     advertisement, if in response to an OPEN message that carries the
     Capabilities Optional Parameter, the speaker receives a NOTIFICATION
     message with the Error Subcode set to Unsupported Optional Parameter.
     In this case the speaker should attempt to re-establish a BGP
     connection with the peer without sending to the peer the Capabilities
     Optional Parameter.
  
RFC2842 assumes that a router (that doesn't implement RFC2842)
would close the BGP session when the router receives an OPEN message
with an unrecognized Optional Parameter. Therefore the text in the
spec should be left unmodified.

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 KAA03065 for <[e-mail]>; Wed, 25 Sep 2002 10:26:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 46B40912BB; Wed, 25 Sep 2002 10:23:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15BBF912BD; Wed, 25 Sep 2002 10:23:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BF525912BB for <[e-mail]>; Wed, 25 Sep 2002 10:23:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A26A75DE32; Wed, 25 Sep 2002 10:23:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id BA1105DE31 for <[e-mail]>; Wed, 25 Sep 2002 10:23:17 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8PENDu23143; Wed, 25 Sep 2002 10:23:13 -0400 (EDT) (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 g8PENAG23136; Wed, 25 Sep 2002 10:23:10 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8PEN9t14185; Wed, 25 Sep 2002 10:23:09 -0400 (EDT)
Date: Wed, 25 Sep 2002 10:23:09 -0400
From: Jeffrey Haas <[e-mail]>
To: Manav Bhatia <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP - IGP Redistribution Issue
Message-ID: <[e-mail]>
References: <[e-mail]> <010a01c2644d$72ecdbe0$[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: <010a01c2644d$72ecdbe0$[e-mail]>; from [e-mail] on Wed, Sep 25, 2002 at 10:08:50AM +0530
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 25, 2002 at 10:08:50AM +0530, Manav Bhatia wrote:
> - Bringing down all the EBGP connections immediately when the interface
> over which they run goes down (without waiting for the HoldTimer to
> expire!).

If your interface hiccups once due to a framing error on your
circuit that causes a flap, do you really want to bring it down?

This can be addressed out of scope from the BGP document by
having the local TCP stack be aware of sessions over a given
interface and decreasing the session timeouts when the interface
goes down.  This means you shouldn't have to wait for the full
length of time for the session to go down.

-- 
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 KAA02791 for <[e-mail]>; Wed, 25 Sep 2002 10:20:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 93B07912B6; Wed, 25 Sep 2002 10:19:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F3CC912BA; Wed, 25 Sep 2002 10:19:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 28A65912B6 for <[e-mail]>; Wed, 25 Sep 2002 10:19:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0F4575DE31; Wed, 25 Sep 2002 10:19:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 91DCB5DE20 for <[e-mail]>; Wed, 25 Sep 2002 10:19:54 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HP12>; Wed, 25 Sep 2002 10:19:54 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 36
Date: Wed, 25 Sep 2002 10:19:53 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Agreed.
--obviously these definitions will need to be reviewed (yikes!)

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 9:28 AM
To: [e-mail]
Subject: issue 36

  36) Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary
 
----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: This change requires a glossary. No Glossary text has been
    proposed.
   
  Discussion:
   
  2. Section 9.1, Need to have Adj-RIB-In, Adj-RIB-Out, and Loc-RIB in the
  glossary, so when they are used in section 9.1, it is well understood what
  they are.

will be added to the section "Definition of commonly used terms" in -18
version.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA02741 for <[e-mail]>; Wed, 25 Sep 2002 10:19:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9610A91226; Wed, 25 Sep 2002 10:18:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1292912B6; Wed, 25 Sep 2002 10:18:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8219491226 for <[e-mail]>; Wed, 25 Sep 2002 10:18:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 675C45DE31; Wed, 25 Sep 2002 10:18:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id CB94B5DE20 for <[e-mail]>; Wed, 25 Sep 2002 10:18:43 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HP1A>; Wed, 25 Sep 2002 10:18:43 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 33
Date: Wed, 25 Sep 2002 10:18:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

5.1.3 NEXT_HOP also, it is missing " well-known mandatory".

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 9:25 AM
To: [e-mail]
Subject: issue 33

  33) Add "Optional Non-Transitive" to the MED Section
 
----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Do we add this text, or no?
  
  Discussion:
  
  4. P.23, change the following:
  
  "The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
   links to discriminate among multiple exit or entry points to the same
   neighboring AS ..."
  
   To the following:
  
  "The MULTI_EXIT_DISC is an optional non-transitive attribute which may be
  used on external (inter-AS) links to discriminate among multiple exit or
  entry points to the same neighboring AS ..."

The change is 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 KAA02714 for <[e-mail]>; Wed, 25 Sep 2002 10:18:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DB0D5912A9; Wed, 25 Sep 2002 10:18:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A899D91226; Wed, 25 Sep 2002 10:18:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B0E9912A9 for <[e-mail]>; Wed, 25 Sep 2002 10:17:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7DFA45DE34; Wed, 25 Sep 2002 10:17:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 1DDCB5DE31 for <[e-mail]>; Wed, 25 Sep 2002 10:17:36 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PEHZm37214 for <[e-mail]>; Wed, 25 Sep 2002 07:17:35 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 44
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 07:17:35 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  44) Section 6.2: OPEN message error handling
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: One commentor observed that the spec seems to specify behavior
    that doesn't seem to be observed by extant implementations, and suggested
    modifications to the spec.  There is no consensus as to if this observation
    holds across implementations, or if it does, if we should change the spec.
  
  Discussion:   
  
  The "BGP4 draft ; section 6.2" thread began with a discussion of
  section 6.2: OPEN message error handling.  Specifically:
  
  "If one of the optional parameters in the Open mesage is not recognized,
  then the error subcode is set to 'unsupported optional parameters"
  
  We have hit on this line when we were testing a BGP connection between
  a speaker that supported capability negotiation and a speaker that did
  not.
  
  The speaker that did not support the neogotiation closed down the peering   
  session using the error clause mentioned above. Sometimes this lead
  to the other router to repeat the OPEN message with the Capability optional
  parameter; a game that went on for minutes.
  
  This router manufacturer stated in a reply to this that :
  "One should not close down the connection if an optional parameter
  is unrecognised. That would make this parameter basically mandatory.
  This is an well known error in the BGP spec. Neither Cisco or Juniper
  do this"
  
  If this is true it might be good to adapt the text.
  
  The response to this quoted RFC2842, Capabilities Advertisement with BGP-4:
  
     A BGP speaker determines that its peer doesn't support capabilities
     advertisement, if in response to an OPEN message that carries the
     Capabilities Optional Parameter, the speaker receives a NOTIFICATION
     message with the Error Subcode set to Unsupported Optional Parameter.
     In this case the speaker should attempt to re-establish a BGP
     connection with the peer without sending to the peer the Capabilities
     Optional Parameter.
  
RFC2842 assumes that a router (that doesn't implement RFC2842)
would close the BGP session when the router receives an OPEN message
with an unrecognized Optional Parameter. Therefore the text in the
spec should be left unmodified.

Yakov.


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 KAA02163 for <[e-mail]>; Wed, 25 Sep 2002 10:10:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A6EE4912B5; Wed, 25 Sep 2002 10:09:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 72391912B9; Wed, 25 Sep 2002 10:09:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 29305912B5 for <[e-mail]>; Wed, 25 Sep 2002 10:09:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1A24D5DE2D; Wed, 25 Sep 2002 10:09:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 8EDFC5DE20 for <[e-mail]>; Wed, 25 Sep 2002 10:09:41 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HPCJ>; Wed, 25 Sep 2002 10:09:41 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: issue 29
Date: Wed, 25 Sep 2002 10:09:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

-----Original Message-----
From: Natale, Jonathan 
Sent: Wednesday, September 25, 2002 9:11 AM
To: 'Yakov Rekhter'
Subject: RE: issue 29

I agree.

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Tuesday, September 24, 2002 10:58 PM
To: [e-mail]
Subject: issue 29

  29) State Why Unresolveable Routes Should Be Kept in Adj-RIB-In
 
----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary:  Explicity state that there is a chance routes can become 
    resolveable, and should therefore be kept in Adj-RIB-In.  No text  
    has yet been suggested.
  
  Discussion:
  
   5. P.46, last sentence, "However, corresponding unresolvable routes
SHOULD 
   be kept in the Adj-RIBs-In."  It would helpful if the author states why
   unresolvable routes should be kept in Adj-RIBs-In?
  
   A reponse to this stated "In case they become resolveable"
  
I suggest we add "in case they become resolvable" after the last sentence
on p. 46.

   The original commentor stated that:
   Then the point that the peer will not refresh the route if we drop
   them (unless we use Route Refresh) because they are unreachable should be
   made.

This should be clear from the following text in Section 3:

   The initial data flow is the portion of the BGP routing table that
   is allowed by the export policy, called the Adj-Ribs-Out (see 3.2).
   Incremental updates are sent as the routing tables change. BGP does
   not require periodic refresh of the routing table. 

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 KAA02155 for <[e-mail]>; Wed, 25 Sep 2002 10:10:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F3859912BA; Wed, 25 Sep 2002 10:09:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B69C8912B9; Wed, 25 Sep 2002 10:09:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 33EE2912BA for <[e-mail]>; Wed, 25 Sep 2002 10:09:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1F4C85DE2D; Wed, 25 Sep 2002 10:09:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 903B15DE20 for <[e-mail]>; Wed, 25 Sep 2002 10:09:51 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HPCL>; Wed, 25 Sep 2002 10:09:51 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: issue 8
Date: Wed, 25 Sep 2002 10:09:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

-----Original Message-----
From: Natale, Jonathan 
Sent: Wednesday, September 25, 2002 9:10 AM
To: 'Yakov Rekhter'
Subject: RE: issue 8

I agree.

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Tuesday, September 24, 2002 9:38 PM
To: [e-mail]
Subject: issue 8

   8) Jitter Text
 
----------------------------------------------------------------------------
   Status: No Consensus
   Change: Potentially 
   Summary:
    Change:
     "jitter should be applied to the
      timers associated with MinASOriginationInterval, Keepalive, and
      MinRouteAdvertisementInterval"
    To:
     "jitter should be applied to the timers associated with ConnectRetry
timer"
   
   Discussion:
   
   In the tread entitled "bgp draft review":
   The thread also proposed:
   
   "jitter should be applied to the
      timers associated with MinASOriginationInterval, Keepalive, and
      MinRouteAdvertisementInterval"
   
   Be changed to:
   
   "jitter should be applied to the
      timers associated with ConnectRetry timer"
   
   - There was limited discussion on this issue.  Implementions will
   add jitter to all of these.  There is no consensus on changing this
   text.

I would suggest that we'll change the text to make sure that jitter
is applied to all the timers. To make this change I would suggest
to get rid of section 9.2.1.3 ("Jitter"), move the text of this
section into Appendix "BGP Timers", and expand the text to indicate
that jitter applies to ConnectRetry timer as well.

Yakov.


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 KAA02112 for <[e-mail]>; Wed, 25 Sep 2002 10:09:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CC448912B4; Wed, 25 Sep 2002 10:09:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9581A912B5; Wed, 25 Sep 2002 10:09:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 60FE9912B4 for <[e-mail]>; Wed, 25 Sep 2002 10:09:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 48CC35DE2D; Wed, 25 Sep 2002 10:09:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id ADFFD5DE20 for <[e-mail]>; Wed, 25 Sep 2002 10:09:06 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HPCD>; Wed, 25 Sep 2002 10:09:06 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: issue 17
Date: Wed, 25 Sep 2002 10:09:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

-----Original Message-----
From: Natale, Jonathan 
Sent: Wednesday, September 25, 2002 10:08 AM
To: 'Yakov Rekhter'
Subject: RE: issue 17

agreed

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 8:53 AM
To: [e-mail]
Subject: issue 17

   17) Add References to other RFC-status BGP docs to base spec.
 
----------------------------------------------------------------------------
   Status: No Consensus
   Change: Potentially
   Summary: Add references to other RFC-status BGP docs to the base spec.
        
   Discussion:
   
   The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread then changes
   titles to: "Review of draft-ietf-idr-bgp4-17.txt" and goes on to
   suggest:
   
   3. All BGP Extensions described in other documents that made it to RFC
   status should be at least referenced in the Reference section P.64. This
is
   justifiable since it's the core BGP standard spec.

Will be added to -18 version.

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 KAA02102 for <[e-mail]>; Wed, 25 Sep 2002 10:09:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D2872912B8; Wed, 25 Sep 2002 10:09:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B7B4912B9; Wed, 25 Sep 2002 10:09:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 54DFD912B8 for <[e-mail]>; Wed, 25 Sep 2002 10:09:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4456A5DE2D; Wed, 25 Sep 2002 10:09:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 9F7775DE20 for <[e-mail]>; Wed, 25 Sep 2002 10:09:17 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HPCG>; Wed, 25 Sep 2002 10:09:17 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: FW: issue 9
Date: Wed, 25 Sep 2002 10:09:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

-----Original Message-----
From: Natale, Jonathan 
Sent: Wednesday, September 25, 2002 10:07 AM
To: 'Yakov Rekhter'
Subject: RE: issue 9

agreed

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 8:49 AM
To: [e-mail]
Subject: issue 9

   9) Reference to RFC904 - EGP Protocol
 
----------------------------------------------------------------------------
   Status: No Consensus
   Change: Potentially
   Summary: Add a reference to RFC904
   
   Discussion:
   
   The "Review Comment: Origin Attribute pg 14" thread suggested adding a
   reference to RFC904(?), to refer to the EGP protocol.  There was no
   discussion.

I'll add reference to [RFC904].

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 KAA01976 for <[e-mail]>; Wed, 25 Sep 2002 10:06:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E0646912B2; Wed, 25 Sep 2002 10:06:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1FF6912B4; Wed, 25 Sep 2002 10:06:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 61116912B2 for <[e-mail]>; Wed, 25 Sep 2002 10:06:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 45C955DE2D; Wed, 25 Sep 2002 10:06:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id AC9755DE2A for <[e-mail]>; Wed, 25 Sep 2002 10:06:16 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HPBP>; Wed, 25 Sep 2002 10:06:16 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: BGP - IGP Redistribution Issue 
Date: Wed, 25 Sep 2002 10:06:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I agree all are out of scope, EXCEPT id:
1) requiring id to be local addr should be removed
2) dis-allowing id to be set to martian should be added
3) allowing peers to have martian id should be added
4) RECOMENDING that id equal IGP's id should be added


-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 8:40 AM
To: Manav Bhatia
Cc: Abarbanel, Benjamin; 'Alexei Roudnev'; 'Jeffrey Haas'; [e-mail]
Subject: Re: BGP - IGP Redistribution Issue 

Manav,

> some more things which could be pondered upon.
> 
> - Bringing down all the EBGP connections immediately when the interface
> over which they run goes down (without waiting for the HoldTimer to
> expire!).
> 
> - router id [hope am not opening a can of worms :-)]

We've been through this discussion before... 

> - A discussion on multiple views/instances/processes of BGP (many ISPs are
> using it) and their possible interaction amongst themselves/IGPs.

outside the scope of the base spec. 

> - Using communities

Ditto.

> - Limited interaction with IGPs

Ditto.

> - Hierarchical peering using Route Reflectors

Ditto (although may be well within the scope of the Route Reflectors spec).

Yakov.

P.S. Folks, the WG chairs would reallly appreciate if (at least for now)
we stay focused on discussing just the *base* spec, and defering
issues that do not belong to the base spec till some later point...

> 
> Manav
> ----- Original Message -----
> From: "Abarbanel, Benjamin" <[e-mail]>
> To: "'Alexei Roudnev'" <[e-mail]>; "Abarbanel, Benjamin"
> <[e-mail]>; "'Jeffrey Haas'" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Tuesday, September 24, 2002 9:53 PM
> Subject: RE: BGP - IGP Redistribution Issue
> 
> 
> | Agreed, are there other "good practice" issues that can be added to this
> | spec?
> |
> | Ben
> |
> | > -----Original Message-----
> | > From: Alexei Roudnev [mailto:[e-mail]]
> | > Sent: Tuesday, September 24, 2002 12:11 PM
> | > To: Abarbanel, Benjamin; 'Jeffrey Haas'
> | > Cc: [e-mail]
> | > Subject: Re: BGP - IGP Redistribution Issue
> | >
> | >
> | > > > As much as I would really like to incorporate some of the
> | > best current
> | > > > practices that network operators have in operating BGP networks in
> | > > > a 1772 replacement, we shouldn't try to reproduce works such as
> | > > > Halabi's book in a RFC.
> | > > >
> | > >
> | > > I thought Halabi's book was derived from IETF Specs and Cisco field
> | > > experience.
> | > It was re-written 2 years ago, without sugnificant changes.
> | >
> | > Anyway, it is a good idea to have some statement preventing
> | > people from bad
> | > practices (such as injecting bgp routes into IGP, even in
> | > small network).
> | >
> | >
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA01679 for <[e-mail]>; Wed, 25 Sep 2002 09:58:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3B223912B0; Wed, 25 Sep 2002 09:58:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00905912B2; Wed, 25 Sep 2002 09:58:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A3C4A912B0 for <[e-mail]>; Wed, 25 Sep 2002 09:58:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8871E5DE27; Wed, 25 Sep 2002 09:58:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id E33DD5DE20 for <[e-mail]>; Wed, 25 Sep 2002 09:58:02 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HPAD>; Wed, 25 Sep 2002 09:58:02 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, Mareline Sheldon <[e-mail]>
Cc: Misha Dovek <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: RE: BGP - IGP Redistribution Issue 
Date: Wed, 25 Sep 2002 09:58:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I agree, both are out of scope.

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 25, 2002 8:37 AM
To: Mareline Sheldon
Cc: Misha Dovek; [e-mail]; [e-mail];
[e-mail]
Subject: Re: BGP - IGP Redistribution Issue 

Mareline,

> Misha,
> 
> > |
> > | - A discussion on multiple views/instances/processes of BGP (many ISPs
ar
e
> > | using it) and their possible interaction amongst themselves/IGPs.
> > 
> > That *might* prove interesting.
> 
> my votes on this too.

This seems to be clearly outside the scope of the *base* spec. And what we 
are discussing right now is the base spec.

> 
> > 
> > |
> > | - Limited interaction with IGPs
> > 
> > Why limited? I gathered that redistributing BGP info into IGP is a
strict N
o
> > No!
> 
> interaction with IGP does not necessarily mean redistributing routes
> to and f ro the IGPs.  There are other ways also by which BGP could
> interact with the IGPs e.g. Traffic Engineering

The interaction with IGP (including interaction with TE) is outside
the scope of the base spec. 

Yakov.

> 
> mareline s.
> 
> > 
> > |
> > | - Hierarchical peering using Route Reflectors
> > 
> > Yes, i am aware of certain ISPs doing that.
> > 
> > Misha
> > 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.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 JAA00584 for <[e-mail]>; Wed, 25 Sep 2002 09:28:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 27D3F912A9; Wed, 25 Sep 2002 09:27:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED953912AA; Wed, 25 Sep 2002 09:27:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D578B912A9 for <[e-mail]>; Wed, 25 Sep 2002 09:27:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BA4145DE15; Wed, 25 Sep 2002 09:27:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 2FE215DE0F for <[e-mail]>; Wed, 25 Sep 2002 09:27:37 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PDRam34666 for <[e-mail]>; Wed, 25 Sep 2002 06:27:36 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 36
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 06:27:36 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  36) Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: This change requires a glossary. No Glossary text has been
    proposed.
   
  Discussion:
   
  2. Section 9.1, Need to have Adj-RIB-In, Adj-RIB-Out, and Loc-RIB in the
  glossary, so when they are used in section 9.1, it is well understood what
  they are.

will be added to the section "Definition of commonly used terms" in -18
version.



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA00484 for <[e-mail]>; Wed, 25 Sep 2002 09:25:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 88D9491226; Wed, 25 Sep 2002 09:25:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E8C2912A9; Wed, 25 Sep 2002 09:25:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E4B291226 for <[e-mail]>; Wed, 25 Sep 2002 09:25:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 167F45DE16; Wed, 25 Sep 2002 09:25:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 7BED45DE15 for <[e-mail]>; Wed, 25 Sep 2002 09:25:06 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PDP6m34534 for <[e-mail]>; Wed, 25 Sep 2002 06:25:06 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 33
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 06:25:06 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  33) Add "Optional Non-Transitive" to the MED Section
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Do we add this text, or no?
  
  Discussion:
  
  4. P.23, change the following:
  
  "The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
   links to discriminate among multiple exit or entry points to the same
   neighboring AS ..."
  
   To the following:
  
  "The MULTI_EXIT_DISC is an optional non-transitive attribute which may be
  used on external (inter-AS) links to discriminate among multiple exit or
  entry points to the same neighboring AS ..."

The change is 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 JAA29729 for <[e-mail]>; Wed, 25 Sep 2002 09:07:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0768B912B7; Wed, 25 Sep 2002 09:06:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE65A912B0; Wed, 25 Sep 2002 09:06:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 43D5B912B7 for <[e-mail]>; Wed, 25 Sep 2002 09:06:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1F5C75DE09; Wed, 25 Sep 2002 09:06:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 834E25DE01 for <[e-mail]>; Wed, 25 Sep 2002 09:06:46 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PD6im33536; Wed, 25 Sep 2002 06:06:44 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Manav Bhatia <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP - IGP Redistribution Issue 
In-Reply-To: Your message of "Wed, 25 Sep 2002 18:33:06 +0530." <04fa01c26493$e4e8fe40$[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 06:06:44 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Manav,

> Yakov,
> This was in response to what other possible things can be discussed a BCP
> document and wasn't with reference to the base spec! Anyway we shall all
> wait for the base spec to first get fixed before we look into these issues.

Thanks !!!

Yakov.

> 
> Thanks,
> Manav
> 
> ----- Original Message -----
> From: "Yakov Rekhter" <[e-mail]>
> To: "Manav Bhatia" <[e-mail]>
> Cc: "Abarbanel, Benjamin" <[e-mail]>; "'Alexei
> Roudnev'" <[e-mail]>; "'Jeffrey Haas'" <[e-mail]>;
> <[e-mail]>
> Sent: Wednesday, September 25, 2002 6:10 PM
> Subject: Re: BGP - IGP Redistribution Issue
> 
> 
> | Manav,
> |
> | > some more things which could be pondered upon.
> | >
> | > - Bringing down all the EBGP connections immediately when the interface
> | > over which they run goes down (without waiting for the HoldTimer to
> | > expire!).
> | >
> | > - router id [hope am not opening a can of worms :-)]
> |
> | We've been through this discussion before...
> |
> | > - A discussion on multiple views/instances/processes of BGP (many ISPs
> are
> | > using it) and their possible interaction amongst themselves/IGPs.
> |
> | outside the scope of the base spec.
> |
> | > - Using communities
> |
> | Ditto.
> |
> | > - Limited interaction with IGPs
> |
> | Ditto.
> |
> | > - Hierarchical peering using Route Reflectors
> |
> | Ditto (although may be well within the scope of the Route Reflectors
> spec).
> |
> | Yakov.
> |
> | P.S. Folks, the WG chairs would reallly appreciate if (at least for now)
> | we stay focused on discussing just the *base* spec, and defering
> | issues that do not belong to the base spec till some later point...
> |
> | >
> | > Manav
> | > ----- Original Message -----
> | > From: "Abarbanel, Benjamin" <[e-mail]>
> | > To: "'Alexei Roudnev'" <[e-mail]>; "Abarbanel, Benjamin"
> | > <[e-mail]>; "'Jeffrey Haas'" <[e-mail]>
> | > Cc: <[e-mail]>
> | > Sent: Tuesday, September 24, 2002 9:53 PM
> | > Subject: RE: BGP - IGP Redistribution Issue
> | >
> | >
> | > | Agreed, are there other "good practice" issues that can be added to
> this
> | > | spec?
> | > |
> | > | Ben
> | > |
> | > | > -----Original Message-----
> | > | > From: Alexei Roudnev [mailto:[e-mail]]
> | > | > Sent: Tuesday, September 24, 2002 12:11 PM
> | > | > To: Abarbanel, Benjamin; 'Jeffrey Haas'
> | > | > Cc: [e-mail]
> | > | > Subject: Re: BGP - IGP Redistribution Issue
> | > | >
> | > | >
> | > | > > > As much as I would really like to incorporate some of the
> | > | > best current
> | > | > > > practices that network operators have in operating BGP networks
> in
> | > | > > > a 1772 replacement, we shouldn't try to reproduce works such as
> | > | > > > Halabi's book in a RFC.
> | > | > > >
> | > | > >
> | > | > > I thought Halabi's book was derived from IETF Specs and Cisco
> field
> | > | > > experience.
> | > | > It was re-written 2 years ago, without sugnificant changes.
> | > | >
> | > | > Anyway, it is a good idea to have some statement preventing
> | > | > people from bad
> | > | > practices (such as injecting bgp routes into IGP, even in
> | > | > small network).
> | > | >
> | > | >
> | >
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA29712 for <[e-mail]>; Wed, 25 Sep 2002 09:07:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3B7EA912B6; Wed, 25 Sep 2002 09:06:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EEAD2912B7; Wed, 25 Sep 2002 09:06:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 70F62912B6 for <[e-mail]>; Wed, 25 Sep 2002 09:06:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5FFF55DE0B; Wed, 25 Sep 2002 09:06:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web20303.mail.yahoo.com (web20303.mail.yahoo.com [216.136.226.84]) by segue.merit.edu (Postfix) with SMTP id 1E9BA5DE09 for <[e-mail]>; Wed, 25 Sep 2002 09:06:25 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [203.200.20.226] by web20303.mail.yahoo.com via HTTP; Wed, 25 Sep 2002 06:06:24 PDT
Date: Wed, 25 Sep 2002 06:06:24 -0700 (PDT)
From: Mareline Sheldon <[e-mail]>
Subject: Re: BGP - IGP Redistribution Issue 
To: Yakov Rekhter <[e-mail]>
Cc: Misha Dovek <[e-mail]>, [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Yakov,
> 
> This seems to be clearly outside the scope of the *base* spec. And what we 
> are discussing right now is the base spec.

It was meant for the Best Current Practises document (something like a 1772) and not the
*base* spec!

mareline s.





__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.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 JAA29628 for <[e-mail]>; Wed, 25 Sep 2002 09:04:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 84AA1912A6; Wed, 25 Sep 2002 09:03:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 503DC912AE; Wed, 25 Sep 2002 09:03:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 97725912A6 for <[e-mail]>; Wed, 25 Sep 2002 09:03:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7EB8B5DE04; Wed, 25 Sep 2002 09:03:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from realname (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 2C5095DE01 for <[e-mail]>; Wed, 25 Sep 2002 09:03:45 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug  5 2002)) id <[e-mail]> for [e-mail]; Wed, 25 Sep 2002 22:08:43 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug  5 2002)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 25 Sep 2002 22:08:43 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 25 Sep 2002 22:09:14 +0900 (KST)
Date: Wed, 25 Sep 2002 18:33:06 +0530
From: Manav Bhatia <[e-mail]>
Subject: Re: BGP - IGP Redistribution Issue
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <04fa01c26493$e4e8fe40$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Yakov,
This was in response to what other possible things can be discussed a BCP
document and wasn't with reference to the base spec! Anyway we shall all
wait for the base spec to first get fixed before we look into these issues.

Thanks,
Manav

----- Original Message -----
From: "Yakov Rekhter" <[e-mail]>
To: "Manav Bhatia" <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>; "'Alexei
Roudnev'" <[e-mail]>; "'Jeffrey Haas'" <[e-mail]>;
<[e-mail]>
Sent: Wednesday, September 25, 2002 6:10 PM
Subject: Re: BGP - IGP Redistribution Issue


| Manav,
|
| > some more things which could be pondered upon.
| >
| > - Bringing down all the EBGP connections immediately when the interface
| > over which they run goes down (without waiting for the HoldTimer to
| > expire!).
| >
| > - router id [hope am not opening a can of worms :-)]
|
| We've been through this discussion before...
|
| > - A discussion on multiple views/instances/processes of BGP (many ISPs
are
| > using it) and their possible interaction amongst themselves/IGPs.
|
| outside the scope of the base spec.
|
| > - Using communities
|
| Ditto.
|
| > - Limited interaction with IGPs
|
| Ditto.
|
| > - Hierarchical peering using Route Reflectors
|
| Ditto (although may be well within the scope of the Route Reflectors
spec).
|
| Yakov.
|
| P.S. Folks, the WG chairs would reallly appreciate if (at least for now)
| we stay focused on discussing just the *base* spec, and defering
| issues that do not belong to the base spec till some later point...
|
| >
| > Manav
| > ----- Original Message -----
| > From: "Abarbanel, Benjamin" <[e-mail]>
| > To: "'Alexei Roudnev'" <[e-mail]>; "Abarbanel, Benjamin"
| > <[e-mail]>; "'Jeffrey Haas'" <[e-mail]>
| > Cc: <[e-mail]>
| > Sent: Tuesday, September 24, 2002 9:53 PM
| > Subject: RE: BGP - IGP Redistribution Issue
| >
| >
| > | Agreed, are there other "good practice" issues that can be added to
this
| > | spec?
| > |
| > | Ben
| > |
| > | > -----Original Message-----
| > | > From: Alexei Roudnev [mailto:[e-mail]]
| > | > Sent: Tuesday, September 24, 2002 12:11 PM
| > | > To: Abarbanel, Benjamin; 'Jeffrey Haas'
| > | > Cc: [e-mail]
| > | > Subject: Re: BGP - IGP Redistribution Issue
| > | >
| > | >
| > | > > > As much as I would really like to incorporate some of the
| > | > best current
| > | > > > practices that network operators have in operating BGP networks
in
| > | > > > a 1772 replacement, we shouldn't try to reproduce works such as
| > | > > > Halabi's book in a RFC.
| > | > > >
| > | > >
| > | > > I thought Halabi's book was derived from IETF Specs and Cisco
field
| > | > > experience.
| > | > It was re-written 2 years ago, without sugnificant changes.
| > | >
| > | > Anyway, it is a good idea to have some statement preventing
| > | > people from bad
| > | > practices (such as injecting bgp routes into IGP, even in
| > | > small network).
| > | >
| > | >
| >



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA29134 for <[e-mail]>; Wed, 25 Sep 2002 08:53:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 47F8B91226; Wed, 25 Sep 2002 08:53:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19DDE912AC; Wed, 25 Sep 2002 08:53:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E560791226 for <[e-mail]>; Wed, 25 Sep 2002 08:53:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C33695DE05; Wed, 25 Sep 2002 08:53:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 379865DE04 for <[e-mail]>; Wed, 25 Sep 2002 08:53:29 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PCrSm32749 for <[e-mail]>; Wed, 25 Sep 2002 05:53:28 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 17
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 05:53:28 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

   17) Add References to other RFC-status BGP docs to base spec.
   ----------------------------------------------------------------------------
   Status: No Consensus
   Change: Potentially
   Summary: Add references to other RFC-status BGP docs to the base spec.
        
   Discussion:
   
   The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread then changes
   titles to: "Review of draft-ietf-idr-bgp4-17.txt" and goes on to
   suggest:
   
   3. All BGP Extensions described in other documents that made it to RFC
   status should be at least referenced in the Reference section P.64. This is
   justifiable since it's the core BGP standard spec.

Will be added to -18 version.

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 IAA28936 for <[e-mail]>; Wed, 25 Sep 2002 08:49:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CF8D3912AA; Wed, 25 Sep 2002 08:48:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0EF391226; Wed, 25 Sep 2002 08:48:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6E67912AC for <[e-mail]>; Wed, 25 Sep 2002 08:48:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C64DA5DE01; Wed, 25 Sep 2002 08:48:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 3DD795DD90 for <[e-mail]>; Wed, 25 Sep 2002 08:48:49 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PCmmm32590 for <[e-mail]>; Wed, 25 Sep 2002 05:48:48 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 9
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 05:48:48 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

   9) Reference to RFC904 - EGP Protocol
   ----------------------------------------------------------------------------
   Status: No Consensus
   Change: Potentially
   Summary: Add a reference to RFC904
   
   Discussion:
   
   The "Review Comment: Origin Attribute pg 14" thread suggested adding a
   reference to RFC904(?), to refer to the EGP protocol.  There was no
   discussion.

I'll add reference to [RFC904].

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 IAA28565 for <[e-mail]>; Wed, 25 Sep 2002 08:41:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 08955912A9; Wed, 25 Sep 2002 08:40:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C41F3912AA; Wed, 25 Sep 2002 08:40:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8FAA5912A9 for <[e-mail]>; Wed, 25 Sep 2002 08:40:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 72F215DDFF; Wed, 25 Sep 2002 08:40:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id D1E4A5DDBD for <[e-mail]>; Wed, 25 Sep 2002 08:40:56 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PCe9m32230; Wed, 25 Sep 2002 05:40:09 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Manav Bhatia <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, "'Alexei Roudnev'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: Re: BGP - IGP Redistribution Issue 
In-Reply-To: Your message of "Wed, 25 Sep 2002 10:08:50 +0530." <010a01c2644d$72ecdbe0$[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 05:40:09 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Manav,

> some more things which could be pondered upon.
> 
> - Bringing down all the EBGP connections immediately when the interface
> over which they run goes down (without waiting for the HoldTimer to
> expire!).
> 
> - router id [hope am not opening a can of worms :-)]

We've been through this discussion before... 

> - A discussion on multiple views/instances/processes of BGP (many ISPs are
> using it) and their possible interaction amongst themselves/IGPs.

outside the scope of the base spec. 

> - Using communities

Ditto.

> - Limited interaction with IGPs

Ditto.

> - Hierarchical peering using Route Reflectors

Ditto (although may be well within the scope of the Route Reflectors spec).

Yakov.

P.S. Folks, the WG chairs would reallly appreciate if (at least for now)
we stay focused on discussing just the *base* spec, and defering
issues that do not belong to the base spec till some later point...

> 
> Manav
> ----- Original Message -----
> From: "Abarbanel, Benjamin" <[e-mail]>
> To: "'Alexei Roudnev'" <[e-mail]>; "Abarbanel, Benjamin"
> <[e-mail]>; "'Jeffrey Haas'" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Tuesday, September 24, 2002 9:53 PM
> Subject: RE: BGP - IGP Redistribution Issue
> 
> 
> | Agreed, are there other "good practice" issues that can be added to this
> | spec?
> |
> | Ben
> |
> | > -----Original Message-----
> | > From: Alexei Roudnev [mailto:[e-mail]]
> | > Sent: Tuesday, September 24, 2002 12:11 PM
> | > To: Abarbanel, Benjamin; 'Jeffrey Haas'
> | > Cc: [e-mail]
> | > Subject: Re: BGP - IGP Redistribution Issue
> | >
> | >
> | > > > As much as I would really like to incorporate some of the
> | > best current
> | > > > practices that network operators have in operating BGP networks in
> | > > > a 1772 replacement, we shouldn't try to reproduce works such as
> | > > > Halabi's book in a RFC.
> | > > >
> | > >
> | > > I thought Halabi's book was derived from IETF Specs and Cisco field
> | > > experience.
> | > It was re-written 2 years ago, without sugnificant changes.
> | >
> | > Anyway, it is a good idea to have some statement preventing
> | > people from bad
> | > practices (such as injecting bgp routes into IGP, even in
> | > small network).
> | >
> | >
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA28436 for <[e-mail]>; Wed, 25 Sep 2002 08:38:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6447F912A6; Wed, 25 Sep 2002 08:37:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39EBA912A9; Wed, 25 Sep 2002 08:37:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 11DC2912A6 for <[e-mail]>; Wed, 25 Sep 2002 08:37:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E8CA85DDFB; Wed, 25 Sep 2002 08:37:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 5B5645DDBD for <[e-mail]>; Wed, 25 Sep 2002 08:37:33 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8PCbNm32087; Wed, 25 Sep 2002 05:37:23 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Mareline Sheldon <[e-mail]>
Cc: Misha Dovek <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: BGP - IGP Redistribution Issue 
In-Reply-To: Your message of "Wed, 25 Sep 2002 05:03:12 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 25 Sep 2002 05:37:23 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Mareline,

> Misha,
> 
> > |
> > | - A discussion on multiple views/instances/processes of BGP (many ISPs ar
e
> > | using it) and their possible interaction amongst themselves/IGPs.
> > 
> > That *might* prove interesting.
> 
> my votes on this too.

This seems to be clearly outside the scope of the *base* spec. And what we 
are discussing right now is the base spec.

> 
> > 
> > |
> > | - Limited interaction with IGPs
> > 
> > Why limited? I gathered that redistributing BGP info into IGP is a strict N
o
> > No!
> 
> interaction with IGP does not necessarily mean redistributing routes
> to and f ro the IGPs.  There are other ways also by which BGP could
> interact with the IGPs e.g. Traffic Engineering

The interaction with IGP (including interaction with TE) is outside
the scope of the base spec. 

Yakov.

> 
> mareline s.
> 
> > 
> > |
> > | - Hierarchical peering using Route Reflectors
> > 
> > Yes, i am aware of certain ISPs doing that.
> > 
> > Misha
> > 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.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 IAA27131 for <[e-mail]>; Wed, 25 Sep 2002 08:03:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B75FF912A1; Wed, 25 Sep 2002 08:03:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 891249120F; Wed, 25 Sep 2002 08:03:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E12C9912AA for <[e-mail]>; Wed, 25 Sep 2002 08:03:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BA2E15DDF7; Wed, 25 Sep 2002 08:03:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web20308.mail.yahoo.com (web20308.mail.yahoo.com [216.136.226.89]) by segue.merit.edu (Postfix) with SMTP id 380C45DDF4 for <[e-mail]>; Wed, 25 Sep 2002 08:03:13 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [203.200.20.226] by web20308.mail.yahoo.com via HTTP; Wed, 25 Sep 2002 05:03:12 PDT
Date: Wed, 25 Sep 2002 05:03:12 -0700 (PDT)
From: Mareline Sheldon <[e-mail]>
Subject: Re: BGP - IGP Redistribution Issue
To: Misha Dovek <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
In-Reply-To: <034b01c2646f$21f70720$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Misha,

> |
> | - A discussion on multiple views/instances/processes of BGP (many ISPs are
> | using it) and their possible interaction amongst themselves/IGPs.
> 
> That *might* prove interesting.

my votes on this too.

> 
> |
> | - Limited interaction with IGPs
> 
> Why limited? I gathered that redistributing BGP info into IGP is a strict No
> No!

interaction with IGP does not necessarily mean redistributing routes to and fro the IGPs.
There are other ways also by which BGP could interact with the IGPs e.g. Traffic Engineering

mareline s.

> 
> |
> | - Hierarchical peering using Route Reflectors
> 
> Yes, i am aware of certain ISPs doing that.
> 
> Misha
> 


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.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 EAA19567 for <[e-mail]>; Wed, 25 Sep 2002 04:41:24 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9678691250; Wed, 25 Sep 2002 04:41:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E01791279; Wed, 25 Sep 2002 04:41:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1315391250 for <[e-mail]>; Wed, 25 Sep 2002 04:41:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id ECE175DD99; Wed, 25 Sep 2002 04:40:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by segue.merit.edu (Postfix) with ESMTP id A65955DD8C for <[e-mail]>; Wed, 25 Sep 2002 04:40:59 -0400 (EDT)
Received: from [10.9.9.110] (helo=snoopy.runbox.com) by tramp.runbox.com with esmtp (Exim 4.05-VA-mm1) id 17u7j1-0006PI-00; Wed, 25 Sep 2002 10:40:51 +0200
Received: from [203.200.20.226] (helo=Manav) (Authenticated Sender=dovek) by snoopy.runbox.com with asmtp (Exim 3.35 #1) id 17u7ii-0006Qc-00; Wed, 25 Sep 2002 10:40:33 +0200
Message-ID: <034b01c2646f$21f70720$[e-mail]>
From: "Misha Dovek" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Re: BGP - IGP Redistribution Issue
Date: Wed, 25 Sep 2002 14:09:52 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

Manav,

| - Bringing down all the EBGP connections immediately when the interface
| over which they run goes down (without waiting for the HoldTimer to
| expire!).

I agree that this does not exist in any IETF document.

|
| - router id [hope am not opening a can of worms :-)]
|
| - A discussion on multiple views/instances/processes of BGP (many ISPs are
| using it) and their possible interaction amongst themselves/IGPs.

That *might* prove interesting.

|
| - Limited interaction with IGPs

Why limited? I gathered that redistributing BGP info into IGP is a strict No
No!

|
| - Hierarchical peering using Route Reflectors

Yes, i am aware of certain ISPs doing that.

Misha



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA10594 for <[e-mail]>; Wed, 25 Sep 2002 00:40:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DCB9E91221; Wed, 25 Sep 2002 00:39:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A68F09129B; Wed, 25 Sep 2002 00:39:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5545291221 for <[e-mail]>; Wed, 25 Sep 2002 00:39:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 39B5C5DF31; Wed, 25 Sep 2002 00:39:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from realname (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id DEA615DD9B for <[e-mail]>; Wed, 25 Sep 2002 00:39:38 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug  5 2002)) id <[e-mail]> for [e-mail]; Wed, 25 Sep 2002 13:44:27 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug  5 2002)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 25 Sep 2002 13:44:27 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 25 Sep 2002 13:44:56 +0900 (KST)
Date: Wed, 25 Sep 2002 10:08:50 +0530
From: Manav Bhatia <[e-mail]>
Subject: Re: BGP - IGP Redistribution Issue
To: "Abarbanel, Benjamin" <[e-mail]>, "'Alexei Roudnev'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>
Cc: [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <010a01c2644d$72ecdbe0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

some more things which could be pondered upon.

- Bringing down all the EBGP connections immediately when the interface
over which they run goes down (without waiting for the HoldTimer to
expire!).

- router id [hope am not opening a can of worms :-)]

- A discussion on multiple views/instances/processes of BGP (many ISPs are
using it) and their possible interaction amongst themselves/IGPs.

- Using communities

- Limited interaction with IGPs

- Hierarchical peering using Route Reflectors

Manav
----- Original Message -----
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Alexei Roudnev'" <[e-mail]>; "Abarbanel, Benjamin"
<[e-mail]>; "'Jeffrey Haas'" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, September 24, 2002 9:53 PM
Subject: RE: BGP - IGP Redistribution Issue


| Agreed, are there other "good practice" issues that can be added to this
| spec?
|
| Ben
|
| > -----Original Message-----
| > From: Alexei Roudnev [mailto:[e-mail]]
| > Sent: Tuesday, September 24, 2002 12:11 PM
| > To: Abarbanel, Benjamin; 'Jeffrey Haas'
| > Cc: [e-mail]
| > Subject: Re: BGP - IGP Redistribution Issue
| >
| >
| > > > As much as I would really like to incorporate some of the
| > best current
| > > > practices that network operators have in operating BGP networks in
| > > > a 1772 replacement, we shouldn't try to reproduce works such as
| > > > Halabi's book in a RFC.
| > > >
| > >
| > > I thought Halabi's book was derived from IETF Specs and Cisco field
| > > experience.
| > It was re-written 2 years ago, without sugnificant changes.
| >
| > Anyway, it is a good idea to have some statement preventing
| > people from bad
| > practices (such as injecting bgp routes into IGP, even in
| > small network).
| >
| >



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA08471 for <[e-mail]>; Tue, 24 Sep 2002 23:40:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4540E9129A; Tue, 24 Sep 2002 23:40:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 107D89129B; Tue, 24 Sep 2002 23:40:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B5BE49129A for <[e-mail]>; Tue, 24 Sep 2002 23:40:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 96DCF5DF14; Tue, 24 Sep 2002 23:40:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 6C3DA5DDD0 for <[e-mail]>; Tue, 24 Sep 2002 23:40:11 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17u322-000NUz-00; Tue, 24 Sep 2002 20:40:10 -0700
Date: Tue, 24 Sep 2002 20:38:10 -0700
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: BGP Base Draft - Issue List v1.1 2002-09-24
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Andrew-

 Though I'm known to be a big hater of all those managerial
 way-to-go's and above-n-beyond's, I couldn't help...

 Awesome job, man!!!

-- 
Alex

Tuesday, September 24, 2002, 5:41:24 PM, [e-mail] wrote:
> Well, you know what they say about never trusting a 1.0 release :).  I
> was going through the messages and came across some threads I hadn't 
> incorporated.  Attached is the updated issues list (v1.1) and the
> changelog.

> 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 XAA07782 for <[e-mail]>; Tue, 24 Sep 2002 23:19:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A67489128B; Tue, 24 Sep 2002 23:19:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DF1D91296; Tue, 24 Sep 2002 23:19:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0AF5E9128B for <[e-mail]>; Tue, 24 Sep 2002 23:19:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EAF465DF0A; Tue, 24 Sep 2002 23:19:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 8E9485DDD0 for <[e-mail]>; Tue, 24 Sep 2002 23:19:18 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8P3JIm09168; Tue, 24 Sep 2002 20:19:18 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], Bill Fenner <[e-mail]>
Subject: revised charter
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 24 Sep 2002 20:19:18 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

Attached is the revised charter. The WG chairs as well as the Routing
ADs would greatly appreciate review/comments. If you have any objections
to the charter, then we would appreciate if you would elaborate on
them. In the absence of any objections by 10/2 we would forward the 
charter to the IESG for approval.

Sue & Yakov.
----------------------------------------------------------------------

The Inter-Domain Routing Working Group is chartered to standardize
and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
1771] capable of supporting policy based routing for TCP/IP internets.
The objective is to promote the use of BGP-4 to support IP version
4 and IP version 6. The working group will continue to work on
improving the scalability of BGP.

The current tasks of the WG are limited to:

- Revise and clarify the base BGP4 document (RFC 1771). Note that
RFC 1771 no longer documents existing practice and one goal of the
update is document existing practice. Determine whether the document
can be advanced as full Standard or needs to recycle at Proposed
or Draft Standard.

- Submit updated base BGP4 MIB to accompany the revised base BGP4 document.

Once these tasks are finished (means WG consensus, WG Last Call,
AD Review, IETF Last Call, and IESG approval for publication), work 
will progress on the following:

- Review and Evaluate Existing RFCs on AS Confederations and Route
Reflection. If changes are needed, create and advance revisions.

- Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
if any changes need to be made based on current Internet practice
or based on the changes to the current bgp draft. If changes are
needed, create an revision. Issue the WG Last Call on advancing
the document to Draft Standard.

- Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
as Draft Standard.

- Progress BGP Extended Communities along standards track. 

- Extend BGP to support a 4-byte AS number, develop plan for
transitioning to usage of 4-byte AS numbers. Advance support for a 4-byte
AS numbers along standards track.

- Produce BGP MIB v2 that includes support for AS Confederations, 
Route Reflection, Communities, Multi-Protocol BGP, BGP Extended
Communities, support for 4-byte AS numbers.

- Progress along the IETF standards track 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. Currently defined in
draft-ietf-idr-route-filter-03.txt.

- Progress along standards track an Outbound Router Filter (ORF)
type for BGP, that can be used to perform aspath based route
filtering. The ORF-type will support aspath based route filtering
as well as regular expression based matching for address groups.
Currently defined in draft-ietf-idr-aspath-orf-00.txt.

- Progress a BGP Graceful Restart mechanism along standards track.

- Progress Subcodes for BGP Cease Notification Message along standards
track.

- Progress  AS-wide Unique BGP Identifier for BGP-4 along standards
track.

- Progress Dynamic Capability for BGP-4 along standards track.

Tasks for this working group are limited to those listed above;
new items to be added to the charter must be approved by the IESG.

Goals and Milestones

DONE    Submit BGP Capability Advertisement to the IESG

NOV 02  Submit BGP4 document to IESG.
DEC 02  Submit updated base BGP4 MIB to IESG.

MAR 03  Submit BGP Graceful Restart to IESG
MAR 03  Submit Extended Communities draft to IESG.
MAR 03  Submit revised text on Multi-Protocol BGP (rfc2858bis) to IESG
MAR 03  Submit BGP MIB v2 to IESG.

MAY 03  Submit 4-byte AS ID to IESG.
MAY 03  BGP TCP MD5 signatures document to IESG.
MAY 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.
MAY 03  Subcodes for BGP Cease Notification Message to IESG
MAY 03  AS-wide Unique BGP Identifier for BGP-4 to IESG
MAY 03  Dynamic Capability for BGP-4 to IESG


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA07111 for <[e-mail]>; Tue, 24 Sep 2002 22:58:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3F4509121B; Tue, 24 Sep 2002 22:58:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 070459128B; Tue, 24 Sep 2002 22:58:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B82339121B for <[e-mail]>; Tue, 24 Sep 2002 22:58:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9CEC55E13B; Tue, 24 Sep 2002 22:58:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 328645E139 for <[e-mail]>; Tue, 24 Sep 2002 22:58:13 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8P2wCm08025 for <[e-mail]>; Tue, 24 Sep 2002 19:58:12 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 29
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 24 Sep 2002 19:58:12 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  29) State Why Unresolveable Routes Should Be Kept in Adj-RIB-In
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary:  Explicity state that there is a chance routes can become 
    resolveable, and should therefore be kept in Adj-RIB-In.  No text  
    has yet been suggested.
  
  Discussion:
  
   5. P.46, last sentence, "However, corresponding unresolvable routes SHOULD 
   be kept in the Adj-RIBs-In."  It would helpful if the author states why
   unresolvable routes should be kept in Adj-RIBs-In?
  
   A reponse to this stated "In case they become resolveable"
  
I suggest we add "in case they become resolvable" after the last sentence
on p. 46.

   The original commentor stated that:
   Then the point that the peer will not refresh the route if we drop
   them (unless we use Route Refresh) because they are unreachable should be
   made.

This should be clear from the following text in Section 3:

   The initial data flow is the portion of the BGP routing table that
   is allowed by the export policy, called the Adj-Ribs-Out (see 3.2).
   Incremental updates are sent as the routing tables change. BGP does
   not require periodic refresh of the routing table. 

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 VAA04409 for <[e-mail]>; Tue, 24 Sep 2002 21:38:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 46E1B91214; Tue, 24 Sep 2002 21:37:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C2DC91296; Tue, 24 Sep 2002 21:37:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5838B91214 for <[e-mail]>; Tue, 24 Sep 2002 21:37:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3C3215E064; Tue, 24 Sep 2002 21:37:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id A1D615DF21 for <[e-mail]>; Tue, 24 Sep 2002 21:37:56 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8P1bum04017 for <[e-mail]>; Tue, 24 Sep 2002 18:37:56 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 8
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 24 Sep 2002 18:37:56 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

   8) Jitter Text
   ----------------------------------------------------------------------------
   Status: No Consensus
   Change: Potentially 
   Summary:
    Change:
     "jitter should be applied to the
      timers associated with MinASOriginationInterval, Keepalive, and
      MinRouteAdvertisementInterval"
    To:
     "jitter should be applied to the timers associated with ConnectRetry timer"
   
   Discussion:
   
   In the tread entitled "bgp draft review":
   The thread also proposed:
   
   "jitter should be applied to the
      timers associated with MinASOriginationInterval, Keepalive, and
      MinRouteAdvertisementInterval"
   
   Be changed to:
   
   "jitter should be applied to the
      timers associated with ConnectRetry timer"
   
   - There was limited discussion on this issue.  Implementions will
   add jitter to all of these.  There is no consensus on changing this
   text.

I would suggest that we'll change the text to make sure that jitter
is applied to all the timers. To make this change I would suggest
to get rid of section 9.2.1.3 ("Jitter"), move the text of this
section into Appendix "BGP Timers", and expand the text to indicate
that jitter applies to ConnectRetry timer as well.

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 UAA02585 for <[e-mail]>; Tue, 24 Sep 2002 20:44:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CDE8E91295; Tue, 24 Sep 2002 20:44:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 934F391296; Tue, 24 Sep 2002 20:44:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1D80D91295 for <[e-mail]>; Tue, 24 Sep 2002 20:44:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E92295E131; Tue, 24 Sep 2002 20:44:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 3F7EF5E07B for <[e-mail]>; Tue, 24 Sep 2002 20:44:23 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id RAA27268; Tue, 24 Sep 2002 17:41:24 -0700 (PDT)
Date: Tue, 24 Sep 2002 17:41:24 -0700
From: [e-mail]
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: BGP Base Draft - Issue List v1.1 2002-09-24
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="kORqDWCi7qDJ0mEj"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Sep 24, 2002 at 04:13:46PM -0700
Sender: [e-mail]
Precedence: bulk

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

Well, you know what they say about never trusting a 1.0 release :).  I
was going through the messages and came across some threads I hadn't 
incorporated.  Attached is the updated issues list (v1.1) and the
changelog.

Andrew

--kORqDWCi7qDJ0mEj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="Issue_List-v1.1.txt"

2002-09-24
v1.1

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) IDR WG Charter
2) TCP Port 
3) FSM wording for what state BGP accepts connections in
4) BGP Identifier/Router ID
5) Direct EBGP Peers
6) Disallow Private Addresses
7) Renumber Appendix Sections
8) Jitter Text
9) Reference to RFC904 - EGP Protocol
10) Extending AS_PATH Attribute
11) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1 
11.1) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3
11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
12) TCP Behavior Wording
13) Next Hop for Originated Route
14) NEXT_HOP to Internal Peer
15) Grammer Fix
16) Need ToC, Glossary and Index
17) Add References to other RFC-status BGP docs to base spec.
18) IP Layer Fragmentation 
19) Appendix Section 6.2: Processing Messages on a Stream Protocol
20) Wording fix in Section 4.3
21) Authentication Text Update
22) Scope of Path Attribute Field
23) Withdrawn and Updated routes in the same UPDATE message
24) Addition or Deletion of Path Attributes
25) NEXT_HOP Semantics
26) Attributes with Multiple Prefixes
27) Allow All Non-Destructive Messages to Refresh Hold Timer
28) BGP Identifier as Variable Quantity
29) State Why Unresolveable Routes Should Be Kept in Adj-RIB-In
30) Mention Other Message Types
31) Add References to Additional Options
32) Clarify EGP Reference
32.1) EGP ORIGIN Clarification
32.2) BGP Desitnation-based Forwarding Paradigm
33) Add "Optional Non-Transitive" to the MED Section
34) Timer & Counter Definition
35) Fix Typo
36) Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary
37) Combine "Unfeasable Routes" and "Withdrawn Routes"
38) Clarify Outbound Route Text
39) Redundant Sentance Fragments
40) Section 9.2.1.1 - Per Peer vs. Per Router MinRouteAdvertisementInterval
41) Mention FSM Internal Timers
42) Delete the FSM Section
43) Clarify the NOTIFICATION Section
44) Section 6.2: OPEN message error handling
45) Consistant References to BGP Peers/Connections/Sessions
46) FSM Connection Collision Detection
47) FSM - Add Explicit State Change Wording
48) Explicitly Define Processing of Incomming Connections
49) Explicity Define Event Generation
50) FSM Timers 
51) FSM ConnectRetryCnt
52) Section 3: Keeping routes in Adj-RIB-In
53) Section 4.3 - Routes v. Destinations - Advertise
54) Section 4.3 - Routes v. Destinations - Withdraw
55) Section 4.3 - Description of AS_PATH length
56) Section 6 - BGP Error Handling
57) Section 6.2 - Hold timer as Zero
58) Deprication of ATOMIC_AGGREGATE
59) Section 4.3 - Move text
60) Section 4.3 - Path Attributes

============================================================================
Issues with Consensus
============================================================================
1) IDR WG Charter
2) TCP Port 
3) FSM wording for what state BGP accepts connections in
5) Direct EBGP Peers
6) Disallow Private Addresses
7) Renumber Appendix Sections
12) TCP Behavior Wording
13) Next Hop for Originated Route
15) Grammer Fix
16) Need ToC, Glossary and Index
20) Wording fix in Section 4.3
23) Withdrawn and Updated routes in the same UPDATE message
25) NEXT_HOP Semantics
26) Attributes with Multiple Prefixes
28) BGP Identifier as Variable Quantity
35) Fix Typo
38) Clarify Outbound Route Text
40) Section 9.2.1.1 - Per Peer vs. Per Router MinRouteAdvertisementInterval
42) Delete the FSM Section
43) Clarify the NOTIFICATION Section
50) FSM Timers 
51) FSM ConnectRetryCnt
52) Section 3: Keeping routes in Adj-RIB-In
54) Section 4.3 - Routes v. Destinations - Withdraw
57) Section 6.2 - Hold timer as Zero
60) Section 4.3 - Path Attributes

----------------------------------------------------------------------------
1) IDR WG Charter
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: New charter adopted.

Discussion:

A variety of discussions surrounded the new charter.  The rough
consensus is to accept the new charter that the AD's have proposed,
and to push as hard a possible to get the base spec to RFC status
so other drafts that are dependent can also move forward.
This thread has messages subjects of "BGP spec and IDR WG charter"
and "IDR WG charter".

For our information, Alex has provided these aproximate timelines:

 Stage		 Anticipated delay	    Comment
----------------------------------------------------------------------------
 AD-review	 1--4 weeks		    The document may go back to the
		 depending on workload	    WG for the AD-review comments
                                            to be addressed; this would
                                            introduce additional delay.

 IETF LC	 2 weeks		    Same as above

 IESG review&	 1--2 weeks depending	    Same as above
 telechat	 on when the IETF LC ends
----------------------------------------------------------------------------

Note that if the document is sent back to the WG at some stage, required
changes may warrant an additional WG Last Call.

I can personally commit to a 2-week upper bound for the AD-review
period. Bill may have a different timer granularity.

The offical vote on this was 7 accept, 4 reject.

----------------------------------------------------------------------------
2) TCP Port 
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: 
 Change:
  "BGP uses TCP port 179 for establishing its connections."
 To: 
  "BGP listens on TCP port 179."

Discussion:

There has been a discussion on clarifying the wording in Section 2,
on which port BGP uses.	 The original text was:

"BGP uses TCP port 179 for establishing its connections."

The proposed new text is:

"BGP listens on TCP port 179."

There seems to be a rough consensus that the new text is better.

This thread has a message subject of "Review: Section 2, TCP Port 179"

----------------------------------------------------------------------------
3) FSM wording for what state BGP accepts connections in
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: No change necessary

Discussion:

An issue was brought up later in the "Review: Section 2, TCP Port 179"
thread about the words in the FSM for what state BGP accepts connections
in.  The consensus is that the existing wording is clear.

----------------------------------------------------------------------------
4) BGP Identifier/Router ID
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: No change necessary to base draft.  Perhaps in a BCP.

Discussion:

The "admin dist/gp spec proposal", "Router ID" and "bgp spec proposal"
threads discussed the BGP Identifier and how close or not it is to IGP's
Router ID.  The consensus was that this discussion is better saved for a
BCP draft, and that it does not need to be contained in the base spec.

----------------------------------------------------------------------------
5) Direct EBGP Peers
----------------------------------------------------------------------------
Status: No Consensus
Change: No
Summary: A recollection that ebgp peers must be direct.  No text
  proposed, no discussion.

Discussion:

Jonathan recalled something that stated that ebgp peers must be direct.
No specific sections were quoted.

Yakov responded to this with:

Section 5.1.3 talks about both the case where ebgp peers are 1 IP
hop away from each other:

   2) When sending a message to an external peer X, and the peer is
      one IP hop away from the speaker:
 
as well as the case where they are multiple IP hops away from each
other:

   3) When sending a message to an external peer X, and the peer is
      multiple IP hops away from the speaker (aka "multihop EBGP"):

And emphasized that multihop EBGP does exist.

This came up in the "bgp draft review" thread.

----------------------------------------------------------------------------
6) Disallow Private Addresses
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: No change necessary

Discussion:

In the tread entitled "bgp draft review":

Mentioned explicitly disallowing private addresses.  The
consensus was that there is no reason to disallow them.	 Which IP
addresses peers use is an operational issue.

----------------------------------------------------------------------------
7) Renumber Appendix Sections
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary:
 Rename/renumber appendix sections so they do not have the
 same numbers as sections of the main text.

Discussion:

In the tread entitled "bgp draft review":

This thread brought up renaming sections in the appendix to avoid
confusion with sections of the same number in the main text.

Yakov responded that he would do so in the next edition.

----------------------------------------------------------------------------
8) Jitter Text
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary:
 Change:
  "jitter should be applied to the
   timers associated with MinASOriginationInterval, Keepalive, and
   MinRouteAdvertisementInterval"
 To:
  "jitter should be applied to the timers associated with ConnectRetry timer"

Discussion:

In the tread entitled "bgp draft review":
The thread also proposed:

"jitter should be applied to the
   timers associated with MinASOriginationInterval, Keepalive, and
   MinRouteAdvertisementInterval"

Be changed to:

"jitter should be applied to the
   timers associated with ConnectRetry timer"

- There was limited discussion on this issue.  Implementions will
add jitter to all of these.  There is no consensus on changing this
text.

----------------------------------------------------------------------------
9) Reference to RFC904 - EGP Protocol
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Add a reference to RFC904

Discussion:

The "Review Comment: Origin Attribute pg 14" thread suggested adding a
reference to RFC904(?), to refer to the EGP protocol.  There was no
discussion.

----------------------------------------------------------------------------
10) Extending AS_PATH Attribute
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Specific text required to delimit behavior when AS_PATH length
 is exceeded.

Discussion:

The "Extending AS_PATH attribute length en route" thread brought up
the issue of what action should we specify when we receive a route
with an AS_PATH that exceeds the defined maximum length.  There was
some discussion, and it was suggested that, after logging the error,
the route not be propegated.  No text was proposed.  This issue needs
consensus:  Do we specify the behavior?	 If so what with what text?

----------------------------------------------------------------------------
11) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Variety of texts proposed to help clear up the rules for moving
 routes from Loc-RIB into Adj-RIB-Out.

Discussion:

The "Proxy: comments on section 9.1.3" thread brought up some lack of
clarity in the section discussing the rules for which routes get propegated
from the Loc-RIB into the Adj-RIB-Out.	These discussions resulted in
a number of suggestions for new text.

The first new text was proposed to clarify the issue that the thread
first brought up:

I agree that this could use some clarification.	 How about adding
to b) in section 9.1:


  The Loc-RIB must contain only one route per destination; further, it
  must include all routes that the BGP speaker is using.

changing c) in section 9.1.2 to:

  c) is selected as a result of the Phase 2 tie breaking rules specified
  in 9.1.2.2, or

and adding

  d) when routing protocols other than BGP are in use, is determined by
  some other local means to be the route that will actually be used to
  reach a particular destination.

This text was never discussed or a consensus formed on putting it in the
document.

This modification to 9.1.2 was also proposed to address the same concern:

How about changing the paragraph after c) in 9.1.2 to:

  The local speaker SHALL then install that route in the Loc-RIB,
  replacing any route to the same destination that is currently being
  held in the Loc-RIB.	This route SHALL then also be installed in
  the BGP speakers forwarding table.

There was one response in the negative to this change, arguing that is
is not necessary.

----------------------------------------------------------------------------
11.1) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Variety of texts proposed to help clear up the rules for moving
 routes from Loc-RIB into Adj-RIB-Out.

Discussion:

In further discussions around this issue, this text was also proposed:

How about adding to section 9.1.3, at the end:

  Any local-policy which results in reachability being added to an
  Adj-RIB-Out without also being added to the local BGP speaker's
  forwarding table is beyond the scope of this document.

This suggestion received one response that agreed to this change.

----------------------------------------------------------------------------
11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Variety of texts proposed to help clear up the rules for moving
 routes from Loc-RIB into Adj-RIB-Out.

Discussion:

Additionally this thread produced this section of new text, in section 2:

<OLD>

"one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with) in
   neighboring ASs only those routes that it itself uses."

Should be changed to

<NEW #1>

"one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with) in
   neighboring ASs only routes whose NLRIs are locally reachable."

<NEW #2>

 "one must focus on the rule that a BGP speaker advertises
  to its peers (other BGP speakers which it communicates with) in
  neighboring ASs only routes which are locally reachable. Local
  reachability can be achieved by having any protocol route to
  the given destination in the routing table."

There was no consensus on which text we ought to use, or if any change
is necessary.

----------------------------------------------------------------------------
12) TCP Behavior Wording
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Minor wording change very contentious.  Consensus was to leave
  things as they are.

Discussion:
The subjectless "your mail" thread discussed a wording clarification from:

 "An implementation that would "hang" the routing information process while
 trying to read from a peer could set up a message buffer (4096 bytes) per
 peer and fill it with data as available until a complete message has been
 received. "

To something that is more TCP-correct, such as:

 "An implementation that would "hang" the routing information process while
 trying to received from a peer could set up a message buffer (4096 bytes) per
 peer and fill it with data as available until a complete message has been
 received. "

(only change: "read" to "received"  This was one of a couple of suggested
changes.)

This suggestion was quite contentious, and although there were a variety
of alternate texts proposed, the only consensus was that this was a very
minor issue, and probably not worth changing.

----------------------------------------------------------------------------
13) Next Hop for Originated Route
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: No reponses, assumed consensus to keep things the same.

Discussion:

There was a one-message thread entitled "next hop for originated route".
This message received no reponse, so the assumption is that there is
a consensus to keep things as they are.

----------------------------------------------------------------------------
14) NEXT_HOP to Internal Peer
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: One concuring reponse, no text proposed.

Discussion:

The thread entitled "NEXT_HOP to internal peer" starts with this question:

When sending a locally originated route to an internal peer, what should
NEXT_HOP be set to?

One response suggested that we add a line stating that the NEXT_HOP address
originates from the IGP.

----------------------------------------------------------------------------
15) Grammer Fix
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: 
  Change:
    "The Prefix field contains IP address prefixes ..."
  To:  
    "contains an IP address prefix ..."

Discussion:
The thread entitled "Review comment: bottom of page 16" corrects a grammer
mistake by suggesting we change:

"The Prefix field contains IP address prefixes ..."

to:

"contains an IP address prefix ..."

Yakov responded that this will be fixed in -18.

The consensus seems to be to correct this, and go with the new text.

----------------------------------------------------------------------------
16) Need ToC, Glossary and Index
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Need to add a Table of Contents (ToC), Glossary and Index to the 
 draft.  Will be added in draft -18.

Discussion:

The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread suggests:

1. Document needs, Table of Contents, Glossary, and Index

2. Paths, Routes, and Prefixes need to be defined in the spec early on (like
in a glossary), so it is obvious what is implied.

Yakov responded that draft -18 will have a ToC and definition of commonly
used terms.

----------------------------------------------------------------------------
17) Add References to other RFC-status BGP docs to base spec.
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Add references to other RFC-status BGP docs to the base spec.

Discussion:

The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread then changes
titles to: "Review of draft-ietf-idr-bgp4-17.txt" and goes on to
suggest:

3. All BGP Extensions described in other documents that made it to RFC
status should be at least referenced in the Reference section P.64. This is
justifiable since it's the core BGP standard spec.

----------------------------------------------------------------------------
18) IP Layer Fragmentation 
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: No need to mention IP Layer Fragmentation in the BGP specification,
 since this is taken care of at the TCP level.

Discussion:

1. P.6	section 4. Message Formats, its possible for the source BGP peer IP
layer to fragment a message such that the receiving BGP peer socket layer
would have to reassemble it. Need to mention this, since BGP implementations
are required to do this.

The response to this was that, while true, reassembly is something that
is inherent in the TCP layer that BGP rides over.  Therefore, this is
something that is in the TCP spec, and needn't be repeated in the BGP spec.
This comment was reaffirmed.  There seems to be consensus that this isn't
something that needs to be in the BGP spec.

----------------------------------------------------------------------------
19) Appendix Section 6.2: Processing Messages on a Stream Protocol
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: This is a hotly debated issue.  The choices are outlined in
  the discussion.  We can: 1) Leave things the way they are 2)
  Take Curtis's suggestion for change 3) Remove the section entirely.

Discussion:

This first came up in reponse to Issue 17:

There was one comment suggesting that section 6.2 (Processing Messages
on a Stream Protocol" mentioned this.

The original reviewer reponsed that the out-of-scope comment was out-of-place
and refered the reponder to section 6.2 (appendix 6)

The original reviewer stated that he is happy with just adding a
reference to section 6.2 in appendix 6 and leaving it at that.

Curtis suggested we just add a reference to Stevens in appendix 6. 6.2
and be done with it.  Specifically:

  6.2  Processing Messages on a Stream Protocol

     BGP uses TCP as a transport mechanism.  If you are unsure as to
     how to handle asynchronous reads and writes on TCP sockets please
     refer to Unix Network Programming [RWStevens] or other
     introductory text for programming techniques for the operating
     system and TCP implementation that you are using.

There were further suggestions to remove the section entirely as out-of-scope.
At least 3 people agreed with this.

Alex responded that he sees no reason to remove it, but wouldn't have a
problem if the WG decides to do so.

----------------------------------------------------------------------------
20) Wording fix in Section 4.3
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: A small change for clarity in section 4.3

Discussion:

This suggestion grew out of the discussion on Issue 18.

The following change was suggested in section 4.3, second line of the 
first paragraph:

s/UPDATE packet/UPDATE message/

Yakov agreed to this change and updated the draft.

----------------------------------------------------------------------------
21) Authentication Text Update
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: A small change to the "Authentication Data:" section to mention
  well established MD5 support.

Discussion:

  P. 10, "Authentication Data:" section you might want to add this,
  It is also possible to use MD5 (RFC2385) at the transport layer to validate
  the entire BGP message.

There was no discussion on this issue.

----------------------------------------------------------------------------
22) Scope of Path Attribute Field
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Add a sentance to clarify that all attributes in the Path Attribute
  field beling to all prefixes in the NLRI.

Discussion:

  P. 12, right after "Path Attributes". The following sentence should be
  added to this section to clarify the scope of the Path Attribute field.
  "All attributes in the Path Attribute field represent the characteristics of
  all the route prefixes defined in the NLRI field of the message".

There was no discussion on this issue.

----------------------------------------------------------------------------
23) Withdrawn and Updated routes in the same UPDATE message
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: For various reasons, not least of which is compatability with
  existing implementaions, the decision was made to keep thing the way
  they are.

Discussion:

4. P.16, last paragraph in section 4.3 as stated,
 "An UPDATE message should not include the same address prefix in the
  WITHDRAWN ROUTES and Network Layer Reachability Information fields,
  however a BGP speaker MUST be able to process UPDATE messages in this
  form. A BGP speaker should treat an UPDATE message of this form as if
  the WITHDRAWN ROUTES doesn't contain the address prefix."

This complexity could have been avoided if withdrawn routes and NRLI
prefixes with their attributes were mutually exclusive of each other and
appeared in different update messages. If that was the case, the priority of
which field to process first would have been as simple as using "first come,
first served" message processing approach.

Yakov commented that this would make the case where they are both in the
same message unspecified.

John commented that this is something we don't want to change this late in
the game.  Although it was acknowledged that this might be a good change
if we were working from a clean slate.

Ben acceeded that this was somewhat wishful thinking on his part.

Curtis's comment seems to coincide with this message, stating:

The existing rules are very clear.

Summarized:

  If an UPDATE contains only a withdraw for a prefix, then withdraw
  whatever route the peer had previously sent.

  If an UPDATE contains the prefix only in the NRLI section, replace
  whatever route had previously been advertised by the peer or add a
  route if there was no previous route, in both cases adding a route
  with the current attributes.

  Don't put the same prefix in the same in both the withdraw and NRLI
  section of the same update.

  If you receive an UPDATE with the same prefix in both the withdraw
  and NRLI, ignore the withdraw.  [Some older implementations thought
  this was a good way to say "delete then add".]

  Process UPDATEs from the same peer in the order received.

And goes on to say, that to him, these rules are clear from the existing
text.

Consensus is that while this would be nice, we need to stick with what
we have, and move on.

----------------------------------------------------------------------------
24) Addition or Deletion of Path Attributes
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: There are two views here.  One argues that the mechanism for
 adding and deleting path attributes should be explicitly stated in the
 draft.  The other argues that this is tied to the definition of "route"
 and additional specification is unnecessary.

Discussion:

5. P. 20 Its not stated how we delete or modify Path Attributes associated
with NLRI prefixes.

A response to this comment said that this is implicit in the definition
of "route" and the general withdraw/replace behavior and therefore doesn't
need to be repeated.

Ben responded saying that, while there was an assumption, there was
no well defined mechanism, and this leads to ambiguity.

John reponded, no need to define everything explicity, or we'll be here
forever.

----------------------------------------------------------------------------
25) NEXT_HOP Semantics
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: After reponders pointed out another sentance, this comment 
 was resolved. Things will stay the way they are.

Discussion:

1. P.28, 2nd to last paragraph. The line that reads, "To be semantically
correct, the IP address in the NEXT_HOP must not be the IP address of the
receiving speaker, and the NEXT_HOP IP address must either be the sender's
IP address (used to establish the BGP session), or the interface associated
with the NEXT_HOP IP address must share a common subnet with the receiving
BGP speaker..."

This is not always true, what if the current ASBR BGP router is advertising
an external AS route (to a IBGP Peer) whose NEXT_HOP IP address is the IP
address of the EBGP peer in the other AS?

A response to this pointed out that right before this is a sentance stating
that this only applied to eBGP links, and only when the peers are one hop
from each other, so a modification is unnecessary.  This reponse was
confirmed with another.

The original reviewer acknowldeged this and withdrew the comment.

The consensus is to leave things the way they are.

----------------------------------------------------------------------------
26) Attributes with Multiple Prefixes
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: After some discussion, the consensus is to keep things the same
  since the suggested behavior is defined in the message format.

Discussion:

2. P. 29, Section 6.3. Add this rule near the attribute rules.
"Multiple prefixes that require the same attribute type with different
values must never appear in the same update message".

A response to this suggested that this text is unnesessary since this
behavior is ruled out by the way the message format is defined.

The original commentor agrees with the reponder.  The consensus is to
leave things the way they are.

----------------------------------------------------------------------------
27) Allow All Non-Destructive Messages to Refresh Hold Timer
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially 
Summary: It is agreed that this is a change that exceeds the original 
  goal of this draft revision.  This goal is to document existing 
  practice in an interoperable way.  If we should do it anyway has not
  been decided.

Discussion:

3. P. 29, Section 6.5, Please rewrite this sentence from:
    "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 ..."

 To This:
    "If a system does not receive successive KEEPALIVE and/or UPDATE
	and/or any other BGP message within the period specified in the Hold
	Time field of the OPEN message ..."

There is disagreement on this change. It has been discussed in other
threads.

The original commentor acknowledged that this is something that would
be "adding a new feature" as opposed to the stated goal of "documenting
what exists."  He suggested that the ADs decide if we should open the
door for new features or not.

----------------------------------------------------------------------------
28) BGP Identifier as Variable Quantity
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: The consensus is that changing the BGP Identifier in the base
  draft is out-of-scope at this point in the draft evolution.

Discussion:

4. P. 31, section 6.8, Please rewrite this sentence from:
   "Comparing BGP Identifiers is done by treating them as (4-octet long)
    unsigned integers."

 To This:
   "Comparing BGP Identifiers is done by treating them as large numbers based
   on their IP Address type (e.g. IPv4, IPv6, etc.)."

A reponse to this was that since BGP Identifier is defined in the base
spec as a 4 byte unsigned integer, and not a variable quantity, the
sentance as written is acceptable.  This was also confirmed by another
response.

The original commentor was thinking of IPv6, and providing sufficent
space to allow a full v6 address to be used.

Again, reponders said that this is out-of-scope for the current draft.

----------------------------------------------------------------------------
29) State Why Unresolveable Routes Should Be Kept in Adj-RIB-In
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary:  Explicity state that there is a chance routes can become 
  resolveable, and should therefore be kept in Adj-RIB-In.  No text
  has yet been suggested.

Discussion:

 5. P.46, last sentence, "However, corresponding unresolvable routes SHOULD
 be kept in the Adj-RIBs-In."  It would helpful if the author states why
 unresolvable routes should be kept in Adj-RIBs-In?

 A reponse to this stated "In case they become resolveable"

 The original commentor stated that:
 Then the point that the peer will not refresh the route if we drop
 them (unless we use Route Refresh) because they are unreachable should be
 made.

----------------------------------------------------------------------------
30) Mention Other Message Types
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Do we add this explicity?  If so when?  With what text?

Discussion:

1. P. 7 Type: Need to add the new message types such as, Capability
Negotiations (RFC2842), Route Refresh, etc.

One reponse argued that these are out-of-scope of the base document.
One reponse agreed, but thought that it should be capability and not
message type. The original commentor reponsed about Message type
from the capability draft.

Sue mentioned this would be added in the second round.

----------------------------------------------------------------------------
31) Add References to Additional Options
----------------------------------------------------------------------------
Status: Consensus, but no text
Change: Yes
Summary: Consensus that we should add the references.  No text proposed.

Discussion:

2. P. 9, right after "This document defines the following optional
parameters:"
Need to mention possible options, such as: Capabilitites (RFC2842),
Multiprotocol extensions (RFC2858), Route Refresh (RFC2918).

One reponse agreed that adding references would be fine.
A second reponse agreed.

----------------------------------------------------------------------------
32) Clarify EGP Reference
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Need to clarify the EGP Reference, since there seems to be some
  confusion on the issue.

Discussion:

3. P. 13, EGP, are there other EGP protocols other than BGP that are in use?
If not, change EGP to BGP.

A response to this suggested that we add a reference to [1] (the EGP
spec) here.

Another reponse clarified that this refers to EGP-the-protocol and
NOT the class.

Another response disagreed, but suggested that:

IGP = network was explicitly introduced into bgp (network cmd)
INCOMPLETE = network was implicitly introduced into bgp (redistribute)
EGP = other

The original commentor thought that this refered to EGP-the-class of
protocols.   And why not use BGP therefore, as the only EGP.

There was some disucssion over whether or not we should mention something
that is historical.

Jeff suggested a footnote in the Origin section about EGP.

Curtis suggested that we state that the EGP in ORIGIN is depricated,
but retain the value to document what it used to mean.

This reviewer thinks a statement about whether this "EGP" origin refers
to the protocol or the class or protocols would be useful.

----------------------------------------------------------------------------
32.1) EGP ORIGIN Clarification
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Proposal to update the EGP ORIGIN section.

Discussion:

This discussion is picked up again in the "Review of draft-ietf-idr-bgp4-17"
thread, where specific text is proposed:

Old:

            "ORIGIN is a well-known mandatory attribute that defines the
            origin of the path information.  The data octet can assume
            the following values:

                  Value		Meaning

                  0	    IGP - Network Layer Reachability Information
                               is interior to the originating AS

                  1	    EGP - Network Layer Reachability Information
                               learned via the EGP protocol

                  2	    INCOMPLETE - Network Layer Reachability
                               Information learned by some other means"
New:

            "ORIGIN is a well-known mandatory attribute that defines the
            origin of the path information.  The data octet can assume
            the following values:

                  Value		Meaning

                  0	    IGP - NLRI was explicitly introduced into bgp

                  1	    EGP - this value was administratively
                               configured to affect policy decisions or
                               NLRI was learned via the EGP protocol [1]

                  2	    INCOMPLETE - NLRI was implicitly introduced
                                      into bgp"

since:
1) The network command sets the origin to IGP and I remember seeing
somewhere that only static routes should be set to IGP.
2) The primary use of EGP value is policy
3) EGP seems to still exist, anyway even if it does not it is
not worth re-writing the world.

Also, change:
"5.1.1 ORIGIN


   ORIGIN is a well-known mandatory attribute.	The ORIGIN attribute
   shall be generated by the autonomous system that originates the
   associated routing information. It shall be included in the UPDATE
   messages of all BGP speakers that choose to propagate this
   information to other BGP speakers."

to:
"5.1.1 ORIGIN

   The value of the ORIGIN attribute shall be set by the speaker
   that originates the associated NLRI.	 Its value shall not be
   changed by any other speaker unless the other speaker is
   administratively configured to do so to affect policy
   decisions."

since:
1) It is already defined as well-known mandatory attribute.
2) It may be set differently within the same AS (not saying this is good).
3) It is commonly used for policy, but by default does not get changed.
4) Speakers have no choice, it is mandatory.

Yakov reponsed that the root of the EGP problems is perhaps best addressed
by the text documented in issue 32.2.

----------------------------------------------------------------------------
32.2) BGP Desitnation-based Forwarding Paradigm
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Proposal to clarify BGP's support for the destination-based
  forwarding paradigm.  There seems to be consensus that some sort of 
  updated text is good, but there is not yet consensus on which text
  that should be.

Discussion:

In response to these proposals, Yakov proposed that the real problem is that
it is not clear that BGP is build to support the destination-based
forwarding paradigm.  To fix this, it was propsed that:

<OLD>

   To characterize the set of policy decisions that can be enforced
   using BGP, one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with) in
   neighboring ASs only those routes that it itself uses. This rule
   reflects the "hop-by-hop" routing paradigm generally used
   throughout the current Internet. Note that some policies cannot
   be supported by the "hop-by-hop" routing paradigm and thus
   require techniques such as source routing (aka explicit routing)
   to enforce. For example, BGP does not enable one AS to send
   traffic to a neighboring AS intending that the traffic take a
   different route from that taken by traffic originating in the
   neighboring AS. On the other hand, BGP can support any policy
   conforming to the "hop-by-hop" routing paradigm. Since the
   current Internet uses only the "hop-by-hop" inter-AS routing
   paradigm and since BGP can support any policy that conforms to
   that paradigm, BGP is highly applicable as an inter-AS routing
   protocol for the current Internet.

<NEW>

   Routing information exchanged via BGP supports only the
   destination-based forwarding paradigm, which assumes that a
   router forwards a packet based solely on the destination address
   carried in the IP header of the packet. This, in turn reflects
   the set of policy decisions that can (and can not) be enforced
   using BGP. Note that some policies cannot be supported by the
   destination-based forwarding paradigm and thus require techniques
   such as source routing (aka explicit routing) to enforce. Such
   policies can not be enforced using BGP either. For example, BGP
   does not enable one AS to send traffic to a neighboring AS
   intending that the traffic take a different route from that
   taken by traffic originating in the neighboring AS.	On the
   other hand, BGP can support any policy conforming to the
   destination-based forwarding paradigm.

Curtis thinks the newer text here is more clear.

In reponse to the new text, Christian Martin propsed a slightly different
new text:

   Routing information exchanged via BGP supports only the
   destination-based forwarding paradigm, which assumes that a
   router forwards a packet based solely on the destination address
   carried in the IP header of the packet. This, in turn reflects
   the set of policy decisions that can (and can not) be enforces
   using BGP. Note that some policies cannot be supported by the
   destination-based forwarding paradigm and thus require techniques
   such as source routing (aka explicit routing) to enforce. Such
   policies can not be enforced using BGP either. For example, BGP
   does not enable one AS to send traffic to a neighboring AS
   based on prefixes originating from the local AS.  On the
   other hand, BGP can support any policy conforming to the
   destination-based forwarding paradigm.

To which Yakov replied:

    Routing information exchanged via BGP supports only the
    destination-based forwarding paradigm, which assumes that a
    router forwards a packet based solely on the destination address
    carried in the IP header of the packet. This, in turn, reflects
    the set of policy decisions that can (and can not) be enforces
    using BGP. Note that some policies cannot be supported by the
    destination-based forwarding paradigm, and thus require techniques
    such as source routing (aka explicit routing) to enforce. Such
    policies can not be enforced using BGP either. For example,
    BGP does not enable one AS to send traffic through a neighboring
    AS to some destination (which is outside of the neighboring
    AS, but is reachable through the neighboring AS) intending that
    the traffic take a different route from that taken by the traffic
    to the same destination that originating in the neighboring AS.
    On the other hand, BGP can support any policy conforming to
    the destination-based forwarding paradigm.

And Chris reponsed:

    Routing information exchanged via BGP supports only the
    destination-based forwarding paradigm, which assumes that a
    router forwards a packet based solely on the destination address
    carried in the IP header of the packet. This, in turn, reflects
    the set of policy decisions that can (and can not) be enforces
    using BGP. Note that some policies cannot be supported by the
    destination-based forwarding paradigm, and thus require techniques
    such as source routing (aka explicit routing) to enforce. Such
    policies can not be enforced using BGP either. For example,
    BGP does not enable one AS to send traffic through a neighboring
    AS to some destination beyond the neighboring AS intending that
    the traffic take a different route from that taken by traffic
    to the same destination which originates in the neighboring AS.
    In other words, the BGP policy of a local AS cannot affect the
    downstream (aka, away from the local AS) forwarding policy of a
    remote AS.	On the other hand, BGP can support any policy conforming
    to the destination-based forwarding paradigm.

Tom Petch prefered Yakov's second formulation, with these changes:

     policies can not be enforced using BGP either. For example,
     BGP does not enable one AS to send traffic
!    to a neighboring AS for forwarding to some destination (reachable
through but) beyond
!    that neighboring AS intending that
!    the traffic take a different route to that taken by the traffic
!    originating in the neighboring AS (for that same destination).

     On the other hand, BGP can support any policy conforming to
     the destination-based forwarding paradigm.

Yakov agreed to Tom's suggested changes.

----------------------------------------------------------------------------
33) Add "Optional Non-Transitive" to the MED Section
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Do we add this text, or no?

Discussion:

4. P.23, change the following:

"The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
 links to discriminate among multiple exit or entry points to the same
 neighboring AS ..."

 To the following:

"The MULTI_EXIT_DISC is an optional non-transitive attribute which may be
used on external (inter-AS) links to discriminate among multiple exit or
entry points to the same neighboring AS ..."

A reponder disagreed, and stated reasons "covered elsewhere"
Original commentor asked for reasons, since the modification seemed obvious
to him.

----------------------------------------------------------------------------
34) Timer & Counter Definition
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: No discussion, no text proposed.

Discussion:

5. In section 8, there are a number of Timers, Counters, etc. that need to
be explicitly defined before they are used by the FSM. Perhaps these
definitions should go in the Glossary section.

----------------------------------------------------------------------------
35) Fix Typo
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Fix a Typo.  No discussion, but this seem clear.

Discussion:

1. P. 41. Typing error, "Each time time the local system...".

----------------------------------------------------------------------------
36) Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: This change requires a glossary. No Glossary text has been 
  proposed.

Discussion:

2. Section 9.1, Need to have Adj-RIB-In, Adj-RIB-Out, and Loc-RIB in the
glossary, so when they are used in section 9.1, it is well understood what
they are.

----------------------------------------------------------------------------
37) Combine "Unfeasable Routes" and "Withdrawn Routes"
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: No definition extant for "Unfeasable Routes". 

Discussion:

3. P. 45, Phase I, There is no definition of what are unfeasible routes? Are
they the same as withdrawn routes? If so, the two should be combined to one
name.
 
----------------------------------------------------------------------------
38) Clarify Outbound Route Text
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Consensus that the issue was suffiecently minor to leave things
  alone.

Discussion:

4. P. 50,  line, "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 (see 9.2)."

Would like to rephrase the sentence for clarity,
"If a route in Loc-RIB is excluded from a particular Adj-RIB-Out and was
previously advertised via Adj-RIB-Out, it must be withdrawn from service by
means of an UPDATE message (see 9.2)."

One comment suggested either leave it alone, or remove "via Adj-RIB-Out".

The original commentor withdrew the comment.

----------------------------------------------------------------------------
39) Redundant Sentance Fragments
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Redundant definitions, clarity requested.  Possible solution below.

Discussion:

5. P. 50, section 9.1.4, The two fragments of this sentence are redundant
and don't say anything new or simplify the content. Just keep one fragment.

"A route describing a smaller set of destinations (a longer prefix) is said
to be more specific than a route describing a larger set of destinations (a
shorted prefix); similarly, a route describing a larger set of destinations
(a shorter prefix) is said to be less specific than a route describing a
smaller set of destinations (a longer prefix)."

There was a comment that disagreed, thinking that both "more specific"
and "less specific" need to be defined.	 And suggested that only the
third and forth parentheses need to be dropped.

The original commentor agreed with the parentheses changes.

----------------------------------------------------------------------------
40) Section 9.2.1.1 - Per Peer vs. Per Router MinRouteAdvertisementInterval
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: The consensus is that current practice allows for the 
  MinRouteAdvertisementInterval to be set per peer, so the text should
  be kept the same.

Discussion:

6. P. 52, section 9.2.1.1 Change this sentence for clarity,
   "This rate limiting procedure applies on a per-destination basis, although
    the value of MinRouteAdvertisementInterval is set on a per BGP peer basis."

 To This:
   "This rate limiting procedure applies on a per-destination basis, although
    the value of MinRouteAdvertisementInterval is set on a BGP router (same
    value for all peers) basis."

There was a comment disagreeing with this proposal.
It was later elaborated on to include that the reason for diagreement was
that the proposed changes changed the protocol and not just a practice
clarification.
Ben reponded asking for how this is a protocol change, he saw it as
a clarification.  Perhaps there is something deeper that needs to be
clarified?
Again, response to this is that current implementations allow the
MinRouteAdvertisementInterval to be set per-peer, not per-router.

Original reviwer conceeded the point.

----------------------------------------------------------------------------
41) Mention FSM Internal Timers
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: No discussion on this issue.  No text proposed.  Perhaps this is
  in the FSM section of the draft?

Discussion:

7. P. 61, item 6.4. Although all the BGP protocol interfacing timers are
   mentioned, there are a few FSM internal timers mentioned in the spec that
   need to be covered  here as well.

----------------------------------------------------------------------------
42) Delete the FSM Section
----------------------------------------------------------------------------
Status: Consensus
Change: Potentially
Summary: There was some confusion on the question: Is the FSM draft going
  to be a seperate document, or incorporated into the base draft.  The
  consensus is that it is going to become part of the base draft, so the
  FSM section will be kept, and elaborated on.

Discussion:

8. Since there is going to be an FSM spec, do we need to have FSM
   descriptions in this spec. Maybe the FSM section should be delete.

There was one response agreeing with this.
One reponse asking for claificaiton:  Was this a move to remove
section 8. Finite State Machine from the base draft??
The original reviewer said, yes, when Sue's FSM draft becomes a WG
document, we should remove section 8 from the base draft.
Yakov asked that the AD's provide input on this suggestion.

Alex responded saying that the FSM draft is going to be part of the base
spec, and not another document once the FSM words are approved.

----------------------------------------------------------------------------
43) Clarify the NOTIFICATION Section
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: 
  Replace:

   "If a peer sends a NOTIFICATION message, and there is an error in that
   message, there is unfortunately no means of reporting this error via
   a subsequent NOTIFICATION message."

  With:

   If a peer sends a NOTIFICATION message, and the receiver of the
   message detects an error in that message, the receiver can not
   use a NOTIFICATION message to report this error back to the peer.
 
Discussion:

The "NOTIFICATION message error handling" thread proposed:

Please change"
"If a peer sends a NOTIFICATION message, and there is an error in that
   message, there is unfortunately no means of reporting this error via
   a subsequent NOTIFICATION message."

To:
"If a peer receives a NOTIFICATION message, and there is an error in that
   message, there is unfortunately no means of reporting this error via
   a subsequent NOTIFICATION message."

This reversal of meaning met with disagreement, and this text was proposed
instead:

   All errors detected while processing the NOTIFICATION message cannot be
   indicated by sending subsequent NOTIFICATION message back to
   originating peer, therefore there is no means of reporting NOTIFICATION
   message processing errors. Any error, such as an unrecognized
   Error Code or Error Subcode, should be noticed, logged locally, and
   brought to the attention of the administration of the peer that has
   sent the message. The means to do this, however, lies outside the scope
   of this document.

The original posted agreed with the intent of the respondant's text, thought
it was too wordy, but did not propose alternate text.

Yakov replied with this propsed text:

    If a peer sends a NOTIFICATION message, and the receiver of the
    message detects an error in that message, the receiver can not
    use a NOTIFICATION message to report this error back to the peer.

Two responses liked this new text.  Unless there are objections, we'll
consider that a consensus.

----------------------------------------------------------------------------
44) Section 6.2: OPEN message error handling
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: One commentor observed that the spec seems to specify behavior
  that doesn't seem to be observed by extant implementations, and suggested
  modifications to the spec.  There is no consensus as to if this observation
  holds across implementations, or if it does, if we should change the spec.

Discussion:

The "BGP4 draft ; section 6.2" thread began with a discussion of
section 6.2: OPEN message error handling.  Specifically:

"If one of the optional parameters in the Open mesage is not recognized,
then the error subcode is set to 'unsupported optional parameters"

We have hit on this line when we were testing a BGP connection between
a speaker that supported capability negotiation and a speaker that did
not.

The speaker that did not support the neogotiation closed down the peering
session using the error clause mentioned above. Sometimes this lead
to the other router to repeat the OPEN message with the Capability optional
parameter; a game that went on for minutes.

This router manufacturer stated in a reply to this that :
"One should not close down the connection if an optional parameter
is unrecognised. That would make this parameter basically mandatory.
This is an well known error in the BGP spec. Neither Cisco or Juniper
do this"

If this is true it might be good to adapt the text.

The response to this quoted RFC2842, Capabilities Advertisement with BGP-4:

   A BGP speaker determines that its peer doesn't support capabilities
   advertisement, if in response to an OPEN message that carries the
   Capabilities Optional Parameter, the speaker receives a NOTIFICATION
   message with the Error Subcode set to Unsupported Optional Parameter.
   In this case the speaker should attempt to re-establish a BGP
   connection with the peer without sending to the peer the Capabilities
   Optional Parameter.

The original poster responded:

This section from the Capabilities Advertisement RFC, is indeed
inline with the section 6.2 of the BGP4 specification. For me however
the question remains if most implementations do no simply ignore optional
parameters that are unknown. And if so, if the text stated above reflects
what is implemented by routers that do not have capability advertisement
at all.

----------------------------------------------------------------------------
45) Consistant References to BGP Peers/Connections/Sessions
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Update the document to make references to BGP Peers, Connections
  and Sessions more clear and consistant.  Proposed text is below, as
  well as current comments.

Discussion:

Ben proposed and Yakov responded:

> 1. Throughout the document we have various ways of naming the BGP
>    peering communication. 1) BGP Session, 2) BGP Peering Session,
   
I'll replace "session" with "connection".

>    3) TCP Connection,

The spec doesn't name BGP peering communication as "TCP connection";
TCP connection is used to establish BGP connection. So, TCP connection
and BGP connection are two different things.

>    4) BGP Connection,

The spec is going to use this term (see above).

>                  5) BGP Peering Connection,

I'll replace "BGP peering connection" with "BGP connection".

> 6) Connection,

The text uses "connection" whenever it is clear from the context
that it refers to "BGP connection" (or "TCP connection").

>    7) BGP Speaker Connection.
    
I'll replace "BGP Speaker Connection" with "BGP connection".

>  
>    BGP router: 1) BGP Speaker, 2) speaker, 3)local speaker

The term "speaker" is used when it is clear from the context that
we are talking about "BGP speaker".

> 2. Change Internal peer to IBGP Peer.

IBGP stands for "BGP connection between internal peers". Therefore  
the term "IBGP Peer" would mean "BGP connection between internal
peers peer".  That doesn't seem appropriate.

This issue has had some discussion, and section 3 was referenced, specifically:

Refer to Section 3 - Summary of operations which clearly states that " .. a
peer in a different AS is referred to as an external peer, while a peer in
the same AS may be described as an internal peer. Internal BGP and external
BGP are commonly abbreviated IBGP and EBGP"

After more discussion it was decided that we should modify a paragraph on
page 4 to read:

   If a particular AS has multiple BGP speakers and is providing
   transit service for other ASs, then care must be taken to ensure
   a consistent view of routing within the AS. A consistent view
   of the interior routes of the AS is provided by the IGP used  
   within the AS. For the purpose of this document, it is assumed
   that a consistent view of the routes exterior to the AS is
   provided by having all BGP speakers within the AS maintain 
   IBGP with each other. Care must be taken to ensure that the   
   interior routers have all been updated with transit information
   before the BGP speakers announce to other ASs that transit  
   service is being provided.

This change has consensus.

> 3. Change External peer to EBGP Peer.

Ditto.

Alex responded that haveing explicit definitions would be nice.  This 
ties into the general glossary suggestion (see issues 16, 34 & 36).

He also suggested that:

"BGP session" which works over a "TCP connection" would be closer to the 
terminology we're actually using now and would avoid possible confusions 
when people read terms like "Connection collision") 

This was discussed in the "Generial Editorial Comment" thread.

----------------------------------------------------------------------------
46) FSM Connection Collision Detection
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: We need to decide which text (the original base draft, or the FSM
  draft) needs to be updated to clear up this issue.  There does appear to
  be agreement that some clarification would be beneficial.

Discussion:

The original reviewer (Tom) commented that the base draft, FSM section, could
use some clarification around the area of connection collision detection.
Specifically, he argued that it seems like there are actually 2 FSM's
depending on which one backs off in the case of a collision.  He 
proposed this text to clear things up:

"8 BGP FInite State Machine  

This section specifies BGP operation - between a BGP speaker and its
peer over a single TCP connection - in terms of a Finite State Machine
(FSM).  Following is a brief summary ... "(as before)
 
Instead of just

"This section specifies BGP operation in terms of a Finite State
Machine (FSM).  Following is a brief summary ... "(as before).  

Curtis responded:

   There is one FSM per 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.
   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 connection that is closed should be disposed of.

I'm not sure which document containing an FSM we should be reading at
this point, but we could add the above paragraph if we need to
explicitly state that the extra connection and its FSM is disposed of
when a collision is detected.

When a TCP accept occurs, a connection is created and an FSM is
created.  Prior to the point where the peer associated with the
connection is known the FSM cannot be associated with a peer.  The
collision is a transient condition in which the rule of "one BGP
session per peer" is temporarily violated and then corrected.

This is discussed in the "FSM but FSM of what?" thread.

----------------------------------------------------------------------------
47) FSM - Add Explicit State Change Wording
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: A desire for explicit state change wording was expressed.  No
  text was proposed.  Additional information was solicited, but the
  discussion may have gone private.

Discussion:

The initial reviewer:

In most places, the actions taken on the receipt of an event include
what the new state will be or that it remains unchanged.  But there
are a signficant number of places where this is not done (eg Connect
state events 14, 15, 16).  I would like to see consistency, always
specify the new/unchanged state.  Else I may be misreading it.

There was a reponse asking for specific text, and offering to take the
discussion private.

This is discussed in the "FSM words - state changes" thread.

----------------------------------------------------------------------------
48) Explicitly Define Processing of Incomming Connections
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Suggested that we add explicit definitions for incomming 
  connection processing, no text proposed.

Discussion:

Alex suggsted we explicity define:

   - processing of incoming TCP connections (peer lookup, acceptance,
     FSM creation, collision control,)

No text was proposed.

This was discussed in the "Generial Editorial Comment" thread.

----------------------------------------------------------------------------
49) Explicity Define Event Generation
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Suggested that we explictiy define BGP message processing. No text
  proposed.

Discussion:

Alex suggsted we explicity define:

   - generation of events while processing BGP messages, i.e.,
     the text describing message processing should say where
     needed that a specific event for the BGP session should
     be generated.

No text was proposed.

This was discussed in the "Generial Editorial Comment" thread.

----------------------------------------------------------------------------
50) FSM Timers 
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Discussion tabled, because new document version rendered the 
 discussion moot.

Discussion:

This discussion began with a suggestion that the timers currently in the
FSM:

In the 26Aug text, I find the timer terminology still confusing.
Timers can, I find,
stop
start
restart
clear
set
reset
expire

Can be cleaned up and simplified to:

start with initial value (spell it out just to be sure)
stop
expire

A reponse to this proposal was, that the existing set is clear, and that
the proposed set is insufficently rich to describe a concept like "reset"
which encompases:  "Stop the timer, and reset it to its initial value."

This discussion reached an impasse, when Sue pointed out that the text
had been updated, and to please review the new text.

This was discussed in the "FSM more words" thread.

----------------------------------------------------------------------------
51) FSM ConnectRetryCnt
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Discussion tabled, because new document version rendered the
 discussion moot.

Discussion:

This started with the observation that the ConnectRetryCnt "seems to
have lost its purpose."  It was suggested that this be made a 
Session Attribute, along with:  OpenDelayTimer and DelayOpenFlag.

Curtis explained that the current purpose of the ConnectRetryCnt is
something to be read by the MIB.  He also advocated against adding
the additional Session Attributes.

----------------------------------------------------------------------------
52) Section 3: Keeping routes in Adj-RIB-In
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: 
  Add:
    To allow local policy changes to have the correct effect without
    resetting  any BGP connections, a BGP speaker SHOULD either
    (a) retain the current version of the routes advertised to it
    by all of its peers for the duration of the connection, or (b)
    make use of the Route Refresh extension [12].

Discussion:

This thread started with a question about why we should retain routes in
the Adj-RIB-In, and how it relates to the Route Refresh extention.

mrr proposed this text:

  ... Therefore, a BGP speaker must either retain the current version of
  the routes advertised by all of its peers for the duration of the
  connection, or make use of the Route Refresh extension [12].  This
  is necessary to allow local policy changes to have the correct effect
  without requiring the reset of any peering sessions.

  If the implementation decides not to retain the current version of
  the routes that have been received from a peer, then Route Refresh
  messages should be sent whenever there is a change to local policy.

Yakov later suggsted this text, with a slight rewording:

    To allow local policy changes to have the correct effect without
    resetting  any BGP connections, a BGP speaker SHOULD either
    (a) retain the current version of the routes advertised to it
    by all of its peers for the duration of the connection, or (b)
    make use of the Route Refresh extension [12].

mrr reponded that he was fine with Yakov's suggestions.

This was discussed in the "Proxy: comments on section 3" thread.

----------------------------------------------------------------------------
53) Section 4.3 - Routes v. Destinations - Advertise
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Clean up the wording in text surrounding the UPDATE message.
 There was no discussion or consensus on this.  But, does the consensus
 change reached in issue 54 address this sufficently?

Discussion:

This issue arose out of this question to the list:

Since:

"For the purpose of this protocol, a route is defined as a unit of
information that pairs a set of destinations with the attributes of a
path to those destinations.  The set of destinations are the systems
whose IP addresses are reported in the Network Layer Reachability
Information (NLRI) field and the path is the information reported in the
path attributes field of the same UPDATE message."

When I read section 4.3:

"An UPDATE message is used to advertise feasible routes sharing common
   path attribute to a peer, or to withdraw multiple unfeasible routes
   from service (see 3.1)."

Shouldn't the text read "... advertise feasible [prefixes |
destinations] sharing common path attribute(S)to a peer ...", because:

1) A route is defined as quoted above from section 3.1?

or since ...

"An UPDATE message can advertise at most one set of path attributes, but
multiple destinations ..."

2) make "routes" in the orignal singular.

There was no discussion or consensus on this.

This was discussed in the "Review Comments: Section 4.3: "routes" vs.
destinations - advertise" thread.

----------------------------------------------------------------------------
54) Section 4.3 - Routes v. Destinations - Withdraw
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Change the definition of "route" as it currently stands to:

   For the purpose of this protocol, a route is defined as a unit
   of information that pairs a set of destinations with the attributes
   of a path to those destinations. The set of destinations are
   systems whose IP addresses are contained in one IP address prefix
   carried in the Network Layer Reachability Information (NLRI)
   field of an UPDATE message and the path is the information
   reported in the path attributes field of the same UPDATE message.

   Multiple routes that have the same path attributes can be
   advertised in a single UPDATE message by including multiple
   prefixes in the NLRI field of the UPDATE message.

Discussion:

This issue was brought up with this question:

When I read these two paragraphs at the end of section 4.3:

"An UPDATE message can list multiple routes to be withdrawn from
service.  Each such route is identified by its destination (expressed as
an IP prefix), which unambiguously identifies the route in the context
of the BGP speaker - BGP speaker connection to which it has been
previously advertised.

An UPDATE message might advertise only routes to be withdrawn from
service, in which case it will not include path attributes or Network
Layer Reachability Information. Conversely, it may advertise only a
feasible route, in which case the WITHDRAWN ROUTES field need not be
present."

It reads as if one must withdraw the _set of destinations_ advertised
with the route instead of just one or more destinations since route is
defined in section 3.1 as:

"For the purpose of this protocol, a route is defined as a unit of
information that pairs a set of destinations with the attributes of a
path to those destinations.  The set of destinations are the systems
whose IP addresses are reported in the Network Layer Reachability
Information (NLRI) field and the path is the information reported in the
path attributes field of the same UPDATE message."

Shouldn't the text change "routes" to destinations, or to prefixes?

The original commentor added this clarificaiton later:

I meant to say, the *same* set of destinations as those advertised
initially.  For example, NLRI with dest-a, dest-b and dest-c with the
same attributes is a "route".  The withdrawal of the "route" can be read
as one must withdraw all destinations originally advertised for that
route (dest-a, dest-b, dest-c) as a unit.

A first time reader could be left wondering if the above must be the
case, or it is valid for an implementation to withdraw just one of these
destinations (e.g. dest-b), leaving the others (dest-a, dest-c)
reachable with their attributes intact.

If there is no relationship between destinations when advertised as a
set of destinations in a route and those destinations that can be
withdrawn should be explicitly stated.  Otherwise, the draft should call
out that it is not legal to withdraw one prefix only in the set of
prefixes advertised as previously as route.

Matt suggested that since the definition seems to cause some confusion,
that we update teh definition to:

  "For the purpose of this protocol, a route is defined as a unit of
  information that pairs a set of destinations with the attributes of a
  path to those destinations.  The set of destinations are systems whose
  IP addresses are reported in one prefix present in the Network Layer
  Reachability Information (NLRI) field of an UPDATE and the path is the
  information reported in the path attributes field of the same UPDATE
  message.
 
  This definition allows multiple routes to be advertised in a single
  UPDATE message by including multiple prefixes in the NLRI field of
  the UPDATE.  All such prefixes must be associated with the same set
  of path attributes."

Yakov suggested some minor rewording:

   For the purpose of this protocol, a route is defined as a unit
   of information that pairs a set of destinations with the attributes
   of a path to those destinations. The set of destinations are
   systems whose IP addresses are contained in one IP address prefix
   carried in the Network Layer Reachability Information (NLRI)
   field of an UPDATE message and the path is the information
   reported in the path attributes field of the same UPDATE message.

   Multiple routes that have the same path attributes can be
   advertised in a single UPDATE message by including multiple
   prefixes in the NLRI field of the UPDATE message.

Both Jeff and Matt responded that they liked this text.

----------------------------------------------------------------------------
55) Section 4.3 - Description of AS_PATH length
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Should we clarify, such as adding an ASCII diagram, the description
 of AS_PATH length?  No diagram or text has been proposed.

Discussion:

This question was raised:

Length fields elsewhere in the draft specify the number of bytes that a
variable length field uses.  For AS_PATH, length is used as the number
of 2 byte AS numbers.  In the interest of not having to check other
sources to be sure, should the descripton of path segment value:
 
"The path segment value field contains one or more AS numbers, each
encoded as a 2-octets long field."

explicitly mention the number of bytes used by the variable length field?

Or, make the description of length explicitly mention that it is not the
length of the variable length field as is the case with other length fields?

One respone to this agreed that some more clarification would be good,
specifically an ASCII art diagram.  No diagram was proposed.

----------------------------------------------------------------------------
56) Section 6 - BGP Error Handling
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: We have some issues that were brought up that are already addressed.
 There is this text on the table:

   When any of the conditions described here are detected, a NOTIFICATION
   message with the indicated Error Code, Error Subcode, and Data
   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 close.

 And this propsoed move of the condition where you receive a route with
 your own AS to section 9:

   I would suggest to move this text to Section 9 (UPDATE message handling),
   as receiving a route with your own AS in the AS path isn't really  
   an error. It is just that usually (but not always) you can't put
   this route in your Adj-RIB-In.

 The other issues in the discussion have been addressed.

Discussion:

This discussion began with some suggestions on ways to clarify the text
in section 6 dealing with error handling.  The original comments, and
Yakov's response are below:

> At the beginning of Section 6. BGP Error Handling:
>
>
>     "When any of the conditions described here are detected, a
>     NOTIFICATION message with the indicated Error Code, Error Subcode,
>     and Data fields is sent, and the BGP connection is closed."
>
> There are several cases where the conditions described in this section
> do not result in the BGP connection being closed.  These conditions
> should either state that the connection stays up.  Another possibility
> is to remove "and the BGP connection is closed." above, and for each
> listed connection, state what happens to the BGP connection.  This
> already takes place for certain conditions, but isn't done consistantly.
    
How about replacing the above with the following:

   When any of the conditions described here are detected, a NOTIFICATION
   message with the indicated Error Code, Error Subcode, and Data
   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 close.
>
>
> I tried to list what I found (which may be wrong or incomplete) below:
>
>
>
> "If the NEXT_HOP attribute is semantically incorrect, the error should
> be logged, and the route should be ignored. In this case, no
> NOTIFICATION message should be sent."
>
> * Append the connection is not closed.

Done.

>   
> "(a) discard new address prefixes from the neighbor, or (b) terminate
> the BGP peering with the neighbor."
>
> * Append "the connection is not closed" to case (a)

added "(while maintaining BGP peering with the neighbor)" to case (a).
 
> 
>     "If
>     the autonomous system number appears in the AS path the route may be
>     stored in the Adj-RIB-In,"
> 
> * append and the BGP connection stays up.
>   
>                                 "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."
I would suggest to move this text to Section 9 (UPDATE message handling),
as receiving a route with your own AS in the AS path isn't really  
an error. It is just that usually (but not always) you can't put
this route in your Adj-RIB-In.
 
> 
> * Q1) does the BGP connection stay up?
 
yes.

> * Q2) what if the router isn't configured to accept routes with its own
> AS in the AS path?  One _may_ store the route in Adj-RIB-In, but if one
> doesn't want to?

So, don't store them.

> Is the BGP connection closed?  If so, what subcode?
    
The connection is *not* closed.

>     "If an optional attribute is recognized, then the value of this
>     attribute is checked. If an error is detected, the attribute is
>     discarded, and the Error Subcode is set to Optional Attribute Error.
>     The Data field contains the attribute (type, length and value)."
>
> * Append and the BGP conneciton stays up after "the attribute is discarded".

Since you have to close the connection, you have to discard all the
routes received via this connection, including the route with the
incorrect attribute. So, there is no need to say that "the attribute
is discarded".

This was discussed in the "-17 review Section 6 - BGP Error Handling."
thread.

----------------------------------------------------------------------------
57) Section 6.2 - Hold timer as Zero
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: It was suggested that we update the text to say that we MUST 
  reject hold time values of zero.  It was pointed out that this is not
  the case and the text should say the way it is.

Discussion:

In Section 6.2 on OPEN message error handling:

    If the Hold Time field of the OPEN message is unacceptable, then the
    Error Subcode MUST be set to Unacceptable Hold Time. An
    implementation MUST reject Hold Time values of one or two seconds.

I feel that text similar to:
  
"An implementation MUST also reject Hold Time values of zero received
from a peer in a different AS" should be considered for completeness.

A number of respondants pointed out that zero hold time is legitimate 
under certain circumstances.

This was discussed in the "-17 review, Section 6.2 - must reject hold time"
thread.

----------------------------------------------------------------------------
58) Deprication of ATOMIC_AGGREGATE
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: It is proposed that ATOMIC_AGGREGATE be depricated.  There has 
 not yet been any discussion on the proposed changes.

Discussion:

Jeff opened this discussion with:

Deprecation of ATOMIC_AGGREGATE:
    
[This is a summary of some discussions from those who have "been there,
done that" during the CIDR deployment period and also comments
from network operators on the NANOG list.]

When BGP-4 was originally drafted, the topic of aggregation was new
enough that people didn't exactly know how it would be used.   
Additionally, there were some transition issues when aggregated
networks would need to be de-aggregated and re-advertised into
a classful routing mesh such as BGP-3.

The ATOMIC_AGGREGATE flag was intended to prevent a route from being
de-aggregated when de-aggregation would introduce routing loops.
Note that de-aggregation in this context specifically means making
a less specific route into one or more more-specific routes.

The current BGP draft has two situations where ATOMIC_AGGREGATE
should be appeneded to a route:
1. When a route's AS_PATH is intentionally truncated, such as what
   happens by default on Cisco's, or using the "brief" option on
   GateD.  Juniper has a similar feature - I'm unsure of the default.
2. When two routes are implicitly aggregated in the LocRib such
   that a more specific route is not selected when a less specific
   route is from a given peer.

   Note that this particular feature is not implemented anywhere that
   I am aware of.

3. There is a third case not covered by the specification: Implicit
   aggregation on export - a more specific route is not exported
   and only a less specific one is.

When network operators were asked about de-aggregation practices,
I received about 40 responses.  The majority of these responses confused
de-aggregation with leaking existing more-specific routes that are
used internally rather than explicitly de-aggregating a less-specific route.
    
There were a very few cases of explicit de-aggregation.  One form
was done for purposes of dealing with another ISP creating a routing
DoS by advertising IP space that didn't belong to them - leaked more
specifics alleviated the problem in many cases.  (Note that this is
a security issue in the routing system.)

The second case was de-aggregating routes internally (and sending the
routes via IBGP marked with NO-ADVERTISE) for purposes of traffic
engineering routing internally where a given upstream failed to
provide enough routing information to allow traffic flows to be
optimized based on supplied prefixes.

My conclusions to this are:
1. De-aggregation is not a common practice.
2. It is no longer a major concern since classful inter-domain routing
   is pretty much gone.
3. The spec doesn't match reality and should be corrected.

My suggestions are thus this:
Section 5.1.6 should be updated as follows:
   ATOMIC_AGGREGATE is a well-known discretionary attribute.  Its
   use is deprecated.
   
   When a router explicitly aggregates several routes for the purpose of
   advertisement to a particular peer, and the AS_PATH of the aggregated
   route excludes at least some of the AS numbers present in the AS_PATH
   of the routes that are aggregated (usually due to truncation), the
   aggregated route, when advertised to the peer, MUST include the 
   ATOMIC_AGGREGATE attribute.
   
Section 9.1.4 should be updated as follows:
Original text:
:    If a BGP speaker receives overlapping routes, the Decision Process 
:    MUST consider both routes based on the configured acceptance policy.
:    If both a less and a more specific route are accepted, then the
:    Decision Process MUST either install both the less and the more
:    specific routes or it MUST aggregate the two routes and install the
:    aggregated route, provided that both routes have the same value of
:    the NEXT_HOP attribute.
:
:    If a BGP speaker chooses to aggregate, then it MUST add
:    ATOMIC_AGGREGATE attribute to the route. A route that carries
:    ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the
:    NLRI of this route can not be made more specific. Forwarding along
:    such a route does not guarantee that IP packets will actually
:    traverse only ASs listed in the AS_PATH attribute of the route.

Replace with:

   It is common practice that more specific routes are often
   implicitly aggregated by selecting or advertising only a less-specific
   route when overlapping routes are present.  As such, all routes
   SHOULD be treated as if ATOMIC_AGGREGATE is present and not be made
   more specific (de-aggregated).  De-aggregation may lead to routing
   loops.

Section 9.2.2 should remain as it is.
   
Implications of not making the above updates:
ATOMIC_AGGREGATE is not implemented as documented.  Current operational 
practices do not seem to often trigger situations that it was
intended to remediate.  After all, by the way it is currently documented,
many of the routes in the Internet would likely have ATOMIC_AGGREGATE.
   
The original motivation for this investigation (aside from a few years
of wondering what this portion of the spec *really* meant) was
making sure the MIB is correctly documented.  I can do this now,
even if the spec is not corrected by simply noting that the values:
lessSpecificRouteNotSelected(1),
lessSpecificRouteSelected(2)

mean:
ATOMIC_AGGREGATE not present
ATOMIC_AGGREGATE present

rather than documenting anything about less and more specific routes.

The v2MIB can be fixed to just call it what it is since it hasn't 
been RFC'ed yet.

Lastly, the spec would just be incorrect.
But all said, nothing bad would really come of this.

----------------------------------------------------------------------------
59) Section 4.3 - Move text 
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Proposal to move text around in Section 4.3 has met with one
 agreement and one disagreement.

Discussion:

This began with this suggestion:

The text about the mimimum length, at first look, gives the impression
that it is still part of the NLRI field description and/or the Path
Attributes section.  A new "subsection" or heading of some sort would be
helpfull in switching context back to the UPDATE message as a whole and
not the path attributes field anymore.

Jonathan agreed, and suggested this text:

" The minimum length of the UPDATE message is 23 octets -- 19 octets
   for the fixed header + 2 octets for the Withdrawn Routes Length + 2
   octets for the Total Path Attribute Length (the value of Withdrawn
   Routes Length is 0 and the value of Total Path Attribute Length is
   0)."

Should be moved up to just after

"... the Total Path Attribute Length field and the
         Withdrawn Routes Length field."

Yakov responded to this with:

Disagree, as "... the Total Path Attribute Length field and the
Withdrawn Routes Length field." explains how to calculate the length
of NLRI field (and therefore is part of the NLRI field description),
while "The minimum length of the UPDATE message is 23 octets...."
has to do with the length of the UPDATE message.

Jonathan also suggested:

" the value of Withdrawn
   Routes Length is 0 and the value of Total Path Attribute Length is
   0)."
 
Should be changed to

" the min. value of Withdrawn
   Routes Length is 0 and the min. value of Total Path Attribute Length is
   0)."

And Yakov responded with:

Disagree, as the text doesn't talk about what is the minimum value
of the Withdrawn Routes Length and Total Path Attribute Length
fields, but talks about the value of these fields in the case of
a min length UPDATE message. 

There is no consensus.

This is discussed in the "Review: Comments: Section 4.3: UPDATE min length"
thread.

----------------------------------------------------------------------------
60) Section 4.3 - Path Attributes
----------------------------------------------------------------------------
Status: Consensus
Change: Potentially
Summary: Make this change to clarify path attributes in an UPDATE:

To correct the confusion I propose to replace:

  A variable length sequence of path attributes is present in every UPDATE.

with:

  A variable length sequence of path attributes is present in
  every UPDATE message, except for an UPDATE message that carries
  only the withdrawn routes.

Discussion:

This thread began with MikeC pointing out:

The top of page 13 says:

"A variable length sequence of path attributes is present in every UPDATE."

Is this really true, given that later, in the second to last paragraph
of this section (4.3):

"An UPDATE message might advertise only routes to be withdrawn from
service, in which case it will not include path attributes or Network
Layer Reachability Information."

This could be confusing to a first time reader.

The path attribute length is present in every UPDATE, the path attribute
field itself can be left out, both according to the description of the
minimum length of the UPDATE message and (implied?) in the picture of
the UPDATE message at the beginning of section 4.3.

This met with one agreement.

Yakov then proposed that:

To correct the confusion I propose to replace:

  A variable length sequence of path attributes is present in every UPDATE.

with:

  A variable length sequence of path attributes is present in
  every UPDATE message, except for an UPDATE message that carries
  only the withdrawn routes.

There was one agreement with this proposal.

This is discussed in the thread: "Review: Section 4.3 - Path Attributes"

----------------------------------------------------------------------------
61) Next Hop for Redistributed Routes
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: There was text suggested, but no discussion.

Discussion:

Jonathan began this thread with:

I propose adding:
     
"When announcing a locally 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 address of the interface that is
used to reach the peer)."
     
AFTER

"When sending a message to an internal peer, 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."

There has been no discussion on this.

This is discussed in the "Next hop for redistributed routes" thread.

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

CHANGELOG

----------------------------------------------------------------------------
v1.0 to v1.1 
2002-09-24
----------------------------------------------------------------------------

Added:

59) Section 4.3 - Move text
60) Section 4.3 - Path Attributes
61) Next Hop for Redistributed Routes

Updated:

5) Direct EBGP Peers
7) Renumber Appendix Sections
43) Clarify the NOTIFICATION Section

Moved to Consensus:

5) Direct EBGP Peers
7) Renumber Appendix Sections
43) Clarify the NOTIFICATION Section

--kORqDWCi7qDJ0mEj--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA29751 for <[e-mail]>; Tue, 24 Sep 2002 19:17:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 67F3491291; Tue, 24 Sep 2002 19:16:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2707C91295; Tue, 24 Sep 2002 19:16:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 06B1291291 for <[e-mail]>; Tue, 24 Sep 2002 19:16:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D8E165E047; Tue, 24 Sep 2002 19:16:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id ACC4B5E055 for <[e-mail]>; Tue, 24 Sep 2002 19:16:40 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id QAA26185; Tue, 24 Sep 2002 16:13:46 -0700 (PDT)
Date: Tue, 24 Sep 2002 16:13:46 -0700
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: BGP Base Draft - Issue List v1.0 2002-09-24
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="PNTmBPCT7hxwcZjr"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: [e-mail]
Precedence: bulk

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

Greetings,

Attached, as text, is a list of the issues that we have been discussing.

Andrew

--PNTmBPCT7hxwcZjr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="Issue_List_2002-09-24.txt"

2002-09-24
v1.0

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) IDR WG Charter
2) TCP Port 
3) FSM wording for what state BGP accepts connections in
4) BGP Identifier/Router ID
5) Direct EBGP Peers
6) Disallow Private Addresses
7) Renumber Appendix Sections
8) Jitter Text
9) Reference to RFC904 - EGP Protocol
10) Extending AS_PATH Attribute
11) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1 
11.1) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3
11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
12) TCP Behavior Wording
13) Next Hop for Originated Route
14) NEXT_HOP to Internal Peer
15) Grammer Fix
16) Need ToC, Glossary and Index
17) Add References to other RFC-status BGP docs to base spec.
18) IP Layer Fragmentation 
19) Appendix Section 6.2: Processing Messages on a Stream Protocol
20) Wording fix in Section 4.3
21) Authentication Text Update
22) Scope of Path Attribute Field
23) Withdrawn and Updated routes in the same UPDATE message
24) Addition or Deletion of Path Attributes
25) NEXT_HOP Semantics
26) Attributes with Multiple Prefixes
27) Allow All Non-Destructive Messages to Refresh Hold Timer
28) BGP Identifier as Variable Quantity
29) State Why Unresolveable Routes Should Be Kept in Adj-RIB-In
30) Mention Other Message Types
31) Add References to Additional Options
32) Clarify EGP Reference
32.1) EGP ORIGIN Clarification
32.2) BGP Desitnation-based Forwarding Paradigm
33) Add "Optional Non-Transitive" to the MED Section
34) Timer & Counter Definition
35) Fix Typo
36) Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary
37) Combine "Unfeasable Routes" and "Withdrawn Routes"
38) Clarify Outbound Route Text
39) Redundant Sentance Fragments
40) Section 9.2.1.1 - Per Peer vs. Per Router MinRouteAdvertisementInterval
41) Mention FSM Internal Timers
42) Delete the FSM Section
43) Clarify the NOTIFICATION Section
44) Section 6.2: OPEN message error handling
45) Consistant References to BGP Peers/Connections/Sessions
46) FSM Connection Collision Detection
47) FSM - Add Explicit State Change Wording
48) Explicitly Define Processing of Incomming Connections
49) Explicity Define Event Generation
50) FSM Timers 
51) FSM ConnectRetryCnt
52) Section 3: Keeping routes in Adj-RIB-In
53) Section 4.3 - Routes v. Destinations - Advertise
54) Section 4.3 - Routes v. Destinations - Withdraw
55) Section 4.3 - Description of AS_PATH length
56) Section 6 - BGP Error Handling
57) Section 6.2 - Hold timer as Zero
58) Deprication of ATOMIC_AGGREGATE

============================================================================
Issues with Consensus
============================================================================
1) IDR WG Charter
2) TCP Port 
3) FSM wording for what state BGP accepts connections in
6) Disallow Private Addresses
12) TCP Behavior Wording
13) Next Hop for Originated Route
15) Grammer Fix
16) Need ToC, Glossary and Index
20) Wording fix in Section 4.3
23) Withdrawn and Updated routes in the same UPDATE message
25) NEXT_HOP Semantics
26) Attributes with Multiple Prefixes
28) BGP Identifier as Variable Quantity
35) Fix Typo
38) Clarify Outbound Route Text
40) Section 9.2.1.1 - Per Peer vs. Per Router MinRouteAdvertisementInterval
42) Delete the FSM Section
50) FSM Timers 
51) FSM ConnectRetryCnt
52) Section 3: Keeping routes in Adj-RIB-In
54) Section 4.3 - Routes v. Destinations - Withdraw
57) Section 6.2 - Hold timer as Zero

----------------------------------------------------------------------------
1) IDR WG Charter
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: New charter adopted.

Discussion:

A variety of discussions surrounded the new charter.  The rough
consensus is to accept the new charter that the AD's have proposed,
and to push as hard a possible to get the base spec to RFC status
so other drafts that are dependent can also move forward.
This thread has messages subjects of "BGP spec and IDR WG charter"
and "IDR WG charter".

For our information, Alex has provided these aproximate timelines:

 Stage		 Anticipated delay	    Comment
----------------------------------------------------------------------------
 AD-review	 1--4 weeks		    The document may go back to the
		 depending on workload	    WG for the AD-review comments
                                            to be addressed; this would
                                            introduce additional delay.

 IETF LC	 2 weeks		    Same as above

 IESG review&	 1--2 weeks depending	    Same as above
 telechat	 on when the IETF LC ends
----------------------------------------------------------------------------

Note that if the document is sent back to the WG at some stage, required
changes may warrant an additional WG Last Call.

I can personally commit to a 2-week upper bound for the AD-review
period. Bill may have a different timer granularity.

The offical vote on this was 7 accept, 4 reject.

----------------------------------------------------------------------------
2) TCP Port 
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: 
 Change:
  "BGP uses TCP port 179 for establishing its connections."
 To: 
  "BGP listens on TCP port 179."

Discussion:

There has been a discussion on clarifying the wording in Section 2,
on which port BGP uses.	 The original text was:

"BGP uses TCP port 179 for establishing its connections."

The proposed new text is:

"BGP listens on TCP port 179."

There seems to be a rough consensus that the new text is better.

This thread has a message subject of "Review: Section 2, TCP Port 179"

----------------------------------------------------------------------------
3) FSM wording for what state BGP accepts connections in
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: No change necessary

Discussion:

An issue was brought up later in the "Review: Section 2, TCP Port 179"
thread about the words in the FSM for what state BGP accepts connections
in.  The consensus is that the existing wording is clear.

----------------------------------------------------------------------------
4) BGP Identifier/Router ID
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: No change necessary to base draft.  Perhaps in a BCP.

Discussion:

The "admin dist/gp spec proposal", "Router ID" and "bgp spec proposal"
threads discussed the BGP Identifier and how close or not it is to IGP's
Router ID.  The consensus was that this discussion is better saved for a
BCP draft, and that it does not need to be contained in the base spec.

----------------------------------------------------------------------------
5) Direct EBGP Peers
----------------------------------------------------------------------------
Status: No Consensus
Change: No
Summary: A recollection that ebgp peers must be direct.  No text
  proposed, no discussion.

Discussion:

A recollection that ebgp peers must be direct.  No specific sections
were quoted.  There was no discussion on this issue.

----------------------------------------------------------------------------
6) Disallow Private Addresses
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: No change necessary

Discussion:

In the tread entitled "bgp draft review":

Mentioned explicitly disallowing private addresses.  The
consensus was that there is no reason to disallow them.	 Which IP
addresses peers use is an operational issue.

----------------------------------------------------------------------------
7) Renumber Appendix Sections
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary:
 Proposal to rename/renumber appendix sections so they do not have the
 same numbers as sections of the main text.

Discussion:

In the tread entitled "bgp draft review":

This thread brought up renaming sections in the appendix to avoid
confusion with sections of the same number in the main text.  There
was no discussion on this issue.

----------------------------------------------------------------------------
8) Jitter Text
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary:
 Change:
  "jitter should be applied to the
   timers associated with MinASOriginationInterval, Keepalive, and
   MinRouteAdvertisementInterval"
 To:
  "jitter should be applied to the timers associated with ConnectRetry timer"

Discussion:

In the tread entitled "bgp draft review":
The thread also proposed:

"jitter should be applied to the
   timers associated with MinASOriginationInterval, Keepalive, and
   MinRouteAdvertisementInterval"

Be changed to:

"jitter should be applied to the
   timers associated with ConnectRetry timer"

- There was limited discussion on this issue.  Implementions will
add jitter to all of these.  There is no consensus on changing this
text.

----------------------------------------------------------------------------
9) Reference to RFC904 - EGP Protocol
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Add a reference to RFC904

Discussion:

The "Review Comment: Origin Attribute pg 14" thread suggested adding a
reference to RFC904(?), to refer to the EGP protocol.  There was no
discussion.

----------------------------------------------------------------------------
10) Extending AS_PATH Attribute
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Specific text required to delimit behavior when AS_PATH length
 is exceeded.

Discussion:

The "Extending AS_PATH attribute length en route" thread brought up
the issue of what action should we specify when we receive a route
with an AS_PATH that exceeds the defined maximum length.  There was
some discussion, and it was suggested that, after logging the error,
the route not be propegated.  No text was proposed.  This issue needs
consensus:  Do we specify the behavior?	 If so what with what text?

----------------------------------------------------------------------------
11) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Variety of texts proposed to help clear up the rules for moving
 routes from Loc-RIB into Adj-RIB-Out.

Discussion:

The "Proxy: comments on section 9.1.3" thread brought up some lack of
clarity in the section discussing the rules for which routes get propegated
from the Loc-RIB into the Adj-RIB-Out.	These discussions resulted in
a number of suggestions for new text.

The first new text was proposed to clarify the issue that the thread
first brought up:

I agree that this could use some clarification.	 How about adding
to b) in section 9.1:


  The Loc-RIB must contain only one route per destination; further, it
  must include all routes that the BGP speaker is using.

changing c) in section 9.1.2 to:

  c) is selected as a result of the Phase 2 tie breaking rules specified
  in 9.1.2.2, or

and adding

  d) when routing protocols other than BGP are in use, is determined by
  some other local means to be the route that will actually be used to
  reach a particular destination.

This text was never discussed or a consensus formed on putting it in the
document.

This modification to 9.1.2 was also proposed to address the same concern:

How about changing the paragraph after c) in 9.1.2 to:

  The local speaker SHALL then install that route in the Loc-RIB,
  replacing any route to the same destination that is currently being
  held in the Loc-RIB.	This route SHALL then also be installed in
  the BGP speakers forwarding table.

There was one response in the negative to this change, arguing that is
is not necessary.

----------------------------------------------------------------------------
11.1) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Variety of texts proposed to help clear up the rules for moving
 routes from Loc-RIB into Adj-RIB-Out.

Discussion:

In further discussions around this issue, this text was also proposed:

How about adding to section 9.1.3, at the end:

  Any local-policy which results in reachability being added to an
  Adj-RIB-Out without also being added to the local BGP speaker's
  forwarding table is beyond the scope of this document.

This suggestion received one response that agreed to this change.

----------------------------------------------------------------------------
11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Variety of texts proposed to help clear up the rules for moving
 routes from Loc-RIB into Adj-RIB-Out.

Discussion:

Additionally this thread produced this section of new text, in section 2:

<OLD>

"one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with) in
   neighboring ASs only those routes that it itself uses."

Should be changed to

<NEW #1>

"one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with) in
   neighboring ASs only routes whose NLRIs are locally reachable."

<NEW #2>

 "one must focus on the rule that a BGP speaker advertises
  to its peers (other BGP speakers which it communicates with) in
  neighboring ASs only routes which are locally reachable. Local
  reachability can be achieved by having any protocol route to
  the given destination in the routing table."

There was no consensus on which text we ought to use, or if any change
is necessary.

----------------------------------------------------------------------------
12) TCP Behavior Wording
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Minor wording change very contentious.  Consensus was to leave
  things as they are.

Discussion:
The subjectless "your mail" thread discussed a wording clarification from:

 "An implementation that would "hang" the routing information process while
 trying to read from a peer could set up a message buffer (4096 bytes) per
 peer and fill it with data as available until a complete message has been
 received. "

To something that is more TCP-correct, such as:

 "An implementation that would "hang" the routing information process while
 trying to received from a peer could set up a message buffer (4096 bytes) per
 peer and fill it with data as available until a complete message has been
 received. "

(only change: "read" to "received"  This was one of a couple of suggested
changes.)

This suggestion was quite contentious, and although there were a variety
of alternate texts proposed, the only consensus was that this was a very
minor issue, and probably not worth changing.

----------------------------------------------------------------------------
13) Next Hop for Originated Route
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: No reponses, assumed consensus to keep things the same.

Discussion:

There was a one-message thread entitled "next hop for originated route".
This message received no reponse, so the assumption is that there is
a consensus to keep things as they are.

----------------------------------------------------------------------------
14) NEXT_HOP to Internal Peer
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: One concuring reponse, no text proposed.

Discussion:

The thread entitled "NEXT_HOP to internal peer" starts with this question:

When sending a locally originated route to an internal peer, what should
NEXT_HOP be set to?

One response suggested that we add a line stating that the NEXT_HOP address
originates from the IGP.

----------------------------------------------------------------------------
15) Grammer Fix
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: 
  Change:
    "The Prefix field contains IP address prefixes ..."
  To:  
    "contains an IP address prefix ..."

Discussion:
The thread entitled "Review comment: bottom of page 16" corrects a grammer
mistake by suggesting we change:

"The Prefix field contains IP address prefixes ..."

to:

"contains an IP address prefix ..."

The consensus seems to be to correct this, and go with the new text.

----------------------------------------------------------------------------
16) Need ToC, Glossary and Index
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Need to add a Table of Contents (ToC), Glossary and Index to the 
 draft.  Will be added in draft -18.

Discussion:

The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread suggests:

1. Document needs, Table of Contents, Glossary, and Index

2. Paths, Routes, and Prefixes need to be defined in the spec early on (like
in a glossary), so it is obvious what is implied.

Yakov responded that draft -18 will have a ToC and definition of commonly
used terms.

----------------------------------------------------------------------------
17) Add References to other RFC-status BGP docs to base spec.
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Add references to other RFC-status BGP docs to the base spec.

Discussion:

The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread then changes
titles to: "Review of draft-ietf-idr-bgp4-17.txt" and goes on to
suggest:

3. All BGP Extensions described in other documents that made it to RFC
status should be at least referenced in the Reference section P.64. This is
justifiable since it's the core BGP standard spec.

----------------------------------------------------------------------------
18) IP Layer Fragmentation 
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: No need to mention IP Layer Fragmentation in the BGP specification,
 since this is taken care of at the TCP level.

Discussion:

1. P.6	section 4. Message Formats, its possible for the source BGP peer IP
layer to fragment a message such that the receiving BGP peer socket layer
would have to reassemble it. Need to mention this, since BGP implementations
are required to do this.

The response to this was that, while true, reassembly is something that
is inherent in the TCP layer that BGP rides over.  Therefore, this is
something that is in the TCP spec, and needn't be repeated in the BGP spec.
This comment was reaffirmed.  There seems to be consensus that this isn't
something that needs to be in the BGP spec.

----------------------------------------------------------------------------
19) Appendix Section 6.2: Processing Messages on a Stream Protocol
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: This is a hotly debated issue.  The choices are outlined in
  the discussion.  We can: 1) Leave things the way they are 2)
  Take Curtis's suggestion for change 3) Remove the section entirely.

Discussion:

This first came up in reponse to Issue 17:

There was one comment suggesting that section 6.2 (Processing Messages
on a Stream Protocol" mentioned this.

The original reviewer reponsed that the out-of-scope comment was out-of-place
and refered the reponder to section 6.2 (appendix 6)

The original reviewer stated that he is happy with just adding a
reference to section 6.2 in appendix 6 and leaving it at that.

Curtis suggested we just add a reference to Stevens in appendix 6. 6.2
and be done with it.  Specifically:

  6.2  Processing Messages on a Stream Protocol

     BGP uses TCP as a transport mechanism.  If you are unsure as to
     how to handle asynchronous reads and writes on TCP sockets please
     refer to Unix Network Programming [RWStevens] or other
     introductory text for programming techniques for the operating
     system and TCP implementation that you are using.

There were further suggestions to remove the section entirely as out-of-scope.
At least 3 people agreed with this.

Alex responded that he sees no reason to remove it, but wouldn't have a
problem if the WG decides to do so.

----------------------------------------------------------------------------
20) Wording fix in Section 4.3
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: A small change for clarity in section 4.3

Discussion:

This suggestion grew out of the discussion on Issue 18.

The following change was suggested in section 4.3, second line of the 
first paragraph:

s/UPDATE packet/UPDATE message/

Yakov agreed to this change and updated the draft.

----------------------------------------------------------------------------
21) Authentication Text Update
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: A small change to the "Authentication Data:" section to mention
  well established MD5 support.

Discussion:

  P. 10, "Authentication Data:" section you might want to add this,
  It is also possible to use MD5 (RFC2385) at the transport layer to validate
  the entire BGP message.

There was no discussion on this issue.

----------------------------------------------------------------------------
22) Scope of Path Attribute Field
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Add a sentance to clarify that all attributes in the Path Attribute
  field beling to all prefixes in the NLRI.

Discussion:

  P. 12, right after "Path Attributes". The following sentence should be
  added to this section to clarify the scope of the Path Attribute field.
  "All attributes in the Path Attribute field represent the characteristics of
  all the route prefixes defined in the NLRI field of the message".

There was no discussion on this issue.

----------------------------------------------------------------------------
23) Withdrawn and Updated routes in the same UPDATE message
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: For various reasons, not least of which is compatability with
  existing implementaions, the decision was made to keep thing the way
  they are.

Discussion:

4. P.16, last paragraph in section 4.3 as stated,
 "An UPDATE message should not include the same address prefix in the
  WITHDRAWN ROUTES and Network Layer Reachability Information fields,
  however a BGP speaker MUST be able to process UPDATE messages in this
  form. A BGP speaker should treat an UPDATE message of this form as if
  the WITHDRAWN ROUTES doesn't contain the address prefix."

This complexity could have been avoided if withdrawn routes and NRLI
prefixes with their attributes were mutually exclusive of each other and
appeared in different update messages. If that was the case, the priority of
which field to process first would have been as simple as using "first come,
first served" message processing approach.

Yakov commented that this would make the case where they are both in the
same message unspecified.

John commented that this is something we don't want to change this late in
the game.  Although it was acknowledged that this might be a good change
if we were working from a clean slate.

Ben acceeded that this was somewhat wishful thinking on his part.

Curtis's comment seems to coincide with this message, stating:

The existing rules are very clear.

Summarized:

  If an UPDATE contains only a withdraw for a prefix, then withdraw
  whatever route the peer had previously sent.

  If an UPDATE contains the prefix only in the NRLI section, replace
  whatever route had previously been advertised by the peer or add a
  route if there was no previous route, in both cases adding a route
  with the current attributes.

  Don't put the same prefix in the same in both the withdraw and NRLI
  section of the same update.

  If you receive an UPDATE with the same prefix in both the withdraw
  and NRLI, ignore the withdraw.  [Some older implementations thought
  this was a good way to say "delete then add".]

  Process UPDATEs from the same peer in the order received.

And goes on to say, that to him, these rules are clear from the existing
text.

Consensus is that while this would be nice, we need to stick with what
we have, and move on.

----------------------------------------------------------------------------
24) Addition or Deletion of Path Attributes
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: There are two views here.  One argues that the mechanism for
 adding and deleting path attributes should be explicitly stated in the
 draft.  The other argues that this is tied to the definition of "route"
 and additional specification is unnecessary.

Discussion:

5. P. 20 Its not stated how we delete or modify Path Attributes associated
with NLRI prefixes.

A response to this comment said that this is implicit in the definition
of "route" and the general withdraw/replace behavior and therefore doesn't
need to be repeated.

Ben responded saying that, while there was an assumption, there was
no well defined mechanism, and this leads to ambiguity.

John reponded, no need to define everything explicity, or we'll be here
forever.

----------------------------------------------------------------------------
25) NEXT_HOP Semantics
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: After reponders pointed out another sentance, this comment 
 was resolved. Things will stay the way they are.

Discussion:

1. P.28, 2nd to last paragraph. The line that reads, "To be semantically
correct, the IP address in the NEXT_HOP must not be the IP address of the
receiving speaker, and the NEXT_HOP IP address must either be the sender's
IP address (used to establish the BGP session), or the interface associated
with the NEXT_HOP IP address must share a common subnet with the receiving
BGP speaker..."

This is not always true, what if the current ASBR BGP router is advertising
an external AS route (to a IBGP Peer) whose NEXT_HOP IP address is the IP
address of the EBGP peer in the other AS?

A response to this pointed out that right before this is a sentance stating
that this only applied to eBGP links, and only when the peers are one hop
from each other, so a modification is unnecessary.  This reponse was
confirmed with another.

The original reviewer acknowldeged this and withdrew the comment.

The consensus is to leave things the way they are.

----------------------------------------------------------------------------
26) Attributes with Multiple Prefixes
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: After some discussion, the consensus is to keep things the same
  since the suggested behavior is defined in the message format.

Discussion:

2. P. 29, Section 6.3. Add this rule near the attribute rules.
"Multiple prefixes that require the same attribute type with different
values must never appear in the same update message".

A response to this suggested that this text is unnesessary since this
behavior is ruled out by the way the message format is defined.

The original commentor agrees with the reponder.  The consensus is to
leave things the way they are.

----------------------------------------------------------------------------
27) Allow All Non-Destructive Messages to Refresh Hold Timer
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially 
Summary: It is agreed that this is a change that exceeds the original 
  goal of this draft revision.  This goal is to document existing 
  practice in an interoperable way.  If we should do it anyway has not
  been decided.

Discussion:

3. P. 29, Section 6.5, Please rewrite this sentence from:
    "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 ..."

 To This:
    "If a system does not receive successive KEEPALIVE and/or UPDATE
	and/or any other BGP message within the period specified in the Hold
	Time field of the OPEN message ..."

There is disagreement on this change. It has been discussed in other
threads.

The original commentor acknowledged that this is something that would
be "adding a new feature" as opposed to the stated goal of "documenting
what exists."  He suggested that the ADs decide if we should open the
door for new features or not.

----------------------------------------------------------------------------
28) BGP Identifier as Variable Quantity
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: The consensus is that changing the BGP Identifier in the base
  draft is out-of-scope at this point in the draft evolution.

Discussion:

4. P. 31, section 6.8, Please rewrite this sentence from:
   "Comparing BGP Identifiers is done by treating them as (4-octet long)
    unsigned integers."

 To This:
   "Comparing BGP Identifiers is done by treating them as large numbers based
   on their IP Address type (e.g. IPv4, IPv6, etc.)."

A reponse to this was that since BGP Identifier is defined in the base
spec as a 4 byte unsigned integer, and not a variable quantity, the
sentance as written is acceptable.  This was also confirmed by another
response.

The original commentor was thinking of IPv6, and providing sufficent
space to allow a full v6 address to be used.

Again, reponders said that this is out-of-scope for the current draft.

----------------------------------------------------------------------------
29) State Why Unresolveable Routes Should Be Kept in Adj-RIB-In
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary:  Explicity state that there is a chance routes can become 
  resolveable, and should therefore be kept in Adj-RIB-In.  No text
  has yet been suggested.

Discussion:

 5. P.46, last sentence, "However, corresponding unresolvable routes SHOULD
 be kept in the Adj-RIBs-In."  It would helpful if the author states why
 unresolvable routes should be kept in Adj-RIBs-In?

 A reponse to this stated "In case they become resolveable"

 The original commentor stated that:
 Then the point that the peer will not refresh the route if we drop
 them (unless we use Route Refresh) because they are unreachable should be
 made.

----------------------------------------------------------------------------
30) Mention Other Message Types
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Do we add this explicity?  If so when?  With what text?

Discussion:

1. P. 7 Type: Need to add the new message types such as, Capability
Negotiations (RFC2842), Route Refresh, etc.

One reponse argued that these are out-of-scope of the base document.
One reponse agreed, but thought that it should be capability and not
message type. The original commentor reponsed about Message type
from the capability draft.

Sue mentioned this would be added in the second round.

----------------------------------------------------------------------------
31) Add References to Additional Options
----------------------------------------------------------------------------
Status: Consensus, but no text
Change: Yes
Summary: Consensus that we should add the references.  No text proposed.

Discussion:

2. P. 9, right after "This document defines the following optional
parameters:"
Need to mention possible options, such as: Capabilitites (RFC2842),
Multiprotocol extensions (RFC2858), Route Refresh (RFC2918).

One reponse agreed that adding references would be fine.
A second reponse agreed.

----------------------------------------------------------------------------
32) Clarify EGP Reference
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Need to clarify the EGP Reference, since there seems to be some
  confusion on the issue.

Discussion:

3. P. 13, EGP, are there other EGP protocols other than BGP that are in use?
If not, change EGP to BGP.

A response to this suggested that we add a reference to [1] (the EGP
spec) here.

Another reponse clarified that this refers to EGP-the-protocol and
NOT the class.

Another response disagreed, but suggested that:

IGP = network was explicitly introduced into bgp (network cmd)
INCOMPLETE = network was implicitly introduced into bgp (redistribute)
EGP = other

The original commentor thought that this refered to EGP-the-class of
protocols.   And why not use BGP therefore, as the only EGP.

There was some disucssion over whether or not we should mention something
that is historical.

Jeff suggested a footnote in the Origin section about EGP.

Curtis suggested that we state that the EGP in ORIGIN is depricated,
but retain the value to document what it used to mean.

This reviewer thinks a statement about whether this "EGP" origin refers
to the protocol or the class or protocols would be useful.

----------------------------------------------------------------------------
32.1) EGP ORIGIN Clarification
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Proposal to update the EGP ORIGIN section.

Discussion:

This discussion is picked up again in the "Review of draft-ietf-idr-bgp4-17"
thread, where specific text is proposed:

Old:

            "ORIGIN is a well-known mandatory attribute that defines the
            origin of the path information.  The data octet can assume
            the following values:

                  Value		Meaning

                  0	    IGP - Network Layer Reachability Information
                               is interior to the originating AS

                  1	    EGP - Network Layer Reachability Information
                               learned via the EGP protocol

                  2	    INCOMPLETE - Network Layer Reachability
                               Information learned by some other means"
New:

            "ORIGIN is a well-known mandatory attribute that defines the
            origin of the path information.  The data octet can assume
            the following values:

                  Value		Meaning

                  0	    IGP - NLRI was explicitly introduced into bgp

                  1	    EGP - this value was administratively
                               configured to affect policy decisions or
                               NLRI was learned via the EGP protocol [1]

                  2	    INCOMPLETE - NLRI was implicitly introduced
                                      into bgp"

since:
1) The network command sets the origin to IGP and I remember seeing
somewhere that only static routes should be set to IGP.
2) The primary use of EGP value is policy
3) EGP seems to still exist, anyway even if it does not it is
not worth re-writing the world.

Also, change:
"5.1.1 ORIGIN


   ORIGIN is a well-known mandatory attribute.	The ORIGIN attribute
   shall be generated by the autonomous system that originates the
   associated routing information. It shall be included in the UPDATE
   messages of all BGP speakers that choose to propagate this
   information to other BGP speakers."

to:
"5.1.1 ORIGIN

   The value of the ORIGIN attribute shall be set by the speaker
   that originates the associated NLRI.	 Its value shall not be
   changed by any other speaker unless the other speaker is
   administratively configured to do so to affect policy
   decisions."

since:
1) It is already defined as well-known mandatory attribute.
2) It may be set differently within the same AS (not saying this is good).
3) It is commonly used for policy, but by default does not get changed.
4) Speakers have no choice, it is mandatory.

Yakov reponsed that the root of the EGP problems is perhaps best addressed
by the text documented in issue 32.2.

----------------------------------------------------------------------------
32.2) BGP Desitnation-based Forwarding Paradigm
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Proposal to clarify BGP's support for the destination-based
  forwarding paradigm.  There seems to be consensus that some sort of 
  updated text is good, but there is not yet consensus on which text
  that should be.

Discussion:

In response to these proposals, Yakov proposed that the real problem is that
it is not clear that BGP is build to support the destination-based
forwarding paradigm.  To fix this, it was propsed that:

<OLD>

   To characterize the set of policy decisions that can be enforced
   using BGP, one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with) in
   neighboring ASs only those routes that it itself uses. This rule
   reflects the "hop-by-hop" routing paradigm generally used
   throughout the current Internet. Note that some policies cannot
   be supported by the "hop-by-hop" routing paradigm and thus
   require techniques such as source routing (aka explicit routing)
   to enforce. For example, BGP does not enable one AS to send
   traffic to a neighboring AS intending that the traffic take a
   different route from that taken by traffic originating in the
   neighboring AS. On the other hand, BGP can support any policy
   conforming to the "hop-by-hop" routing paradigm. Since the
   current Internet uses only the "hop-by-hop" inter-AS routing
   paradigm and since BGP can support any policy that conforms to
   that paradigm, BGP is highly applicable as an inter-AS routing
   protocol for the current Internet.

<NEW>

   Routing information exchanged via BGP supports only the
   destination-based forwarding paradigm, which assumes that a
   router forwards a packet based solely on the destination address
   carried in the IP header of the packet. This, in turn reflects
   the set of policy decisions that can (and can not) be enforced
   using BGP. Note that some policies cannot be supported by the
   destination-based forwarding paradigm and thus require techniques
   such as source routing (aka explicit routing) to enforce. Such
   policies can not be enforced using BGP either. For example, BGP
   does not enable one AS to send traffic to a neighboring AS
   intending that the traffic take a different route from that
   taken by traffic originating in the neighboring AS.	On the
   other hand, BGP can support any policy conforming to the
   destination-based forwarding paradigm.

Curtis thinks the newer text here is more clear.

In reponse to the new text, Christian Martin propsed a slightly different
new text:

   Routing information exchanged via BGP supports only the
   destination-based forwarding paradigm, which assumes that a
   router forwards a packet based solely on the destination address
   carried in the IP header of the packet. This, in turn reflects
   the set of policy decisions that can (and can not) be enforces
   using BGP. Note that some policies cannot be supported by the
   destination-based forwarding paradigm and thus require techniques
   such as source routing (aka explicit routing) to enforce. Such
   policies can not be enforced using BGP either. For example, BGP
   does not enable one AS to send traffic to a neighboring AS
   based on prefixes originating from the local AS.  On the
   other hand, BGP can support any policy conforming to the
   destination-based forwarding paradigm.

To which Yakov replied:

    Routing information exchanged via BGP supports only the
    destination-based forwarding paradigm, which assumes that a
    router forwards a packet based solely on the destination address
    carried in the IP header of the packet. This, in turn, reflects
    the set of policy decisions that can (and can not) be enforces
    using BGP. Note that some policies cannot be supported by the
    destination-based forwarding paradigm, and thus require techniques
    such as source routing (aka explicit routing) to enforce. Such
    policies can not be enforced using BGP either. For example,
    BGP does not enable one AS to send traffic through a neighboring
    AS to some destination (which is outside of the neighboring
    AS, but is reachable through the neighboring AS) intending that
    the traffic take a different route from that taken by the traffic
    to the same destination that originating in the neighboring AS.
    On the other hand, BGP can support any policy conforming to
    the destination-based forwarding paradigm.

And Chris reponsed:

    Routing information exchanged via BGP supports only the
    destination-based forwarding paradigm, which assumes that a
    router forwards a packet based solely on the destination address
    carried in the IP header of the packet. This, in turn, reflects
    the set of policy decisions that can (and can not) be enforces
    using BGP. Note that some policies cannot be supported by the
    destination-based forwarding paradigm, and thus require techniques
    such as source routing (aka explicit routing) to enforce. Such
    policies can not be enforced using BGP either. For example,
    BGP does not enable one AS to send traffic through a neighboring
    AS to some destination beyond the neighboring AS intending that
    the traffic take a different route from that taken by traffic
    to the same destination which originates in the neighboring AS.
    In other words, the BGP policy of a local AS cannot affect the
    downstream (aka, away from the local AS) forwarding policy of a
    remote AS.	On the other hand, BGP can support any policy conforming
    to the destination-based forwarding paradigm.

Tom Petch prefered Yakov's second formulation, with these changes:

     policies can not be enforced using BGP either. For example,
     BGP does not enable one AS to send traffic
!    to a neighboring AS for forwarding to some destination (reachable
through but) beyond
!    that neighboring AS intending that
!    the traffic take a different route to that taken by the traffic
!    originating in the neighboring AS (for that same destination).

     On the other hand, BGP can support any policy conforming to
     the destination-based forwarding paradigm.

Yakov agreed to Tom's suggested changes.

----------------------------------------------------------------------------
33) Add "Optional Non-Transitive" to the MED Section
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Do we add this text, or no?

Discussion:

4. P.23, change the following:

"The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
 links to discriminate among multiple exit or entry points to the same
 neighboring AS ..."

 To the following:

"The MULTI_EXIT_DISC is an optional non-transitive attribute which may be
used on external (inter-AS) links to discriminate among multiple exit or
entry points to the same neighboring AS ..."

A reponder disagreed, and stated reasons "covered elsewhere"
Original commentor asked for reasons, since the modification seemed obvious
to him.

----------------------------------------------------------------------------
34) Timer & Counter Definition
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: No discussion, no text proposed.

Discussion:

5. In section 8, there are a number of Timers, Counters, etc. that need to
be explicitly defined before they are used by the FSM. Perhaps these
definitions should go in the Glossary section.

----------------------------------------------------------------------------
35) Fix Typo
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Fix a Typo.  No discussion, but this seem clear.

Discussion:

1. P. 41. Typing error, "Each time time the local system...".

----------------------------------------------------------------------------
36) Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: This change requires a glossary. No Glossary text has been 
  proposed.

Discussion:

2. Section 9.1, Need to have Adj-RIB-In, Adj-RIB-Out, and Loc-RIB in the
glossary, so when they are used in section 9.1, it is well understood what
they are.

----------------------------------------------------------------------------
37) Combine "Unfeasable Routes" and "Withdrawn Routes"
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: No definition extant for "Unfeasable Routes". 

Discussion:

3. P. 45, Phase I, There is no definition of what are unfeasible routes? Are
they the same as withdrawn routes? If so, the two should be combined to one
name.
 
----------------------------------------------------------------------------
38) Clarify Outbound Route Text
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Consensus that the issue was suffiecently minor to leave things
  alone.

Discussion:

4. P. 50,  line, "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 (see 9.2)."

Would like to rephrase the sentence for clarity,
"If a route in Loc-RIB is excluded from a particular Adj-RIB-Out and was
previously advertised via Adj-RIB-Out, it must be withdrawn from service by
means of an UPDATE message (see 9.2)."

One comment suggested either leave it alone, or remove "via Adj-RIB-Out".

The original commentor withdrew the comment.

----------------------------------------------------------------------------
39) Redundant Sentance Fragments
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Redundant definitions, clarity requested.  Possible solution below.

Discussion:

5. P. 50, section 9.1.4, The two fragments of this sentence are redundant
and don't say anything new or simplify the content. Just keep one fragment.

"A route describing a smaller set of destinations (a longer prefix) is said
to be more specific than a route describing a larger set of destinations (a
shorted prefix); similarly, a route describing a larger set of destinations
(a shorter prefix) is said to be less specific than a route describing a
smaller set of destinations (a longer prefix)."

There was a comment that disagreed, thinking that both "more specific"
and "less specific" need to be defined.	 And suggested that only the
third and forth parentheses need to be dropped.

The original commentor agreed with the parentheses changes.

----------------------------------------------------------------------------
40) Section 9.2.1.1 - Per Peer vs. Per Router MinRouteAdvertisementInterval
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: The consensus is that current practice allows for the 
  MinRouteAdvertisementInterval to be set per peer, so the text should
  be kept the same.

Discussion:

6. P. 52, section 9.2.1.1 Change this sentence for clarity,
   "This rate limiting procedure applies on a per-destination basis, although
    the value of MinRouteAdvertisementInterval is set on a per BGP peer basis."

 To This:
   "This rate limiting procedure applies on a per-destination basis, although
    the value of MinRouteAdvertisementInterval is set on a BGP router (same
    value for all peers) basis."

There was a comment disagreeing with this proposal.
It was later elaborated on to include that the reason for diagreement was
that the proposed changes changed the protocol and not just a practice
clarification.
Ben reponded asking for how this is a protocol change, he saw it as
a clarification.  Perhaps there is something deeper that needs to be
clarified?
Again, response to this is that current implementations allow the
MinRouteAdvertisementInterval to be set per-peer, not per-router.

Original reviwer conceeded the point.

----------------------------------------------------------------------------
41) Mention FSM Internal Timers
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: No discussion on this issue.  No text proposed.  Perhaps this is
  in the FSM section of the draft?

Discussion:

7. P. 61, item 6.4. Although all the BGP protocol interfacing timers are
   mentioned, there are a few FSM internal timers mentioned in the spec that
   need to be covered  here as well.

----------------------------------------------------------------------------
42) Delete the FSM Section
----------------------------------------------------------------------------
Status: Consensus
Change: Potentially
Summary: There was some confusion on the question: Is the FSM draft going
  to be a seperate document, or incorporated into the base draft.  The
  consensus is that it is going to become part of the base draft, so the
  FSM section will be kept, and elaborated on.

Discussion:

8. Since there is going to be an FSM spec, do we need to have FSM
   descriptions in this spec. Maybe the FSM section should be delete.

There was one response agreeing with this.
One reponse asking for claificaiton:  Was this a move to remove
section 8. Finite State Machine from the base draft??
The original reviewer said, yes, when Sue's FSM draft becomes a WG
document, we should remove section 8 from the base draft.
Yakov asked that the AD's provide input on this suggestion.

Alex responded saying that the FSM draft is going to be part of the base
spec, and not another document once the FSM words are approved.

----------------------------------------------------------------------------
43) Clarify the NOTIFICATION Section
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Text and counter text was proposed, no consensus on which text
  should be used.

Discussion:

The "NOTIFICATION message error handling" thread proposed:

Please change"
"If a peer sends a NOTIFICATION message, and there is an error in that
   message, there is unfortunately no means of reporting this error via
   a subsequent NOTIFICATION message."

To:
"If a peer receives a NOTIFICATION message, and there is an error in that
   message, there is unfortunately no means of reporting this error via
   a subsequent NOTIFICATION message."

This reversal of meaning met with disagreement, and this text was proposed
instead:

   All errors detected while processing the NOTIFICATION message cannot be
   indicated by sending subsequent NOTIFICATION message back to
   originating peer, therefore there is no means of reporting NOTIFICATION
   message processing errors. Any error, such as an unrecognized
   Error Code or Error Subcode, should be noticed, logged locally, and
   brought to the attention of the administration of the peer that has
   sent the message. The means to do this, however, lies outside the scope
   of this document.

The original posted agreed with the intent of the respondant's text, thought
it was too wordy, but did not propose alternate text.

----------------------------------------------------------------------------
44) Section 6.2: OPEN message error handling
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: One commentor observed that the spec seems to specify behavior
  that doesn't seem to be observed by extant implementations, and suggested
  modifications to the spec.  There is no consensus as to if this observation
  holds across implementations, or if it does, if we should change the spec.

Discussion:

The "BGP4 draft ; section 6.2" thread began with a discussion of
section 6.2: OPEN message error handling.  Specifically:

"If one of the optional parameters in the Open mesage is not recognized,
then the error subcode is set to 'unsupported optional parameters"

We have hit on this line when we were testing a BGP connection between
a speaker that supported capability negotiation and a speaker that did
not.

The speaker that did not support the neogotiation closed down the peering
session using the error clause mentioned above. Sometimes this lead
to the other router to repeat the OPEN message with the Capability optional
parameter; a game that went on for minutes.

This router manufacturer stated in a reply to this that :
"One should not close down the connection if an optional parameter
is unrecognised. That would make this parameter basically mandatory.
This is an well known error in the BGP spec. Neither Cisco or Juniper
do this"

If this is true it might be good to adapt the text.

The response to this quoted RFC2842, Capabilities Advertisement with BGP-4:

   A BGP speaker determines that its peer doesn't support capabilities
   advertisement, if in response to an OPEN message that carries the
   Capabilities Optional Parameter, the speaker receives a NOTIFICATION
   message with the Error Subcode set to Unsupported Optional Parameter.
   In this case the speaker should attempt to re-establish a BGP
   connection with the peer without sending to the peer the Capabilities
   Optional Parameter.

The original poster responded:

This section from the Capabilities Advertisement RFC, is indeed
inline with the section 6.2 of the BGP4 specification. For me however
the question remains if most implementations do no simply ignore optional
parameters that are unknown. And if so, if the text stated above reflects
what is implemented by routers that do not have capability advertisement
at all.

----------------------------------------------------------------------------
45) Consistant References to BGP Peers/Connections/Sessions
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Update the document to make references to BGP Peers, Connections
  and Sessions more clear and consistant.  Proposed text is below, as
  well as current comments.

Discussion:

Ben proposed and Yakov responded:

> 1. Throughout the document we have various ways of naming the BGP
>    peering communication. 1) BGP Session, 2) BGP Peering Session,
   
I'll replace "session" with "connection".

>    3) TCP Connection,

The spec doesn't name BGP peering communication as "TCP connection";
TCP connection is used to establish BGP connection. So, TCP connection
and BGP connection are two different things.

>    4) BGP Connection,

The spec is going to use this term (see above).

>                  5) BGP Peering Connection,

I'll replace "BGP peering connection" with "BGP connection".

> 6) Connection,

The text uses "connection" whenever it is clear from the context
that it refers to "BGP connection" (or "TCP connection").

>    7) BGP Speaker Connection.
    
I'll replace "BGP Speaker Connection" with "BGP connection".

>  
>    BGP router: 1) BGP Speaker, 2) speaker, 3)local speaker

The term "speaker" is used when it is clear from the context that
we are talking about "BGP speaker".

> 2. Change Internal peer to IBGP Peer.

IBGP stands for "BGP connection between internal peers". Therefore  
the term "IBGP Peer" would mean "BGP connection between internal
peers peer".  That doesn't seem appropriate.

This issue has had some discussion, and section 3 was referenced, specifically:

Refer to Section 3 - Summary of operations which clearly states that " .. a
peer in a different AS is referred to as an external peer, while a peer in
the same AS may be described as an internal peer. Internal BGP and external
BGP are commonly abbreviated IBGP and EBGP"

After more discussion it was decided that we should modify a paragraph on
page 4 to read:

   If a particular AS has multiple BGP speakers and is providing
   transit service for other ASs, then care must be taken to ensure
   a consistent view of routing within the AS. A consistent view
   of the interior routes of the AS is provided by the IGP used  
   within the AS. For the purpose of this document, it is assumed
   that a consistent view of the routes exterior to the AS is
   provided by having all BGP speakers within the AS maintain 
   IBGP with each other. Care must be taken to ensure that the   
   interior routers have all been updated with transit information
   before the BGP speakers announce to other ASs that transit  
   service is being provided.

This change has consensus.

> 3. Change External peer to EBGP Peer.

Ditto.

Alex responded that haveing explicit definitions would be nice.  This 
ties into the general glossary suggestion (see issues 16, 34 & 36).

He also suggested that:

"BGP session" which works over a "TCP connection" would be closer to the 
terminology we're actually using now and would avoid possible confusions 
when people read terms like "Connection collision") 

This was discussed in the "Generial Editorial Comment" thread.

----------------------------------------------------------------------------
46) FSM Connection Collision Detection
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: We need to decide which text (the original base draft, or the FSM
  draft) needs to be updated to clear up this issue.  There does appear to
  be agreement that some clarification would be beneficial.

Discussion:

The original reviewer (Tom) commented that the base draft, FSM section, could
use some clarification around the area of connection collision detection.
Specifically, he argued that it seems like there are actually 2 FSM's
depending on which one backs off in the case of a collision.  He 
proposed this text to clear things up:

"8 BGP FInite State Machine  

This section specifies BGP operation - between a BGP speaker and its
peer over a single TCP connection - in terms of a Finite State Machine
(FSM).  Following is a brief summary ... "(as before)
 
Instead of just

"This section specifies BGP operation in terms of a Finite State
Machine (FSM).  Following is a brief summary ... "(as before).  

Curtis responded:

   There is one FSM per 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.
   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 connection that is closed should be disposed of.

I'm not sure which document containing an FSM we should be reading at
this point, but we could add the above paragraph if we need to
explicitly state that the extra connection and its FSM is disposed of
when a collision is detected.

When a TCP accept occurs, a connection is created and an FSM is
created.  Prior to the point where the peer associated with the
connection is known the FSM cannot be associated with a peer.  The
collision is a transient condition in which the rule of "one BGP
session per peer" is temporarily violated and then corrected.

This is discussed in the "FSM but FSM of what?" thread.

----------------------------------------------------------------------------
47) FSM - Add Explicit State Change Wording
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: A desire for explicit state change wording was expressed.  No
  text was proposed.  Additional information was solicited, but the
  discussion may have gone private.

Discussion:

The initial reviewer:

In most places, the actions taken on the receipt of an event include
what the new state will be or that it remains unchanged.  But there
are a signficant number of places where this is not done (eg Connect
state events 14, 15, 16).  I would like to see consistency, always
specify the new/unchanged state.  Else I may be misreading it.

There was a reponse asking for specific text, and offering to take the
discussion private.

This is discussed in the "FSM words - state changes" thread.

----------------------------------------------------------------------------
48) Explicitly Define Processing of Incomming Connections
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Suggested that we add explicit definitions for incomming 
  connection processing, no text proposed.

Discussion:

Alex suggsted we explicity define:

   - processing of incoming TCP connections (peer lookup, acceptance,
     FSM creation, collision control,)

No text was proposed.

This was discussed in the "Generial Editorial Comment" thread.

----------------------------------------------------------------------------
49) Explicity Define Event Generation
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Suggested that we explictiy define BGP message processing. No text
  proposed.

Discussion:

Alex suggsted we explicity define:

   - generation of events while processing BGP messages, i.e.,
     the text describing message processing should say where
     needed that a specific event for the BGP session should
     be generated.

No text was proposed.

This was discussed in the "Generial Editorial Comment" thread.

----------------------------------------------------------------------------
50) FSM Timers 
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Discussion tabled, because new document version rendered the 
 discussion moot.

Discussion:

This discussion began with a suggestion that the timers currently in the
FSM:

In the 26Aug text, I find the timer terminology still confusing.
Timers can, I find,
stop
start
restart
clear
set
reset
expire

Can be cleaned up and simplified to:

start with initial value (spell it out just to be sure)
stop
expire

A reponse to this proposal was, that the existing set is clear, and that
the proposed set is insufficently rich to describe a concept like "reset"
which encompases:  "Stop the timer, and reset it to its initial value."

This discussion reached an impasse, when Sue pointed out that the text
had been updated, and to please review the new text.

This was discussed in the "FSM more words" thread.

----------------------------------------------------------------------------
51) FSM ConnectRetryCnt
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Discussion tabled, because new document version rendered the
 discussion moot.

Discussion:

This started with the observation that the ConnectRetryCnt "seems to
have lost its purpose."  It was suggested that this be made a 
Session Attribute, along with:  OpenDelayTimer and DelayOpenFlag.

Curtis explained that the current purpose of the ConnectRetryCnt is
something to be read by the MIB.  He also advocated against adding
the additional Session Attributes.

----------------------------------------------------------------------------
52) Section 3: Keeping routes in Adj-RIB-In
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: 
  Add:
    To allow local policy changes to have the correct effect without
    resetting  any BGP connections, a BGP speaker SHOULD either
    (a) retain the current version of the routes advertised to it
    by all of its peers for the duration of the connection, or (b)
    make use of the Route Refresh extension [12].

Discussion:

This thread started with a question about why we should retain routes in
the Adj-RIB-In, and how it relates to the Route Refresh extention.

mrr proposed this text:

  ... Therefore, a BGP speaker must either retain the current version of
  the routes advertised by all of its peers for the duration of the
  connection, or make use of the Route Refresh extension [12].  This
  is necessary to allow local policy changes to have the correct effect
  without requiring the reset of any peering sessions.

  If the implementation decides not to retain the current version of
  the routes that have been received from a peer, then Route Refresh
  messages should be sent whenever there is a change to local policy.

Yakov later suggsted this text, with a slight rewording:

    To allow local policy changes to have the correct effect without
    resetting  any BGP connections, a BGP speaker SHOULD either
    (a) retain the current version of the routes advertised to it
    by all of its peers for the duration of the connection, or (b)
    make use of the Route Refresh extension [12].

mrr reponded that he was fine with Yakov's suggestions.

This was discussed in the "Proxy: comments on section 3" thread.

----------------------------------------------------------------------------
53) Section 4.3 - Routes v. Destinations - Advertise
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Clean up the wording in text surrounding the UPDATE message.
 There was no discussion or consensus on this.  But, does the consensus
 change reached in issue 54 address this sufficently?

Discussion:

This issue arose out of this question to the list:

Since:

"For the purpose of this protocol, a route is defined as a unit of
information that pairs a set of destinations with the attributes of a
path to those destinations.  The set of destinations are the systems
whose IP addresses are reported in the Network Layer Reachability
Information (NLRI) field and the path is the information reported in the
path attributes field of the same UPDATE message."

When I read section 4.3:

"An UPDATE message is used to advertise feasible routes sharing common
   path attribute to a peer, or to withdraw multiple unfeasible routes
   from service (see 3.1)."

Shouldn't the text read "... advertise feasible [prefixes |
destinations] sharing common path attribute(S)to a peer ...", because:

1) A route is defined as quoted above from section 3.1?

or since ...

"An UPDATE message can advertise at most one set of path attributes, but
multiple destinations ..."

2) make "routes" in the orignal singular.

There was no discussion or consensus on this.

This was discussed in the "Review Comments: Section 4.3: "routes" vs.
destinations - advertise" thread.

----------------------------------------------------------------------------
54) Section 4.3 - Routes v. Destinations - Withdraw
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Change the definition of "route" as it currently stands to:

   For the purpose of this protocol, a route is defined as a unit
   of information that pairs a set of destinations with the attributes
   of a path to those destinations. The set of destinations are
   systems whose IP addresses are contained in one IP address prefix
   carried in the Network Layer Reachability Information (NLRI)
   field of an UPDATE message and the path is the information
   reported in the path attributes field of the same UPDATE message.

   Multiple routes that have the same path attributes can be
   advertised in a single UPDATE message by including multiple
   prefixes in the NLRI field of the UPDATE message.

Discussion:

This issue was brought up with this question:

When I read these two paragraphs at the end of section 4.3:

"An UPDATE message can list multiple routes to be withdrawn from
service.  Each such route is identified by its destination (expressed as
an IP prefix), which unambiguously identifies the route in the context
of the BGP speaker - BGP speaker connection to which it has been
previously advertised.

An UPDATE message might advertise only routes to be withdrawn from
service, in which case it will not include path attributes or Network
Layer Reachability Information. Conversely, it may advertise only a
feasible route, in which case the WITHDRAWN ROUTES field need not be
present."

It reads as if one must withdraw the _set of destinations_ advertised
with the route instead of just one or more destinations since route is
defined in section 3.1 as:

"For the purpose of this protocol, a route is defined as a unit of
information that pairs a set of destinations with the attributes of a
path to those destinations.  The set of destinations are the systems
whose IP addresses are reported in the Network Layer Reachability
Information (NLRI) field and the path is the information reported in the
path attributes field of the same UPDATE message."

Shouldn't the text change "routes" to destinations, or to prefixes?

The original commentor added this clarificaiton later:

I meant to say, the *same* set of destinations as those advertised
initially.  For example, NLRI with dest-a, dest-b and dest-c with the
same attributes is a "route".  The withdrawal of the "route" can be read
as one must withdraw all destinations originally advertised for that
route (dest-a, dest-b, dest-c) as a unit.

A first time reader could be left wondering if the above must be the
case, or it is valid for an implementation to withdraw just one of these
destinations (e.g. dest-b), leaving the others (dest-a, dest-c)
reachable with their attributes intact.

If there is no relationship between destinations when advertised as a
set of destinations in a route and those destinations that can be
withdrawn should be explicitly stated.  Otherwise, the draft should call
out that it is not legal to withdraw one prefix only in the set of
prefixes advertised as previously as route.

Matt suggested that since the definition seems to cause some confusion,
that we update teh definition to:

  "For the purpose of this protocol, a route is defined as a unit of
  information that pairs a set of destinations with the attributes of a
  path to those destinations.  The set of destinations are systems whose
  IP addresses are reported in one prefix present in the Network Layer
  Reachability Information (NLRI) field of an UPDATE and the path is the
  information reported in the path attributes field of the same UPDATE
  message.
 
  This definition allows multiple routes to be advertised in a single
  UPDATE message by including multiple prefixes in the NLRI field of
  the UPDATE.  All such prefixes must be associated with the same set
  of path attributes."

Yakov suggested some minor rewording:

   For the purpose of this protocol, a route is defined as a unit
   of information that pairs a set of destinations with the attributes
   of a path to those destinations. The set of destinations are
   systems whose IP addresses are contained in one IP address prefix
   carried in the Network Layer Reachability Information (NLRI)
   field of an UPDATE message and the path is the information
   reported in the path attributes field of the same UPDATE message.

   Multiple routes that have the same path attributes can be
   advertised in a single UPDATE message by including multiple
   prefixes in the NLRI field of the UPDATE message.

Both Jeff and Matt responded that they liked this text.

----------------------------------------------------------------------------
55) Section 4.3 - Description of AS_PATH length
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Should we clarify, such as adding an ASCII diagram, the description
 of AS_PATH length?  No diagram or text has been proposed.

Discussion:

This question was raised:

Length fields elsewhere in the draft specify the number of bytes that a
variable length field uses.  For AS_PATH, length is used as the number
of 2 byte AS numbers.  In the interest of not having to check other
sources to be sure, should the descripton of path segment value:
 
"The path segment value field contains one or more AS numbers, each
encoded as a 2-octets long field."

explicitly mention the number of bytes used by the variable length field?

Or, make the description of length explicitly mention that it is not the
length of the variable length field as is the case with other length fields?

One respone to this agreed that some more clarification would be good,
specifically an ASCII art diagram.  No diagram was proposed.

----------------------------------------------------------------------------
56) Section 6 - BGP Error Handling
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: We have some issues that were brought up that are already addressed.
 There is this text on the table:

   When any of the conditions described here are detected, a NOTIFICATION
   message with the indicated Error Code, Error Subcode, and Data
   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 close.

 And this propsoed move of the condition where you receive a route with
 your own AS to section 9:

   I would suggest to move this text to Section 9 (UPDATE message handling),
   as receiving a route with your own AS in the AS path isn't really  
   an error. It is just that usually (but not always) you can't put
   this route in your Adj-RIB-In.

 The other issues in the discussion have been addressed.

Discussion:

This discussion began with some suggestions on ways to clarify the text
in section 6 dealing with error handling.  The original comments, and
Yakov's response are below:

> At the beginning of Section 6. BGP Error Handling:
>
>
>     "When any of the conditions described here are detected, a
>     NOTIFICATION message with the indicated Error Code, Error Subcode,
>     and Data fields is sent, and the BGP connection is closed."
>
> There are several cases where the conditions described in this section
> do not result in the BGP connection being closed.  These conditions
> should either state that the connection stays up.  Another possibility
> is to remove "and the BGP connection is closed." above, and for each
> listed connection, state what happens to the BGP connection.  This
> already takes place for certain conditions, but isn't done consistantly.
    
How about replacing the above with the following:

   When any of the conditions described here are detected, a NOTIFICATION
   message with the indicated Error Code, Error Subcode, and Data
   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 close.
>
>
> I tried to list what I found (which may be wrong or incomplete) below:
>
>
>
> "If the NEXT_HOP attribute is semantically incorrect, the error should
> be logged, and the route should be ignored. In this case, no
> NOTIFICATION message should be sent."
>
> * Append the connection is not closed.

Done.

>   
> "(a) discard new address prefixes from the neighbor, or (b) terminate
> the BGP peering with the neighbor."
>
> * Append "the connection is not closed" to case (a)

added "(while maintaining BGP peering with the neighbor)" to case (a).
 
> 
>     "If
>     the autonomous system number appears in the AS path the route may be
>     stored in the Adj-RIB-In,"
> 
> * append and the BGP connection stays up.
>   
>                                 "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."
I would suggest to move this text to Section 9 (UPDATE message handling),
as receiving a route with your own AS in the AS path isn't really  
an error. It is just that usually (but not always) you can't put
this route in your Adj-RIB-In.
 
> 
> * Q1) does the BGP connection stay up?
 
yes.

> * Q2) what if the router isn't configured to accept routes with its own
> AS in the AS path?  One _may_ store the route in Adj-RIB-In, but if one
> doesn't want to?

So, don't store them.

> Is the BGP connection closed?  If so, what subcode?
    
The connection is *not* closed.

>     "If an optional attribute is recognized, then the value of this
>     attribute is checked. If an error is detected, the attribute is
>     discarded, and the Error Subcode is set to Optional Attribute Error.
>     The Data field contains the attribute (type, length and value)."
>
> * Append and the BGP conneciton stays up after "the attribute is discarded".

Since you have to close the connection, you have to discard all the
routes received via this connection, including the route with the
incorrect attribute. So, there is no need to say that "the attribute
is discarded".

This was discussed in the "-17 review Section 6 - BGP Error Handling."
thread.

----------------------------------------------------------------------------
57) Section 6.2 - Hold timer as Zero
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: It was suggested that we update the text to say that we MUST 
  reject hold time values of zero.  It was pointed out that this is not
  the case and the text should say the way it is.

Discussion:

In Section 6.2 on OPEN message error handling:

    If the Hold Time field of the OPEN message is unacceptable, then the
    Error Subcode MUST be set to Unacceptable Hold Time. An
    implementation MUST reject Hold Time values of one or two seconds.

I feel that text similar to:
  
"An implementation MUST also reject Hold Time values of zero received
from a peer in a different AS" should be considered for completeness.

A number of respondants pointed out that zero hold time is legitimate 
under certain circumstances.

This was discussed in the "-17 review, Section 6.2 - must reject hold time"
thread.

----------------------------------------------------------------------------
58) Deprication of ATOMIC_AGGREGATE
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: It is proposed that ATOMIC_AGGREGATE be depricated.  There has 
 not yet been any discussion on the proposed changes.

Discussion:

Jeff opened this discussion with:

Deprecation of ATOMIC_AGGREGATE:
    
[This is a summary of some discussions from those who have "been there,
done that" during the CIDR deployment period and also comments
from network operators on the NANOG list.]

When BGP-4 was originally drafted, the topic of aggregation was new
enough that people didn't exactly know how it would be used.   
Additionally, there were some transition issues when aggregated
networks would need to be de-aggregated and re-advertised into
a classful routing mesh such as BGP-3.

The ATOMIC_AGGREGATE flag was intended to prevent a route from being
de-aggregated when de-aggregation would introduce routing loops.
Note that de-aggregation in this context specifically means making
a less specific route into one or more more-specific routes.

The current BGP draft has two situations where ATOMIC_AGGREGATE
should be appeneded to a route:
1. When a route's AS_PATH is intentionally truncated, such as what
   happens by default on Cisco's, or using the "brief" option on
   GateD.  Juniper has a similar feature - I'm unsure of the default.
2. When two routes are implicitly aggregated in the LocRib such
   that a more specific route is not selected when a less specific
   route is from a given peer.

   Note that this particular feature is not implemented anywhere that
   I am aware of.

3. There is a third case not covered by the specification: Implicit
   aggregation on export - a more specific route is not exported
   and only a less specific one is.

When network operators were asked about de-aggregation practices,
I received about 40 responses.  The majority of these responses confused
de-aggregation with leaking existing more-specific routes that are
used internally rather than explicitly de-aggregating a less-specific route.
    
There were a very few cases of explicit de-aggregation.  One form
was done for purposes of dealing with another ISP creating a routing
DoS by advertising IP space that didn't belong to them - leaked more
specifics alleviated the problem in many cases.  (Note that this is
a security issue in the routing system.)

The second case was de-aggregating routes internally (and sending the
routes via IBGP marked with NO-ADVERTISE) for purposes of traffic
engineering routing internally where a given upstream failed to
provide enough routing information to allow traffic flows to be
optimized based on supplied prefixes.

My conclusions to this are:
1. De-aggregation is not a common practice.
2. It is no longer a major concern since classful inter-domain routing
   is pretty much gone.
3. The spec doesn't match reality and should be corrected.

My suggestions are thus this:
Section 5.1.6 should be updated as follows:
   ATOMIC_AGGREGATE is a well-known discretionary attribute.  Its
   use is deprecated.
   
   When a router explicitly aggregates several routes for the purpose of
   advertisement to a particular peer, and the AS_PATH of the aggregated
   route excludes at least some of the AS numbers present in the AS_PATH
   of the routes that are aggregated (usually due to truncation), the
   aggregated route, when advertised to the peer, MUST include the 
   ATOMIC_AGGREGATE attribute.
   
Section 9.1.4 should be updated as follows:
Original text:
:    If a BGP speaker receives overlapping routes, the Decision Process 
:    MUST consider both routes based on the configured acceptance policy.
:    If both a less and a more specific route are accepted, then the
:    Decision Process MUST either install both the less and the more
:    specific routes or it MUST aggregate the two routes and install the
:    aggregated route, provided that both routes have the same value of
:    the NEXT_HOP attribute.
:
:    If a BGP speaker chooses to aggregate, then it MUST add
:    ATOMIC_AGGREGATE attribute to the route. A route that carries
:    ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the
:    NLRI of this route can not be made more specific. Forwarding along
:    such a route does not guarantee that IP packets will actually
:    traverse only ASs listed in the AS_PATH attribute of the route.

Replace with:

   It is common practice that more specific routes are often
   implicitly aggregated by selecting or advertising only a less-specific
   route when overlapping routes are present.  As such, all routes
   SHOULD be treated as if ATOMIC_AGGREGATE is present and not be made
   more specific (de-aggregated).  De-aggregation may lead to routing
   loops.

Section 9.2.2 should remain as it is.
   
Implications of not making the above updates:
ATOMIC_AGGREGATE is not implemented as documented.  Current operational 
practices do not seem to often trigger situations that it was
intended to remediate.  After all, by the way it is currently documented,
many of the routes in the Internet would likely have ATOMIC_AGGREGATE.
   
The original motivation for this investigation (aside from a few years
of wondering what this portion of the spec *really* meant) was
making sure the MIB is correctly documented.  I can do this now,
even if the spec is not corrected by simply noting that the values:
lessSpecificRouteNotSelected(1),
lessSpecificRouteSelected(2)

mean:
ATOMIC_AGGREGATE not present
ATOMIC_AGGREGATE present

rather than documenting anything about less and more specific routes.

The v2MIB can be fixed to just call it what it is since it hasn't 
been RFC'ed yet.

Lastly, the spec would just be incorrect.
But all said, nothing bad would really come of this.

--PNTmBPCT7hxwcZjr--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA27210 for <[e-mail]>; Tue, 24 Sep 2002 17:59:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EEA2C9128B; Tue, 24 Sep 2002 17:58:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBFE29128F; Tue, 24 Sep 2002 17:58:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 56B859128B for <[e-mail]>; Tue, 24 Sep 2002 17:58:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 46D485E111; Tue, 24 Sep 2002 17:58:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 82BD55DDC8 for <[e-mail]>; Tue, 24 Sep 2002 17:58:56 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HMGM>; Tue, 24 Sep 2002 17:58:55 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: your mail
Date: Tue, 24 Sep 2002 17:58:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Thanks for the prompt reply.  A major vendor sets it to 0x0E for v2,3,4.
Another vendor sets it to 0x10 for v1.  These are 2 other ways to interpret
this (both incorrect).  Interesting.

-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Tuesday, September 24, 2002 5:46 PM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: your mail

On Tue, Sep 24, 2002 at 05:38:52PM -0400, Natale, Jonathan wrote:
> The way I read the bgpVersion SNMP object description, it should be set to
> 0x7000 if you support versions 2, 3, and 4; 0x1000 if you support version
4.
> Is this correct?

According to the MIB, yes.

> Thank you.

-- 
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 RAA26762 for <[e-mail]>; Tue, 24 Sep 2002 17:46:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4E6CA91286; Tue, 24 Sep 2002 17:46:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09C369128B; Tue, 24 Sep 2002 17:46:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A5D6D91286 for <[e-mail]>; Tue, 24 Sep 2002 17:46:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3C41C5E12C; Tue, 24 Sep 2002 17:46:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id B345F5DDC8 for <[e-mail]>; Tue, 24 Sep 2002 17:46:01 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8OLjwl07390; Tue, 24 Sep 2002 17:45:58 -0400 (EDT) (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 g8OLjsG07382; Tue, 24 Sep 2002 17:45:54 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8OLjs811601; Tue, 24 Sep 2002 17:45:54 -0400 (EDT)
Date: Tue, 24 Sep 2002 17:45:54 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: your mail
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, Sep 24, 2002 at 05:38:52PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Sep 24, 2002 at 05:38:52PM -0400, Natale, Jonathan wrote:
> The way I read the bgpVersion SNMP object description, it should be set to
> 0x7000 if you support versions 2, 3, and 4; 0x1000 if you support version 4.
> Is this correct?

According to the MIB, yes.

> Thank you.

-- 
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 RAA26548 for <[e-mail]>; Tue, 24 Sep 2002 17:39:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B7CE19121A; Tue, 24 Sep 2002 17:38:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 87B2991286; Tue, 24 Sep 2002 17:38:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2C4B99121A for <[e-mail]>; Tue, 24 Sep 2002 17:38:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0CD775E12C; Tue, 24 Sep 2002 17:38:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 5D5D75DEA6 for <[e-mail]>; Tue, 24 Sep 2002 17:38:55 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1HM1Q>; Tue, 24 Sep 2002 17:38:53 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: 
Date: Tue, 24 Sep 2002 17:38:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

The way I read the bgpVersion SNMP object description, it should be set to
0x7000 if you support versions 2, 3, and 4; 0x1000 if you support version 4.
Is this correct?

Thank you.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA16392 for <[e-mail]>; Tue, 24 Sep 2002 12:23:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4B36291269; Tue, 24 Sep 2002 12:23:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18E4B9128B; Tue, 24 Sep 2002 12:23:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 232DB91269 for <[e-mail]>; Tue, 24 Sep 2002 12:23:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 06A3C5E0E9; Tue, 24 Sep 2002 12:23:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 84F855E0E7 for <[e-mail]>; Tue, 24 Sep 2002 12:23:17 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA10311; Tue, 24 Sep 2002 12:23:15 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA18733; Tue, 24 Sep 2002 12:23:15 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7GG9Z>; Tue, 24 Sep 2002 12:23:15 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Alexei Roudnev'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>
Cc: [e-mail]
Subject: RE: BGP - IGP Redistribution Issue
Date: Tue, 24 Sep 2002 12:23:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Agreed, are there other "good practice" issues that can be added to this
spec?

Ben

> -----Original Message-----
> From: Alexei Roudnev [mailto:[e-mail]]
> Sent: Tuesday, September 24, 2002 12:11 PM
> To: Abarbanel, Benjamin; 'Jeffrey Haas'
> Cc: [e-mail]
> Subject: Re: BGP - IGP Redistribution Issue
> 
> 
> > > As much as I would really like to incorporate some of the 
> best current
> > > practices that network operators have in operating BGP networks in
> > > a 1772 replacement, we shouldn't try to reproduce works such as
> > > Halabi's book in a RFC.
> > >
> >
> > I thought Halabi's book was derived from IETF Specs and Cisco field
> > experience.
> It was re-written 2 years ago, without sugnificant changes.
> 
> Anyway, it is a good idea to have some statement preventing 
> people from bad
> practices (such as injecting bgp routes into IGP, even in 
> small network).
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA15858 for <[e-mail]>; Tue, 24 Sep 2002 12:09:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C458E9124C; Tue, 24 Sep 2002 12:08:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83CB691269; Tue, 24 Sep 2002 12:08:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3ADFA9124C for <[e-mail]>; Tue, 24 Sep 2002 12:08:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 206E45E0E0; Tue, 24 Sep 2002 12:08:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 511545E0DF for <[e-mail]>; Tue, 24 Sep 2002 12:08:55 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8OG8r897468; Tue, 24 Sep 2002 12:08:53 -0400 (EDT) (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 g8OG8oG97461; Tue, 24 Sep 2002 12:08:50 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8OG8ok02064; Tue, 24 Sep 2002 12:08:50 -0400 (EDT)
Date: Tue, 24 Sep 2002 12:08:50 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: Working Group last call
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, Sep 24, 2002 at 05:55:46AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Tue, Sep 24, 2002 at 05:55:46AM -0700, Yakov Rekhter wrote:
> Just to clarify, what ended yesterday is the comment period on both
> the -17 version excluding FSM, and on the FSM text, as posted
> (separately) by Sue.

Unfortunately, I missed the deadline for this comment due to lack of
time.  Please consider this comment for -19 if we have reason to
make it this far:

Deprecation of ATOMIC_AGGREGATE:

[This is a summary of some discussions from those who have "been there,
done that" during the CIDR deployment period and also comments
from network operators on the NANOG list.]

When BGP-4 was originally drafted, the topic of aggregation was new
enough that people didn't exactly know how it would be used.
Additionally, there were some transition issues when aggregated
networks would need to be de-aggregated and re-advertised into
a classful routing mesh such as BGP-3.

The ATOMIC_AGGREGATE flag was intended to prevent a route from being
de-aggregated when de-aggregation would introduce routing loops.
Note that de-aggregation in this context specifically means making
a less specific route into one or more more-specific routes.

The current BGP draft has two situations where ATOMIC_AGGREGATE
should be appeneded to a route:
1. When a route's AS_PATH is intentionally truncated, such as what
   happens by default on Cisco's, or using the "brief" option on
   GateD.  Juniper has a similar feature - I'm unsure of the default.
2. When two routes are implicitly aggregated in the LocRib such
   that a more specific route is not selected when a less specific
   route is from a given peer.

   Note that this particular feature is not implemented anywhere that
   I am aware of.

3. There is a third case not covered by the specification: Implicit
   aggregation on export - a more specific route is not exported
   and only a less specific one is.

When network operators were asked about de-aggregation practices,
I received about 40 responses.  The majority of these responses confused
de-aggregation with leaking existing more-specific routes that are
used internally rather than explicitly de-aggregating a less-specific route.  

There were a very few cases of explicit de-aggregation.  One form
was done for purposes of dealing with another ISP creating a routing
DoS by advertising IP space that didn't belong to them - leaked more
specifics alleviated the problem in many cases.  (Note that this is
a security issue in the routing system.)

The second case was de-aggregating routes internally (and sending the
routes via IBGP marked with NO-ADVERTISE) for purposes of traffic
engineering routing internally where a given upstream failed to
provide enough routing information to allow traffic flows to be
optimized based on supplied prefixes.

My conclusions to this are:
1. De-aggregation is not a common practice.
2. It is no longer a major concern since classful inter-domain routing 
   is pretty much gone.
3. The spec doesn't match reality and should be corrected.

My suggestions are thus this:
Section 5.1.6 should be updated as follows:
   ATOMIC_AGGREGATE is a well-known discretionary attribute.  Its
   use is deprecated.

   When a router explicitly aggregates several routes for the purpose of
   advertisement to a particular peer, and the AS_PATH of the aggregated
   route excludes at least some of the AS numbers present in the AS_PATH
   of the routes that are aggregated (usually due to truncation), the 
   aggregated route, when advertised to the peer, MUST include the 
   ATOMIC_AGGREGATE attribute.

Section 9.1.4 should be updated as follows:
Original text:
:    If a BGP speaker receives overlapping routes, the Decision Process
:    MUST consider both routes based on the configured acceptance policy.
:    If both a less and a more specific route are accepted, then the
:    Decision Process MUST either install both the less and the more
:    specific routes or it MUST aggregate the two routes and install the
:    aggregated route, provided that both routes have the same value of
:    the NEXT_HOP attribute.
: 
:    If a BGP speaker chooses to aggregate, then it MUST add
:    ATOMIC_AGGREGATE attribute to the route. A route that carries
:    ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the
:    NLRI of this route can not be made more specific. Forwarding along
:    such a route does not guarantee that IP packets will actually
:    traverse only ASs listed in the AS_PATH attribute of the route.

Replace with:

   It is common practice that more specific routes are often
   implicitly aggregated by selecting or advertising only a less-specific
   route when overlapping routes are present.  As such, all routes
   SHOULD be treated as if ATOMIC_AGGREGATE is present and not be made
   more specific (de-aggregated).  De-aggregation may lead to routing
   loops.

Section 9.2.2 should remain as it is.

Implications of not making the above updates:
ATOMIC_AGGREGATE is not implemented as documented.  Current operational
practices do not seem to often trigger situations that it was
intended to remediate.  After all, by the way it is currently documented,
many of the routes in the Internet would likely have ATOMIC_AGGREGATE.

The original motivation for this investigation (aside from a few years
of wondering what this portion of the spec *really* meant) was
making sure the MIB is correctly documented.  I can do this now,
even if the spec is not corrected by simply noting that the values:
lessSpecificRouteNotSelected(1),
lessSpecificRouteSelected(2)

mean:
ATOMIC_AGGREGATE not present
ATOMIC_AGGREGATE present

rather than documenting anything about less and more specific routes.

The v2MIB can be fixed to just call it what it is since it hasn't
been RFC'ed yet.

Lastly, the spec would just be incorrect.
But all said, nothing bad would really come of this.

-- 
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 LAA15416 for <[e-mail]>; Tue, 24 Sep 2002 11:55:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6DE7791258; Tue, 24 Sep 2002 11:54:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 41AE191269; Tue, 24 Sep 2002 11:54:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 47E4B91258 for <[e-mail]>; Tue, 24 Sep 2002 11:54:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2E3D55DF3D; Tue, 24 Sep 2002 11:54:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id A88B95E0E0 for <[e-mail]>; Tue, 24 Sep 2002 11:54:51 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08566; Tue, 24 Sep 2002 11:54:49 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA12305; Tue, 24 Sep 2002 11:54:49 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7GFG3>; Tue, 24 Sep 2002 11:54:48 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: BGP - IGP Redistribution Issue
Date: Tue, 24 Sep 2002 11:54:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Jeff:
  Comments below

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Tuesday, September 24, 2002 11:29 AM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: BGP - IGP Redistribution Issue
> 
> 
> Ben,
> 
> On Tue, Sep 24, 2002 at 11:15:09AM -0400, Abarbanel, Benjamin wrote:
> > Would it make sense to add the recommendation to RFC1772bis, in some
> > practical deployment techniques. I realize its hard to 
> undue what has been
> > cast in concrete, but at least a recommendation could be added.
> 
> As much as I would really like to incorporate some of the best current
> practices that network operators have in operating BGP networks in
> a 1772 replacement, we shouldn't try to reproduce works such as
> Halabi's book in a RFC.
> 

I thought Halabi's book was derived from IETF Specs and Cisco field
experience.
Thus, if RFCs are amended to include more practical things then it should
not
negate any text books that are written by any particular vendor.
 

> While redistributing your BGP into your IGP is a common mistake
> (and usually one that you learn from very quickly) for many network
> operators, there are valid situations where you may want to do
> this intentionally.  The real trick is to make sure that the
> redistributed routes are not accidentally re-injected back into
> BGP to prevent re-origination.
> 
> One technique that I've heard of is to simply tag the injected routes
> such that at the routers where IGP routes are injected that the
> tagged routes are excluded.  But this is just one way, and there
> is more than one way to...
>

RFC1772 Appendix A.2.2 describes this technique.

> Perhaps some suggestions from those who were about when 1772 was
> written to figure out what we should be thinking about for it.
> 
>

RFC1772 Appendix A.2.1 states that its OK to redistribute BGP routes to IGP.

I think this was written (circa 1995) before the BGP tables grew to a
significantly large size. Thus, additional recommendations placed in this 
section in the form of RFC1772bis would take care of the issue.
 

Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA14579 for <[e-mail]>; Tue, 24 Sep 2002 11:29:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 72A2691269; Tue, 24 Sep 2002 11:28:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4459E9128B; Tue, 24 Sep 2002 11:28:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 17D9F91269 for <[e-mail]>; Tue, 24 Sep 2002 11:28:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EA41B5E0DE; Tue, 24 Sep 2002 11:28:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 5BD4C5DF26 for <[e-mail]>; Tue, 24 Sep 2002 11:28:40 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8OFSbU96304; Tue, 24 Sep 2002 11:28:37 -0400 (EDT) (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 g8OFSYG96293; Tue, 24 Sep 2002 11:28:34 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8OFSYm01956; Tue, 24 Sep 2002 11:28:34 -0400 (EDT)
Date: Tue, 24 Sep 2002 11:28:34 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP - IGP Redistribution Issue
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, Sep 24, 2002 at 11:15:09AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Ben,

On Tue, Sep 24, 2002 at 11:15:09AM -0400, Abarbanel, Benjamin wrote:
> Would it make sense to add the recommendation to RFC1772bis, in some
> practical deployment techniques. I realize its hard to undue what has been
> cast in concrete, but at least a recommendation could be added.

As much as I would really like to incorporate some of the best current
practices that network operators have in operating BGP networks in
a 1772 replacement, we shouldn't try to reproduce works such as
Halabi's book in a RFC.

While redistributing your BGP into your IGP is a common mistake
(and usually one that you learn from very quickly) for many network
operators, there are valid situations where you may want to do
this intentionally.  The real trick is to make sure that the
redistributed routes are not accidentally re-injected back into
BGP to prevent re-origination.

One technique that I've heard of is to simply tag the injected routes
such that at the routers where IGP routes are injected that the
tagged routes are excluded.  But this is just one way, and there
is more than one way to...

Perhaps some suggestions from those who were about when 1772 was
written to figure out what we should be thinking about for it.

> Ben

-- 
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 LAA14239 for <[e-mail]>; Tue, 24 Sep 2002 11:16:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 816BF91258; Tue, 24 Sep 2002 11:15:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38C0291269; Tue, 24 Sep 2002 11:15:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA13491258 for <[e-mail]>; Tue, 24 Sep 2002 11:15:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 500BE5E0E0; Tue, 24 Sep 2002 11:15:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 779685E0DE for <[e-mail]>; Tue, 24 Sep 2002 11:15:13 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04993; Tue, 24 Sep 2002 11:15:11 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA00760; Tue, 24 Sep 2002 11:15:11 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7GCBX>; Tue, 24 Sep 2002 11:15:11 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: BGP - IGP Redistribution Issue
Date: Tue, 24 Sep 2002 11:15:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Tuesday, September 24, 2002 11:09 AM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: Generial Editorial Comment
> 
> 
> On Tue, Sep 24, 2002 at 10:27:48AM -0400, Abarbanel, Benjamin wrote:
> > While we are on the subject of BGP interworking with other 
> protocols. If its
> > a bad idea to redistribute the massive BGP tables into IGP 
> protocols such as
> > OSPF/ISIS, should we not have a rule in some spec 
> forbidding it from being
> > done
> > to avoid an IGP meltdown?
> 
> While some may disagree, it is not our place to take the loaded
> shotgun out of the hands of foolish network operators.  Not even
> if they point it at themselves, repeatedly press the trigger
> and wonder why people are telling them it is a bad idea.
> 
> Otherwise known as:
> Rope. Gallows. Have fun.
> 

Would it make sense to add the recommendation to RFC1772bis, in some
practical deployment techniques. I realize its hard to undue what has been
cast in concrete, but at least a recommendation could be added.

Ben



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA13987 for <[e-mail]>; Tue, 24 Sep 2002 11:09:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E22EF9124C; Tue, 24 Sep 2002 11:09:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABC7491258; Tue, 24 Sep 2002 11:09:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 876229124C for <[e-mail]>; Tue, 24 Sep 2002 11:09:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 663185E0DD; Tue, 24 Sep 2002 11:09:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id A98D55E0D5 for <[e-mail]>; Tue, 24 Sep 2002 11:09:09 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8OF8hx95718; Tue, 24 Sep 2002 11:08:43 -0400 (EDT) (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 g8OF8eG95711; Tue, 24 Sep 2002 11:08:40 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8OF8ew01896; Tue, 24 Sep 2002 11:08:40 -0400 (EDT)
Date: Tue, 24 Sep 2002 11:08:40 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: Generial Editorial Comment
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, Sep 24, 2002 at 10:27:48AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Sep 24, 2002 at 10:27:48AM -0400, Abarbanel, Benjamin wrote:
> While we are on the subject of BGP interworking with other protocols. If its
> a bad idea to redistribute the massive BGP tables into IGP protocols such as
> OSPF/ISIS, should we not have a rule in some spec forbidding it from being
> done
> to avoid an IGP meltdown?

While some may disagree, it is not our place to take the loaded
shotgun out of the hands of foolish network operators.  Not even
if they point it at themselves, repeatedly press the trigger
and wonder why people are telling them it is a bad idea.

Otherwise known as:
Rope. Gallows. Have fun.

> Ben

-- 
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 KAA12645 for <[e-mail]>; Tue, 24 Sep 2002 10:28:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7A2D29124C; Tue, 24 Sep 2002 10:27:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43C6C91254; Tue, 24 Sep 2002 10:27:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 43EB69124C for <[e-mail]>; Tue, 24 Sep 2002 10:27:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 228995E0D3; Tue, 24 Sep 2002 10:27:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id A0D555DDB3 for <[e-mail]>; Tue, 24 Sep 2002 10:27:53 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA00666; Tue, 24 Sep 2002 10:27:51 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA17626; Tue, 24 Sep 2002 10:27:51 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7F9VY>; Tue, 24 Sep 2002 10:27:51 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, "'Manav Bhatia'" <[e-mail]>, [e-mail]
Subject: RE: Generial Editorial Comment 
Date: Tue, 24 Sep 2002 10:27:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

That is one reason why its not a good idea to export BGP routes to other
protocols.

While we are on the subject of BGP interworking with other protocols. If its
a bad idea to redistribute the massive BGP tables into IGP protocols such as
OSPF/ISIS, should we not have a rule in some spec forbidding it from being
done
to avoid an IGP meltdown?

Ben

> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Monday, September 23, 2002 9:33 PM
> To: Abarbanel, Benjamin
> Cc: 'Yakov Rekhter'; 'Manav Bhatia'; [e-mail]
> Subject: Re: Generial Editorial Comment 
> 
> 
> 
> In message 
> <[e-mail]>, 
> "Abarbanel, Benjamin" writes:
> > 
> > Overall paragraph sounds good to me.
> > 
> > Except one sentence does'nt sound right.
> > 
> > "Alternately the IGP can pass BGP information among routers 
> within an AS,
> >  taking care not to lose BGP attributes". 
> > 
> >  Is it possible for IGP protocols (OSPF/ISIS) to carry such 
> BGP attributes
> > as  
> >  "AS PATH", in their link state packets?
> 
> This kind of thing could be done by defining a new OSPF opaque LSA.
> Back in 1993 or 1994 Dennis Fergusson proposed an OSPF LSA type 8 for
> this purpose to offset the inadequacy of the rfc1745 use of OSPF tags
> but the internet-draft expired.  Dennis later decided that it wasn't
> such a good idea anyway as the number of BGP routes had grown
> considerably since he made the proposal.
> 
> So the answer with existing IGPs excluding yet to be defined
> extensions is "no".
> 
> > Ben
> 
> 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 IAA09515 for <[e-mail]>; Tue, 24 Sep 2002 08:56:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5FD0C91212; Tue, 24 Sep 2002 08:56:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 278F291213; Tue, 24 Sep 2002 08:56:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D292F91212 for <[e-mail]>; Tue, 24 Sep 2002 08:56:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B994C5E0B6; Tue, 24 Sep 2002 08:56:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 195345E046 for <[e-mail]>; Tue, 24 Sep 2002 08:56:06 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8OCtkm43770; Tue, 24 Sep 2002 05:55:46 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: Jeffrey Haas <[e-mail]>, [e-mail], Alex Zinin <[e-mail]>
Subject: Re: Working Group last call 
In-Reply-To: Your message of "Tue, 24 Sep 2002 02:27:14 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 24 Sep 2002 05:55:46 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Curtis,

> In message <[e-mail]>, Jeffrey Haas writes:
> > On Sun, Sep 22, 2002 at 06:05:54PM -0700, Yakov Rekhter wrote:
> > > Folks,
> > > 
> > > Just to remind you the it ends tomorrow (see below).
> > 
> > Just got my comments in. [mea maxima culpa]
> > 
> > Might I suggest that considering this last call might be one step
> > premature without seeing the updated text?
> > 
> > > Yakov.
> > 
> > -- 
> > Jeff Haas 
> > NextHop Technologies
> 
> 
> It is definitely premature.  You have to repeat the last call if
> anything but editorial changes are made.  Replacing the FSM is more
> than an editorial change.

Just to clarify, what ended yesterday is the comment period on both
the -17 version excluding FSM, and on the FSM text, as posted
(separately) by 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 CAA27220 for <[e-mail]>; Tue, 24 Sep 2002 02:28:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id AF8689129D; Tue, 24 Sep 2002 02:28:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D1189129E; Tue, 24 Sep 2002 02:28:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4A9719129D for <[e-mail]>; Tue, 24 Sep 2002 02:28:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2463F5DE23; Tue, 24 Sep 2002 02:28:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 15EB35E091 for <[e-mail]>; Tue, 24 Sep 2002 02:28:16 -0400 (EDT)
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 CAA78649; Tue, 24 Sep 2002 02:27:14 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail], Alex Zinin <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Working Group last call 
In-reply-to: Your message of "Mon, 23 Sep 2002 13:59:21 EDT." <[e-mail]> 
Date: Tue, 24 Sep 2002 02:27:14 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Jeffrey Haas writes:
> On Sun, Sep 22, 2002 at 06:05:54PM -0700, Yakov Rekhter wrote:
> > Folks,
> > 
> > Just to remind you the it ends tomorrow (see below).
> 
> Just got my comments in. [mea maxima culpa]
> 
> Might I suggest that considering this last call might be one step
> premature without seeing the updated text?
> 
> > Yakov.
> 
> -- 
> Jeff Haas 
> NextHop Technologies


It is definitely premature.  You have to repeat the last call if
anything but editorial changes are made.  Replacing the FSM is more
than an editorial change.

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 WAA18810 for <[e-mail]>; Mon, 23 Sep 2002 22:07:15 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DBC049128F; Mon, 23 Sep 2002 22:06:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A536591293; Mon, 23 Sep 2002 22:06:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 62C499128F for <[e-mail]>; Mon, 23 Sep 2002 22:06:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4962A5E041; Mon, 23 Sep 2002 22:06:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 3FCB75DDBE for <[e-mail]>; Mon, 23 Sep 2002 22:06:53 -0400 (EDT)
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 WAA78009; Mon, 23 Sep 2002 22:05:53 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Generial Editorial Comment 
In-reply-to: Your message of "Mon, 23 Sep 2002 10:27:28 PDT." <[e-mail]> 
Date: Mon, 23 Sep 2002 22:05:53 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Yakov Rekhter writes
:
> > 
> > I thought inter-working with other protocols such as IGP (OSPF/ISIS) is
> > outside the scope of this document. Via previous discussion on this list.
> 
> Just to add to my previous e-mail, here is the modified paragraph:
> 
>    If a particular AS has multiple BGP speakers and is providing
>    transit service for other ASs, then care must be taken to ensure
>    a consistent view of routing within the AS. A consistent view
>    of the interior routes of the AS is provided by the IGP used
>    within the AS. For the purpose of this document, it is assumed
>    that a consistent view of the routes exterior to the AS is
>    provided by having all BGP speakers within the AS maintain direct
>    IBGP with each other. Care must be taken to ensure that the
>    interior routers have all been updated with transit information
>    before the BGP speakers announce to other ASs that transit
>    service is being provided.
> 
> Yakov.
> 


That's fine too.  Sorry for not reading to the end of the thread
before replying.

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 VAA17985 for <[e-mail]>; Mon, 23 Sep 2002 21:40:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 793339129B; Mon, 23 Sep 2002 21:38:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2026091293; Mon, 23 Sep 2002 21:38:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6EE79128F for <[e-mail]>; Mon, 23 Sep 2002 21:38:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C28185E036; Mon, 23 Sep 2002 21:38:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 8488A5DE28 for <[e-mail]>; Mon, 23 Sep 2002 21:38:27 -0400 (EDT)
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 VAA77840; Mon, 23 Sep 2002 21:37:26 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, "'Manav Bhatia'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Generial Editorial Comment 
In-reply-to: Your message of "Mon, 23 Sep 2002 10:00:09 PDT." <[e-mail]> 
Date: Mon, 23 Sep 2002 21:37:26 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Yakov Rekhter writes
:
> > > 
> > > Here is the replacement text:
> > > 
> > >            A consistent view of the routes exterior to the AS can be
> > >    provided by having all BGP speakers within the AS maintain direct 
> > >    IBGP with each other. Alternately the IGP can pass BGP information
> > >    among routers within an AS, taking care not to lose BGP attributes 
> > >    that will be needed by BGP speakers for advertisements to external
> > >    peers if transit connectivity is being provided. For the purpose
> > >    of this document, it is assumed that BGP information is passed
> > >    within an AS using IBGP. Care must be taken to ensure that the
> > >    interior routers have all been updated with transit information
> > >    before the BGP speakers announce to other ASs that transit service
> > >    is being provided.
> > > 
> > > Yakov.
> > >
> > 
> > Overall paragraph sounds good to me.
> > 
> > Except one sentence does'nt sound right.
> > 
> > "Alternately the IGP can pass BGP information among routers within an AS,
> >  taking care not to lose BGP attributes". 
> > 
> >  Is it possible for IGP protocols (OSPF/ISIS) to carry such BGP attributes
> > as  "AS PATH", in their link state packets?
> 
> It is certainly possible, at least in *theory*, to define new TLVs to carry
> BGP attributes in OSPF/ISIS. Whether doing this makes sense in *practice*
> is a separate issue. I think it would be fair to say that we've yet to
> see any empirical evidences that doing this would be any better than using 
> IBGP. And it is certainly true that as of today neither ISIS nor OSPF
> supports this capability.
> 
> So, with this in mind I think we should either (a) delete this sentence
> altogether, or (b) replace it with the following:
> 
>   Alternately, at least in principle, the IGP (with appropriate
>   extensions) can pass BGP information among routers within an AS,
>   taking care not to lose BGP attributes. At the time of this writing
>   none of the IGPs have this capability. Whether doing this would
>   offer any practical benefits over using IBGP is outside the scope
>   of this document.
> 
> Yakov.


Yakov,

That is a good replacement.

Curtis


ps - I found a copy of Dennis' draft "The OSPF External Attributes
LSA", dated March 1993, expired September 1993.  Nice nostalgia item.  :-)


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA17730 for <[e-mail]>; Mon, 23 Sep 2002 21:34:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6910B9120C; Mon, 23 Sep 2002 21:33:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36DEF91210; Mon, 23 Sep 2002 21:33:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EA0B69120C for <[e-mail]>; Mon, 23 Sep 2002 21:33:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CD4505E035; Mon, 23 Sep 2002 21:33:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id C8D485DE28 for <[e-mail]>; Mon, 23 Sep 2002 21:33:40 -0400 (EDT)
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 VAA77820; Mon, 23 Sep 2002 21:32:39 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, "'Manav Bhatia'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Generial Editorial Comment 
In-reply-to: Your message of "Mon, 23 Sep 2002 12:47:30 EDT." <[e-mail]> 
Date: Mon, 23 Sep 2002 21:32:39 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> 
> Overall paragraph sounds good to me.
> 
> Except one sentence does'nt sound right.
> 
> "Alternately the IGP can pass BGP information among routers within an AS,
>  taking care not to lose BGP attributes". 
> 
>  Is it possible for IGP protocols (OSPF/ISIS) to carry such BGP attributes
> as  
>  "AS PATH", in their link state packets?

This kind of thing could be done by defining a new OSPF opaque LSA.
Back in 1993 or 1994 Dennis Fergusson proposed an OSPF LSA type 8 for
this purpose to offset the inadequacy of the rfc1745 use of OSPF tags
but the internet-draft expired.  Dennis later decided that it wasn't
such a good idea anyway as the number of BGP routes had grown
considerably since he made the proposal.

So the answer with existing IGPs excluding yet to be defined
extensions is "no".

> Ben

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 QAA07933 for <[e-mail]>; Mon, 23 Sep 2002 16:28:24 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2C4DC91269; Mon, 23 Sep 2002 16:27:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA1209126E; Mon, 23 Sep 2002 16:27:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D7EA491269 for <[e-mail]>; Mon, 23 Sep 2002 16:27:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C1E335DF3C; Mon, 23 Sep 2002 16:27:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 107375DF07 for <[e-mail]>; Mon, 23 Sep 2002 16:27:44 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8NKRgR73127; Mon, 23 Sep 2002 16:27:42 -0400 (EDT) (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 g8NKRdG73120; Mon, 23 Sep 2002 16:27:39 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g8NKRdx16011; Mon, 23 Sep 2002 16:27:39 -0400 (EDT)
Date: Mon, 23 Sep 2002 16:27:39 -0400
From: Mathew Richardson <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: Proxy: comments on section 3
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4i
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

> Yakov Rekhter <[e-mail]> [Mon, Sep 23, 2002 at 01:04:08PM -0700]:
>Matt,

<snip>

>How about the slight rewording, as follows:
>
>    To allow local policy changes to have the correct effect without
>    resetting  any BGP connections, a BGP speaker SHOULD either
>    (a) retain the current version of the routes advertised to it
>    by all of its peers for the duration of the connection, or (b)
>    make use of the Route Refresh extension [12].

<snip>

That sounds good.

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 QAA07207 for <[e-mail]>; Mon, 23 Sep 2002 16:04:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 17F3A91238; Mon, 23 Sep 2002 16:04:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3D6091265; Mon, 23 Sep 2002 16:04:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D00091238 for <[e-mail]>; Mon, 23 Sep 2002 16:04:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 825305DF3C; Mon, 23 Sep 2002 16:04:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id E4C255DDC5 for <[e-mail]>; Mon, 23 Sep 2002 16:04:09 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8NK48m90010; Mon, 23 Sep 2002 13:04:08 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Mathew Richardson <[e-mail]>
Cc: [e-mail]
Subject: Re: Proxy: comments on section 3 
In-Reply-To: Your message of "Fri, 06 Sep 2002 09:23:21 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 23 Sep 2002 13:04:08 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Matt,

> >Something at the beginning of Section 3 of  is not clear.  
> >
> >> The initial data flow is the portion of the BGP routing table that is
> >> allowed by the export policy, called the Adj-Ribs-Out (see 3.2).
> >> Incremental updates are sent as the routing tables change. BGP does
> >> not require periodic refresh of the routing table. Therefore, a BGP
> >> speaker __must__ retain the current version of the routes advertised by
> >> all of its peers for the duration of the connection. 
> >
> >Shouldn't "must retain" be "SHOULD retain"?  The text that comes next
> >(below) contradicts "must".
> > 
> >> If the
> >> implementation decides to not store the routes that have been
> >> received from a peer, but have been filtered out according to
> >> configured local policy, the BGP Route Refresh extension [12] may be
> >> used to request the full set of routes from a peer without resetting
> >> the BGP session when the local policy configuration changes.
> >
> >Regarding Route Refresh, this is clear.  When I change local policy, I would
> >need to trigger a "Route Refresh" (e.g. clear ip bgp).
> >
> >However, what about if route refresh isn't supported (locally or by the
> >remote peer, or both)?
> 
> This is why you must retain them.  I, personally, was against adding
> the Route Refresh text to the base spec, and would still like to see
> it removed.  Given that I'm in the minority on this, how about something
> like:
> 
>   ... Therefore, a BGP speaker must either retain the current version of
>   the routes advertised by all of its peers for the duration of the
>   connection, or make use of the Route Refresh extension [12].  This
>   is necessary to allow local policy changes to have the correct effect
>   without requiring the reset of any peering sessions.
> 
>   If the implementation decides not to retain the current version of
>   the routes that have been received from a peer, then Route Refresh
>   messages should be sent whenever there is a change to local policy.

How about the slight rewording, as follows:

    To allow local policy changes to have the correct effect without
    resetting  any BGP connections, a BGP speaker SHOULD either
    (a) retain the current version of the routes advertised to it
    by all of its peers for the duration of the connection, or (b)
    make use of the Route Refresh extension [12].

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 PAA05661 for <[e-mail]>; Mon, 23 Sep 2002 15:16:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D5E48912A9; Mon, 23 Sep 2002 15:15:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D67C912AF; Mon, 23 Sep 2002 15:15:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2B113912A9 for <[e-mail]>; Mon, 23 Sep 2002 15:15:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C43AC5DE4B; Mon, 23 Sep 2002 15:15:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 062555DDC5 for <[e-mail]>; Mon, 23 Sep 2002 15:15:12 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8NJFAc70429 for [e-mail]; Mon, 23 Sep 2002 15:15:10 -0400 (EDT) (envelope-from [e-mail])
Received: from amidala.nexthop.com (dchopra.nexthop.com [64.211.218.117]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g8NJF7G70422 for <[e-mail]>; Mon, 23 Sep 2002 15:15:07 -0400 (EDT) (envelope-from [e-mail])
Received: from localhost (localhost [[UNIX: localhost]]) by amidala.nexthop.com (8.11.3/8.11.3) with ESMTP id g8NJF7c29735 for <[e-mail]>; Mon, 23 Sep 2002 15:15:07 -0400 (EDT)
X-Authentication-Warning: amidala.nexthop.com: dchopra owned process doing -bs
Date: Mon, 23 Sep 2002 15:15:07 -0400 (EDT)
From: Disha Chopra <[e-mail]>
To: <[e-mail]>
Subject: question on when to apply ORF received with DEFER flag
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

I have a question about when the ORF that is received with a DEFER flag
should be applied.
Consider the scenario in which we receive an ORF (with DEFER) and
that would prevent a route "foo" from going out.
We have not yet received the ORF with flag IMMEDIATE and niether have we
received an Route Refresh message with no ORFS.
Should the previously queued route "foo" be sent out or should it be held
back?

Thanks for your time
Regards,
-Disha






Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA04254 for <[e-mail]>; Mon, 23 Sep 2002 14:33:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3ADE9912A0; Mon, 23 Sep 2002 14:33:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06616912A5; Mon, 23 Sep 2002 14:33:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C1F07912A0 for <[e-mail]>; Mon, 23 Sep 2002 14:33:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9FD5E5E008; Mon, 23 Sep 2002 14:33:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 767B15DF40 for <[e-mail]>; Mon, 23 Sep 2002 14:33:12 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17tY18-000B0g-00; Mon, 23 Sep 2002 11:33:10 -0700
Date: Mon, 23 Sep 2002 11:31:19 -0700
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: Re: Generial Editorial Comment
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Yakov,

[...]
> Please suggest the appropriate text.

Please see if document editors can use the contents of the message I
sent months ago to initiate the discussion:

> Date: Thu, 17 Jan 2002 17:44:11 -0800
> From: Alex Zinin <[e-mail]>
> Message-ID: <[e-mail]>
> To: [e-mail]
> Subject: More thoughts on FSM

BTW, it also has a draft of the FSM state diagram, which I also think
would be quite useful.

Alex




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA03962 for <[e-mail]>; Mon, 23 Sep 2002 14:26:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E66349129A; Mon, 23 Sep 2002 14:25:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1615912A0; Mon, 23 Sep 2002 14:25:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 530659129A for <[e-mail]>; Mon, 23 Sep 2002 14:25:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3149F5E009; Mon, 23 Sep 2002 14:25:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id CA5325DE07 for <[e-mail]>; Mon, 23 Sep 2002 14:25:20 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8NIPIm77796; Mon, 23 Sep 2002 11:25:18 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: Generial Editorial Comment 
In-Reply-To: Your message of "Mon, 23 Sep 2002 14:12:13 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 23 Sep 2002 11:25:18 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> Yakov,
>   The frequently used terms, IBGP, EBGP, Speakers, peers, withdrawn routes,
> unfeasable routes, connections, sessions, Adj-Rib-in, Loc-Rib, Adj-Rib-out,
> various config parameters, timers, data structures, etc, etc. All should be
> added to the new section called "Frequently Used Terms", or whatever you
> choose to call it. 

The -18 version is going to have a new section "Definition of commonly 
used terms". This section will provide definition for terms that have a 
specific meaning to the BGP protocol and that are used throughout the text.

Yakov.

> 
> 
> Ben
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Monday, September 23, 2002 2:05 PM
> > To: Jeffrey Haas
> > Cc: [e-mail]
> > Subject: Re: Generial Editorial Comment 
> > 
> > 
> > Jeff,
> > 
> > > Yakov,
> > > 
> > > On Mon, Sep 23, 2002 at 10:27:28AM -0700, Yakov Rekhter wrote:
> > > > Just to add to my previous e-mail, here is the modified paragraph:
> > > [...]
> > > 
> > > >    that a consistent view of the routes exterior to the AS is
> > > >    provided by having all BGP speakers within the AS 
> > maintain direct
> > > >    IBGP with each other.
> > > 
> > > "direct IBGP" slightly implies that the routers are 
> > directly connected
> > > to each other - i.e. on the same link.
> > > 
> > > I'd suggest "maintain IBGP connections/sessions"
> > 
> > The term "IBGP" means "BGP connection between internal peers".
> > So, there is no need to say "IBGP connections" - "IBGP" should be
> > sufficient. I'll be glad to drop the word "direct" though...
> > 
> > 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 OAA03533 for <[e-mail]>; Mon, 23 Sep 2002 14:12:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F035891296; Mon, 23 Sep 2002 14:12:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5A3C91299; Mon, 23 Sep 2002 14:12:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C628691296 for <[e-mail]>; Mon, 23 Sep 2002 14:12:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B6BD95E00E; Mon, 23 Sep 2002 14:12:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 43A565E00C for <[e-mail]>; Mon, 23 Sep 2002 14:12:26 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA24805; Mon, 23 Sep 2002 14:12:23 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA27253; Mon, 23 Sep 2002 14:12:25 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7103N>; Mon, 23 Sep 2002 14:12:24 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: RE: Generial Editorial Comment 
Date: Mon, 23 Sep 2002 14:12:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov,
  The frequently used terms, IBGP, EBGP, Speakers, peers, withdrawn routes,
unfeasable routes, connections, sessions, Adj-Rib-in, Loc-Rib, Adj-Rib-out,
various config parameters, timers, data structures, etc, etc. All should be
added to the new section called "Frequently Used Terms", or whatever you
choose to call it. 


Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Monday, September 23, 2002 2:05 PM
> To: Jeffrey Haas
> Cc: [e-mail]
> Subject: Re: Generial Editorial Comment 
> 
> 
> Jeff,
> 
> > Yakov,
> > 
> > On Mon, Sep 23, 2002 at 10:27:28AM -0700, Yakov Rekhter wrote:
> > > Just to add to my previous e-mail, here is the modified paragraph:
> > [...]
> > 
> > >    that a consistent view of the routes exterior to the AS is
> > >    provided by having all BGP speakers within the AS 
> maintain direct
> > >    IBGP with each other.
> > 
> > "direct IBGP" slightly implies that the routers are 
> directly connected
> > to each other - i.e. on the same link.
> > 
> > I'd suggest "maintain IBGP connections/sessions"
> 
> The term "IBGP" means "BGP connection between internal peers".
> So, there is no need to say "IBGP connections" - "IBGP" should be
> sufficient. I'll be glad to drop the word "direct" though...
> 
> 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 OAA03467 for <[e-mail]>; Mon, 23 Sep 2002 14:11:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 995EE91297; Mon, 23 Sep 2002 14:10:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 68AB491296; Mon, 23 Sep 2002 14:10:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3998691297 for <[e-mail]>; Mon, 23 Sep 2002 14:10:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1B7855E010; Mon, 23 Sep 2002 14:10:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 596B45E008 for <[e-mail]>; Mon, 23 Sep 2002 14:10:34 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8NIAWU68769; Mon, 23 Sep 2002 14:10:32 -0400 (EDT) (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 g8NIAQG68750; Mon, 23 Sep 2002 14:10:26 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8NIAQW14747; Mon, 23 Sep 2002 14:10:26 -0400 (EDT)
Date: Mon, 23 Sep 2002 14:10:26 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: Generial Editorial Comment
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, Sep 23, 2002 at 11:04:30AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Mon, Sep 23, 2002 at 11:04:30AM -0700, Yakov Rekhter wrote:
> The term "IBGP" means "BGP connection between internal peers".
> So, there is no need to say "IBGP connections" - "IBGP" should be
> sufficient. I'll be glad to drop the word "direct" though...

That would work.

> 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 OAA03294 for <[e-mail]>; Mon, 23 Sep 2002 14:04:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8F5909128B; Mon, 23 Sep 2002 14:04:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5EED591296; Mon, 23 Sep 2002 14:04:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 38DBC9128B for <[e-mail]>; Mon, 23 Sep 2002 14:04:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 216B95DF6D; Mon, 23 Sep 2002 14:04:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 7BC9E5DE07 for <[e-mail]>; Mon, 23 Sep 2002 14:04:31 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8NI4Um75178; Mon, 23 Sep 2002 11:04:30 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: Generial Editorial Comment 
In-Reply-To: Your message of "Mon, 23 Sep 2002 13:56:51 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 23 Sep 2002 11:04:30 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> Yakov,
> 
> On Mon, Sep 23, 2002 at 10:27:28AM -0700, Yakov Rekhter wrote:
> > Just to add to my previous e-mail, here is the modified paragraph:
> [...]
> 
> >    that a consistent view of the routes exterior to the AS is
> >    provided by having all BGP speakers within the AS maintain direct
> >    IBGP with each other.
> 
> "direct IBGP" slightly implies that the routers are directly connected
> to each other - i.e. on the same link.
> 
> I'd suggest "maintain IBGP connections/sessions"

The term "IBGP" means "BGP connection between internal peers".
So, there is no need to say "IBGP connections" - "IBGP" should be
sufficient. I'll be glad to drop the word "direct" though...

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 NAA03128 for <[e-mail]>; Mon, 23 Sep 2002 13:59:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 68FBA91295; Mon, 23 Sep 2002 13:59:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3479291296; Mon, 23 Sep 2002 13:59:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2CA2A91295 for <[e-mail]>; Mon, 23 Sep 2002 13:59:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 13E6B5DF07; Mon, 23 Sep 2002 13:59:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 345955DE07 for <[e-mail]>; Mon, 23 Sep 2002 13:59:35 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8NHxV168383; Mon, 23 Sep 2002 13:59:31 -0400 (EDT) (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 g8NHxLG68348; Mon, 23 Sep 2002 13:59:21 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8NHxLc14640; Mon, 23 Sep 2002 13:59:21 -0400 (EDT)
Date: Mon, 23 Sep 2002 13:59:21 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail], Alex Zinin <[e-mail]>
Subject: Re: Working Group last call
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 Sun, Sep 22, 2002 at 06:05:54PM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Sun, Sep 22, 2002 at 06:05:54PM -0700, Yakov Rekhter wrote:
> Folks,
> 
> Just to remind you the it ends tomorrow (see below).

Just got my comments in. [mea maxima culpa]

Might I suggest that considering this last call might be one step
premature without seeing the updated text?

> 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 NAA03014 for <[e-mail]>; Mon, 23 Sep 2002 13:57:27 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9F61E91294; Mon, 23 Sep 2002 13:56:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6EDF591295; Mon, 23 Sep 2002 13:56:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6553C91294 for <[e-mail]>; Mon, 23 Sep 2002 13:56:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4C2945DED8; Mon, 23 Sep 2002 13:56:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 90A2C5DE07 for <[e-mail]>; Mon, 23 Sep 2002 13:56:57 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8NHuta68255; Mon, 23 Sep 2002 13:56:56 -0400 (EDT) (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 g8NHupG68240; Mon, 23 Sep 2002 13:56:51 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8NHup714612; Mon, 23 Sep 2002 13:56:51 -0400 (EDT)
Date: Mon, 23 Sep 2002 13:56:51 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: Generial Editorial Comment
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, Sep 23, 2002 at 10:27:28AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Mon, Sep 23, 2002 at 10:27:28AM -0700, Yakov Rekhter wrote:
> Just to add to my previous e-mail, here is the modified paragraph:
[...]

>    that a consistent view of the routes exterior to the AS is
>    provided by having all BGP speakers within the AS maintain direct
>    IBGP with each other.

"direct IBGP" slightly implies that the routers are directly connected
to each other - i.e. on the same link.

I'd suggest "maintain IBGP connections/sessions"


-- 
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 NAA02917 for <[e-mail]>; Mon, 23 Sep 2002 13:54:24 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 79EF591291; Mon, 23 Sep 2002 13:54:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D05091294; Mon, 23 Sep 2002 13:54:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C5E3491291 for <[e-mail]>; Mon, 23 Sep 2002 13:53:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A77A55DED8; Mon, 23 Sep 2002 13:53:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id AE5435DE07 for <[e-mail]>; Mon, 23 Sep 2002 13:53:57 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8NHrtl68108; Mon, 23 Sep 2002 13:53:55 -0400 (EDT) (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 g8NHrqG68101; Mon, 23 Sep 2002 13:53:52 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8NHrqD14577; Mon, 23 Sep 2002 13:53:52 -0400 (EDT)
Date: Mon, 23 Sep 2002 13:53:52 -0400
From: Jeffrey Haas <[e-mail]>
To: Susan Hares <[e-mail]>, [e-mail]
Subject: FSM word comments
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Sep 12, 2002 at 03:29:31PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Sue,

In addition to the comments about wording consistancy, capitalization
consistancy is also needed throughout the document.

>  Event5: Automatic start with passive Transport establishment
>  Event6: Automatic start with bgp_stop_flap option set

For completeness, shouldn't there also be a 
"Automatic start with passive transport and bgp_stop_flap_on"?
If not, Event6 should also be flagged to be the event that takes
place with either passive enabled or disabled.

I would also suggest altering the wording from "The passive flag
indicates that the peer will lissten prior to establishing a
connection", which implies to me that we listen and *then*
establish the connection.  What is actually meant here is that
the FSM instance doesn't initiate a transport connection but
simply listens for an incoming one.

Note that other people were commenting on:
>  Event8:  idle Hold timer expires 

which still occurs in this document.

Also:

>   If a persistent BGP peer oscillation damping function is 
>   enabled, two additional events may occur within Idle state:  
>       -	Automatic start with bgp_stop_flap set [Event6],
>       -	Idle Hold Timer expired [Event 8].

Please add:
> Connect State:
> 
>   In this state, BGP is waiting for the transport protocol 
>   connection to be completed.
> 
>   If the transport 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: 
>      -	clears the ConnectRetry timer, 
>      -	set the BGP Open Delay timer to the initial 

       - Stays in the connect state

This is a DFA, after all.

> Active State:
[...]

>  A manual stop event[Event2], the local system:
>         - Sets the administrative down in the MIB reason code,
> 	- Sends a notification with a Cease,

We can't send a notification - there is no transport connection

> 	- If any BGP routes exist, delete the routes

There are no routes

> 	- release all BGP resources, 
> 	- drops the Transport connection, 

etc.

>  In response to any other event (Events 7-8, 10-11,18, 20-
>  27), the local system:
>         - stores the MIB information to indicate appropriate 
>           error [FSM for Events 7-8, 10-11, 18, 20-27]
>         - reset the connect retry timer (sets to zero),
>         - release all BGP resources, 
> 	- drops the transport connection, 

ditto.

> Open Sent:
>  If the BGP message header checking [Event20] or OPEN message
>  check detects an error (see Section 6.2)[Event21], the local system:
>        - sends a NOTIFICATION message with appropriate error 
>          code, 
>        - reset the connect retry timer (sets to zero),
>        - if there are any routes associated with the BGP session,
> 	 delete these routes
>        - release all BGP resources,
>        - drop the transport session 
>        - increments the ConnectRetryCnt by 1, 
>        - bgp peer oscillation damping process,  
>        [Actions I, J in FSM table, depending on error],
>        - and goes to the Idle state.
> 
>  Collision detection mechanisms (section 6.8) need to be 
>  applied when a valid BGP Open is received [Event 18 or 
>  Event 19].  Please refer to section 6.8 for the details of 
>  the comparison. An administrative collision detect is when 
>  BGP implementation determines my means outside the scope of 

by means

>   If a NOTIFICATION message is received with a version 
>   error[Event23], Notification message without version number 
>   [Event 24], the local system: 

Something's not right about the English here - is this "or Notification
message without version number"?

>        - resets the connect retry timer (sets to zero)
>        - drops the Transport connection,
>        - releases all BGP resources, 
>        - increments the ConnectRetryCnt by 1
>        - process any BGP peer oscillation damping,
> 	[Action Y]  
>        - and sets the state to Idle.
> 
> 
>  The Start events [Event1, 3-6] are ignored in the OpenSent 
>  state.
> 
>   If a manual stop event [Event 2] is issued in Open sent 
>  state, the local system:
> 	- Sets administrative down reason in MIB reason,
> 	- sends the Notification with a cease,
> 	- if BGP routes exists, delete the routes,

We should have no routes in this state.

> 	- Release all BGP resources, 
> 	- Drops the Transport connection, 
> 	- set ConnectRetryCnt to zero, 
> 	- resets the Connect Retry timer (set to zero),
> 	[Action S in the FSM table], and
> 	- transitions to the Idle state.
> 
>   If an automatic stop event [Event 7] is issued in Open sent 
>   state, the local system:
> 	- Sets administrative down reason in MIB reason,
> 	- sends the Notification with a cease,
> 	- if any routes are associated with te BGP session,
> 	  delete the routes, 

ditto.

> Open Confirm State
> 	- if any BGP routes, dete the routes

We have no routes to "dete". :-)

>         - releases all BGP resources, 
> 	- drop the transport connection, 
>         - sets the ConnectRetryCnt to zero
>         - sets the connect retry timer to zero
>         [Action S in the FSM table]
>         - transitions to Idle state.
> 
>  In response to the Automatic stop event initiated by the 
>  system[event 7], the local system:
>         - sets the MIB entry for this peer to administratively 
>           down, 
>         - sends the NOTIFICATION message with Cease,
> 	- connect retry timer reset (set to zero)
> 	- If any BGP routes exist, delete the routes,

No routes here either.

>  If a TCP connection is attempted to an invalid port [Event 
>  14], the local system will ignore the second connection 
>  attempt.  

Since we're talking about transport events at a deep level
(which I don't necessarily agree with in this case), the local
system needs to do the appropriate thing to reject the incoming
connection.

>  If an OPEN message is received, all fields are check for 

are checked

>  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:
>         - sets the Call Collision cease in the MIB reason 
>          code,
>         - sends a Notification with a Cease 
>         - resets the Connect timer (set to zero),
> 	- releases all BGP resources,
> 	- Drops the TCP connection (send TCP FIN),

Again, the dangers of talking about TCP events here.
You now have to worry about FIN+ACK, etc.  Lets not talk about this.

>  If during the processing of another Open message, the BGP 
>  implementation determines my means outside the scope of 

by means

> Established State:
>  If the local system receives an UPDATE message, and the 
>  Update message error handling procedure (see Section 6.3) 
>  detects an error [Event27], the local system:

I'm somewhat concerned by the definition of "an error" in this
particular case.  There are several things that are considered
errors that may either be ignored or are recoverable.

We should probably say something along the lines of "detects an
error that must be reported via a NOTIFICATION message"

>  If the KeepAlive timer expires [Event11], the local system 
>  sends a KEEPALIVE message, it restarts its KeepAlive timer, 

and restarts
no comma

>  In response to a Transport connection succeeds [Event 15
>  or Event 16], the 2nd connection shall be tracked until
>  it sends an OPEN message.  

The language needs tightening here.  If you are tracking it
solely as an observer, thats fine.  If you have a single FSM
then the act of not tracking it is problematic - it may mean
that you've disconncted the session.

-- 
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 NAA02755 for <[e-mail]>; Mon, 23 Sep 2002 13:48:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 001949128E; Mon, 23 Sep 2002 13:48:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7B2991291; Mon, 23 Sep 2002 13:48:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B7039128E for <[e-mail]>; Mon, 23 Sep 2002 13:48:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 86D615DF05; Mon, 23 Sep 2002 13:48:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 0A6EC5DE07 for <[e-mail]>; Mon, 23 Sep 2002 13:48:06 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA23262; Mon, 23 Sep 2002 13:48:03 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA23303; Mon, 23 Sep 2002 13:48:03 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R719N4>; Mon, 23 Sep 2002 13:48:02 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Generial Editorial Comment 
Date: Mon, 23 Sep 2002 13:47:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov,

Excellent, lets go with this version.

Thanks,
Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Monday, September 23, 2002 1:27 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: Generial Editorial Comment 
> 
> 
> Ben,
> 
> [clipped...]
> 
> > > > Overall paragraph sounds good to me.
> > > > 
> > > > Except one sentence does'nt sound right.
> > > > 
> > > > "Alternately the IGP can pass BGP information among routers 
> > > within an AS,
> > > >  taking care not to lose BGP attributes". 
> > > > 
> > > >  Is it possible for IGP protocols (OSPF/ISIS) to carry such 
> > > BGP attributes
> > > > as  "AS PATH", in their link state packets?
> > > 
> > > It is certainly possible, at least in *theory*, to define new 
> > > TLVs to carry
> > > BGP attributes in OSPF/ISIS. Whether doing this makes sense 
> > > in *practice*
> > > is a separate issue. I think it would be fair to say that 
> we've yet to
> > > see any empirical evidences that doing this would be any 
> > > better than using 
> > > IBGP. And it is certainly true that as of today neither 
> ISIS nor OSPF
> > > supports this capability.
> > > 
> > > So, with this in mind I think we should either (a) delete 
> > > this sentence
> > > altogether, or (b) replace it with the following:
> > > 
> > >   Alternately, at least in principle, the IGP (with appropriate
> > >   extensions) can pass BGP information among routers within an AS,
> > >   taking care not to lose BGP attributes. At the time of 
> this writing
> > >   none of the IGPs have this capability. Whether doing this would
> > >   offer any practical benefits over using IBGP is outside 
> the scope
> > >   of this document.
> > > 
> > > Yakov.
> > > 
> > 
> > I thought inter-working with other protocols such as IGP 
> (OSPF/ISIS) is
> > outside the scope of this document. Via previous discussion 
> on this list.
> 
> Just to add to my previous e-mail, here is the modified paragraph:
> 
>    If a particular AS has multiple BGP speakers and is providing
>    transit service for other ASs, then care must be taken to ensure
>    a consistent view of routing within the AS. A consistent view
>    of the interior routes of the AS is provided by the IGP used
>    within the AS. For the purpose of this document, it is assumed
>    that a consistent view of the routes exterior to the AS is
>    provided by having all BGP speakers within the AS maintain direct
>    IBGP with each other. Care must be taken to ensure that the
>    interior routers have all been updated with transit information
>    before the BGP speakers announce to other ASs that transit
>    service is being provided.
> 
> 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 NAA02112 for <[e-mail]>; Mon, 23 Sep 2002 13:28:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C56639128F; Mon, 23 Sep 2002 13:27:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96F2A91291; Mon, 23 Sep 2002 13:27:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 238D29128F for <[e-mail]>; Mon, 23 Sep 2002 13:27:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0A75C5DED8; Mon, 23 Sep 2002 13:27:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 6DC755DE07 for <[e-mail]>; Mon, 23 Sep 2002 13:27:30 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8NHRSm70940; Mon, 23 Sep 2002 10:27:28 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: Generial Editorial Comment 
In-Reply-To: Your message of "Mon, 23 Sep 2002 13:03:48 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 23 Sep 2002 10:27:28 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

[clipped...]

> > > Overall paragraph sounds good to me.
> > > 
> > > Except one sentence does'nt sound right.
> > > 
> > > "Alternately the IGP can pass BGP information among routers 
> > within an AS,
> > >  taking care not to lose BGP attributes". 
> > > 
> > >  Is it possible for IGP protocols (OSPF/ISIS) to carry such 
> > BGP attributes
> > > as  "AS PATH", in their link state packets?
> > 
> > It is certainly possible, at least in *theory*, to define new 
> > TLVs to carry
> > BGP attributes in OSPF/ISIS. Whether doing this makes sense 
> > in *practice*
> > is a separate issue. I think it would be fair to say that we've yet to
> > see any empirical evidences that doing this would be any 
> > better than using 
> > IBGP. And it is certainly true that as of today neither ISIS nor OSPF
> > supports this capability.
> > 
> > So, with this in mind I think we should either (a) delete 
> > this sentence
> > altogether, or (b) replace it with the following:
> > 
> >   Alternately, at least in principle, the IGP (with appropriate
> >   extensions) can pass BGP information among routers within an AS,
> >   taking care not to lose BGP attributes. At the time of this writing
> >   none of the IGPs have this capability. Whether doing this would
> >   offer any practical benefits over using IBGP is outside the scope
> >   of this document.
> > 
> > Yakov.
> > 
> 
> I thought inter-working with other protocols such as IGP (OSPF/ISIS) is
> outside the scope of this document. Via previous discussion on this list.

Just to add to my previous e-mail, here is the modified paragraph:

   If a particular AS has multiple BGP speakers and is providing
   transit service for other ASs, then care must be taken to ensure
   a consistent view of routing within the AS. A consistent view
   of the interior routes of the AS is provided by the IGP used
   within the AS. For the purpose of this document, it is assumed
   that a consistent view of the routes exterior to the AS is
   provided by having all BGP speakers within the AS maintain direct
   IBGP with each other. Care must be taken to ensure that the
   interior routers have all been updated with transit information
   before the BGP speakers announce to other ASs that transit
   service is being provided.

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 NAA01565 for <[e-mail]>; Mon, 23 Sep 2002 13:10:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F3BCE9128A; Mon, 23 Sep 2002 13:09:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C34A89128F; Mon, 23 Sep 2002 13:09:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 88B399128A for <[e-mail]>; Mon, 23 Sep 2002 13:09:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 721445DE93; Mon, 23 Sep 2002 13:09:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 153555DE7F for <[e-mail]>; Mon, 23 Sep 2002 13:09:38 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8NH9Ym69394; Mon, 23 Sep 2002 10:09:34 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Manav Bhatia'" <[e-mail]>, [e-mail]
Subject: Re: Generial Editorial Comment 
In-Reply-To: Your message of "Mon, 23 Sep 2002 13:03:48 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 23 Sep 2002 10:09:34 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

[clipped...]

> > > Overall paragraph sounds good to me.
> > > 
> > > Except one sentence does'nt sound right.
> > > 
> > > "Alternately the IGP can pass BGP information among routers 
> > within an AS,
> > >  taking care not to lose BGP attributes". 
> > > 
> > >  Is it possible for IGP protocols (OSPF/ISIS) to carry such 
> > BGP attributes
> > > as  "AS PATH", in their link state packets?
> > 
> > It is certainly possible, at least in *theory*, to define new 
> > TLVs to carry
> > BGP attributes in OSPF/ISIS. Whether doing this makes sense 
> > in *practice*
> > is a separate issue. I think it would be fair to say that we've yet to
> > see any empirical evidences that doing this would be any 
> > better than using 
> > IBGP. And it is certainly true that as of today neither ISIS nor OSPF
> > supports this capability.
> > 
> > So, with this in mind I think we should either (a) delete 
> > this sentence
> > altogether, or (b) replace it with the following:
> > 
> >   Alternately, at least in principle, the IGP (with appropriate
> >   extensions) can pass BGP information among routers within an AS,
> >   taking care not to lose BGP attributes. At the time of this writing
> >   none of the IGPs have this capability. Whether doing this would
> >   offer any practical benefits over using IBGP is outside the scope
> >   of this document.
> > 
> > Yakov.
> > 
> 
> I thought inter-working with other protocols such as IGP (OSPF/ISIS) is
> outside the scope of this document. Via previous discussion on this list.

That is correct. And with this in mind, let's just delete the sentence.

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 NAA01500 for <[e-mail]>; Mon, 23 Sep 2002 13:07:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 04E579129C; Mon, 23 Sep 2002 13:05:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5911691294; Mon, 23 Sep 2002 13:04:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3452591295 for <[e-mail]>; Mon, 23 Sep 2002 13:03:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 185175DE7F; Mon, 23 Sep 2002 13:03:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 96CC65DDDB for <[e-mail]>; Mon, 23 Sep 2002 13:03:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA20076; Mon, 23 Sep 2002 13:03:50 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA12200; Mon, 23 Sep 2002 13:03:51 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7150D>; Mon, 23 Sep 2002 13:03:50 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Manav Bhatia'" <[e-mail]>, [e-mail]
Subject: RE: Generial Editorial Comment 
Date: Mon, 23 Sep 2002 13:03:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov,

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Monday, September 23, 2002 1:00 PM
> To: Abarbanel, Benjamin
> Cc: 'Manav Bhatia'; [e-mail]
> Subject: Re: Generial Editorial Comment 
> 
> 
> Ben,
> 
> > > Ben,
> > > 
> > > > IBGP by itself in most text implies the internal BGP 
> > > protocol, same applies
> > > > to EBGP. Therefore adding the word peer to it completes 
> the intended
> > > > meaning.
> > > > 
> > > > on p. 4 "taking care not to lose BGP attributes that will 
> > > be needed by EBGP
> > > >          speakers ..."
> > > > 
> > > > on p. 4 "Care must be taken to ensure that the interior routers
> > > >          have all been updated with transit information 
> > > before the EBGP
> > > >          speakers announce ..."
> > > > 
> > > > on p. 4 "... BGP speakers within the AS maintain direct 
> > > IBGP connections
> > > > ..."
> > > > 
> > > > on p. 4 "... it is assumed that BGP information is passed 
> > > within an AS
> > > >          using IBGP." 
> > > 
> > > Here is the replacement text:
> > > 
> > >            A consistent view of the routes exterior to 
> the AS can be
> > >    provided by having all BGP speakers within the AS 
> maintain direct 
> > >    IBGP with each other. Alternately the IGP can pass BGP 
> information
> > >    among routers within an AS, taking care not to lose 
> BGP attributes 
> > >    that will be needed by BGP speakers for advertisements 
> to external
> > >    peers if transit connectivity is being provided. For 
> the purpose
> > >    of this document, it is assumed that BGP information is passed
> > >    within an AS using IBGP. Care must be taken to ensure that the
> > >    interior routers have all been updated with transit information
> > >    before the BGP speakers announce to other ASs that 
> transit service
> > >    is being provided.
> > > 
> > > Yakov.
> > >
> > 
> > Overall paragraph sounds good to me.
> > 
> > Except one sentence does'nt sound right.
> > 
> > "Alternately the IGP can pass BGP information among routers 
> within an AS,
> >  taking care not to lose BGP attributes". 
> > 
> >  Is it possible for IGP protocols (OSPF/ISIS) to carry such 
> BGP attributes
> > as  "AS PATH", in their link state packets?
> 
> It is certainly possible, at least in *theory*, to define new 
> TLVs to carry
> BGP attributes in OSPF/ISIS. Whether doing this makes sense 
> in *practice*
> is a separate issue. I think it would be fair to say that we've yet to
> see any empirical evidences that doing this would be any 
> better than using 
> IBGP. And it is certainly true that as of today neither ISIS nor OSPF
> supports this capability.
> 
> So, with this in mind I think we should either (a) delete 
> this sentence
> altogether, or (b) replace it with the following:
> 
>   Alternately, at least in principle, the IGP (with appropriate
>   extensions) can pass BGP information among routers within an AS,
>   taking care not to lose BGP attributes. At the time of this writing
>   none of the IGPs have this capability. Whether doing this would
>   offer any practical benefits over using IBGP is outside the scope
>   of this document.
> 
> Yakov.
> 

I thought inter-working with other protocols such as IGP (OSPF/ISIS) is
outside the scope of this document. Via previous discussion on this list.

Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA01475 for <[e-mail]>; Mon, 23 Sep 2002 13:06:54 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 704DE91290; Mon, 23 Sep 2002 13:01:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BEDA9128A; Mon, 23 Sep 2002 13:00:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3748E91290 for <[e-mail]>; Mon, 23 Sep 2002 13:00:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D80395DE74; Mon, 23 Sep 2002 13:00:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id F0B1C5DDDB for <[e-mail]>; Mon, 23 Sep 2002 13:00:12 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8NH09m68531; Mon, 23 Sep 2002 10:00:09 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Manav Bhatia'" <[e-mail]>, [e-mail]
Subject: Re: Generial Editorial Comment 
In-Reply-To: Your message of "Mon, 23 Sep 2002 12:47:30 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 23 Sep 2002 10:00:09 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> > Ben,
> > 
> > > IBGP by itself in most text implies the internal BGP 
> > protocol, same applies
> > > to EBGP. Therefore adding the word peer to it completes the intended
> > > meaning.
> > > 
> > > on p. 4 "taking care not to lose BGP attributes that will 
> > be needed by EBGP
> > >          speakers ..."
> > > 
> > > on p. 4 "Care must be taken to ensure that the interior routers
> > >          have all been updated with transit information 
> > before the EBGP
> > >          speakers announce ..."
> > > 
> > > on p. 4 "... BGP speakers within the AS maintain direct 
> > IBGP connections
> > > ..."
> > > 
> > > on p. 4 "... it is assumed that BGP information is passed 
> > within an AS
> > >          using IBGP." 
> > 
> > Here is the replacement text:
> > 
> >            A consistent view of the routes exterior to the AS can be
> >    provided by having all BGP speakers within the AS maintain direct 
> >    IBGP with each other. Alternately the IGP can pass BGP information
> >    among routers within an AS, taking care not to lose BGP attributes 
> >    that will be needed by BGP speakers for advertisements to external
> >    peers if transit connectivity is being provided. For the purpose
> >    of this document, it is assumed that BGP information is passed
> >    within an AS using IBGP. Care must be taken to ensure that the
> >    interior routers have all been updated with transit information
> >    before the BGP speakers announce to other ASs that transit service
> >    is being provided.
> > 
> > Yakov.
> >
> 
> Overall paragraph sounds good to me.
> 
> Except one sentence does'nt sound right.
> 
> "Alternately the IGP can pass BGP information among routers within an AS,
>  taking care not to lose BGP attributes". 
> 
>  Is it possible for IGP protocols (OSPF/ISIS) to carry such BGP attributes
> as  "AS PATH", in their link state packets?

It is certainly possible, at least in *theory*, to define new TLVs to carry
BGP attributes in OSPF/ISIS. Whether doing this makes sense in *practice*
is a separate issue. I think it would be fair to say that we've yet to
see any empirical evidences that doing this would be any better than using 
IBGP. And it is certainly true that as of today neither ISIS nor OSPF
supports this capability.

So, with this in mind I think we should either (a) delete this sentence
altogether, or (b) replace it with the following:

  Alternately, at least in principle, the IGP (with appropriate
  extensions) can pass BGP information among routers within an AS,
  taking care not to lose BGP attributes. At the time of this writing
  none of the IGPs have this capability. Whether doing this would
  offer any practical benefits over using IBGP is outside the scope
  of this 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 MAA00876 for <[e-mail]>; Mon, 23 Sep 2002 12:48:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2687F91238; Mon, 23 Sep 2002 12:47:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E463591289; Mon, 23 Sep 2002 12:47:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E05A691238 for <[e-mail]>; Mon, 23 Sep 2002 12:47:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CEE435DF40; Mon, 23 Sep 2002 12:47:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 583F25DDDB for <[e-mail]>; Mon, 23 Sep 2002 12:47:35 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA18974; Mon, 23 Sep 2002 12:47:32 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA08201; Mon, 23 Sep 2002 12:47:34 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R71ZZ2>; Mon, 23 Sep 2002 12:47:33 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Manav Bhatia'" <[e-mail]>, [e-mail]
Subject: RE: Generial Editorial Comment 
Date: Mon, 23 Sep 2002 12:47:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov,

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Monday, September 23, 2002 12:30 PM
> To: Abarbanel, Benjamin
> Cc: 'Manav Bhatia'; [e-mail]
> Subject: Re: Generial Editorial Comment 
> 
> 
> Ben,
> 
> > IBGP by itself in most text implies the internal BGP 
> protocol, same applies
> > to EBGP. Therefore adding the word peer to it completes the intended
> > meaning.
> > 
> > on p. 4 "taking care not to lose BGP attributes that will 
> be needed by EBGP
> >          speakers ..."
> > 
> > on p. 4 "Care must be taken to ensure that the interior routers
> >          have all been updated with transit information 
> before the EBGP
> >          speakers announce ..."
> > 
> > on p. 4 "... BGP speakers within the AS maintain direct 
> IBGP connections
> > ..."
> > 
> > on p. 4 "... it is assumed that BGP information is passed 
> within an AS
> >          using IBGP." 
> 
> Here is the replacement text:
> 
>            A consistent view of the routes exterior to the AS can be
>    provided by having all BGP speakers within the AS maintain direct 
>    IBGP with each other. Alternately the IGP can pass BGP information
>    among routers within an AS, taking care not to lose BGP attributes 
>    that will be needed by BGP speakers for advertisements to external
>    peers if transit connectivity is being provided. For the purpose
>    of this document, it is assumed that BGP information is passed
>    within an AS using IBGP. Care must be taken to ensure that the
>    interior routers have all been updated with transit information
>    before the BGP speakers announce to other ASs that transit service
>    is being provided.
> 
> Yakov.
>

Overall paragraph sounds good to me.

Except one sentence does'nt sound right.

"Alternately the IGP can pass BGP information among routers within an AS,
 taking care not to lose BGP attributes". 

 Is it possible for IGP protocols (OSPF/ISIS) to carry such BGP attributes
as  
 "AS PATH", in their link state packets?

Ben


Thanks,
Ben 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA00481 for <[e-mail]>; Mon, 23 Sep 2002 12:35:24 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0785A91288; Mon, 23 Sep 2002 12:35:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C92FC91289; Mon, 23 Sep 2002 12:35:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9ED6291288 for <[e-mail]>; Mon, 23 Sep 2002 12:35:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8D0535DE24; Mon, 23 Sep 2002 12:35:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 320D95DDF1 for <[e-mail]>; Mon, 23 Sep 2002 12:35:19 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8NGZFm66551; Mon, 23 Sep 2002 09:35:15 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Manav Bhatia <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: Re: Generial Editorial Comment 
In-Reply-To: Your message of "Mon, 23 Sep 2002 20:01:28 +0530." <080401c2630d$e8798d40$[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 23 Sep 2002 09:35:14 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Manav,

> | > IBGP stands for "BGP connection between internal peers". Therefore
> | > the term "IBGP Peer" would mean "BGP connection between internal
> | > peers peer".  That doesn't seem appropriate.
> | >
> | If you are a BGP AS border router, you have an (internal) IBGP peer and
> an
> | (external) EBGP peer. Where is the confusion?
> 
> Refer to Section 3 - Summary of operations which clearly states that " .. a
> peer in a different AS is referred to as an external peer, while a peer in
> the same AS may be described as an internal peer. Internal BGP and external
> BGP are commonly abbreviated IBGP and EBGP"

Correct. The terms "IBGP" and "EBGP" refer to *protocols*. On the
other hand, the terms "internal peer" and "external peer" refer to peers. 
The protocol used with an internal peer is IBGP, the protocol used with
an external peer is EBGP.

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 MAA00371 for <[e-mail]>; Mon, 23 Sep 2002 12:31:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2193C91286; Mon, 23 Sep 2002 12:30:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E53BA91287; Mon, 23 Sep 2002 12:30:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AEFEF91286 for <[e-mail]>; Mon, 23 Sep 2002 12:30:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 54E5D5DDEE; Mon, 23 Sep 2002 12:30:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 5B9375DDF1 for <[e-mail]>; Mon, 23 Sep 2002 12:30:15 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8NGUBm66186; Mon, 23 Sep 2002 09:30:11 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Manav Bhatia'" <[e-mail]>, [e-mail]
Subject: Re: Generial Editorial Comment 
In-Reply-To: Your message of "Mon, 23 Sep 2002 10:44:37 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 23 Sep 2002 09:30:11 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> IBGP by itself in most text implies the internal BGP protocol, same applies
> to EBGP. Therefore adding the word peer to it completes the intended
> meaning.
> 
> on p. 4 "taking care not to lose BGP attributes that will be needed by EBGP
>          speakers ..."
> 
> on p. 4 "Care must be taken to ensure that the interior routers
>          have all been updated with transit information before the EBGP
>          speakers announce ..."
> 
> on p. 4 "... BGP speakers within the AS maintain direct IBGP connections
> ..."
> 
> on p. 4 "... it is assumed that BGP information is passed within an AS
>          using IBGP." 

Here is the replacement text:

           A consistent view of the routes exterior to the AS can be
   provided by having all BGP speakers within the AS maintain direct 
   IBGP with each other. Alternately the IGP can pass BGP information
   among routers within an AS, taking care not to lose BGP attributes 
   that will be needed by BGP speakers for advertisements to external
   peers if transit connectivity is being provided. For the purpose
   of this document, it is assumed that BGP information is passed
   within an AS using IBGP. Care must be taken to ensure that the
   interior routers have all been updated with transit information
   before the BGP speakers announce to other ASs that transit service
   is being provided.

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 KAA26981 for <[e-mail]>; Mon, 23 Sep 2002 10:47:01 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2FD5691283; Mon, 23 Sep 2002 10:46:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F016091284; Mon, 23 Sep 2002 10:46:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F1C9A91283 for <[e-mail]>; Mon, 23 Sep 2002 10:46:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8048F5E009; Mon, 23 Sep 2002 10:46:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 9446C5E008 for <[e-mail]>; Mon, 23 Sep 2002 10:46:02 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10414; Mon, 23 Sep 2002 10:46:00 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10609; Mon, 23 Sep 2002 10:46:01 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R71R01>; Mon, 23 Sep 2002 10:46:00 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Mareline Sheldon'" <[e-mail]>, Manav Bhatia <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Generial Editorial Comment
Date: Mon, 23 Sep 2002 10:45:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Correct.  

LOL,
Ben

> -----Original Message-----
> From: Mareline Sheldon [mailto:[e-mail]]
> Sent: Monday, September 23, 2002 10:41 AM
> To: Manav Bhatia; Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: Generial Editorial Comment
> 
> 
> Manay,
> I guess what Ben wanted to state was that an IBGP peer makes 
> more sense than an internal peer
> and the same for EBGP peer.
> 
> mareline s.
> 
> --- Manav Bhatia <[e-mail]> wrote:
> > Ben,
> > 
> > | > IBGP stands for "BGP connection between internal 
> peers". Therefore
> > | > the term "IBGP Peer" would mean "BGP connection between internal
> > | > peers peer".  That doesn't seem appropriate.
> > | >
> > | If you are a BGP AS border router, you have an (internal) 
> IBGP peer and
> > an
> > | (external) EBGP peer. Where is the confusion?
> > 
> > Refer to Section 3 - Summary of operations which clearly 
> states that " .. a
> > peer in a different AS is referred to as an external peer, 
> while a peer in
> > the same AS may be described as an internal peer. Internal 
> BGP and external
> > BGP are commonly abbreviated IBGP and EBGP"
> > 
> > Regards,
> > Manav
> > 
> > 
> > 
> > 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.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 KAA26934 for <[e-mail]>; Mon, 23 Sep 2002 10:45:25 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8ACB991281; Mon, 23 Sep 2002 10:44:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5849E91283; Mon, 23 Sep 2002 10:44:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 68D7C91281 for <[e-mail]>; Mon, 23 Sep 2002 10:44:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 526EB5E007; Mon, 23 Sep 2002 10:44:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id D27B55DE89 for <[e-mail]>; Mon, 23 Sep 2002 10:44:42 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10298; Mon, 23 Sep 2002 10:44:39 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10166; Mon, 23 Sep 2002 10:44:40 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R71R66>; Mon, 23 Sep 2002 10:44:39 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Manav Bhatia'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Generial Editorial Comment
Date: Mon, 23 Sep 2002 10:44:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

IBGP by itself in most text implies the internal BGP protocol, same applies
to EBGP. Therefore adding the word peer to it completes the intended
meaning.

on p. 4 "taking care not to lose BGP attributes that will be needed by EBGP

         speakers ..."

on p. 4 "Care must be taken to ensure that the interior routers
         have all been updated with transit information before the EBGP
         speakers announce ..."

on p. 4 "... BGP speakers within the AS maintain direct IBGP connections
..."

on p. 4 "... it is assumed that BGP information is passed within an AS
         using IBGP." 

on p. 20 " The mandatory category refers to an attribute which must be
present
           in both IBGP and EBGP exchanges ..."

Ben

> From: Manav Bhatia [mailto:[e-mail]]
> Sent: Monday, September 23, 2002 10:31 AM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: Generial Editorial Comment
> 
> 
> Ben,
> 
> | > IBGP stands for "BGP connection between internal peers". Therefore
> | > the term "IBGP Peer" would mean "BGP connection between internal
> | > peers peer".  That doesn't seem appropriate.
> | >
> | If you are a BGP AS border router, you have an (internal) 
> IBGP peer and
> an
> | (external) EBGP peer. Where is the confusion?
> 
> Refer to Section 3 - Summary of operations which clearly 
> states that " .. a
> peer in a different AS is referred to as an external peer, 
> while a peer in
> the same AS may be described as an internal peer. Internal 
> BGP and external
> BGP are commonly abbreviated IBGP and EBGP"
> 
> Regards,
> Manav
> 
> 
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA26828 for <[e-mail]>; Mon, 23 Sep 2002 10:41:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 27B0E91280; Mon, 23 Sep 2002 10:41:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E33B891281; Mon, 23 Sep 2002 10:41:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DB72891280 for <[e-mail]>; Mon, 23 Sep 2002 10:41:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C604C5E007; Mon, 23 Sep 2002 10:41:13 -0400 (EDT)
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 440C95DE89 for <[e-mail]>; Mon, 23 Sep 2002 10:41:13 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [203.200.20.226] by web20307.mail.yahoo.com via HTTP; Mon, 23 Sep 2002 07:41:09 PDT
Date: Mon, 23 Sep 2002 07:41:09 -0700 (PDT)
From: Mareline Sheldon <[e-mail]>
Subject: Re: Generial Editorial Comment
To: Manav Bhatia <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
In-Reply-To: <080401c2630d$e8798d40$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Manay,
I guess what Ben wanted to state was that an IBGP peer makes more sense than an internal peer
and the same for EBGP peer.

mareline s.

--- Manav Bhatia <[e-mail]> wrote:
> Ben,
> 
> | > IBGP stands for "BGP connection between internal peers". Therefore
> | > the term "IBGP Peer" would mean "BGP connection between internal
> | > peers peer".  That doesn't seem appropriate.
> | >
> | If you are a BGP AS border router, you have an (internal) IBGP peer and
> an
> | (external) EBGP peer. Where is the confusion?
> 
> Refer to Section 3 - Summary of operations which clearly states that " .. a
> peer in a different AS is referred to as an external peer, while a peer in
> the same AS may be described as an internal peer. Internal BGP and external
> BGP are commonly abbreviated IBGP and EBGP"
> 
> Regards,
> Manav
> 
> 
> 
> 


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.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 KAA26526 for <[e-mail]>; Mon, 23 Sep 2002 10:33:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 572909127F; Mon, 23 Sep 2002 10:32:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 20C7491280; Mon, 23 Sep 2002 10:32:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D412E9127F for <[e-mail]>; Mon, 23 Sep 2002 10:32:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E8E955E005; Mon, 23 Sep 2002 10:32:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from realname (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 79F995E006 for <[e-mail]>; Mon, 23 Sep 2002 10:32:04 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug  5 2002)) id <[e-mail]> for [e-mail]; Mon, 23 Sep 2002 23:36:57 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug  5 2002)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 23 Sep 2002 23:36:57 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 23 Sep 2002 23:37:27 +0900 (KST)
Date: Mon, 23 Sep 2002 20:01:28 +0530
From: Manav Bhatia <[e-mail]>
Subject: Re: Generial Editorial Comment
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <080401c2630d$e8798d40$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

| > IBGP stands for "BGP connection between internal peers". Therefore
| > the term "IBGP Peer" would mean "BGP connection between internal
| > peers peer".  That doesn't seem appropriate.
| >
| If you are a BGP AS border router, you have an (internal) IBGP peer and
an
| (external) EBGP peer. Where is the confusion?

Refer to Section 3 - Summary of operations which clearly states that " .. a
peer in a different AS is referred to as an external peer, while a peer in
the same AS may be described as an internal peer. Internal BGP and external
BGP are commonly abbreviated IBGP and EBGP"

Regards,
Manav






Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA25651 for <[e-mail]>; Mon, 23 Sep 2002 10:11:36 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A728F9127C; Mon, 23 Sep 2002 10:11:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6EBDA9127D; Mon, 23 Sep 2002 10:11:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D1039127C for <[e-mail]>; Mon, 23 Sep 2002 10:11:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6A44C5DF3C; Mon, 23 Sep 2002 10:11:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id E48625DE89 for <[e-mail]>; Mon, 23 Sep 2002 10:11:13 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA06839; Mon, 23 Sep 2002 10:11:11 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29629; Mon, 23 Sep 2002 10:11:12 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R713YZ>; Mon, 23 Sep 2002 10:11:11 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Generial Editorial Comment 
Date: Mon, 23 Sep 2002 10:11:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov,

> 
> > 2. Change Internal peer to IBGP Peer.
> 
> IBGP stands for "BGP connection between internal peers". Therefore
> the term "IBGP Peer" would mean "BGP connection between internal
> peers peer".  That doesn't seem appropriate. 
> 
If you are a BGP AS border router, you have an (internal) IBGP peer and an
(external) EBGP peer. Where is the confusion?

 
Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA23172 for <[e-mail]>; Mon, 23 Sep 2002 08:56:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5BB439126E; Mon, 23 Sep 2002 08:56:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F78B91277; Mon, 23 Sep 2002 08:56:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC6D19126E for <[e-mail]>; Mon, 23 Sep 2002 08:56:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id AFCB25DF6D; Mon, 23 Sep 2002 08:56:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id A3B715DF00 for <[e-mail]>; Mon, 23 Sep 2002 08:56:16 -0400 (EDT)
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 IAA70985; Mon, 23 Sep 2002 08:55:22 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Mareline Sheldon <[e-mail]>
Cc: [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: Multiple BGP Process 
In-reply-to: Your message of "Mon, 23 Sep 2002 01:40:28 PDT." <[e-mail]> 
Date: Mon, 23 Sep 2002 08:55:21 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Mareline Sheld
on writes:
> Curtis,
> > 
> > In cases where it is useful to have one router appear to be in two
> > different AS, for example doing IBGP in both, two BGP processes are
> > run rather than buying two routers and a link between them.
> > 
> Not necessarily .. you dont need to run two BGP processes to make one router 
> appear to be in
> two different AS as IBGP in both. You can have the same instance/process runn
> ing and still do
> that using different views.
> 
> regards,
> marelines s.


Views, gated tasks, threads, processes ... we're talking
implementation details here.  Gated is proof that you can run all of
your protocols without the help of threads, or processes and without
the help of the scheduler provided by the OS.

The point is the the two instances of BGP, however they are
implemented and whatever you'd like to call them, have different
loc-RIBs and it is desirable to provide the ability to specify policy
to export or aggregate between them.  There is an issue of which
loc-RIB (or what combination of them) gets installed in the FIB or
whether there are also two FIBs with the appropriate one installed on
interfaces facing each AS.

We're well outside the scope of the BGP spec.

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 EAA14951 for <[e-mail]>; Mon, 23 Sep 2002 04:40:58 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 62C8791265; Mon, 23 Sep 2002 04:40:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C5F491272; Mon, 23 Sep 2002 04:40:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1425B91265 for <[e-mail]>; Mon, 23 Sep 2002 04:40:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E73045DE41; Mon, 23 Sep 2002 04:40:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web20308.mail.yahoo.com (web20308.mail.yahoo.com [216.136.226.89]) by segue.merit.edu (Postfix) with SMTP id 6B5DD5DDB8 for <[e-mail]>; Mon, 23 Sep 2002 04:40:28 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [203.200.20.226] by web20308.mail.yahoo.com via HTTP; Mon, 23 Sep 2002 01:40:28 PDT
Date: Mon, 23 Sep 2002 01:40:28 -0700 (PDT)
From: Mareline Sheldon <[e-mail]>
Subject: Re: Multiple BGP Process 
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Curtis,
> 
> In cases where it is useful to have one router appear to be in two
> different AS, for example doing IBGP in both, two BGP processes are
> run rather than buying two routers and a link between them.
> 
Not necessarily .. you dont need to run two BGP processes to make one router appear to be in
two different AS as IBGP in both. You can have the same instance/process running and still do
that using different views.

regards,
marelines s.


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.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 VAA00113 for <[e-mail]>; Sun, 22 Sep 2002 21:10:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 18C1B91269; Sun, 22 Sep 2002 21:09:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D46F89126A; Sun, 22 Sep 2002 21:09:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8369D91269 for <[e-mail]>; Sun, 22 Sep 2002 21:09:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 608735E378; Sun, 22 Sep 2002 21:09:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id C60135DF61 for <[e-mail]>; Sun, 22 Sep 2002 21:09:40 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8N19Sm03424; Sun, 22 Sep 2002 18:09:28 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: Re: Generial Editorial Comment 
In-Reply-To: Your message of "Fri, 20 Sep 2002 15:11:55 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sun, 22 Sep 2002 18:09:28 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Alex,

> Defining terms like this in a separate section would be really nice.
> (BTW, I personally think using "BGP session" which works over a "TCP
> connection" would be closer to the terminology we're actually using
> now and would avoid possible confusions when people read terms like
> "Connection collision") It would also be great if we had descriptions
> for all data structures that are not explicitly defined (e.g., the
> current spec has no notion of a peer data structure), timers, etc.
> 
> Two other things that I think would make sense to explicitly
> define are
> 
>    - processing of incoming TCP connections (peer lookup, acceptance,
>      FSM creation, collision control,)
> 
>    - generation of events while processing BGP messages, i.e.,
>      the text describing message processing should say where
>      needed that a specific event for the BGP session should
>      be generated.

Please suggest the appropriate text.

yakov.

>  
> Thanks.
> 
> -- 
> Alex
> 
> Friday, September 20, 2002, 2:18:27 PM, Yakov Rekhter wrote:
> > Ben,
> 
> >> I have some general editorial comments.
> >> 
> >> 1. Throughout the document we have various ways of naming the BGP
> >>    peering communication. 1) BGP Session, 2) BGP Peering Session, 
> 
> > I'll replace "session" with "connection". 
> 
> >>    3) TCP Connection, 
> 
> > The spec doesn't name BGP peering communication as "TCP connection";
> > TCP connection is used to establish BGP connection. So, TCP connection
> > and BGP connection are two different things.
> 
> >>    4) BGP Connection, 
> 
> > The spec is going to use this term (see above).
> 
>>                  5) BGP Peering Connection, 
> 
> > I'll replace "BGP peering connection" with "BGP connection".
> 
> >> 6) Connection, 
> 
> > The text uses "connection" whenever it is clear from the context
> > that it refers to "BGP connection" (or "TCP connection").
> 
> >>    7) BGP Speaker Connection. 
> 
> > I'll replace "BGP Speaker Connection" with "BGP connection".
> 
> >> 
> >>    BGP router: 1) BGP Speaker, 2) speaker, 3)local speaker
> 
> > The term "speaker" is used when it is clear from the context that
> > we are talking about "BGP speaker".
> 
> >> 2. Change Internal peer to IBGP Peer.
> 
> > IBGP stands for "BGP connection between internal peers". Therefore
> > the term "IBGP Peer" would mean "BGP connection between internal
> > peers peer".  That doesn't seem appropriate. 
> 
> >> 3. Change External peer to EBGP Peer.
> 
> > Ditto.
> 
> > 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 VAA29970 for <[e-mail]>; Sun, 22 Sep 2002 21:06:16 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A746191268; Sun, 22 Sep 2002 21:05:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CBF291269; Sun, 22 Sep 2002 21:05:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3830F91268 for <[e-mail]>; Sun, 22 Sep 2002 21:05:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 132FB5E378; Sun, 22 Sep 2002 21:05:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 7D67E5DF61 for <[e-mail]>; Sun, 22 Sep 2002 21:05:55 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8N15sm03359; Sun, 22 Sep 2002 18:05:55 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: Alex Zinin <[e-mail]>
Subject: Working Group last call
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sun, 22 Sep 2002 18:05:54 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

Just to remind you the it ends tomorrow (see below).

Yakov.
------- Forwarded Message

Date:    Wed, 11 Sep 2002 09:27:45 -0700
From:    Yakov Rekhter <[e-mail]>
To:      Alex Zinin <[e-mail]>
cc:      [e-mail], [e-mail]
Subject: Re: Working Group last call 

Alex,

> Yakov,
> 
>   I'd like to ask the WG chairs to extend the comment period
>   for at least another two weeks--as I indicated in one of my
>   messages earlier, I'm hearing that people are in deadlines
>   and ask for more time to review.

The WG chairs are pleased to grant the two weeks extension (from 9/9 
to 9/23).

Please track down those people who indicated that two weeks would
not be enough. We are counting on you to get the comments from these 
people in as early as possible.

Sue & Yakov.

------- End of Forwarded Message



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA23515 for <[e-mail]>; Fri, 20 Sep 2002 18:14:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 67ED79123F; Fri, 20 Sep 2002 18:14:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24E2B912CB; Fri, 20 Sep 2002 18:14:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2C85F9123F for <[e-mail]>; Fri, 20 Sep 2002 18:14:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 128C85DF5C; Fri, 20 Sep 2002 18:14:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id DC0B75DEF4 for <[e-mail]>; Fri, 20 Sep 2002 18:14:02 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17sW2C-0003GZ-00; Fri, 20 Sep 2002 15:14:00 -0700
Date: Fri, 20 Sep 2002 15:11:55 -0700
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: Re: Generial Editorial Comment
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Defining terms like this in a separate section would be really nice.
(BTW, I personally think using "BGP session" which works over a "TCP
connection" would be closer to the terminology we're actually using
now and would avoid possible confusions when people read terms like
"Connection collision") It would also be great if we had descriptions
for all data structures that are not explicitly defined (e.g., the
current spec has no notion of a peer data structure), timers, etc.

Two other things that I think would make sense to explicitly
define are

   - processing of incoming TCP connections (peer lookup, acceptance,
     FSM creation, collision control,)

   - generation of events while processing BGP messages, i.e.,
     the text describing message processing should say where
     needed that a specific event for the BGP session should
     be generated.
 
Thanks.

-- 
Alex

Friday, September 20, 2002, 2:18:27 PM, Yakov Rekhter wrote:
> Ben,

>> I have some general editorial comments.
>> 
>> 1. Throughout the document we have various ways of naming the BGP
>>    peering communication. 1) BGP Session, 2) BGP Peering Session, 

> I'll replace "session" with "connection". 

>>    3) TCP Connection, 

> The spec doesn't name BGP peering communication as "TCP connection";
> TCP connection is used to establish BGP connection. So, TCP connection
> and BGP connection are two different things.

>>    4) BGP Connection, 

> The spec is going to use this term (see above).

>>                  5) BGP Peering Connection, 

> I'll replace "BGP peering connection" with "BGP connection".

>> 6) Connection, 

> The text uses "connection" whenever it is clear from the context
> that it refers to "BGP connection" (or "TCP connection").

>>    7) BGP Speaker Connection. 

> I'll replace "BGP Speaker Connection" with "BGP connection".

>> 
>>    BGP router: 1) BGP Speaker, 2) speaker, 3)local speaker

> The term "speaker" is used when it is clear from the context that
> we are talking about "BGP speaker".

>> 2. Change Internal peer to IBGP Peer.

> IBGP stands for "BGP connection between internal peers". Therefore
> the term "IBGP Peer" would mean "BGP connection between internal
> peers peer".  That doesn't seem appropriate. 

>> 3. Change External peer to EBGP Peer.

> Ditto.

> 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 RAA21721 for <[e-mail]>; Fri, 20 Sep 2002 17:19:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 80739912C9; Fri, 20 Sep 2002 17:18:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4DCF5912CA; Fri, 20 Sep 2002 17:18:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 13622912C9 for <[e-mail]>; Fri, 20 Sep 2002 17:18:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F18285E18B; Fri, 20 Sep 2002 17:18:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 961E85DF5C for <[e-mail]>; Fri, 20 Sep 2002 17:18:29 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8KLIRm02847; Fri, 20 Sep 2002 14:18:27 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: Generial Editorial Comment 
In-Reply-To: Your message of "Fri, 20 Sep 2002 16:18:12 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 20 Sep 2002 14:18:27 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> I have some general editorial comments.
> 
> 1. Throughout the document we have various ways of naming the BGP
>    peering communication. 1) BGP Session, 2) BGP Peering Session, 

I'll replace "session" with "connection". 

>    3) TCP Connection, 

The spec doesn't name BGP peering communication as "TCP connection";
TCP connection is used to establish BGP connection. So, TCP connection
and BGP connection are two different things.

>    4) BGP Connection, 

The spec is going to use this term (see above).

>                  5) BGP Peering Connection, 

I'll replace "BGP peering connection" with "BGP connection".

> 6) Connection, 

The text uses "connection" whenever it is clear from the context
that it refers to "BGP connection" (or "TCP connection").

>    7) BGP Speaker Connection. 

I'll replace "BGP Speaker Connection" with "BGP connection".

> 
>    BGP router: 1) BGP Speaker, 2) speaker, 3)local speaker

The term "speaker" is used when it is clear from the context that
we are talking about "BGP speaker".

> 2. Change Internal peer to IBGP Peer.

IBGP stands for "BGP connection between internal peers". Therefore
the term "IBGP Peer" would mean "BGP connection between internal
peers peer".  That doesn't seem appropriate. 

> 3. Change External peer to EBGP Peer.

Ditto.

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 QAA19804 for <[e-mail]>; Fri, 20 Sep 2002 16:18:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 377DE912C4; Fri, 20 Sep 2002 16:18:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04E8C912C6; Fri, 20 Sep 2002 16:18:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C6F2E912C4 for <[e-mail]>; Fri, 20 Sep 2002 16:18:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A71495E2CD; Fri, 20 Sep 2002 16:18:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 157EF5DE14 for <[e-mail]>; Fri, 20 Sep 2002 16:18:16 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA27664; Fri, 20 Sep 2002 16:18:13 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA00290; Fri, 20 Sep 2002 16:18:14 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7DJZL>; Fri, 20 Sep 2002 16:18:13 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: Generial Editorial Comment 
Date: Fri, 20 Sep 2002 16:18:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I have some general editorial comments.

1. Throughout the document we have various ways of naming the BGP
   peering communication. 1) BGP Session, 2) BGP Peering Session, 3) TCP   
   Connection, 4) BGP Connection, 5) BGP Peering Connection, 6) Connection, 
   7) BGP Speaker Connection. 

   BGP router: 1) BGP Speaker, 2) speaker, 3)local speaker

2. Change Internal peer to IBGP Peer.

3. Change External peer to EBGP Peer.

I know this is nits, but it maintains a clear consistency in the content.

Thanks,
Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Friday, September 20, 2002 3:39 PM
> To: Michael C. Cambria
> Cc: [e-mail]
> Subject: Re: -17 review Section 6 - BGP Error Handling. 
> 
> 
> Mike,
> 
> > Hi,
> > 
> > At the beginning of Section 6. BGP Error Handling:
> > 
> > 
> >     "When any of the conditions described here are detected, a
> >     NOTIFICATION message with the indicated Error Code, 
> Error Subcode,
> >     and Data fields is sent, and the BGP connection is closed."
> > 
> > There are several cases where the conditions described in 
> this section 
> > do not result in the BGP connection being closed.  These conditions 
> > should either state that the connection stays up.  Another 
> possibility 
> > is to remove "and the BGP connection is closed." above, and 
> for each 
> > listed connection, state what happens to the BGP connection.  This 
> > already takes place for certain conditions, but isn't done 
> consistantly.
> 
> How about replacing the above with the following:
> 
>    When any of the conditions described here are detected, a 
> NOTIFICATION
>    message with the indicated Error Code, Error Subcode, and Data
>    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 close. 
> > 
> > 
> > I tried to list what I found (which may be wrong or 
> incomplete) below:
> > 
> > 
> > 
> > "If the NEXT_HOP attribute is semantically incorrect, the 
> error should 
> > be logged, and the route should be ignored. In this case, no 
> > NOTIFICATION message should be sent."
> > 
> > * Append the connection is not closed.
> 
> Done.
> 
> > 
> > "(a) discard new address prefixes from the neighbor, or (b) 
> terminate 
> > the BGP peering with the neighbor."
> > 
> > * Append "the connection is not closed" to case (a)
> 
> added "(while maintaining BGP peering with the neighbor)" to case (a).
> 
> > 
> >     "If
> >     the autonomous system number appears in the AS path the 
> route may be
> >     stored in the Adj-RIB-In,"
> > 
> > * append and the BGP connection stays up.
> > 
> >                                 "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."
> 
> I would suggest to move this text to Section 9 (UPDATE 
> message handling),
> as receiving a route with your own AS in the AS path isn't really
> an error. It is just that usually (but not always) you can't put
> this route in your Adj-RIB-In. 
> 
> > 
> > * Q1) does the BGP connection stay up?
> 
> yes.
> 
> > * Q2) what if the router isn't configured to accept routes 
> with its own 
> > AS in the AS path?  One _may_ store the route in 
> Adj-RIB-In, but if one 
> > doesn't want to?  
> 
> So, don't store them.
> 
> > Is the BGP connection closed?  If so, what subcode?
> 
> The connection is *not* closed.
> 
> >     "If an optional attribute is recognized, then the value of this
> >     attribute is checked. If an error is detected, the attribute is
> >     discarded, and the Error Subcode is set to Optional 
> Attribute Error.
> >     The Data field contains the attribute (type, length and value)."
> > 
> > * Append and the BGP conneciton stays up after "the 
> attribute is discarded".
> 
> Since you have to close the connection, you have to discard all the
> routes received via this connection, including the route with the
> incorrect attribute. So, there is no need to say that "the attribute
> is discarded".
> 
> 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 PAA18793 for <[e-mail]>; Fri, 20 Sep 2002 15:45:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6F6E3912C5; Fri, 20 Sep 2002 15:43:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 333D5912C6; Fri, 20 Sep 2002 15:43:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2C643912C5 for <[e-mail]>; Fri, 20 Sep 2002 15:43:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 19A575E2CB; Fri, 20 Sep 2002 15:43:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id B2C185E2C8 for <[e-mail]>; Fri, 20 Sep 2002 15:43:22 -0400 (EDT)
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 PAA50984; Fri, 20 Sep 2002 15:42:39 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Natale, Jonathan'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, "'Mathew Richardson'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Proxy: comments on section 9.1.3 
In-reply-to: Your message of "Fri, 20 Sep 2002 12:27:38 EDT." <[e-mail]> 
Date: Fri, 20 Sep 2002 15:42:39 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> My only point is if a BGP route is added to the FIB (Routing Table), it does
> not
> gaurantee it is used for forwarding. There may be other protocol routes
> in the FIB for the same destination that get preference and thus cause the
> BGP route not to be used for forwarding. 
> 
> I thought we were trying to say that any time this happens the impacts to
> BGP propagating this route to outgoing peers is outside the scope of this
> documents.
> 
> Ben


Ben,

The FIB is the forwarding table (forwarding information base).  There
is one entry per destination in the FIB though in multipath the one
entry may specify split traffic over more than one next hop.

The FIB is by definition what is used for forwarding.

Curtis



> > -----Original Message-----
> > From: Natale, Jonathan [mailto:[e-mail]]
> > Sent: Friday, September 20, 2002 12:18 PM
> > To: 'Abarbanel, Benjamin'; 'Yakov Rekhter'; 'Mathew Richardson'
> > Cc: [e-mail]
> > Subject: RE: Proxy: comments on section 9.1.3 
> > 
> > 
> > Ben,
> > 
> > I like Yakov's better.  Nothing personal.
> > 
> > :-)
> > 
> > -----Original Message-----
> > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > Sent: Friday, September 20, 2002 12:16 PM
> > To: 'Yakov Rekhter'; 'Mathew Richardson'
> > Cc: [e-mail]
> > Subject: RE: Proxy: comments on section 9.1.3 
> > 
> > Yakov:
> >   I hate to sound picky, but could this improve the intended meaning?
> > 
> >   "Any local-policy which results in routes being added to an
> >    Adj-RIB-Out without also being used for forwarding, is outside the 
> >    scope of this document."
> > 
> > Ben
> > 
> > > -----Original Message-----
> > > From: Yakov Rekhter [mailto:[e-mail]]
> > > Sent: Friday, September 20, 2002 12:08 PM
> > > To: 'Mathew Richardson'
> > > Cc: [e-mail]
> > > Subject: Re: Proxy: comments on section 9.1.3 
> > > 
> > > 
> > > Matt,
> > > 
> > > > > 'Mathew Richardson' <[e-mail]> [Fri, Sep 06, 2002 
> > > at 11:16:06AM -040
> > > 0]:
> > > > 
> > > > <snip>
> > > > 
> > > > Replying to myself to correct some poor grammar:
> > > > 
> > > > >I think that case must either be disallowed, or placed 
> > outside the
> > > > >scope of the base document.  How about adding to section 9.1.3,
> > > > >at the end:
> > > > >
> > > > >  Any local-policy which results in reachability being 
> > added to an
> > > > >  Adj-RIB-Out without also being added to the local BGP speaker's
> > > > >  forwarding table, are beyond the scope of this document.
> > > > 
> > > > <snip>
> > > > 
> > > > The last line should read:
> > > > 
> > > >   forwarding table is beyond the scope of this document.
> > > 
> > > Accepted with a minor rewording (as follows):
> > > 
> > >  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.
> > > 
> > > 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 PAA18682 for <[e-mail]>; Fri, 20 Sep 2002 15:41:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B4360912C2; Fri, 20 Sep 2002 15:39:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BE74912C3; Fri, 20 Sep 2002 15:39:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 31BF5912C2 for <[e-mail]>; Fri, 20 Sep 2002 15:39:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 12F875E318; Fri, 20 Sep 2002 15:39:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 5AE835E2C8 for <[e-mail]>; Fri, 20 Sep 2002 15:39:27 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8KJdLm81047; Fri, 20 Sep 2002 12:39:21 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Michael C. Cambria" <[e-mail]>
Cc: [e-mail]
Subject: Re: -17 review Section 6 - BGP Error Handling. 
In-Reply-To: Your message of "Fri, 20 Sep 2002 14:35:27 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 20 Sep 2002 12:39:21 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Mike,

> Hi,
> 
> At the beginning of Section 6. BGP Error Handling:
> 
> 
>     "When any of the conditions described here are detected, a
>     NOTIFICATION message with the indicated Error Code, Error Subcode,
>     and Data fields is sent, and the BGP connection is closed."
> 
> There are several cases where the conditions described in this section 
> do not result in the BGP connection being closed.  These conditions 
> should either state that the connection stays up.  Another possibility 
> is to remove "and the BGP connection is closed." above, and for each 
> listed connection, state what happens to the BGP connection.  This 
> already takes place for certain conditions, but isn't done consistantly.

How about replacing the above with the following:

   When any of the conditions described here are detected, a NOTIFICATION
   message with the indicated Error Code, Error Subcode, and Data
   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 close. 
> 
> 
> I tried to list what I found (which may be wrong or incomplete) below:
> 
> 
> 
> "If the NEXT_HOP attribute is semantically incorrect, the error should 
> be logged, and the route should be ignored. In this case, no 
> NOTIFICATION message should be sent."
> 
> * Append the connection is not closed.

Done.

> 
> "(a) discard new address prefixes from the neighbor, or (b) terminate 
> the BGP peering with the neighbor."
> 
> * Append "the connection is not closed" to case (a)

added "(while maintaining BGP peering with the neighbor)" to case (a).

> 
>     "If
>     the autonomous system number appears in the AS path the route may be
>     stored in the Adj-RIB-In,"
> 
> * append and the BGP connection stays up.
> 
>                                 "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."

I would suggest to move this text to Section 9 (UPDATE message handling),
as receiving a route with your own AS in the AS path isn't really
an error. It is just that usually (but not always) you can't put
this route in your Adj-RIB-In. 

> 
> * Q1) does the BGP connection stay up?

yes.

> * Q2) what if the router isn't configured to accept routes with its own 
> AS in the AS path?  One _may_ store the route in Adj-RIB-In, but if one 
> doesn't want to?  

So, don't store them.

> Is the BGP connection closed?  If so, what subcode?

The connection is *not* closed.

>     "If an optional attribute is recognized, then the value of this
>     attribute is checked. If an error is detected, the attribute is
>     discarded, and the Error Subcode is set to Optional Attribute Error.
>     The Data field contains the attribute (type, length and value)."
> 
> * Append and the BGP conneciton stays up after "the attribute is discarded".

Since you have to close the connection, you have to discard all the
routes received via this connection, including the route with the
incorrect attribute. So, there is no need to say that "the attribute
is discarded".

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 PAA17945 for <[e-mail]>; Fri, 20 Sep 2002 15:18:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 520EC912C0; Fri, 20 Sep 2002 15:18:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 11344912C1; Fri, 20 Sep 2002 15:18:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C5260912C0 for <[e-mail]>; Fri, 20 Sep 2002 15:17:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7C8875E323; Fri, 20 Sep 2002 15:17:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 075AD5E2C8 for <[e-mail]>; Fri, 20 Sep 2002 15:17:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24211; Fri, 20 Sep 2002 15:17:40 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA20644; Fri, 20 Sep 2002 15:17:42 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7DHQZ>; Fri, 20 Sep 2002 15:17:41 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Michael C. Cambria'" <[e-mail]>, [e-mail]
Subject: RE: -17 review, Section 6.2 - must reject hold time
Date: Fri, 20 Sep 2002 15:17:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hold time set to zero is also mentioned in the definition of the Hold Timer
on
p 8.

Ben

> -----Original Message-----
> From: Michael C. Cambria [mailto:[e-mail]]
> Sent: Friday, September 20, 2002 2:56 PM
> To: [e-mail]
> Subject: Re: -17 review, Section 6.2 - must reject hold time
> 
> 
> 
> Jeff / Yakov
> 
> Understood.  I thought I read somewhere that it couldn't for external 
> peers.  I can't find it, only my note in the margin to post the (now 
> wrong) suggestion.  It could be that I mis-read KEEPALIVE 
> "may" be sent 
> as MUST and internalized it (since I always use them.)  Sorry.
> 
> Thanks,
> MikeC
> 
> 
> Yakov Rekhter wrote:
> > Mike,
> > 
> > 
> >>In Section 6.2 on OPEN message error handling:
> >>
> >>    If the Hold Time field of the OPEN message is 
> unacceptable, then the
> >>    Error Subcode MUST be set to Unacceptable Hold Time. An
> >>    implementation MUST reject Hold Time values of one or 
> two seconds.
> >>
> >>I feel that text similar to:
> >>
> >>"An implementation MUST also reject Hold Time values of 
> zero received 
> >>from a peer in a different AS" should be considered for 
> completeness.
> > 
> > 
> >>From 4.4:
> > 
> >    If the negotiated Hold Time interval is zero, then 
> periodic KEEPALIVE
> >    messages MUST NOT be sent.  
> > 
> > So, setting Hold Time to zero is perfectly valid (under certain
> > circumstances).
> > 
> > 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 PAA17806 for <[e-mail]>; Fri, 20 Sep 2002 15:13:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 86DF7912BF; Fri, 20 Sep 2002 15:13:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E558912C0; Fri, 20 Sep 2002 15:13:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D92E9912BF for <[e-mail]>; Fri, 20 Sep 2002 15:12:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B4FE25E318; Fri, 20 Sep 2002 15:12:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id 350E95E14C for <[e-mail]>; Fri, 20 Sep 2002 15:12:59 -0400 (EDT)
Received: from fid4.com (mcambria3.avayactc.com [199.93.238.136]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g8KJA4uo024227 for <[e-mail]>; Fri, 20 Sep 2002 15:10:04 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 20 Sep 2002 14:55:34 -0400
From: "Michael C. Cambria" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020819
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: -17 review, Section 6.2 - must reject hold time
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Jeff / Yakov

Understood.  I thought I read somewhere that it couldn't for external 
peers.  I can't find it, only my note in the margin to post the (now 
wrong) suggestion.  It could be that I mis-read KEEPALIVE "may" be sent 
as MUST and internalized it (since I always use them.)  Sorry.

Thanks,
MikeC


Yakov Rekhter wrote:
> Mike,
> 
> 
>>In Section 6.2 on OPEN message error handling:
>>
>>    If the Hold Time field of the OPEN message is unacceptable, then the
>>    Error Subcode MUST be set to Unacceptable Hold Time. An
>>    implementation MUST reject Hold Time values of one or two seconds.
>>
>>I feel that text similar to:
>>
>>"An implementation MUST also reject Hold Time values of zero received 
>>from a peer in a different AS" should be considered for completeness.
> 
> 
>>From 4.4:
> 
>    If the negotiated Hold Time interval is zero, then periodic KEEPALIVE
>    messages MUST NOT be sent.  
> 
> So, setting Hold Time to zero is perfectly valid (under certain
> circumstances).
> 
> 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 OAA17041 for <[e-mail]>; Fri, 20 Sep 2002 14:53:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DA962912BE; Fri, 20 Sep 2002 14:52:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC22E912BF; Fri, 20 Sep 2002 14:52:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B80C912BE for <[e-mail]>; Fri, 20 Sep 2002 14:52:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 40A225E31E; Fri, 20 Sep 2002 14:52:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id B25E05E2CB for <[e-mail]>; Fri, 20 Sep 2002 14:52:51 -0400 (EDT)
Received: from fid4.com (mcambria3.avayactc.com [199.93.238.136]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g8KInuuo024200 for <[e-mail]>; Fri, 20 Sep 2002 14:49:56 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 20 Sep 2002 14:35:27 -0400
From: "Michael C. Cambria" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020819
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: -17 review Section 6 - BGP Error Handling.
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hi,

At the beginning of Section 6. BGP Error Handling:


    "When any of the conditions described here are detected, a
    NOTIFICATION message with the indicated Error Code, Error Subcode,
    and Data fields is sent, and the BGP connection is closed."

There are several cases where the conditions described in this section 
do not result in the BGP connection being closed.  These conditions 
should either state that the connection stays up.  Another possibility 
is to remove "and the BGP connection is closed." above, and for each 
listed connection, state what happens to the BGP connection.  This 
already takes place for certain conditions, but isn't done consistantly.


I tried to list what I found (which may be wrong or incomplete) below:



"If the NEXT_HOP attribute is semantically incorrect, the error should 
be logged, and the route should be ignored. In this case, no 
NOTIFICATION message should be sent."

* Append the connection is not closed.


"(a) discard new address prefixes from the neighbor, or (b) terminate 
the BGP peering with the neighbor."

* Append "the connection is not closed" to case (a)


    "If
    the autonomous system number appears in the AS path the route may be
    stored in the Adj-RIB-In,"

* append and the BGP connection stays up.

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

* Q1) does the BGP connection stay up?

* Q2) what if the router isn't configured to accept routes with its own 
AS in the AS path?  One _may_ store the route in Adj-RIB-In, but if one 
doesn't want to?  Is the BGP connection closed?  If so, what subcode?


    "If an optional attribute is recognized, then the value of this
    attribute is checked. If an error is detected, the attribute is
    discarded, and the Error Subcode is set to Optional Attribute Error.
    The Data field contains the attribute (type, length and value)."

* Append and the BGP conneciton stays up after "the attribute is discarded".


Thanks,
MikeC



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA16875 for <[e-mail]>; Fri, 20 Sep 2002 14:50:06 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3B802912BD; Fri, 20 Sep 2002 14:49:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04ED0912BE; Fri, 20 Sep 2002 14:49:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B6640912BD for <[e-mail]>; Fri, 20 Sep 2002 14:49:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8C1C55E318; Fri, 20 Sep 2002 14:49:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 0152F5E2CB for <[e-mail]>; Fri, 20 Sep 2002 14:49:28 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8KInMm76747; Fri, 20 Sep 2002 11:49:22 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Michael C. Cambria" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: -17 review, Section 6.2 - must reject hold time 
In-Reply-To: Your message of "Fri, 20 Sep 2002 14:16:02 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 20 Sep 2002 11:49:22 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Mike,

> In Section 6.2 on OPEN message error handling:
> 
>     If the Hold Time field of the OPEN message is unacceptable, then the
>     Error Subcode MUST be set to Unacceptable Hold Time. An
>     implementation MUST reject Hold Time values of one or two seconds.
> 
> I feel that text similar to:
> 
> "An implementation MUST also reject Hold Time values of zero received 
> from a peer in a different AS" should be considered for completeness.

>From 4.4:

   If the negotiated Hold Time interval is zero, then periodic KEEPALIVE
   messages MUST NOT be sent.  

So, setting Hold Time to zero is perfectly valid (under certain
circumstances).

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 OAA16584 for <[e-mail]>; Fri, 20 Sep 2002 14:40:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F0610912BB; Fri, 20 Sep 2002 14:40:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7CE8912BC; Fri, 20 Sep 2002 14:40:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 858E4912BB for <[e-mail]>; Fri, 20 Sep 2002 14:40:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 73F745E31C; Fri, 20 Sep 2002 14:40:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id A62A05E318 for <[e-mail]>; Fri, 20 Sep 2002 14:40:03 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8KIdug08742; Fri, 20 Sep 2002 14:39:56 -0400 (EDT) (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 g8KIdrG08735; Fri, 20 Sep 2002 14:39:53 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8KIdrq20662; Fri, 20 Sep 2002 14:39:53 -0400 (EDT)
Date: Fri, 20 Sep 2002 14:39:53 -0400
From: Jeffrey Haas <[e-mail]>
To: "Michael C. Cambria" <[e-mail]>
Cc: [e-mail]
Subject: Re: -17 review, Section 6.2 - must reject hold time
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 Fri, Sep 20, 2002 at 02:16:02PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Sep 20, 2002 at 02:16:02PM -0400, Michael C. Cambria wrote:
> "An implementation MUST also reject Hold Time values of zero received 
> from a peer in a different AS" should be considered for completeness.

Excepting that people use this to disable hold timers altogether.

> MikeC

-- 
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 OAA16461 for <[e-mail]>; Fri, 20 Sep 2002 14:36:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D5260912BA; Fri, 20 Sep 2002 14:36:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A09C1912BB; Fri, 20 Sep 2002 14:36:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7032C912BA for <[e-mail]>; Fri, 20 Sep 2002 14:36:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 59F0D5E31B; Fri, 20 Sep 2002 14:36:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 8D4695E318 for <[e-mail]>; Fri, 20 Sep 2002 14:36:26 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8KIaPD08470 for [e-mail]; Fri, 20 Sep 2002 14:36:25 -0400 (EDT) (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 g8KIaMG08463 for <[e-mail]>; Fri, 20 Sep 2002 14:36:22 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g8KIaMP18341 for [e-mail]; Fri, 20 Sep 2002 14:36:22 -0400 (EDT)
Date: Fri, 20 Sep 2002 14:36:22 -0400
From: Mathew Richardson <[e-mail]>
To: [e-mail]
Subject: Re: Review Comments: Section 4.3: "route" vs. destination - withdraw
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4i
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

> Yakov Rekhter <[e-mail]> [Fri, Sep 20, 2002 at 09:54:09AM -0700]:

<snip>

>   For the purpose of this protocol, a route is defined as a unit
>   of information that pairs a set of destinations with the attributes
>   of a path to those destinations. The set of destinations are
>   systems whose IP addresses are contained in one IP address prefix
>   carried in the Network Layer Reachability Information (NLRI)
>   field of an UPDATE message and the path is the information
>   reported in the path attributes field of the same UPDATE message.
>
>   Multiple routes that have the same path attributes can be
>   advertised in a single UPDATE message by including multiple
>   prefixes in the NLRI field of the UPDATE message.

<snip>

Sounds good :).

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 OAA16322 for <[e-mail]>; Fri, 20 Sep 2002 14:33:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5A775912B6; Fri, 20 Sep 2002 14:33:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 179E9912B8; Fri, 20 Sep 2002 14:33:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0F219912B6 for <[e-mail]>; Fri, 20 Sep 2002 14:33:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EBE215E318; Fri, 20 Sep 2002 14:33:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id 715CA5E31B for <[e-mail]>; Fri, 20 Sep 2002 14:33:31 -0400 (EDT)
Received: from fid4.com (mcambria3.avayactc.com [199.93.238.136]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g8KIUVuo024159 for <[e-mail]>; Fri, 20 Sep 2002 14:30:32 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 20 Sep 2002 14:16:02 -0400
From: "Michael C. Cambria" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020819
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: -17 review, Section 6.2 - must reject hold time
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

In Section 6.2 on OPEN message error handling:

    If the Hold Time field of the OPEN message is unacceptable, then the
    Error Subcode MUST be set to Unacceptable Hold Time. An
    implementation MUST reject Hold Time values of one or two seconds.

I feel that text similar to:

"An implementation MUST also reject Hold Time values of zero received 
from a peer in a different AS" should be considered for completeness.

MikeC



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA16315 for <[e-mail]>; Fri, 20 Sep 2002 14:33:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 986E0912B8; Fri, 20 Sep 2002 14:33:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F945912BA; Fri, 20 Sep 2002 14:33:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4902D912B8 for <[e-mail]>; Fri, 20 Sep 2002 14:33:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 244995E31D; Fri, 20 Sep 2002 14:33:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 1CF435E318 for <[e-mail]>; Fri, 20 Sep 2002 14:33:33 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8KIXWM08304 for [e-mail]; Fri, 20 Sep 2002 14:33:32 -0400 (EDT) (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 g8KIXSG08285 for <[e-mail]>; Fri, 20 Sep 2002 14:33:28 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g8KIXS718321 for [e-mail]; Fri, 20 Sep 2002 14:33:28 -0400 (EDT)
Date: Fri, 20 Sep 2002 14:33:28 -0400
From: "'Mathew Richardson'" <[e-mail]>
To: [e-mail]
Subject: Re: Proxy: comments on section 9.1.3
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4i
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

> Yakov Rekhter <[e-mail]> [Fri, Sep 20, 2002 at 09:07:43AM -0700]:

<snip>

>Accepted with a minor rewording (as follows):
>
> 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.
>
>Yakov.

Sounds good.

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 OAA16299 for <[e-mail]>; Fri, 20 Sep 2002 14:33:30 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 880AB9122F; Fri, 20 Sep 2002 14:32:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49C53912B6; Fri, 20 Sep 2002 14:32:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC5449122F for <[e-mail]>; Fri, 20 Sep 2002 14:32:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2D6205E31D; Fri, 20 Sep 2002 14:32:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 90A255E31C for <[e-mail]>; Fri, 20 Sep 2002 14:32:15 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8KIVvS08237; Fri, 20 Sep 2002 14:31:57 -0400 (EDT) (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 g8KIVsG08230; Fri, 20 Sep 2002 14:31:54 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8KIVs420599; Fri, 20 Sep 2002 14:31:54 -0400 (EDT)
Date: Fri, 20 Sep 2002 14:31:54 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Proxy: comments on section 9.1.3
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, Sep 10, 2002 at 05:28:15PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

BTW, just to be public about this:

On Tue, Sep 10, 2002 at 05:28:15PM -0400, Curtis Villamizar wrote:
> > > You are referring to 3.1 which maybe isn't clear enough.
> > > 
> > >  3.1 Routes: Advertisement and Storage
> > > 
> > >    For the purpose of this protocol, a route is defined as a unit of
> > >    information that pairs a set of destinations with the attributes of a
> > 
> > Note *set*.
> > 
> > Thus, I expect that a "route" consists of one or more destinations
> > in the NLRI with path attributes.
> 
> destination == host address
> 
> One route is one NRLI plus the attributes.
> 
> One UPDATE may have zero or more NRLI.

Thanks for your explanation.  With the note that "destination== host address",
things made much more sense.  But I've had every one of our new people
at NextHop reading the spec ask about this, so I like the new text
much better. :-)

-- 
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 OAA15769 for <[e-mail]>; Fri, 20 Sep 2002 14:15:54 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5B9F2912B7; Fri, 20 Sep 2002 14:13:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 23FFC912BA; Fri, 20 Sep 2002 14:13:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 67FD0912B7 for <[e-mail]>; Fri, 20 Sep 2002 14:13:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 58F3D5E316; Fri, 20 Sep 2002 14:13:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id D9F9F5E2CC for <[e-mail]>; Fri, 20 Sep 2002 14:13:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA20227; Fri, 20 Sep 2002 14:13:41 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA07524; Fri, 20 Sep 2002 14:13:43 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7DD57>; Fri, 20 Sep 2002 14:13:42 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Review Comments: draft-ietf-idr-bgp4-17.txt 
Date: Fri, 20 Sep 2002 14:13:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Thank You, Yakov

I appreciate it. 

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Friday, September 20, 2002 1:55 PM
> To: Abarbanel, Benjamin
> Cc: '[e-mail]'
> Subject: Re: Review Comments: draft-ietf-idr-bgp4-17.txt 
> 
> 
> Ben,
> 
> > General Comment:
> > 
> > 1. Document needs, Table of Contents, Glossary, and Index
> 
> Table of Contents and definition of commonly used terms will be
> added to the -18 version.
> 
> 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 NAA15144 for <[e-mail]>; Fri, 20 Sep 2002 13:55:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 73148912B5; Fri, 20 Sep 2002 13:55:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44A18912B6; Fri, 20 Sep 2002 13:55:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1439C912B5 for <[e-mail]>; Fri, 20 Sep 2002 13:55:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E4A9B5E316; Fri, 20 Sep 2002 13:55:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 593FE5E2A0 for <[e-mail]>; Fri, 20 Sep 2002 13:55:12 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8KHtAm70582; Fri, 20 Sep 2002 10:55:10 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: Review Comments: draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 10:31:13 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 20 Sep 2002 10:55:10 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> General Comment:
> 
> 1. Document needs, Table of Contents, Glossary, and Index

Table of Contents and definition of commonly used terms will be
added to the -18 version.

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 NAA15098 for <[e-mail]>; Fri, 20 Sep 2002 13:54:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 99095912B4; Fri, 20 Sep 2002 13:53:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 668E2912B5; Fri, 20 Sep 2002 13:53:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CEEA6912B4 for <[e-mail]>; Fri, 20 Sep 2002 13:53:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B6B4B5E2A0; Fri, 20 Sep 2002 13:53:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 5DFE65E1BB for <[e-mail]>; Fri, 20 Sep 2002 13:53:29 -0400 (EDT)
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 NAA50277; Fri, 20 Sep 2002 13:53:12 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
In-reply-to: Your message of "Thu, 19 Sep 2002 11:43:34 EDT." <[e-mail]> 
Date: Fri, 20 Sep 2002 13:53:12 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> Jeff:
> 
> > -----Original Message-----
> > From: Jeffrey Haas [mailto:[e-mail]]
> > Sent: Thursday, September 19, 2002 11:25 AM
> > To: Abarbanel, Benjamin
> > Cc: [e-mail]
> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive
> > 
> > 
> > On Wed, Sep 18, 2002 at 04:56:01PM -0400, Abarbanel, Benjamin wrote:
> > > Then all other route types that win over the BGP routes in 
> > the Routing table
> > > should be automatically exported to BGP.
> > 
> > Probably the simplest way of dealing with this is dealing with
> > the case when a route in LocRib and the Routing table conflict
> > and the Routing Table has a non-BGP route installed in it is
> > to note that (in almost all cases if not always) the route actually
> > installed in the Routing Table is the one passed to Phase 3 of
> > the selection process.
> > 
> 
> My point is that the non-BGP route has to be configured for export to
> BGP for this to be done. Sometimes it is not obvious and the operator
> forgets to do so. Sometimes, he intentially does not want to do so.
> Thus a potential inconsistency could occur. 
> 
> Remember non-BGP routes do not have attributes like AS-Path. If an
> IGP/Static route is prefered over a IBGP route for a destination that is
> outside this AS, it could create routing loops. Implying the route got
> exported from EBGP to IGP by another IBGP router. Then that router flooded
> this route as a regular IGP 
> route to the current router, where the problem occured. Now that I have
> twisted your thinking a bit, you see the problem.
> 
> > -- 
> > Jeff Haas 
> > NextHop Technologies


Static routes can cause black holes and routing loops.  You don't need
BGP to help static routes do this but you can mess up BGP routing with
static routes.  That is inherent to a route that you make up from
nothing other than a configuration entry.  [btw - a static route will
only casue a route loop in BGP if the static route points outside your
AS to someone who is routing based on it, otherwise just a black
hole.]

An IGP route (that is not derived from a static route) will not cause
a route loop if injected into BGP and if the recommendations of the
BGP spec are followed, namely "don't advertise a route you don't use"
and apply the same route selection rules thrughout the AS.  If an
interface in your IGP is misnumbered, it could blackhole traffic to
the legitimate site but the BGP protocol can't prevent that.

Other uses of BGP that may cause a routing loop have so far been left
outside of the spec.  The spec goes further to specify the an order in
which route selection rules should be applied, which if not violate
will not form a route loop no matter the configuration of the AS and
will result in route loop free interoperability with other vendors.
We have so far left such things as modifying the route selection rules
within an AS, using alternate route selection rules or ordering which
can accidentally be configured to form persistent route loops, as
outside the spec.

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 NAA14998 for <[e-mail]>; Fri, 20 Sep 2002 13:50:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BD035912B9; Fri, 20 Sep 2002 13:48:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 988B4912BC; Fri, 20 Sep 2002 13:48:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 108F7912BA for <[e-mail]>; Fri, 20 Sep 2002 13:47:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 689935E316; Fri, 20 Sep 2002 13:46:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 7FD5D5E2A0 for <[e-mail]>; Fri, 20 Sep 2002 13:46:57 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8KHktl06177; Fri, 20 Sep 2002 13:46:55 -0400 (EDT) (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 g8KHkqG06170; Fri, 20 Sep 2002 13:46:52 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8KHkqR20072; Fri, 20 Sep 2002 13:46:52 -0400 (EDT)
Date: Fri, 20 Sep 2002 13:46:52 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: Review Comments: Section 4.3: "route" vs. destination - withdraw
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, Sep 20, 2002 at 09:54:09AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Being one of the biggest complainers about the current text:

On Fri, Sep 20, 2002 at 09:54:09AM -0700, Yakov Rekhter wrote:
>    For the purpose of this protocol, a route is defined as a unit
>    of information that pairs a set of destinations with the attributes
>    of a path to those destinations. The set of destinations are
>    systems whose IP addresses are contained in one IP address prefix
>    carried in the Network Layer Reachability Information (NLRI)
>    field of an UPDATE message and the path is the information
>    reported in the path attributes field of the same UPDATE message.
> 
>    Multiple routes that have the same path attributes can be
>    advertised in a single UPDATE message by including multiple
>    prefixes in the NLRI field of the UPDATE message.

I love this. :-)

> 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 NAA14760 for <[e-mail]>; Fri, 20 Sep 2002 13:44:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 31E1B912B2; Fri, 20 Sep 2002 13:44:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05737912B3; Fri, 20 Sep 2002 13:44:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E79F6912B2 for <[e-mail]>; Fri, 20 Sep 2002 13:44:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D672C5E2A0; Fri, 20 Sep 2002 13:44:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 557BC5E151 for <[e-mail]>; Fri, 20 Sep 2002 13:44:05 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA18396; Fri, 20 Sep 2002 13:44:03 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA02061; Fri, 20 Sep 2002 13:44:01 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7DCMH>; Fri, 20 Sep 2002 13:43:56 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Proxy: comments on section 9.1.3
Date: Fri, 20 Sep 2002 13:43:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Jeff:
 I knew that, I should have not used the word FIB. Again this is something
that is also implementation specific, thus your point may or may not be
totally correct. But you know what I meant. 

Anyway, I still wonder whether my correction to the text is technically
correct
or off base on what we are trying to say?

Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Friday, September 20, 2002 1:41 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: Proxy: comments on section 9.1.3
> 
> 
> Ben,
> 
> To be picky:
> 
> On Fri, Sep 20, 2002 at 12:27:38PM -0400, Abarbanel, Benjamin wrote:
> > My only point is if a BGP route is added to the FIB 
> (Routing Table), it does
> 
> The FIB is distinct from the Routing Table.  The Routing Table is
> used to populate one or more FIBs.
> 
> (And, if you have implementations with multiple routing instances,
> VRFs, etc, then you may have multiple Routing Tables that
> control or share access to one or more FIBs. :-)
> 
> > Ben
> 
> -- 
> 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 NAA14646 for <[e-mail]>; Fri, 20 Sep 2002 13:41:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 86CB1912B0; Fri, 20 Sep 2002 13:40:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 52492912B2; Fri, 20 Sep 2002 13:40:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 382B3912B0 for <[e-mail]>; Fri, 20 Sep 2002 13:40:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 241A95DFA0; Fri, 20 Sep 2002 13:40:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 653F25DF4A for <[e-mail]>; Fri, 20 Sep 2002 13:40:45 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8KHeef05951; Fri, 20 Sep 2002 13:40:40 -0400 (EDT) (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 g8KHebG05944; Fri, 20 Sep 2002 13:40:37 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8KHeb819993; Fri, 20 Sep 2002 13:40:37 -0400 (EDT)
Date: Fri, 20 Sep 2002 13:40:37 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: Proxy: comments on section 9.1.3
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 Fri, Sep 20, 2002 at 12:27:38PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Ben,

To be picky:

On Fri, Sep 20, 2002 at 12:27:38PM -0400, Abarbanel, Benjamin wrote:
> My only point is if a BGP route is added to the FIB (Routing Table), it does

The FIB is distinct from the Routing Table.  The Routing Table is
used to populate one or more FIBs.

(And, if you have implementations with multiple routing instances,
VRFs, etc, then you may have multiple Routing Tables that
control or share access to one or more FIBs. :-)

> Ben

-- 
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 NAA14565 for <[e-mail]>; Fri, 20 Sep 2002 13:39:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5894D912AF; Fri, 20 Sep 2002 13:36:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 17902912B2; Fri, 20 Sep 2002 13:36:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BD739912AF for <[e-mail]>; Fri, 20 Sep 2002 13:36:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id AB0485DFA0; Fri, 20 Sep 2002 13:36:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 4F3FB5DF4A for <[e-mail]>; Fri, 20 Sep 2002 13:36:20 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8KHaCm68650; Fri, 20 Sep 2002 10:36:13 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Michael C. Cambria'" <[e-mail]>, [e-mail]
Subject: Re: Review: Comments: Section 4.3: UPDATE min length 
In-Reply-To: Your message of "Tue, 10 Sep 2002 08:56:31 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 20 Sep 2002 10:36:12 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> Right.
> 
> " The minimum length of the UPDATE message is 23 octets -- 19 octets
>    for the fixed header + 2 octets for the Withdrawn Routes Length + 2
>    octets for the Total Path Attribute Length (the value of Withdrawn
>    Routes Length is 0 and the value of Total Path Attribute Length is
>    0)."
> 
> Should be moved up to just after
> 
> "... the Total Path Attribute Length field and the
>          Withdrawn Routes Length field."

Disagree, as "... the Total Path Attribute Length field and the
Withdrawn Routes Length field." explains how to calculate the length
of NLRI field (and therefore is part of the NLRI field description),
while "The minimum length of the UPDATE message is 23 octets...."
has to do with the length of the UPDATE message.

> And
> 
> " the value of Withdrawn
>    Routes Length is 0 and the value of Total Path Attribute Length is
>    0)."
> 
> Should be changed to 
> 
> " the min. value of Withdrawn
>    Routes Length is 0 and the min. value of Total Path Attribute Length is
>    0)."

Disagree, as the text doesn't talk about what is the minimum value
of the Withdrawn Routes Length and Total Path Attribute Length
fields, but talks about the value of these fields in the case of
a min length UPDATE message.

Yakov.

> 
> -----Original Message-----
> From: Michael C. Cambria [mailto:[e-mail]] 
> Sent: Saturday, September 07, 2002 1:02 PM
> To: [e-mail]
> Subject: Review: Comments: Section 4.3: UPDATE min length
> 
> 
> The text about the mimimum length, at first look, gives the impression 
> that it is still part of the NLRI field description and/or the Path 
> Attributes section.  A new "subsection" or heading of some sort would be 
> helpfull in switching context back to the UPDATE message as a whole and 
> not the path attributes field anymore.
> 
> MikeC


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA14329 for <[e-mail]>; Fri, 20 Sep 2002 13:32:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 990C0912A9; Fri, 20 Sep 2002 13:32:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 664F5912AD; Fri, 20 Sep 2002 13:32:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 442CF912A9 for <[e-mail]>; Fri, 20 Sep 2002 13:32:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A95435E316; Fri, 20 Sep 2002 13:32:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id E351F5E151 for <[e-mail]>; Fri, 20 Sep 2002 13:32:00 -0400 (EDT)
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 NAA50222; Fri, 20 Sep 2002 13:31:46 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Mareline Sheldon <[e-mail]>
Cc: [e-mail]
Reply-To: [e-mail]
Subject: Re: Multiple BGP Process 
In-reply-to: Your message of "Thu, 19 Sep 2002 00:14:24 PDT." <[e-mail]> 
Date: Fri, 20 Sep 2002 13:31:46 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Mareline Sheld
on writes:
> Hi,
> Do we have this concept of running multiple BGP processes on a signle router?
>  I could not find
> any literature on the net and will appreciate if anybody could give me some p
> ointers to it. Is
> there any need for that?
> 
> Thanks,
> mareline s.


Not a big deal.

In cases where it is useful to have one router appear to be in two
different AS, for example doing IBGP in both, two BGP processes are
run rather than buying two routers and a link between them.

This seems to happen at the US/Europe boundary for one ISP where due
to traffic engineering requirements of the interconnect points the
same router could benefit from having traffic engineering information
from both AS.

Partition of the IGP is desirable for scaling.  IGP areas would solve
this but IGP areas are already used in US and in Europe so two AS are
used.  I think these are internal AS and so are not visible to the
outside world.

The only thing that might be non-obvious is that it is desirable to
have policy control and aggregation of information between the BGP
processes.

This is just one example.  There are others.

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 NAA13874 for <[e-mail]>; Fri, 20 Sep 2002 13:17:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EDA5E912A8; Fri, 20 Sep 2002 13:16:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9299912A9; Fri, 20 Sep 2002 13:16:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 28011912A8 for <[e-mail]>; Fri, 20 Sep 2002 13:16:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9A85F5E317; Fri, 20 Sep 2002 13:16:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id A82375E314 for <[e-mail]>; Fri, 20 Sep 2002 13:16:39 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8KHGcm66929; Fri, 20 Sep 2002 10:16:38 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: bgp draft review 
In-Reply-To: Your message of "Tue, 10 Sep 2002 08:35:11 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 20 Sep 2002 10:16:38 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> Please add a table a contents, and please rename the 6.x sections in
> appendix so they are not confused with the regular 6.x sections.

Sure. 

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 NAA13663 for <[e-mail]>; Fri, 20 Sep 2002 13:10:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8C523912A5; Fri, 20 Sep 2002 13:09:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55B88912A7; Fri, 20 Sep 2002 13:09:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 00D0E912A5 for <[e-mail]>; Fri, 20 Sep 2002 13:09:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CF9C75E2FF; Fri, 20 Sep 2002 13:09:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 79B445E278 for <[e-mail]>; Fri, 20 Sep 2002 13:09:47 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1GZ6Z>; Fri, 20 Sep 2002 13:09:47 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Michael C. Cambria" <[e-mail]>
Cc: [e-mail]
Subject: RE: Review: Section 4.3 - Path Attributes 
Date: Fri, 20 Sep 2002 13:09:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Sounds good.

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Friday, September 20, 2002 12:30 PM
To: Michael C. Cambria
Cc: [e-mail]
Subject: Re: Review: Section 4.3 - Path Attributes 

Michael,

> 
>  From a first time reader point of view ...
> 
> The top of page 13 says:
> 
> "A variable length sequence of path attributes is present in every
UPDATE."
> 
> Is this really true, given that later, in the second to last paragraph 
> of this section (4.3):
> 
> "An UPDATE message might advertise only routes to be withdrawn from 
> service, in which case it will not include path attributes or Network 
> Layer Reachability Information."
> 
> This could be confusing to a first time reader.
> 
> The path attribute length is present in every UPDATE, the path attribute 
> field itself can be left out, both according to the description of the 
> minimum length of the UPDATE message and (implied?) in the picture of 
> the UPDATE message at the beginning of section 4.3.

To correct the confusion I propose to replace:

  A variable length sequence of path attributes is present in every UPDATE.

with:

  A variable length sequence of path attributes is present in
  every UPDATE message, except for an UPDATE message that carries 
  only the withdrawn 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 MAA13160 for <[e-mail]>; Fri, 20 Sep 2002 12:54:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BA21591296; Fri, 20 Sep 2002 12:54:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BB63912A5; Fri, 20 Sep 2002 12:54:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5736D91296 for <[e-mail]>; Fri, 20 Sep 2002 12:54:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3F6905E311; Fri, 20 Sep 2002 12:54:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id A0F735DDAD for <[e-mail]>; Fri, 20 Sep 2002 12:54:16 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8KGs9m65058; Fri, 20 Sep 2002 09:54:09 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Mathew Richardson <[e-mail]>
Cc: "Michael C. Cambria" <[e-mail]>, [e-mail]
Subject: Re: Review Comments: Section 4.3: "route" vs. destination - withdraw 
In-Reply-To: Your message of "Mon, 09 Sep 2002 11:24:10 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 20 Sep 2002 09:54:09 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Matt,

> >From a first time reader point of view ...
> >
> >When I read these two paragraphs at the end of section 4.3:
> >
> >"An UPDATE message can list multiple routes to be withdrawn from 
> >service.  Each such route is identified by its destination (expressed as 
> >an IP prefix), which unambiguously identifies the route in the context 
> >of the BGP speaker - BGP speaker connection to which it has been 
> >previously advertised.
> >
> >An UPDATE message might advertise only routes to be withdrawn from 
> >service, in which case it will not include path attributes or Network 
> >Layer Reachability Information. Conversely, it may advertise only a 
> >feasible route, in which case the WITHDRAWN ROUTES field need not be 
> >present."
> >
> >It reads as if one must withdraw the _set of destinations_ advertised 
> >with the route instead of just one or more destinations since route is 
> >defined in section 3.1 as:
> >
> >"For the purpose of this protocol, a route is defined as a unit of 
> >information that pairs a set of destinations with the attributes of a 
> >path to those destinations.  The set of destinations are the systems 
> >whose IP addresses are reported in the Network Layer Reachability 
> >Information (NLRI) field and the path is the information reported in the 
> >path attributes field of the same UPDATE message."
> 
> <snip>
> 
> Since this definition seems to result in a lot of confusion, how about
> changing the definition of route as follows:
> 
>   "For the purpose of this protocol, a route is defined as a unit of
>   information that pairs a set of destinations with the attributes of a
>   path to those destinations.  The set of destinations are systems whose
>   IP addresses are reported in one prefix present in the Network Layer
>   Reachability Information (NLRI) field of an UPDATE and the path is the
>   information reported in the path attributes field of the same UPDATE
>   message.
> 
>   This definition allows multiple routes to be advertised in a single
>   UPDATE message by including multiple prefixes in the NLRI field of
>   the UPDATE.  All such prefixes must be associated with the same set
>   of path attributes."

How about some minor rewording of your text, as follows:

   For the purpose of this protocol, a route is defined as a unit
   of information that pairs a set of destinations with the attributes
   of a path to those destinations. The set of destinations are
   systems whose IP addresses are contained in one IP address prefix
   carried in the Network Layer Reachability Information (NLRI)
   field of an UPDATE message and the path is the information
   reported in the path attributes field of the same UPDATE message.

   Multiple routes that have the same path attributes can be
   advertised in a single UPDATE message by including multiple
   prefixes in the NLRI field of the UPDATE message.

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 MAA12663 for <[e-mail]>; Fri, 20 Sep 2002 12:38:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3ADA79121D; Fri, 20 Sep 2002 12:37:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0298C91227; Fri, 20 Sep 2002 12:37:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B80709121D for <[e-mail]>; Fri, 20 Sep 2002 12:37:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8D9EE5DEF4; Fri, 20 Sep 2002 12:37:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id EEE085DDAD for <[e-mail]>; Fri, 20 Sep 2002 12:37:53 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8KGblm63636; Fri, 20 Sep 2002 09:37:47 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Michael C. Cambria" <[e-mail]>
Cc: [e-mail]
Subject: Re: Review comment: bottom of page 16 
In-Reply-To: Your message of "Sat, 07 Sep 2002 22:33:33 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 20 Sep 2002 09:37:47 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Mike,

> 
> The description of the NLRI prefix field in update reads as if there are 
>   multiple prefixes per field.
> 
> "The Prefix field contains IP address prefixes ..."
> 
> Shouldn't this say "contains an IP address prefix ...", similar to the 
> description of the withdrawn routes field?  e.g. each single prefix is 
> preceeded by a length.

Correct (will be fixed in the -18 version). 

Thanks for pointing this out !!!

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 MAA12441 for <[e-mail]>; Fri, 20 Sep 2002 12:31:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 20B4A912A0; Fri, 20 Sep 2002 12:30:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1DBF912A5; Fri, 20 Sep 2002 12:30:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F65B912A0 for <[e-mail]>; Fri, 20 Sep 2002 12:30:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B4ED35E315; Fri, 20 Sep 2002 12:30:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 19CFD5E311 for <[e-mail]>; Fri, 20 Sep 2002 12:30:15 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8KGU9m63077; Fri, 20 Sep 2002 09:30:09 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Michael C. Cambria" <[e-mail]>
Cc: [e-mail]
Subject: Re: Review: Section 4.3 - Path Attributes 
In-Reply-To: Your message of "Sat, 07 Sep 2002 12:59:27 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 20 Sep 2002 09:30:09 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Michael,

> 
>  From a first time reader point of view ...
> 
> The top of page 13 says:
> 
> "A variable length sequence of path attributes is present in every UPDATE."
> 
> Is this really true, given that later, in the second to last paragraph 
> of this section (4.3):
> 
> "An UPDATE message might advertise only routes to be withdrawn from 
> service, in which case it will not include path attributes or Network 
> Layer Reachability Information."
> 
> This could be confusing to a first time reader.
> 
> The path attribute length is present in every UPDATE, the path attribute 
> field itself can be left out, both according to the description of the 
> minimum length of the UPDATE message and (implied?) in the picture of 
> the UPDATE message at the beginning of section 4.3.

To correct the confusion I propose to replace:

  A variable length sequence of path attributes is present in every UPDATE.

with:

  A variable length sequence of path attributes is present in
  every UPDATE message, except for an UPDATE message that carries 
  only the withdrawn routes.

Yakov.


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 MAA12426 for <[e-mail]>; Fri, 20 Sep 2002 12:31:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2C0C39123A; Fri, 20 Sep 2002 12:29:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1941912A5; Fri, 20 Sep 2002 12:29:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 32DC79123A for <[e-mail]>; Fri, 20 Sep 2002 12:28:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 118D55E313; Fri, 20 Sep 2002 12:28:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 8E61B5E311 for <[e-mail]>; Fri, 20 Sep 2002 12:28:55 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA14100; Fri, 20 Sep 2002 12:28:44 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA17906; Fri, 20 Sep 2002 12:27:40 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7C9RJ>; Fri, 20 Sep 2002 12:27:39 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, "'Mathew Richardson'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Proxy: comments on section 9.1.3 
Date: Fri, 20 Sep 2002 12:27:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

My only point is if a BGP route is added to the FIB (Routing Table), it does
not
gaurantee it is used for forwarding. There may be other protocol routes
in the FIB for the same destination that get preference and thus cause the
BGP route not to be used for forwarding. 

I thought we were trying to say that any time this happens the impacts to
BGP propagating this route to outgoing peers is outside the scope of this
documents.

Ben
> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Friday, September 20, 2002 12:18 PM
> To: 'Abarbanel, Benjamin'; 'Yakov Rekhter'; 'Mathew Richardson'
> Cc: [e-mail]
> Subject: RE: Proxy: comments on section 9.1.3 
> 
> 
> Ben,
> 
> I like Yakov's better.  Nothing personal.
> 
> :-)
> 
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Friday, September 20, 2002 12:16 PM
> To: 'Yakov Rekhter'; 'Mathew Richardson'
> Cc: [e-mail]
> Subject: RE: Proxy: comments on section 9.1.3 
> 
> Yakov:
>   I hate to sound picky, but could this improve the intended meaning?
> 
>   "Any local-policy which results in routes being added to an
>    Adj-RIB-Out without also being used for forwarding, is outside the 
>    scope of this document."
> 
> Ben
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Friday, September 20, 2002 12:08 PM
> > To: 'Mathew Richardson'
> > Cc: [e-mail]
> > Subject: Re: Proxy: comments on section 9.1.3 
> > 
> > 
> > Matt,
> > 
> > > > 'Mathew Richardson' <[e-mail]> [Fri, Sep 06, 2002 
> > at 11:16:06AM -040
> > 0]:
> > > 
> > > <snip>
> > > 
> > > Replying to myself to correct some poor grammar:
> > > 
> > > >I think that case must either be disallowed, or placed 
> outside the
> > > >scope of the base document.  How about adding to section 9.1.3,
> > > >at the end:
> > > >
> > > >  Any local-policy which results in reachability being 
> added to an
> > > >  Adj-RIB-Out without also being added to the local BGP speaker's
> > > >  forwarding table, are beyond the scope of this document.
> > > 
> > > <snip>
> > > 
> > > The last line should read:
> > > 
> > >   forwarding table is beyond the scope of this document.
> > 
> > Accepted with a minor rewording (as follows):
> > 
> >  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.
> > 
> > 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 MAA11952 for <[e-mail]>; Fri, 20 Sep 2002 12:18:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id ED58691233; Fri, 20 Sep 2002 12:18:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B51EB91235; Fri, 20 Sep 2002 12:18:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CAF7791233 for <[e-mail]>; Fri, 20 Sep 2002 12:17:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9A4565E30E; Fri, 20 Sep 2002 12:17:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 25C6C5E30D for <[e-mail]>; Fri, 20 Sep 2002 12:17:53 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1GZSH>; Fri, 20 Sep 2002 12:17:52 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, "'Mathew Richardson'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Proxy: comments on section 9.1.3 
Date: Fri, 20 Sep 2002 12:17:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Ben,

I like Yakov's better.  Nothing personal.

:-)

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Friday, September 20, 2002 12:16 PM
To: 'Yakov Rekhter'; 'Mathew Richardson'
Cc: [e-mail]
Subject: RE: Proxy: comments on section 9.1.3 

Yakov:
  I hate to sound picky, but could this improve the intended meaning?

  "Any local-policy which results in routes being added to an
   Adj-RIB-Out without also being used for forwarding, is outside the 
   scope of this document."

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Friday, September 20, 2002 12:08 PM
> To: 'Mathew Richardson'
> Cc: [e-mail]
> Subject: Re: Proxy: comments on section 9.1.3 
> 
> 
> Matt,
> 
> > > 'Mathew Richardson' <[e-mail]> [Fri, Sep 06, 2002 
> at 11:16:06AM -040
> 0]:
> > 
> > <snip>
> > 
> > Replying to myself to correct some poor grammar:
> > 
> > >I think that case must either be disallowed, or placed outside the
> > >scope of the base document.  How about adding to section 9.1.3,
> > >at the end:
> > >
> > >  Any local-policy which results in reachability being added to an
> > >  Adj-RIB-Out without also being added to the local BGP speaker's
> > >  forwarding table, are beyond the scope of this document.
> > 
> > <snip>
> > 
> > The last line should read:
> > 
> >   forwarding table is beyond the scope of this document.
> 
> Accepted with a minor rewording (as follows):
> 
>  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.
> 
> 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 MAA11894 for <[e-mail]>; Fri, 20 Sep 2002 12:17:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 94A1091238; Fri, 20 Sep 2002 12:16:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F4D991235; Fri, 20 Sep 2002 12:16:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 72DBC91233 for <[e-mail]>; Fri, 20 Sep 2002 12:16:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EF6205E30D; Fri, 20 Sep 2002 12:16:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 6FEC35E30B for <[e-mail]>; Fri, 20 Sep 2002 12:16:30 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1GZSC>; Fri, 20 Sep 2002 12:16:29 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Proxy: comments on section 9.1.3 
Date: Fri, 20 Sep 2002 12:16:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Yakov,

In response to your proposed text:

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

I agree, it should be added. Very clear!

That's what I was trying to say:

"To characterize the set of policy decisions that can be enforced using BGP,
one must focus on the rule that a BGP speaker may advertise to other BGP
speakers only those prefixes that are eligible for use by itself - whether
or not to require the prefixes actually be used itself based on some
priority mechanism for choosing routes from independent routing processes
MAY be an administratively configurable option [N]." ... [N] RFC1812

Curtis made some good arguments on why bgp does not need to/should not do
this.

-Jonathan

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Friday, September 20, 2002 12:08 PM
To: 'Mathew Richardson'
Cc: [e-mail]
Subject: Re: Proxy: comments on section 9.1.3 

Matt,

> > 'Mathew Richardson' <[e-mail]> [Fri, Sep 06, 2002 at 11:16:06AM
-040
0]:
> 
> <snip>
> 
> Replying to myself to correct some poor grammar:
> 
> >I think that case must either be disallowed, or placed outside the
> >scope of the base document.  How about adding to section 9.1.3,
> >at the end:
> >
> >  Any local-policy which results in reachability being added to an
> >  Adj-RIB-Out without also being added to the local BGP speaker's
> >  forwarding table, are beyond the scope of this document.
> 
> <snip>
> 
> The last line should read:
> 
>   forwarding table is beyond the scope of this document.

Accepted with a minor rewording (as follows):

 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.

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 MAA11872 for <[e-mail]>; Fri, 20 Sep 2002 12:16:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 33A0A91232; Fri, 20 Sep 2002 12:15:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED3B191233; Fri, 20 Sep 2002 12:15:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 011FE91232 for <[e-mail]>; Fri, 20 Sep 2002 12:15:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A74DB5E30E; Fri, 20 Sep 2002 12:15:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id C78915E30D for <[e-mail]>; Fri, 20 Sep 2002 12:15:34 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA13554; Fri, 20 Sep 2002 12:15:32 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA15879; Fri, 20 Sep 2002 12:15:34 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7C89H>; Fri, 20 Sep 2002 12:15:33 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "'Mathew Richardson'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Proxy: comments on section 9.1.3 
Date: Fri, 20 Sep 2002 12:15:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov:
  I hate to sound picky, but could this improve the intended meaning?

  "Any local-policy which results in routes being added to an
   Adj-RIB-Out without also being used for forwarding, is outside the 
   scope of this document."

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Friday, September 20, 2002 12:08 PM
> To: 'Mathew Richardson'
> Cc: [e-mail]
> Subject: Re: Proxy: comments on section 9.1.3 
> 
> 
> Matt,
> 
> > > 'Mathew Richardson' <[e-mail]> [Fri, Sep 06, 2002 
> at 11:16:06AM -040
> 0]:
> > 
> > <snip>
> > 
> > Replying to myself to correct some poor grammar:
> > 
> > >I think that case must either be disallowed, or placed outside the
> > >scope of the base document.  How about adding to section 9.1.3,
> > >at the end:
> > >
> > >  Any local-policy which results in reachability being added to an
> > >  Adj-RIB-Out without also being added to the local BGP speaker's
> > >  forwarding table, are beyond the scope of this document.
> > 
> > <snip>
> > 
> > The last line should read:
> > 
> >   forwarding table is beyond the scope of this document.
> 
> Accepted with a minor rewording (as follows):
> 
>  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.
> 
> 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 MAA11634 for <[e-mail]>; Fri, 20 Sep 2002 12:08:06 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B073F91231; Fri, 20 Sep 2002 12:07:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C39A91232; Fri, 20 Sep 2002 12:07:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 497DC91231 for <[e-mail]>; Fri, 20 Sep 2002 12:07:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 229CA5E306; Fri, 20 Sep 2002 12:07:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id BB2315DDDC for <[e-mail]>; Fri, 20 Sep 2002 12:07:44 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8KG7hm61211; Fri, 20 Sep 2002 09:07:43 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "'Mathew Richardson'" <[e-mail]>
Cc: [e-mail]
Subject: Re: Proxy: comments on section 9.1.3 
In-Reply-To: Your message of "Fri, 06 Sep 2002 11:23:30 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 20 Sep 2002 09:07:43 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Matt,

> > 'Mathew Richardson' <[e-mail]> [Fri, Sep 06, 2002 at 11:16:06AM -040
0]:
> 
> <snip>
> 
> Replying to myself to correct some poor grammar:
> 
> >I think that case must either be disallowed, or placed outside the
> >scope of the base document.  How about adding to section 9.1.3,
> >at the end:
> >
> >  Any local-policy which results in reachability being added to an
> >  Adj-RIB-Out without also being added to the local BGP speaker's
> >  forwarding table, are beyond the scope of this document.
> 
> <snip>
> 
> The last line should read:
> 
>   forwarding table is beyond the scope of this document.

Accepted with a minor rewording (as follows):

 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.

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 LAA10603 for <[e-mail]>; Fri, 20 Sep 2002 11:33:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DA02491230; Fri, 20 Sep 2002 11:33:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7DBB91231; Fri, 20 Sep 2002 11:33:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8B67C91230 for <[e-mail]>; Fri, 20 Sep 2002 11:33:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6AD8D5E2F7; Fri, 20 Sep 2002 11:33:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id BFC625E2F3 for <[e-mail]>; Fri, 20 Sep 2002 11:33:16 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8KFXCw02562; Fri, 20 Sep 2002 11:33:12 -0400 (EDT) (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 g8KFX9G02555; Fri, 20 Sep 2002 11:33:09 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8KFX9g19281; Fri, 20 Sep 2002 11:33:09 -0400 (EDT)
Date: Fri, 20 Sep 2002 11:33:09 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: Mareline Sheldon <[e-mail]>, [e-mail]
Subject: Re: BGP Connections
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 Fri, Sep 20, 2002 at 11:26:39AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Sep 20, 2002 at 11:26:39AM -0400, Abarbanel, Benjamin wrote:
> Can you provide a path where this document
> (draft-kato-bgp-ipv6-link-local-01)
> can be found.

My apologies. I was looking at my local repository and it appears
to have expired.

I would suggest anyone who is interested contact the authors per
the message inside the ietf.org ftp site:

: This Internet-Draft has been deleted. Unrevised documents placed in the
: Internet-Drafts directories have a maximum life of six months. After
: that time, they are deleted. This Internet-Draft was not published as
: an RFC.
: 
: Internet-Drafts are not an archival document series, and expired
: drafts, such as this one, are not available; please do not ask for
: copies... they are not available. The Secretariat does not have
: information as to future plans of the authors or working groups WRT the
: deleted Internet-Draft.
: 
: For more information or a copy of the document, contact the author directly.
: 
: Draft Author(s):
: 
: B. Manning: [e-mail]
:     
: A. Kato: [e-mail]    

If you find the authors unresponsive, I'll be happy to e-mail you the
-00 copy that I have in my local repository.

> Ben

-- 
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 LAA10358 for <[e-mail]>; Fri, 20 Sep 2002 11:27:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2BA1791225; Fri, 20 Sep 2002 11:26:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E97C491230; Fri, 20 Sep 2002 11:26:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E36BB91225 for <[e-mail]>; Fri, 20 Sep 2002 11:26:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BAFAE5E2F4; Fri, 20 Sep 2002 11:26:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 4664D5E2F3 for <[e-mail]>; Fri, 20 Sep 2002 11:26:44 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA10498; Fri, 20 Sep 2002 11:26:41 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA06359; Fri, 20 Sep 2002 11:26:42 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7C6N2>; Fri, 20 Sep 2002 11:26:41 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, Mareline Sheldon <[e-mail]>
Cc: [e-mail]
Subject: RE: BGP Connections
Date: Fri, 20 Sep 2002 11:26:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Jeff:

Can you provide a path where this document
(draft-kato-bgp-ipv6-link-local-01)
can be found.


Thank You
Ben
> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Friday, September 20, 2002 9:56 AM
> To: Mareline Sheldon
> Cc: [e-mail]
> Subject: Re: BGP Connections
> 
> 
> On Thu, Sep 19, 2002 at 08:38:41PM -0700, Mareline Sheldon wrote:
> > are there any thoughts for writing a BGP spec for IPv6 
> which uses the IPv6 features like
> > anycast, link local IP addresses, site local etc.. as of 
> now we just use IPv4 to carry IPv6
> > information. Are there any thoughts for actually running 
> BGP over v6?
> 
> GateD and Cisco definitely interoperate using IPv6 as its 
> networking layer.
> 
> What "features" of IPv6 were you specifically thinking of?
> Anycast would be generally broken since we use a transport protocol
> like TCP.
> There was a link-layer peering extension proposed a while ago:
> draft-kato-bgp-ipv6-link-local-01
> 



> > mareline s.
> 
> -- 
> 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 KAA08876 for <[e-mail]>; Fri, 20 Sep 2002 10:41:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2A7349122D; Fri, 20 Sep 2002 10:41:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E855E9122E; Fri, 20 Sep 2002 10:41:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C3CD39122D for <[e-mail]>; Fri, 20 Sep 2002 10:41:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A83855DF42; Fri, 20 Sep 2002 10:41:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 33AC55DF0D for <[e-mail]>; Fri, 20 Sep 2002 10:41:00 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA06680; Fri, 20 Sep 2002 10:40:58 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA26861; Fri, 20 Sep 2002 10:40:59 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7CY4C>; Fri, 20 Sep 2002 10:40:58 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Mareline Sheldon'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, "'Nicolas REBIERRE'" <[e-mail]>, [e-mail]
Subject: RE: BGP Connections
Date: Fri, 20 Sep 2002 10:40:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Mareline:

> -----Original Message-----
> From: Mareline Sheldon [mailto:[e-mail]]
> Sent: Thursday, September 19, 2002 11:39 PM
> To: Abarbanel, Benjamin; 'Nicolas REBIERRE'; [e-mail]
> Subject: RE: BGP Connections
> 
> 
> are there any thoughts for writing a BGP spec for IPv6 which 
> uses the IPv6 features like
> anycast, link local IP addresses, site local etc.. as of now 

There have been efforts to document this issue and possible solutions
in these specs:

  RFC2545, Some mention of link local addressing useage. Some mention
           of IPv6 transport capability for peer sessions.

  Look at this spec:
http://www.ietf.org/internet-drafts/draft-itojun-jinmei-ipv6-issues-00.txt
section 1.2.


 Ben

> we just use IPv4 to carry IPv6
> information. Are there any thoughts for actually running BGP over v6?
> 
> just a thought .. 
> 
> mareline s.
> 
> --- "Abarbanel, Benjamin" <[e-mail]> wrote:
> > Nicolas:
> > 
> > You comments raise interesting observations.
> > 
> > below
> > 
> > > -----Original Message-----
> > > From: Nicolas REBIERRE [mailto:[e-mail]]
> > > Sent: Thursday, September 19, 2002 11:56 AM
> > > To: [e-mail]
> > > Subject: BGP Connections
> > > 
> > > 
> > > Hi all,
> > > 
> > > MP-BGP allows to advertise both IPv4 and IPv6 routes upon 
> a TCP over
> > > IPv4 connection. But shouldn't it better to have 2 
> distinct FSM with 2
> > > TCP connections: BGP/TCP/IPv6 for IPv6 routes, 
> BGP/TCP/IPv4 for IPv4
> > > routes ? This allows to handle IPv4 and IPv6 separately. 
> Moreover, if
> > 
> > Since the core/backbone network is only a IPv4 network, you 
> will not be 
> > able to setup a TCP session over IPv6 infrastructure. Most 
> likely you will 
> > use tunneling IPv6 over IPv4 or IPv6 over MPLS/IPv4 to 
> propagate the IPv6
> > routing information.  I think the goal now is to pass 
> exterior IPv6 (island)
> > clouds information through a core IPv4 backbone. When the 
> core is a true 
> > IPv6 topology your point makes sense.
> > 
> > > there is only one BGP/TCP/IPv4 connection for both kind 
> of routes, a
> > > problem on IPv6 connectivity will not be detected.
> > > 
> > True, that is the drawback of the current (temporary) solution. 
> > 
> > > So If one wants to receive both IPv4 and IPv6 routes from 
> a dual stack
> > > peer, could we impose to configure two connections to that peer,
> > > one for IPv4 and onother one for IPv6.
> > Not possible with current specs that I have seen.
> > 
> > > Could this restriction cause interoperability problems with some
> > > implementations ?
> > Maybe, can you be more specific what you are thinking of?
> > 
> > Ben 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.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 JAA07291 for <[e-mail]>; Fri, 20 Sep 2002 09:56:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B0C5A9122B; Fri, 20 Sep 2002 09:56:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C5979122C; Fri, 20 Sep 2002 09:56:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 33C509122B for <[e-mail]>; Fri, 20 Sep 2002 09:56:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0DF045E2DD; Fri, 20 Sep 2002 09:56:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 3678D5E2DC for <[e-mail]>; Fri, 20 Sep 2002 09:56:15 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8KDuAO99830; Fri, 20 Sep 2002 09:56:10 -0400 (EDT) (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 g8KDu7G99821; Fri, 20 Sep 2002 09:56:07 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8KDu7x18836; Fri, 20 Sep 2002 09:56:07 -0400 (EDT)
Date: Fri, 20 Sep 2002 09:56:07 -0400
From: Jeffrey Haas <[e-mail]>
To: Mareline Sheldon <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP Connections
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 Thu, Sep 19, 2002 at 08:38:41PM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Sep 19, 2002 at 08:38:41PM -0700, Mareline Sheldon wrote:
> are there any thoughts for writing a BGP spec for IPv6 which uses the IPv6 features like
> anycast, link local IP addresses, site local etc.. as of now we just use IPv4 to carry IPv6
> information. Are there any thoughts for actually running BGP over v6?

GateD and Cisco definitely interoperate using IPv6 as its networking layer.

What "features" of IPv6 were you specifically thinking of?
Anycast would be generally broken since we use a transport protocol
like TCP.
There was a link-layer peering extension proposed a while ago:
draft-kato-bgp-ipv6-link-local-01

> mareline s.

-- 
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 XAA12368 for <[e-mail]>; Thu, 19 Sep 2002 23:39:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E75D89121F; Thu, 19 Sep 2002 23:38:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B534891221; Thu, 19 Sep 2002 23:38:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C3EED9121F for <[e-mail]>; Thu, 19 Sep 2002 23:38:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8B9C95E231; Thu, 19 Sep 2002 23:38:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web20304.mail.yahoo.com (web20304.mail.yahoo.com [216.136.226.85]) by segue.merit.edu (Postfix) with SMTP id EA2BB5E22B for <[e-mail]>; Thu, 19 Sep 2002 23:38:46 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [203.200.20.226] by web20304.mail.yahoo.com via HTTP; Thu, 19 Sep 2002 20:38:41 PDT
Date: Thu, 19 Sep 2002 20:38:41 -0700 (PDT)
From: Mareline Sheldon <[e-mail]>
Subject: RE: BGP Connections
To: "Abarbanel, Benjamin" <[e-mail]>, "'Nicolas REBIERRE'" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

are there any thoughts for writing a BGP spec for IPv6 which uses the IPv6 features like
anycast, link local IP addresses, site local etc.. as of now we just use IPv4 to carry IPv6
information. Are there any thoughts for actually running BGP over v6?

just a thought .. 

mareline s.

--- "Abarbanel, Benjamin" <[e-mail]> wrote:
> Nicolas:
> 
> You comments raise interesting observations.
> 
> below
> 
> > -----Original Message-----
> > From: Nicolas REBIERRE [mailto:[e-mail]]
> > Sent: Thursday, September 19, 2002 11:56 AM
> > To: [e-mail]
> > Subject: BGP Connections
> > 
> > 
> > Hi all,
> > 
> > MP-BGP allows to advertise both IPv4 and IPv6 routes upon a TCP over
> > IPv4 connection. But shouldn't it better to have 2 distinct FSM with 2
> > TCP connections: BGP/TCP/IPv6 for IPv6 routes, BGP/TCP/IPv4 for IPv4
> > routes ? This allows to handle IPv4 and IPv6 separately. Moreover, if
> 
> Since the core/backbone network is only a IPv4 network, you will not be 
> able to setup a TCP session over IPv6 infrastructure. Most likely you will 
> use tunneling IPv6 over IPv4 or IPv6 over MPLS/IPv4 to propagate the IPv6
> routing information.  I think the goal now is to pass exterior IPv6 (island)
> clouds information through a core IPv4 backbone. When the core is a true 
> IPv6 topology your point makes sense.
> 
> > there is only one BGP/TCP/IPv4 connection for both kind of routes, a
> > problem on IPv6 connectivity will not be detected.
> > 
> True, that is the drawback of the current (temporary) solution. 
> 
> > So If one wants to receive both IPv4 and IPv6 routes from a dual stack
> > peer, could we impose to configure two connections to that peer,
> > one for IPv4 and onother one for IPv6.
> Not possible with current specs that I have seen.
> 
> > Could this restriction cause interoperability problems with some
> > implementations ?
> Maybe, can you be more specific what you are thinking of?
> 
> Ben 


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.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 SAA01559 for <[e-mail]>; Thu, 19 Sep 2002 18:31:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CB1E09120A; Thu, 19 Sep 2002 18:30:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D97A91211; Thu, 19 Sep 2002 18:30:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD7479120A for <[e-mail]>; Thu, 19 Sep 2002 18:30:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2E5005E1D9; Thu, 19 Sep 2002 18:30:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from syd01rly001.ad.powertel.com.au (webmail.powertel.com.au [202.92.123.72]) by segue.merit.edu (Postfix) with ESMTP id 0FFBF5DDBA for <[e-mail]>; Thu, 19 Sep 2002 18:30:09 -0400 (EDT)
Received: from syd01exc001.ad.powertel.com.au (unverified) by syd01rly001.ad.powertel.com.au (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]>; Fri, 20 Sep 2002 08:30:07 +1000
Received: by syd01exc001.ad.powertel.com.au with Internet Mail Service (5.5.2653.19) id <RK4NG4XX>; Fri, 20 Sep 2002 08:30:07 +1000
Message-ID: <[e-mail]>
From: Jason Sinclair <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "'Mareline Sheldon'" <[e-mail]>, [e-mail]
Subject: RE: Multiple BGP Process
Date: Fri, 20 Sep 2002 08:30:05 +1000
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

On the other hand Cisco does allow for the concept of multiple BGP peer ID's
if this serves the purpose you require.

Jason Sinclair CCIE #9100
Manager, Network Control Centre
POWERTEL
55 Clarence Street, 
SYDNEY NSW 2000 
AUSTRALIA
office: + 61 2 8264 3820
mobile: + 61 416 105 858
email: [e-mail]

 -----Original Message-----
From: 	Natale, Jonathan [mailto:[e-mail]] 
Sent:	Thursday, 19 September 2002 21:45
To:	'Mareline Sheldon'; [e-mail]
Subject:	RE: Multiple BGP Process

Crisco does not support it, not sure about Juniper.  Is there a need for it?

-----Original Message-----
From: Mareline Sheldon [mailto:[e-mail]] 
Sent: Thursday, September 19, 2002 3:14 AM
To: [e-mail]
Subject: Multiple BGP Process

Hi,
Do we have this concept of running multiple BGP processes on a signle
router? I could not find
any literature on the net and will appreciate if anybody could give me some
pointers to it. Is
there any need for that?

Thanks,
mareline s.

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com


**********************************************************************
PowerTel Limited, winners of
Broadband Wholesale Carrier of the year, CommsWorld Telecomms Awards 2001
Best Emerging Telco, Australian Telecom Awards 2001

**********************************************************************
This email (including all attachments) is intended solely for the named
addressee. It is confidential and may contain commercially sensitive
information. If you receive it in error, please let us know by reply email,
delete it from your system and destroy any copies.

This email is also subject to copyright. No part of it should be reproduced,
adapted or transmitted without the prior written consent of the copyright owner.

Emails may be interfered with, may contain computer viruses or other defects
and may not be successfully replicated on other systems. We give no
warranties in relation to these matters. If you have any doubts about
the authenticity of an email purportedly sent by us, please contact us
immediately.

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



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA22103 for <[e-mail]>; Thu, 19 Sep 2002 14:10:27 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E16DE912AD; Thu, 19 Sep 2002 14:10:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A289912AF; Thu, 19 Sep 2002 14:10:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1000A912AD for <[e-mail]>; Thu, 19 Sep 2002 14:10:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F1E025E183; Thu, 19 Sep 2002 14:10:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 290035DDB4 for <[e-mail]>; Thu, 19 Sep 2002 14:10:05 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8JIA1D76150; Thu, 19 Sep 2002 14:10:01 -0400 (EDT) (envelope-from [e-mail])
Received: from SKHtemp.nexthop.com ([192.168.173.232]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g8JI9vG76139; Thu, 19 Sep 2002 14:09:57 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 19 Sep 2002 14:14:14 -0400
To: [e-mail]
From: Susan Hares <[e-mail]>
Subject: Warning machine crash
Cc: Yakov Rekhter <[e-mail]>, [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

idr group:

My laptop where I read mail lost a hard drive in
a fairly fun way (lots of heat).  My sys-admins cannot
rapidly recover information that was lost.  Could
people who sent me private emails from 9/5 to 9/18?

I would really appreciate if you sent me a private
email about the FSM that you resend that email.


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 MAA17826 for <[e-mail]>; Thu, 19 Sep 2002 12:18:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1758A912A9; Thu, 19 Sep 2002 12:18:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD180912AA; Thu, 19 Sep 2002 12:18:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 91A89912A9 for <[e-mail]>; Thu, 19 Sep 2002 12:17:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 71A035E15D; Thu, 19 Sep 2002 12:17:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id E6A095E15C for <[e-mail]>; Thu, 19 Sep 2002 12:17:50 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA23272; Thu, 19 Sep 2002 12:17:48 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA24249; Thu, 19 Sep 2002 12:17:49 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7BTKD>; Thu, 19 Sep 2002 12:17:48 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Nicolas REBIERRE'" <[e-mail]>, [e-mail]
Subject: RE: BGP Connections
Date: Thu, 19 Sep 2002 12:17:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Nicolas:

You comments raise interesting observations.

below

> -----Original Message-----
> From: Nicolas REBIERRE [mailto:[e-mail]]
> Sent: Thursday, September 19, 2002 11:56 AM
> To: [e-mail]
> Subject: BGP Connections
> 
> 
> Hi all,
> 
> MP-BGP allows to advertise both IPv4 and IPv6 routes upon a TCP over
> IPv4 connection. But shouldn't it better to have 2 distinct FSM with 2
> TCP connections: BGP/TCP/IPv6 for IPv6 routes, BGP/TCP/IPv4 for IPv4
> routes ? This allows to handle IPv4 and IPv6 separately. Moreover, if

Since the core/backbone network is only a IPv4 network, you will not be 
able to setup a TCP session over IPv6 infrastructure. Most likely you will 
use tunneling IPv6 over IPv4 or IPv6 over MPLS/IPv4 to propagate the IPv6
routing information.  I think the goal now is to pass exterior IPv6 (island)
clouds information through a core IPv4 backbone. When the core is a true 
IPv6 topology your point makes sense.

> there is only one BGP/TCP/IPv4 connection for both kind of routes, a
> problem on IPv6 connectivity will not be detected.
> 
True, that is the drawback of the current (temporary) solution. 

> So If one wants to receive both IPv4 and IPv6 routes from a dual stack
> peer, could we impose to configure two connections to that peer,
> one for IPv4 and onother one for IPv6.
Not possible with current specs that I have seen.

> Could this restriction cause interoperability problems with some
> implementations ?
Maybe, can you be more specific what you are thinking of?

Ben 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA17241 for <[e-mail]>; Thu, 19 Sep 2002 12:01:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3EB95912A8; Thu, 19 Sep 2002 12:00:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C41D912A9; Thu, 19 Sep 2002 12:00:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9F3D3912A8 for <[e-mail]>; Thu, 19 Sep 2002 12:00:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 370A95E155; Thu, 19 Sep 2002 12:00:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from smail2.alcatel.fr (ceg-na5.alcatel.fr [213.223.66.5]) by segue.merit.edu (Postfix) with ESMTP id 4C0935DDAA for <[e-mail]>; Thu, 19 Sep 2002 12:00:35 -0400 (EDT)
Received: from nmu.alcatel.fr (tcmh80.nmu.alcatel.fr [139.54.143.3]) by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id g8JFwOCv025474 for <[e-mail]>; Thu, 19 Sep 2002 17:58:24 +0200
Received: from nmu.alcatel.fr (hoedic [192.200.245.152]) by nmu.alcatel.fr (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id RAA25760 for <[e-mail]>; Thu, 19 Sep 2002 17:59:32 +0200 (METDST)
Message-ID: <[e-mail]>
Date: Thu, 19 Sep 2002 17:55:37 +0200
From: Nicolas REBIERRE <[e-mail]>
Organization: Alcatel
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: BGP Connections
Content-Type: multipart/mixed; boundary="------------531EAF17A2E6830814052444"
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.
--------------531EAF17A2E6830814052444
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

MP-BGP allows to advertise both IPv4 and IPv6 routes upon a TCP over
IPv4 connection. But shouldn't it better to have 2 distinct FSM with 2
TCP connections: BGP/TCP/IPv6 for IPv6 routes, BGP/TCP/IPv4 for IPv4
routes ? This allows to handle IPv4 and IPv6 separately. Moreover, if
there is only one BGP/TCP/IPv4 connection for both kind of routes, a
problem on IPv6 connectivity will not be detected.

So If one wants to receive both IPv4 and IPv6 routes from a dual stack
peer, could we impose to configure two connections to that peer,
one for IPv4 and onother one for IPv6.
Could this restriction cause interoperability problems with some
implementations ?

Kind regards,

Chris.

--------------531EAF17A2E6830814052444
Content-Type: text/x-vcard; charset=us-ascii;
 name="nicolas.rebierre.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Nicolas REBIERRE
Content-Disposition: attachment;
 filename="nicolas.rebierre.vcf"

begin:vcard 
n:REBIERRE;Nicolas
tel;fax:[phone]
tel;work:([phone]
x-mozilla-html:TRUE
org:Alcatel;CTO/Enabling Software
adr:;;Route de Nozay;Marcoussis;;91460;France
version:2.1
email;internet:[e-mail]
title:CAIPv6 Engineer
fn:Nicolas REBIERRE
end:vcard

--------------531EAF17A2E6830814052444--



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA16440 for <[e-mail]>; Thu, 19 Sep 2002 11:44:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 33D9C912A0; Thu, 19 Sep 2002 11:43:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05763912A8; Thu, 19 Sep 2002 11:43:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15F61912A0 for <[e-mail]>; Thu, 19 Sep 2002 11:43:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E22AE5E152; Thu, 19 Sep 2002 11:43:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 5B2255DDBC for <[e-mail]>; Thu, 19 Sep 2002 11:43:42 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA21389; Thu, 19 Sep 2002 11:43:40 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18440; Thu, 19 Sep 2002 11:43:40 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7BR57>; Thu, 19 Sep 2002 11:43:40 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive
Date: Thu, 19 Sep 2002 11:43:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Jeff:

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Thursday, September 19, 2002 11:25 AM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive
> 
> 
> On Wed, Sep 18, 2002 at 04:56:01PM -0400, Abarbanel, Benjamin wrote:
> > Then all other route types that win over the BGP routes in 
> the Routing table
> > should be automatically exported to BGP.
> 
> Probably the simplest way of dealing with this is dealing with
> the case when a route in LocRib and the Routing table conflict
> and the Routing Table has a non-BGP route installed in it is
> to note that (in almost all cases if not always) the route actually
> installed in the Routing Table is the one passed to Phase 3 of
> the selection process.
> 

My point is that the non-BGP route has to be configured for export to
BGP for this to be done. Sometimes it is not obvious and the operator
forgets to do so. Sometimes, he intentially does not want to do so.
Thus a potential inconsistency could occur. 

Remember non-BGP routes do not have attributes like AS-Path. If an
IGP/Static route is prefered over a IBGP route for a destination that is
outside this AS, it could create routing loops. Implying the route got
exported from EBGP to IGP by another IBGP router. Then that router flooded
this route as a regular IGP 
route to the current router, where the problem occured. Now that I have
twisted your thinking a bit, you see the problem.

> -- 
> 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 LAA15565 for <[e-mail]>; Thu, 19 Sep 2002 11:25:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 74A209120F; Thu, 19 Sep 2002 11:25:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 32412912A8; Thu, 19 Sep 2002 11:25:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 23FE29120F for <[e-mail]>; Thu, 19 Sep 2002 11:25:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0A7A25E155; Thu, 19 Sep 2002 11:25:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 34B915E150 for <[e-mail]>; Thu, 19 Sep 2002 11:25:18 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8JFPG370507; Thu, 19 Sep 2002 11:25:16 -0400 (EDT) (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 g8JFPDG70500; Thu, 19 Sep 2002 11:25:13 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8JFPDV15325; Thu, 19 Sep 2002 11:25:13 -0400 (EDT)
Date: Thu, 19 Sep 2002 11:25:13 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive
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 Wed, Sep 18, 2002 at 04:56:01PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 18, 2002 at 04:56:01PM -0400, Abarbanel, Benjamin wrote:
> Then all other route types that win over the BGP routes in the Routing table
> should be automatically exported to BGP.

Probably the simplest way of dealing with this is dealing with
the case when a route in LocRib and the Routing table conflict
and the Routing Table has a non-BGP route installed in it is
to note that (in almost all cases if not always) the route actually
installed in the Routing Table is the one passed to Phase 3 of
the selection process.

-- 
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 LAA14622 for <[e-mail]>; Thu, 19 Sep 2002 11:01:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BCB77912A7; Thu, 19 Sep 2002 11:01:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 842C2912A8; Thu, 19 Sep 2002 11:01:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B1A59912A7 for <[e-mail]>; Thu, 19 Sep 2002 11:01:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 55B035E151; Thu, 19 Sep 2002 11:01:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mail2.hyperchip.com (mail2.hyperchip.com [216.94.112.4]) by segue.merit.edu (Postfix) with ESMTP id E3FF55DDAA for <[e-mail]>; Thu, 19 Sep 2002 11:01:17 -0400 (EDT)
Received: from hermes.hyperchip.com ([10.0.0.12] helo=hermes.hypernet.com) by mail2.hyperchip.com with esmtp (Exim 3.22 #1) id 17s2nm-00048p-00; Thu, 19 Sep 2002 11:01:10 -0400
Received: by hermes.hyperchip.com with Internet Mail Service (5.5.2653.19) id <R95R0A6T>; Thu, 19 Sep 2002 10:58:31 -0400
Message-ID: <[e-mail]>
From: Tian Fang <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: I-D ACTION:draft-mcpherson-rfc3065bis-00.txt
Date: Thu, 19 Sep 2002 10:58:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25FED.040C7B90"
Sender: [e-mail]
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C25FED.040C7B90
Content-Type: text/plain;
	charset="iso-8859-1"

I have a question that whether MED of routes from confederation members
should be compared or not, which is not clear in both rfc3065 and the new
draft.

In bgp-4 draft 17, neighborAS(route) is used to get the neighbor AS of the
route. However, what should be returned by neighborAS() when the route
includes AS_CONFED_SEQUENCE/AS_CONFED_SET segments?

To my understanding, if AS_SET/AS_SEQUENCE exist(s) in the aspath, the first
(leftmost) AS in AS_SEQUENCE should be returned by neighborAS(), no matter
whether AS_CONFED_SEQUENCE/AS_CONFED_SET exist(s) or not. if only
AS_CONFED_SEQUENCE/AS_CONFED_SET exist(s) in the aspath, the first
(leftmost) AS in AS_CONFED_SEQUENCE should be returned by neighborAS().

If my understanding is correct, should it included in somewhere to make it
clear?

Thx.

Tian Fang


-----Original Message-----
From: Danny McPherson [mailto:[e-mail]]
Sent: Thursday, September 19, 2002 10:04 AM
To: [e-mail]
Subject: Re: I-D ACTION:draft-mcpherson-rfc3065bis-00.txt



Folks, we'd like to make this a WG document and progress it
as soon as it makes sense.  There are a number of changes 
and clarifications, many of which have been collected 
from the list.  

Please provide feedback to the authors &/or mailing list
when you get the opportunity.

Thanks!

-danny

> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 
> 	Title		: Autonomous System Confederations for BGP
> 	Author(s)	: P. Traina, D. McPherson, J. Scudder
> 	Filename	: draft-mcpherson-rfc3065bis-00.txt
> 	Pages		: 10
> 	Date		: 2002-9-18


------_=_NextPart_001_01C25FED.040C7B90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: I-D ACTION:draft-mcpherson-rfc3065bis-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I have a question that whether MED of routes from =
confederation members should be compared or not, which is not clear in =
both rfc3065 and the new draft.</FONT></P>

<P><FONT SIZE=3D2>In bgp-4 draft 17, neighborAS(route) is used to get =
the neighbor AS of the route. However, what should be returned by =
neighborAS() when the route includes AS_CONFED_SEQUENCE/AS_CONFED_SET =
segments?</FONT></P>

<P><FONT SIZE=3D2>To my understanding, if AS_SET/AS_SEQUENCE exist(s) =
in the aspath, the first (leftmost) AS in AS_SEQUENCE should be =
returned by neighborAS(), no matter whether =
AS_CONFED_SEQUENCE/AS_CONFED_SET exist(s) or not. if only =
AS_CONFED_SEQUENCE/AS_CONFED_SET exist(s) in the aspath, the first =
(leftmost) AS in AS_CONFED_SEQUENCE should be returned by =
neighborAS().</FONT></P>

<P><FONT SIZE=3D2>If my understanding is correct, should it included in =
somewhere to make it clear?</FONT>
</P>

<P><FONT SIZE=3D2>Thx.</FONT>
</P>

<P><FONT SIZE=3D2>Tian Fang</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Danny McPherson [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, September 19, 2002 10:04 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: I-D =
ACTION:draft-mcpherson-rfc3065bis-00.txt</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Folks, we'd like to make this a WG document and =
progress it</FONT>
<BR><FONT SIZE=3D2>as soon as it makes sense.&nbsp; There are a number =
of changes </FONT>
<BR><FONT SIZE=3D2>and clarifications, many of which have been =
collected </FONT>
<BR><FONT SIZE=3D2>from the list.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Please provide feedback to the authors &amp;/or =
mailing list</FONT>
<BR><FONT SIZE=3D2>when you get the opportunity.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks!</FONT>
</P>

<P><FONT SIZE=3D2>-danny</FONT>
</P>

<P><FONT SIZE=3D2>&gt; A New Internet-Draft is available from the =
on-line Internet-Drafts directories.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
Autonomous System Confederations for BGP</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : P. Traina, D. =
McPherson, J. Scudder</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-mcpherson-rfc3065bis-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
10</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Date&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
2002-9-18</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C25FED.040C7B90--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA14265 for <[e-mail]>; Thu, 19 Sep 2002 10:53:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 437F6912A5; Thu, 19 Sep 2002 10:53:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08DE9912A6; Thu, 19 Sep 2002 10:53:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E2F04912A5 for <[e-mail]>; Thu, 19 Sep 2002 10:53:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BB23E5DF3D; Thu, 19 Sep 2002 10:53:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id E26FC5DDAA for <[e-mail]>; Thu, 19 Sep 2002 10:53:24 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8JErLB69483; Thu, 19 Sep 2002 10:53:21 -0400 (EDT) (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 g8JErIG69476; Thu, 19 Sep 2002 10:53:18 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8JErIF14987; Thu, 19 Sep 2002 10:53:18 -0400 (EDT)
Date: Thu, 19 Sep 2002 10:53:18 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Mareline Sheldon'" <[e-mail]>, [e-mail]
Subject: Re: Multiple BGP Process
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, Sep 19, 2002 at 07:45:25AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Sep 19, 2002 at 07:45:25AM -0400, Natale, Jonathan wrote:
> Crisco does not support it, not sure about Juniper.  Is there a need for it?

I'd say no, despite what implementations do.
(What about VRF instances?)

After all, its just multiple instances of the bgp spec - nothing fancy
needed.  The rest are implementation details.

-- 
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 KAA12343 for <[e-mail]>; Thu, 19 Sep 2002 10:08:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C886A91296; Thu, 19 Sep 2002 10:08:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92035912A1; Thu, 19 Sep 2002 10:08:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A4CBE91296 for <[e-mail]>; Thu, 19 Sep 2002 10:08:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 81DFC5DE1D; Thu, 19 Sep 2002 10:08:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id E8A6E5DDAA for <[e-mail]>; Thu, 19 Sep 2002 10:08:06 -0400 (EDT)
Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g8JE3sg23078 for <[e-mail]>; Thu, 19 Sep 2002 08:03:54 -0600
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
To: [e-mail]
From: Danny McPherson <[e-mail]>
Reply-To: [e-mail]
Subject: Re: I-D ACTION:draft-mcpherson-rfc3065bis-00.txt 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 19 Sep 2002 08:03:53 -0600
Sender: [e-mail]
Precedence: bulk

Folks, we'd like to make this a WG document and progress it
as soon as it makes sense.  There are a number of changes 
and clarifications, many of which have been collected 
from the list.  

Please provide feedback to the authors &/or mailing list
when you get the opportunity.

Thanks!

-danny

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Autonomous System Confederations for BGP
> 	Author(s)	: P. Traina, D. McPherson, J. Scudder
> 	Filename	: draft-mcpherson-rfc3065bis-00.txt
> 	Pages		: 10
> 	Date		: 2002-9-18



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA07602 for <[e-mail]>; Thu, 19 Sep 2002 08:00:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EAF5D91296; Thu, 19 Sep 2002 07:59:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B26BF912A0; Thu, 19 Sep 2002 07:59:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 69DB391296 for <[e-mail]>; Thu, 19 Sep 2002 07:59:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5013D5DF2B; Thu, 19 Sep 2002 07:59:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web11106.mail.yahoo.com (web11106.mail.yahoo.com [216.136.131.153]) by segue.merit.edu (Postfix) with SMTP id BBE855DDAA for <[e-mail]>; Thu, 19 Sep 2002 07:59:19 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [202.140.142.131] by web11106.mail.yahoo.com via HTTP; Thu, 19 Sep 2002 04:59:19 PDT
Date: Thu, 19 Sep 2002 04:59:19 -0700 (PDT)
From: Sivananda Ramnath <[e-mail]>
Subject: RE: Multiple BGP Process
To: [e-mail]
Cc: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Hello,

    Are you referring to this in the context of
virtual routers, or are you planning to actually run
multiple processes in a single router (like with OSPF)
?

   Could you explain why you would like to do the
latter ? It seems to me that this would be useful for
either

   a) Controlling distribution of routes
   b) Migration (from one AS number to another, or
merging 2 ASs)

   a) can be achieved through route maps and policies,
and perhaps using communities as well.
   b) is already possible, like in the way Cisco does
this.

   I hope I understood your question correctly.

Sivanand
([e-mail])

> -----Original Message-----
> From: Mareline Sheldon [mailto:[e-mail]]
> Sent: Thursday, September 19, 2002 12:44 PM
> To: [e-mail]
> Subject: Multiple BGP Process
> 
> 
> Hi,
> Do we have this concept of running multiple BGP
processes on 
> a signle router? I could not find
> any literature on the net and will appreciate if
anybody 
> could give me some pointers to it. Is
> there any need for that?
> 
> Thanks,
> mareline s.


__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.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 HAA07214 for <[e-mail]>; Thu, 19 Sep 2002 07:48:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 96F1C912A1; Thu, 19 Sep 2002 07:48:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 17FC191296; Thu, 19 Sep 2002 07:48:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3EAEC912A1 for <[e-mail]>; Thu, 19 Sep 2002 07:48:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 256505DF2B; Thu, 19 Sep 2002 07:48:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 9DBC85DDAA for <[e-mail]>; Thu, 19 Sep 2002 07:48:00 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00384; Thu, 19 Sep 2002 07:46:12 -0400 (EDT)
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-mcpherson-rfc3065bis-00.txt
Date: Thu, 19 Sep 2002 07:46:11 -0400
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Autonomous System Confederations for BGP
	Author(s)	: P. Traina, D. McPherson, J. Scudder
	Filename	: draft-mcpherson-rfc3065bis-00.txt
	Pages		: 10
	Date		: 2002-9-18
	
The Border Gateway Protocol (BGP) is an inter-autonomous system
routing protocol designed for Transmission Control Protocol/Internet
Protocol (TCP/IP) networks.  BGP requires that all BGP speakers
within a single autonomous system (AS) must be fully meshed.  This
represents a serious scaling problem that has been well documented in
a number of proposals.
This document describes an extension to BGP which may be used to
create a confederation of autonomous systems that is represented as a
single autonomous system to BGP peers external to the confederation,
thereby removing the 'full mesh' requirement.  The intention of this
extension is to aid in policy administration and reduce the
management complexity of maintaining a large autonomous system.

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-mcpherson-rfc3065bis-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 HAA07154 for <[e-mail]>; Thu, 19 Sep 2002 07:46:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BB4C791254; Thu, 19 Sep 2002 07:45:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CB7491296; Thu, 19 Sep 2002 07:45:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 31CFF91254 for <[e-mail]>; Thu, 19 Sep 2002 07:45:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DBC725DF2B; Thu, 19 Sep 2002 07:45:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 396A35DDAA for <[e-mail]>; Thu, 19 Sep 2002 07:45:31 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1GTQ9>; Thu, 19 Sep 2002 07:45:30 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Mareline Sheldon'" <[e-mail]>, [e-mail]
Subject: RE: Multiple BGP Process
Date: Thu, 19 Sep 2002 07:45:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Crisco does not support it, not sure about Juniper.  Is there a need for it?

-----Original Message-----
From: Mareline Sheldon [mailto:[e-mail]] 
Sent: Thursday, September 19, 2002 3:14 AM
To: [e-mail]
Subject: Multiple BGP Process

Hi,
Do we have this concept of running multiple BGP processes on a signle
router? I could not find
any literature on the net and will appreciate if anybody could give me some
pointers to it. Is
there any need for that?

Thanks,
mareline s.

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.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 HAA07024 for <[e-mail]>; Thu, 19 Sep 2002 07:42:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 45ABB91201; Thu, 19 Sep 2002 07:42:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B69491254; Thu, 19 Sep 2002 07:42:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BA7C091201 for <[e-mail]>; Thu, 19 Sep 2002 07:42:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9F83A5DF2B; Thu, 19 Sep 2002 07:42:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 561765DDAA for <[e-mail]>; Thu, 19 Sep 2002 07:42:11 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1GTQT>; Thu, 19 Sep 2002 07:42:10 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail] '" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive
Date: Thu, 19 Sep 2002 07:42:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

How about:
"To characterize the set of policy decisions that can be enforced
using BGP, one must focus on the rule that a BGP speaker may advertise
to other BGP speakers only those prefixes that are eligible for use by
itself - whether or not to require the prefixes actually be used itself
based on some priority mechanism for choosing routes from independent
routing processes MAY be an administratively configurable option [N]."
...
[N] RFC1812


-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Saturday, September 14, 2002 12:06 PM
To: 'Natale, Jonathan '; '[e-mail] '
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive

Jonathan:
  I did raise this issue before several days ago, the case that BGP only
advertises IBGP/EBGP routes to its peers, but sometimes a better route,
say IGP or static is used for forwarding. Thus making the statement not
totally true. We suggested that the statement be revised to imply that 
reachability of these routes are gauranteed by the BGP speaker not their
implied "use" in the forwarding table.

Thanks,
Ben

-----Original Message-----
From: Natale, Jonathan
To: [e-mail]
Sent: 9/13/02 6:42 PM
Subject: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive

I propose changing:
"To characterize the set of policy decisions that can be enforced
   using BGP, one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with) in
   neighboring ASs only those routes that it itself uses."

To:
"To characterize the set of policy decisions that can be enforced
   using BGP, one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with)
   only those prefixes that it itself uses. Whether or not to require
the
prefixes be used itself by virtue of a bgp learned route MAY be an
administratively configurable option."

Since:
1) This rule applies to IBGP as well as to EBGP. 
2) The prefix need not necessarily be in the local routing table via
bgp.
3) Juniper has a advertise inactive concept, Cisco does not.
4) The term route (vs prefix) is defined to include the attributes which
means that Cisco is non-compliant (in that it will advertise a route if
the
route's prefix is installed via another protocol), and juniper may be
configured to be non-compliant (turning off advertise inactive).


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA27546 for <[e-mail]>; Thu, 19 Sep 2002 03:14:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A70DA9124C; Thu, 19 Sep 2002 03:14:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E58A91254; Thu, 19 Sep 2002 03:14:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E0DB9124C for <[e-mail]>; Thu, 19 Sep 2002 03:14:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1F3EE5E13F; Thu, 19 Sep 2002 03:14:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web20301.mail.yahoo.com (web20301.mail.yahoo.com [216.136.226.82]) by segue.merit.edu (Postfix) with SMTP id BF8685E127 for <[e-mail]>; Thu, 19 Sep 2002 03:14:24 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [203.200.20.226] by web20301.mail.yahoo.com via HTTP; Thu, 19 Sep 2002 00:14:24 PDT
Date: Thu, 19 Sep 2002 00:14:24 -0700 (PDT)
From: Mareline Sheldon <[e-mail]>
Subject: Multiple BGP Process
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Hi,
Do we have this concept of running multiple BGP processes on a signle router? I could not find
any literature on the net and will appreciate if anybody could give me some pointers to it. Is
there any need for that?

Thanks,
mareline s.

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.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 UAA11905 for <[e-mail]>; Wed, 18 Sep 2002 20:04:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B10949120C; Wed, 18 Sep 2002 20:04:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CF1891210; Wed, 18 Sep 2002 20:04:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A68349120C for <[e-mail]>; Wed, 18 Sep 2002 20:04:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8F3D25E0F9; Wed, 18 Sep 2002 20:04:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 814E75DDBE for <[e-mail]>; Wed, 18 Sep 2002 20:04:04 -0400 (EDT)
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 UAA34195; Wed, 18 Sep 2002 20:02:01 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'Natale,     Jonathan '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
In-reply-to: Your message of "Wed, 18 Sep 2002 16:56:01 EDT." <[e-mail]> 
Date: Wed, 18 Sep 2002 20:02:01 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> Comments below
> 
> Ben
> 
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:[e-mail]]
> > Sent: Wednesday, September 18, 2002 3:49 PM
> > To: Abarbanel, Benjamin
> > Cc: 'Natale, Jonathan '; '[e-mail] '
> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
> > 
> > 
> > 
> > In message 
> > <[e-mail]>, 
> > "Abarbanel, Benjamin" writes:
> > > Jonathan:
> > >   I did raise this issue before several days ago, the case 
> > that BGP only
> > > advertises IBGP/EBGP routes to its peers, but sometimes a 
> > better route,
> > > say IGP or static is used for forwarding. Thus making the 
> > statement not
> > > totally true. We suggested that the statement be revised to 
> > imply that 
> > > reachability of these routes are gauranteed by the BGP 
> > speaker not their
> > > implied "use" in the forwarding table.
> > > 
> > > Thanks,
> > > Ben
> > 
> > 
> > Ben, Jonathan,
> > 
> > If an IGP route is used for forwarding, it should be exported to BGP
> > and that route advertised in which case it would get the origin IGP
> > and one AS in the AS path.  [If an IGP route is used simply to resolve
> > the next-hop, that doesn't count, but I think you knew that since your
> > comments don't imply the opposite.]  Using one route but advertising a
> > route learned by another means is a violation of the protocol spec.
> > Even in the case of virtual routing tables for VPNs, each route is in
> > effect "used" but in a limited context and advertising the route to
> > some other context where it is not used would generally not be a good
> > idea.
> > 
> Then all other route types that win over the BGP routes in the Routing table
> should be automatically exported to BGP. The problem is most vendors I know
> off, make it a configuration option that might not be enabled and thus open
> the door to a potential route use and advertise inconsistency.   
> 
> Maybe we need to add a sentence about this point somewhere (how aboute
> RFC1772)?


The text says you can't advertise routes you don't use.  It does not
say you must advertise all of the routes you use.


> > Router vendors have provided knobs to allow the providers to violate
> > the specs.  If one router vendor does it and one large enough customer
> > uses it, chances are another router vendor will follow suit, whether
> > it is a good practice or not.
> > 
> > One case that I am aware of where such a violation occurs is
> > advertising the route to an exchange point.  There is often no peering
> > with the exchange point provider but the exchange point provider
> > sometimes gets an AS number.  The shared address of the exchange point
> > itself is advertised into IBGP (and sometimes to EBGP) and that
> > advertisement is in turn advertised out to EBGP even though the IGP
> > route is used.
> > 
> > Another case is where singly homed sites appear as both static routes
> > injected into IBGP and as IGP routes.  Configurations are set so that
> > the IBGP route is preferred by BGP so BGP communities attached to the
> > route can be respected.  It should be possible to suppress injecting
> > the static into the IGP, leaving only an IBGP route to the router to
> > which the static is attached, removing the moral dilema on other
> > routers of which route to advertise to EBGP peers.  But it doesn't
> > actually make any real difference, so it is usually just passed into
> > the IGP as well.
> > 
> > In some cases the IGP might yield a different next-hop if two routers
> > share a prefix advertised into BGP to get communities, and advertised
> > into the IGP by more than one router.  This would be the case if the
> > IGP cost to the shared prefix was different (the closest advertiser is
> > not the best route).
> > 
> > If this is done, and done wrong or right, there is no interoperability
> > problem.  If configured sufficiently wrong, there may be a black hole
> > or route loop.  Given the guidlelines that Alex just sent out (or
> > replied to), there is no reason to put this in the BGP spec.
> > 
> > When usage sometimes deviates from the spec, and in some cases from
> > safe practices, this can be documented in the applicability statement
> > which is currently rfc1772 and needs a lot of work.  [Aside: I don't
> > know of any usage that could not be accommodated without violating the
> > spec.  If someone does then it would be useful to document it in the
> > applicability statemen, not the protocol spec.  The usages seem to
> > fall into affecting route preference independently of the BGP route
> > which carries BGP communities needed for export.]
> > 
> > The text cited below is in a paragraph that is essentially saying BGP
> > can support IP style forwarding but can't turn IP into NIMROD (or ERP
> > given the time that this paragraph was written).  This is introductory
> > text, and we may be arguing about its precision with regard to some
> > issue tangential to the context of the paragraph in which the
> > statement appears.  Regardless, dropping the "in neighboring ASs" for
> > the reason you've cited is fine.  [Now lets move on to page 
> > 3...  :-) ]
> > 
> > Curtis
> > 
> > ps - there is some confusion below regarding the term route.  An OSPF
> > route is a route.  A BGP route is a route.  A route has iformation
> > other than the prefix.  It is possible to convert a route of one type
> > into a route of another type, or convert any (useful) route into a
> > forwarding entry.  There is no problem with the use of the word route
> > below.
> 
> But sometimes when you convert route type A to type B you might loose A's
> attributes, such when its converted back to A, it is less informative. Also,
> that is why people might not want to redistribute between protocols too
> much.


Conversion between route types does lose information.  Are you arguing
with the definition of route on this basis?  I don't see what point
you are trying to make.


> Ben

Curtis


> > > -----Original Message-----
> > > From: Natale, Jonathan
> > > To: [e-mail]
> > > Sent: 9/13/02 6:42 PM
> > > Subject: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive
> > > 
> > > I propose changing:
> > > "To characterize the set of policy decisions that can be enforced
> > >    using BGP, one must focus on the rule that a BGP speaker 
> > advertises
> > >    to its peers (other BGP speakers which it communicates with) in
> > >    neighboring ASs only those routes that it itself uses."
> > > 
> > > To:
> > > "To characterize the set of policy decisions that can be enforced
> > >    using BGP, one must focus on the rule that a BGP speaker 
> > advertises
> > >    to its peers (other BGP speakers which it communicates with)
> > >    only those prefixes that it itself uses. Whether or not 
> > to require
> > > the
> > > prefixes be used itself by virtue of a bgp learned route MAY be an
> > > administratively configurable option."
> > > 
> > > Since:
> > > 1) This rule applies to IBGP as well as to EBGP. 
> > > 2) The prefix need not necessarily be in the local routing table via
> > > bgp.
> > > 3) Juniper has a advertise inactive concept, Cisco does not.
> > > 4) The term route (vs prefix) is defined to include the 
> > attributes which
> > > means that Cisco is non-compliant (in that it will 
> > advertise a route if
> > > the
> > > route's prefix is installed via another protocol), and 
> > juniper may be
> > > configured to be non-compliant (turning off advertise inactive).
> > > 
> > > 
> > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA09028 for <[e-mail]>; Wed, 18 Sep 2002 18:40:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 987E69124C; Wed, 18 Sep 2002 18:39:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6434D91253; Wed, 18 Sep 2002 18:39:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 151AE9124C for <[e-mail]>; Wed, 18 Sep 2002 18:39:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EF6C25E0F7; Wed, 18 Sep 2002 18:39:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 0301B5DE39 for <[e-mail]>; Wed, 18 Sep 2002 18:39:38 -0400 (EDT)
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 SAA33578; Wed, 18 Sep 2002 18:37:38 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "David Waters" <[e-mail]>
Cc: "Yakov Rekhter" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: rfc1745 (was Re: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt)
In-reply-to: Your message of "Wed, 18 Sep 2002 10:10:32 +0530." <011a01c25ecd$896cf100$[e-mail]> 
Date: Wed, 18 Sep 2002 18:37:38 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <011a01c25ecd$896cf100$[e-mail]>, "David Waters" writ
es:
> anybody has any idea as to why the BGP-OSPF RFC is now historical and why
> it isnt being deployed anywhere?
> 
> - David


RFC1745 is historic because:

  The AS path frequently didn't fit into the tags and truncating AS
  path is harmfull (can cause route loops).

  Networks tended to blow up in a spectacular manner when injecting
  10s or thousands of BGP routes into the IGP back when people
  actually tried doing this.  There have also been spectacular network
  failures due to accidentally injecting BGP into the IGP.

Or more briefly -- its use is considered dangerous.

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 SAA07776 for <[e-mail]>; Wed, 18 Sep 2002 18:01:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1D35C912A0; Wed, 18 Sep 2002 18:00:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DEE55912A1; Wed, 18 Sep 2002 18:00:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7391A912A0 for <[e-mail]>; Wed, 18 Sep 2002 18:00:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E89345DF7E; Wed, 18 Sep 2002 18:00:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 8B7C45E0BC for <[e-mail]>; Wed, 18 Sep 2002 18:00:51 -0400 (EDT)
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 RAA33482; Wed, 18 Sep 2002 17:58:49 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "David Waters" <[e-mail]>
Cc: [e-mail]
Reply-To: [e-mail]
Subject: Re: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt 
In-reply-to: Your message of "Tue, 17 Sep 2002 18:54:45 +0530." <03b401c25e4d$9b8ce4b0$[e-mail]> 
Date: Wed, 18 Sep 2002 17:58:49 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <03b401c25e4d$9b8ce4b0$[e-mail]>, "David Waters" writ
es:
> Hello,
> I have always been slightly disturbed with this terminology used in BGP i.e
> BGP ID. Why cant we like all the other protocols use the term Router ID?
> Can it be mentioned explicitly in this document that the BGP ID is nothing
> but a Router ID. I gather that it is painfully obvious to the people really
> conversant with BGP but it is not so with the newbies !
> 
> I had struggled during my initial days with the protocol and i find that
> more and more people get confused with this BGP ID. Is there any thought in
> the IDR WG to look into this issue.
> 
> David.


We coincidentally just went through a long discussion (in the context
of reviewing dir-bgp4-17) about when the BGP ID is not equal to the
Router ID used by the IGP.  The fact that BGP ID can be (but usually
isn't) different from Router ID is why the term BGP ID is used.

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 QAA05479 for <[e-mail]>; Wed, 18 Sep 2002 16:56:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2A5AC91296; Wed, 18 Sep 2002 16:56:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA0AA9129E; Wed, 18 Sep 2002 16:56:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A543691296 for <[e-mail]>; Wed, 18 Sep 2002 16:56:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7DBBC5DF08; Wed, 18 Sep 2002 16:56:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id F38315DED6 for <[e-mail]>; Wed, 18 Sep 2002 16:56:09 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA15469; Wed, 18 Sep 2002 16:56:06 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA19659; Wed, 18 Sep 2002 16:56:08 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7AK7T>; Wed, 18 Sep 2002 16:56:07 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Natale, Jonathan '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
Date: Wed, 18 Sep 2002 16:56:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Comments below

Ben

> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Wednesday, September 18, 2002 3:49 PM
> To: Abarbanel, Benjamin
> Cc: 'Natale, Jonathan '; '[e-mail] '
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
> 
> 
> 
> In message 
> <[e-mail]>, 
> "Abarbanel, Benjamin" writes:
> > Jonathan:
> >   I did raise this issue before several days ago, the case 
> that BGP only
> > advertises IBGP/EBGP routes to its peers, but sometimes a 
> better route,
> > say IGP or static is used for forwarding. Thus making the 
> statement not
> > totally true. We suggested that the statement be revised to 
> imply that 
> > reachability of these routes are gauranteed by the BGP 
> speaker not their
> > implied "use" in the forwarding table.
> > 
> > Thanks,
> > Ben
> 
> 
> Ben, Jonathan,
> 
> If an IGP route is used for forwarding, it should be exported to BGP
> and that route advertised in which case it would get the origin IGP
> and one AS in the AS path.  [If an IGP route is used simply to resolve
> the next-hop, that doesn't count, but I think you knew that since your
> comments don't imply the opposite.]  Using one route but advertising a
> route learned by another means is a violation of the protocol spec.
> Even in the case of virtual routing tables for VPNs, each route is in
> effect "used" but in a limited context and advertising the route to
> some other context where it is not used would generally not be a good
> idea.
> 
Then all other route types that win over the BGP routes in the Routing table
should be automatically exported to BGP. The problem is most vendors I know
off, make it a configuration option that might not be enabled and thus open
the door to a potential route use and advertise inconsistency.   

Maybe we need to add a sentence about this point somewhere (how aboute
RFC1772)?

> Router vendors have provided knobs to allow the providers to violate
> the specs.  If one router vendor does it and one large enough customer
> uses it, chances are another router vendor will follow suit, whether
> it is a good practice or not.
> 
> One case that I am aware of where such a violation occurs is
> advertising the route to an exchange point.  There is often no peering
> with the exchange point provider but the exchange point provider
> sometimes gets an AS number.  The shared address of the exchange point
> itself is advertised into IBGP (and sometimes to EBGP) and that
> advertisement is in turn advertised out to EBGP even though the IGP
> route is used.
> 
> Another case is where singly homed sites appear as both static routes
> injected into IBGP and as IGP routes.  Configurations are set so that
> the IBGP route is preferred by BGP so BGP communities attached to the
> route can be respected.  It should be possible to suppress injecting
> the static into the IGP, leaving only an IBGP route to the router to
> which the static is attached, removing the moral dilema on other
> routers of which route to advertise to EBGP peers.  But it doesn't
> actually make any real difference, so it is usually just passed into
> the IGP as well.
> 
> In some cases the IGP might yield a different next-hop if two routers
> share a prefix advertised into BGP to get communities, and advertised
> into the IGP by more than one router.  This would be the case if the
> IGP cost to the shared prefix was different (the closest advertiser is
> not the best route).
> 
> If this is done, and done wrong or right, there is no interoperability
> problem.  If configured sufficiently wrong, there may be a black hole
> or route loop.  Given the guidlelines that Alex just sent out (or
> replied to), there is no reason to put this in the BGP spec.
> 
> When usage sometimes deviates from the spec, and in some cases from
> safe practices, this can be documented in the applicability statement
> which is currently rfc1772 and needs a lot of work.  [Aside: I don't
> know of any usage that could not be accommodated without violating the
> spec.  If someone does then it would be useful to document it in the
> applicability statemen, not the protocol spec.  The usages seem to
> fall into affecting route preference independently of the BGP route
> which carries BGP communities needed for export.]
> 
> The text cited below is in a paragraph that is essentially saying BGP
> can support IP style forwarding but can't turn IP into NIMROD (or ERP
> given the time that this paragraph was written).  This is introductory
> text, and we may be arguing about its precision with regard to some
> issue tangential to the context of the paragraph in which the
> statement appears.  Regardless, dropping the "in neighboring ASs" for
> the reason you've cited is fine.  [Now lets move on to page 
> 3...  :-) ]
> 
> Curtis
> 
> ps - there is some confusion below regarding the term route.  An OSPF
> route is a route.  A BGP route is a route.  A route has iformation
> other than the prefix.  It is possible to convert a route of one type
> into a route of another type, or convert any (useful) route into a
> forwarding entry.  There is no problem with the use of the word route
> below.

But sometimes when you convert route type A to type B you might loose A's
attributes, such when its converted back to A, it is less informative. Also,
that is why people might not want to redistribute between protocols too
much.

Ben
> 
> 
> > -----Original Message-----
> > From: Natale, Jonathan
> > To: [e-mail]
> > Sent: 9/13/02 6:42 PM
> > Subject: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive
> > 
> > I propose changing:
> > "To characterize the set of policy decisions that can be enforced
> >    using BGP, one must focus on the rule that a BGP speaker 
> advertises
> >    to its peers (other BGP speakers which it communicates with) in
> >    neighboring ASs only those routes that it itself uses."
> > 
> > To:
> > "To characterize the set of policy decisions that can be enforced
> >    using BGP, one must focus on the rule that a BGP speaker 
> advertises
> >    to its peers (other BGP speakers which it communicates with)
> >    only those prefixes that it itself uses. Whether or not 
> to require
> > the
> > prefixes be used itself by virtue of a bgp learned route MAY be an
> > administratively configurable option."
> > 
> > Since:
> > 1) This rule applies to IBGP as well as to EBGP. 
> > 2) The prefix need not necessarily be in the local routing table via
> > bgp.
> > 3) Juniper has a advertise inactive concept, Cisco does not.
> > 4) The term route (vs prefix) is defined to include the 
> attributes which
> > means that Cisco is non-compliant (in that it will 
> advertise a route if
> > the
> > route's prefix is installed via another protocol), and 
> juniper may be
> > configured to be non-compliant (turning off advertise inactive).
> > 
> > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA04475 for <[e-mail]>; Wed, 18 Sep 2002 16:25:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D297B9129B; Wed, 18 Sep 2002 16:25:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E2C79129E; Wed, 18 Sep 2002 16:25:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 228D39129B for <[e-mail]>; Wed, 18 Sep 2002 16:25:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0AEC85E0B2; Wed, 18 Sep 2002 16:25:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 7BE9F5DE8F for <[e-mail]>; Wed, 18 Sep 2002 16:25:17 -0400 (EDT)
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 QAA33338; Wed, 18 Sep 2002 16:23:15 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Martin, Christian" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, "Natale,     Jonathan" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
In-reply-to: Your message of "Sun, 15 Sep 2002 15:14:50 EDT." <[e-mail]> 
Date: Wed, 18 Sep 2002 16:23:15 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, "Mar
tin, Christian" writes:
> Yakov,
> 	
> In both examples below, it would appear that BGP does not have the
> capability to affect asymmetric routing, which it clearly does as is
> evidenced by traffic on the Internet today.  Perhaps it would be more clear
> to use an example that is more congruent with the destination-based vs
> source-based argument you are making.
> 
> IE:
> 
>    Routing information exchanged via BGP supports only the
>    destination-based forwarding paradigm, which assumes that a
>    router forwards a packet based solely on the destination address
>    carried in the IP header of the packet. This, in turn reflects
>    the set of policy decisions that can (and can not) be enforces
>    using BGP. Note that some policies cannot be supported by the
>    destination-based forwarding paradigm and thus require techniques
>    such as source routing (aka explicit routing) to enforce. Such
>    policies can not be enforced using BGP either. For example, BGP
>    does not enable one AS to send traffic to a neighboring AS
>    based on prefixes originating from the local AS.  On the
>    other hand, BGP can support any policy conforming to the
>    destination-based forwarding paradigm.
> 
> I know this is a late change and it hasn't been addressed before, but after
> reading it in a capsule, it looks like it would be beneficial to consider
> the edit.
> 
> Thanks,
> -chris


Chris,

It would help if you mentioned that only the sentence starting with
"For example" differs.

I think Yakov's example is more clear and addresses the point of this
paragraph.  That is "IP + BGP != NIMROD (or any close relative)".

Curtis



> > So, with this in mind I would suggest to replace
> > 
> >    To characterize the set of policy decisions that can be enforced
> >    using BGP, one must focus on the rule that a BGP speaker advertises
> >    to its peers (other BGP speakers which it communicates with) in
> >    neighboring ASs only those routes that it itself uses. This rule
> >    reflects the "hop-by-hop" routing paradigm generally used
> >    throughout the current Internet. Note that some policies cannot
> >    be supported by the "hop-by-hop" routing paradigm and thus
> >    require techniques such as source routing (aka explicit routing)
> >    to enforce. For example, BGP does not enable one AS to send
> >    traffic to a neighboring AS intending that the traffic take a
> >    different route from that taken by traffic originating in the
> >    neighboring AS. On the other hand, BGP can support any policy
> >    conforming to the "hop-by-hop" routing paradigm. Since the
> >    current Internet uses only the "hop-by-hop" inter-AS routing
> >    paradigm and since BGP can support any policy that conforms to
> >    that paradigm, BGP is highly applicable as an inter-AS routing
> >    protocol for the current Internet.
> > 
> > with the following:
> > 
> >    Routing information exchanged via BGP supports only the
> >    destination-based forwarding paradigm, which assumes that a
> >    router forwards a packet based solely on the destination address
> >    carried in the IP header of the packet. This, in turn reflects
> >    the set of policy decisions that can (and can not) be enforces
> >    using BGP. Note that some policies cannot be supported by the
> >    destination-based forwarding paradigm and thus require techniques
> >    such as source routing (aka explicit routing) to enforce. Such
>    policies can not be enforced using BGP either. For example, BGP
> >    does not enable one AS to send traffic to a neighboring AS
> >    intending that the traffic take a different route from that
> >    taken by traffic originating in the neighboring AS.  On the
> >    other hand, BGP can support any policy conforming to the
> >    destination-based forwarding paradigm.
> > 
> > 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 QAA04254 for <[e-mail]>; Wed, 18 Sep 2002 16:18:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2224291209; Wed, 18 Sep 2002 16:18:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1E519129B; Wed, 18 Sep 2002 16:18:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0AC6991209 for <[e-mail]>; Wed, 18 Sep 2002 16:17:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D7CDB5DE90; Wed, 18 Sep 2002 16:17:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 616625DE8F for <[e-mail]>; Wed, 18 Sep 2002 16:17:42 -0400 (EDT)
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 QAA33319; Wed, 18 Sep 2002 16:15:42 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Tom Petch" <[e-mail]>
Cc: "idr" <[e-mail]>, "Susan Hares" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: FSM but FSM of what? 
In-reply-to: Your message of "Sun, 15 Sep 2002 11:02:09 BST." <003301c25c9f$08345cc0$0301a8c0@tom3> 
Date: Wed, 18 Sep 2002 16:15:42 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <003301c25c9f$08345cc0$0301a8c0@tom3>, "Tom Petch" writes:
> The business of what the FSM is the FSM of still nags me (I had a
> problem with it when I first read BGP-17 and to some extent still
> have).
> 
> I think it nags me most in connection collision detection.  This is
> defined (bgp-17 s6.8) as taking place between the same pair of IP
> addresses (so the TCP connections are differentiated by port numbers
> as ever).  When the FSM says the new state after a collision should be
> Idle (for the connection initiated by the lower value of BGP
> Identifier), then that only applies to this connection (uniquely
> identified by TCP protocol  and a source/destination duple of both IP
> address and port number); the winning (different port number duple)
> connection will go on to Established via OpenConfirm.
> 
> So clearly (to me) there are two FSM here, with the same pair of IP
> addresses
> but different port numbers ie we are defining the FSM of a particular
> TCP connection.


Does this clear things up at all?

   There is one FSM per 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.
   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 connection that is closed should be disposed of.


> But can that work in Idle state when we have no TCP connection, only a
> putative one.
> 
> As ever, I raise this because I believe it is worth clarifying in so
> far as we can.  IMHO, it also impacts the references to the need to
> track
> Transport Indicates while in OpenConfirm or Established.  The tracking
> is of the same IP address pair with a different port number pair in a
> (?)different FSM with the events coming from that FSM to our FSM to
> cause our FSM to revert to Idle (or not as the case may be).  And this
> is an area that grows more complex with the other drafts (currently
> out of scope); so I want an unambiguous base to work from.
> 
> We could have a single FSM catering for multiple connections but I
> think that that would be too complex to be useful.  So perhaps a
> more explicit reference to the fact that we are processing a single
> connection once that (TCP) connection has been established.
> 
> Like
> 
> "8 BGP FInite State Machine
> 
> This section specifies BGP operation - between a BGP speaker and its
> peer over a single TCP connection - in terms of a Finite State Machine
> (FSM).  Following is a brief summary ... "(as before)
> 
> Instead of just
> 
> 
> 
> "This section specifies BGP operation in terms of a Finite State
> Machine (FSM).  Following is a brief summary ... "(as before).
> 
> A month ago I would have said transport connection instead of TCP
> connection but I have been put right on that; I see BGP as TCP-based
> as far as this draft is concerned.  And transport connection does then
> make any reference to (TCP-specific) port numbers  ... err confusing?
> 
> 
> Tom Petch
> [e-mail]


I'm not sure which document containing an FSM we should be reading at
this point, but we could add the above paragraph if we need to
explicitly state that the extra connection and its FSM is disposed of
when a collision is detected.

When a TCP accept occurs, a connection is created and an FSM is
created.  Prior to the point where the peer associated with the
connection is known the FSM cannot be associated with a peer.  The
collision is a transient condition in which the rule of "one BGP
session per peer" is temporarily violated and then corrected.

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 QAA03699 for <[e-mail]>; Wed, 18 Sep 2002 16:02:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7B5519129B; Wed, 18 Sep 2002 16:01:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5107E9129F; Wed, 18 Sep 2002 16:01:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3CF4E9129B for <[e-mail]>; Wed, 18 Sep 2002 16:01:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 200015E0B7; Wed, 18 Sep 2002 16:01:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 173755DE8F for <[e-mail]>; Wed, 18 Sep 2002 16:01:56 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8IK1qr48613; Wed, 18 Sep 2002 16:01:52 -0400 (EDT) (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 g8IK1nG48606; Wed, 18 Sep 2002 16:01:49 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8IK1nT08626; Wed, 18 Sep 2002 16:01:49 -0400 (EDT)
Date: Wed, 18 Sep 2002 16:01:49 -0400
From: Jeffrey Haas <[e-mail]>
To: Sivananda Ramnath <[e-mail]>
Cc: [e-mail]
Subject: Re: IDR WG charter
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 Wed, Sep 18, 2002 at 12:51:36PM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 18, 2002 at 12:51:36PM -0700, Sivananda Ramnath wrote:
>     I went over the revised charter. I don't
> understand why the MIB needs to be updated and
> submitted as well before other areas can be worked on.

I pointed this out to our WG chairs. :-)

> My understanding to date has been that the revised MIB
> (the version 2 MIB, so to speak) is better. Is it that
> the draft MIB reflects current practice/requirements
> more than the extensible (or version 2) MIB? I would
> appreciate any clarification in this regard.

The base MIB needed to be revised to reflect proper SNMP practice,
regardless of its correctness BGP-wise.
(It mostly is correct.)

The existing MIB didn't deal with BGP extensions very well.
Plus, configurability of the protocol via the MIB was a request.

> Sivanand

-- 
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 PAA03483 for <[e-mail]>; Wed, 18 Sep 2002 15:57:21 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EF1589129E; Wed, 18 Sep 2002 15:57:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAA1A9129F; Wed, 18 Sep 2002 15:56:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 861779129E for <[e-mail]>; Wed, 18 Sep 2002 15:56:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6E5D35E0B7; Wed, 18 Sep 2002 15:56:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id B5B5C5DE8F for <[e-mail]>; Wed, 18 Sep 2002 15:56:57 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8IJutv48503; Wed, 18 Sep 2002 15:56:55 -0400 (EDT) (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 g8IJuqG48496; Wed, 18 Sep 2002 15:56:52 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g8IJuqG18578; Wed, 18 Sep 2002 15:56:52 -0400 (EDT)
Date: Wed, 18 Sep 2002 15:56:52 -0400
From: Mathew Richardson <[e-mail]>
To: Sivananda Ramnath <[e-mail]>
Cc: [e-mail]
Subject: Re: IDR WG charter
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

> Sivananda Ramnath <[e-mail]> [Wed, Sep 18, 2002 at 12:51:36PM -0700]:
>Hello,
>
>    I went over the revised charter. I don't
>understand why the MIB needs to be updated and
>submitted as well before other areas can be worked on.
>My understanding to date has been that the revised MIB
>(the version 2 MIB, so to speak) is better. Is it that
>the draft MIB reflects current practice/requirements
>more than the extensible (or version 2) MIB?

<snip>

Yes.  The old MIB is actually implemented, and deployed... the "v2" MIB
is neither.

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 PAA03442 for <[e-mail]>; Wed, 18 Sep 2002 15:56:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1A4369129B; Wed, 18 Sep 2002 15:55:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF11C9129E; Wed, 18 Sep 2002 15:55:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0EF059129B for <[e-mail]>; Wed, 18 Sep 2002 15:55:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E58FF5DF67; Wed, 18 Sep 2002 15:55:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 9C8515DE8F for <[e-mail]>; Wed, 18 Sep 2002 15:55:41 -0400 (EDT)
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 PAA33253; Wed, 18 Sep 2002 15:53:42 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
In-reply-to: Your message of "Sat, 14 Sep 2002 19:18:53 PDT." <[e-mail]> 
Date: Wed, 18 Sep 2002 15:53:42 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Yakov Rekhter writes
:
> 
> The *real* issue that the text you mentioned above is trying to
> capture (although it clearly didn't capture it well enough) is that 
> BGP is built to support the destination-based forwarding paradigm.
> 
> So, with this in mind I would suggest to replace
> 
>    To characterize the set of policy decisions that can be enforced
>    using BGP, one must focus on the rule that a BGP speaker advertises
>    to its peers (other BGP speakers which it communicates with) in
>    neighboring ASs only those routes that it itself uses. This rule
>    reflects the "hop-by-hop" routing paradigm generally used
>    throughout the current Internet. Note that some policies cannot
>    be supported by the "hop-by-hop" routing paradigm and thus
>    require techniques such as source routing (aka explicit routing)
>    to enforce. For example, BGP does not enable one AS to send
>    traffic to a neighboring AS intending that the traffic take a
>    different route from that taken by traffic originating in the
>    neighboring AS. On the other hand, BGP can support any policy
>    conforming to the "hop-by-hop" routing paradigm. Since the
>    current Internet uses only the "hop-by-hop" inter-AS routing
>    paradigm and since BGP can support any policy that conforms to
>    that paradigm, BGP is highly applicable as an inter-AS routing
>    protocol for the current Internet.
> 
> with the following:
> 
>    Routing information exchanged via BGP supports only the
>    destination-based forwarding paradigm, which assumes that a
>    router forwards a packet based solely on the destination address
>    carried in the IP header of the packet. This, in turn reflects
>    the set of policy decisions that can (and can not) be enforces
>    using BGP. Note that some policies cannot be supported by the
>    destination-based forwarding paradigm and thus require techniques
>    such as source routing (aka explicit routing) to enforce. Such
>    policies can not be enforced using BGP either. For example, BGP
>    does not enable one AS to send traffic to a neighboring AS
>    intending that the traffic take a different route from that
>    taken by traffic originating in the neighboring AS.  On the
>    other hand, BGP can support any policy conforming to the
>    destination-based forwarding paradigm.
> 
> Yakov.
> 


The replacement paragraph is much more clear.

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 PAA03310 for <[e-mail]>; Wed, 18 Sep 2002 15:52:01 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0719391296; Wed, 18 Sep 2002 15:51:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC61C9129B; Wed, 18 Sep 2002 15:51:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 83C3C91296 for <[e-mail]>; Wed, 18 Sep 2002 15:51:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 72C5D5DF67; Wed, 18 Sep 2002 15:51:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web11107.mail.yahoo.com (web11107.mail.yahoo.com [216.136.131.154]) by segue.merit.edu (Postfix) with SMTP id D9ABB5DE8F for <[e-mail]>; Wed, 18 Sep 2002 15:51:36 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [202.140.142.131] by web11107.mail.yahoo.com via HTTP; Wed, 18 Sep 2002 12:51:36 PDT
Date: Wed, 18 Sep 2002 12:51:36 -0700 (PDT)
From: Sivananda Ramnath <[e-mail]>
Subject: RE: IDR WG charter
To: [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Hello,

    I went over the revised charter. I don't
understand why the MIB needs to be updated and
submitted as well before other areas can be worked on.
My understanding to date has been that the revised MIB
(the version 2 MIB, so to speak) is better. Is it that
the draft MIB reflects current practice/requirements
more than the extensible (or version 2) MIB? I would
appreciate any clarification in this regard.

Sivanand



> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 18, 2002 8:23 PM
> To: [e-mail]
> Subject: IDR WG charter
> 
> 
> Folks,
> 
> In response to the attached I got 7 "accept" and 4
"reject".
> 
> Yakov.

__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.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 PAA03284 for <[e-mail]>; Wed, 18 Sep 2002 15:51:27 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id AC80791209; Wed, 18 Sep 2002 15:50:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73F5491296; Wed, 18 Sep 2002 15:50:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0857C91209 for <[e-mail]>; Wed, 18 Sep 2002 15:50:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E08C45DF67; Wed, 18 Sep 2002 15:50:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 1D7185DE8F for <[e-mail]>; Wed, 18 Sep 2002 15:50:53 -0400 (EDT)
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 PAA33234; Wed, 18 Sep 2002 15:48:52 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Natale, Jonathan '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
In-reply-to: Your message of "Sat, 14 Sep 2002 12:06:05 EDT." <[e-mail]> 
Date: Wed, 18 Sep 2002 15:48:52 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> Jonathan:
>   I did raise this issue before several days ago, the case that BGP only
> advertises IBGP/EBGP routes to its peers, but sometimes a better route,
> say IGP or static is used for forwarding. Thus making the statement not
> totally true. We suggested that the statement be revised to imply that 
> reachability of these routes are gauranteed by the BGP speaker not their
> implied "use" in the forwarding table.
> 
> Thanks,
> Ben


Ben, Jonathan,

If an IGP route is used for forwarding, it should be exported to BGP
and that route advertised in which case it would get the origin IGP
and one AS in the AS path.  [If an IGP route is used simply to resolve
the next-hop, that doesn't count, but I think you knew that since your
comments don't imply the opposite.]  Using one route but advertising a
route learned by another means is a violation of the protocol spec.
Even in the case of virtual routing tables for VPNs, each route is in
effect "used" but in a limited context and advertising the route to
some other context where it is not used would generally not be a good
idea.

Router vendors have provided knobs to allow the providers to violate
the specs.  If one router vendor does it and one large enough customer
uses it, chances are another router vendor will follow suit, whether
it is a good practice or not.

One case that I am aware of where such a violation occurs is
advertising the route to an exchange point.  There is often no peering
with the exchange point provider but the exchange point provider
sometimes gets an AS number.  The shared address of the exchange point
itself is advertised into IBGP (and sometimes to EBGP) and that
advertisement is in turn advertised out to EBGP even though the IGP
route is used.

Another case is where singly homed sites appear as both static routes
injected into IBGP and as IGP routes.  Configurations are set so that
the IBGP route is preferred by BGP so BGP communities attached to the
route can be respected.  It should be possible to suppress injecting
the static into the IGP, leaving only an IBGP route to the router to
which the static is attached, removing the moral dilema on other
routers of which route to advertise to EBGP peers.  But it doesn't
actually make any real difference, so it is usually just passed into
the IGP as well.

In some cases the IGP might yield a different next-hop if two routers
share a prefix advertised into BGP to get communities, and advertised
into the IGP by more than one router.  This would be the case if the
IGP cost to the shared prefix was different (the closest advertiser is
not the best route).

If this is done, and done wrong or right, there is no interoperability
problem.  If configured sufficiently wrong, there may be a black hole
or route loop.  Given the guidlelines that Alex just sent out (or
replied to), there is no reason to put this in the BGP spec.

When usage sometimes deviates from the spec, and in some cases from
safe practices, this can be documented in the applicability statement
which is currently rfc1772 and needs a lot of work.  [Aside: I don't
know of any usage that could not be accommodated without violating the
spec.  If someone does then it would be useful to document it in the
applicability statemen, not the protocol spec.  The usages seem to
fall into affecting route preference independently of the BGP route
which carries BGP communities needed for export.]

The text cited below is in a paragraph that is essentially saying BGP
can support IP style forwarding but can't turn IP into NIMROD (or ERP
given the time that this paragraph was written).  This is introductory
text, and we may be arguing about its precision with regard to some
issue tangential to the context of the paragraph in which the
statement appears.  Regardless, dropping the "in neighboring ASs" for
the reason you've cited is fine.  [Now lets move on to page 3...  :-) ]

Curtis

ps - there is some confusion below regarding the term route.  An OSPF
route is a route.  A BGP route is a route.  A route has iformation
other than the prefix.  It is possible to convert a route of one type
into a route of another type, or convert any (useful) route into a
forwarding entry.  There is no problem with the use of the word route
below.


> -----Original Message-----
> From: Natale, Jonathan
> To: [e-mail]
> Sent: 9/13/02 6:42 PM
> Subject: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive
> 
> I propose changing:
> "To characterize the set of policy decisions that can be enforced
>    using BGP, one must focus on the rule that a BGP speaker advertises
>    to its peers (other BGP speakers which it communicates with) in
>    neighboring ASs only those routes that it itself uses."
> 
> To:
> "To characterize the set of policy decisions that can be enforced
>    using BGP, one must focus on the rule that a BGP speaker advertises
>    to its peers (other BGP speakers which it communicates with)
>    only those prefixes that it itself uses. Whether or not to require
> the
> prefixes be used itself by virtue of a bgp learned route MAY be an
> administratively configurable option."
> 
> Since:
> 1) This rule applies to IBGP as well as to EBGP. 
> 2) The prefix need not necessarily be in the local routing table via
> bgp.
> 3) Juniper has a advertise inactive concept, Cisco does not.
> 4) The term route (vs prefix) is defined to include the attributes which
> means that Cisco is non-compliant (in that it will advertise a route if
> the
> route's prefix is installed via another protocol), and juniper may be
> configured to be non-compliant (turning off advertise inactive).
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA01774 for <[e-mail]>; Wed, 18 Sep 2002 15:08:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4DF499129B; Wed, 18 Sep 2002 15:07:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B8F79129D; Wed, 18 Sep 2002 15:07:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B6D7C9129B for <[e-mail]>; Wed, 18 Sep 2002 15:07:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9D69B5E0AE; Wed, 18 Sep 2002 15:07:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 1341F5DE0A for <[e-mail]>; Wed, 18 Sep 2002 15:07:40 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8IJ7cm98054; Wed, 18 Sep 2002 12:07:38 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: bgp draft review 
In-Reply-To: Your message of "Fri, 06 Sep 2002 11:08:08 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 18 Sep 2002 12:07:38 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> Somewhere it says ebgp peers must be direct, right?  

Section 5.1.3 talks about both the case where ebgp peers are 1 IP 
hop away from each other:

   2) When sending a message to an external peer X, and the peer is
      one IP hop away from the speaker:

as well as the case where they are multiple IP hops away from each
other:

   3) When sending a message to an external peer X, and the peer is
      multiple IP hops away from the speaker (aka "multihop EBGP"):

> So then ttl should be
> 1, right?  Maybe that should be added.
>
> Also, a option to allow non-direct ebgp should be added.

See above - it is multihop EBGP.

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 OAA01178 for <[e-mail]>; Wed, 18 Sep 2002 14:53:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9AC4E91279; Wed, 18 Sep 2002 14:52:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E8B19129B; Wed, 18 Sep 2002 14:52:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 051CF91279 for <[e-mail]>; Wed, 18 Sep 2002 14:52:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E200B5E0AC; Wed, 18 Sep 2002 14:52:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 9752F5DDC5 for <[e-mail]>; Wed, 18 Sep 2002 14:52:40 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1GPS5>; Wed, 18 Sep 2002 14:52:40 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'Ignas Bagdonas'" <[e-mail]>, [e-mail]
Subject: RE: NOTIFICATION message error handling. 
Date: Wed, 18 Sep 2002 14:52:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

That is fine.

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, September 18, 2002 2:31 PM
To: Natale, Jonathan
Cc: 'Ignas Bagdonas'; [e-mail]
Subject: Re: NOTIFICATION message error handling. 

Jonathan,

> I see your point, but your text seems too wordy.
> 
> What about:
> "If a speaker receives a NOTIFICATION message, and there is an error in
that
> >    message, there is unfortunately no means of reporting this error via
> >    a subsequent NOTIFICATION message."
> 
> Since throughout the doc "speaker" seems to mean local peer and "peer"
seems
> to mean remote peer.  This may be another area where consistency/
> definitions would make the doc more readable/workable.

How about the following:

    If a peer sends a NOTIFICATION message, and the receiver of the
    message detects an error in that message, the receiver can not 
    use a NOTIFICATION message to report this error back to the peer.

Yakov.

> 
> -----Original Message-----
> From: Ignas Bagdonas [mailto:[e-mail]] 
> Sent: Friday, September 13, 2002 1:28 PM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: NOTIFICATION message error handling.
> 
> 
> ,
> 
> [This is section 6.4]
> 
> > Please change"
> > "If a peer sends a NOTIFICATION message, and there is an error in that
> >    message, there is unfortunately no means of reporting this error via
> >    a subsequent NOTIFICATION message."
> >
> > To:
> > "If a peer receives a NOTIFICATION message, and there is an error in
that
> >    message, there is unfortunately no means of reporting this error via
> >    a subsequent NOTIFICATION message."
> 
> 
> I would tend to disagree - the proposed change reverses the meaning of the
> statement. It is remote peer that sends us malformed NOTIFICATION and
> cannot be informed about that.
> 
> I would suggest the following text instead:
> 
>    All errors detected while processing the NOTIFICATION message cannot be
>    indicated by sending subsequent NOTIFICATION message back to
>    originating peer, therefore there is no means of reporting NOTIFICATION
>    message processing errors. Any error, such as an unrecognized
>    Error Code or Error Subcode, should be noticed, logged locally, and
>    brought to the attention of the administration of the peer that has
>    sent the message. The means to do this, however, lies outside the scope
>    of this document.
> 
> 
> 
> Ignas
> 
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA00864 for <[e-mail]>; Wed, 18 Sep 2002 14:43:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 032B291296; Wed, 18 Sep 2002 14:43:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8F2D9129B; Wed, 18 Sep 2002 14:43:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6BCE591296 for <[e-mail]>; Wed, 18 Sep 2002 14:43:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4832D5DDC5; Wed, 18 Sep 2002 14:43:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from voruta.vu.lt (mail.vu.lt [193.219.80.13]) by segue.merit.edu (Postfix) with ESMTP id 608485E0A9 for <[e-mail]>; Wed, 18 Sep 2002 14:43:36 -0400 (EDT)
Received: from localhost (ignas@localhost) by voruta.vu.lt (8.11.1/8.11.0/VU-20001122) with ESMTP id g8IIkhR03884; Wed, 18 Sep 2002 20:46:43 +0200 (GMT)
Date: Wed, 18 Sep 2002 20:46:43 +0200 (GMT)
From: Ignas Bagdonas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, <[e-mail]>
Subject: Re: NOTIFICATION message error handling. 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

,

> How about the following:
>
>     If a peer sends a NOTIFICATION message, and the receiver of the
>     message detects an error in that message, the receiver can not
>     use a NOTIFICATION message to report this error back to the peer.

Fine with me - simple and clear


Ignas





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA00514 for <[e-mail]>; Wed, 18 Sep 2002 14:31:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 494A491293; Wed, 18 Sep 2002 14:30:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18DD691296; Wed, 18 Sep 2002 14:30:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AC14991293 for <[e-mail]>; Wed, 18 Sep 2002 14:30:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 39A4F5E0AD; Wed, 18 Sep 2002 14:30:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 630845E0AC for <[e-mail]>; Wed, 18 Sep 2002 14:30:46 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8IIUbm94524; Wed, 18 Sep 2002 11:30:37 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Ignas Bagdonas'" <[e-mail]>, [e-mail]
Subject: Re: NOTIFICATION message error handling. 
In-Reply-To: Your message of "Fri, 13 Sep 2002 14:00:21 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 18 Sep 2002 11:30:37 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> I see your point, but your text seems too wordy.
> 
> What about:
> "If a speaker receives a NOTIFICATION message, and there is an error in that
> >    message, there is unfortunately no means of reporting this error via
> >    a subsequent NOTIFICATION message."
> 
> Since throughout the doc "speaker" seems to mean local peer and "peer" seems
> to mean remote peer.  This may be another area where consistency/
> definitions would make the doc more readable/workable.

How about the following:

    If a peer sends a NOTIFICATION message, and the receiver of the
    message detects an error in that message, the receiver can not 
    use a NOTIFICATION message to report this error back to the peer.

Yakov.

> 
> -----Original Message-----
> From: Ignas Bagdonas [mailto:[e-mail]] 
> Sent: Friday, September 13, 2002 1:28 PM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: NOTIFICATION message error handling.
> 
> 
> ,
> 
> [This is section 6.4]
> 
> > Please change"
> > "If a peer sends a NOTIFICATION message, and there is an error in that
> >    message, there is unfortunately no means of reporting this error via
> >    a subsequent NOTIFICATION message."
> >
> > To:
> > "If a peer receives a NOTIFICATION message, and there is an error in that
> >    message, there is unfortunately no means of reporting this error via
> >    a subsequent NOTIFICATION message."
> 
> 
> I would tend to disagree - the proposed change reverses the meaning of the
> statement. It is remote peer that sends us malformed NOTIFICATION and
> cannot be informed about that.
> 
> I would suggest the following text instead:
> 
>    All errors detected while processing the NOTIFICATION message cannot be
>    indicated by sending subsequent NOTIFICATION message back to
>    originating peer, therefore there is no means of reporting NOTIFICATION
>    message processing errors. Any error, such as an unrecognized
>    Error Code or Error Subcode, should be noticed, logged locally, and
>    brought to the attention of the administration of the peer that has
>    sent the message. The means to do this, however, lies outside the scope
>    of this document.
> 
> 
> 
> Ignas
> 
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA29584 for <[e-mail]>; Wed, 18 Sep 2002 14:05:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 74F4E91298; Wed, 18 Sep 2002 14:04:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4290F9129B; Wed, 18 Sep 2002 14:04:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1002291298 for <[e-mail]>; Wed, 18 Sep 2002 14:04:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E736D5E09F; Wed, 18 Sep 2002 14:04:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 5B38B5E08B for <[e-mail]>; Wed, 18 Sep 2002 14:04:56 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8II4im91599; Wed, 18 Sep 2002 11:04:44 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "John G. Scudder" <[e-mail]>
Cc: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 14:51:21 EDT." <p05111a42b9a53fa2a211@[192.168.42.10]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 18 Sep 2002 11:04:44 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> At 2:43 PM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >The point is the application has to reassemble the packet, not TCP.
> 
> I think the crux of the confusion is in the use of the word "packet". 
> BGP doesn't know from packets, which have a specific network-layer 
> meaning.  It uses messages, or what some folks like to call protocol 
> data units (PDUs).
> 
> So actually, there is something to be fixed here.  In section 4.3, 
> second line of first paragraph, s/UPDATE packet/UPDATE message/. 
> That's the only misuse of "packet" I found in a quick grep of the 
> document.

Done.

yakov.


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 OAA29547 for <[e-mail]>; Wed, 18 Sep 2002 14:04:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B621191296; Wed, 18 Sep 2002 14:03:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CD4991298; Wed, 18 Sep 2002 14:03:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DFD0791296 for <[e-mail]>; Wed, 18 Sep 2002 14:03:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C1DFF5E0A9; Wed, 18 Sep 2002 14:03:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 0D0335E08B for <[e-mail]>; Wed, 18 Sep 2002 14:03:20 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8II3Iu45168; Wed, 18 Sep 2002 14:03:18 -0400 (EDT) (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 g8II3FG45159; Wed, 18 Sep 2002 14:03:15 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8II3FR04950; Wed, 18 Sep 2002 14:03:15 -0400 (EDT)
Date: Wed, 18 Sep 2002 14:03:15 -0400
From: Jeffrey Haas <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Cc: [e-mail]
Subject: Re: IDR WG charter
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 Wed, Sep 18, 2002 at 01:04:31PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Eric,

On Wed, Sep 18, 2002 at 01:04:31PM -0400, Gray, Eric wrote:
> 	You misunderstand me.  I meant we were making
> no progress toward a new charter as a result of the
> results Yakov announced.  Whether or not the fact
> that BGP is still not a full standard indicates we
> may be behind schedule is for others to decide... 

I did misunderstand you.  The only item that was contentious in
the new charter as I understood it was "finish the base bgp spec
before you do anything else".

Glad to see we're on the same page.

> Eric W. Gray

-- 
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 OAA29534 for <[e-mail]>; Wed, 18 Sep 2002 14:03:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A2D2991293; Wed, 18 Sep 2002 14:03:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C16291296; Wed, 18 Sep 2002 14:03:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D744791293 for <[e-mail]>; Wed, 18 Sep 2002 14:03:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B86975E0A7; Wed, 18 Sep 2002 14:03:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 2CC835E08B for <[e-mail]>; Wed, 18 Sep 2002 14:03:05 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8II2um91388; Wed, 18 Sep 2002 11:02:56 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "John G. Scudder" <[e-mail]>
Cc: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 12:55:16 EDT." <p05111a3bb9a523c71adf@[192.168.42.10]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 18 Sep 2002 11:02:56 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

John,

> As a general comment, if you are going to split up your remarks into 
> many tiny messages it would be very helpful if you would use 
> descriptive subjects.  Also, FYI you seem to have an off-by-one error 
> in your reading of the page numbers.
> 
> This message aggregates my replies to all your messages with the 
> subject "Review of draft-ietf-idr-bgp4-17.txt".
> 
> At 10:35 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >4. In many places in the document the term Transport Connection is used, and
> >in the FSM area the term TCP Connection is used. One generic term should be
> >used   throughout the document in case a different transport (like SCTP) is
> >used to service the BGP sessions.
> 
> As Yakov mentioned earlier, BGP is not actually 
> transport-independent.  This might equally well argue in favor of 
> dropping the "transport connection" pretense and just saying "TCP" 
> throughout (applies to the FSM too, BTW).

That seems like a reasonable suggestion.

> A future protocol based on BGP 4 might be transport independent 
> and/or run over SCTP, but I think that is far beyond our current 
> scope.

Agreed.

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 NAA27544 for <[e-mail]>; Wed, 18 Sep 2002 13:05:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A72789128B; Wed, 18 Sep 2002 13:04:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 78C309128E; Wed, 18 Sep 2002 13:04:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 17CFB9128B for <[e-mail]>; Wed, 18 Sep 2002 13:04:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E6F0C5DE07; Wed, 18 Sep 2002 13:04:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 7D15E5E08B for <[e-mail]>; Wed, 18 Sep 2002 13:04:37 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1GPBR>; Wed, 18 Sep 2002 13:04:37 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Gray, Eric" <[e-mail]>
Cc: [e-mail]
Subject: RE: IDR WG charter
Date: Wed, 18 Sep 2002 13:04:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Jeff,

	You misunderstand me.  I meant we were making
no progress toward a new charter as a result of the
results Yakov announced.  Whether or not the fact
that BGP is still not a full standard indicates we
may be behind schedule is for others to decide... 

	:-)

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Wednesday, September 18, 2002 11:57 AM
> To: Gray, Eric
> Cc: [e-mail]
> Subject: Re: IDR WG charter
> 
> On Wed, Sep 18, 2002 at 11:20:48AM -0400, Gray, Eric wrote:
> > 	As it is currently left, we are making no
> > progress...
> 
> As it currently stands, there is a good amount of useful feedback
> on the base specification.  Once that's integrated and we repeat with
> the next version, we should hopefully converge rapidly on something
> we can submit as an RFC candidate.
> 
> Thats all the AD's wanted.
> 
> > Eric W. Gray
> 
> --
> 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 MAA26410 for <[e-mail]>; Wed, 18 Sep 2002 12:31:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 670FE91279; Wed, 18 Sep 2002 12:31:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A6289128B; Wed, 18 Sep 2002 12:31:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0744591279 for <[e-mail]>; Wed, 18 Sep 2002 12:31:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DB1F25E095; Wed, 18 Sep 2002 12:31:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from roam.psg.com (pixsv79.isi.com [192.73.222.230]) by segue.merit.edu (Postfix) with ESMTP id AF7795E094 for <[e-mail]>; Wed, 18 Sep 2002 12:31:13 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17rhjM-0004NW-00; Wed, 18 Sep 2002 19:31:12 +0300
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: IDR WG charter
References: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 18 Sep 2002 19:31:12 +0300
Sender: [e-mail]
Precedence: bulk

> In response to the attached I got 7 "accept" and 4 "reject".

we repeatedly learn why we don't do voting in the ietf

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 LAA25187 for <[e-mail]>; Wed, 18 Sep 2002 11:57:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 444189128E; Wed, 18 Sep 2002 11:57:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15DDF91290; Wed, 18 Sep 2002 11:57:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 07E759128E for <[e-mail]>; Wed, 18 Sep 2002 11:57:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E64FE5E07A; Wed, 18 Sep 2002 11:57:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 2F6235DE5C for <[e-mail]>; Wed, 18 Sep 2002 11:57:07 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8IFv0a39329; Wed, 18 Sep 2002 11:57:00 -0400 (EDT) (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 g8IFuuG39319; Wed, 18 Sep 2002 11:56:56 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8IFuuC20474; Wed, 18 Sep 2002 11:56:56 -0400 (EDT)
Date: Wed, 18 Sep 2002 11:56:56 -0400
From: Jeffrey Haas <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Cc: [e-mail]
Subject: Re: IDR WG charter
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 Wed, Sep 18, 2002 at 11:20:48AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 18, 2002 at 11:20:48AM -0400, Gray, Eric wrote:
> 	As it is currently left, we are making no
> progress...

As it currently stands, there is a good amount of useful feedback
on the base specification.  Once that's integrated and we repeat with
the next version, we should hopefully converge rapidly on something
we can submit as an RFC candidate.

Thats all the AD's wanted.

> Eric W. Gray

-- 
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 LAA24993 for <[e-mail]>; Wed, 18 Sep 2002 11:53:58 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 823099128B; Wed, 18 Sep 2002 11:53:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51C619128E; Wed, 18 Sep 2002 11:53:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC5D99128B for <[e-mail]>; Wed, 18 Sep 2002 11:53:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B5C505DE5C; Wed, 18 Sep 2002 11:53:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 231865DDEE for <[e-mail]>; Wed, 18 Sep 2002 11:53:27 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8IFrPm79163; Wed, 18 Sep 2002 08:53:25 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Cc: [e-mail]
Subject: Re: IDR WG charter 
In-Reply-To: Your message of "Wed, 18 Sep 2002 11:20:48 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 18 Sep 2002 08:53:25 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Eric,

> Yakov,
> 
> 	I would like to understand whether those who
> rejected the new proposal did so because they felt
> the current charter is better, or because they are
> convinced that a better charter could be produced.
> 
> 	At a minimum, the current charter needs to 
> be updated.  If people are unhappy with proposals
> from the AD, then they should be explicit about
> their reasoning.  Ideally, those rejecting the
> proposal would make either specific suggestions
> as to changes or propose an alternative.
> 
> 	As it is currently left, we are making no
> progress...

We certainly have "rough consensus" to accept the new charter,
and that is exactly what the WG is going to do.

The only thing we need to do with the new charter is to add
few items that have been missing, like Cease subcodes, Graceful
restart, Dynamic Capability (they've been missing both in the
current charter and in the new proposed charter), and settle
on the dates. I'll post the updated new charter within few
days.

Yakov.

> 
> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> [e-mail]
> 508 305 7214
> 
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Wednesday, September 18, 2002 10:53 AM
> > To: [e-mail]
> > Subject: IDR WG charter
> > 
> > Folks,
> > 
> > In response to the attached I got 7 "accept" and 4 "reject".
> > 
> > Yakov.
> > ------- Forwarded Message
> > 
> > Date:    Tue, 03 Sep 2002 09:43:42 -0700
> > From:    Yakov Rekhter <[e-mail]>
> > To:      [e-mail]
> > cc:      [e-mail], [e-mail]
> > Subject: IDR WG charter
> 
> > Folks,
> > 
> > So far we received just two e-mail on the subject of the IDR WG
> > charter proposed by Bill and Alex. The WG chairs would like to get
> > opinion of the WG members on whether the WG should accept the new
> > charter, or stay with the existing one.  With this in mind, please
> > send me an e-mail with either "accept" (means accept the new
> > charter), or "reject" (means stay with the existing charter). The
> > deadline is Sep 17.
> > 
> > Sue & Yakov.
> > - ------- Forwarded Message
> > 
> > Date:    Mon, 26 Aug 2002 07:18:00 -0700
> > From:    Yakov Rekhter <[e-mail]>
> > To:      [e-mail]
> > cc:      [e-mail]
> > Subject: IDR WG charter
> > 
> > Folks,
> > 
> > Please comment on the revised charter proposed by Bill and Alex
> > (see below). The deadline for comments is Sep 10, 2002.
> > 
> > Sue & Yakov
> > - - ------- Forwarded Message
> > 
> > Date:    Thu, 22 Aug 2002 16:11:10 -0700
> > From:    Bill Fenner <[e-mail]>
> > To:      [e-mail]
> > Subject: BGP spec and IDR WG charter
> > 
> > Dear IDR WG,
> > 
> >   After some consideration, the Routing Area Directors have decided
> > not to forward any IDR documents for IESG consideration until the
> > base BGP spec update is finished.[*]  Despite the best efforts of all
> > involved, the spec update has been taking an incredible amount of
> > time.  We take this step in order to focus all possible resources
> > of the WG community on the BGP spec update.
> > 
> >   This may seem like a negative action.  On the contrary, it is
> > meant to support the accomplishment of the working group's goals.[**]
> > The milestone for the submission of the BGP4 draft to the IESG
> > was scheduled for January 2002.
> > 
> >   Attached is a proposed update for the IDR working group charter.
> > Note that we just made up the dates in the goals and milestones,
> > and the WG should come up with realistic ones.
> > 
> >   Bill and Alex
> > 
> > [*] "finished" means, in this case, WG consensus, WG Last Call,
> > AD Review, IETF Last Call, and IESG approval for publication.
> > 
> > [**] In further support of the goal of having a quality specification
> > that reflects current reality, the ADs have been working on assembling
> > a team of reviewers that consists primarily of protocol implementors,
> > who have committed their time to examine the spec.  We will be
> > sending another message to this list explaining the details of how
> > this team will do its work.
> > 
> > - - - - - -
> > 
> > The Inter-Domain Routing Working Group is chartered to standardize
> > and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
> > 1771] capable of supporting policy based routing for TCP/IP internets.
> > The objective is to promote the use of BGP-4 to support IP version
> > 4 and IP version 6. The working group will continue to work on
> > improving the scalability of BGP.
> > 
> > The current tasks of the WG are limited to:
> > 
> > - - - - Revise and clarify the base BGP4 document (RFC 1771). Note that
> > RFC 1771 no longer documents existing practice and one goal of the
> > update is document existing practice. Determine whether the document
> > can be advanced as full Standard or needs to recycle at Proposed
> > or Draft Standard.
> > 
> > - - - - Submit updated MIBs to accompany the revised base BGP4 document.
> > 
> > Once these tasks are completed, work will progress on the following:
> > 
> > - - - - Review and Evaluate Existing RFCs on AS Confederations and Route
> > Reflection. If changes are needed, create and advance revisions.
> > 
> > - - - - Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
> > if any changes need to be made based on current Internet practice
> > or based on the changes to the current bgp draft. If changes are
> > needed, create an revision. Issue the WG Last Call on advancing
> > the document to Draft Standard.
> > 
> > - - - - Produce an updated MIB for AS Confederations, Route Reflection,
> > Communities, Multi-Protocol BGP, etc..
> > 
> > - - - - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
> > as Draft Standard.
> > 
> > - - - - Complete work on an Extended Community Attribute. Develop MIB
> > for BGP Extended Communities.
> > 
> > - - - - Extend BGP to support a 4-byte AS number, develop plan for
> > transitioning to usage of 4-byte AS numbers
> > 
> > - - - - Progress along the IETF standards track 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. Currently defined in
> > draft-ietf-idr-route-filter-03.txt.
> > 
> > - - - - Progress along standards track an Outbound Router Filter (ORF)
> > type for BGP, that can be used to perform aspath based route
> > filtering. The ORF-type will support aspath based route filtering
> > as well as regular expression based matching for address groups.
> > Currently defined in draft-ietf-idr-aspath-orf-00.txt.
> > 
> > Tasks for this working group are limited to those listed above;
> > new items to be added to the charter must be approved by the IESG.
> > 
> > Goals and Milestones
> > 
> > DONE    Submit BGP Capability Advertisement to the IESG
> > NOV 02  Submit BGP4 document to IESG.
> > DEC 02  Submit updated base BGP4 MIB to IESG.
> > MAR 03  Submit extensible BGP MIB to IESG.
> > MAR 03  Submit Extended Communities draft to IESG.
> > MAR 03  Submit 4-byte AS ID to IESG.
> > MAR 03  Initial Draft for RFC2858 (if needed)
> > MAR 03  BGP TCP MD5 signatures document to IESG.
> > MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.
> > 
> > - - ------- End of Forwarded Message
> > 
> > 
> > - ------- End of Forwarded Message
> > 
> > 
> > ------- End of Forwarded Message


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA23898 for <[e-mail]>; Wed, 18 Sep 2002 11:23:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EF8A291279; Wed, 18 Sep 2002 11:21:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6D559128B; Wed, 18 Sep 2002 11:21:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8DE4A91279 for <[e-mail]>; Wed, 18 Sep 2002 11:20:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7B0705DF05; Wed, 18 Sep 2002 11:20:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (unknown [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 2CA8B5DE74 for <[e-mail]>; Wed, 18 Sep 2002 11:20:59 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1G3Q8>; Wed, 18 Sep 2002 11:20:54 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: IDR WG charter
Date: Wed, 18 Sep 2002 11:20:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Yakov,

	I would like to understand whether those who
rejected the new proposal did so because they felt
the current charter is better, or because they are
convinced that a better charter could be produced.

	At a minimum, the current charter needs to 
be updated.  If people are unhappy with proposals
from the AD, then they should be explicit about
their reasoning.  Ideally, those rejecting the
proposal would make either specific suggestions
as to changes or propose an alternative.

	As it is currently left, we are making no
progress...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[e-mail]
508 305 7214


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 18, 2002 10:53 AM
> To: [e-mail]
> Subject: IDR WG charter
> 
> Folks,
> 
> In response to the attached I got 7 "accept" and 4 "reject".
> 
> Yakov.
> ------- Forwarded Message
> 
> Date:    Tue, 03 Sep 2002 09:43:42 -0700
> From:    Yakov Rekhter <[e-mail]>
> To:      [e-mail]
> cc:      [e-mail], [e-mail]
> Subject: IDR WG charter
> 
> Folks,
> 
> So far we received just two e-mail on the subject of the IDR WG
> charter proposed by Bill and Alex. The WG chairs would like to get
> opinion of the WG members on whether the WG should accept the new
> charter, or stay with the existing one.  With this in mind, please
> send me an e-mail with either "accept" (means accept the new
> charter), or "reject" (means stay with the existing charter). The
> deadline is Sep 17.
> 
> Sue & Yakov.
> - ------- Forwarded Message
> 
> Date:    Mon, 26 Aug 2002 07:18:00 -0700
> From:    Yakov Rekhter <[e-mail]>
> To:      [e-mail]
> cc:      [e-mail]
> Subject: IDR WG charter
> 
> Folks,
> 
> Please comment on the revised charter proposed by Bill and Alex
> (see below). The deadline for comments is Sep 10, 2002.
> 
> Sue & Yakov
> - - ------- Forwarded Message
> 
> Date:    Thu, 22 Aug 2002 16:11:10 -0700
> From:    Bill Fenner <[e-mail]>
> To:      [e-mail]
> Subject: BGP spec and IDR WG charter
> 
> Dear IDR WG,
> 
>   After some consideration, the Routing Area Directors have decided
> not to forward any IDR documents for IESG consideration until the
> base BGP spec update is finished.[*]  Despite the best efforts of all
> involved, the spec update has been taking an incredible amount of
> time.  We take this step in order to focus all possible resources
> of the WG community on the BGP spec update.
> 
>   This may seem like a negative action.  On the contrary, it is
> meant to support the accomplishment of the working group's goals.[**]
> The milestone for the submission of the BGP4 draft to the IESG
> was scheduled for January 2002.
> 
>   Attached is a proposed update for the IDR working group charter.
> Note that we just made up the dates in the goals and milestones,
> and the WG should come up with realistic ones.
> 
>   Bill and Alex
> 
> [*] "finished" means, in this case, WG consensus, WG Last Call,
> AD Review, IETF Last Call, and IESG approval for publication.
> 
> [**] In further support of the goal of having a quality specification
> that reflects current reality, the ADs have been working on assembling
> a team of reviewers that consists primarily of protocol implementors,
> who have committed their time to examine the spec.  We will be
> sending another message to this list explaining the details of how
> this team will do its work.
> 
> - - - - - -
> 
> The Inter-Domain Routing Working Group is chartered to standardize
> and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
> 1771] capable of supporting policy based routing for TCP/IP internets.
> The objective is to promote the use of BGP-4 to support IP version
> 4 and IP version 6. The working group will continue to work on
> improving the scalability of BGP.
> 
> The current tasks of the WG are limited to:
> 
> - - - - Revise and clarify the base BGP4 document (RFC 1771). Note that
> RFC 1771 no longer documents existing practice and one goal of the
> update is document existing practice. Determine whether the document
> can be advanced as full Standard or needs to recycle at Proposed
> or Draft Standard.
> 
> - - - - Submit updated MIBs to accompany the revised base BGP4 document.
> 
> Once these tasks are completed, work will progress on the following:
> 
> - - - - Review and Evaluate Existing RFCs on AS Confederations and Route
> Reflection. If changes are needed, create and advance revisions.
> 
> - - - - Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
> if any changes need to be made based on current Internet practice
> or based on the changes to the current bgp draft. If changes are
> needed, create an revision. Issue the WG Last Call on advancing
> the document to Draft Standard.
> 
> - - - - Produce an updated MIB for AS Confederations, Route Reflection,
> Communities, Multi-Protocol BGP, etc..
> 
> - - - - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
> as Draft Standard.
> 
> - - - - Complete work on an Extended Community Attribute. Develop MIB
> for BGP Extended Communities.
> 
> - - - - Extend BGP to support a 4-byte AS number, develop plan for
> transitioning to usage of 4-byte AS numbers
> 
> - - - - Progress along the IETF standards track 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. Currently defined in
> draft-ietf-idr-route-filter-03.txt.
> 
> - - - - Progress along standards track an Outbound Router Filter (ORF)
> type for BGP, that can be used to perform aspath based route
> filtering. The ORF-type will support aspath based route filtering
> as well as regular expression based matching for address groups.
> Currently defined in draft-ietf-idr-aspath-orf-00.txt.
> 
> Tasks for this working group are limited to those listed above;
> new items to be added to the charter must be approved by the IESG.
> 
> Goals and Milestones
> 
> DONE    Submit BGP Capability Advertisement to the IESG
> NOV 02  Submit BGP4 document to IESG.
> DEC 02  Submit updated base BGP4 MIB to IESG.
> MAR 03  Submit extensible BGP MIB to IESG.
> MAR 03  Submit Extended Communities draft to IESG.
> MAR 03  Submit 4-byte AS ID to IESG.
> MAR 03  Initial Draft for RFC2858 (if needed)
> MAR 03  BGP TCP MD5 signatures document to IESG.
> MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.
> 
> - - ------- End of Forwarded Message
> 
> 
> - ------- End of Forwarded Message
> 
> 
> ------- End of Forwarded Message


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA22762 for <[e-mail]>; Wed, 18 Sep 2002 10:54:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0327D91288; Wed, 18 Sep 2002 10:53:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B865B9128B; Wed, 18 Sep 2002 10:53:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4F0A891288 for <[e-mail]>; Wed, 18 Sep 2002 10:53:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2E80D5E06C; Wed, 18 Sep 2002 10:53:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 8BC0A5E065 for <[e-mail]>; Wed, 18 Sep 2002 10:53:29 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8IErTm74971 for <[e-mail]>; Wed, 18 Sep 2002 07:53:29 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: IDR WG charter
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 18 Sep 2002 07:53:29 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

In response to the attached I got 7 "accept" and 4 "reject".

Yakov.
------- Forwarded Message

Date:    Tue, 03 Sep 2002 09:43:42 -0700
From:    Yakov Rekhter <[e-mail]>
To:      [e-mail]
cc:      [e-mail], [e-mail]
Subject: IDR WG charter

Folks,

So far we received just two e-mail on the subject of the IDR WG
charter proposed by Bill and Alex. The WG chairs would like to get
opinion of the WG members on whether the WG should accept the new
charter, or stay with the existing one.  With this in mind, please
send me an e-mail with either "accept" (means accept the new
charter), or "reject" (means stay with the existing charter). The
deadline is Sep 17.

Sue & Yakov.
- ------- Forwarded Message

Date:    Mon, 26 Aug 2002 07:18:00 -0700
From:    Yakov Rekhter <[e-mail]>
To:      [e-mail]
cc:      [e-mail]
Subject: IDR WG charter

Folks,

Please comment on the revised charter proposed by Bill and Alex
(see below). The deadline for comments is Sep 10, 2002.

Sue & Yakov
- - ------- Forwarded Message

Date:    Thu, 22 Aug 2002 16:11:10 -0700
From:    Bill Fenner <[e-mail]>
To:      [e-mail]
Subject: BGP spec and IDR WG charter

Dear IDR WG,

  After some consideration, the Routing Area Directors have decided
not to forward any IDR documents for IESG consideration until the
base BGP spec update is finished.[*]  Despite the best efforts of all
involved, the spec update has been taking an incredible amount of
time.  We take this step in order to focus all possible resources
of the WG community on the BGP spec update.

  This may seem like a negative action.  On the contrary, it is
meant to support the accomplishment of the working group's goals.[**]
The milestone for the submission of the BGP4 draft to the IESG
was scheduled for January 2002.

  Attached is a proposed update for the IDR working group charter.
Note that we just made up the dates in the goals and milestones,
and the WG should come up with realistic ones.

  Bill and Alex

[*] "finished" means, in this case, WG consensus, WG Last Call,
AD Review, IETF Last Call, and IESG approval for publication.

[**] In further support of the goal of having a quality specification
that reflects current reality, the ADs have been working on assembling
a team of reviewers that consists primarily of protocol implementors,
who have committed their time to examine the spec.  We will be
sending another message to this list explaining the details of how
this team will do its work.

- - - - - -

The Inter-Domain Routing Working Group is chartered to standardize
and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
1771] capable of supporting policy based routing for TCP/IP internets.
The objective is to promote the use of BGP-4 to support IP version
4 and IP version 6. The working group will continue to work on
improving the scalability of BGP.

The current tasks of the WG are limited to:

- - - - Revise and clarify the base BGP4 document (RFC 1771). Note that
RFC 1771 no longer documents existing practice and one goal of the
update is document existing practice. Determine whether the document
can be advanced as full Standard or needs to recycle at Proposed
or Draft Standard.

- - - - Submit updated MIBs to accompany the revised base BGP4 document.

Once these tasks are completed, work will progress on the following:

- - - - Review and Evaluate Existing RFCs on AS Confederations and Route
Reflection. If changes are needed, create and advance revisions.

- - - - Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
if any changes need to be made based on current Internet practice
or based on the changes to the current bgp draft. If changes are
needed, create an revision. Issue the WG Last Call on advancing
the document to Draft Standard.

- - - - Produce an updated MIB for AS Confederations, Route Reflection,
Communities, Multi-Protocol BGP, etc..

- - - - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
as Draft Standard.

- - - - Complete work on an Extended Community Attribute. Develop MIB
for BGP Extended Communities.

- - - - Extend BGP to support a 4-byte AS number, develop plan for
transitioning to usage of 4-byte AS numbers

- - - - Progress along the IETF standards track 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. Currently defined in
draft-ietf-idr-route-filter-03.txt.

- - - - Progress along standards track an Outbound Router Filter (ORF)
type for BGP, that can be used to perform aspath based route
filtering. The ORF-type will support aspath based route filtering
as well as regular expression based matching for address groups.
Currently defined in draft-ietf-idr-aspath-orf-00.txt.

Tasks for this working group are limited to those listed above;
new items to be added to the charter must be approved by the IESG.

Goals and Milestones

DONE    Submit BGP Capability Advertisement to the IESG
NOV 02  Submit BGP4 document to IESG.
DEC 02  Submit updated base BGP4 MIB to IESG.
MAR 03  Submit extensible BGP MIB to IESG.
MAR 03  Submit Extended Communities draft to IESG.
MAR 03  Submit 4-byte AS ID to IESG.
MAR 03  Initial Draft for RFC2858 (if needed)
MAR 03  BGP TCP MD5 signatures document to IESG.
MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.

- - ------- End of Forwarded Message


- ------- End of Forwarded Message


------- End of Forwarded Message



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA21451 for <[e-mail]>; Wed, 18 Sep 2002 10:16:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7AE4D9129B; Wed, 18 Sep 2002 10:15:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BB3B9128E; Wed, 18 Sep 2002 10:15:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 425999129B for <[e-mail]>; Wed, 18 Sep 2002 10:15:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DBAE55E068; Wed, 18 Sep 2002 10:15:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by segue.merit.edu (Postfix) with ESMTP id 325B95E067 for <[e-mail]>; Wed, 18 Sep 2002 10:15:38 -0400 (EDT)
Received: from [10.9.9.110] (helo=snoopy.runbox.com) by tramp.runbox.com with esmtp (Exim 4.05-VA-mm1) id 17rfc9-00026a-00; Wed, 18 Sep 2002 16:15:37 +0200
Received: from [203.200.20.226] (helo=Manav) (Authenticated Sender=davidwaters) by snoopy.runbox.com with asmtp (Exim 3.35 #1) id 17rfbm-00066N-00; Wed, 18 Sep 2002 16:15:15 +0200
Message-ID: <036401c25f1d$c2d56350$[e-mail]>
From: "David Waters" <[e-mail]>
To: "Russ White" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt
Date: Wed, 18 Sep 2002 19:44:50 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

| seems like it should be in any given TE or MPLS extenstion draft,
| rather than in the BGP base spec.

moreover i am not asking this to be added in the base spec :-)

-- David 



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA20875 for <[e-mail]>; Wed, 18 Sep 2002 10:06:15 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8822091262; Wed, 18 Sep 2002 10:05:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53C9391285; Wed, 18 Sep 2002 10:05:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D250B91262 for <[e-mail]>; Wed, 18 Sep 2002 10:05:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B86FD5DE78; Wed, 18 Sep 2002 10:05:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by segue.merit.edu (Postfix) with ESMTP id 75C1F5DE35 for <[e-mail]>; Wed, 18 Sep 2002 10:05:52 -0400 (EDT)
Received: from [10.9.9.110] (helo=snoopy.runbox.com) by tramp.runbox.com with esmtp (Exim 4.05-VA-mm1) id 17rfSh-00077u-00; Wed, 18 Sep 2002 16:05:51 +0200
Received: from [203.200.20.226] (helo=Manav) (Authenticated Sender=davidwaters) by snoopy.runbox.com with asmtp (Exim 3.35 #1) id 17rfSc-0006JO-00; Wed, 18 Sep 2002 16:05:46 +0200
Message-ID: <034001c25f1c$6ff7d0b0$[e-mail]>
From: "David Waters" <[e-mail]>
To: "Russ White" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt
Date: Wed, 18 Sep 2002 19:35:22 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

snip from one of the earlier posts in the WG -
"draft-ietf-isis-traffic-04.txt states that if some router advertises the
router ID TLV (containing the 4-octet router ID of the router originating
the LSP) in its LSP, and if it also advertises BGP routes with the BGP next
hop set to the BGP router ID (which is what is usually done), then in such
cases, the TE router ID should match the BGP router ID."

I guess other documents are saying this :-)

David

----- Original Message -----
From: "Russ White" <[e-mail]>
To: "David Waters" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, September 18, 2002 7:31 PM
Subject: Re: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt


|
| I didn't say they didn't match--just that as far as I know, it's
| not being checked on the BGP side. If it's a TE requirement, it
| seems like it should be in any given TE or MPLS extenstion draft,
| rather than in the BGP base spec.
|
| :-)
|
| Russ
|
| On Wed, 18 Sep 2002, David Waters wrote:
|
| > and what when you do TE?
| >
| > ----- Original Message -----
| > From: "Russ White" <[e-mail]>
| > To: "David Waters" <[e-mail]>
| > Cc: "Yakov Rekhter" <[e-mail]>; <[e-mail]>
| > Sent: Wednesday, September 18, 2002 6:14 PM
| > Subject: Re: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt
| >
| >
| > |
| > | > Anyway its a good practice to do so. Is there any network
| > | > operator in the wild *not* doing this?
| > |
| > | Virtually every network I've encountered has synchronization
| > | turned off--so, while their protocol IDs may match, they are not
| > | being checked.
| > |
| > | Russ
| > |
| > |
| > | __________________________________
| > | [e-mail] CCIE <>< Grace Alone
| > |
| > |
| > |
| >
|
| __________________________________
| [e-mail] CCIE <>< Grace Alone
|
|



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA20754 for <[e-mail]>; Wed, 18 Sep 2002 10:02:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D58C19124A; Wed, 18 Sep 2002 10:01:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9906291262; Wed, 18 Sep 2002 10:01:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DCBDC9124A for <[e-mail]>; Wed, 18 Sep 2002 10:01:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C23065E062; Wed, 18 Sep 2002 10:01:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id C34C25DE35 for <[e-mail]>; Wed, 18 Sep 2002 10:01:43 -0400 (EDT)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA25105; Wed, 18 Sep 2002 10:01:41 -0400 (EDT)
Date: Wed, 18 Sep 2002 10:01:40 -0400 (EDT)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: David Waters <[e-mail]>
Cc: [e-mail]
Subject: Re: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt 
In-Reply-To: <02f601c25f1b$1769f190$[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

I didn't say they didn't match--just that as far as I know, it's
not being checked on the BGP side. If it's a TE requirement, it
seems like it should be in any given TE or MPLS extenstion draft,
rather than in the BGP base spec.

:-)

Russ

On Wed, 18 Sep 2002, David Waters wrote:

> and what when you do TE?
> 
> ----- Original Message ----- 
> From: "Russ White" <[e-mail]>
> To: "David Waters" <[e-mail]>
> Cc: "Yakov Rekhter" <[e-mail]>; <[e-mail]>
> Sent: Wednesday, September 18, 2002 6:14 PM
> Subject: Re: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt 
> 
> 
> | 
> | > Anyway its a good practice to do so. Is there any network
> | > operator in the wild *not* doing this?
> | 
> | Virtually every network I've encountered has synchronization
> | turned off--so, while their protocol IDs may match, they are not
> | being checked.
> | 
> | Russ
> | 
> | 
> | __________________________________
> | [e-mail] CCIE <>< Grace Alone
> | 
> | 
> | 
> 

__________________________________
[e-mail] CCIE <>< Grace Alone




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA20567 for <[e-mail]>; Wed, 18 Sep 2002 09:57:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B7D7C91279; Wed, 18 Sep 2002 09:56:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 878E891285; Wed, 18 Sep 2002 09:56:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C19791279 for <[e-mail]>; Wed, 18 Sep 2002 09:56:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0245A5E05E; Wed, 18 Sep 2002 09:56:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by segue.merit.edu (Postfix) with ESMTP id B3D1C5DE35 for <[e-mail]>; Wed, 18 Sep 2002 09:56:40 -0400 (EDT)
Received: from [10.9.9.110] (helo=snoopy.runbox.com) by tramp.runbox.com with esmtp (Exim 4.05-VA-mm1) id 17rfJn-0003RB-00; Wed, 18 Sep 2002 15:56:39 +0200
Received: from [203.200.20.226] (helo=Manav) (Authenticated Sender=davidwaters) by snoopy.runbox.com with asmtp (Exim 3.35 #1) id 17rfJI-0006eu-00; Wed, 18 Sep 2002 15:56:08 +0200
Message-ID: <02f601c25f1b$1769f190$[e-mail]>
From: "David Waters" <[e-mail]>
To: "Russ White" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt 
Date: Wed, 18 Sep 2002 19:25:44 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

and what when you do TE?

----- Original Message ----- 
From: "Russ White" <[e-mail]>
To: "David Waters" <[e-mail]>
Cc: "Yakov Rekhter" <[e-mail]>; <[e-mail]>
Sent: Wednesday, September 18, 2002 6:14 PM
Subject: Re: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt 


| 
| > Anyway its a good practice to do so. Is there any network
| > operator in the wild *not* doing this?
| 
| Virtually every network I've encountered has synchronization
| turned off--so, while their protocol IDs may match, they are not
| being checked.
| 
| Russ
| 
| 
| __________________________________
| [e-mail] CCIE <>< Grace Alone
| 
| 
| 



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA17922 for <[e-mail]>; Wed, 18 Sep 2002 08:45:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 91FE491279; Wed, 18 Sep 2002 08:44:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D9F39127C; Wed, 18 Sep 2002 08:44:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CBF1B91279 for <[e-mail]>; Wed, 18 Sep 2002 08:44:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B580D5E05C; Wed, 18 Sep 2002 08:44:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 4135A5E059 for <[e-mail]>; Wed, 18 Sep 2002 08:44:44 -0400 (EDT)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA21480; Wed, 18 Sep 2002 08:44:37 -0400 (EDT)
Date: Wed, 18 Sep 2002 08:44:37 -0400 (EDT)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: David Waters <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt 
In-Reply-To: <01bd01c25eee$2fa07ef0$[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Anyway its a good practice to do so. Is there any network
> operator in the wild *not* doing this?

Virtually every network I've encountered has synchronization
turned off--so, while their protocol IDs may match, they are not
being checked.

Russ


__________________________________
[e-mail] CCIE <>< Grace Alone




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA12745 for <[e-mail]>; Wed, 18 Sep 2002 06:21:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 875EB91262; Wed, 18 Sep 2002 06:20:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4CDF89126E; Wed, 18 Sep 2002 06:20:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1028291262 for <[e-mail]>; Wed, 18 Sep 2002 06:20:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F1DC35DF9C; Wed, 18 Sep 2002 06:20:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by segue.merit.edu (Postfix) with ESMTP id 016F15DEA2 for <[e-mail]>; Wed, 18 Sep 2002 06:20:42 -0400 (EDT)
Received: from Bemail06.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g8IAE8N26007; Wed, 18 Sep 2002 12:14:08 +0200
Received: from alcatel.be ([138.203.142.3]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002091812200509:4121 ; Wed, 18 Sep 2002 12:20:05 +0200 
Message-ID: <[e-mail]>
Date: Wed, 18 Sep 2002 12:19:48 +0200
From: [e-mail]
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], BGP mailing list <[e-mail]>
Subject: Re: BGP4 draft ; section 6.2
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 09/18/2002 12:20:05, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 09/18/2002 12:20:07, Serialize complete at 09/18/2002 12:20:07
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

[e-mail] wrote:

> Hans,
>
> Please send your mails with plain ASCII text encoding.  It is a mess to
> read your html in mutt.
>

Sorry for this, please find attached the version in plain ascii.


>
> Thanks!
>
> Andrew

All,

Thanks for the replies on this question.

I have tried to group all answers I have received sofar below, toegther with some observations
from my side.


Hans De Vleeschouwer.

Original question:

  All,

  I have a doubt related to section 6.2: OPEN message error handling, related to the statement:

  " If one of the optional parameters in the Open mesage is not recognized, then the error
subcode is set to
  'unsupported optional parameters"

  We have hit on this line when we were testing a BGP connection between a speaker that supported
capability
  negotiation and a speaker that did not.

  The speaker that did not support the neogotiation closed down the peering session using the
error clause mentioned
  above.  Sometimes this lead to the other router to repeat the OPEN message with the Capability
optional parameter; a
  game that went on for minutes.

  This router manufacturer stated in a reply to this that :

       "One should not close down the connection if an optional parameter is unrecognised. That
would make
       this parameter basically mandatory.

       This is an well known error in the BGP spec. Neither Cisco or Juniper do this"

  If this is true it might be good to adapt the text.

  Hans de Vleeschouwer
  Alcatel.


Replies received:

Mathew Richardson wrote:

  > [e-mail] <[e-mail]> [Fri, Sep 13, 2002 at
03:43:55PM
  +0200]:

  From rfc2842:

     A BGP speaker determines that its peer doesn't support capabilities
     advertisement, if in response to an OPEN message that carries the
     Capabilities Optional Parameter, the speaker receives a NOTIFICATION
     message with the Error Subcode set to Unsupported Optional Parameter.
     In this case the speaker should attempt to re-establish a BGP
     connection with the peer without sending to the peer the Capabilities
     Optional Parameter.

  mrr


This section from the Capabilities Advertisement RFC, is indeed inline with the section 6.2 of
the BGP4 specification.
For me however the question remains if most implementations do no simply ignore optional
parameters that are
unknown. And if so, if the text stated above reflects what is implemented by routers that do not
have capability
advertisement at all.

"Natale, Jonathan" wrote:

  I just re-read your email; it is the rtr that does not have capabilities at
  all...

  1) currently, not too many implementations do the exponential back off in
  response to an error, and the whole FSM thing is being re-hashed now.  So it
  will flap.

  2) ignoring options (since *I think*(???) capabilities is the only one used
  anywhere) is probably not that bad of an idea since sending capabilities are
  only saying what the sender supports, not what the receiver supports.
  Obviously, ignoring capabilities is better when peering with a vendor that
  does not re-open without the capabilities as they should per rfc2842 (or
  maybe a config switch for this).  This is not spelled out in any rfc that I
  am aware of

  3) I do not know about the Juniper side of this.

  4) you might want to check the vendor's bugs.

  5) I *think* what the vendor was referring to is:

  From: Natale, Jonathan [mailto:[e-mail]]
  Sent: Tuesday, August 06, 2002 4:19 PM
  To: '[e-mail]'
  Subject: capability

  I would like to propose:

  >"If a BGP speaker that supports a certain capability determines that
  >    its peer doesn't support this capability, the speaker MAY send a
  >    NOTIFICATION message to the peer, and terminate peering (see Section
  >    "Extensions to Error Handling" for more details). The Error Subcode
  >    in the message is set to Unsupported Capability. The message SHOULD
  >    contain the capability (capabilities) that causes the speaker to send
  >    the message.  The decision to send the message and terminate peering
  >    is local to the speaker. If terminated, such peering SHOULD NOT be
  >    re-established automatically."
  >
  >be changed to:
  >
  >"If a BGP speaker that **does not want its peer to support** a certain
  >capability determines that
  >    its peer **does** support this capability, the speaker MAY send a
  >    NOTIFICATION message to the peer, and terminate peering (see Section
  >    "Extensions to Error Handling" for more details). The Error Subcode
  >    in the message is set to Unsupported Capability. The message SHOULD
  >    contain the capability (capabilities) that causes the speaker to send
  >    the message.  The decision to send the message and terminate peering
  >    is local to the speaker. **If terminated, the peer MAY re-open the
  >    connection without the offending capability-this is known as capability
  >    negotiation.**"
  >

  ... The response I got was basically that the draft is already done.


Here I find 3 elements:

1. the matter of the exponential backoff. This is indeed an interesting thing, since I have
noticed during testing that most
routers do not seem to do this, at least not in all cases (e.g. no exponential backoff in case of
a TCP connection that fails
with an RST message.).
However, as I understood this matter is subject of new ongoing work, and is therefore not part of
the current rework of
the BGP draft?

2. the reaction to unrecognised TLVs. Here I understand that Mathew is prepared to discuss
changing the way a peer
should react to such an event, i.e. changing the wording of section 6.2 so that  unrecognised
optional TLVs should be
ignored.

3. the reaction to an 'undesired' capability. This again is an interesting question that is to my
opinion not fully clear
(several vendors again react differently in this case). However it is taking the original problem
one step further, so I
would like to have this outside of this discussion for now.








Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA08675 for <[e-mail]>; Wed, 18 Sep 2002 04:35:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C0C109124A; Wed, 18 Sep 2002 04:34:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3FCB79126C; Wed, 18 Sep 2002 04:34:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5ADEE9124A for <[e-mail]>; Wed, 18 Sep 2002 04:34:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 436295DEDE; Wed, 18 Sep 2002 04:34:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by segue.merit.edu (Postfix) with ESMTP id BD6605DE25 for <[e-mail]>; Wed, 18 Sep 2002 04:34:49 -0400 (EDT)
Received: from [10.9.9.110] (helo=snoopy.runbox.com) by tramp.runbox.com with esmtp (Exim 4.05-VA-mm1) id 17raIK-0000fm-00; Wed, 18 Sep 2002 10:34:48 +0200
Received: from [203.200.20.226] (helo=Manav) (Authenticated Sender=davidwaters) by snoopy.runbox.com with asmtp (Exim 3.35 #1) id 17raIC-0007S2-00; Wed, 18 Sep 2002 10:34:41 +0200
Message-ID: <01bd01c25eee$2fa07ef0$[e-mail]>
From: "David Waters" <[e-mail]>
To: "Yakov Rekhter" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt 
Date: Wed, 18 Sep 2002 14:04:15 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

Yakov,
I did go through all the archives and i found no logical conclusion to the
great debate (everybody just kind of "backed off" in despair!) and nowhere
did i find the reason why they shouldn't match. What i indeed found were
some mails which clearly indicated (e.g. TE extensions to OSPF) that they
should be the same.

Anyway its a good practice to do so. Is there any network operator in the
wild *not* doing this?

I'll be surprised to find any raised hands.

Additionally you also said that only OSPF uses this term. Well i have some
more protocols using it and they all imply the same meaning.

- EIGRP
- PIM
- MPLS - TE

This list is in no way exhaustive and we can definitely come up with more.
It'll be really nice if somebody can come up with some kind of document on
RID issue.

David.

----- Original Message -----
From: "Yakov Rekhter" <[e-mail]>
To: "David Waters" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, September 18, 2002 3:04 AM
Subject: Re: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt


| David,
|
| > Hello,
| > I have always been slightly disturbed with this terminology used in BGP
i.e
| > BGP ID. Why cant we like all the other protocols use the term Router
ID?
| > Can it be mentioned explicitly in this document that the BGP ID is
nothing
| > but a Router ID. I gather that it is painfully obvious to the people
really
| > conversant with BGP but it is not so with the newbies !
| >
| > I had struggled during my initial days with the protocol and i find
that
| > more and more people get confused with this BGP ID. Is there any
thought in
| > the IDR WG to look into this issue.
|
| First of all the term Router ID is used by neither RIP nor ISIS. This
| term is used just by OSPF. So, saying that "all the other protocols
| use the term Router ID" may be a bit too strong.
|
| Second, there is no requirement to have BGP ID the same as the OSPF
| Router ID (see recent e-mail exchange on this list).
|
| Third, the semantics of OSPF Router ID is different from the semantics
| of BGP ID (the latter has to be an IP address, while the former need
| not to).
|
| With all of the above in mind, I think we should stick with the term
| BGP ID.
|
| Yakov.
|
| >
| > David.
| >
| > ----- Original Message -----
| > From: <[e-mail]>
| > To: <IETF-Announce:>
| > Cc: <[e-mail]>
| > Sent: Monday, September 16, 2002 5:16 PM
| > Subject: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt
| >
| >
| > | 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 : AS-wide Unique BGP Identifier for BGP-4
| > | Author(s) : E. Chen, J. Yuan
| > | Filename : draft-ietf-idr-bgp-identifier-01.txt
| > | Pages : 4
| > | Date : 2002-9-13
| > |
| > | To accommodate situations where the current requirements for the BGP
| > | Identifier are not met, this document relaxes the definition of the
| > | BGP Identifier to be a 4-octet unsigned, non-zero integer, and
| > | relaxes the 'uniqueness' requirement so that only AS-wide uniqueness
| > | of the BGP Identifiers is required. These revisions to the base BGP
| > | specification do not introduce any backward compatibility issue.
| > |
| > | A URL for this Internet-Draft is:
| > |
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-identifier-01.txt
| > |
| > | To remove yourself from the IETF Announcement list, send a message to
| > | ietf-announce-request with the word unsubscribe in the body of the
| > message.
| > |
| > | Internet-Drafts are also available by anonymous FTP. Login with the
| > username
| > | "anonymous" and a password of your e-mail address. After logging in,
| > | type "cd internet-drafts" and then
| > | "get draft-ietf-idr-bgp-identifier-01.txt".
| > |
| > | A list of Internet-Drafts directories can be found in
| > | http://www.ietf.org/shadow.html
| > | or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
| > |
| > |
| > | Internet-Drafts can also be obtained by e-mail.
| > |
| > | Send a message to:
| > | [e-mail].
| > | In the body type:
| > | "FILE /internet-drafts/draft-ietf-idr-bgp-identifier-01.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
| >
| >
|



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA00114 for <[e-mail]>; Wed, 18 Sep 2002 00:41:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4B2DE91228; Wed, 18 Sep 2002 00:41:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1903B9122A; Wed, 18 Sep 2002 00:41:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8569791228 for <[e-mail]>; Wed, 18 Sep 2002 00:41:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5D8C55DEA5; Wed, 18 Sep 2002 00:41:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by segue.merit.edu (Postfix) with ESMTP id DC1A95DDE2 for <[e-mail]>; Wed, 18 Sep 2002 00:41:11 -0400 (EDT)
Received: from [10.9.9.110] (helo=snoopy.runbox.com) by tramp.runbox.com with esmtp (Exim 4.05-VA-mm1) id 17rWeE-00089B-00; Wed, 18 Sep 2002 06:41:10 +0200
Received: from [203.200.20.226] (helo=Manav) (Authenticated Sender=davidwaters) by snoopy.runbox.com with asmtp (Exim 3.35 #1) id 17rWe1-0001P7-00; Wed, 18 Sep 2002 06:40:58 +0200
Message-ID: <011a01c25ecd$896cf100$[e-mail]>
From: "David Waters" <[e-mail]>
To: "Yakov Rekhter" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt 
Date: Wed, 18 Sep 2002 10:10:32 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

anybody has any idea as to why the BGP-OSPF RFC is now historical and why
it isnt being deployed anywhere?

- David

----- Original Message -----
From: "Yakov Rekhter" <[e-mail]>
To: "David Waters" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, September 18, 2002 3:04 AM
Subject: Re: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt


| David,
|
| > Hello,
| > I have always been slightly disturbed with this terminology used in BGP
i.e
| > BGP ID. Why cant we like all the other protocols use the term Router
ID?
| > Can it be mentioned explicitly in this document that the BGP ID is
nothing
| > but a Router ID. I gather that it is painfully obvious to the people
really
| > conversant with BGP but it is not so with the newbies !
| >
| > I had struggled during my initial days with the protocol and i find
that
| > more and more people get confused with this BGP ID. Is there any
thought in
| > the IDR WG to look into this issue.
|
| First of all the term Router ID is used by neither RIP nor ISIS. This
| term is used just by OSPF. So, saying that "all the other protocols
| use the term Router ID" may be a bit too strong.
|
| Second, there is no requirement to have BGP ID the same as the OSPF
| Router ID (see recent e-mail exchange on this list).
|
| Third, the semantics of OSPF Router ID is different from the semantics
| of BGP ID (the latter has to be an IP address, while the former need
| not to).
|
| With all of the above in mind, I think we should stick with the term
| BGP ID.
|
| Yakov.
|
| >
| > David.
| >
| > ----- Original Message -----
| > From: <[e-mail]>
| > To: <IETF-Announce:>
| > Cc: <[e-mail]>
| > Sent: Monday, September 16, 2002 5:16 PM
| > Subject: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt
| >
| >
| > | 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 : AS-wide Unique BGP Identifier for BGP-4
| > | Author(s) : E. Chen, J. Yuan
| > | Filename : draft-ietf-idr-bgp-identifier-01.txt
| > | Pages : 4
| > | Date : 2002-9-13
| > |
| > | To accommodate situations where the current requirements for the BGP
| > | Identifier are not met, this document relaxes the definition of the
| > | BGP Identifier to be a 4-octet unsigned, non-zero integer, and
| > | relaxes the 'uniqueness' requirement so that only AS-wide uniqueness
| > | of the BGP Identifiers is required. These revisions to the base BGP
| > | specification do not introduce any backward compatibility issue.
| > |
| > | A URL for this Internet-Draft is:
| > |
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-identifier-01.txt
| > |
| > | To remove yourself from the IETF Announcement list, send a message to
| > | ietf-announce-request with the word unsubscribe in the body of the
| > message.
| > |
| > | Internet-Drafts are also available by anonymous FTP. Login with the
| > username
| > | "anonymous" and a password of your e-mail address. After logging in,
| > | type "cd internet-drafts" and then
| > | "get draft-ietf-idr-bgp-identifier-01.txt".
| > |
| > | A list of Internet-Drafts directories can be found in
| > | http://www.ietf.org/shadow.html
| > | or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
| > |
| > |
| > | Internet-Drafts can also be obtained by e-mail.
| > |
| > | Send a message to:
| > | [e-mail].
| > | In the body type:
| > | "FILE /internet-drafts/draft-ietf-idr-bgp-identifier-01.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
| >
| >
|



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA14911 for <[e-mail]>; Tue, 17 Sep 2002 17:40:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A9C829124A; Tue, 17 Sep 2002 17:40:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B87C91269; Tue, 17 Sep 2002 17:40:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 308889124A for <[e-mail]>; Tue, 17 Sep 2002 17:40:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 109FA5DFE0; Tue, 17 Sep 2002 17:40:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id DD2215DDE1 for <[e-mail]>; Tue, 17 Sep 2002 17:40:09 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17rQ4h-000KxX-00; Tue, 17 Sep 2002 14:40:03 -0700
Date: Tue, 17 Sep 2002 14:38:20 -0700
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Cc: BGP mailing list <[e-mail]>
Subject: Re: general remark on the ongoing review
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hans,

 This is one of the reasons why I suggested that a list of
 issues is maintained. The chairs told me that we actually
 have a person taking care of this, so hopefully we should
 see something pretty soon. Sue and Yakov would have a better
 idea of when the first version is due.

-- 
Alex

Tuesday, September 17, 2002, 12:03:20 AM, [e-mail] wrote:
> Just a thought...

> I have seen so many comments recently on various parts of the current
> draft (version 17), that, for me at least, it becomes hard to know what
> is by now changed in the text and what is not. This in turn makes it
> hard to review the text completely.

> Would it be an idea to re-issue the document (e.g. as a draft-18) so
> that we can have a look on how the document looks like now, to make sure
> we all look at the same document again?


> hans De Vleeschouwer
>   Alcatel.




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 RAA14749 for <[e-mail]>; Tue, 17 Sep 2002 17:35:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B421A91237; Tue, 17 Sep 2002 17:34:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3442A91269; Tue, 17 Sep 2002 17:34:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD12791206 for <[e-mail]>; Tue, 17 Sep 2002 17:34:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 928A75DE6D; Tue, 17 Sep 2002 17:34:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id C88E65DFE4 for <[e-mail]>; Tue, 17 Sep 2002 17:34:19 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8HLYCm23236; Tue, 17 Sep 2002 14:34:13 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "David Waters" <[e-mail]>
Cc: [e-mail]
Subject: Re: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt 
In-Reply-To: Your message of "Tue, 17 Sep 2002 18:54:45 +0530." <03b401c25e4d$9b8ce4b0$[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 14:34:12 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

David,

> Hello,
> I have always been slightly disturbed with this terminology used in BGP i.e
> BGP ID. Why cant we like all the other protocols use the term Router ID?
> Can it be mentioned explicitly in this document that the BGP ID is nothing
> but a Router ID. I gather that it is painfully obvious to the people really
> conversant with BGP but it is not so with the newbies !
> 
> I had struggled during my initial days with the protocol and i find that
> more and more people get confused with this BGP ID. Is there any thought in
> the IDR WG to look into this issue.

First of all the term Router ID is used by neither RIP nor ISIS. This
term is used just by OSPF. So, saying that "all the other protocols
use the term Router ID" may be a bit too strong.

Second, there is no requirement to have BGP ID the same as the OSPF
Router ID (see recent e-mail exchange on this list).

Third, the semantics of OSPF Router ID is different from the semantics
of BGP ID (the latter has to be an IP address, while the former need
not to).

With all of the above in mind, I think we should stick with the term
BGP ID.

Yakov.

> 
> David.
> 
> ----- Original Message -----
> From: <[e-mail]>
> To: <IETF-Announce:>
> Cc: <[e-mail]>
> Sent: Monday, September 16, 2002 5:16 PM
> Subject: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt
> 
> 
> | 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 : AS-wide Unique BGP Identifier for BGP-4
> | Author(s) : E. Chen, J. Yuan
> | Filename : draft-ietf-idr-bgp-identifier-01.txt
> | Pages : 4
> | Date : 2002-9-13
> |
> | To accommodate situations where the current requirements for the BGP
> | Identifier are not met, this document relaxes the definition of the
> | BGP Identifier to be a 4-octet unsigned, non-zero integer, and
> | relaxes the 'uniqueness' requirement so that only AS-wide uniqueness
> | of the BGP Identifiers is required. These revisions to the base BGP
> | specification do not introduce any backward compatibility issue.
> |
> | A URL for this Internet-Draft is:
> | http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-identifier-01.txt
> |
> | To remove yourself from the IETF Announcement list, send a message to
> | ietf-announce-request with the word unsubscribe in the body of the
> message.
> |
> | Internet-Drafts are also available by anonymous FTP. Login with the
> username
> | "anonymous" and a password of your e-mail address. After logging in,
> | type "cd internet-drafts" and then
> | "get draft-ietf-idr-bgp-identifier-01.txt".
> |
> | A list of Internet-Drafts directories can be found in
> | http://www.ietf.org/shadow.html
> | or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> |
> |
> | Internet-Drafts can also be obtained by e-mail.
> |
> | Send a message to:
> | [e-mail].
> | In the body type:
> | "FILE /internet-drafts/draft-ietf-idr-bgp-identifier-01.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
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA08342 for <[e-mail]>; Tue, 17 Sep 2002 14:36:58 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E4A8B91262; Tue, 17 Sep 2002 14:36:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A82FE91263; Tue, 17 Sep 2002 14:36:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 16ABA91262 for <[e-mail]>; Tue, 17 Sep 2002 14:36:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0372E5DFD1; Tue, 17 Sep 2002 14:36:36 -0400 (EDT)
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 C81265DFD0 for <[e-mail]>; Tue, 17 Sep 2002 14:36:35 -0400 (EDT)
Received: from tom3 (usermi36.uk.uudial.com [62.188.122.220]) by shockwave.systems.pipex.net (Postfix) with SMTP id 6A0A016000C78; Tue, 17 Sep 2002 19:36:33 +0100 (BST)
Message-ID: <001601c25e78$bcbec2e0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>, "Susan Hares" <[e-mail]>
Subject: FSM Manual Stop
Date: Tue, 17 Sep 2002 19:32:25 +0100
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

Two minor points in the FSM.

Manual stop resets the ConnectRetryCnt to zero everywhere except when
the FSM is already Idle when Manual stop is ignored.  Is this what is
intended?  Or when in Idle
state, should Manual stop still act as a general reset, resetting
counts and timers?  (Idle state can be entered as things stand with
ConnectRetryCnt non-zero).

And I notice that Manual start is ignored in Active state so if there
is a
need to get from Active to Connect state, then it is necessary to
Manual stop and
then Manual start.  Is this the intended design (as opposed to a
possible oversight)?

Tom Petch
[e-mail]





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 JAA26897 for <[e-mail]>; Tue, 17 Sep 2002 09:27:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F0AF091265; Tue, 17 Sep 2002 09:25:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABAA291266; Tue, 17 Sep 2002 09:25:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F047691265 for <[e-mail]>; Tue, 17 Sep 2002 09:25:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DBF325DF95; Tue, 17 Sep 2002 09:25:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from aibo.runbox.com (aibo.runbox.com [193.71.199.94]) by segue.merit.edu (Postfix) with ESMTP id 7CD385DDB0 for <[e-mail]>; Tue, 17 Sep 2002 09:25:32 -0400 (EDT)
Received: from [10.9.9.9] (helo=fetch.runbox.com) by tramp.runbox.com with esmtp (Exim 4.05-VA-mm1) id 17rIM7-0002pS-00 for [e-mail]; Tue, 17 Sep 2002 15:25:31 +0200
Received: from [203.200.20.226] (helo=Manav) (Authenticated Sender=davidwaters) by fetch.runbox.com with asmtp (Exim 3.35 #1) id 17rILn-0001ql-00 for [e-mail]; Tue, 17 Sep 2002 15:25:11 +0200
Message-ID: <03b401c25e4d$9b8ce4b0$[e-mail]>
From: "David Waters" <[e-mail]>
To: <[e-mail]>
Subject: FW: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt
Date: Tue, 17 Sep 2002 18:54:45 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk

Hello,
I have always been slightly disturbed with this terminology used in BGP i.e
BGP ID. Why cant we like all the other protocols use the term Router ID?
Can it be mentioned explicitly in this document that the BGP ID is nothing
but a Router ID. I gather that it is painfully obvious to the people really
conversant with BGP but it is not so with the newbies !

I had struggled during my initial days with the protocol and i find that
more and more people get confused with this BGP ID. Is there any thought in
the IDR WG to look into this issue.

David.

----- Original Message -----
From: <[e-mail]>
To: <IETF-Announce:>
Cc: <[e-mail]>
Sent: Monday, September 16, 2002 5:16 PM
Subject: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt


| 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 : AS-wide Unique BGP Identifier for BGP-4
| Author(s) : E. Chen, J. Yuan
| Filename : draft-ietf-idr-bgp-identifier-01.txt
| Pages : 4
| Date : 2002-9-13
|
| To accommodate situations where the current requirements for the BGP
| Identifier are not met, this document relaxes the definition of the
| BGP Identifier to be a 4-octet unsigned, non-zero integer, and
| relaxes the 'uniqueness' requirement so that only AS-wide uniqueness
| of the BGP Identifiers is required. These revisions to the base BGP
| specification do not introduce any backward compatibility issue.
|
| A URL for this Internet-Draft is:
| http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-identifier-01.txt
|
| To remove yourself from the IETF Announcement list, send a message to
| ietf-announce-request with the word unsubscribe in the body of the
message.
|
| Internet-Drafts are also available by anonymous FTP. Login with the
username
| "anonymous" and a password of your e-mail address. After logging in,
| type "cd internet-drafts" and then
| "get draft-ietf-idr-bgp-identifier-01.txt".
|
| A list of Internet-Drafts directories can be found in
| http://www.ietf.org/shadow.html
| or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
|
|
| Internet-Drafts can also be obtained by e-mail.
|
| Send a message to:
| [e-mail].
| In the body type:
| "FILE /internet-drafts/draft-ietf-idr-bgp-identifier-01.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




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA21822 for <[e-mail]>; Tue, 17 Sep 2002 06:58:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BC0FA91234; Tue, 17 Sep 2002 06:58:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8FF4F91236; Tue, 17 Sep 2002 06:58:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 44D8F91234 for <[e-mail]>; Tue, 17 Sep 2002 06:58:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 24F215DEF3; Tue, 17 Sep 2002 06:58:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by segue.merit.edu (Postfix) with ESMTP id 668465DE00 for <[e-mail]>; Tue, 17 Sep 2002 06:58:08 -0400 (EDT)
Received: from Bemail06.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g8HAqAI31716 for <[e-mail]>; Tue, 17 Sep 2002 12:52:10 +0200
Received: from alcatel.be ([138.203.191.116]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002091712580655:4292 ; Tue, 17 Sep 2002 12:58:06 +0200 
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 12:58:01 +0200
From: [e-mail]
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: BGP mailing list <[e-mail]>
Subject: Re: BGP4 draft ; section 6.2
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 09/17/2002 12:58:06, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 09/17/2002 12:58:07, Serialize complete at 09/17/2002 12:58:07
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
All,
<p>Thanks for the replies on this question.
<p>I have tried to group all answers I have received sofar below, toegther
with some observations from my side.
<br>&nbsp;
<p>Hans De Vleeschouwer.
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p>Original question:
<blockquote TYPE=CITE>All,
<p>I have a doubt related to section 6.2: OPEN message error handling,
related to the statement:
<p><i>" If one of the optional parameters in the Open mesage is not recognized,
then the error subcode is set to 'unsupported optional parameters"</i>
<p>We have hit on this line when we were testing a BGP connection between
a speaker that supported capability negotiation and a speaker that did
not.
<p>The speaker that did not support the neogotiation closed down the peering
session using the error clause mentioned above.&nbsp; Sometimes this lead
to the other router to repeat the OPEN message with the Capability optional
parameter; a game that went on for minutes.
<p>This router manufacturer stated in a reply to this that :
<blockquote>"One should not close down the connection if an optional parameter
is unrecognised. That would make this parameter basically mandatory.
<p>This is an well known error in the BGP spec. Neither Cisco or Juniper
do this"</blockquote>
If this is true it might be good to adapt the text.
<p>Hans de Vleeschouwer
<br>Alcatel.
<br>&nbsp;</blockquote>
Replies received:
<p>Mathew Richardson wrote:
<blockquote TYPE=CITE>> [e-mail] &lt;[e-mail]>
[Fri, Sep 13, 2002 at 03:43:55PM +0200]:
<p>From rfc2842:
<p>&nbsp;&nbsp; A BGP speaker determines that its peer doesn't support
capabilities
<br>&nbsp;&nbsp; advertisement, if in response to an OPEN message that
carries the
<br>&nbsp;&nbsp; Capabilities Optional Parameter, the speaker receives
a NOTIFICATION
<br>&nbsp;&nbsp; message with the Error Subcode set to Unsupported Optional
Parameter.
<br>&nbsp;&nbsp; In this case the speaker should attempt to re-establish
a BGP
<br>&nbsp;&nbsp; connection with the peer without sending to the peer the
Capabilities
<br>&nbsp;&nbsp; Optional Parameter.
<p>mrr</blockquote>

<p><br>This section from the Capabilities Advertisement RFC, is indeed
inline with the section 6.2 of the BGP4 specification.&nbsp; For me however
the question remains if most implementations do no simply ignore optional
parameters that are unknown. And if so, if the text stated above reflects
what is implemented by routers that do not have capability advertisement
at all.
<p>"Natale, Jonathan" wrote:
<blockquote TYPE=CITE>I just re-read your email; it is the rtr that does
not have capabilities at
<br>all...
<p>1) currently, not too many implementations do the exponential back off
in
<br>response to an error, and the whole FSM thing is being re-hashed now.&nbsp;
So it
<br>will flap.
<p>2) ignoring options (since *I think*(???) capabilities is the only one
used
<br>anywhere) is probably not that bad of an idea since sending capabilities
are
<br>only saying what the sender supports, not what the receiver supports.
<br>Obviously, ignoring capabilities is better when peering with a vendor
that
<br>does not re-open without the capabilities as they should per rfc2842
(or
<br>maybe a config switch for this).&nbsp; This is not spelled out in any
rfc that I
<br>am aware of
<p>3) I do not know about the Juniper side of this.
<p>4) you might want to check the vendor's bugs.
<p>5) I *think* what the vendor was referring to is:
<p>From: Natale, Jonathan [<a href="mailto:[e-mail]">mailto:[e-mail]</a>]
<br>Sent: Tuesday, August 06, 2002 4:19 PM
<br>To: '[e-mail]'
<br>Subject: capability
<p>I would like to propose:
<p>>"If a BGP speaker that supports a certain capability determines that
<br>>&nbsp;&nbsp;&nbsp; its peer doesn't support this capability, the speaker
MAY send a
<br>>&nbsp;&nbsp;&nbsp; NOTIFICATION message to the peer, and terminate
peering (see Section
<br>>&nbsp;&nbsp;&nbsp; "Extensions to Error Handling" for more details).
The Error Subcode
<br>>&nbsp;&nbsp;&nbsp; in the message is set to Unsupported Capability.
The message SHOULD
<br>>&nbsp;&nbsp;&nbsp; contain the capability (capabilities) that causes
the speaker to send
<br>>&nbsp;&nbsp;&nbsp; the message.&nbsp; The decision to send the message
and terminate peering
<br>>&nbsp;&nbsp;&nbsp; is local to the speaker. If terminated, such peering
SHOULD NOT be
<br>>&nbsp;&nbsp;&nbsp; re-established automatically."
<br>>
<br>>be changed to:
<br>>
<br>>"If a BGP speaker that **does not want its peer to support** a certain
<br>>capability determines that
<br>>&nbsp;&nbsp;&nbsp; its peer **does** support this capability, the
speaker MAY send a
<br>>&nbsp;&nbsp;&nbsp; NOTIFICATION message to the peer, and terminate
peering (see Section
<br>>&nbsp;&nbsp;&nbsp; "Extensions to Error Handling" for more details).
The Error Subcode
<br>>&nbsp;&nbsp;&nbsp; in the message is set to Unsupported Capability.
The message SHOULD
<br>>&nbsp;&nbsp;&nbsp; contain the capability (capabilities) that causes
the speaker to send
<br>>&nbsp;&nbsp;&nbsp; the message.&nbsp; The decision to send the message
and terminate peering
<br>>&nbsp;&nbsp;&nbsp; is local to the speaker. **If terminated, the peer
MAY re-open the
<br>>&nbsp;&nbsp;&nbsp; connection without the offending capability-this
is known as capability
<br>>&nbsp;&nbsp;&nbsp; negotiation.**"
<br>>
<p>... The response I got was basically that the draft is already done.
<br>&nbsp;</blockquote>
Here I find 3 elements:
<p>1. the matter of the exponential backoff. This is indeed an interesting
thing, since I have noticed during testing that most routers do not seem
to do this, at least not in all cases (e.g. no exponential backoff in case
of a TCP connection that fails with an RST message.).
<br>However, as I understood this matter is subject of new ongoing work,
and is therefore not part of the current rework of the BGP draft?
<p>2. the reaction to unrecognised TLVs. Here I understand that Mathew
is prepared to discuss changing the way a peer should react to such an
event, i.e. changing the wording of section 6.2 so that&nbsp; unrecognised
optional TLVs should be ignored.
<p>3. the reaction to an 'undesired' capability. This again is an interesting
question that is to my opinion not fully clear (several vendors again react
differently in this case). However it is taking the original problem one
step further, so I would like to have this outside of this discussion for
now.
<br>&nbsp;
<br>&nbsp;</html>



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA19511 for <[e-mail]>; Tue, 17 Sep 2002 05:52:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0415791218; Tue, 17 Sep 2002 05:51:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5CA291234; Tue, 17 Sep 2002 05:51:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8101491218 for <[e-mail]>; Tue, 17 Sep 2002 05:51:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 691C55DEC3; Tue, 17 Sep 2002 05:51:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by segue.merit.edu (Postfix) with ESMTP id 9C10D5DE00 for <[e-mail]>; Tue, 17 Sep 2002 05:51:51 -0400 (EDT)
Received: from Bemail06.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g8H9jax08811; Tue, 17 Sep 2002 11:45:44 +0200
Received: from alcatel.be ([138.203.191.116]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002091711513179:3771 ; Tue, 17 Sep 2002 11:51:31 +0200 
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 11:51:27 +0200
From: [e-mail]
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Abarbanel, Benjamin" <[e-mail]>, BGP mailing list <[e-mail]>
Subject: Re: BGP4 draft ; section 6.2
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 09/17/2002 11:51:31, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 09/17/2002 11:51:40, Serialize complete at 09/17/2002 11:51:40
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Ben,
<p>I am not always fully focussed to the worklist as I&nbsp; guess I should
be&nbsp; ;-(.&nbsp;&nbsp; So I guess I must have missed your mail on this.
If you still have this mail I would really appreciate it if you could forward
it again.
<p>Thanks,
<br>Hans
<p>"Abarbanel, Benjamin" wrote:
<blockquote TYPE=CITE>&nbsp;<span 
class=249331114-13092002><font face="Arial"><font color="#0000FF"><font size=-1>Hans:</font></font></font></span><span class=249331114-13092002><font face="Arial"><font color="#0000FF"><font size=-1>I
wonder why you have not responded to my previous email?</font></font></font></span><span 
class=249331114-13092002></span><span 
class=249331114-13092002><font face="Arial"><font color="#0000FF"><font size=-1>Ben</font></font></font></span><span 
class=249331114-13092002></span><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> [e-mail]
[<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Friday, September 13,
2002 9:44 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> BGP mailing list</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> BGP4 draft ; section
6.2</font></font>
<br>&nbsp;
<blockquote 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">All,
<p>I have a doubt related to section 6.2: OPEN message error handling,
related to the statement:
<p><i>" If one of the optional parameters in the Open mesage is not recognized,
then the error subcode is set to 'unsupported optional parameters"</i>
<p>We have hit on this line when we were testing a BGP connection between
a speaker that supported capability negotiation and a speaker that did
not.
<p>The speaker that did not support the neogotiation closed down the peering
session using the error clause mentioned above.&nbsp; Sometimes this lead
to the other router to repeat the OPEN message with the Capability optional
parameter; a game that went on for minutes.
<p>This router manufacturer stated in a reply to this that :
<blockquote>"One should not close down the connection if an optional parameter
is unrecognised. That would make this parameter basically mandatory.
<p>This is an well known error in the BGP spec. Neither Cisco or Juniper
do this"</blockquote>

<p><br>If this is true it might be good to adapt the text.
<p>Hans de Vleeschouwer
<br>Alcatel.
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;</blockquote>
</blockquote>
</html>



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA13816 for <[e-mail]>; Tue, 17 Sep 2002 03:05:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8606A91258; Tue, 17 Sep 2002 03:05:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0706991259; Tue, 17 Sep 2002 03:05:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 327BD91258 for <[e-mail]>; Tue, 17 Sep 2002 03:03:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EAA865DE8B; Tue, 17 Sep 2002 03:03:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by segue.merit.edu (Postfix) with ESMTP id 507A65DDA2 for <[e-mail]>; Tue, 17 Sep 2002 03:03:29 -0400 (EDT)
Received: from Bemail06.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g8H6vSV30252 for <[e-mail]>; Tue, 17 Sep 2002 08:57:28 +0200
Received: from alcatel.be ([138.203.191.116]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002091709032375:1969 ; Tue, 17 Sep 2002 09:03:23 +0200 
Message-ID: <[e-mail]>
Date: Tue, 17 Sep 2002 09:03:20 +0200
From: [e-mail]
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: BGP mailing list <[e-mail]>
Subject: general remark on the ongoing review 
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 09/17/2002 09:03:23, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 09/17/2002 09:03:24, Serialize complete at 09/17/2002 09:03:24
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Just a thought...

I have seen so many comments recently on various parts of the current
draft (version 17), that, for me at least, it becomes hard to know what
is by now changed in the text and what is not. This in turn makes it
hard to review the text completely.

Would it be an idea to re-issue the document (e.g. as a draft-18) so
that we can have a look on how the document looks like now, to make sure
we all look at the same document again?


hans De Vleeschouwer
  Alcatel.





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA12868 for <[e-mail]>; Tue, 17 Sep 2002 02:41:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5B62B91256; Tue, 17 Sep 2002 02:41:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2302091258; Tue, 17 Sep 2002 02:41:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BDEA391256 for <[e-mail]>; Tue, 17 Sep 2002 02:41:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id ADD1C5DE7C; Tue, 17 Sep 2002 02:41:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from smtp.cwnt.com (smtp.cwnt.com [192.116.246.129]) by segue.merit.edu (Postfix) with ESMTP id ABF675DDA2 for <[e-mail]>; Tue, 17 Sep 2002 02:41:17 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: BGP4 draft ; section 6.2
Date: Tue, 17 Sep 2002 09:41:16 +0300
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: BGP4 draft ; section 6.2
Thread-Index: AcJbPERtOknZ/gb2THeR9Othi3XEKAC2O+xQ
From: "David Margulis" <[e-mail]>
To: "BGP mailing list" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id CAA12868

-----Original Message-----
From: Natale, Jonathan [mailto:[e-mail]]
Sent: Friday, September 13, 2002 6:43 PM
To: '[e-mail]'; BGP mailing list
Subject: RE: BGP4 draft ; section 6.2


I just re-read your email; it is the rtr that does not have capabilities at
all...

1) currently, not too many implementations do the exponential back off in
response to an error, and the whole FSM thing is being re-hashed now.  So it
will flap.

2) ignoring options (since *I think*(???) capabilities is the only one used
anywhere) is probably not that bad of an idea since sending capabilities are
only saying what the sender supports, not what the receiver supports.
Obviously, ignoring capabilities is better when peering with a vendor that
does not re-open without the capabilities as they should per rfc2842 (or
maybe a config switch for this).  This is not spelled out in any rfc that I
am aware of

3) I do not know about the Juniper side of this.
 
4) you might want to check the vendor's bugs.
     
5) I *think* what the vendor was referring to is:

From: Natale, Jonathan [mailto:[e-mail]] 
Sent: Tuesday, August 06, 2002 4:19 PM
To: '[e-mail]'
Subject: capability

I would like to propose:

>"If a BGP speaker that supports a certain capability determines that
>    its peer doesn't support this capability, the speaker MAY send a
>    NOTIFICATION message to the peer, and terminate peering (see Section
>    "Extensions to Error Handling" for more details). The Error Subcode
>    in the message is set to Unsupported Capability. The message SHOULD
>    contain the capability (capabilities) that causes the speaker to send
>    the message.  The decision to send the message and terminate peering
>    is local to the speaker. If terminated, such peering SHOULD NOT be
>    re-established automatically."
>
>be changed to:
>
>"If a BGP speaker that **does not want its peer to support** a certain
>capability determines that
>    its peer **does** support this capability, the speaker MAY send a
>    NOTIFICATION message to the peer, and terminate peering (see Section
>    "Extensions to Error Handling" for more details). The Error Subcode
>    in the message is set to Unsupported Capability. The message SHOULD
>    contain the capability (capabilities) that causes the speaker to send
>    the message.  The decision to send the message and terminate peering
>    is local to the speaker. **If terminated, the peer MAY re-open the
>    connection without the offending capability-this is known as capability
>    negotiation.**"
>

... The response I got was basically that the draft is already done.


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] 
Sent: Friday, September 13, 2002 9:44 AM
To: BGP mailing list
Subject: BGP4 draft ; section 6.2

All, 
I have a doubt related to section 6.2: OPEN message error handling, related
to the statement: 
" If one of the optional parameters in the Open mesage is not recognized,
then the error subcode is set to 'unsupported optional parameters" 
We have hit on this line when we were testing a BGP connection between a
speaker that supported capability negotiation and a speaker that did not. 
The speaker that did not support the neogotiation closed down the peering
session using the error clause mentioned above.  Sometimes this lead to the
other router to repeat the OPEN message with the Capability optional
parameter; a game that went on for minutes. 
This router manufacturer stated in a reply to this that : 
"One should not close down the connection if an optional parameter is
unrecognised. That would make this parameter basically mandatory. 
This is an well known error in the BGP spec. Neither Cisco or Juniper do
this"

If this is true it might be good to adapt the text. 
Hans de Vleeschouwer 
Alcatel. 
  
  
 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA12835 for <[e-mail]>; Tue, 17 Sep 2002 02:40:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D07F291255; Tue, 17 Sep 2002 02:40:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A035491256; Tue, 17 Sep 2002 02:40:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5BD9D91255 for <[e-mail]>; Tue, 17 Sep 2002 02:40:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 38AB45DE8B; Tue, 17 Sep 2002 02:40:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from smtp.cwnt.com (smtp.cwnt.com [192.116.246.129]) by segue.merit.edu (Postfix) with ESMTP id 411995DDA2 for <[e-mail]>; Tue, 17 Sep 2002 02:40:15 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: BGP4 draft ; section 6.2
Date: Tue, 17 Sep 2002 09:40:09 +0300
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: BGP4 draft ; section 6.2
Thread-Index: AcJbLvsZc8NW7yOkRIGKbG1o8XY9BwC5eH0g
From: "David Margulis" <[e-mail]>
To: "David Margulis" <[e-mail]>
Cc: "BGP mailing list" <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id CAA12835

-----Original Message-----
From: Mathew Richardson [mailto:[e-mail]]
Sent: Friday, September 13, 2002 5:08 PM
To: [e-mail]
Cc: BGP mailing list
Subject: Re: BGP4 draft ; section 6.2


> [e-mail] <[e-mail]> [Fri, Sep 13, 2002 at 03:43:55PM +0200]:

>From rfc2842:

   A BGP speaker determines that its peer doesn't support capabilities
   advertisement, if in response to an OPEN message that carries the
   Capabilities Optional Parameter, the speaker receives a NOTIFICATION
   message with the Error Subcode set to Unsupported Optional Parameter.
   In this case the speaker should attempt to re-establish a BGP
   connection with the peer without sending to the peer the Capabilities
   Optional Parameter.

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 VAA02890 for <[e-mail]>; Mon, 16 Sep 2002 21:55:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0AAD89129B; Mon, 16 Sep 2002 21:55:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C64009129C; Mon, 16 Sep 2002 21:55:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F7F09129B for <[e-mail]>; Mon, 16 Sep 2002 21:55:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4E9365DE29; Mon, 16 Sep 2002 21:55:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 9DA915DD92 for <[e-mail]>; Mon, 16 Sep 2002 21:55:26 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8H1tMm50880; Mon, 16 Sep 2002 18:55:22 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Tom Petch" <[e-mail]>
Cc: "Martin, Christian" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
In-Reply-To: Your message of "Mon, 16 Sep 2002 14:53:06 BST." <00e601c25d88$7b65cdc0$0301a8c0@tom3> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 16 Sep 2002 18:55:22 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Tom,

> I prefer Yakov's formulation but suggest turning the long sentence
> around thus:
> (! denotes changed text).
> 
> 
>      Routing information exchanged via BGP supports only the
>      destination-based forwarding paradigm, which assumes that a
>      router forwards a packet based solely on the destination address
>      carried in the IP header of the packet. This, in turn, reflects
>      the set of policy decisions that can (and can not) be enforced*
>      using BGP. Note that some policies cannot be supported by the
>      destination-based forwarding paradigm, and thus require
> techniques
>      such as source routing (aka explicit routing) to be enforced*.
> Such
>      policies can not be enforced using BGP either. For example,
>      BGP does not enable one AS to send traffic
> !    to a neighboring AS for forwarding to some destination (reachable
> through but) beyond
> !    that neighboring AS intending that
> !    the traffic take a different route to that taken by the traffic
> !    originating in the neighboring AS (for that same destination).
> 
>      On the other hand, BGP can support any policy conforming to
>      the destination-based forwarding paradigm.

The changes you proposed are fine.

Yakov.

> 
> 
> 
> Tom Petch
> [e-mail]
> 
> -----Original Message-----
> From: Martin, Christian <[e-mail]>
> To: 'Yakov Rekhter' <[e-mail]>; Martin, Christian
> <[e-mail]>
> Cc: '[e-mail]' <[e-mail]>
> Date: 15 September 2002 21:03
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive
> 
> 
> >Yakov,
> >
> >I see what you are trying to say, but it took me a few reads.  What
> we are
> >saying is that BGP policy local to an AS cannot affect a path that a
> >neighboring AS uses to continue downstream.  This is hard to say in
> any
> >succinct way, and the sentence is pretty long.
> >
> >Maybe something like this:
> >
> >    Routing information exchanged via BGP supports only the
>    destination-based forwarding paradigm, which assumes that a
> >    router forwards a packet based solely on the destination address
> >    carried in the IP header of the packet. This, in turn, reflects
> >    the set of policy decisions that can (and can not) be enforces
> >    using BGP. Note that some policies cannot be supported by the
> >    destination-based forwarding paradigm, and thus require
> techniques
> >    such as source routing (aka explicit routing) to enforce. Such
> >    policies can not be enforced using BGP either. For example,
> >    BGP does not enable one AS to send traffic through a neighboring
> >    AS to some destination beyond the neighboring AS intending that
> >    the traffic take a different route from that taken by traffic
> >    to the same destination which originates in the neighboring AS.
> >    In other words, the BGP policy of a local AS cannot affect the
> >    downstream (aka, away from the local AS) forwarding policy of a
> >    remote AS.  On the other hand, BGP can support any policy
> conforming
> >    to the destination-based forwarding paradigm.
> >
> >-chris
> >
> >> -----Original Message-----
> >> From: Yakov Rekhter [mailto:[e-mail]]
> >> Sent: Sunday, September 15, 2002 3:25 PM
> >> To: Martin, Christian
> >> Cc: Natale, Jonathan; '[e-mail]'
> >> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise
> inactive
> >>
> >>
> >> Martin,
> >>
> >> > Yakov,
> >> >
> >> > In both examples below, it would appear that BGP does not have
> the
> >> > capability to affect asymmetric routing, which it clearly
> >> does as is
> >> > evidenced by traffic on the Internet today.  Perhaps it
> >> would be more
> >> > clear to use an example that is more congruent with the
> >> > destination-based vs source-based argument you are making.
> >> >
> >> > IE:
> >> >
> >> >    Routing information exchanged via BGP supports only the
> >> >    destination-based forwarding paradigm, which assumes that a
> >> >    router forwards a packet based solely on the destination
> address
> >> >    carried in the IP header of the packet. This, in turn reflects
> >> >    the set of policy decisions that can (and can not) be enforces
> >> >    using BGP. Note that some policies cannot be supported by the
> >> >    destination-based forwarding paradigm and thus require
> techniques
> >> >    such as source routing (aka explicit routing) to enforce. Such
> >> >    policies can not be enforced using BGP either. For example,
> BGP
> >> >    does not enable one AS to send traffic to a neighboring AS
> >> >    based on prefixes originating from the local AS.  On the
> >> >    other hand, BGP can support any policy conforming to the
> >> >    destination-based forwarding paradigm.
> >>
> >> How about the following:
> >>
> >>     Routing information exchanged via BGP supports only the
> >>     destination-based forwarding paradigm, which assumes that a
> >>     router forwards a packet based solely on the destination
> address
> >>     carried in the IP header of the packet. This, in turn, reflects
> >>     the set of policy decisions that can (and can not) be enforces
> >>     using BGP. Note that some policies cannot be supported by the
> >>     destination-based forwarding paradigm, and thus require
> techniques
> >>     such as source routing (aka explicit routing) to enforce. Such
> >>     policies can not be enforced using BGP either. For example,
> >>     BGP does not enable one AS to send traffic through a
> neighboring
> >>     AS to some destination (which is outside of the neighboring
> >>     AS, but is reachable through the neighboring AS) intending that
> >>     the traffic take a different route from that taken by the
> traffic
> >>     to the same destination that originating in the neighboring AS.
> >>     On the other hand, BGP can support any policy conforming to
> >>     the destination-based forwarding paradigm.
> >>
> >> 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 SAA25263 for <[e-mail]>; Mon, 16 Sep 2002 18:44:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 40E3791298; Mon, 16 Sep 2002 18:44:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C57B9129A; Mon, 16 Sep 2002 18:44:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BDD2F91298 for <[e-mail]>; Mon, 16 Sep 2002 18:44:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A20045DE2F; Mon, 16 Sep 2002 18:44:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 77EEC5DE0E for <[e-mail]>; Mon, 16 Sep 2002 18:44:08 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17r4b9-000AoG-00; Mon, 16 Sep 2002 15:44:07 -0700
Date: Mon, 16 Sep 2002 15:41:24 -0700
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: Bill Fenner <[e-mail]>, [e-mail]
Subject: Re: BGP spec and IDR WG charter
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Yakov,

>> I admit I made a mistake forwarding draft-ietf-idr-md5-keys to the
>> IESG without it being on the WG charter.  I'll try not to make such
>> mistakes in the future.

> So, what is the current status on that draft ?

It's been to an IESG telechat, where some issues were raised. We'll
follow up on this separately.

>> >3. The WG completed the work on the extended communities and submitted 
>> >   the draft to the IESG 3 weeks before you informed the WG
>> >   about the Routing Area Directors' decision not to forward any 
>> >   IDR documents for IESG considerations until the base BGP spec update 
>> >   is finished.
>> 
>> Actually, we're going to include extended communities in the work
>> that's held up.  There's something that I didn't understand about the
>> IETF process until I became an AD, and although we've tried to explain
>> it to some extent (e.g. Thomas and Allison's "life of an I-D" plenary
>> presentation last year) it's probably still not widely understood.
>> Working Groups submit documents to their ADs; the AD then reviews the
>> document, possibly asks the WG for changes, and then submits it to the
>> IESG for consideration.  Since I had not yet finished my review of this
>> document when we made this decision, we will not be forwarding it to the
>> IESG until the base spec is finished.

> Ok.

> On a related topic, in order for us to put specific dates in the charter
> we need to know how long it would take the IESG to process BGP base
> spec from the moment the WG would forward the spec to you and Alex.

Here's an approximation:

 Stage           Anticipated delay          Comment
----------------------------------------------------------------------------
 AD-review       1--4 weeks                 The document may go back to the
                 depending on workload      WG for the AD-review comments
                                            to be addressed; this would
                                            introduce additional delay.

 IETF LC         2 weeks                    Same as above

 IESG review&    1--2 weeks depending       Same as above
 telechat        on when the IETF LC ends
----------------------------------------------------------------------------

Note that if the document is sent back to the WG at some stage, required
changes may warrant an additional WG Last Call.

I can personally commit to a 2-week upper bound for the AD-review
period. Bill may have a different timer granularity.

Alex




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA24488 for <[e-mail]>; Mon, 16 Sep 2002 18:23:16 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7686091259; Mon, 16 Sep 2002 18:22:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4025591298; Mon, 16 Sep 2002 18:22:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E12E791259 for <[e-mail]>; Mon, 16 Sep 2002 18:22:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BF4955DDE5; Mon, 16 Sep 2002 18:22:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 961705DDCB for <[e-mail]>; Mon, 16 Sep 2002 18:22:46 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17r4GP-0009eb-00; Mon, 16 Sep 2002 15:22:41 -0700
Date: Mon, 16 Sep 2002 15:20:04 -0700
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Curtis Villamizar <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Curtis,

Wednesday, September 11, 2002, 5:43:05 PM, Curtis Villamizar wrote:
[...]
> ps - The WG chairs, ADs, or others can chime in but IMHO the bounds,
> stated in part in prior messages, should be the following.

>   1) If the document is incorrect, incomplete, or ambiguous, it has a
>      flaw and needs to be changed.  Changing the protocol itself,
>      except to reflect current implementation of multiple vendors, is
>      out of bounds.  [under that assumption that by now we've made the
>      implmentations work].

Correct

> Changes to reflect a single vendor's
>      idiosyncracies are out of bounds, particularly if no
>      interoperability issues exist.

"no interoperability issue" is key here. If in reality people have
to guess or reverse-engineer specific behavior of a particular
vendor's implementation (for instance because that particular vendor
has a large installed base, and one just can't go into a network
without it) even though that behavior does not follow what
the current spec says, I'd rather see this documented somehow (note
the difference between "documenting" and "mandating").

>   2) If the document is unclear to the well qualified reader (one
>      possessing a thorough understanding of foundations of this work,
>      including IP routing, TCP, TCP programming, and the referenced
>      documents)

+ ", and not including knowledge of BGP implementations, BGP-related
books, articles or e-mail discussions"

> then the document may need to be changed to improve
>      clarity.

>   3) Editorial or document organization changes that would clearly
>      improve clarity of the document in areas where clarity is
>      deficient to the well qualified and carefull reader are welcome.
>      Addition of background tutorial information is out of bounds.

> This may help us make real progress.  In the past we haven't had to
> explicitly state this but I think this time we do.  We seem to be
> bogged down in minutia.

I guess Curtis'es point here is to make sure we do not go over the
line of putting in stuff that does not belong in the spec, and my
point is to make sure we do not abuse any formal or informal rules and
drop stuff important for interoperability because of this. Let's keep
the final goal in mind--making possible the development of independent
and interoperable implementations.

Alex




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA22749 for <[e-mail]>; Mon, 16 Sep 2002 17:26:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DE37691258; Mon, 16 Sep 2002 17:26:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1B0E91259; Mon, 16 Sep 2002 17:26:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3646C91258 for <[e-mail]>; Mon, 16 Sep 2002 17:26:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 245A55DDDF; Mon, 16 Sep 2002 17:26:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id DEFDF5DDDD for <[e-mail]>; Mon, 16 Sep 2002 17:26:33 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17r3O4-0006a5-00 for [e-mail]; Mon, 16 Sep 2002 14:26:32 -0700
Date: Mon, 16 Sep 2002 14:24:11 -0700
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: Atmosphere in the WG
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

A couple of requests here:

1) Don't *make* it personal, and don't *take* it personal, please.

2) WG chairs, please foster a healthy, open, and cooperative
   environment in the WG.

Thanks.

-- 
Alex

Wednesday, September 11, 2002, 2:25:52 PM, Abarbanel, Benjamin wrote:
> Yakov,

> I dont want this thread to turn into being absurd. So lets drop the topic
> I dont think we are getting anywhere here.

> I just made an innocent comment about fixing the meaning of some text. I
> apologize to all those who are offended by my review of the spec.


> Thank You,
> Ben

>> -----Original Message-----
>> From: Yakov Rekhter [mailto:[e-mail]]
>> Sent: Wednesday, September 11, 2002 5:22 PM
>> To: Abarbanel, Benjamin
>> Cc: 'Yakov Rekhter'; 'Justin Fletcher'; [e-mail]; Alex Zinin
>> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
>> 
>> 
>> > Just common sense, knowing how BGP, TCP and sockets work. I 
>> guess I made
>> > too a general statement, 
>> 
>> I think you are correct on this.
>> 
>> >                             maybe I should have said all 
>> implementations
>> > I looked at do it this way. 
>> 
>> That would certainly be more accurate. It would be even better if you
>> would say how many implementations you looked at.
>> 
>> Yakov.
>>   
>> > > -----Original Message-----
>> > > From: Yakov Rekhter [mailto:[e-mail]]
>> > > Sent: Wednesday, September 11, 2002 5:09 PM
>> > > To: Abarbanel, Benjamin
>> > > Cc: 'Justin Fletcher'; [e-mail]; Alex Zinin
>> > > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
>> > > 
>> > > 
>> > > Ben,
>> > > 
>> > > > At some point the wisdom of the day was to put this in. 
>> Now its too
>> > > > implementation specific, and people want to remove it. 
>> When in fact 
>> > > > everyone who builds BGP code does it this way.
>> > > 
>> > > Are you 100% sure that "everyone who builds BGP code does it 
>> > > this way" ?
>> > > (Did you actually check this with *everyone* who builds BGP ?)
>> > > 
>> > > Yakov.
>> > > 
>> > > > I see no reason why section Appendix 6.2 should be deleted. 
>> > > > 
>> > > > Thank You,
>> > > > Ben
>> > > > 
>> > > > > -----Original Message-----
>> > > > > From: Justin Fletcher [mailto:[e-mail]]
>> > > > > Sent: Wednesday, September 11, 2002 5:01 PM
>> > > > > To: [e-mail]
>> > > > > Cc: Alex Zinin; Yakov Rekhter; Abarbanel, Benjamin
>> > > > > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
>> > > > > 
>> > > > > 
>> > > > > On Wed, 2002-09-11 at 13:30, Curtis Villamizar wrote:
>> > > > > > 
>> > > > > > In message <[e-mail]>, Alex 
>> > > Zinin writes:
>> > > > > > > Yakov, Ben-
>> > > > > > > 
>> > > > > > >  I thought section 6.2 "Processing Messages on a 
>> > > Stream Protocol"
>> > > > > > >  actually talked about these things...
>> > > > > > > 
>> > > > > > > -- 
>> > > > > > > Alex
>> > > > > > 
>> > > > > > 
>> > > > > > A you suggesting we turn the terse reminder in the 
>> > > appendix into a
>> > > > > > full TCP programming tutorial?
>> > > > > > 
>> > > > > > Maybe we should just change that section to.
>> > > > > > 
>> > > > > >   6.2  Processing Messages on a Stream Protocol
>> > > > > > 
>> > > > > >      BGP uses TCP as a transport mechanism.  If you are 
>> > > unsure as to
>> > > > > >      how to handle asynchronous reads and writes on TCP 
>> > > > > sockets please
>> > > > > >      refer to Unix Network Programming [RWStevens] or other
>> > > > > >      introductory text for programming techniques for 
>> > > the operating
>> > > > > >      system and TCP implementation that you are using.
>> > > > > > 
>> > > > > > That would save having to rewrite major parts of Stevens 
>> > > > > work into the
>> > > > > > BGP spec.
>> > > > > > 
>> > > > > > Curtis
>> > > > > 
>> > > > > Perhaps the entire section should be deleted as beyond scope.
>> > > > > 
>> > > > > Justin Fletcher
>> > > > > 
>> > > > > 
>> > > 
>> 




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA21835 for <[e-mail]>; Mon, 16 Sep 2002 16:59:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D363191255; Mon, 16 Sep 2002 16:58:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A312591258; Mon, 16 Sep 2002 16:58:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6E71E91255 for <[e-mail]>; Mon, 16 Sep 2002 16:58:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5C4EE5DDDD; Mon, 16 Sep 2002 16:58:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 351755DDCF for <[e-mail]>; Mon, 16 Sep 2002 16:58:44 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17r2x7-00057q-00; Mon, 16 Sep 2002 13:58:41 -0700
Date: Mon, 16 Sep 2002 13:56:26 -0700
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, Justin Fletcher <[e-mail]>, <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Wednesday, September 11, 2002, 2:11:39 PM, Yakov Rekhter wrote:
> Ben,

>> Yakov,
>>   Dont we need the WG ADS approval to remove sections from the document?
>>   (e.g. FSM Section to be deleted)

> I don't recall seeing this requirement in the RFCs that document
> the IETF process.

Correct. This is a WG detail. Feedback from the ADs maybe considered
as hints about what the ADs will be looking for during the document
review. In the FSM case, the ADs would be really surprised if no FSM
description was in the spec. In the case of section 6.2, I personally
do not see a reason to remove it from the spec (it is in the appendix
anyways), but I won't raise a flag if the WG decides to do so.

Alex




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA20808 for <[e-mail]>; Mon, 16 Sep 2002 16:28:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1B39B91296; Mon, 16 Sep 2002 16:28:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D6CC891297; Mon, 16 Sep 2002 16:28:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A085F91296 for <[e-mail]>; Mon, 16 Sep 2002 16:28:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8FDBF5DDC2; Mon, 16 Sep 2002 16:28:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 684995DD9D for <[e-mail]>; Mon, 16 Sep 2002 16:28:13 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17r2TP-0003cA-00; Mon, 16 Sep 2002 13:27:59 -0700
Date: Mon, 16 Sep 2002 13:25:53 -0700
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, "'John G. Scudder'" <[e-mail]>, <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Yakov, Ben, folks-

Wednesday, August 21, 2002, 6:28:00 PM, Alex Zinin wrote:
[...]
> Regarding your note on FSM, I strongly believe that FSM should
> be part of the spec.

No changes since then :) I think there being a separate draft
describing the FSM might have confused Ben into believing that
it would evolve as a separate document.

-- 
Alex

Wednesday, September 11, 2002, 11:21:16 AM, Yakov Rekhter wrote:
> Ben,

>> > Ben and John,
>> > 
>> > [clipped...]
>> > 
>> > > > At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>> > > > >8. Since there is going to be an FSM spec, do we need to have FSM
>> > > > >    descriptions in this spec. Maybe the FSM section should 
>> > > > be delete.
>> > > > 
>> > > > Yep.
>> > > > 
>> > > OK.
>> > 
>> > Just to make clear, are you suggesting to take section 8 ("8. 
>> > BGP Finite State machine.") out of the base spec draft ?
>> > 
>> Yes, or when the FSM draft becomes a WG document.

> I'd like to hear comments from the ADs (Alex and Bill) on this proposal.

> 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 JAA05480 for <[e-mail]>; Mon, 16 Sep 2002 09:57:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9DC1991256; Mon, 16 Sep 2002 09:56:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6569A91257; Mon, 16 Sep 2002 09:56:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F00B291256 for <[e-mail]>; Mon, 16 Sep 2002 09:56:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D9ECB5DF50; Mon, 16 Sep 2002 09:56:46 -0400 (EDT)
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 779795DD93 for <[e-mail]>; Mon, 16 Sep 2002 09:56:46 -0400 (EDT)
Received: from tom3 (useraq95.uk.uudial.com [62.188.136.155]) by colossus.systems.pipex.net (Postfix) with SMTP id 7074D16000C0A; Mon, 16 Sep 2002 14:56:43 +0100 (BST)
Message-ID: <00e601c25d88$7b65cdc0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Martin, Christian" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
Date: Mon, 16 Sep 2002 14:53:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

I prefer Yakov's formulation but suggest turning the long sentence
around thus:
(! denotes changed text).


     Routing information exchanged via BGP supports only the
     destination-based forwarding paradigm, which assumes that a
     router forwards a packet based solely on the destination address
     carried in the IP header of the packet. This, in turn, reflects
     the set of policy decisions that can (and can not) be enforced*
     using BGP. Note that some policies cannot be supported by the
     destination-based forwarding paradigm, and thus require
techniques
     such as source routing (aka explicit routing) to be enforced*.
Such
     policies can not be enforced using BGP either. For example,
     BGP does not enable one AS to send traffic
!    to a neighboring AS for forwarding to some destination (reachable
through but) beyond
!    that neighboring AS intending that
!    the traffic take a different route to that taken by the traffic
!    originating in the neighboring AS (for that same destination).

     On the other hand, BGP can support any policy conforming to
     the destination-based forwarding paradigm.



Tom Petch
[e-mail]

-----Original Message-----
From: Martin, Christian <[e-mail]>
To: 'Yakov Rekhter' <[e-mail]>; Martin, Christian
<[e-mail]>
Cc: '[e-mail]' <[e-mail]>
Date: 15 September 2002 21:03
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive


>Yakov,
>
>I see what you are trying to say, but it took me a few reads.  What
we are
>saying is that BGP policy local to an AS cannot affect a path that a
>neighboring AS uses to continue downstream.  This is hard to say in
any
>succinct way, and the sentence is pretty long.
>
>Maybe something like this:
>
>    Routing information exchanged via BGP supports only the
>    destination-based forwarding paradigm, which assumes that a
>    router forwards a packet based solely on the destination address
>    carried in the IP header of the packet. This, in turn, reflects
>    the set of policy decisions that can (and can not) be enforces
>    using BGP. Note that some policies cannot be supported by the
>    destination-based forwarding paradigm, and thus require
techniques
>    such as source routing (aka explicit routing) to enforce. Such
>    policies can not be enforced using BGP either. For example,
>    BGP does not enable one AS to send traffic through a neighboring
>    AS to some destination beyond the neighboring AS intending that
>    the traffic take a different route from that taken by traffic
>    to the same destination which originates in the neighboring AS.
>    In other words, the BGP policy of a local AS cannot affect the
>    downstream (aka, away from the local AS) forwarding policy of a
>    remote AS.  On the other hand, BGP can support any policy
conforming
>    to the destination-based forwarding paradigm.
>
>-chris
>
>> -----Original Message-----
>> From: Yakov Rekhter [mailto:[e-mail]]
>> Sent: Sunday, September 15, 2002 3:25 PM
>> To: Martin, Christian
>> Cc: Natale, Jonathan; '[e-mail]'
>> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise
inactive
>>
>>
>> Martin,
>>
>> > Yakov,
>> >
>> > In both examples below, it would appear that BGP does not have
the
>> > capability to affect asymmetric routing, which it clearly
>> does as is
>> > evidenced by traffic on the Internet today.  Perhaps it
>> would be more
>> > clear to use an example that is more congruent with the
>> > destination-based vs source-based argument you are making.
>> >
>> > IE:
>> >
>> >    Routing information exchanged via BGP supports only the
>> >    destination-based forwarding paradigm, which assumes that a
>> >    router forwards a packet based solely on the destination
address
>> >    carried in the IP header of the packet. This, in turn reflects
>> >    the set of policy decisions that can (and can not) be enforces
>> >    using BGP. Note that some policies cannot be supported by the
>> >    destination-based forwarding paradigm and thus require
techniques
>> >    such as source routing (aka explicit routing) to enforce. Such
>> >    policies can not be enforced using BGP either. For example,
BGP
>> >    does not enable one AS to send traffic to a neighboring AS
>> >    based on prefixes originating from the local AS.  On the
>> >    other hand, BGP can support any policy conforming to the
>> >    destination-based forwarding paradigm.
>>
>> How about the following:
>>
>>     Routing information exchanged via BGP supports only the
>>     destination-based forwarding paradigm, which assumes that a
>>     router forwards a packet based solely on the destination
address
>>     carried in the IP header of the packet. This, in turn, reflects
>>     the set of policy decisions that can (and can not) be enforces
>>     using BGP. Note that some policies cannot be supported by the
>>     destination-based forwarding paradigm, and thus require
techniques
>>     such as source routing (aka explicit routing) to enforce. Such
>>     policies can not be enforced using BGP either. For example,
>>     BGP does not enable one AS to send traffic through a
neighboring
>>     AS to some destination (which is outside of the neighboring
>>     AS, but is reachable through the neighboring AS) intending that
>>     the traffic take a different route from that taken by the
traffic
>>     to the same destination that originating in the neighboring AS.
>>     On the other hand, BGP can support any policy conforming to
>>     the destination-based forwarding paradigm.
>>
>> 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 HAA01013 for <[e-mail]>; Mon, 16 Sep 2002 07:48:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F173E9124F; Mon, 16 Sep 2002 07:48:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2FCE91251; Mon, 16 Sep 2002 07:48:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 762BE9124F for <[e-mail]>; Mon, 16 Sep 2002 07:48:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5A8355DF48; Mon, 16 Sep 2002 07:48:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id DC5A85DDD5 for <[e-mail]>; Mon, 16 Sep 2002 07:48:28 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00826; Mon, 16 Sep 2002 07:46:43 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-idr-bgp-identifier-01.txt
Date: Mon, 16 Sep 2002 07:46:43 -0400
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		: AS-wide Unique BGP Identifier for BGP-4
	Author(s)	: E. Chen, J. Yuan
	Filename	: draft-ietf-idr-bgp-identifier-01.txt
	Pages		: 4
	Date		: 2002-9-13
	
To accommodate situations where the current requirements for the BGP
Identifier are not met, this document relaxes the definition of the
BGP Identifier to be a 4-octet unsigned, non-zero integer, and
relaxes the 'uniqueness' requirement so that only AS-wide uniqueness
of the BGP Identifiers is required. These revisions to the base BGP
specification do not introduce any backward compatibility issue.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-identifier-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp-identifier-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp-identifier-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp-identifier-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp-identifier-01.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 QAA29031 for <[e-mail]>; Sun, 15 Sep 2002 16:03:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E03129123C; Sun, 15 Sep 2002 16:02:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A4E279123F; Sun, 15 Sep 2002 16:02:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E7EDF9123C for <[e-mail]>; Sun, 15 Sep 2002 16:02:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BFAD85DF54; Sun, 15 Sep 2002 16:02:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by segue.merit.edu (Postfix) with ESMTP id 8853E5DE1C for <[e-mail]>; Sun, 15 Sep 2002 16:02:11 -0400 (EDT)
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2656.59) id <QSYHR7L1>; Sun, 15 Sep 2002 16:02:11 -0400
Message-ID: <[e-mail]>
From: "Martin, Christian" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Martin, Christian" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
Date: Sun, 15 Sep 2002 16:02:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Yakov,

I see what you are trying to say, but it took me a few reads.  What we are
saying is that BGP policy local to an AS cannot affect a path that a
neighboring AS uses to continue downstream.  This is hard to say in any
succinct way, and the sentence is pretty long.

Maybe something like this:

    Routing information exchanged via BGP supports only the
    destination-based forwarding paradigm, which assumes that a
    router forwards a packet based solely on the destination address
    carried in the IP header of the packet. This, in turn, reflects
    the set of policy decisions that can (and can not) be enforces
    using BGP. Note that some policies cannot be supported by the
    destination-based forwarding paradigm, and thus require techniques
    such as source routing (aka explicit routing) to enforce. Such
    policies can not be enforced using BGP either. For example,
    BGP does not enable one AS to send traffic through a neighboring
    AS to some destination beyond the neighboring AS intending that 
    the traffic take a different route from that taken by traffic
    to the same destination which originates in the neighboring AS.
    In other words, the BGP policy of a local AS cannot affect the 
    downstream (aka, away from the local AS) forwarding policy of a 
    remote AS.  On the other hand, BGP can support any policy conforming 
    to the destination-based forwarding paradigm.

-chris

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Sunday, September 15, 2002 3:25 PM
> To: Martin, Christian
> Cc: Natale, Jonathan; '[e-mail]'
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
> 
> 
> Martin,
> 
> > Yakov,
> > 	
> > In both examples below, it would appear that BGP does not have the 
> > capability to affect asymmetric routing, which it clearly 
> does as is 
> > evidenced by traffic on the Internet today.  Perhaps it 
> would be more 
> > clear to use an example that is more congruent with the 
> > destination-based vs source-based argument you are making.
> > 
> > IE:
> > 
> >    Routing information exchanged via BGP supports only the
> >    destination-based forwarding paradigm, which assumes that a
> >    router forwards a packet based solely on the destination address
> >    carried in the IP header of the packet. This, in turn reflects
> >    the set of policy decisions that can (and can not) be enforces
> >    using BGP. Note that some policies cannot be supported by the
> >    destination-based forwarding paradigm and thus require techniques
> >    such as source routing (aka explicit routing) to enforce. Such
> >    policies can not be enforced using BGP either. For example, BGP
> >    does not enable one AS to send traffic to a neighboring AS
> >    based on prefixes originating from the local AS.  On the
> >    other hand, BGP can support any policy conforming to the
> >    destination-based forwarding paradigm.
> 
> How about the following:
> 
>     Routing information exchanged via BGP supports only the
>     destination-based forwarding paradigm, which assumes that a
>     router forwards a packet based solely on the destination address
>     carried in the IP header of the packet. This, in turn, reflects
>     the set of policy decisions that can (and can not) be enforces
>     using BGP. Note that some policies cannot be supported by the
>     destination-based forwarding paradigm, and thus require techniques
>     such as source routing (aka explicit routing) to enforce. Such
>     policies can not be enforced using BGP either. For example,
>     BGP does not enable one AS to send traffic through a neighboring
>     AS to some destination (which is outside of the neighboring
>     AS, but is reachable through the neighboring AS) intending that
>     the traffic take a different route from that taken by the traffic
>     to the same destination that originating in the neighboring AS.
>     On the other hand, BGP can support any policy conforming to
>     the destination-based forwarding paradigm.
> 
> 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 PAA27829 for <[e-mail]>; Sun, 15 Sep 2002 15:26:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6E06C9123F; Sun, 15 Sep 2002 15:25:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DA2291240; Sun, 15 Sep 2002 15:25:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 12F1B9123F for <[e-mail]>; Sun, 15 Sep 2002 15:25:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id ED26B5DDD5; Sun, 15 Sep 2002 15:25:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 6341A5DDD2 for <[e-mail]>; Sun, 15 Sep 2002 15:25:24 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8FJPMm59340; Sun, 15 Sep 2002 12:25:22 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Martin, Christian" <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
In-Reply-To: Your message of "Sun, 15 Sep 2002 15:14:50 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sun, 15 Sep 2002 12:25:22 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Martin,

> Yakov,
> 	
> In both examples below, it would appear that BGP does not have the
> capability to affect asymmetric routing, which it clearly does as is
> evidenced by traffic on the Internet today.  Perhaps it would be more clear
> to use an example that is more congruent with the destination-based vs
> source-based argument you are making.
> 
> IE:
> 
>    Routing information exchanged via BGP supports only the
>    destination-based forwarding paradigm, which assumes that a
>    router forwards a packet based solely on the destination address
>    carried in the IP header of the packet. This, in turn reflects
>    the set of policy decisions that can (and can not) be enforces
>    using BGP. Note that some policies cannot be supported by the
>    destination-based forwarding paradigm and thus require techniques
>    such as source routing (aka explicit routing) to enforce. Such
>    policies can not be enforced using BGP either. For example, BGP
>    does not enable one AS to send traffic to a neighboring AS
>    based on prefixes originating from the local AS.  On the
>    other hand, BGP can support any policy conforming to the
>    destination-based forwarding paradigm.

How about the following:

    Routing information exchanged via BGP supports only the
    destination-based forwarding paradigm, which assumes that a
    router forwards a packet based solely on the destination address
    carried in the IP header of the packet. This, in turn, reflects
    the set of policy decisions that can (and can not) be enforces
    using BGP. Note that some policies cannot be supported by the
    destination-based forwarding paradigm, and thus require techniques
    such as source routing (aka explicit routing) to enforce. Such
    policies can not be enforced using BGP either. For example,
    BGP does not enable one AS to send traffic through a neighboring
    AS to some destination (which is outside of the neighboring
    AS, but is reachable through the neighboring AS) intending that
    the traffic take a different route from that taken by the traffic
    to the same destination that originating in the neighboring AS.
    On the other hand, BGP can support any policy conforming to
    the destination-based forwarding paradigm.

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 PAA27402 for <[e-mail]>; Sun, 15 Sep 2002 15:15:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 99B669123C; Sun, 15 Sep 2002 15:15:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 221819123F; Sun, 15 Sep 2002 15:15:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0EEF89123C for <[e-mail]>; Sun, 15 Sep 2002 15:15:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D243E5DDD2; Sun, 15 Sep 2002 15:15:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from entmail.gnilink.net (entmail.gnilink.net [199.45.47.10]) by segue.merit.edu (Postfix) with ESMTP id 981B75DDEF for <[e-mail]>; Sun, 15 Sep 2002 15:15:00 -0400 (EDT)
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2656.59) id <QSYHR72S>; Sun, 15 Sep 2002 15:15:00 -0400
Message-ID: <[e-mail]>
From: "Martin, Christian" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
Date: Sun, 15 Sep 2002 15:14:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Yakov,
	
In both examples below, it would appear that BGP does not have the
capability to affect asymmetric routing, which it clearly does as is
evidenced by traffic on the Internet today.  Perhaps it would be more clear
to use an example that is more congruent with the destination-based vs
source-based argument you are making.

IE:

   Routing information exchanged via BGP supports only the
   destination-based forwarding paradigm, which assumes that a
   router forwards a packet based solely on the destination address
   carried in the IP header of the packet. This, in turn reflects
   the set of policy decisions that can (and can not) be enforces
   using BGP. Note that some policies cannot be supported by the
   destination-based forwarding paradigm and thus require techniques
   such as source routing (aka explicit routing) to enforce. Such
   policies can not be enforced using BGP either. For example, BGP
   does not enable one AS to send traffic to a neighboring AS
   based on prefixes originating from the local AS.  On the
   other hand, BGP can support any policy conforming to the
   destination-based forwarding paradigm.

I know this is a late change and it hasn't been addressed before, but after
reading it in a capsule, it looks like it would be beneficial to consider
the edit.

Thanks,
-chris



> So, with this in mind I would suggest to replace
> 
>    To characterize the set of policy decisions that can be enforced
>    using BGP, one must focus on the rule that a BGP speaker advertises
>    to its peers (other BGP speakers which it communicates with) in
>    neighboring ASs only those routes that it itself uses. This rule
>    reflects the "hop-by-hop" routing paradigm generally used
>    throughout the current Internet. Note that some policies cannot
>    be supported by the "hop-by-hop" routing paradigm and thus
>    require techniques such as source routing (aka explicit routing)
>    to enforce. For example, BGP does not enable one AS to send
>    traffic to a neighboring AS intending that the traffic take a
>    different route from that taken by traffic originating in the
>    neighboring AS. On the other hand, BGP can support any policy
>    conforming to the "hop-by-hop" routing paradigm. Since the
>    current Internet uses only the "hop-by-hop" inter-AS routing
>    paradigm and since BGP can support any policy that conforms to
>    that paradigm, BGP is highly applicable as an inter-AS routing
>    protocol for the current Internet.
> 
> with the following:
> 
>    Routing information exchanged via BGP supports only the
>    destination-based forwarding paradigm, which assumes that a
>    router forwards a packet based solely on the destination address
>    carried in the IP header of the packet. This, in turn reflects
>    the set of policy decisions that can (and can not) be enforces
>    using BGP. Note that some policies cannot be supported by the
>    destination-based forwarding paradigm and thus require techniques
>    such as source routing (aka explicit routing) to enforce. Such
>    policies can not be enforced using BGP either. For example, BGP
>    does not enable one AS to send traffic to a neighboring AS
>    intending that the traffic take a different route from that
>    taken by traffic originating in the neighboring AS.  On the
>    other hand, BGP can support any policy conforming to the
>    destination-based forwarding paradigm.
> 
> 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 GAA09640 for <[e-mail]>; Sun, 15 Sep 2002 06:06:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CB3229120D; Sun, 15 Sep 2002 06:05:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9710991225; Sun, 15 Sep 2002 06:05:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 51F609120D for <[e-mail]>; Sun, 15 Sep 2002 06:05:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 31CB15DDA1; Sun, 15 Sep 2002 06:05:45 -0400 (EDT)
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 DD05E5DD9F for <[e-mail]>; Sun, 15 Sep 2002 06:05:44 -0400 (EDT)
Received: from tom3 (usermb71.uk.uudial.com [62.188.120.70]) by shockwave.systems.pipex.net (Postfix) with SMTP id 49AAC16000D99; Sun, 15 Sep 2002 11:05:37 +0100 (BST)
Message-ID: <003301c25c9f$08345cc0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>
Cc: "Susan Hares" <[e-mail]>
Subject: FSM but FSM of what?
Date: Sun, 15 Sep 2002 11:02:09 +0100
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

The business of what the FSM is the FSM of still nags me (I had a
problem with it when I first read BGP-17 and to some extent still
have).

I think it nags me most in connection collision detection.  This is
defined (bgp-17 s6.8) as taking place between the same pair of IP
addresses (so the TCP connections are differentiated by port numbers
as ever).  When the FSM says the new state after a collision should be
Idle (for the connection initiated by the lower value of BGP
Identifier), then that only applies to this connection (uniquely
identified by TCP protocol  and a source/destination duple of both IP
address and port number); the winning (different port number duple)
connection will go on to Established via OpenConfirm.

So clearly (to me) there are two FSM here, with the same pair of IP
addresses
but different port numbers ie we are defining the FSM of a particular
TCP connection.

But can that work in Idle state when we have no TCP connection, only a
putative one.

As ever, I raise this because I believe it is worth clarifying in so
far as we can.  IMHO, it also impacts the references to the need to
track
Transport Indicates while in OpenConfirm or Established.  The tracking
is of the same IP address pair with a different port number pair in a
(?)different FSM with the events coming from that FSM to our FSM to
cause our FSM to revert to Idle (or not as the case may be).  And this
is an area that grows more complex with the other drafts (currently
out of scope); so I want an unambiguous base to work from.

We could have a single FSM catering for multiple connections but I
think that that would be too complex to be useful.  So perhaps a
more explicit reference to the fact that we are processing a single
connection once that (TCP) connection has been established.

Like

"8 BGP FInite State Machine

This section specifies BGP operation - between a BGP speaker and its
peer over a single TCP connection - in terms of a Finite State Machine
(FSM).  Following is a brief summary ... "(as before)

Instead of just



"This section specifies BGP operation in terms of a Finite State
Machine (FSM).  Following is a brief summary ... "(as before).

A month ago I would have said transport connection instead of TCP
connection but I have been put right on that; I see BGP as TCP-based
as far as this draft is concerned.  And transport connection does then
make any reference to (TCP-specific) port numbers  ... err confusing?


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 WAA24333 for <[e-mail]>; Sat, 14 Sep 2002 22:19:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BF79591230; Sat, 14 Sep 2002 22:18:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8955891231; Sat, 14 Sep 2002 22:18:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 31EBE91230 for <[e-mail]>; Sat, 14 Sep 2002 22:18:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 217185DEFE; Sat, 14 Sep 2002 22:18:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id BC1795DDDA for <[e-mail]>; Sat, 14 Sep 2002 22:18:55 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8F2Irm32350; Sat, 14 Sep 2002 19:18:53 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
In-Reply-To: Your message of "Fri, 13 Sep 2002 18:42:48 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sat, 14 Sep 2002 19:18:53 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> I propose changing:
> "To characterize the set of policy decisions that can be enforced
>    using BGP, one must focus on the rule that a BGP speaker advertises
>    to its peers (other BGP speakers which it communicates with) in
>    neighboring ASs only those routes that it itself uses."
> 
> To:
> "To characterize the set of policy decisions that can be enforced
>    using BGP, one must focus on the rule that a BGP speaker advertises
>    to its peers (other BGP speakers which it communicates with)
>    only those prefixes that it itself uses. Whether or not to require the
> prefixes be used itself by virtue of a bgp learned route MAY be an
> administratively configurable option."
> 
> Since:
> 1) This rule applies to IBGP as well as to EBGP. 
> 2) The prefix need not necessarily be in the local routing table via bgp.
> 3) Juniper has a advertise inactive concept, Cisco does not.
> 4) The term route (vs prefix) is defined to include the attributes which
> means that Cisco is non-compliant (in that it will advertise a route if the
> route's prefix is installed via another protocol), and juniper may be
> configured to be non-compliant (turning off advertise inactive).

The original text (and I think your replacement text as well) is
a bit broken as it doesn't cover the case of the "third-party" Next
Hop.

The *real* issue that the text you mentioned above is trying to
capture (although it clearly didn't capture it well enough) is that 
BGP is built to support the destination-based forwarding paradigm.

So, with this in mind I would suggest to replace

   To characterize the set of policy decisions that can be enforced
   using BGP, one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with) in
   neighboring ASs only those routes that it itself uses. This rule
   reflects the "hop-by-hop" routing paradigm generally used
   throughout the current Internet. Note that some policies cannot
   be supported by the "hop-by-hop" routing paradigm and thus
   require techniques such as source routing (aka explicit routing)
   to enforce. For example, BGP does not enable one AS to send
   traffic to a neighboring AS intending that the traffic take a
   different route from that taken by traffic originating in the
   neighboring AS. On the other hand, BGP can support any policy
   conforming to the "hop-by-hop" routing paradigm. Since the
   current Internet uses only the "hop-by-hop" inter-AS routing
   paradigm and since BGP can support any policy that conforms to
   that paradigm, BGP is highly applicable as an inter-AS routing
   protocol for the current Internet.

with the following:

   Routing information exchanged via BGP supports only the
   destination-based forwarding paradigm, which assumes that a
   router forwards a packet based solely on the destination address
   carried in the IP header of the packet. This, in turn reflects
   the set of policy decisions that can (and can not) be enforces
   using BGP. Note that some policies cannot be supported by the
   destination-based forwarding paradigm and thus require techniques
   such as source routing (aka explicit routing) to enforce. Such
   policies can not be enforced using BGP either. For example, BGP
   does not enable one AS to send traffic to a neighboring AS
   intending that the traffic take a different route from that
   taken by traffic originating in the neighboring AS.  On the
   other hand, BGP can support any policy conforming to the
   destination-based forwarding paradigm.

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 MAA03912 for <[e-mail]>; Sat, 14 Sep 2002 12:06:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5E96991214; Sat, 14 Sep 2002 12:06:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2855191216; Sat, 14 Sep 2002 12:06:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3893291214 for <[e-mail]>; Sat, 14 Sep 2002 12:06:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1F2D75DE5B; Sat, 14 Sep 2002 12:06:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 6CA205DD9D for <[e-mail]>; Sat, 14 Sep 2002 12:06:17 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA01204; Sat, 14 Sep 2002 12:06:10 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA06065; Sat, 14 Sep 2002 12:06:12 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DV165>; Sat, 14 Sep 2002 12:06:11 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive
Date: Sat, 14 Sep 2002 12:06:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Jonathan:
  I did raise this issue before several days ago, the case that BGP only
advertises IBGP/EBGP routes to its peers, but sometimes a better route,
say IGP or static is used for forwarding. Thus making the statement not
totally true. We suggested that the statement be revised to imply that 
reachability of these routes are gauranteed by the BGP speaker not their
implied "use" in the forwarding table.

Thanks,
Ben

-----Original Message-----
From: Natale, Jonathan
To: [e-mail]
Sent: 9/13/02 6:42 PM
Subject: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive

I propose changing:
"To characterize the set of policy decisions that can be enforced
   using BGP, one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with) in
   neighboring ASs only those routes that it itself uses."

To:
"To characterize the set of policy decisions that can be enforced
   using BGP, one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with)
   only those prefixes that it itself uses. Whether or not to require
the
prefixes be used itself by virtue of a bgp learned route MAY be an
administratively configurable option."

Since:
1) This rule applies to IBGP as well as to EBGP. 
2) The prefix need not necessarily be in the local routing table via
bgp.
3) Juniper has a advertise inactive concept, Cisco does not.
4) The term route (vs prefix) is defined to include the attributes which
means that Cisco is non-compliant (in that it will advertise a route if
the
route's prefix is installed via another protocol), and juniper may be
configured to be non-compliant (turning off advertise inactive).



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA29289 for <[e-mail]>; Fri, 13 Sep 2002 18:43:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 115C491208; Fri, 13 Sep 2002 18:42:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C51BD9120C; Fri, 13 Sep 2002 18:42:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6DD1D91208 for <[e-mail]>; Fri, 13 Sep 2002 18:42:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4DB315DE94; Fri, 13 Sep 2002 18:42:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 09C8E5DE5E for <[e-mail]>; Fri, 13 Sep 2002 18:42:50 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1C4MD>; Fri, 13 Sep 2002 18:42:49 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject:  Review of draft-ietf-idr-bgp4-17.txt-advertise inactive
Date: Fri, 13 Sep 2002 18:42:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I propose changing:
"To characterize the set of policy decisions that can be enforced
   using BGP, one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with) in
   neighboring ASs only those routes that it itself uses."

To:
"To characterize the set of policy decisions that can be enforced
   using BGP, one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with)
   only those prefixes that it itself uses. Whether or not to require the
prefixes be used itself by virtue of a bgp learned route MAY be an
administratively configurable option."

Since:
1) This rule applies to IBGP as well as to EBGP. 
2) The prefix need not necessarily be in the local routing table via bgp.
3) Juniper has a advertise inactive concept, Cisco does not.
4) The term route (vs prefix) is defined to include the attributes which
means that Cisco is non-compliant (in that it will advertise a route if the
route's prefix is installed via another protocol), and juniper may be
configured to be non-compliant (turning off advertise inactive).




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA21058 for <[e-mail]>; Fri, 13 Sep 2002 14:23:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 941759131E; Fri, 13 Sep 2002 14:23:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F3DB9131F; Fri, 13 Sep 2002 14:23:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1CE2D9131E for <[e-mail]>; Fri, 13 Sep 2002 14:23:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F3FFD5DDEA; Fri, 13 Sep 2002 14:23:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from laptoy770.fictitious.org (unknown [209.150.1.238]) by segue.merit.edu (Postfix) with ESMTP id F30675DDBE for <[e-mail]>; Fri, 13 Sep 2002 14:23:30 -0400 (EDT)
Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.11.2/8.11.2) with ESMTP id g8DIOJ844932; Fri, 13 Sep 2002 14:24:19 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-reply-to: Your message of "Thu, 12 Sep 2002 10:47:46 EDT." <[e-mail]> 
Date: Fri, 13 Sep 2002 14:24:18 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Jeffrey Haas writes:
> On Wed, Sep 11, 2002 at 06:17:27PM -0400, Curtis Villamizar wrote:
> > We might want to say the value EGP in the ORIGIN field (which does
> > mean the EGP protocol, not any EGP type protocol) is depricated since
> > the EGP protocol has been moved to historic but retain the value to
> > document what it used to mean.
> 
> I would ask us to consider carefully before deprecating it.
> While no longer used (from what I've seen or heard) as the origin
> of the route being from the EGP protocol, people *are* using it in
> their route-maps to bias route selection.
> 
> -- 
> Jeff Haas 
> NextHop Technologies


We should at least change the wording to indicate that EGP referred to
a now historical protocol.

The applications statement 1772-bis can mention the out of spec usage
that is occurring.  (Give them a knob and who knows what they'll do
with it).

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 OAA20445 for <[e-mail]>; Fri, 13 Sep 2002 14:04:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id AF2D79131C; Fri, 13 Sep 2002 14:00:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C7119131E; Fri, 13 Sep 2002 14:00:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 44D509131C for <[e-mail]>; Fri, 13 Sep 2002 14:00:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B7D705DE4B; Fri, 13 Sep 2002 14:00:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 431235DE0A for <[e-mail]>; Fri, 13 Sep 2002 14:00:22 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CTHP>; Fri, 13 Sep 2002 14:00:21 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Ignas Bagdonas'" <[e-mail]>
Cc: [e-mail]
Subject: RE: NOTIFICATION message error handling.
Date: Fri, 13 Sep 2002 14:00:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I see your point, but your text seems too wordy.

What about:
"If a speaker receives a NOTIFICATION message, and there is an error in that
>    message, there is unfortunately no means of reporting this error via
>    a subsequent NOTIFICATION message."

Since throughout the doc "speaker" seems to mean local peer and "peer" seems
to mean remote peer.  This may be another area where consistency/
definitions would make the doc more readable/workable.

-----Original Message-----
From: Ignas Bagdonas [mailto:[e-mail]] 
Sent: Friday, September 13, 2002 1:28 PM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: NOTIFICATION message error handling.


,

[This is section 6.4]

> Please change"
> "If a peer sends a NOTIFICATION message, and there is an error in that
>    message, there is unfortunately no means of reporting this error via
>    a subsequent NOTIFICATION message."
>
> To:
> "If a peer receives a NOTIFICATION message, and there is an error in that
>    message, there is unfortunately no means of reporting this error via
>    a subsequent NOTIFICATION message."


I would tend to disagree - the proposed change reverses the meaning of the
statement. It is remote peer that sends us malformed NOTIFICATION and
cannot be informed about that.

I would suggest the following text instead:

   All errors detected while processing the NOTIFICATION message cannot be
   indicated by sending subsequent NOTIFICATION message back to
   originating peer, therefore there is no means of reporting NOTIFICATION
   message processing errors. Any error, such as an unrecognized
   Error Code or Error Subcode, should be noticed, logged locally, and
   brought to the attention of the administration of the peer that has
   sent the message. The means to do this, however, lies outside the scope
   of this document.



Ignas





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA19207 for <[e-mail]>; Fri, 13 Sep 2002 13:25:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6891F91207; Fri, 13 Sep 2002 13:24:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E0D49131B; Fri, 13 Sep 2002 13:24:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D0E4B91207 for <[e-mail]>; Fri, 13 Sep 2002 13:24:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B10AB5DE92; Fri, 13 Sep 2002 13:24:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from voruta.vu.lt (mail.vu.lt [193.219.80.13]) by segue.merit.edu (Postfix) with ESMTP id 05A2C5DDBE for <[e-mail]>; Fri, 13 Sep 2002 13:24:49 -0400 (EDT)
Received: from localhost (ignas@localhost) by voruta.vu.lt (8.11.1/8.11.0/VU-20001122) with ESMTP id g8DHRwG04950; Fri, 13 Sep 2002 19:27:58 +0200 (GMT)
Date: Fri, 13 Sep 2002 19:27:58 +0200 (GMT)
From: Ignas Bagdonas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: NOTIFICATION message error handling.
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

,

[This is section 6.4]

> Please change"
> "If a peer sends a NOTIFICATION message, and there is an error in that
>    message, there is unfortunately no means of reporting this error via
>    a subsequent NOTIFICATION message."
>
> To:
> "If a peer receives a NOTIFICATION message, and there is an error in that
>    message, there is unfortunately no means of reporting this error via
>    a subsequent NOTIFICATION message."


I would tend to disagree - the proposed change reverses the meaning of the
statement. It is remote peer that sends us malformed NOTIFICATION and
cannot be informed about that.

I would suggest the following text instead:

   All errors detected while processing the NOTIFICATION message cannot be
   indicated by sending subsequent NOTIFICATION message back to
   originating peer, therefore there is no means of reporting NOTIFICATION
   message processing errors. Any error, such as an unrecognized
   Error Code or Error Subcode, should be noticed, logged locally, and
   brought to the attention of the administration of the peer that has
   sent the message. The means to do this, however, lies outside the scope
   of this document.



Ignas






Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA16998 for <[e-mail]>; Fri, 13 Sep 2002 11:43:25 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F26E891318; Fri, 13 Sep 2002 11:43:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B784491319; Fri, 13 Sep 2002 11:43:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4A7E991318 for <[e-mail]>; Fri, 13 Sep 2002 11:43:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3A5795DF02; Fri, 13 Sep 2002 11:43:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 559D15DE07 for <[e-mail]>; Fri, 13 Sep 2002 11:42:59 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CSVC>; Fri, 13 Sep 2002 11:42:55 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, BGP mailing list <[e-mail]>
Subject: RE: BGP4 draft ; section 6.2
Date: Fri, 13 Sep 2002 11:42:55 -0400
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id LAA16998

I just re-read your email; it is the rtr that does not have capabilities at
all...

1) currently, not too many implementations do the exponential back off in
response to an error, and the whole FSM thing is being re-hashed now.  So it
will flap.

2) ignoring options (since *I think*(???) capabilities is the only one used
anywhere) is probably not that bad of an idea since sending capabilities are
only saying what the sender supports, not what the receiver supports.
Obviously, ignoring capabilities is better when peering with a vendor that
does not re-open without the capabilities as they should per rfc2842 (or
maybe a config switch for this).  This is not spelled out in any rfc that I
am aware of

3) I do not know about the Juniper side of this.
 
4) you might want to check the vendor's bugs.
     
5) I *think* what the vendor was referring to is:

From: Natale, Jonathan [mailto:[e-mail]] 
Sent: Tuesday, August 06, 2002 4:19 PM
To: '[e-mail]'
Subject: capability

I would like to propose:

>"If a BGP speaker that supports a certain capability determines that
>    its peer doesn't support this capability, the speaker MAY send a
>    NOTIFICATION message to the peer, and terminate peering (see Section
>    "Extensions to Error Handling" for more details). The Error Subcode
>    in the message is set to Unsupported Capability. The message SHOULD
>    contain the capability (capabilities) that causes the speaker to send
>    the message.  The decision to send the message and terminate peering
>    is local to the speaker. If terminated, such peering SHOULD NOT be
>    re-established automatically."
>
>be changed to:
>
>"If a BGP speaker that **does not want its peer to support** a certain
>capability determines that
>    its peer **does** support this capability, the speaker MAY send a
>    NOTIFICATION message to the peer, and terminate peering (see Section
>    "Extensions to Error Handling" for more details). The Error Subcode
>    in the message is set to Unsupported Capability. The message SHOULD
>    contain the capability (capabilities) that causes the speaker to send
>    the message.  The decision to send the message and terminate peering
>    is local to the speaker. **If terminated, the peer MAY re-open the
>    connection without the offending capability-this is known as capability
>    negotiation.**"
>

... The response I got was basically that the draft is already done.


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] 
Sent: Friday, September 13, 2002 9:44 AM
To: BGP mailing list
Subject: BGP4 draft ; section 6.2

All, 
I have a doubt related to section 6.2: OPEN message error handling, related
to the statement: 
" If one of the optional parameters in the Open mesage is not recognized,
then the error subcode is set to 'unsupported optional parameters" 
We have hit on this line when we were testing a BGP connection between a
speaker that supported capability negotiation and a speaker that did not. 
The speaker that did not support the neogotiation closed down the peering
session using the error clause mentioned above.  Sometimes this lead to the
other router to repeat the OPEN message with the Capability optional
parameter; a game that went on for minutes. 
This router manufacturer stated in a reply to this that : 
"One should not close down the connection if an optional parameter is
unrecognised. That would make this parameter basically mandatory. 
This is an well known error in the BGP spec. Neither Cisco or Juniper do
this"

If this is true it might be good to adapt the text. 
Hans de Vleeschouwer 
Alcatel. 
  
  
 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA16685 for <[e-mail]>; Fri, 13 Sep 2002 11:23:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 14F579120A; Fri, 13 Sep 2002 11:22:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D583891205; Fri, 13 Sep 2002 11:22:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 27C7791315 for <[e-mail]>; Fri, 13 Sep 2002 11:22:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1495A5DF02; Fri, 13 Sep 2002 11:22:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id A60255DE07 for <[e-mail]>; Fri, 13 Sep 2002 11:22:24 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CSS5>; Fri, 13 Sep 2002 11:22:24 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'BGP mailing list'" <[e-mail]>
Subject: RE: BGP4 draft ; section 6.2
Date: Fri, 13 Sep 2002 11:22:23 -0400
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id LAA16685

(not sure if this got thru, it was not plain text)

-----Original Message-----
From: Natale, Jonathan 
Sent: Friday, September 13, 2002 11:18 AM
To: '[e-mail]'; BGP mailing list
Subject: RE: BGP4 draft ; section 6.2

Kind of a buggy area.  Try "neighbor 1.1.1.1 dont-capability-negotiate". 
Not sure on the Juniper side.
 
-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] 
Sent: Friday, September 13, 2002 9:44 AM
To: BGP mailing list
Subject: BGP4 draft ; section 6.2
 
All, 
I have a doubt related to section 6.2: OPEN message error handling, related
to the statement: 
" If one of the optional parameters in the Open mesage is not recognized,
then the error subcode is set to 'unsupported optional parameters" 
We have hit on this line when we were testing a BGP connection between a
speaker that supported capability negotiation and a speaker that did not. 
The speaker that did not support the neogotiation closed down the peering
session using the error clause mentioned above.  Sometimes this lead to the
other router to repeat the OPEN message with the Capability optional
parameter; a game that went on for minutes. 
This router manufacturer stated in a reply to this that : 
"One should not close down the connection if an optional parameter is
unrecognised. That would make this parameter basically mandatory. 
This is an well known error in the BGP spec. Neither Cisco or Juniper do
this"

If this is true it might be good to adapt the text. 
Hans de Vleeschouwer 
Alcatel. 
  
  
 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA16635 for <[e-mail]>; Fri, 13 Sep 2002 11:19:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1729591313; Fri, 13 Sep 2002 11:19:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B175B9120A; Fri, 13 Sep 2002 11:19:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2B1CE91205 for <[e-mail]>; Fri, 13 Sep 2002 11:17:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0D9E95DF07; Fri, 13 Sep 2002 11:17:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id AFA585DF02 for <[e-mail]>; Fri, 13 Sep 2002 11:17:57 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CSSL>; Fri, 13 Sep 2002 11:17:57 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, BGP mailing list <[e-mail]>
Subject: RE: BGP4 draft ; section 6.2
Date: Fri, 13 Sep 2002 11:17:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25B38.BD39C050"
Sender: [e-mail]
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C25B38.BD39C050
Content-Type: text/plain

Kind of a buggy area.  Try "neighbor 1.1.1.1 dont-capability-negotiate".
Not sure on the Juniper side.

 

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] 
Sent: Friday, September 13, 2002 9:44 AM
To: BGP mailing list
Subject: BGP4 draft ; section 6.2

 

All, 

I have a doubt related to section 6.2: OPEN message error handling, related
to the statement: 

" If one of the optional parameters in the Open mesage is not recognized,
then the error subcode is set to 'unsupported optional parameters" 

We have hit on this line when we were testing a BGP connection between a
speaker that supported capability negotiation and a speaker that did not. 

The speaker that did not support the neogotiation closed down the peering
session using the error clause mentioned above.  Sometimes this lead to the
other router to repeat the OPEN message with the Capability optional
parameter; a game that went on for minutes. 

This router manufacturer stated in a reply to this that : 

"One should not close down the connection if an optional parameter is
unrecognised. That would make this parameter basically mandatory. 

This is an well known error in the BGP spec. Neither Cisco or Juniper do
this"


If this is true it might be good to adapt the text. 

Hans de Vleeschouwer 
Alcatel. 
  
  
 


------_=_NextPart_001_01C25B38.BD39C050
Content-Type: text/html

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">


<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Kind of a buggy area.&nbsp; Try "neighbor
1.1.1.1 dont-capability-negotiate".&nbsp; Not sure on the Juniper side.</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style='font-weight:bold'>From:</span></b>
[e-mail] [mailto:[e-mail]] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, September 13, 2002
9:44 AM<br>
<b><span style='font-weight:bold'>To:</span></b> BGP mailing list<br>
<b><span style='font-weight:bold'>Subject:</span></b> BGP4 draft ; section 6.2</span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>&nbsp;</span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>All, </span></font></p>

<p style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>I have a doubt related to section 6.2: OPEN message
error handling, related to the statement: </span></font></p>

<p style='margin-left:.5in'><i><font size=3 face="Times New Roman"><span
style='font-size:12.0pt;font-style:italic'>&quot; If one of the optional
parameters in the Open mesage is not recognized, then the error subcode is set
to 'unsupported optional parameters&quot;</span></font></i> </p>

<p style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>We have hit on this line when we were testing a BGP
connection between a speaker that supported capability negotiation and a
speaker that did not. </span></font></p>

<p style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>The speaker that did not support the neogotiation
closed down the peering session using the error clause mentioned above.&nbsp;
Sometimes this lead to the other router to repeat the OPEN message with the
Capability optional parameter; a game that went on for minutes. </span></font></p>

<p style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>This router manufacturer stated in a reply to this
that : </span></font></p>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>&quot;One should not close down the connection if an
optional parameter is unrecognised. That would make this parameter basically
mandatory. </span></font></p>

<p style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>This is an well known error in the BGP spec. Neither
Cisco or Juniper do this&quot;</span></font></p>

</blockquote>

<p style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'><br>
If this is true it might be good to adapt the text. </span></font></p>

<p style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>Hans de Vleeschouwer <br>
Alcatel. <br>
&nbsp; <br>
&nbsp; <br>
&nbsp;</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C25B38.BD39C050--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA15558 for <[e-mail]>; Fri, 13 Sep 2002 10:08:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1FC41912FB; Fri, 13 Sep 2002 10:07:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E15269130E; Fri, 13 Sep 2002 10:07:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB612912FB for <[e-mail]>; Fri, 13 Sep 2002 10:07:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B7F405DEB7; Fri, 13 Sep 2002 10:07:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 0926B5DE07 for <[e-mail]>; Fri, 13 Sep 2002 10:07:57 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8DE7lo17542; Fri, 13 Sep 2002 10:07:47 -0400 (EDT) (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 g8DE7iG17535; Fri, 13 Sep 2002 10:07:44 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g8DE7i324105; Fri, 13 Sep 2002 10:07:44 -0400 (EDT)
Date: Fri, 13 Sep 2002 10:07:43 -0400
From: Mathew Richardson <[e-mail]>
To: [e-mail]
Cc: BGP mailing list <[e-mail]>
Subject: Re: BGP4 draft ; section 6.2
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

> [e-mail] <[e-mail]> [Fri, Sep 13, 2002 at 03:43:55PM +0200]:

>From rfc2842:

   A BGP speaker determines that its peer doesn't support capabilities
   advertisement, if in response to an OPEN message that carries the
   Capabilities Optional Parameter, the speaker receives a NOTIFICATION
   message with the Error Subcode set to Unsupported Optional Parameter.
   In this case the speaker should attempt to re-establish a BGP
   connection with the peer without sending to the peer the Capabilities
   Optional Parameter.

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 JAA15383 for <[e-mail]>; Fri, 13 Sep 2002 09:44:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 37219912F9; Fri, 13 Sep 2002 09:44:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F28A0912FB; Fri, 13 Sep 2002 09:44:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6909912F9 for <[e-mail]>; Fri, 13 Sep 2002 09:44:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C095B5DE3D; Fri, 13 Sep 2002 09:44:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by segue.merit.edu (Postfix) with ESMTP id 0D3135DE35 for <[e-mail]>; Fri, 13 Sep 2002 09:44:07 -0400 (EDT)
Received: from Bemail06.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g8DDcCO16336 for <[e-mail]>; Fri, 13 Sep 2002 15:38:12 +0200
Received: from alcatel.be ([138.203.191.116]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002091315440157:5923 ; Fri, 13 Sep 2002 15:44:01 +0200 
Message-ID: <[e-mail]>
Date: Fri, 13 Sep 2002 15:43:55 +0200
From: [e-mail]
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: BGP mailing list <[e-mail]>
Subject: BGP4 draft ; section 6.2
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 09/13/2002 15:44:01, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 09/13/2002 15:44:02, Serialize complete at 09/13/2002 15:44:02
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
All,
<p>I have a doubt related to section 6.2: OPEN message error handling,
related to the statement:
<p><i>" If one of the optional parameters in the Open mesage is not recognized,
then the error subcode is set to 'unsupported optional parameters"</i>
<p>We have hit on this line when we were testing a BGP connection between
a speaker that supported capability negotiation and a speaker that did
not.
<p>The speaker that did not support the neogotiation closed down the peering
session using the error clause mentioned above.&nbsp; Sometimes this lead
to the other router to repeat the OPEN message with the Capability optional
parameter; a game that went on for minutes.
<p>This router manufacturer stated in a reply to this that :
<blockquote>"One should not close down the connection if an optional parameter
is unrecognised. That would make this parameter basically mandatory.
<p>This is an well known error in the BGP spec. Neither Cisco or Juniper
do this"</blockquote>

<p><br>If this is true it might be good to adapt the text.
<p>Hans de Vleeschouwer
<br>Alcatel.
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;</html>



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA19765 for <[e-mail]>; Thu, 12 Sep 2002 19:50:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BDFAA912E5; Thu, 12 Sep 2002 19:50:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88F2D912E7; Thu, 12 Sep 2002 19:50:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0936B912E5 for <[e-mail]>; Thu, 12 Sep 2002 19:49:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DDBD55DE89; Thu, 12 Sep 2002 19:49:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 33B3E5DE87 for <[e-mail]>; Thu, 12 Sep 2002 19:49:55 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8CNnqv04168; Thu, 12 Sep 2002 19:49:52 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([65.241.132.110]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g8CNnmG04161; Thu, 12 Sep 2002 19:49:49 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 12 Sep 2002 19:49:49 -0400
To: [e-mail]
From: Susan Hares <[e-mail]>
Subject: Last Call on BGP - What we are reviewing
Cc: yakov Rekhter <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

We are not reviewing the FSM part of the draft-17 text. But we
are reviewing the rest of draft-17, as well as Sue's text on FSM
work replacement.

Please send comments about draft-17 (except the FSM) and FSM comments
to the [e-mail].  We'd appreciate the comments as soon as people
can send them.


Yakov and 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 TAA18593 for <[e-mail]>; Thu, 12 Sep 2002 19:13:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6D9C7912DC; Thu, 12 Sep 2002 19:13:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CF85912DE; Thu, 12 Sep 2002 19:13:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EEDC2912DC for <[e-mail]>; Thu, 12 Sep 2002 19:13:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D20F55DE8D; Thu, 12 Sep 2002 19:13:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from kanmx1.ca.alcatel.com (unknown [209.202.115.138]) by segue.merit.edu (Postfix) with SMTP id 8DDC25DE89 for <[e-mail]>; Thu, 12 Sep 2002 19:13:06 -0400 (EDT)
Received: (qmail 21842 invoked from network); 12 Sep 2002 23:17:37 -0000
Received: (ofmipd 138.120.52.246); 12 Sep 2002 23:17:15 -0000
Date: 12 Sep 2002 19:13:05 -0400
Message-ID: <[e-mail]>
From: "Xia W Zhao" <[e-mail]>
To: "Susan Hares" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Organization: Alcatel CID
X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Subject: FSM review
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Sue,

A standard description should serve better instead of using following
different ways:
"starts peer connection"
"starts the BGP peer session"
"start the peer Connection"
"start the BGP session"


Event4 & Event5: Definition:
  "The passive flag indicates that the peer will listen prior to
establishing a connection." sounds like normal peers do not listen prior
to establishing a/the connection. It should be changed to
  "The passive flag indicates that the peer will not initiate a
connection but listen prior to establishing a connection."

Event6 & Event8 & Idle state: 
  The following words 
  "persistent peer oscillation"
  "persistent BGP adjacency flapping"
  "persistent BGP peer flapping"
  "persistent BGP peer oscillation"
 
  should be consistent by using 
  "persistent BGP peer flapping". Because flapping can be caused by
oscillation and others, using flapping is more accurate.

Event8:
  "idle Hold timer", "Idle Hold timer", "Idle Hold Timer" should be
changed to

  "idle hold timer"

Event10: "hold time expires" should be changed to 
  "hold timer expires"

"8.2.3) Transport Message based" should be changed to 
"8.1.3 Transport Message Based Events"

Event14 Definition:
 "Transport request received with either ..." not clear to me. Is it
better to change it to
  "Event indicating transport received with either ..." if this is what
it meant.

Event17
  "Transport connection fails" should be changed to
  "Transport Connection Failed"

  "This BGP peer receives a transport connection failure notice" should
be changed to
  "The local system has received a transport connection failure notice"
  
  "the remtoe BGP peer's TCP machine" should be changed to 
  "the remote site' TCP machine", and

  "The local peer" should be changed to
  "The local system" for the purpose of consistent.

"8.2) Description of FSM" should be changed to
"8.2 Description of FSM".

Xia


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA15704 for <[e-mail]>; Thu, 12 Sep 2002 17:42:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 00A50912D7; Thu, 12 Sep 2002 17:41:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC0C5912D9; Thu, 12 Sep 2002 17:41:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F5BA912D7 for <[e-mail]>; Thu, 12 Sep 2002 17:41:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 577EF5DE7B; Thu, 12 Sep 2002 17:41:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id C69FA5DDE3 for <[e-mail]>; Thu, 12 Sep 2002 17:41:51 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA01986; Thu, 12 Sep 2002 17:41:49 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA04789; Thu, 12 Sep 2002 17:41:50 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DTP4T>; Thu, 12 Sep 2002 17:41:49 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Tom Petch'" <[e-mail]>, [e-mail], BGP mailing list <[e-mail]>
Subject: RE: problem in collision strategy?
Date: Thu, 12 Sep 2002 17:41:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25AA5.32D6B230"
Sender: [e-mail]
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C25AA5.32D6B230
Content-Type: text/plain;
	charset="iso-8859-1"

This is described in Sue's FSM spec under section.
 
2.4.2 Collision Detect Processing in Established state
 
If Hans implements the config option, the race condition will go away.
 
Ben

-----Original Message-----
From: Tom Petch [mailto:[e-mail]]
Sent: Thursday, September 12, 2002 2:06 PM
To: [e-mail]; BGP mailing list
Subject: Re: problem in collision strategy?


Interesting, fascinating even.
 
The two ends should implement the same Connection collision detection and
arrive at the same conclusion.  The way I read it, both should retain the
(TCP) connection initiated by the BGP speaker with the higher value of BGP
Identifier; assuming that that is speaker 2, then 
This triggers the collision detection in speaker 2. As he still 
believes that connection 1 is established, he decides to close the
connection 2 
 
is in error; speaker 2 should close the first connection just as speaker one
has done.
 
Tom Petch, Network Consultant
[e-mail] <mailto:[e-mail]> 


-----Original Message-----
From: [e-mail]
<mailto:[e-mail]>  < [e-mail]
<mailto:[e-mail]> >
To: BGP mailing list < [e-mail] <mailto:[e-mail]> >
Date: 12 September 2002 15:38
Subject: problem in collision strategy?

<snip>

(in the scenario below time progresses downwards) 
  


+---------------+                  +---------------+ 
! BGP speaker A !                  ! BGP speaker B ! 
! 10.10.10.10   !------------------+ 10.10.11.11   ! 
!               !                  !               ! 
+---------------+                  +---------------+ 
         !          Setup TCP connection 1! 
         !===============================>! 
         !                                ! 


BGP speaker 1 initiates a TCP connection towards speaker2 
This action is successfull. 


         !   OPEN for connection 1        ! 
         !===============================>! 


Speaker 1 being informed that the TCP is up, sends an OPEN 
message for the connection he initiated. The OPEN message 
is NOT yet treated by speaker 2. (probably speaker 2 is not 
yet aware of the connection because he did not check the TCP 
events ). 


The states in BGP are: 
 Connection 1: Open Sent           Connection 1: idle? 


        !   Setup TCP connection 2        ! 
        !<================================! 
        !                                 ! 


At this stage, speaker 2 also sets up a TCP connection to speaker A 
(this happens before the BGP application of speaker 2 is 
aware of the connection of speaker 1). 
  


        !       OPEN for connection 2     ! 
        !================================>! 


Now BGP speaker 1, being informed of a new connection immediatelly 
sends an OPEN message. On Speaker 2 we have either a slow TCP, a slow BGP 
or a slow link in between (actually it was a test tool, so I do not know 
really).but in any case it seems that the BGP states now became: 


The states in BGP are: 
 Connection 1: Open Sent           Connection 1: idle? 
 Connection 1: Open Sent           Connection 2: idle? 


       !        OPEN for connection 1      ! 
       !<==================================! 
       !                                   ! 
       !        KEEPALIVE for connection 1 ! 
       !==================================>! 


BGP speaker 2 'wakes up' and responds to connection 1. BGP speaker 1 
who is reacting alert, sends a KEEPALIVE for connection 1 
The states in BGP are: 
 Connection 1: Open confirm        Connection 1: see below 
 COnnection 1: Open Sent           Connection 2: ? 


AT this stage, the collision detection mechanism starts in BGP 
speaker 1. Since BGP speaker 2 has the highest id, speaker 1 decides 
to tear down his original TCP connection (connection 1). 


       !   KEEPALIVE for connection 1   ! 
       !<===============================! 
  Connection 1: gone 
  COnnection 2 : Open Sent 


In the mean time BGP speaker 2, not being aware of the fact that 
speaker 1 closed the connection 1 wakes up again, and receives the 
keealive from speaker 1 , sends back a keepalive and bring the 
connection 1 in establsihed state.(note that on this keepalive will be 
lost, as the connection is closed. 
                                   Connection 1: established 


Also at this moment, BGP speaker 2 notices that connection 2 is up 
and sends an OPEN mesage for connection 2, and trasitions to OPEN SENT 
                                   Connection 2: OPEN sent. 


      !        OPEN for connection 2        ! 
      !<====================================! 


BGP speaker 2 then treats the OPEN mesage from speaker 1 (which arrived 
quite some time ago, but was not treated until now). 
for connection 2. 


This triggers the collision detection in speaker 2. As he still 
believes that connection 1 is established, he decides to close the
connection 2 


The end result is that both connection are cleared. 
  
  
  
  
  


------_=_NextPart_001_01C25AA5.32D6B230
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=569584221-12092002>This 
is described in Sue's FSM spec under section.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=569584221-12092002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=569584221-12092002>2.4.2 
Collision Detect Processing in Established state</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=569584221-12092002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=569584221-12092002>If 
Hans implements the config option, the race condition will go 
away.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=569584221-12092002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=569584221-12092002>Ben</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Tom Petch 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, September 12, 
  2002 2:06 PM<BR><B>To:</B> [e-mail]; BGP mailing 
  list<BR><B>Subject:</B> Re: problem in collision 
strategy?<BR><BR></DIV></FONT>
  <DIV><FONT color=#000000 size=2>Interesting, fascinating even.</FONT></DIV>
  <DIV><FONT color=#000000 size=2></FONT>&nbsp;</DIV>
  <DIV><FONT size=2>The two ends should implement the same Connection collision 
  detection and arrive at the same conclusion.&nbsp; The way I read it, both 
  should retain the (TCP) connection initiated by the BGP speaker with the 
  higher value of BGP Identifier; assuming that that is speaker 2, then 
  </FONT></DIV>
  <DIV><FONT size=2></FONT><TT>This triggers the collision detection in speaker 
  2. As he still</TT> <BR><TT>believes that connection 1 is established, he 
  decides to close the connection 2</TT><TT></TT> </DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=#000000 size=2>is in error; speaker 2 should close the first 
  connection just as speaker one has done.</FONT></DIV>
  <DIV><FONT color=#000000 size=2></FONT>&nbsp;</DIV>
  <DIV><FONT color=#000000 size=2>Tom Petch, Network Consultant<BR><A 
  href="mailto:[e-mail]">[e-mail]</A><BR></FONT></DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
    <DIV><FONT face=Arial size=2><B>-----Original Message-----</B><BR><B>From: 
    </B><A 
    href="mailto:[e-mail]">[e-mail]</A> 
    &lt;<A 
    href="mailto:[e-mail]">[e-mail]</A>&gt;<BR><B>To: 
    </B>BGP mailing list &lt;<A 
    href="mailto:[e-mail]">[e-mail]</A>&gt;<BR><B>Date: </B>12 
    September 2002 15:38<BR><B>Subject: </B>problem in collision 
    strategy?<BR></FONT></DIV>
    <DIV>&lt;snip&gt;</DIV>
    <P>(in the scenario below time progresses downwards) <BR>&nbsp; 
    <P><TT>+---------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    +---------------+</TT> <BR><TT>! BGP speaker A 
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    ! BGP speaker B !</TT> <BR><TT>! 10.10.10.10&nbsp;&nbsp; 
    !------------------+ 10.10.11.11&nbsp;&nbsp; !</TT> 
    <BR><TT>!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !</TT> 
    <BR><TT>+---------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    +---------------+</TT> 
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Setup TCP connection 
    1!</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !===============================&gt;!</TT> 
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !</TT> 
    <P><TT>BGP speaker 1 initiates a TCP connection towards speaker2</TT> 
    <BR><TT>This action is successfull.</TT> 
    <P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp; OPEN 
    for connection 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</TT> 
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !===============================&gt;!</TT> 
    <P><TT>Speaker 1 being informed that the TCP is up, sends an OPEN</TT> 
    <BR><TT>message for the connection he initiated. The OPEN message</TT> 
    <BR><TT>is NOT yet treated by speaker 2. (probably speaker 2 is not</TT> 
    <BR><TT>yet aware of the connection because he did not check the TCP</TT> 
    <BR><TT>events ).</TT> 
    <P><TT>The states in BGP are:</TT> <BR><TT>&nbsp;Connection 1: Open 
    Sent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connection 
    1: idle?</TT> 
    <P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp; Setup TCP 
    connection 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</TT> 
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !&lt;================================!</TT> 
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !</TT> 
    <P><TT>At this stage, speaker 2 also sets up a TCP connection to speaker 
    A</TT> <BR><TT>(this happens before the BGP application of speaker 2 is</TT> 
    <BR><TT>aware of the connection of speaker 1).</TT> <BR>&nbsp; 
    <P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OPEN for connection 
    2&nbsp;&nbsp;&nbsp;&nbsp; !</TT> 
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !================================&gt;!</TT> 
    <P><TT>Now BGP speaker 1, being informed of a new connection 
    immediatelly</TT> <BR><TT>sends an OPEN message. On Speaker 2 we have either 
    a slow TCP, a slow BGP</TT> <BR><TT>or a slow link in between (actually it 
    was a test tool, so I do not know</TT> <BR><TT>really).but in any case it 
    seems that the BGP states now became:</TT> 
    <P><TT>The states in BGP are:</TT> <BR><TT>&nbsp;Connection 1: Open 
    Sent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connection 
    1: idle?</TT> <BR><TT>&nbsp;Connection 1: Open 
    Sent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connection 
    2: idle?</TT> 
    <P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OPEN for connection 
    1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</TT> 
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !&lt;==================================!</TT> 
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KEEPALIVE for connection 1 
    !</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !==================================&gt;!</TT> 
    <P><TT>BGP speaker 2 'wakes up' and responds to connection 1. BGP speaker 
    1</TT> <BR><TT>who is reacting alert, sends a KEEPALIVE for connection 
    1</TT> <BR><TT>The states in BGP are:</TT> <BR><TT>&nbsp;Connection 1: Open 
    confirm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connection 1: see 
    below</TT> <BR><TT>&nbsp;COnnection 1: Open 
    Sent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connection 
    2: ?</TT> 
    <P><TT>AT this stage, the collision detection mechanism starts in BGP</TT> 
    <BR><TT>speaker 1. Since BGP speaker 2 has the highest id, speaker 1 
    decides</TT> <BR><TT>to tear down his original TCP connection (connection 
    1).</TT> 
    <P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp; KEEPALIVE for 
    connection 1&nbsp;&nbsp; !</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !&lt;===============================!</TT> <BR><TT>&nbsp; Connection 1: 
    gone</TT> <BR><TT>&nbsp; COnnection 2 : Open Sent</TT> 
    <P><TT>In the mean time BGP speaker 2, not being aware of the fact that</TT> 
    <BR><TT>speaker 1 closed the connection 1 wakes up again, and receives 
    the</TT> <BR><TT>keealive from speaker 1 , sends back a keepalive and bring 
    the</TT> <BR><TT>connection 1 in establsihed state.(note that on this 
    keepalive will be</TT> <BR><TT>lost, as the connection is closed.</TT> 
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    Connection 1: established</TT><TT></TT> 
    <P><TT>Also at this moment, BGP speaker 2 notices that connection 2 is 
    up</TT> <BR><TT>and sends an OPEN mesage for connection 2, and trasitions to 
    OPEN SENT</TT> 
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    Connection 2: OPEN sent.</TT><TT></TT> 
    <P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OPEN for connection 
    2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</TT> 
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    !&lt;====================================!</TT><TT></TT> 
    <P><TT>BGP speaker 2 then treats the OPEN mesage from speaker 1 (which 
    arrived</TT> <BR><TT>quite some time ago, but was not treated until 
    now).</TT> <BR><TT>for connection 2.</TT><TT></TT> 
    <P><TT>This triggers the collision detection in speaker 2. As he still</TT> 
    <BR><TT>believes that connection 1 is established, he decides to close the 
    connection 2</TT><TT></TT> 
    <P><TT>The end result is that both connection are cleared.</TT> <BR>&nbsp; 
    <BR>&nbsp; <BR>&nbsp; <BR>&nbsp; <BR>&nbsp; 
</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C25AA5.32D6B230--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA13125 for <[e-mail]>; Thu, 12 Sep 2002 16:19:16 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E60B89122A; Thu, 12 Sep 2002 16:18:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9FA7D912D4; Thu, 12 Sep 2002 16:17:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E531D91237 for <[e-mail]>; Thu, 12 Sep 2002 16:17:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B24675DE73; Thu, 12 Sep 2002 16:17:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 07D875DE41 for <[e-mail]>; Thu, 12 Sep 2002 16:17:12 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8CKHB498684; Thu, 12 Sep 2002 16:17:11 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([65.241.132.110]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g8CKH5G98670; Thu, 12 Sep 2002 16:17:05 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 12 Sep 2002 20:17:04 -0400
To: "Tom Petch" <[e-mail]>
From: Susan Hares <[e-mail]>
Subject: Re: problem in collision strategy?
Cc: <[e-mail]>, "BGP mailing list" <[e-mail]>
In-Reply-To: <00d901c25a87$15a64c20$0301a8c0@tom3>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_21193775==_.ALT"
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

--=====================_21193775==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed


Tom:

Didn't the improved words and state machine (hares-statemt-02.txt)
and backoff draft fix this?  I thought you had agreed
to that earlier.

If it doesn't could you let me know:

         1) which document you are referencing
         2) what section and page
         3) What you think is wrong with the text.

I am very much looking for any holes in these specifications.

**Top Priority** is the FSM words.  I have always indicated that
the hares-statemt and hares-backoff-01 drafts are additional
documents which address why I think I've nailed the connection
code.

I think we've done the sequence below.  Can you give text and
explain to me why this is not done?

Sue

At 07:06 PM 9/12/2002 +0100, Tom Petch wrote:
>Interesting, fascinating even.
>
>The two ends should implement the same Connection collision detection and 
>arrive at the same conclusion.  The way I read it, both should retain the 
>(TCP) connection initiated by the BGP speaker with the higher value of BGP 
>Identifier; assuming that that is speaker 2, then
>This triggers the collision detection in speaker 2. As he still
>believes that connection 1 is established, he decides to close the 
>connection 2
>
>is in error; speaker 2 should close the first connection just as speaker 
>one has done.
>
>Tom Petch, Network Consultant
><mailto:[e-mail]>[e-mail]
>>-----Original Message-----
>>From: 
>><mailto:[e-mail]>[e-mail] 
>><<mailto:[e-mail]>[e-mail]>
>>To: BGP mailing list <<mailto:[e-mail]>[e-mail]>
>>Date: 12 September 2002 15:38
>>Subject: problem in collision strategy?
>><snip>
>>
>>(in the scenario below time progresses downwards)
>>
>>
>>+---------------+                  +---------------+
>>! BGP speaker A !                  ! BGP speaker B !
>>! 10.10.10.10   !------------------+ 10.10.11.11   !
>>!               !                  !               !
>>+---------------+                  +---------------+
>>          !          Setup TCP connection 1!
>>          !===============================>!
>>          !                                !
>>
>>BGP speaker 1 initiates a TCP connection towards speaker2
>>This action is successfull.
>>
>>          !   OPEN for connection 1        !
>>          !===============================>!
>>
>>Speaker 1 being informed that the TCP is up, sends an OPEN
>>message for the connection he initiated. The OPEN message
>>is NOT yet treated by speaker 2. (probably speaker 2 is not
>>yet aware of the connection because he did not check the TCP
>>events ).
>>
>>The states in BGP are:
>>  Connection 1: Open Sent           Connection 1: idle?
>>
>>         !   Setup TCP connection 2        !
>>         !<================================!
>>         !                                 !
>>
>>At this stage, speaker 2 also sets up a TCP connection to speaker A
>>(this happens before the BGP application of speaker 2 is
>>aware of the connection of speaker 1).
>>
>>
>>         !       OPEN for connection 2     !
>>         !================================>!
>>
>>Now BGP speaker 1, being informed of a new connection immediatelly
>>sends an OPEN message. On Speaker 2 we have either a slow TCP, a slow BGP
>>or a slow link in between (actually it was a test tool, so I do not know
>>really).but in any case it seems that the BGP states now became:
>>
>>The states in BGP are:
>>  Connection 1: Open Sent           Connection 1: idle?
>>  Connection 1: Open Sent           Connection 2: idle?
>>
>>        !        OPEN for connection 1      !
>>        !<==================================!
>>        !                                   !
>>        !        KEEPALIVE for connection 1 !
>>        !==================================>!
>>
>>BGP speaker 2 'wakes up' and responds to connection 1. BGP speaker 1
>>who is reacting alert, sends a KEEPALIVE for connection 1
>>The states in BGP are:
>>  Connection 1: Open confirm        Connection 1: see below
>>  COnnection 1: Open Sent           Connection 2: ?
>>
>>AT this stage, the collision detection mechanism starts in BGP
>>speaker 1. Since BGP speaker 2 has the highest id, speaker 1 decides
>>to tear down his original TCP connection (connection 1).
>>
>>        !   KEEPALIVE for connection 1   !
>>        !<===============================!
>>   Connection 1: gone
>>   COnnection 2 : Open Sent
>>
>>In the mean time BGP speaker 2, not being aware of the fact that
>>speaker 1 closed the connection 1 wakes up again, and receives the
>>keealive from speaker 1 , sends back a keepalive and bring the
>>connection 1 in establsihed state.(note that on this keepalive will be
>>lost, as the connection is closed.
>>                                    Connection 1: established
>>
>>Also at this moment, BGP speaker 2 notices that connection 2 is up
>>and sends an OPEN mesage for connection 2, and trasitions to OPEN SENT
>>                                    Connection 2: OPEN sent.
>>
>>       !        OPEN for connection 2        !
>>       !<====================================!
>>
>>BGP speaker 2 then treats the OPEN mesage from speaker 1 (which arrived
>>quite some time ago, but was not treated until now).
>>for connection 2.
>>
>>This triggers the collision detection in speaker 2. As he still
>>believes that connection 1 is established, he decides to close the 
>>connection 2
>>
>>The end result is that both connection are cleared.
>>
>>
>>
>>
>>


--=====================_21193775==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
Tom:<br>
<br>
Didn't the improved words and state machine (hares-statemt-02.txt)<br>
and backoff draft fix this?&nbsp; I thought you had agreed<br>
to that earlier.<br>
<br>
If it doesn't could you let me know:<br>
<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>1) which
document you are referencing<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>2) what
section and page<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>3) What
you think is wrong with the text.<br>
<br>
I am very much looking for any holes in these specifications.<br>
<br>
**Top Priority** is the FSM words.&nbsp; I have always indicated
that<br>
the hares-statemt and hares-backoff-01 drafts are additional<br>
documents which address why I think I've nailed the connection<br>
code.<br>
<br>
I think we've done the sequence below.&nbsp; Can you give text and<br>
explain to me why this is not done?<br>
<br>
Sue<br>
<br>
At 07:06 PM 9/12/2002 +0100, Tom Petch wrote:<br>
<blockquote type=cite class=cite cite><font size=2>Interesting,
fascinating even.</font><br>
&nbsp;<br>
<font size=2>The two ends should implement the same Connection collision
detection and arrive at the same conclusion.&nbsp; The way I read it,
both should retain the (TCP) connection initiated by the BGP speaker with
the higher value of BGP Identifier; assuming that that is speaker 2, then
</font><br>
<tt>This triggers the collision detection in speaker 2. As he still</tt>
<br>
<tt>believes that connection 1 is established, he decides to close the connection 2</tt> <br>
&nbsp;<br>
<font size=2>is in error; speaker 2 should close the first connection just as speaker one has done.</font><br>
&nbsp;<br>
<font size=2>Tom Petch, Network Consultant<br>
<a href="mailto:[e-mail]">[e-mail]</a><br>
</font><blockquote type=cite class=cite cite><font face="arial" size=2><b>-----Original Message-----</b><br>
<b>From: </b><a href="mailto:[e-mail]">[e-mail]</a> &lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt;<br>
<b>To: </b>BGP mailing list &lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt;<br>
<b>Date: </b>12 September 2002 15:38<br>
<b>Subject: </b>problem in collision strategy?<br>
</font>&lt;snip&gt;<br>
<br>
(in the scenario below time progresses downwards) <br>
&nbsp; <br>
<br>
<tt>+---------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +---------------+</tt> <br>
<tt>! BGP speaker A !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ! BGP speaker B !</tt> <br>
<tt>! 10.10.10.10&nbsp;&nbsp; !------------------+ 10.10.11.11&nbsp;&nbsp; !</tt> <br>
<tt>!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</tt> <br>
<tt>+---------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +---------------+</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Setup TCP connection 1!</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !===============================&gt;!</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</tt> <br>
<br>
<tt>BGP speaker 1 initiates a TCP connection towards speaker2</tt> <br>
<tt>This action is successfull.</tt> <br>
<br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp; OPEN for connection 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !===============================&gt;!</tt> <br>
<br>
<tt>Speaker 1 being informed that the TCP is up, sends an OPEN</tt> <br>
<tt>message for the connection he initiated. The OPEN message</tt> <br>
<tt>is NOT yet treated by speaker 2. (probably speaker 2 is not</tt> <br>
<tt>yet aware of the connection because he did not check the TCP</tt> <br>
<tt>events ).</tt> <br>
<br>
<tt>The states in BGP are:</tt> <br>
<tt>&nbsp;Connection 1: Open Sent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connection 1: idle?</tt> <br>
<br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp; Setup TCP connection 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&lt;================================!</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</tt> <br>
<br>
<tt>At this stage, speaker 2 also sets up a TCP connection to speaker A</tt> <br>
<tt>(this happens before the BGP application of speaker 2 is</tt> <br>
<tt>aware of the connection of speaker 1).</tt> <br>
&nbsp; <br>
<br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OPEN for connection 2&nbsp;&nbsp;&nbsp;&nbsp; !</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !================================&gt;!</tt> <br>
<br>
<tt>Now BGP speaker 1, being informed of a new connection immediatelly</tt> <br>
<tt>sends an OPEN message. On Speaker 2 we have either a slow TCP, a slow BGP</tt> <br>
<tt>or a slow link in between (actually it was a test tool, so I do not know</tt> <br>
<tt>really).but in any case it seems that the BGP states now became:</tt> <br>
<br>
<tt>The states in BGP are:</tt> <br>
<tt>&nbsp;Connection 1: Open Sent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connection 1: idle?</tt> <br>
<tt>&nbsp;Connection 1: Open Sent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connection 2: idle?</tt> <br>
<br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OPEN for connection 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&lt;==================================!</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KEEPALIVE for connection 1 !</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !==================================&gt;!</tt> <br>
<br>
<tt>BGP speaker 2 'wakes up' and responds to connection 1. BGP speaker 1</tt> <br>
<tt>who is reacting alert, sends a KEEPALIVE for connection 1</tt> <br>
<tt>The states in BGP are:</tt> <br>
<tt>&nbsp;Connection 1: Open confirm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connection 1: see below</tt> <br>
<tt>&nbsp;COnnection 1: Open Sent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connection 2: ?</tt> <br>
<br>
<tt>AT this stage, the collision detection mechanism starts in BGP</tt> <br>
<tt>speaker 1. Since BGP speaker 2 has the highest id, speaker 1 decides</tt> <br>
<tt>to tear down his original TCP connection (connection 1).</tt> <br>
<br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp; KEEPALIVE for connection 1&nbsp;&nbsp; !</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&lt;===============================!</tt> <br>
<tt>&nbsp; Connection 1: gone</tt> <br>
<tt>&nbsp; COnnection 2 : Open Sent</tt> <br>
<br>
<tt>In the mean time BGP speaker 2, not being aware of the fact that</tt> <br>
<tt>speaker 1 closed the connection 1 wakes up again, and receives the</tt> <br>
<tt>keealive from speaker 1 , sends back a keepalive and bring the</tt> <br>
<tt>connection 1 in establsihed state.(note that on this keepalive will be</tt> <br>
<tt>lost, as the connection is closed.</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connection 1: established</tt> <br>
<br>
<tt>Also at this moment, BGP speaker 2 notices that connection 2 is up</tt> <br>
<tt>and sends an OPEN mesage for connection 2, and trasitions to OPEN SENT</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connection 2: OPEN sent.</tt> <br>
<br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OPEN for connection 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</tt> <br>
<tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&lt;====================================!</tt> <br>
<br>
<tt>BGP speaker 2 then treats the OPEN mesage from speaker 1 (which arrived</tt> <br>
<tt>quite some time ago, but was not treated until now).</tt> <br>
<tt>for connection 2.</tt> <br>
<br>
<tt>This triggers the collision detection in speaker 2. As he still</tt> <br>
<tt>believes that connection 1 is established, he decides to close the connection 2</tt> <br>
<br>
<tt>The end result is that both connection are cleared.</tt> <br>
&nbsp; <br>
&nbsp; <br>
&nbsp; <br>
&nbsp; <br>
&nbsp; </blockquote></blockquote><br>
</html>

--=====================_21193775==_.ALT--



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA12785 for <[e-mail]>; Thu, 12 Sep 2002 16:08:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 56ECE912D9; Thu, 12 Sep 2002 16:08:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 223F9912DA; Thu, 12 Sep 2002 16:08:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C194A912D9 for <[e-mail]>; Thu, 12 Sep 2002 16:08:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B208D5DE7B; Thu, 12 Sep 2002 16:08:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id EF3005DE41 for <[e-mail]>; Thu, 12 Sep 2002 16:08:19 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8CK8J598468; Thu, 12 Sep 2002 16:08:19 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([65.241.132.110]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g8CK8FG98461; Thu, 12 Sep 2002 16:08:15 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 12 Sep 2002 20:08:15 -0400
To: "Natale, Jonathan" <[e-mail]>
From: Susan Hares <[e-mail]>
Subject: RE: FSM ConnectRetryCnt 
Cc: idr <[e-mail]>
In-Reply-To: <[e-mail] loxnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Jonathan:

warning:
    The FSM words are not in draft-17.  The FSM words to review
    have been sent to the text and you.  Please stop reviewing
    draft-17 - I don't want you to waste your precious time.

Please note that - we have done this.  hares-backoff-00 (and
soon to be hares-backoff-01)  awaits your comments.

But..we should start a different email threat on this one.

It is not in the current fsm words.

Sue


At 12:32 PM 9/12/2002 -0400, Natale, Jonathan wrote:
>I though we were documenting what is deployed and what is hard to read?  I
>agree that peer flapping is a noble cause, but maybe the whole concept
>should be in another draft?
>
>-----Original Message-----
>From: Tom Petch [mailto:[e-mail]]
>Sent: Wednesday, September 11, 2002 6:01 PM
>To: Susan Hares
>Cc: idr; Susan Hares; yakov Rekhter; [e-mail]; [e-mail];
>randy Bush
>Subject: Re: FSM ConnectRetryCnt
>
>Um; thanks for the explanation.  I appreciate I am picky but I would
>like a brief sentence in BGP base document as to why we do this, if we
>keep the rest of the processing in which I assume we should (?).
>
>Tom Petch
>[e-mail]
>-----Original Message-----
>From: Susan Hares <[e-mail]>
>To: Tom Petch <[e-mail]>
>Cc: idr <[e-mail]>; Susan Hares <[e-mail]>; yakov Rekhter
><[e-mail]>; [e-mail]
><[e-mail]>; [e-mail] <[e-mail]>; randy Bush
><[e-mail]>
>Date: 11 September 2002 21:18
>Subject: Re: FSM ConnectRetryCnt
>
>
> >
> >1st - ConnectRetryCnt was included to damp out
> >         persistent bgp peer oscillations.
> >
> >         1) The peer connections would drop due to an error condition
> >            (such as a bogus prefix),
> >         2) the auto-restart would engage,
> >         3) the connection would re-establish,
> >         4) the same data would get sent the error would occur, and
> >                 the cycle starts with #1
> >
> >The bgp peer oscillation draft I've written took this information
> >out of the BGP specification due to working group consensus
> >**AND** the fact it did not match with the current implementations.
> >
> >Since the persistent route oscillation **is** in some
>implementations,
> >we put the text off into a separate document.   Divide and conquer
> >
> >hares-backoff-00.txt
> >was my latest draft.  Due to the charter of the WG at this time,
> >we cannot include this in the work until we finish the.
> >
> >The ConnectRetryCnt is cleared upon manual reset, because
> >the operators need something to be able to manual stop the
> >mechanism to stop the flap.
> >
> >Does this answer the questions on the draft?
> >
> >sue
> >
> >
> >06:30 PM 9/11/2002 +0100, Tom Petch wrote:
> >>This seems to have lost its purpose (which it had in BGP-17).  It
>gets
> >>cleared on manual stop, incremented by one when something goes wrong
> >>but so what?  An explanation would help.
> >>
> >>And I think it should be a Session Attribute required for each
> >>connection, along with
> >>OpenDelayTimer
> >>DelayOpenFlag
> >>
> >>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 QAA12706 for <[e-mail]>; Thu, 12 Sep 2002 16:06:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C92FC912D8; Thu, 12 Sep 2002 16:05:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6FB96912D9; Thu, 12 Sep 2002 16:05:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 23085912D8 for <[e-mail]>; Thu, 12 Sep 2002 16:05:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 038925DE7B; Thu, 12 Sep 2002 16:05:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 40E075DE41 for <[e-mail]>; Thu, 12 Sep 2002 16:05:52 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8CK5px98330; Thu, 12 Sep 2002 16:05:51 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([65.241.132.110]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g8CK5mG98323; Thu, 12 Sep 2002 16:05:48 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 12 Sep 2002 20:05:47 -0400
To: "Natale, Jonathan" <[e-mail]>
From: Susan Hares <[e-mail]>
Subject: Re: FW: FSM more words 
Cc: [e-mail]
In-Reply-To: <[e-mail] loxnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Jonathan and Curtis:

**We are not reviewing the draft-17 text.  We are reviewing the
FSM word replacements.   Please save your precious cycles
of review for the text I just sent out.  It has been
sent out several times (in the same form) from July 17th forward.


At 12:26 PM 9/12/2002 -0400, Natale, Jonathan wrote:


>-----Original Message-----
>From: Natale, Jonathan
>Sent: Thursday, September 12, 2002 12:23 PM
>To: '[e-mail]'
>Subject: RE: FSM more words
>
>I also think that the terms should be consistent.  Curtis, I see your point,
>but I also think that by using consistent terms it is easier to search the
>doc.
>
>-----Original Message-----
>From: Curtis Villamizar [mailto:[e-mail]]
>Sent: Wednesday, September 11, 2002 5:33 PM
>To: Tom Petch
>Cc: idr; Susan Hares; yakov Rekhter; [e-mail]; [e-mail];
>randy Bush
>Subject: Re: FSM more words
>
>
>In message <013601c259b9$f5fcc340$0301a8c0@tom3>, "Tom Petch" writes:
> > In the 26Aug text, I find the timer terminology still confusing.
> > Timers can, I find,
> > stop
> > start
> > restart
> > clear
> > set
> > reset
> > expire

I would like you to review the improved text and see if we have
put context around most of these.  A timer may be started, stopped, cleared,
reset or expire.  I believe the context to be complete in
the second set of words.

Could you check the right set of words and see what you think.

Sue Hares


> >
> > Rich the English language is but I see this as overuse.
> > For me, timers
> > start, stop, expire
>
>I didn't find the word "reset" in draft-ietf-idr-bgp4-17.tx.
>
>Restarting a time is getting rid of any running timer and starting the
>timer from its configured initial value (ie: stop, then start).  That
>seems to be entirely consistent with uses of the word restart in other
>contexts.
>
>Clear and stop a timer are synonomous.  I can't see how that could not
>be obvious.
>
>The word set is used in phrases like "set Hold timer to a large value"
>which is not adequately covered by the words start and stop.
>
> > The only further refinement is that they may start with an initial
> > value or with the value they had when they were stopped (eg NFL game
> > clocks); I do not believe, but cannot be sure, that the last is ever
> > used in the FSM.  Which means all we need is
> > start with initial value (spell it out just to be sure)
> > stop
> > expire
> > and anything else just confuses - me and I suspect others.
> >
> > Tom Petch
> > [e-mail]
>
>Just as we can't include a complete TCP tutorial, we can't include
>english dictionary entries for every small word used in the document.
>
>I don't see any reason for change.
>
>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 QAA12652 for <[e-mail]>; Thu, 12 Sep 2002 16:04:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A8774912D7; Thu, 12 Sep 2002 16:01:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F3ED912D8; Thu, 12 Sep 2002 16:01:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 16604912D7 for <[e-mail]>; Thu, 12 Sep 2002 16:01:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E87145DE7B; Thu, 12 Sep 2002 16:01:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 3EEB25DE6D for <[e-mail]>; Thu, 12 Sep 2002 16:01:30 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8CK1TI98197; Thu, 12 Sep 2002 16:01:29 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([65.241.132.110]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g8CK1OG98188; Thu, 12 Sep 2002 16:01:24 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 12 Sep 2002 20:01:24 -0400
To: [e-mail]
From: Susan Hares <[e-mail]>
Subject: Re: IdleHold
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_20252701==_"
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

--=====================_20252701==_
Content-Type: text/plain; charset="us-ascii"; format=flowed


Greg and all members of IDR.

We are not reviewing draft-17.  Draft-17 is broken.
We are reviewing the text I sent to the list for inclusion.
I am attaching the text.

Please, please stop if you are reviewing draft-17.  The comments
you are raising have been raised before (sometimes by
co-workers in your same company).  And I fixed the text.

Greg - you are not the only one with this misconception.

Was there some way the last call was unclear about
what was being reviewed?


Sue

At 12:09 PM 9/12/2002 -0400, Greg Hankins wrote:
>On Thu, Sep 12, 2002 at 03:29:31PM -0400, Susan Hares wrote:
> >1st clarification - there is no IdleHold state in BGP.  There is
> >an IDLE state with sub-state like features.  Where do you find this
> >IdleHold state in the words I've attached?
>
>draft-ietf-idr-bgp4-17 page 34.  It describes a new state, a new timer and
>a new flag.  You imply that the state has already been moved to a separate
>draft, if so then this is great.
>
>Greg
>
> >At 10:45 AM 9/12/2002 -0400, Greg Hankins wrote:
> >>I am still not convinced that IdleHold should be in the new BGP
> >>specification.
> >>
> >>Given that the goal of the WG is to "revise and clarify the base BGP4
> >>document" and to "document existing practice", I do not think that it
> >>should be included because this doesn't seem to be an existing practice
> >>(or at least one practiced by the majority of implementations).
> >>
> >>I have two questions:
> >>
> >>1. Which existing implementations support the IdleHold state, its timer
> >>    and flag?
> >
> >***NO*** Implementation support Idle hold state.
> >
> >Please refer to the hares-backoff draft for two know possibilities.
> >GateD by NextHop was the source of one method.  Another method is
> >attempting to describe cisco's back-off.   We will look to include others.
> >It's a "drafty" draft right now.  Please send me your favorite
> >persisent peer oscillation information.
> >
> >>2. What existing documentation (books/courses/etc) lists IdleHold as a 
> state
> >>    in the FSM?
> >
> >There is no IdleHold state.  There are Idle hold features (see the
> >bgp draft-15 for those sub-features described.)
> >
> >
> >>If the answers to these questions are not "the majority", then it isn't
> >>an existing practice.  Any implementation that does not support this state
> >>is now automatically non-standards compliant.
> >>
> >>I suggest that this state be documented in a separate draft that addresses
> >>stability.
> >
> >The sub-state within Idle has been moved to the backoffdraft.
> >We are taking this approach.  Yakov and I agree that this is a good idea.
> >
> >
> >Hope this helps.   Do give me a call if this is unclear.  Let me know
> >if you need the phone number.
> >
> >Sue
> >
> >
> >
> >
> >
> >
> >>Greg
> >>
> >>--
> >>Greg Hankins <[e-mail]> | Riverstone Networks, Inc.
> >>Systems Engineering                       | 5200 Great America Parkway
> >>http://www.riverstonenet.com/             | Santa Clara, CA 95054
> >>[phone]                           | [phone]
>
> >
> >
> >Note: (this is version 5 of the changes to
> >       the text.)
> >
> >8.0    BGP Finite State Machine
> >
> >
> >This section specifies the BGP operation in terms of a
> >Finite State Machine (FSM).  The section falls into 2
> >parts:
> >
> >    1) Description of Events for the State machine (section
> >        8.1
> >    2) Description of the FSM (section 8.2)
> >
> >Session Attributes required for each connection are;
> >
> >   1)  state
> >   2)  Connect Retry timer
> >   3)  Hold timer
> >   4)  Hold time
> >   5)  Keepalive timer
> >
> >8.1 Events for the BGP FSM
> >
> >8.1.1   Administrative Events (events 1-5)
> >
> >Please note that only Event 1 (manual start) and Event 2
> >(manual stop) are mandatory administrative events. All
> >other administrative events are optional.
> >
> > Event1: Manual start
> >
> >          Definition: Administrator manually starts peer
> >                       connection
> >          Status:      Mandatory
> >
> > Event2: Manual stop
> >
> >          Definition: Local system administrator manually
> >                       stops the peer connection.
> >
> >          Status:      mandatory
> >
> >
> > Event3: Automatic Start
> >
> >          Definition: Local system automatically starts the
> >                       BGP peer session
> >
> >          Status:     Optional depending on local system
> >
> > Event4: Manual start with passive Transport Establishment
> >
> >          Definition: Administrator manually start the peer
> >                       Connection, but has the passive flag
> >                       enabled.  The passive flag indicates
> >                       that the peer will listen prior to
> >                       establishing the connection.
> >
> >          Status:     Optional depending on local system
> >
> >
> > Event5: Automatic start with passive Transport establishment
> >
> >         Definition:  Local system automatically starts the
> >                       BGP session with the passive flag
> >                       enabled.  The passive flag indicates
> >                       that the peer will listen prior to
> >                       establishing a connection.
> >
> >         Status:      Optional depending on local system use
> >                      of a passive connection.
> >
> > Event6: Automatic start with bgp_stop_flap option set
> >
> >          Definition: Local system automatically starts the
> >                       BGP peer session with persistent peer
> >                       oscillation damping enabled.  The exact
> >                       method of damping persistent peer
> >                       oscillations is left up to the
> >                       implementation.   These methods of
> >                       damping persistent BGP adjacency
> >                       flapping are outside the scope of this
> >                       document.
> >
> >
> >           Status:     Optional, used only if the bgp peer has
> >                       Enabled a method of damping persistent
> >                       BGP peer flapping.
> >
> >
> > Event7: Auto stop
> >
> >          Definition: Local system automatically stops the
> >                       BGP peer session.
> >
> >          Status:     Optional depending on local system
> >
> >
> >8.1.2 Timer Events (events 8-11)
> >
> > Event8:  idle Hold timer expires
> >
> >           Definition: Idle Hold timer expires.  The Idle
> >                       Hold Timer is only used when persistent
> >                       BGP oscillation damping functions are
> >                       enabled.
> >
> >           Status:     Optional.  Used when persistent
> >                       BGP peer oscillation damping functions
> >                       are enabled.
> >
> >
> >
> > Event9: connect retry timer expires
> >
> >           Definition: An event triggered by the expiration of
> >                       the ConnectRetry timer.
> >
> >          Status:     Mandatory
> >
> > Event10: hold time expires
> >
> >          Definition: An event generated when the HoldTimer
> >                       expires.
> >
> >          Status:     Mandatory
> >
> > Event11: keepalive timer expires
> >
> >          Definition: A periodic event generated due to the
> >                       expiration of the KeepAlive Timer.
> >
> >          Status:     Mandatory
> >
> > Event12: DelayBGP Open timer expires [changed]
> >
> >          Definition: A timer that delays sending of the BGP
> >                      Open message for n seconds after the
> >                       Transport connection has been completed.
> >
> >          status:     Optional
> >
> >8.2.3) Tranport Message based (13-16)
> >
> > Event13: Transport Connection Indication & valid remote peer[changed]
> >
> >          Definition: Event indicating that transport
> >                       Request 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.
> >
> >
> >          Status:     Mandatory
> >
> > Event14: RCV Transport Connection Indication and Invalid Source or
> >          Destination [changed]
> >
> >           Definition: Transport request received 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.
> >
> >           Status:     Mandatory
> >
> > Event15: Transport Connection request sent received an ACK.
> >
> >           Definition: Local system's request to establish a transport
> >                      Connection to the remote side received
> >                      an ACK.
> >
> >
> >           Status:    Mandatory
> >
> > Event16: Transport Connection Confirmed [changed]
> >
> >          Definition: The local system has received a Confirmation that
> >                       the transport connection has been established by
> >                      the remote site.
> >
> >         Status:      Mandatory
> >
> > Event17: Transport connection fails [changed]
> >
> >           Definition: This BGP peer receives a transport
> >                      connection failure notice.  This
> >                      connection notice could be caused by a
> >                      Transport disconnect message or a
> >                      Timeout in the transport session.
> >
> >                       If this connection is using TCP, 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
> >
> >
> >8.1.4 BGP Messages (18-27)
> >
> > Event18: BGPOpen
> >
> >           Definition:  An event indicating that a valid Open
> >                       message has been received.
> >
> >          Status:      Mandatory
> >
> > Event19: BGPOpen with BGP Delay Open Timer running [changed]
> >
> >           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.
> >
> >           Status:    Optional
> >
> > Event20: BGPHeaderErr
> >
> >          Definition: BGP message header is not valid.
> >
> >          Status:     Mandatory
> >
> > Event21: BGPOpenMsgErr
> >          Definition: An BGP Open message has been received
> >                        with errors.
> >
> >          Status:      Mandatory
> >
> >
> > Event22: Open collision discard
> >
> >           Definition: An event generated administratively
> >                       when a connection Collision has been
> >                       detected while processing an incoming
> >                       Open message. This connection has been
> >                       selected to disconnected.  See section
> >                       6.8 for more information on collision
> >                      detection.
> >
> >                       Event 22 is an administrative could
> >                       occur if FSM is implemented as two
> >                       linked state machines.
> >
> >         Status:      Optional
> >
> > Event23: NotifMsgVerErr
> >
> >           Definition: An event is generated when a
> >                        NOTIFICIATION message with "version
> >                        error" is received.
> >
> >           Status:     Mandatory
> >
> > Event24: NotifMsg
> >
> >           Definition: An event is generated when a
> >                        NOTIFICATION messages is received and
> >                        the error code is anything but
> >                       "version error".
> >
> >            Status:    Mandatory
> >
> > Event25: KeepAliveMsg
> >
> >           Definition: An event is generated when a KEEPALIVE
> >                       Message is received.
> >
> >               Status: Mandatory
> >
> > Event26: UpdateMsg
> >
> >           Definition: An event is generated when a valid
> >                       Update Message is received.
> >
> >               Status: Mandatory
> >
> > Event27: UpdateMsgErr
> >
> >           Definition: An event is generated when an invalid
> >                       Update message is received.
> >
> >               Status: Mandatory
> >
> >
> >8.2) Description of FSM
> >
> >
> >Idle state
> >
> >   Initially BGP is in the Idle state.
> >
> >   In this state BGP refuses all incoming BGP connections.  No
> >   resources are allocated to the peer.    In response to a
> >   manual start event(Event1) or an automatic start
> >   event(Event3), the local system
> >      -        initializes all BGP resources,
> >      -        sets the Connect retry counter to zero
> >      -        starts the ConnectRetry timer with initial value,
> >      -        initiates a transport connection to the other BGP
> >        peer,
> >      -        listens for a connection that may be initiated by
> >        the remote BGP peer, and
> >        [Action A in the FSM table]
> >      -        changes its state to connect.
> >
> >  An manual stop event (Event2) is ignored in the Idle state.
> >
> >  In response to a manual start event with the passive Transport
> >  flag (Event 4) or automatic start with the passive Transport flag
> >  (Event 5), the local system:
> >      -        initializes all BGP resources,
> >      -        sets the connect retry count to zero,
> >      -        start the Connect Retry timer with initial value,
> >      -        listens for a connection that may be initiated by
> >        the remote peer
> >        [Action B in the FSM table]
> >      -        changes its state to Active.
> >
> >  The exact value of the ConnectRetry timer is a local
> >  matter, but it should be sufficiently large to allow TCP
> >  initialization.
> >
> >  If a persistent BGP peer oscillation damping function is
> >  enabled, two additional events may occur within Idle state:
> >      -        Automatic start with bgp_stop_flap set [Event6],
> >      -        Idle Hold Timer expired [Event 8].
> >
> >  The method of preventing persistent BGP peer oscillation is
> >  outside the scope of this document.
> >
> >  Any other events [Events 9-27] received in the Idle state,
> >  are noted by the MIB processing as FSM Errors [action V]
> >  and the local peer stays in the Idle State.
> >
> >
> >Connect State:
> >
> >  In this state, BGP is waiting for the transport protocol
> >  connection to be completed.
> >
> >  If the transport 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:
> >     - clears the ConnectRetry timer,
> >     - set the BGP Open Delay timer to the initial
> >        value.
> >        [Action ZZ in FSM table]
> >
> >  If the Delay Open flag is not set, the local system:
> >     - clears the ConnectRetry timer,
> >     - completes BGP initialization
> >     - send an Open message to its peer,
> >     - sets Hold timer to a large value,
> >     - Change the state to Open Sent
> >   [Action H in the FSM table]
> >
> >  A hold timer value of 4 minutes is suggested.
> >
> >  If the Open Delay timer expires [Event 12] in the connect
> >  state,
> >     - send an Open message to its peer,
> >     - set the Hold timer to a large value,
> >       [Action H in the FSM Table], and
> >     - change the state to Open Sent.
> >
> >  If the BGP port receives a Transport connection indication
> >  [Event 13], the Transport connection is processed (actions AA or
> >  AB in the FSM table) and the connection remains
> >  in the connected state.
> >
> >  If the transport connection receives an Transport indication
> >  that is invalid or unconfigured. [Event 14]:
> >     - the transport connection is rejected.
> >       [Action L in the FSM table]
> >
> >  If the transport connection fails (timeout or transport
> >  disconnect) [Event17], the local system:
> >      - restarts the ConnectRetry timer,
> >      - continues to listen for a connection that may be
> >        initiated by the remote BGP peer, and
> >     [Action G in the FSM table]
> >      - changes its state to Active.
> >
> >
> >  If an Open is received with the BGP Delay Open timer is
> >  running [Event 19], the local system:
> >       - clears the connect retry timer (cleared to zero),
> >       - completes the BGP initialization,
> >       - Stops and clears the BGP Open Delay timer
> >       - Sends an Open message
> >
> >       [Action H in the FSM table], and
> >       - changes its state to Open Confirm.
> >
> >
> > The start events [Event 1, 3-6] are ignored in connect
> > state.
> >
> > A manual stop event[Event2], the local system:
> >       - drops the transport connection,
> >       - releases all BGP resources,
> >       - sets connect retry count to zero
> >       - resets the connect retry timer (sets to zero)
> >      [Action Z in the FSM table]
> >       - goes to Idle state.
> >
> >  In response to the ConnectRetry timer expired event(Event
> >  9), the local system:
> >      - Sets the MIB FSM error information with ConnectRetry
> >        expired,
> >      - drops the transport connection
> >      - restarts the ConnectRetry timer
> >      - initiates a transport connection to the other BGP
> >        peer,
> >      - continues to listen for a connection that may be
> >        initiated by the remote BGP peer, and
> >      [Action O in the FSM table]
> >      - stays in Connect state.
> >
> > In response to any other events [Events 7-8, 10-11, 18, 20-
> > 27] the local system:
> >     - resets the connect retry timer (sets to zero),
> >     - drops the Transport connection,
> >     - release all BGP resources,
> >     - increments the ConnectRetryCnt by 1,
> >     - [optionally] performs bgp peer oscillation damping, and
> >     [Action D in the FSM table],
> >     - goes to Idle state.
> >
> >
> >Active State:
> >
> > In this state BGP is trying to acquire a peer by listening
> > for and accepting a transport protocol connection.
> >
> > A transport connection succeeds [Event 15 or Event 16], the
> > local system: process the transport connection flags
> >       - If the BGP delay open flag is set:
> >          o clears the ConnectRetry timer,
> >          o completes the BGP initialization,
> >          o sets the BGP delay Open timer
> >         [Action ZZ]
> >
> >        - If the BGP delay open flag is not set:
> >          o clears the ConnectRetry timer,
> >          o completes the BGP initialization,
> >          o sends the Open message to it's peer,
> >          o sets its Hold timer to a large value,
> >         [Action H in the FSM table]
> >          and changes its state to OpenSent.
> >
> > A Hold timer value of 4 minutes is suggested.
> >
> > If the local system receives a valid Transport Indication
> > [Event 13], the local system processes the Transport flags
> >  (actions aa or ab in FSM section 2.3.4).
> >
> > If the local system receives a Transport indication
> > that is invalid for this connection [Event 14]:
> >      - the transport connection is rejected
> >        [Action L in the FSM table]
> >
> > If the local system receives a Transport connection
> > failed [Event 17] (timeout or receives Transport
> > disconnect), the local system will:
> >       - set Transport disconnect in the MIB reason code,
> >       - restart ConnectRetry timer (with initial value)
> >       - release all BGP resources
> >       - Acknowledge the drop of Transport connection if
> >          transport disconnect (If TCP, send a FIN ACK),
> >       - Increment ConnectRetryCnt by 1,
> >       - perform the BGP peer oscillation damping process [2]
> >       [Action Y in the FSM table]
> >
> > If the local system has the Delay Open timer expired [event
> > 12] local system:
> >        - clears the Connect Retry timer (set to zero),
> >       - stops and clears the Delay Open timer (set to zero)
> >        - completes the BGP initialization,
> >        - sends the Open message to it's remote peer,
> >        - sets it's Hold timer to a large value,
> >        [Action H in the FSM table]
> >        - and set the state to Open Confirm.
> >
> > A Hold timer value of 4 minutes is also suggested for this
> > state transition.
> >
> > If an Open is received with the BGP Delay Open timer is
> > running [Event 19], the local system
> >       - clears the connect retry timer (cleared to zero),
> >       - Stops and clears the BGP Open Delay timer
> >       - completes the BGP initialization,
> >       - Stops and clears the BGP Open Delay timer
> >       - Sends an Open message
> >       - Set the Hold timer to a large value (4 minutes),
> >       [Action H in the FSM table], and
> >       - changes its state to Open Confirm.
> >
> >
> > In response the ConnectRetry timer expired event[Event9],
> > the local system:
> >        - restarts the ConnectRetry timer (with initial value),
> >        - initiates a transport connection to the other BGP
> >          peer,
> >        - Continues to listen for transport connection that may be
> >          initiated by remote BGP peer,
> >        [Action F in the FSM table]
> >       - and changes its state to Connect.
> >
> >
> > The start events [Event1, 3-6] are ignored in the Active
> > state.
> >
> > A manual stop event[Event2], the local system:
> >        - Sets the administrative down in the MIB reason code,
> >       - Sends a notification with a Cease,
> >       - If any BGP routes exist, delete the routes
> >       - release all BGP resources,
> >       - drops the Transport connection,
> >        - sets connect retry count to zero
> >        - resets the connect retry timer (sets to zero)
> >        [Action S in the FSM table]
> >        - goes to Idle state.
> >
> > In response to any other event (Events 7-8, 10-11,18, 20-
> > 27), the local system:
> >        - stores the MIB information to indicate appropriate
> >          error [FSM for Events 7-8, 10-11, 18, 20-27]
> >        - reset the connect retry timer (sets to zero),
> >        - release all BGP resources,
> >       - drops the transport connection,
> >        - increments the ConnectRetryCnt by one,
> >        - optionally performs BGP peer oscillation damping,
> >         [Action D in FSM table],
> >       - and goes to the idle state
> >
> >
> >Open Sent:
> >
> > In this state BGP waits for an Open Message from its peer.
> >
> > When an OPEN message is received, all fields are checked
> > for correctness.  If there are no errors in the OPEN message
> > [Event 18] the local system:
> >       - resets the BGP Delay timer to zero,
> >       - reset BGP Connect Timer to zero,
> >       - sends a KEEPALIVE message and
> >       - sets a KeepAlive timer (via the text below)
> >       - sets the Hold timer according to the negotiated value
> >         (see section 4.2), and
> >         [Action N in the FSM table]
> >       - sets the state to Open Confirm.
> >
> >
> > If the negotiated Hold time value is zero, then the Hold
> > Time timer and KeepAlive timers are not started.   If the
> > value of the Autonomous System field is the same as the
> > local Autonomous System number, then the connection is an
> > "internal" connection; otherwise, it is an "external"
> > connection.   (This will impact UPDATE processing as
> > described below.)
> >
> >
> > If the BGP message header checking [Event20] or OPEN message
> > check detects an error (see Section 6.2)[Event21], the local system:
> >       - sends a NOTIFICATION message with appropriate error
> >         code,
> >       - reset the connect retry timer (sets to zero),
> >       - if there are any routes associated with the BGP session,
> >       delete these routes
> >       - release all BGP resources,
> >       - drop the transport session
> >       - increments the ConnectRetryCnt by 1,
> >       - bgp peer oscillation damping process,
> >       [Actions I, J in FSM table, depending on error],
> >       - and goes to the Idle state.
> >
> > Collision detection mechanisms (section 6.8) need to be
> > applied when a valid BGP Open is received [Event 18 or
> > Event 19].  Please refer to section 6.8 for the details of
> > the comparison. An administrative collision detect is when
> > BGP implementation determines my means outside the scope of
> > this document that a connection collision has occurred.
> >
> > If a connection in Open Sent is determined to be the
> > connection that must be closed, an administrative collision
> > detect [Event 22] is signaled to the state machine. If such
> > an administrative collision detect dump [Event 22] is
> > received in Open Sent, the local system:
> >       - sets MIB state information to
> >         collision detect closure,
> >       - send a NOTIFICATION with a CEASE
> >       - resets the connect retry timer,
> >       - release all BGP resources,
> >       - drop the transport connection,
> >       - increments ConnectRetryCnt by 1,
> >       - performs any BGP peer oscillation damp process, and
> >       [Action R in the FSM],
> >       - enters Idle state.
> >
> >
> >  If a NOTIFICATION message is received with a version
> >  error[Event23], Notification message without version number
> >  [Event 24], the local system:
> >       - resets the connect retry timer (sets to zero)
> >       - drops the Transport connection,
> >       - releases all BGP resources,
> >       - increments the ConnectRetryCnt by 1
> >       - process any BGP peer oscillation damping,
> >       [Action Y]
> >       - and sets the state to Idle.
> >
> >
> > The Start events [Event1, 3-6] are ignored in the OpenSent
> > state.
> >
> >  If a manual stop event [Event 2] is issued in Open sent
> > state, the local system:
> >       - Sets administrative down reason in MIB reason,
> >       - sends the Notification with a cease,
> >       - if BGP routes exists, delete the routes,
> >       - Release all BGP resources,
> >       - Drops the Transport connection,
> >       - set ConnectRetryCnt to zero,
> >       - resets the Connect Retry timer (set to zero),
> >       [Action S in the FSM table], and
> >       - transitions to the Idle state.
> >
> >  If an automatic stop event [Event 7] is issued in Open sent
> >  state, the local system:
> >       - Sets administrative down reason in MIB reason,
> >       - sends the Notification with a cease,
> >       - if any routes are associated with te BGP session,
> >         delete the routes,
> >       - release all the BGP resources
> >       - Drops the Transport connection,
> >       - increments the ConnectRetryCnt by 1,
> >       - BGP peer oscillation process [2]
> >       [Action C in the FSM table], and
> >       - transitions to the Idle state.
> >
> > If the Hold Timer expires[Event 10], the local system:
> >       - set Hold timer expired in MIB Error reason code,
> >       - send a NOTIFICATION message with error code Hold
> >         Timer Expired,
> >       - reset the connect retry timer (sets to zero),
> >       - releases all BGP resources,
> >       - drops the Transport connection,
> >       - increments the ConnectRetryCnt by 1
> >         [Action K in the FSM table], and
> >       - transitions to the Idle state.
> >
> >
> > If a transport indication is received for valid connection
> > [Event 13] or transport Request Acknowledgement [Event 15]
> > is received, or a transport connect confirm [Event 16] is
> > received a second TCP session may be in progress.  This
> > second TCP session is tracked per the Call Collision
> > processing (section 6.8) until an OPEN message is received.
> >
> > A TCP connection for an invalid port [Event 14] is ignored.
> >
> > If a Transport Failure [Event17], is received from the
> > underlying transport protocol, the local system:
> >       - closes the BGP connection,
> >       - restarts the Connect Retry timer,
> >       - and continues to listen for a connection that may be
> >         initiated by the remote BGP peer,
> >       [Action O in the FSM table]
> >       - and goes into Active state.
> >
> >
> > In response to any other event [Events 8-9, 11-12, 19, 25-27],
> >  the local system:
> >       - sends the NOTIFICATION with the Error Code Finite
> >          state machine error,
> >        - resets the connect retry timer (sets to zero),
> >       - releases all BGP resources
> >        - drops the Transport connection,
> >        - increments the ConnectRetryCnt by 1,
> >        - process any bgp peer oscillation damping[2]
> >        [Action E in the FSM table],
> >        - and sets the state to idle.
> >
> >
> >Open Confirm State
> >
> > In this state BGP waits for a KEEPALIVE or NOTIFICATION
> > message.
> >
> > If the local system receives a KEEPALIVE message[Event 25],
> >        - restarts the Hold timer,
> >          [Action P in the FSM table], and
> >        - changes its state to Established.
> >
> >
> > If the local system receives a NOTIFICATION message [event
> > 23-24] or receives a TCP Disconnect [event 17] from the
> > underlying transport protocol, the local system:
> >        - sets the appropriate MIB information for FSM error,
> >        - resets the connect retry timer (sets the timer to
> >          zero),
> >       - releases all BGP resources,
> >        - drops the TCP connection,
> >        - increments the ConnectRetryCnt by 1,
> >        [Action Y in the FSM table],
> >        - and sets the state to idle.
> >
> > Any start event [Event1, 3-6] is ignored in the OpenConfirm
> > state.
> >
> > In response to a manual stop event[Event 2] initiated by
> > the operator, the local system:
> >       - set Administrative down in MIB Reason code,
> >        - sends the NOTIFICATION message with Cease,
> >       - if any BGP routes, dete the routes
> >        - releases all BGP resources,
> >       - drop the transport connection,
> >        - sets the ConnectRetryCnt to zero
> >        - sets the connect retry timer to zero
> >        [Action S in the FSM table]
> >        - transitions to Idle state.
> >
> > In response to the Automatic stop event initiated by the
> > system[event 7], the local system:
> >        - sets the MIB entry for this peer to administratively
> >          down,
> >        - sends the NOTIFICATION message with Cease,
> >       - connect retry timer reset (set to zero)
> >       - If any BGP routes exist, delete the routes,
> >       - release all BGP resources,
> >        - drops the transport connection,
> >        - increments the ConnectRetryCnt by 1,
> >        [Action C in the FSM table], and
> >        - transitions to the Idle State.
> >
> > If the Hold Timer expires before a KEEPALIVE message is
> > received [event10], the local system:
> >        - set the MIB reason to Hold time expired,
> >        - send the NOTIFICATION message with the error code
> >          set to Hold Time Expired,
> >        - resets the connect retry timer (sets the timer to to
> >          zero),
> >       - releases all BGP resources,
> >        - drops the transport connection,
> >        - increments the ConnectRetryCnt by 1
> >          [Action K in the FSM table],
> >        - and sets the state to Idle.
> >
> >
> > If the local system receives a KEEPALIVE timer expires
> > event [Event 11], the system:
> >        - sends a KEEPALIVE message,
> >        - restarts the Keepalive timer
> >        [Action Q the in FSM table],and
> >        - remains in Open Confirmed state.
> >
> > In the event of TCP establishment [Event 13], or TCP
> > connection succeeding [Event 15 or Event 16] while in Open
> > Confirm, the local system needs to track the 2nd
> > connection.
> >
> > If a TCP connection is attempted to an invalid port [Event
> > 14], the local system will ignore the second connection
> > attempt.
> >
> > If an OPEN message is received, all fields are check for
> > correctness.  If the BGP message header checking [Event20]
> > or OPEN message check detects an error (see Section
> > 6.2)[Event21], [the local system:
> >        - sends a NOTIFICATION message with appropriate error
> >          code,
> >        - resets the connect retry timer (sets the timer to
> >          zero),
> >        - releases all BGP resources,
> >        - drops the TCP connection,
> >        - increments the ConnectRetryCnt by 1,
> >        - runs the BGP peer oscillation damping process [2]
> >       [Actions I, J, in the FSM table depending on the error]
> >        - and goes to the Idle 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:
> >        - sets the Call Collision cease in the MIB reason
> >         code,
> >        - sends a Notification with a Cease
> >        - resets the Connect timer (set to zero),
> >       - releases all BGP resources,
> >       - Drops the TCP connection (send TCP FIN),
> >       - increments the ConnectRetryCnt by 1, and
> >       - performs any BGP peer oscillation damping process [2].
> >       [action
> >
> >
> > If during the processing of another Open message, the BGP
> > implementation determines my means outside the scope of
> > this document that a connection collision has occurred and
> > this connection is to be closed, the local system will
> > issue a call collision dump [Event 22].  When the local
> > system receives a call collision dump event [Event 22], the
> > local system:
> >        - Sets the MIB FSM variable to indicate collision
> >          detected and dump connection.
> >        - send a NOTIFICATION with a CEASE
> >        - deletes all routes associated with connection,
> >        - resets the connect retry timer,
> >        - releases all BGP resources
> >        - drops all TCP connection,
> >        - increments the ConnectRetryCnt by 1,
> >        - and performs any BGP peer oscillation damping,
> >        [Action R in the FSM table],
> >        - enters Idle state.
> >
> > In response to any other event [Events 8-9, 12, 19, 26-27],
> > the local system:
> >        - sends a NOTIFICATION with a code of Finite State
> >          Machine Error,
> >        - resets the connect retry timer (sets to zero)
> >        - drops the TCP connection,
> >        - releases all BGP resources,
> >        - increments the ConnectRetryCnt by 1,
> >        - performs any BGP peer oscillation damping,
> >        [Action E in the FSM table], and
> >        - transitions to Idle state.
> >
> >
> >Established State:
> >
> > In the Established state BGP can exchange UPDATE,
> > NOTFICATION, and KEEPALIVE messages with its peer.
> >
> > If the local system receives an UPDATE message [Event26],
> > the local system will:
> >       - process the update packet
> >       - restarts its Hold timer, if the negotiated Hold Time
> >          value is non-zero.
> >       [Action W in the FSM table], and
> >       - remain in the Established state.
> >
> >
> > If the local system receives a NOTIFICATION message
> > [Event23 or Event24] or a disconnect [Event17] from the
> > underlying transport protocol, it:
> >       - sets the appropriate error code in MIB reason code,
> >       - if any BGP routes exist, delete all BGP routes,
> >        - resets the connect retry timer (sets to zero),
> >        - releases all the BGP resources,
> >       - drops the TCP connection,
> >       - increments the ConnectRetryCnt by 1, and
> >       [Action T in the FSM table]
> >       - Goes to the Idle state.
> >
> >
> > If the local system receives a Keepalive message
> > [Event 25], the local system will:
> >        - restarts its Hold Timer, if the negotiated Hold Time
> >          value is non-zero.
> >       [Action P in the FSM table], and
> >       - remain in the Established state.
> >
> > If the local system receives an UPDATE message, and the
> > Update message error handling procedure (see Section 6.3)
> > detects an error [Event27], the local system:
> >       - sends a NOTIFICATION message with Update error,
> >       - resets the connect retry timer (sets to zero),
> >       - drops the TCP connection,
> >       - releases all BGP resources,
> >       - increments the ConnectRetryCnt by 1
> >       - performs any BGP peer oscillation damping
> >      [Action U in FSM table],
> >       - and goes to Idle state.
> >
> >
> > Any start event (Event 1, 3-6) is ignored in the
> > Established state.
> >
> > In response to a manual stop event (initiated by an
> > operator)[Event2]:
> >        - sets the Administrative stop in MIB reason code,
> >       - sends the NOTIFICATION message with Cease,
> >        - if BGP routes exist, delete the BGP routes,
> >        - release BGP resources,
> >       - drop TCP connection,
> >        - set ConnectRetryCnt to zero (0),
> >        - reset connect retry timer to zero (0), and
> >        [Action S in FSM table]
> >        - transition to the Idle.
> >
> > In response to an automatic stop event initiated by the
> > system (automatic) [Event7], the local system:
> >     - sets Administrative Stop in MIB Reason code,
> >     - sends a NOTIFICATION with Cease,
> >     - resets the connect retry timer (sets to zero)
> >     - deletes all routes associated with bgp peer session,
> >     - releases all BGP resources,
> >     - drops the transport connection,
> >     - increments the ConnectRetryCnt by 1,
> >     - performs any BGP peer oscillation damping, and
> >     [Action C in FSM table]
> >     - transitions to the idle state.
> >
> > An example automatic stop event is exceeding the number of
> > prefixes for a given peer and the local system
> > automatically disconnecting the peer.
> >
> >
> > If the Hold timer expires [Event10], the local system:
> >      - sends a NOTIFICATION message with Error Code Hold
> >        Timer Expired,
> >      - resets the connect retry timer (sets to zero),
> >      - releases all BGP resources,
> >      - drops the TCP connection,
> >      - increments the ConnectRetryCnt by 1,
> >      -        performs any BGP peer oscillation damping,
> >      [Action M in FSM table]
> >      - and goes to Idle state.
> >
> > If the KeepAlive timer expires [Event11], the local system
> > sends a KEEPALIVE message, it restarts its KeepAlive timer,
> > unless the negotiated Hold Time value is zero [Action Q].
> >
> > Each time time the local system sends a KEEPALIVE or UPDATE
> > message, it restarts its KeepAlive timer, unless the
> > negotiated Hold Time value is zero.
> >
> >
> > A transport connection indication [Event 13] received
> > for a valid port will cause the 2nd connection to be
> > tracked.  A transport connection indications for
> > invalid port [Event 14], will be ignored.
> >
> > In response to a Transport connection succeeds [Event 15
> > 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
> > checked to see if it collides (section 6.8) with any other
> > session. If the BGP implementation determines that this
> > connection needs to be terminated, it will process an Call
> > Collision dump event[Event 22].  If this session needs to be
> > terminated, the connection will be terminated by:
> >
> >     - send a NOTIFICATION with a CEASE
> >     - deletes all routes associated with connection,
> >     - resets the connect retry timer,
> >     - if any BGP routes, delete the routes,
> >     - release all BGP resources,
> >     - drops the transport connection,
> >     - increments ConnectRetryCnt by 1,
> >     - and performs any BGP peer oscillation damping,
> >    [Action R in the FSM table],
> >     - and enters the Idle state
> >
> >
> > In response to any other event [Events 8-9,12, 19-21] the
> > local system:
> >     - sends a NOTIFICATION message with Error Code Finite
> >       State Machine Error,
> >     - deletes all routes associated with BGP peer session,
> >     - resets the connect retry timer (sets to zero)
> >     - releases all BGP resources,
> >     - drops the TCP connection,
> >     - increments the ConnectRetryCnt by 1,
> >     - performs any BGP peer oscillation damping, and
> >     [Action E in FSM table],
> >     - transitions to Idle.
> >
>
>
>
>--
>Greg Hankins <[e-mail]> | Riverstone Networks, Inc.
>Systems Engineering                       | 5200 Great America Parkway
>http://www.riverstonenet.com/             | Santa Clara, CA 95054
>[phone]                           | [phone]

--=====================_20252701==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="FSM-words-05b.txt"



Note: (this is version 5 of the changes to
       the text.) 

8.0	BGP Finite State Machine


This section specifies the BGP operation in terms of a 
Finite State Machine (FSM).  The section falls into 2 
parts:

    1)	Description of Events for the State machine (section 
        8.1
    2)	Description of the FSM (section 8.2)

Session Attributes required for each connection are; 

   1)	state
   2)	Connect Retry timer
   3)	Hold timer
   4)	Hold time
   5)	Keepalive timer

8.1 Events for the BGP FSM

8.1.1   Administrative Events (events 1-5)

Please note that only Event 1 (manual start) and Event 2 
(manual stop) are mandatory administrative events. All 
other administrative events are optional.

 Event1: Manual start 

	   Definition: Administrator manually starts peer
                       connection
	   Status: 	Mandatory

 Event2: Manual stop

	   Definition: Local system administrator manually 
                       stops the peer connection.

	   Status: 	mandatory
	   

 Event3: Automatic Start

 	   Definition: Local system automatically starts the 
                       BGP peer session

	   Status:     Optional depending on local system

 Event4: Manual start with passive Transport Establishment

	   Definition: Administrator manually start the peer
                       Connection, but has the passive flag 
                       enabled.  The passive flag indicates 
                       that the peer will listen prior to 
                       establishing the connection.

	   Status:     Optional depending on local system
		

 Event5: Automatic start with passive Transport establishment

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

	  Status:      Optional depending on local system use
		       of a passive connection.

 Event6: Automatic start with bgp_stop_flap option set

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

           Status: 	Optional, used only if the bgp peer has 
	  	        Enabled a method of damping persistent
		        BGP peer flapping.


 Event7: Auto stop

	   Definition: Local system automatically stops the
                       BGP peer session.  
	
	   Status:     Optional depending on local system


8.1.2 Timer Events (events 8-11)

 Event8:  idle Hold timer expires 

           Definition: Idle Hold timer expires.  The Idle 
                       Hold Timer is only used when persistent  
                       BGP oscillation damping functions are 
                       enabled.  

           Status: 	Optional.  Used when persistent
			BGP peer oscillation damping functions
			are enabled. 



 Event9: connect retry timer expires

           Definition: An event triggered by the expiration of 
                       the ConnectRetry timer.
  
	   Status:     Mandatory

 Event10: hold time expires

	   Definition: An event generated when the HoldTimer 
                       expires.

	   Status:     Mandatory

 Event11: keepalive timer expires

	   Definition: A periodic event generated due to the 
                       expiration of the KeepAlive Timer. 
 
	   Status:     Mandatory

 Event12: DelayBGP Open timer expires [changed]
	
	   Definition: A timer that delays sending of the BGP
	               Open message for n seconds after the
                       Transport connection has been completed. 

	   status:     Optional

8.2.3) Tranport Message based (13-16) 

 Event13: Transport Connection Indication & valid remote peer[changed]

	   Definition: Event indicating that transport
                       Request 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.


	   Status:     Mandatory

 Event14: RCV Transport Connection Indication and Invalid Source or 
          Destination [changed]

           Definition: Transport request received 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.

	    Status: 	 Mandatory
	
 Event15: Transport Connection request sent received an ACK.

           Definition: Local system's request to establish a transport
		       Connection to the remote side received
		       an ACK.


	    Status:    Mandatory

 Event16: Transport Connection Confirmed [changed]

	   Definition: The local system has received a Confirmation that
                       the transport connection has been established by
		       the remote site. 

	  Status:      Mandatory

 Event17: Transport connection fails [changed]

           Definition: This BGP peer receives a transport
		       connection failure notice.  This
		       connection notice could be caused by a
		       Transport disconnect message or a
		       Timeout in the transport session.

                       If this connection is using TCP, 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


8.1.4 BGP Messages (18-27)

 Event18: BGPOpen

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

	   Status: 	Mandatory

 Event19: BGPOpen with BGP Delay Open Timer running [changed]

           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. 

	    Status:    Optional

 Event20: BGPHeaderErr

	   Definition: BGP message header is not valid.  

	   Status:     Mandatory

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


 Event22: Open collision discard

           Definition: An event generated administratively 
                       when a connection Collision has been 
                       detected while processing an incoming  
                       Open message. This connection has been 
                       selected to disconnected.  See section 
                       6.8 for more information on collision
	               detection.  

                       Event 22 is an administrative could 
                       occur if FSM is implemented as two 
                       linked state machines.  

	  Status:      Optional

 Event23: NotifMsgVerErr

	    Definition: An event is generated when a 
                        NOTIFICIATION message with "version   
                        error" is received.

	    Status:     Mandatory

 Event24: NotifMsg

	    Definition: An event is generated when a 
                        NOTIFICATION messages is received and
                        the error code is anything but 	 
			"version error".

	     Status:	Mandatory
		        
 Event25: KeepAliveMsg

	    Definition: An event is generated when a KEEPALIVE
			Message is received.

		Status: Mandatory

 Event26: UpdateMsg

	    Definition: An event is generated when a valid 
			Update Message is received.

		Status: Mandatory

 Event27: UpdateMsgErr

	    Definition: An event is generated when an invalid
			Update message is received.

		Status:	Mandatory

 
8.2) Description of FSM


Idle state

   Initially BGP is in the Idle state.   

   In this state BGP refuses all incoming BGP connections.  No 
   resources are allocated to the peer.    In response to a 
   manual start event(Event1) or an automatic start 
   event(Event3), the local system 
      -	initializes all BGP resources, 
      -	sets the Connect retry counter to zero
      -	starts the ConnectRetry timer with initial value, 
      -	initiates a transport connection to the other BGP 
        peer, 
      -	listens for a connection that may be initiated by 
        the remote BGP peer, and
        [Action A in the FSM table]
      -	changes its state to connect.

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

  In response to a manual start event with the passive Transport
  flag (Event 4) or automatic start with the passive Transport flag 
  (Event 5), the local system:
      -	initializes all BGP resources,
      -	sets the connect retry count to zero,
      -	start the Connect Retry timer with initial value, 
      -	listens for a connection that may be initiated by 
        the remote peer
        [Action B in the FSM table] 
      -	changes its state to Active.

  The exact value of the ConnectRetry timer is a local 
  matter, but it should be sufficiently large to allow TCP 
  initialization.   

  If a persistent BGP peer oscillation damping function is 
  enabled, two additional events may occur within Idle state:  
      -	Automatic start with bgp_stop_flap set [Event6],
      -	Idle Hold Timer expired [Event 8].

  The method of preventing persistent BGP peer oscillation is 
  outside the scope of this document.

  Any other events [Events 9-27] received in the Idle state, 
  are noted by the MIB processing as FSM Errors [action V]
  and the local peer stays in the Idle State.


Connect State:

  In this state, BGP is waiting for the transport protocol 
  connection to be completed.

  If the transport 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: 
     -	clears the ConnectRetry timer, 
     -	set the BGP Open Delay timer to the initial 
        value.
        [Action ZZ in FSM table]

  If the Delay Open flag is not set, the local system: 
     - clears the ConnectRetry timer, 
     - completes BGP initialization
     - send an Open message to its peer,
     - sets Hold timer to a large value,
     - Change the state to Open Sent 
   [Action H in the FSM table]

  A hold timer value of 4 minutes is suggested.

  If the Open Delay timer expires [Event 12] in the connect 
  state,
     - send an Open message to its peer,
     - set the Hold timer to a large value,
	[Action H in the FSM Table], and
     - change the state to Open Sent. 

  If the BGP port receives a Transport connection indication 
  [Event 13], the Transport connection is processed (actions AA or
  AB in the FSM table) and the connection remains
  in the connected state. 

  If the transport connection receives an Transport indication
  that is invalid or unconfigured. [Event 14]:
     - the transport connection is rejected.
	[Action L in the FSM table]

  If the transport connection fails (timeout or transport
  disconnect) [Event17], the local system:
      - restarts the ConnectRetry timer, 
      - continues to listen for a connection that may be 
        initiated by the remote BGP peer, and
     [Action G in the FSM table]
      - changes its state to Active. 


  If an Open is received with the BGP Delay Open timer is 
  running [Event 19], the local system:
	- clears the connect retry timer (cleared to zero),
	- completes the BGP initialization, 
	- Stops and clears the BGP Open Delay timer
	- Sends an Open message

	[Action H in the FSM table], and
	- changes its state to Open Confirm.


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

 A manual stop event[Event2], the local system:
       - drops the transport connection, 
       - releases all BGP resources,
       - sets connect retry count to zero
       - resets the connect retry timer (sets to zero)
      [Action Z in the FSM table]
       - goes to Idle state.

  In response to the ConnectRetry timer expired event(Event 
  9), the local system: 
      - Sets the MIB FSM error information with ConnectRetry 
        expired, 
      - drops the transport connection 
      - restarts the ConnectRetry timer
      - initiates a transport connection to the other BGP 
        peer, 
      - continues to listen for a connection that may be 
        initiated by the remote BGP peer, and
      [Action O in the FSM table]
      - stays in Connect state.

 In response to any other events [Events 7-8, 10-11, 18, 20-
 27] the local system:
     - resets the connect retry timer (sets to zero),
     - drops the Transport connection,
     - release all BGP resources, 
     - increments the ConnectRetryCnt by 1,
     - [optionally] performs bgp peer oscillation damping, and
     [Action D in the FSM table],
     - goes to Idle state.


Active State:

 In this state BGP is trying to acquire a peer by listening 
 for and accepting a transport protocol connection.  

 A transport connection succeeds [Event 15 or Event 16], the 
 local system: process the transport connection flags
	- If the BGP delay open flag is set:
          o clears the ConnectRetry timer, 
          o completes the BGP initialization,
          o sets the BGP delay Open timer
         [Action ZZ]

        - If the BGP delay open flag is not set:
          o clears the ConnectRetry timer,
          o completes the BGP initialization, 
          o sends the Open message to it's peer, 
          o sets its Hold timer to a large value, 
         [Action H in the FSM table]
          and changes its state to OpenSent.  

 A Hold timer value of 4 minutes is suggested.  

 If the local system receives a valid Transport Indication
 [Event 13], the local system processes the Transport flags
  (actions aa or ab in FSM section 2.3.4).  

 If the local system receives a Transport indication
 that is invalid for this connection [Event 14]:
      - the transport connection is rejected
        [Action L in the FSM table]

 If the local system receives a Transport connection
 failed [Event 17] (timeout or receives Transport
 disconnect), the local system will:
	- set Transport disconnect in the MIB reason code,
	- restart ConnectRetry timer (with initial value)
	- release all BGP resources
	- Acknowledge the drop of Transport connection if
          transport disconnect (If TCP, send a FIN ACK),
	- Increment ConnectRetryCnt by 1,
	- perform the BGP peer oscillation damping process [2]
	[Action Y in the FSM table]

 If the local system has the Delay Open timer expired [event 
 12] local system: 
        - clears the Connect Retry timer (set to zero),
	- stops and clears the Delay Open timer (set to zero) 
        - completes the BGP initialization,
        - sends the Open message to it's remote peer,
        - sets it's Hold timer to a large value,
        [Action H in the FSM table]
        - and set the state to Open Confirm.

 A Hold timer value of 4 minutes is also suggested for this 
 state transition.

 If an Open is received with the BGP Delay Open timer is 
 running [Event 19], the local system 
	- clears the connect retry timer (cleared to zero),
	- Stops and clears the BGP Open Delay timer  
	- completes the BGP initialization, 
	- Stops and clears the BGP Open Delay timer
	- Sends an Open message
	- Set the Hold timer to a large value (4 minutes),
	[Action H in the FSM table], and
	- changes its state to Open Confirm.


 In response the ConnectRetry timer expired event[Event9], 
 the local system:
        - restarts the ConnectRetry timer (with initial value),
        - initiates a transport connection to the other BGP 
          peer,
        - Continues to listen for transport connection that may be 
          initiated by remote BGP peer, 
        [Action F in the FSM table]
	- and changes its state to Connect.  


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

 A manual stop event[Event2], the local system:
        - Sets the administrative down in the MIB reason code,
	- Sends a notification with a Cease,
	- If any BGP routes exist, delete the routes
	- release all BGP resources, 
	- drops the Transport connection, 
        - sets connect retry count to zero
        - resets the connect retry timer (sets to zero)
        [Action S in the FSM table]
        - goes to Idle state.

 In response to any other event (Events 7-8, 10-11,18, 20-
 27), the local system:
        - stores the MIB information to indicate appropriate 
          error [FSM for Events 7-8, 10-11, 18, 20-27]
        - reset the connect retry timer (sets to zero),
        - release all BGP resources, 
	- drops the transport connection, 
        - increments the ConnectRetryCnt by one,
        - optionally performs BGP peer oscillation damping, 
  	  [Action D in FSM table],
	- and goes to the idle state


Open Sent:

 In this state BGP waits for an Open Message from its peer.  

 When an OPEN message is received, all fields are checked 
 for correctness.  If there are no errors in the OPEN message 
 [Event 18] the local system:
       - resets the BGP Delay timer to zero,
       - reset BGP Connect Timer to zero, 
       - sends a KEEPALIVE message and
       - sets a KeepAlive timer (via the text below)
       - sets the Hold timer according to the negotiated value 
         (see section 4.2), and 
         [Action N in the FSM table]
       - sets the state to Open Confirm.


 If the negotiated Hold time value is zero, then the Hold 
 Time timer and KeepAlive timers are not started.   If the 
 value of the Autonomous System field is the same as the 
 local Autonomous System number, then the connection is an 
 "internal" connection; otherwise, it is an "external" 
 connection.   (This will impact UPDATE processing as 
 described below.)  


 If the BGP message header checking [Event20] or OPEN message
 check detects an error (see Section 6.2)[Event21], the local system:
       - sends a NOTIFICATION message with appropriate error 
         code, 
       - reset the connect retry timer (sets to zero),
       - if there are any routes associated with the BGP session,
	 delete these routes
       - release all BGP resources,
       - drop the transport session 
       - increments the ConnectRetryCnt by 1, 
       - bgp peer oscillation damping process,  
       [Actions I, J in FSM table, depending on error],
       - and goes to the Idle state.

 Collision detection mechanisms (section 6.8) need to be 
 applied when a valid BGP Open is received [Event 18 or 
 Event 19].  Please refer to section 6.8 for the details of 
 the comparison. An administrative collision detect is when 
 BGP implementation determines my means outside the scope of 
 this document that a connection collision has occurred.   

 If a connection in Open Sent is determined to be the 
 connection that must be closed, an administrative collision 
 detect [Event 22] is signaled to the state machine. If such 
 an administrative collision detect dump [Event 22] is 
 received in Open Sent, the local system:  
       - sets MIB state information to 
         collision detect closure, 
       - send a NOTIFICATION with a CEASE
       - resets the connect retry timer,
       - release all BGP resources,
       - drop the transport connection,
       - increments ConnectRetryCnt by 1,
       - performs any BGP peer oscillation damp process, and
       [Action R in the FSM],
       - enters Idle state.


  If a NOTIFICATION message is received with a version 
  error[Event23], Notification message without version number 
  [Event 24], the local system: 
       - resets the connect retry timer (sets to zero)
       - drops the Transport connection,
       - releases all BGP resources, 
       - increments the ConnectRetryCnt by 1
       - process any BGP peer oscillation damping,
	[Action Y]  
       - and sets the state to Idle.


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

  If a manual stop event [Event 2] is issued in Open sent 
 state, the local system:
	- Sets administrative down reason in MIB reason,
	- sends the Notification with a cease,
	- if BGP routes exists, delete the routes,
	- Release all BGP resources, 
	- Drops the Transport connection, 
	- set ConnectRetryCnt to zero, 
	- resets the Connect Retry timer (set to zero),
	[Action S in the FSM table], and
	- transitions to the Idle state.

  If an automatic stop event [Event 7] is issued in Open sent 
  state, the local system:
	- Sets administrative down reason in MIB reason,
	- sends the Notification with a cease,
	- if any routes are associated with te BGP session,
	  delete the routes, 
	- release all the BGP resources
	- Drops the Transport connection, 
	- increments the ConnectRetryCnt by 1, 
	- BGP peer oscillation process [2]
	[Action C in the FSM table], and
	- transitions to the Idle state.

 If the Hold Timer expires[Event 10], the local system:
       - set Hold timer expired in MIB Error reason code, 
       - send a NOTIFICATION message with error code Hold 
         Timer Expired,
       - reset the connect retry timer (sets to zero),
       - releases all BGP resources,
       - drops the Transport connection, 
       - increments the ConnectRetryCnt by 1
         [Action K in the FSM table], and
	- transitions to the Idle state.


 If a transport indication is received for valid connection 
 [Event 13] or transport Request Acknowledgement [Event 15]
 is received, or a transport connect confirm [Event 16] is
 received a second TCP session may be in progress.  This
 second TCP session is tracked per the Call Collision 
 processing (section 6.8) until an OPEN message is received.

 A TCP connection for an invalid port [Event 14] is ignored. 

 If a Transport Failure [Event17], is received from the 
 underlying transport protocol, the local system:
       - closes the BGP connection, 
       - restarts the Connect Retry timer, 
       - and continues to listen for a connection that may be 
         initiated by the remote BGP peer,
       [Action O in the FSM table]
       - and goes into Active state.


 In response to any other event [Events 8-9, 11-12, 19, 25-27], 
  the local system:
	- sends the NOTIFICATION with the Error Code Finite 
          state machine error,
        - resets the connect retry timer (sets to zero),
	- releases all BGP resources
        - drops the Transport connection, 
        - increments the ConnectRetryCnt by 1, 
        - process any bgp peer oscillation damping[2] 
        [Action E in the FSM table],
        - and sets the state to idle.


Open Confirm State

 In this state BGP waits for a KEEPALIVE or NOTIFICATION 
 message.

 If the local system receives a KEEPALIVE message[Event 25], 
        - restarts the Hold timer, 
          [Action P in the FSM table], and
        - changes its state to Established. 


 If the local system receives a NOTIFICATION message [event 
 23-24] or receives a TCP Disconnect [event 17] from the 
 underlying transport protocol, the local system:  
        - sets the appropriate MIB information for FSM error, 
        - resets the connect retry timer (sets the timer to 
          zero),
	- releases all BGP resources, 
        - drops the TCP connection,
        - increments the ConnectRetryCnt by 1, 
        [Action Y in the FSM table],
        - and sets the state to idle.

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

 In response to a manual stop event[Event 2] initiated by 
 the operator, the local system: 
	- set Administrative down in MIB Reason code,
        - sends the NOTIFICATION message with Cease, 
	- if any BGP routes, dete the routes
        - releases all BGP resources, 
	- drop the transport connection, 
        - sets the ConnectRetryCnt to zero
        - sets the connect retry timer to zero
        [Action S in the FSM table]
        - transitions to Idle state.

 In response to the Automatic stop event initiated by the 
 system[event 7], the local system:
        - sets the MIB entry for this peer to administratively 
          down, 
        - sends the NOTIFICATION message with Cease,
	- connect retry timer reset (set to zero)
	- If any BGP routes exist, delete the routes,
	- release all BGP resources,
        - drops the transport connection,
        - increments the ConnectRetryCnt by 1, 
        [Action C in the FSM table], and
        - transitions to the Idle State.

 If the Hold Timer expires before a KEEPALIVE message is 
 received [event10], the local system:
        - set the MIB reason to Hold time expired, 
        - send the NOTIFICATION message with the error code 
          set to Hold Time Expired, 
        - resets the connect retry timer (sets the timer to to 
          zero),
	- releases all BGP resources, 
        - drops the transport connection, 
        - increments the ConnectRetryCnt by 1 
          [Action K in the FSM table], 
        - and sets the state to Idle.


 If the local system receives a KEEPALIVE timer expires 
 event [Event 11], the system:
        - sends a KEEPALIVE message,
        - restarts the Keepalive timer 
        [Action Q the in FSM table],and 
        - remains in Open Confirmed state.

 In the event of TCP establishment [Event 13], or TCP 
 connection succeeding [Event 15 or Event 16] while in Open 
 Confirm, the local system needs to track the 2nd 
 connection.  

 If a TCP connection is attempted to an invalid port [Event 
 14], the local system will ignore the second connection 
 attempt.  

 If an OPEN message is received, all fields are check for 
 correctness.  If the BGP message header checking [Event20] 
 or OPEN message check detects an error (see Section 
 6.2)[Event21], [the local system:
        - sends a NOTIFICATION message with appropriate error 
          code, 
        - resets the connect retry timer (sets the timer to 
          zero),
        - releases all BGP resources, 
        - drops the TCP connection,
        - increments the ConnectRetryCnt by 1, 
        - runs the BGP peer oscillation damping process [2]  
       [Actions I, J, in the FSM table depending on the error]
        - and goes to the Idle 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:
        - sets the Call Collision cease in the MIB reason 
         code,
        - sends a Notification with a Cease 
        - resets the Connect timer (set to zero),
	- releases all BGP resources,
	- Drops the TCP connection (send TCP FIN),
	- increments the ConnectRetryCnt by 1, and
	- performs any BGP peer oscillation damping process [2].
	[action 


 If during the processing of another Open message, the BGP 
 implementation determines my means outside the scope of 
 this document that a connection collision has occurred and 
 this connection is to be closed, the local system will 
 issue a call collision dump [Event 22].  When the local 
 system receives a call collision dump event [Event 22], the 
 local system:
        - Sets the MIB FSM variable to indicate collision 
          detected and dump connection.
        - send a NOTIFICATION with a CEASE
        - deletes all routes associated with connection,
        - resets the connect retry timer,
        - releases all BGP resources
        - drops all TCP connection,
        - increments the ConnectRetryCnt by 1, 
        - and performs any BGP peer oscillation damping,
        [Action R in the FSM table],
        - enters Idle state.

 In response to any other event [Events 8-9, 12, 19, 26-27], 
 the local system:
        - sends a NOTIFICATION with a code of Finite State 
          Machine Error,
        - resets the connect retry timer (sets to zero)
        - drops the TCP connection,
        - releases all BGP resources, 
        - increments the ConnectRetryCnt by 1, 
        - performs any BGP peer oscillation damping,
        [Action E in the FSM table], and 
        - transitions to Idle state.


Established State:

 In the Established state BGP can exchange UPDATE, 
 NOTFICATION, and KEEPALIVE messages with its peer.

 If the local system receives an UPDATE message [Event26], 
 the local system will:
	- process the update packet
	- restarts its Hold timer, if the negotiated Hold Time 
          value is non-zero.
	[Action W in the FSM table], and
	- remain in the Established state.

 
 If the local system receives a NOTIFICATION message 
 [Event23 or Event24] or a disconnect [Event17] from the 
 underlying transport protocol, it:
	- sets the appropriate error code in MIB reason code,
	- if any BGP routes exist, delete all BGP routes,  
        - resets the connect retry timer (sets to zero), 
        - releases all the BGP resources, 
	- drops the TCP connection,
	- increments the ConnectRetryCnt by 1, and 
       [Action T in the FSM table]   
	- Goes to the Idle state.


 If the local system receives a Keepalive message
 [Event 25], the local system will:
        - restarts its Hold Timer, if the negotiated Hold Time 
          value is non-zero.
       [Action P in the FSM table], and
	- remain in the Established state.

 If the local system receives an UPDATE message, and the 
 Update message error handling procedure (see Section 6.3) 
 detects an error [Event27], the local system:
       - sends a NOTIFICATION message with Update error,
       - resets the connect retry timer (sets to zero),
       - drops the TCP connection,
       - releases all BGP resources, 
       - increments the ConnectRetryCnt by 1 
       - performs any BGP peer oscillation damping
      [Action U in FSM table], 
       - and goes to Idle state.


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

 In response to a manual stop event (initiated by an 
 operator)[Event2]:
        - sets the Administrative stop in MIB reason code, 
	- sends the NOTIFICATION message with Cease, 
        - if BGP routes exist, delete the BGP routes, 
        - release BGP resources,
	- drop TCP connection, 
        - set ConnectRetryCnt to zero (0),
        - reset connect retry timer to zero (0), and
        [Action S in FSM table]
        - transition to the Idle.

 In response to an automatic stop event initiated by the 
 system (automatic) [Event7], the local system:
     - sets Administrative Stop in MIB Reason code, 
     - sends a NOTIFICATION with Cease,
     - resets the connect retry timer (sets to zero)
     - deletes all routes associated with bgp peer session,
     - releases all BGP resources, 
     - drops the transport connection,   
     - increments the ConnectRetryCnt by 1, 
     - performs any BGP peer oscillation damping, and 
     [Action C in FSM table]
     - transitions to the idle state.

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


 If the Hold timer expires [Event10], the local system:
      - sends a NOTIFICATION message with Error Code Hold 
        Timer Expired,
      - resets the connect retry timer (sets to zero),
      - releases all BGP resources, 
      - drops the TCP connection, 
      - increments the ConnectRetryCnt by 1,  
      -	performs any BGP peer oscillation damping,
      [Action M in FSM table] 
      - and goes to Idle state.

 If the KeepAlive timer expires [Event11], the local system 
 sends a KEEPALIVE message, it restarts its KeepAlive timer, 
 unless the negotiated Hold Time value is zero [Action Q].

 Each time time the local system sends a KEEPALIVE or UPDATE 
 message, it restarts its KeepAlive timer, unless the 
 negotiated Hold Time value is zero.


 A transport connection indication [Event 13] received
 for a valid port will cause the 2nd connection to be
 tracked.  A transport connection indications for 
 invalid port [Event 14], will be ignored. 
 
 In response to a Transport connection succeeds [Event 15
 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 
 checked to see if it collides (section 6.8) with any other 
 session. If the BGP implementation determines that this 
 connection needs to be terminated, it will process an Call 
 Collision dump event[Event 22].  If this session needs to be 
 terminated, the connection will be terminated by:

     - send a NOTIFICATION with a CEASE
     - deletes all routes associated with connection,
     - resets the connect retry timer,
     - if any BGP routes, delete the routes,
     - release all BGP resources, 
     - drops the transport connection,
     - increments ConnectRetryCnt by 1,
     - and performs any BGP peer oscillation damping,
    [Action R in the FSM table],
     - and enters the Idle state


 In response to any other event [Events 8-9,12, 19-21] the 
 local system:
     - sends a NOTIFICATION message with Error Code Finite 
       State Machine Error,
     - deletes all routes associated with BGP peer session, 
     - resets the connect retry timer (sets to zero)
     - releases all BGP resources,
     - drops the TCP connection,
     - increments the ConnectRetryCnt by 1, 
     - performs any BGP peer oscillation damping, and
     [Action E in FSM table],
     - transitions to Idle.


--=====================_20252701==_
Content-Type: text/plain; charset="us-ascii"; format=flowed


--=====================_20252701==_--



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA12363 for <[e-mail]>; Thu, 12 Sep 2002 15:56:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A563291242; Thu, 12 Sep 2002 15:55:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6AF2C912D7; Thu, 12 Sep 2002 15:55:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D7C5991242 for <[e-mail]>; Thu, 12 Sep 2002 15:55:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B2E765DE89; Thu, 12 Sep 2002 15:55:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 6543A5DE7B for <[e-mail]>; Thu, 12 Sep 2002 15:55:19 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8CJtIG98047; Thu, 12 Sep 2002 15:55:18 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([65.241.132.110]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g8CJt8G98010; Thu, 12 Sep 2002 15:55:08 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 12 Sep 2002 19:55:07 -0400
To: "Natale, Jonathan" <[e-mail]>
From: Susan Hares <[e-mail]>
Subject: Re: IdleHoldtimer = 2**(ConnectRetryCnt)*60
Cc: [e-mail]
In-Reply-To: <[e-mail] loxnetworks.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_19876430==_"
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

--=====================_19876430==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

Jonathan:

Thank-you for trying to review the right text.  But...
.. what version of the FSM words are you working on?
I have **no*** Idle Hold state in the text.   I have
no Idle Hold state.  I enclosed the words for you to review.


At 11:39 AM 9/12/2002 -0400, Natale, Jonathan wrote:
>In reference to:
>
>"Upon entering the Idle Hold state, if the IdleHoldTimer exceeds
>          the local limit the "Keep Idle" flag is set."
>
>Need to add:
>"The "Keep Idle" local limit MAY be configurable", the suggested default
>value is 0."

No text with this in it.


>And change:
>
>"IdleHoldtimer = 2**(ConnectRetryCnt)*60"
>
>TO
>
>"IdleHoldtimer = (2**(ConnectRetryCnt) - 1)*60"
>
>Since:
>1) Currently, the "Keep Idle" local is not mentioned anywhere else.

This text has been removed to the backoff draft or the state machine
draft.

>2) The current "IdleHoldtimer = 2**(ConnectRetryCnt)*60" formula makes
>automated testing difficult, and may lead to some delay in correcting
>configuration errors if the remote side can not be reset ("Stop event
>initiated by the operator").

Please send more details but reference the backoff-draft not the
main words.   I'm really interested in why you think this?  I may
be assuming something in my test cases.

>3) ***Current implementations accept connections right away*** (this may be
>due to a "bug" in which connections are accepted in Idle (???), but this may
>be another discussion).

See the fact that implementations do accept connections right away
because they have the feature turned off.

>4) Another way of achieving this, instead of defaulting the "Keep Idle"
>local limit to zero (but something else about "Keep Idle" local limit needs
>to be added no matter what), is to set the ConnectRetryCnt to zero when a
>CEASE NOTIFICATION message is received.  But if this is done, the
>IdleHoldtimer = 2**(ConnectRetryCnt)*60 should still be changed to
>IdleHoldtimer = (2**(ConnectRetryCnt) - 1)*60 .

zero - meaning infinite time-out is a semantic that is worth
discussion in terms of the backoff draft.

I'd love to discuss zero versus infinite, but could you look at the
hares-backoff and hares-statemt draft.  We could get on the same
page with these new BGP specs.

Since this is not on the charter, we should ask if we should
take this discussion on-list or off-list.


>5) Also, maybe the ConnectRetryCnt should be set to zero upon becoming
>established???  This eliminates the need for 4) above.

I don't think so, because it doesn't prevent the original problem.

         step 1) get bad prefix
         step 2) dump the connection
         step 3) automatic restart the connection
         step 4) get established
         step 5) cycle back to step 5

Peers going up and down with 150K routes does not help router
performance.


Thanks again for taking the time to review the words.  But,
could you look at the words we are suggesting.

Sue
--=====================_19876430==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="FSM-words-05b.txt"



Note: (this is version 5 of the changes to
       the text.) 

8.0	BGP Finite State Machine


This section specifies the BGP operation in terms of a 
Finite State Machine (FSM).  The section falls into 2 
parts:

    1)	Description of Events for the State machine (section 
        8.1
    2)	Description of the FSM (section 8.2)

Session Attributes required for each connection are; 

   1)	state
   2)	Connect Retry timer
   3)	Hold timer
   4)	Hold time
   5)	Keepalive timer

8.1 Events for the BGP FSM

8.1.1   Administrative Events (events 1-5)

Please note that only Event 1 (manual start) and Event 2 
(manual stop) are mandatory administrative events. All 
other administrative events are optional.

 Event1: Manual start 

	   Definition: Administrator manually starts peer
                       connection
	   Status: 	Mandatory

 Event2: Manual stop

	   Definition: Local system administrator manually 
                       stops the peer connection.

	   Status: 	mandatory
	   

 Event3: Automatic Start

 	   Definition: Local system automatically starts the 
                       BGP peer session

	   Status:     Optional depending on local system

 Event4: Manual start with passive Transport Establishment

	   Definition: Administrator manually start the peer
                       Connection, but has the passive flag 
                       enabled.  The passive flag indicates 
                       that the peer will listen prior to 
                       establishing the connection.

	   Status:     Optional depending on local system
		

 Event5: Automatic start with passive Transport establishment

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

	  Status:      Optional depending on local system use
		       of a passive connection.

 Event6: Automatic start with bgp_stop_flap option set

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

           Status: 	Optional, used only if the bgp peer has 
	  	        Enabled a method of damping persistent
		        BGP peer flapping.


 Event7: Auto stop

	   Definition: Local system automatically stops the
                       BGP peer session.  
	
	   Status:     Optional depending on local system


8.1.2 Timer Events (events 8-11)

 Event8:  idle Hold timer expires 

           Definition: Idle Hold timer expires.  The Idle 
                       Hold Timer is only used when persistent  
                       BGP oscillation damping functions are 
                       enabled.  

           Status: 	Optional.  Used when persistent
			BGP peer oscillation damping functions
			are enabled. 



 Event9: connect retry timer expires

           Definition: An event triggered by the expiration of 
                       the ConnectRetry timer.
  
	   Status:     Mandatory

 Event10: hold time expires

	   Definition: An event generated when the HoldTimer 
                       expires.

	   Status:     Mandatory

 Event11: keepalive timer expires

	   Definition: A periodic event generated due to the 
                       expiration of the KeepAlive Timer. 
 
	   Status:     Mandatory

 Event12: DelayBGP Open timer expires [changed]
	
	   Definition: A timer that delays sending of the BGP
	               Open message for n seconds after the
                       Transport connection has been completed. 

	   status:     Optional

8.2.3) Tranport Message based (13-16) 

 Event13: Transport Connection Indication & valid remote peer[changed]

	   Definition: Event indicating that transport
                       Request 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.


	   Status:     Mandatory

 Event14: RCV Transport Connection Indication and Invalid Source or 
          Destination [changed]

           Definition: Transport request received 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.

	    Status: 	 Mandatory
	
 Event15: Transport Connection request sent received an ACK.

           Definition: Local system's request to establish a transport
		       Connection to the remote side received
		       an ACK.


	    Status:    Mandatory

 Event16: Transport Connection Confirmed [changed]

	   Definition: The local system has received a Confirmation that
                       the transport connection has been established by
		       the remote site. 

	  Status:      Mandatory

 Event17: Transport connection fails [changed]

           Definition: This BGP peer receives a transport
		       connection failure notice.  This
		       connection notice could be caused by a
		       Transport disconnect message or a
		       Timeout in the transport session.

                       If this connection is using TCP, 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


8.1.4 BGP Messages (18-27)

 Event18: BGPOpen

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

	   Status: 	Mandatory

 Event19: BGPOpen with BGP Delay Open Timer running [changed]

           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. 

	    Status:    Optional

 Event20: BGPHeaderErr

	   Definition: BGP message header is not valid.  

	   Status:     Mandatory

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


 Event22: Open collision discard

           Definition: An event generated administratively 
                       when a connection Collision has been 
                       detected while processing an incoming  
                       Open message. This connection has been 
                       selected to disconnected.  See section 
                       6.8 for more information on collision
	               detection.  

                       Event 22 is an administrative could 
                       occur if FSM is implemented as two 
                       linked state machines.  

	  Status:      Optional

 Event23: NotifMsgVerErr

	    Definition: An event is generated when a 
                        NOTIFICIATION message with "version   
                        error" is received.

	    Status:     Mandatory

 Event24: NotifMsg

	    Definition: An event is generated when a 
                        NOTIFICATION messages is received and
                        the error code is anything but 	 
			"version error".

	     Status:	Mandatory
		        
 Event25: KeepAliveMsg

	    Definition: An event is generated when a KEEPALIVE
			Message is received.

		Status: Mandatory

 Event26: UpdateMsg

	    Definition: An event is generated when a valid 
			Update Message is received.

		Status: Mandatory

 Event27: UpdateMsgErr

	    Definition: An event is generated when an invalid
			Update message is received.

		Status:	Mandatory

 
8.2) Description of FSM


Idle state

   Initially BGP is in the Idle state.   

   In this state BGP refuses all incoming BGP connections.  No 
   resources are allocated to the peer.    In response to a 
   manual start event(Event1) or an automatic start 
   event(Event3), the local system 
      -	initializes all BGP resources, 
      -	sets the Connect retry counter to zero
      -	starts the ConnectRetry timer with initial value, 
      -	initiates a transport connection to the other BGP 
        peer, 
      -	listens for a connection that may be initiated by 
        the remote BGP peer, and
        [Action A in the FSM table]
      -	changes its state to connect.

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

  In response to a manual start event with the passive Transport
  flag (Event 4) or automatic start with the passive Transport flag 
  (Event 5), the local system:
      -	initializes all BGP resources,
      -	sets the connect retry count to zero,
      -	start the Connect Retry timer with initial value, 
      -	listens for a connection that may be initiated by 
        the remote peer
        [Action B in the FSM table] 
      -	changes its state to Active.

  The exact value of the ConnectRetry timer is a local 
  matter, but it should be sufficiently large to allow TCP 
  initialization.   

  If a persistent BGP peer oscillation damping function is 
  enabled, two additional events may occur within Idle state:  
      -	Automatic start with bgp_stop_flap set [Event6],
      -	Idle Hold Timer expired [Event 8].

  The method of preventing persistent BGP peer oscillation is 
  outside the scope of this document.

  Any other events [Events 9-27] received in the Idle state, 
  are noted by the MIB processing as FSM Errors [action V]
  and the local peer stays in the Idle State.


Connect State:

  In this state, BGP is waiting for the transport protocol 
  connection to be completed.

  If the transport 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: 
     -	clears the ConnectRetry timer, 
     -	set the BGP Open Delay timer to the initial 
        value.
        [Action ZZ in FSM table]

  If the Delay Open flag is not set, the local system: 
     - clears the ConnectRetry timer, 
     - completes BGP initialization
     - send an Open message to its peer,
     - sets Hold timer to a large value,
     - Change the state to Open Sent 
   [Action H in the FSM table]

  A hold timer value of 4 minutes is suggested.

  If the Open Delay timer expires [Event 12] in the connect 
  state,
     - send an Open message to its peer,
     - set the Hold timer to a large value,
	[Action H in the FSM Table], and
     - change the state to Open Sent. 

  If the BGP port receives a Transport connection indication 
  [Event 13], the Transport connection is processed (actions AA or
  AB in the FSM table) and the connection remains
  in the connected state. 

  If the transport connection receives an Transport indication
  that is invalid or unconfigured. [Event 14]:
     - the transport connection is rejected.
	[Action L in the FSM table]

  If the transport connection fails (timeout or transport
  disconnect) [Event17], the local system:
      - restarts the ConnectRetry timer, 
      - continues to listen for a connection that may be 
        initiated by the remote BGP peer, and
     [Action G in the FSM table]
      - changes its state to Active. 


  If an Open is received with the BGP Delay Open timer is 
  running [Event 19], the local system:
	- clears the connect retry timer (cleared to zero),
	- completes the BGP initialization, 
	- Stops and clears the BGP Open Delay timer
	- Sends an Open message

	[Action H in the FSM table], and
	- changes its state to Open Confirm.


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

 A manual stop event[Event2], the local system:
       - drops the transport connection, 
       - releases all BGP resources,
       - sets connect retry count to zero
       - resets the connect retry timer (sets to zero)
      [Action Z in the FSM table]
       - goes to Idle state.

  In response to the ConnectRetry timer expired event(Event 
  9), the local system: 
      - Sets the MIB FSM error information with ConnectRetry 
        expired, 
      - drops the transport connection 
      - restarts the ConnectRetry timer
      - initiates a transport connection to the other BGP 
        peer, 
      - continues to listen for a connection that may be 
        initiated by the remote BGP peer, and
      [Action O in the FSM table]
      - stays in Connect state.

 In response to any other events [Events 7-8, 10-11, 18, 20-
 27] the local system:
     - resets the connect retry timer (sets to zero),
     - drops the Transport connection,
     - release all BGP resources, 
     - increments the ConnectRetryCnt by 1,
     - [optionally] performs bgp peer oscillation damping, and
     [Action D in the FSM table],
     - goes to Idle state.


Active State:

 In this state BGP is trying to acquire a peer by listening 
 for and accepting a transport protocol connection.  

 A transport connection succeeds [Event 15 or Event 16], the 
 local system: process the transport connection flags
	- If the BGP delay open flag is set:
          o clears the ConnectRetry timer, 
          o completes the BGP initialization,
          o sets the BGP delay Open timer
         [Action ZZ]

        - If the BGP delay open flag is not set:
          o clears the ConnectRetry timer,
          o completes the BGP initialization, 
          o sends the Open message to it's peer, 
          o sets its Hold timer to a large value, 
         [Action H in the FSM table]
          and changes its state to OpenSent.  

 A Hold timer value of 4 minutes is suggested.  

 If the local system receives a valid Transport Indication
 [Event 13], the local system processes the Transport flags
  (actions aa or ab in FSM section 2.3.4).  

 If the local system receives a Transport indication
 that is invalid for this connection [Event 14]:
      - the transport connection is rejected
        [Action L in the FSM table]

 If the local system receives a Transport connection
 failed [Event 17] (timeout or receives Transport
 disconnect), the local system will:
	- set Transport disconnect in the MIB reason code,
	- restart ConnectRetry timer (with initial value)
	- release all BGP resources
	- Acknowledge the drop of Transport connection if
          transport disconnect (If TCP, send a FIN ACK),
	- Increment ConnectRetryCnt by 1,
	- perform the BGP peer oscillation damping process [2]
	[Action Y in the FSM table]

 If the local system has the Delay Open timer expired [event 
 12] local system: 
        - clears the Connect Retry timer (set to zero),
	- stops and clears the Delay Open timer (set to zero) 
        - completes the BGP initialization,
        - sends the Open message to it's remote peer,
        - sets it's Hold timer to a large value,
        [Action H in the FSM table]
        - and set the state to Open Confirm.

 A Hold timer value of 4 minutes is also suggested for this 
 state transition.

 If an Open is received with the BGP Delay Open timer is 
 running [Event 19], the local system 
	- clears the connect retry timer (cleared to zero),
	- Stops and clears the BGP Open Delay timer  
	- completes the BGP initialization, 
	- Stops and clears the BGP Open Delay timer
	- Sends an Open message
	- Set the Hold timer to a large value (4 minutes),
	[Action H in the FSM table], and
	- changes its state to Open Confirm.


 In response the ConnectRetry timer expired event[Event9], 
 the local system:
        - restarts the ConnectRetry timer (with initial value),
        - initiates a transport connection to the other BGP 
          peer,
        - Continues to listen for transport connection that may be 
          initiated by remote BGP peer, 
        [Action F in the FSM table]
	- and changes its state to Connect.  


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

 A manual stop event[Event2], the local system:
        - Sets the administrative down in the MIB reason code,
	- Sends a notification with a Cease,
	- If any BGP routes exist, delete the routes
	- release all BGP resources, 
	- drops the Transport connection, 
        - sets connect retry count to zero
        - resets the connect retry timer (sets to zero)
        [Action S in the FSM table]
        - goes to Idle state.

 In response to any other event (Events 7-8, 10-11,18, 20-
 27), the local system:
        - stores the MIB information to indicate appropriate 
          error [FSM for Events 7-8, 10-11, 18, 20-27]
        - reset the connect retry timer (sets to zero),
        - release all BGP resources, 
	- drops the transport connection, 
        - increments the ConnectRetryCnt by one,
        - optionally performs BGP peer oscillation damping, 
  	  [Action D in FSM table],
	- and goes to the idle state


Open Sent:

 In this state BGP waits for an Open Message from its peer.  

 When an OPEN message is received, all fields are checked 
 for correctness.  If there are no errors in the OPEN message 
 [Event 18] the local system:
       - resets the BGP Delay timer to zero,
       - reset BGP Connect Timer to zero, 
       - sends a KEEPALIVE message and
       - sets a KeepAlive timer (via the text below)
       - sets the Hold timer according to the negotiated value 
         (see section 4.2), and 
         [Action N in the FSM table]
       - sets the state to Open Confirm.


 If the negotiated Hold time value is zero, then the Hold 
 Time timer and KeepAlive timers are not started.   If the 
 value of the Autonomous System field is the same as the 
 local Autonomous System number, then the connection is an 
 "internal" connection; otherwise, it is an "external" 
 connection.   (This will impact UPDATE processing as 
 described below.)  


 If the BGP message header checking [Event20] or OPEN message
 check detects an error (see Section 6.2)[Event21], the local system:
       - sends a NOTIFICATION message with appropriate error 
         code, 
       - reset the connect retry timer (sets to zero),
       - if there are any routes associated with the BGP session,
	 delete these routes
       - release all BGP resources,
       - drop the transport session 
       - increments the ConnectRetryCnt by 1, 
       - bgp peer oscillation damping process,  
       [Actions I, J in FSM table, depending on error],
       - and goes to the Idle state.

 Collision detection mechanisms (section 6.8) need to be 
 applied when a valid BGP Open is received [Event 18 or 
 Event 19].  Please refer to section 6.8 for the details of 
 the comparison. An administrative collision detect is when 
 BGP implementation determines my means outside the scope of 
 this document that a connection collision has occurred.   

 If a connection in Open Sent is determined to be the 
 connection that must be closed, an administrative collision 
 detect [Event 22] is signaled to the state machine. If such 
 an administrative collision detect dump [Event 22] is 
 received in Open Sent, the local system:  
       - sets MIB state information to 
         collision detect closure, 
       - send a NOTIFICATION with a CEASE
       - resets the connect retry timer,
       - release all BGP resources,
       - drop the transport connection,
       - increments ConnectRetryCnt by 1,
       - performs any BGP peer oscillation damp process, and
       [Action R in the FSM],
       - enters Idle state.


  If a NOTIFICATION message is received with a version 
  error[Event23], Notification message without version number 
  [Event 24], the local system: 
       - resets the connect retry timer (sets to zero)
       - drops the Transport connection,
       - releases all BGP resources, 
       - increments the ConnectRetryCnt by 1
       - process any BGP peer oscillation damping,
	[Action Y]  
       - and sets the state to Idle.


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

  If a manual stop event [Event 2] is issued in Open sent 
 state, the local system:
	- Sets administrative down reason in MIB reason,
	- sends the Notification with a cease,
	- if BGP routes exists, delete the routes,
	- Release all BGP resources, 
	- Drops the Transport connection, 
	- set ConnectRetryCnt to zero, 
	- resets the Connect Retry timer (set to zero),
	[Action S in the FSM table], and
	- transitions to the Idle state.

  If an automatic stop event [Event 7] is issued in Open sent 
  state, the local system:
	- Sets administrative down reason in MIB reason,
	- sends the Notification with a cease,
	- if any routes are associated with te BGP session,
	  delete the routes, 
	- release all the BGP resources
	- Drops the Transport connection, 
	- increments the ConnectRetryCnt by 1, 
	- BGP peer oscillation process [2]
	[Action C in the FSM table], and
	- transitions to the Idle state.

 If the Hold Timer expires[Event 10], the local system:
       - set Hold timer expired in MIB Error reason code, 
       - send a NOTIFICATION message with error code Hold 
         Timer Expired,
       - reset the connect retry timer (sets to zero),
       - releases all BGP resources,
       - drops the Transport connection, 
       - increments the ConnectRetryCnt by 1
         [Action K in the FSM table], and
	- transitions to the Idle state.


 If a transport indication is received for valid connection 
 [Event 13] or transport Request Acknowledgement [Event 15]
 is received, or a transport connect confirm [Event 16] is
 received a second TCP session may be in progress.  This
 second TCP session is tracked per the Call Collision 
 processing (section 6.8) until an OPEN message is received.

 A TCP connection for an invalid port [Event 14] is ignored. 

 If a Transport Failure [Event17], is received from the 
 underlying transport protocol, the local system:
       - closes the BGP connection, 
       - restarts the Connect Retry timer, 
       - and continues to listen for a connection that may be 
         initiated by the remote BGP peer,
       [Action O in the FSM table]
       - and goes into Active state.


 In response to any other event [Events 8-9, 11-12, 19, 25-27], 
  the local system:
	- sends the NOTIFICATION with the Error Code Finite 
          state machine error,
        - resets the connect retry timer (sets to zero),
	- releases all BGP resources
        - drops the Transport connection, 
        - increments the ConnectRetryCnt by 1, 
        - process any bgp peer oscillation damping[2] 
        [Action E in the FSM table],
        - and sets the state to idle.


Open Confirm State

 In this state BGP waits for a KEEPALIVE or NOTIFICATION 
 message.

 If the local system receives a KEEPALIVE message[Event 25], 
        - restarts the Hold timer, 
          [Action P in the FSM table], and
        - changes its state to Established. 


 If the local system receives a NOTIFICATION message [event 
 23-24] or receives a TCP Disconnect [event 17] from the 
 underlying transport protocol, the local system:  
        - sets the appropriate MIB information for FSM error, 
        - resets the connect retry timer (sets the timer to 
          zero),
	- releases all BGP resources, 
        - drops the TCP connection,
        - increments the ConnectRetryCnt by 1, 
        [Action Y in the FSM table],
        - and sets the state to idle.

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

 In response to a manual stop event[Event 2] initiated by 
 the operator, the local system: 
	- set Administrative down in MIB Reason code,
        - sends the NOTIFICATION message with Cease, 
	- if any BGP routes, dete the routes
        - releases all BGP resources, 
	- drop the transport connection, 
        - sets the ConnectRetryCnt to zero
        - sets the connect retry timer to zero
        [Action S in the FSM table]
        - transitions to Idle state.

 In response to the Automatic stop event initiated by the 
 system[event 7], the local system:
        - sets the MIB entry for this peer to administratively 
          down, 
        - sends the NOTIFICATION message with Cease,
	- connect retry timer reset (set to zero)
	- If any BGP routes exist, delete the routes,
	- release all BGP resources,
        - drops the transport connection,
        - increments the ConnectRetryCnt by 1, 
        [Action C in the FSM table], and
        - transitions to the Idle State.

 If the Hold Timer expires before a KEEPALIVE message is 
 received [event10], the local system:
        - set the MIB reason to Hold time expired, 
        - send the NOTIFICATION message with the error code 
          set to Hold Time Expired, 
        - resets the connect retry timer (sets the timer to to 
          zero),
	- releases all BGP resources, 
        - drops the transport connection, 
        - increments the ConnectRetryCnt by 1 
          [Action K in the FSM table], 
        - and sets the state to Idle.


 If the local system receives a KEEPALIVE timer expires 
 event [Event 11], the system:
        - sends a KEEPALIVE message,
        - restarts the Keepalive timer 
        [Action Q the in FSM table],and 
        - remains in Open Confirmed state.

 In the event of TCP establishment [Event 13], or TCP 
 connection succeeding [Event 15 or Event 16] while in Open 
 Confirm, the local system needs to track the 2nd 
 connection.  

 If a TCP connection is attempted to an invalid port [Event 
 14], the local system will ignore the second connection 
 attempt.  

 If an OPEN message is received, all fields are check for 
 correctness.  If the BGP message header checking [Event20] 
 or OPEN message check detects an error (see Section 
 6.2)[Event21], [the local system:
        - sends a NOTIFICATION message with appropriate error 
          code, 
        - resets the connect retry timer (sets the timer to 
          zero),
        - releases all BGP resources, 
        - drops the TCP connection,
        - increments the ConnectRetryCnt by 1, 
        - runs the BGP peer oscillation damping process [2]  
       [Actions I, J, in the FSM table depending on the error]
        - and goes to the Idle 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:
        - sets the Call Collision cease in the MIB reason 
         code,
        - sends a Notification with a Cease 
        - resets the Connect timer (set to zero),
	- releases all BGP resources,
	- Drops the TCP connection (send TCP FIN),
	- increments the ConnectRetryCnt by 1, and
	- performs any BGP peer oscillation damping process [2].
	[action 


 If during the processing of another Open message, the BGP 
 implementation determines my means outside the scope of 
 this document that a connection collision has occurred and 
 this connection is to be closed, the local system will 
 issue a call collision dump [Event 22].  When the local 
 system receives a call collision dump event [Event 22], the 
 local system:
        - Sets the MIB FSM variable to indicate collision 
          detected and dump connection.
        - send a NOTIFICATION with a CEASE
        - deletes all routes associated with connection,
        - resets the connect retry timer,
        - releases all BGP resources
        - drops all TCP connection,
        - increments the ConnectRetryCnt by 1, 
        - and performs any BGP peer oscillation damping,
        [Action R in the FSM table],
        - enters Idle state.

 In response to any other event [Events 8-9, 12, 19, 26-27], 
 the local system:
        - sends a NOTIFICATION with a code of Finite State 
          Machine Error,
        - resets the connect retry timer (sets to zero)
        - drops the TCP connection,
        - releases all BGP resources, 
        - increments the ConnectRetryCnt by 1, 
        - performs any BGP peer oscillation damping,
        [Action E in the FSM table], and 
        - transitions to Idle state.


Established State:

 In the Established state BGP can exchange UPDATE, 
 NOTFICATION, and KEEPALIVE messages with its peer.

 If the local system receives an UPDATE message [Event26], 
 the local system will:
	- process the update packet
	- restarts its Hold timer, if the negotiated Hold Time 
          value is non-zero.
	[Action W in the FSM table], and
	- remain in the Established state.

 
 If the local system receives a NOTIFICATION message 
 [Event23 or Event24] or a disconnect [Event17] from the 
 underlying transport protocol, it:
	- sets the appropriate error code in MIB reason code,
	- if any BGP routes exist, delete all BGP routes,  
        - resets the connect retry timer (sets to zero), 
        - releases all the BGP resources, 
	- drops the TCP connection,
	- increments the ConnectRetryCnt by 1, and 
       [Action T in the FSM table]   
	- Goes to the Idle state.


 If the local system receives a Keepalive message
 [Event 25], the local system will:
        - restarts its Hold Timer, if the negotiated Hold Time 
          value is non-zero.
       [Action P in the FSM table], and
	- remain in the Established state.

 If the local system receives an UPDATE message, and the 
 Update message error handling procedure (see Section 6.3) 
 detects an error [Event27], the local system:
       - sends a NOTIFICATION message with Update error,
       - resets the connect retry timer (sets to zero),
       - drops the TCP connection,
       - releases all BGP resources, 
       - increments the ConnectRetryCnt by 1 
       - performs any BGP peer oscillation damping
      [Action U in FSM table], 
       - and goes to Idle state.


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

 In response to a manual stop event (initiated by an 
 operator)[Event2]:
        - sets the Administrative stop in MIB reason code, 
	- sends the NOTIFICATION message with Cease, 
        - if BGP routes exist, delete the BGP routes, 
        - release BGP resources,
	- drop TCP connection, 
        - set ConnectRetryCnt to zero (0),
        - reset connect retry timer to zero (0), and
        [Action S in FSM table]
        - transition to the Idle.

 In response to an automatic stop event initiated by the 
 system (automatic) [Event7], the local system:
     - sets Administrative Stop in MIB Reason code, 
     - sends a NOTIFICATION with Cease,
     - resets the connect retry timer (sets to zero)
     - deletes all routes associated with bgp peer session,
     - releases all BGP resources, 
     - drops the transport connection,   
     - increments the ConnectRetryCnt by 1, 
     - performs any BGP peer oscillation damping, and 
     [Action C in FSM table]
     - transitions to the idle state.

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


 If the Hold timer expires [Event10], the local system:
      - sends a NOTIFICATION message with Error Code Hold 
        Timer Expired,
      - resets the connect retry timer (sets to zero),
      - releases all BGP resources, 
      - drops the TCP connection, 
      - increments the ConnectRetryCnt by 1,  
      -	performs any BGP peer oscillation damping,
      [Action M in FSM table] 
      - and goes to Idle state.

 If the KeepAlive timer expires [Event11], the local system 
 sends a KEEPALIVE message, it restarts its KeepAlive timer, 
 unless the negotiated Hold Time value is zero [Action Q].

 Each time time the local system sends a KEEPALIVE or UPDATE 
 message, it restarts its KeepAlive timer, unless the 
 negotiated Hold Time value is zero.


 A transport connection indication [Event 13] received
 for a valid port will cause the 2nd connection to be
 tracked.  A transport connection indications for 
 invalid port [Event 14], will be ignored. 
 
 In response to a Transport connection succeeds [Event 15
 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 
 checked to see if it collides (section 6.8) with any other 
 session. If the BGP implementation determines that this 
 connection needs to be terminated, it will process an Call 
 Collision dump event[Event 22].  If this session needs to be 
 terminated, the connection will be terminated by:

     - send a NOTIFICATION with a CEASE
     - deletes all routes associated with connection,
     - resets the connect retry timer,
     - if any BGP routes, delete the routes,
     - release all BGP resources, 
     - drops the transport connection,
     - increments ConnectRetryCnt by 1,
     - and performs any BGP peer oscillation damping,
    [Action R in the FSM table],
     - and enters the Idle state


 In response to any other event [Events 8-9,12, 19-21] the 
 local system:
     - sends a NOTIFICATION message with Error Code Finite 
       State Machine Error,
     - deletes all routes associated with BGP peer session, 
     - resets the connect retry timer (sets to zero)
     - releases all BGP resources,
     - drops the TCP connection,
     - increments the ConnectRetryCnt by 1, 
     - performs any BGP peer oscillation damping, and
     [Action E in FSM table],
     - transitions to Idle.


--=====================_19876430==_
Content-Type: text/plain; charset="us-ascii"; format=flowed


--=====================_19876430==_--



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA11108 for <[e-mail]>; Thu, 12 Sep 2002 15:14:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 88372912D4; Thu, 12 Sep 2002 15:14:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 578E8912D5; Thu, 12 Sep 2002 15:14:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D4B05912D4 for <[e-mail]>; Thu, 12 Sep 2002 15:14:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BE3AB5DE73; Thu, 12 Sep 2002 15:14:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 7071F5DDE1 for <[e-mail]>; Thu, 12 Sep 2002 15:14:32 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1C3L3>; Thu, 12 Sep 2002 15:14:32 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'David Barak'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
Date: Thu, 12 Sep 2002 15:14:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

References


   [1] Mills, D., "Exterior Gateway Protocol Formal Specification",
   RFC904, April 1984.


--this was a previous suggestion by another guy, so I threw it in.

-----Original Message-----
From: David Barak [mailto:[e-mail]] 
Sent: Thursday, September 12, 2002 2:26 PM
To: Natale, Jonathan
Cc: 'Yakov Rekhter'; [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 

I support this change.  However, to what does footnote [1] refer?

David Barak
WorldCom
Voice: [phone]
Fax: [phone]

"Quis custodes ipsos custodiet?" - Juvenal

On Thu, 12 Sep 2002, Natale, Jonathan wrote:

> Change:
>             "ORIGIN is a well-known mandatory attribute that defines the
>             origin of the path information.  The data octet can assume
>             the following values:
> 
>                   Value      Meaning
> 
>                   0         IGP - Network Layer Reachability Information
>                                is interior to the originating AS
> 
>                   1         EGP - Network Layer Reachability Information
>                                learned via the EGP protocol
> 
>                   2         INCOMPLETE - Network Layer Reachability
>                                Information learned by some other means"
> to:
>             "ORIGIN is a well-known mandatory attribute that defines the
>             origin of the path information.  The data octet can assume
>             the following values:
> 
>                   Value      Meaning
> 
>                   0         IGP - NLRI was explicitly introduced into bgp
> 
>                   1         EGP - this value was administratively
>                                configured to affect policy decisions or
>                                NLRI was learned via the EGP protocol [1]
> 
>                   2         INCOMPLETE - NLRI was implicitly introduced
>                                       into bgp"
> 
> since:
> 1) The network command sets the origin to IGP and I remember seeing
> somewhere that only static routes should be set to IGP.
> 2) The primary use of EGP value is policy
> 3) EGP seems to still exist, anyway even if it does not it is
> not worth re-writing the world.
> 
> Also, change:
> "5.1.1 ORIGIN
> 
> 
>    ORIGIN is a well-known mandatory attribute.  The ORIGIN attribute
>    shall be generated by the autonomous system that originates the
>    associated routing information. It shall be included in the UPDATE
>    messages of all BGP speakers that choose to propagate this
>    information to other BGP speakers."
> 
> to:
> "5.1.1 ORIGIN
> 
>    The value of the ORIGIN attribute shall be set by the speaker
>    that originates the associated NLRI.  Its value shall not be
>    changed by any other speaker unless the other speaker is
>    administratively configured to do so to affect policy
>    decisions."
> 
> since:
> 1) It is already defined as well-known mandatory attribute.
> 2) It may be set differently within the same AS (not saying this is good).
> 3) It is commonly used for policy, but by default does not get changed.
> 4) Speakers have no choice, it is mandatory.
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Thursday, September 12, 2002 1:16 PM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> 
> Jonathan,
> 
> > I think a reference to the fact that it is mainly used for route
selection
> > would suffice.
> 
> please propose the text.
> 
> Yakov.
> 
> > 
> > -----Original Message-----
> > From: Jeffrey Haas [mailto:[e-mail]] 
> > Sent: Thursday, September 12, 2002 10:48 AM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> > 
> > On Wed, Sep 11, 2002 at 06:17:27PM -0400, Curtis Villamizar wrote:
> > > We might want to say the value EGP in the ORIGIN field (which does
> > > mean the EGP protocol, not any EGP type protocol) is depricated since
> > > the EGP protocol has been moved to historic but retain the value to
> > > document what it used to mean.
> > 
> > I would ask us to consider carefully before deprecating it.
> > While no longer used (from what I've seen or heard) as the origin
> > of the route being from the EGP protocol, people *are* using it in
> > their route-maps to bias route selection.
> > 
> > -- 
> > 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 OAA09191 for <[e-mail]>; Thu, 12 Sep 2002 14:19:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E20EF91242; Thu, 12 Sep 2002 14:18:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 833BE9127C; Thu, 12 Sep 2002 14:17:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 57FE591242 for <[e-mail]>; Thu, 12 Sep 2002 14:17:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2B3D05DDE1; Thu, 12 Sep 2002 14:17:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 51CBA5DE70 for <[e-mail]>; Thu, 12 Sep 2002 14:17:13 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1C3CT>; Thu, 12 Sep 2002 14:17:12 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
Date: Thu, 12 Sep 2002 14:17:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Change:
            "ORIGIN is a well-known mandatory attribute that defines the
            origin of the path information.  The data octet can assume
            the following values:

                  Value      Meaning

                  0         IGP - Network Layer Reachability Information
                               is interior to the originating AS

                  1         EGP - Network Layer Reachability Information
                               learned via the EGP protocol

                  2         INCOMPLETE - Network Layer Reachability
                               Information learned by some other means"
to:
            "ORIGIN is a well-known mandatory attribute that defines the
            origin of the path information.  The data octet can assume
            the following values:

                  Value      Meaning

                  0         IGP - NLRI was explicitly introduced into bgp

                  1         EGP - this value was administratively
                               configured to affect policy decisions or
                               NLRI was learned via the EGP protocol [1]

                  2         INCOMPLETE - NLRI was implicitly introduced
                                      into bgp"

since:
1) The network command sets the origin to IGP and I remember seeing
somewhere that only static routes should be set to IGP.
2) The primary use of EGP value is policy
3) EGP seems to still exist, anyway even if it does not it is
not worth re-writing the world.

Also, change:
"5.1.1 ORIGIN


   ORIGIN is a well-known mandatory attribute.  The ORIGIN attribute
   shall be generated by the autonomous system that originates the
   associated routing information. It shall be included in the UPDATE
   messages of all BGP speakers that choose to propagate this
   information to other BGP speakers."

to:
"5.1.1 ORIGIN

   The value of the ORIGIN attribute shall be set by the speaker
   that originates the associated NLRI.  Its value shall not be
   changed by any other speaker unless the other speaker is
   administratively configured to do so to affect policy
   decisions."

since:
1) It is already defined as well-known mandatory attribute.
2) It may be set differently within the same AS (not saying this is good).
3) It is commonly used for policy, but by default does not get changed.
4) Speakers have no choice, it is mandatory.

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Thursday, September 12, 2002 1:16 PM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 

Jonathan,

> I think a reference to the fact that it is mainly used for route selection
> would suffice.

please propose the text.

Yakov.

> 
> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]] 
> Sent: Thursday, September 12, 2002 10:48 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> 
> On Wed, Sep 11, 2002 at 06:17:27PM -0400, Curtis Villamizar wrote:
> > We might want to say the value EGP in the ORIGIN field (which does
> > mean the EGP protocol, not any EGP type protocol) is depricated since
> > the EGP protocol has been moved to historic but retain the value to
> > document what it used to mean.
> 
> I would ask us to consider carefully before deprecating it.
> While no longer used (from what I've seen or heard) as the origin
> of the route being from the EGP protocol, people *are* using it in
> their route-maps to bias route selection.
> 
> -- 
> 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 OAA08865 for <[e-mail]>; Thu, 12 Sep 2002 14:09:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5AD9691237; Thu, 12 Sep 2002 14:09:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C40391242; Thu, 12 Sep 2002 14:09:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7406291237 for <[e-mail]>; Thu, 12 Sep 2002 14:09:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5BCDF5DE73; Thu, 12 Sep 2002 14:09:14 -0400 (EDT)
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 B26D25DE43 for <[e-mail]>; Thu, 12 Sep 2002 14:09:13 -0400 (EDT)
Received: from tom3 (userbp67.uk.uudial.com [62.188.146.62]) by colossus.systems.pipex.net (Postfix) with SMTP id 0214A16000595; Thu, 12 Sep 2002 19:09:09 +0100 (BST)
Message-ID: <00d901c25a87$15a64c20$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: <[e-mail]>, "BGP mailing list" <[e-mail]>
Subject: Re: problem in collision strategy?
Date: Thu, 12 Sep 2002 19:06:09 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D4_01C25A8F.74237860"
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

This is a multi-part message in MIME format.

------=_NextPart_000_00D4_01C25A8F.74237860
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Interesting, fascinating even.
=20
The two ends should implement the same Connection collision detection =
and arrive at the same conclusion.  The way I read it, both should =
retain the (TCP) connection initiated by the BGP speaker with the higher =
value of BGP Identifier; assuming that that is speaker 2, then=20
This triggers the collision detection in speaker 2. As he still=20
believes that connection 1 is established, he decides to close the =
connection 2=20

is in error; speaker 2 should close the first connection just as speaker =
one has done.
=20
Tom Petch, Network Consultant
[e-mail]

    -----Original Message-----
    From: [e-mail] =
<[e-mail]>
    To: BGP mailing list <[e-mail]>
    Date: 12 September 2002 15:38
    Subject: problem in collision strategy?
   =20
    <snip>
    (in the scenario below time progresses downwards)=20
     =20

    +---------------+                  +---------------+=20
    ! BGP speaker A !                  ! BGP speaker B !=20
    ! 10.10.10.10   !------------------+ 10.10.11.11   !=20
    !               !                  !               !=20
    +---------------+                  +---------------+=20
             !          Setup TCP connection 1!=20
             =
!=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D>!=20
             !                                !=20

    BGP speaker 1 initiates a TCP connection towards speaker2=20
    This action is successfull.=20

             !   OPEN for connection 1        !=20
             =
!=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D>!=20

    Speaker 1 being informed that the TCP is up, sends an OPEN=20
    message for the connection he initiated. The OPEN message=20
    is NOT yet treated by speaker 2. (probably speaker 2 is not=20
    yet aware of the connection because he did not check the TCP=20
    events ).=20

    The states in BGP are:=20
     Connection 1: Open Sent           Connection 1: idle?=20

            !   Setup TCP connection 2        !=20
            =
!<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D!=20
            !                                 !=20

    At this stage, speaker 2 also sets up a TCP connection to speaker A=20
    (this happens before the BGP application of speaker 2 is=20
    aware of the connection of speaker 1).=20
     =20

            !       OPEN for connection 2     !=20
            =
!=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D>!=20

    Now BGP speaker 1, being informed of a new connection immediatelly=20
    sends an OPEN message. On Speaker 2 we have either a slow TCP, a =
slow BGP=20
    or a slow link in between (actually it was a test tool, so I do not =
know=20
    really).but in any case it seems that the BGP states now became:=20

    The states in BGP are:=20
     Connection 1: Open Sent           Connection 1: idle?=20
     Connection 1: Open Sent           Connection 2: idle?=20

           !        OPEN for connection 1      !=20
           =
!<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D!=20
           !                                   !=20
           !        KEEPALIVE for connection 1 !=20
           =
!=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>!=20

    BGP speaker 2 'wakes up' and responds to connection 1. BGP speaker 1 =

    who is reacting alert, sends a KEEPALIVE for connection 1=20
    The states in BGP are:=20
     Connection 1: Open confirm        Connection 1: see below=20
     COnnection 1: Open Sent           Connection 2: ?=20

    AT this stage, the collision detection mechanism starts in BGP=20
    speaker 1. Since BGP speaker 2 has the highest id, speaker 1 decides =

    to tear down his original TCP connection (connection 1).=20

           !   KEEPALIVE for connection 1   !=20
           =
!<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D!=20
      Connection 1: gone=20
      COnnection 2 : Open Sent=20

    In the mean time BGP speaker 2, not being aware of the fact that=20
    speaker 1 closed the connection 1 wakes up again, and receives the=20
    keealive from speaker 1 , sends back a keepalive and bring the=20
    connection 1 in establsihed state.(note that on this keepalive will =
be=20
    lost, as the connection is closed.=20
                                       Connection 1: established=20

    Also at this moment, BGP speaker 2 notices that connection 2 is up=20
    and sends an OPEN mesage for connection 2, and trasitions to OPEN =
SENT=20
                                       Connection 2: OPEN sent.=20

          !        OPEN for connection 2        !=20
          =
!<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D!=20

    BGP speaker 2 then treats the OPEN mesage from speaker 1 (which =
arrived=20
    quite some time ago, but was not treated until now).=20
    for connection 2.=20

    This triggers the collision detection in speaker 2. As he still=20
    believes that connection 1 is established, he decides to close the =
connection 2=20

    The end result is that both connection are cleared.=20
     =20
     =20
     =20
     =20
     =20


------=_NextPart_000_00D4_01C25A8F.74237860
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Interesting, fascinating =
even.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The two ends should implement the same Connection =
collision=20
detection and arrive at the same conclusion.&nbsp; The way I read it, =
both=20
should retain the (TCP) connection initiated by the BGP speaker with the =
higher=20
value of BGP Identifier; assuming that that is speaker 2, then =
</FONT></DIV>
<DIV><FONT size=3D2></FONT><TT>This triggers the collision detection in =
speaker 2.=20
As he still</TT> <BR><TT>believes that connection 1 is established, he =
decides=20
to close the connection 2</TT><TT></TT> </DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>is in error; speaker 2 should close =
the first=20
connection just as speaker one has done.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>Tom Petch, Network Consultant<BR><A=20
href=3D"mailto:[e-mail]">[e-mail]</A><B=
R></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 solid 2px; MARGIN-LEFT: 5px; PADDING-LEFT: =
5px">
    <DIV><FONT face=3DArial size=3D2><B>-----Original =
Message-----</B><BR><B>From:=20
    </B><A=20
    =
href=3D"mailto:[e-mail]">hans.de_vleeschouwer@alca=
tel.be</A>=20
    &lt;<A=20
    =
href=3D"mailto:[e-mail]">hans.de_vleeschouwer@alca=
tel.be</A>&gt;<BR><B>To:=20
    </B>BGP mailing list &lt;<A=20
    href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR><B>Date: =
</B>12=20
    September 2002 15:38<BR><B>Subject: </B>problem in collision=20
    strategy?<BR></FONT></DIV>
    <DIV>&lt;snip&gt;</DIV>
    <P>(in the scenario below time progresses downwards) <BR>&nbsp;=20
    =
<P><TT>+---------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    +---------------+</TT> <BR><TT>! BGP speaker A=20
    =
!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    ! BGP speaker B !</TT> <BR><TT>! 10.10.10.10&nbsp;&nbsp;=20
    !------------------+ 10.10.11.11&nbsp;&nbsp; !</TT>=20
    =
<BR><TT>!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
    =
!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
    !</TT>=20
    =
<BR><TT>+---------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    +---------------+</TT>=20
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Setup TCP =
connection=20
    1!</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
!=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D&gt;!</TT>=20
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    !</TT>=20
    <P><TT>BGP speaker 1 initiates a TCP connection towards =
speaker2</TT>=20
    <BR><TT>This action is successfull.</TT>=20
    <P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
!&nbsp;&nbsp; OPEN=20
    for connection 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</TT>=20
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
!=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D&gt;!</TT>=20
    <P><TT>Speaker 1 being informed that the TCP is up, sends an =
OPEN</TT>=20
    <BR><TT>message for the connection he initiated. The OPEN =
message</TT>=20
    <BR><TT>is NOT yet treated by speaker 2. (probably speaker 2 is =
not</TT>=20
    <BR><TT>yet aware of the connection because he did not check the =
TCP</TT>=20
    <BR><TT>events ).</TT>=20
    <P><TT>The states in BGP are:</TT> <BR><TT>&nbsp;Connection 1: Open=20
    Sent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Connection=20
    1: idle?</TT>=20
    <P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp; =
Setup TCP=20
    connection 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</TT>=20
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
!&lt;=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D!</TT>=20
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    !</TT>=20
    <P><TT>At this stage, speaker 2 also sets up a TCP connection to =
speaker=20
    A</TT> <BR><TT>(this happens before the BGP application of speaker 2 =
is</TT>=20
    <BR><TT>aware of the connection of speaker 1).</TT> <BR>&nbsp;=20
    <P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OPEN for connection=20
    2&nbsp;&nbsp;&nbsp;&nbsp; !</TT>=20
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
!=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D&gt;!</TT>=20
    <P><TT>Now BGP speaker 1, being informed of a new connection=20
    immediatelly</TT> <BR><TT>sends an OPEN message. On Speaker 2 we =
have either=20
    a slow TCP, a slow BGP</TT> <BR><TT>or a slow link in between =
(actually it=20
    was a test tool, so I do not know</TT> <BR><TT>really).but in any =
case it=20
    seems that the BGP states now became:</TT>=20
    <P><TT>The states in BGP are:</TT> <BR><TT>&nbsp;Connection 1: Open=20
    Sent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Connection=20
    1: idle?</TT> <BR><TT>&nbsp;Connection 1: Open=20
    Sent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Connection=20
    2: idle?</TT>=20
    <P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OPEN for connection=20
    1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</TT>=20
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
!&lt;=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D!</TT>=20
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    !</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; KEEPALIVE for connection =
1=20
    !</TT> <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
!=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D&gt;!</TT>=20
    <P><TT>BGP speaker 2 'wakes up' and responds to connection 1. BGP =
speaker=20
    1</TT> <BR><TT>who is reacting alert, sends a KEEPALIVE for =
connection=20
    1</TT> <BR><TT>The states in BGP are:</TT> <BR><TT>&nbsp;Connection =
1: Open=20
    confirm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Connection 1: see=20
    below</TT> <BR><TT>&nbsp;COnnection 1: Open=20
    Sent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Connection=20
    2: ?</TT>=20
    <P><TT>AT this stage, the collision detection mechanism starts in =
BGP</TT>=20
    <BR><TT>speaker 1. Since BGP speaker 2 has the highest id, speaker 1 =

    decides</TT> <BR><TT>to tear down his original TCP connection =
(connection=20
    1).</TT>=20
    <P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp; KEEPALIVE =
for=20
    connection 1&nbsp;&nbsp; !</TT> =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
!&lt;=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D!</TT> <BR><TT>&nbsp; Connection 1:=20
    gone</TT> <BR><TT>&nbsp; COnnection 2 : Open Sent</TT>=20
    <P><TT>In the mean time BGP speaker 2, not being aware of the fact =
that</TT>=20
    <BR><TT>speaker 1 closed the connection 1 wakes up again, and =
receives=20
    the</TT> <BR><TT>keealive from speaker 1 , sends back a keepalive =
and bring=20
    the</TT> <BR><TT>connection 1 in establsihed state.(note that on =
this=20
    keepalive will be</TT> <BR><TT>lost, as the connection is =
closed.</TT>=20
    =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Connection 1: established</TT><TT></TT>=20
    <P><TT>Also at this moment, BGP speaker 2 notices that connection 2 =
is=20
    up</TT> <BR><TT>and sends an OPEN mesage for connection 2, and =
trasitions to=20
    OPEN SENT</TT>=20
    =
<BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    Connection 2: OPEN sent.</TT><TT></TT>=20
    <P><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OPEN for connection=20
    2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</TT>=20
    <BR><TT>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    =
!&lt;=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D!</TT><TT></TT>=20
    <P><TT>BGP speaker 2 then treats the OPEN mesage from speaker 1 =
(which=20
    arrived</TT> <BR><TT>quite some time ago, but was not treated until=20
    now).</TT> <BR><TT>for connection 2.</TT><TT></TT>=20
    <P><TT>This triggers the collision detection in speaker 2. As he =
still</TT>=20
    <BR><TT>believes that connection 1 is established, he decides to =
close the=20
    connection 2</TT><TT></TT>=20
    <P><TT>The end result is that both connection are cleared.</TT> =
<BR>&nbsp;=20
    <BR>&nbsp; <BR>&nbsp; <BR>&nbsp; <BR>&nbsp; =
</P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00D4_01C25A8F.74237860--



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA07241 for <[e-mail]>; Thu, 12 Sep 2002 13:17:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id ED1639124A; Thu, 12 Sep 2002 13:16:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D4A79128C; Thu, 12 Sep 2002 13:16:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 385A49124A for <[e-mail]>; Thu, 12 Sep 2002 13:16:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 254C75DDE6; Thu, 12 Sep 2002 13:16:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 8F7815DDC6 for <[e-mail]>; Thu, 12 Sep 2002 13:16:13 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8CHGCm58687; Thu, 12 Sep 2002 10:16:12 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Thu, 12 Sep 2002 12:55:21 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 12 Sep 2002 10:16:12 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> I think a reference to the fact that it is mainly used for route selection
> would suffice.

please propose the text.

Yakov.

> 
> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]] 
> Sent: Thursday, September 12, 2002 10:48 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> 
> On Wed, Sep 11, 2002 at 06:17:27PM -0400, Curtis Villamizar wrote:
> > We might want to say the value EGP in the ORIGIN field (which does
> > mean the EGP protocol, not any EGP type protocol) is depricated since
> > the EGP protocol has been moved to historic but retain the value to
> > document what it used to mean.
> 
> I would ask us to consider carefully before deprecating it.
> While no longer used (from what I've seen or heard) as the origin
> of the route being from the EGP protocol, people *are* using it in
> their route-maps to bias route selection.
> 
> -- 
> 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 NAA07216 for <[e-mail]>; Thu, 12 Sep 2002 13:16:30 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id AFD17912CB; Thu, 12 Sep 2002 13:15:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49C2D912D0; Thu, 12 Sep 2002 13:15:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 48DC6912CB for <[e-mail]>; Thu, 12 Sep 2002 13:15:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A2C675DE6F; Thu, 12 Sep 2002 13:15:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 100675DDE6 for <[e-mail]>; Thu, 12 Sep 2002 13:15:14 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA14276; Thu, 12 Sep 2002 13:15:07 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA00447; Thu, 12 Sep 2002 13:15:08 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DS91Z>; Thu, 12 Sep 2002 13:15:07 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: Tom Petch <[e-mail]>, idr <[e-mail]>, Susan Hares <[e-mail]>, yakov Rekhter <[e-mail]>, [e-mail], [e-mail], randy Bush <[e-mail]>
Subject: RE: FSM more words 
Date: Thu, 12 Sep 2002 13:15:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

 
> 
> 
> Ya, he's nit-picky, but he did make some good pts.
> 
> :-)
> 
Thank You Jonathan. With this I will refrain from making any more
contributions to this list.

Best to All,
Ben

 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA06896 for <[e-mail]>; Thu, 12 Sep 2002 13:07:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D517F91242; Thu, 12 Sep 2002 13:07:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2C699128C; Thu, 12 Sep 2002 13:07:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7CDFC91242 for <[e-mail]>; Thu, 12 Sep 2002 13:07:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 647555DE43; Thu, 12 Sep 2002 13:07:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 0E4F65DDE6 for <[e-mail]>; Thu, 12 Sep 2002 13:07:16 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CN53>; Thu, 12 Sep 2002 13:07:15 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Susan Hares'" <[e-mail]>
Cc: [e-mail]
Subject: RE: IdleHold
Date: Thu, 12 Sep 2002 13:07:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Sue,

I know you asked Greg, but I am on the draft-ietf-idr-bgp4-17.txt.  Am I
lost?  Or maybe you searched for "Idle Hold" like me and missed it (hence my
previous request to change IdleHold to Idle Hold)???

-Jonathan
:-)

-----Original Message-----
From: Susan Hares [mailto:[e-mail]] 
Sent: Thursday, September 12, 2002 3:30 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: IdleHold

Greg:

1st clarification - there is no IdleHold state in BGP.  There is
an IDLE state with sub-state like features.  Where do you find this
IdleHold state in the words I've attached?

Are we on the same document?


At 10:45 AM 9/12/2002 -0400, Greg Hankins wrote:
>I am still not convinced that IdleHold should be in the new BGP
>specification.
>
>Given that the goal of the WG is to "revise and clarify the base BGP4
>document" and to "document existing practice", I do not think that it
>should be included because this doesn't seem to be an existing practice
>(or at least one practiced by the majority of implementations).
>
>I have two questions:
>
>1. Which existing implementations support the IdleHold state, its timer
>    and flag?

***NO*** Implementation support Idle hold state.

Please refer to the hares-backoff draft for two know possibilities.
GateD by NextHop was the source of one method.  Another method is
attempting to describe cisco's back-off.   We will look to include others.
It's a "drafty" draft right now.  Please send me your favorite
persisent peer oscillation information.

>2. What existing documentation (books/courses/etc) lists IdleHold as a
state
>    in the FSM?

There is no IdleHold state.  There are Idle hold features (see the
bgp draft-15 for those sub-features described.)


>If the answers to these questions are not "the majority", then it isn't
>an existing practice.  Any implementation that does not support this state
>is now automatically non-standards compliant.
>
>I suggest that this state be documented in a separate draft that addresses
>stability.

The sub-state within Idle has been moved to the backoffdraft.
We are taking this approach.  Yakov and I agree that this is a good idea.


Hope this helps.   Do give me a call if this is unclear.  Let me know
if you need the phone number.

Sue






>Greg
>
>--
>Greg Hankins <[e-mail]> | Riverstone Networks, Inc.
>Systems Engineering                       | 5200 Great America Parkway
>http://www.riverstonenet.com/             | Santa Clara, CA 95054
>[phone]                           | [phone]


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA06726 for <[e-mail]>; Thu, 12 Sep 2002 13:01:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 109A3912B5; Thu, 12 Sep 2002 13:00:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC11A912CB; Thu, 12 Sep 2002 13:00:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 852FB912B5 for <[e-mail]>; Thu, 12 Sep 2002 13:00:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5A53E5DE43; Thu, 12 Sep 2002 13:00:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 0B5635DDE6 for <[e-mail]>; Thu, 12 Sep 2002 13:00:40 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CNZ6>; Thu, 12 Sep 2002 13:00:39 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Susan Hares'" <[e-mail]>
Cc: [e-mail]
Subject: RE: "ConnectRetryCnt to zero"
Date: Thu, 12 Sep 2002 13:00:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

No, just want to be able to search easily, for example for where whatEver
gets set to whatEver, so the consistency should go beyond this example. The
spec is quite large, even if you did read it all, you'd likely not retain it
all, so it needs to be workable.

Thnx

-----Original Message-----
From: Susan Hares [mailto:[e-mail]] 
Sent: Thursday, September 12, 2002 3:21 PM
To: Natale, Jonathan
Subject: Re: "ConnectRetryCnt to zero"

Do you have a preference?

At 11:09 AM 9/12/2002 -0400, you wrote:
>Please pick one and stick with it:
>"ConnectRetryCnt to zero"
>"ConnectRetryCnt = 0"

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 MAA06513 for <[e-mail]>; Thu, 12 Sep 2002 12:55:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A98D891290; Thu, 12 Sep 2002 12:55:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 730B4912B5; Thu, 12 Sep 2002 12:55:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4293691290 for <[e-mail]>; Thu, 12 Sep 2002 12:55:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 31DC75DE6F; Thu, 12 Sep 2002 12:55:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id DCE655DE43 for <[e-mail]>; Thu, 12 Sep 2002 12:55:21 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CNYQ>; Thu, 12 Sep 2002 12:55:21 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Thu, 12 Sep 2002 12:55:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I think a reference to the fact that it is mainly used for route selection
would suffice.

-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Thursday, September 12, 2002 10:48 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt

On Wed, Sep 11, 2002 at 06:17:27PM -0400, Curtis Villamizar wrote:
> We might want to say the value EGP in the ORIGIN field (which does
> mean the EGP protocol, not any EGP type protocol) is depricated since
> the EGP protocol has been moved to historic but retain the value to
> document what it used to mean.

I would ask us to consider carefully before deprecating it.
While no longer used (from what I've seen or heard) as the origin
of the route being from the EGP protocol, people *are* using it in
their route-maps to bias route selection.

-- 
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 MAA06355 for <[e-mail]>; Thu, 12 Sep 2002 12:52:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9C35F9128B; Thu, 12 Sep 2002 12:52:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BC7D912B5; Thu, 12 Sep 2002 12:52:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 04FD39128B for <[e-mail]>; Thu, 12 Sep 2002 12:52:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B86B15DE6F; Thu, 12 Sep 2002 12:52:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 6F2E25DE43 for <[e-mail]>; Thu, 12 Sep 2002 12:52:07 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CNYC>; Thu, 12 Sep 2002 12:52:03 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: IdleHold
Date: Thu, 12 Sep 2002 12:52:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I agree, it should be in a separate draft.

-----Original Message-----
From: Greg Hankins [mailto:[e-mail]] 
Sent: Thursday, September 12, 2002 10:46 AM
To: [e-mail]
Subject: IdleHold

I am still not convinced that IdleHold should be in the new BGP
specification.

Given that the goal of the WG is to "revise and clarify the base BGP4
document" and to "document existing practice", I do not think that it
should be included because this doesn't seem to be an existing practice
(or at least one practiced by the majority of implementations).

I have two questions:

1. Which existing implementations support the IdleHold state, its timer
   and flag?

2. What existing documentation (books/courses/etc) lists IdleHold as a state
   in the FSM?

If the answers to these questions are not "the majority", then it isn't
an existing practice.  Any implementation that does not support this state
is now automatically non-standards compliant.

I suggest that this state be documented in a separate draft that addresses
stability.

Greg

-- 
Greg Hankins <[e-mail]> | Riverstone Networks, Inc.
Systems Engineering                       | 5200 Great America Parkway
http://www.riverstonenet.com/             | Santa Clara, CA 95054
[phone]                           | [phone]


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA06089 for <[e-mail]>; Thu, 12 Sep 2002 12:44:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3B28591293; Thu, 12 Sep 2002 12:44:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06A5B912B5; Thu, 12 Sep 2002 12:44:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C031F91293 for <[e-mail]>; Thu, 12 Sep 2002 12:44:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id AE6675DE65; Thu, 12 Sep 2002 12:44:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 229B45DE43 for <[e-mail]>; Thu, 12 Sep 2002 12:44:09 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CNXC>; Thu, 12 Sep 2002 12:44:08 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'John G. Scudder'" <[e-mail]>, [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
Date: Thu, 12 Sep 2002 12:44:07 -0400
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id MAA06089

I agree, the text is clear and it matches practice (close enough).

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Wednesday, September 11, 2002 7:47 PM
To: Abarbanel, Benjamin
Cc: 'John G. Scudder'; [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 


In message
<[e-mail]>, 
"Abarbanel, Benjamin" writes:
> > 
> > >  > At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > >>  >6. P. 52, section 9.2.1.1 Change this sentence for clarity,
> > >>  >    "This rate limiting procedure applies on a 
> > per-destination basis,
> > >>  >although 
> > >>  >     the value of MinRouteAdvertisementInterval is set on a
> > >>  per BGP peer
> > >>  >basis."
> > >>  >
> > >>  >  To This:
> > >>  >    "This rate limiting procedure applies on a 
> > per-destination basis,
> > >>  >although
> > >  > >     the value of MinRouteAdvertisementInterval is set on a
> > >>  BGP router (same
> > >>  >     value for all peers) basis."
> > >>
> > >>  I disagree.
> > >why?
> > 
> > Because the proposed text does not correctly describe current 
> > implementations.  You are proposing a change to the protocol, not a 
> > clarification of existing practice.
> Then tell me how I am wrong. 
> 
> I read "per-destination basis" and "per BGP peer basis" as two different
> things. The first term, is the neighbor, the second term is our router. 
> If I was wrong then they both have to say either "per destination basis"
or
> "per peer basis" but not both. It confuses the reader, who does not know
> the protocol that way. Remember, assumptions, are sometimes bad.
> 
> Ben



  9.2.1.1 Frequency of Route Advertisement

   The parameter MinRouteAdvertisementInterval determines the minimum
   amount of time that must elapse between advertisement of routes to a
   particular destination from a single BGP speaker. This rate limiting
   procedure applies on a per-destination basis, although the value of
   MinRouteAdvertisementInterval is set on a per BGP peer basis.


MinRouteAdvertisementInterval is applied on a per destination basis.

MinRouteAdvertisementInterval is configured on a per peer basis.

The text is clear.  It matches practice.  

Route flap damping ala rfc2439 is a whole different mechanism but the
base BGP protocol spec does not have to include or even reference
extensions defined in separate documents.

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 MAA06029 for <[e-mail]>; Thu, 12 Sep 2002 12:42:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CD2A39128C; Thu, 12 Sep 2002 12:42:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98BF391293; Thu, 12 Sep 2002 12:42:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E113C9128C for <[e-mail]>; Thu, 12 Sep 2002 12:42:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CE4625DE65; Thu, 12 Sep 2002 12:42:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 4E44A5DE43 for <[e-mail]>; Thu, 12 Sep 2002 12:42:10 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CNW8>; Thu, 12 Sep 2002 12:42:09 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: Tom Petch <[e-mail]>, idr <[e-mail]>, Susan Hares <[e-mail]>, yakov Rekhter <[e-mail]>, [e-mail], [e-mail], randy Bush <[e-mail]>
Subject: RE: FSM more words 
Date: Thu, 12 Sep 2002 12:42:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Ya, he's nit-picky, but he did make some good pts.

:-)

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Wednesday, September 11, 2002 7:03 PM
To: Abarbanel, Benjamin
Cc: '[e-mail]'; Tom Petch; idr; Susan Hares; yakov Rekhter;
[e-mail]; [e-mail]; randy Bush
Subject: Re: FSM more words 


In message
<[e-mail]>, 
"Abarbanel, Benjamin" writes:
> Curtis:
>   If I were a lawyer I would disagree with you. Cause one small word could
> mean the difference between victory or defeat of a case. Just some
thoughts.
> 
> Ben


You are obviously in the wrong profession.  Please consider a change.  :-)

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 MAA05737 for <[e-mail]>; Thu, 12 Sep 2002 12:34:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1393A912BF; Thu, 12 Sep 2002 12:34:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 603D69128C; Thu, 12 Sep 2002 12:34:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 47C27912BF for <[e-mail]>; Thu, 12 Sep 2002 12:34:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 257935DE43; Thu, 12 Sep 2002 12:34:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id D2BC65DDE2 for <[e-mail]>; Thu, 12 Sep 2002 12:34:06 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CNVT>; Thu, 12 Sep 2002 12:34:06 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: your mail 
Date: Thu, 12 Sep 2002 12:34:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Change "read from a peer" to "received from a peer" and/or drop this thread!

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Wednesday, September 11, 2002 6:12 PM
To: Abarbanel, Benjamin
Cc: 'Jeffrey Haas'; '[e-mail]'
Subject: Re: your mail 


In message
<[e-mail]>, 
"Abarbanel, Benjamin" writes:
> My point is that no one "reads from a peer", that is physically
impossible.
> If there are many other ways to skin the cat, then mention like this,
> "reads from a peer socket/stream/session/etc." just to be technically
> correct.
> 
> Ben


It if physically impossible to "read from a peer" which also makes it
painfully obvious that what is meant is "read from the socket for the
TCP connection that is associated with the BGP session for a specific
peer".

The latter is unambiguous even to the complete idiot but overly wordy
for anyone with an understanding of what a protocol based on TCP
entails.  The former is short and it is unambiguous for the intended
audience of the BGP protocol spec.

Curtis

ps - Please stop wasting our time.  Please be sure that your comments
are regarding something that is incorrect, incomplete, ambiguous, or
unclear when read from the standpoint of a person well versed in IP
routing, TCP, and TCP programming.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA05724 for <[e-mail]>; Thu, 12 Sep 2002 12:34:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2CDB09127C; Thu, 12 Sep 2002 12:34:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46D3E9128C; Thu, 12 Sep 2002 12:32:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AB8C89127C for <[e-mail]>; Thu, 12 Sep 2002 12:32:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 18EA25DE43; Thu, 12 Sep 2002 12:32:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 0F00C5DDE2 for <[e-mail]>; Thu, 12 Sep 2002 12:32:12 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CNVN>; Thu, 12 Sep 2002 12:32:11 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: idr <[e-mail]>
Subject: RE: FSM ConnectRetryCnt
Date: Thu, 12 Sep 2002 12:32:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I though we were documenting what is deployed and what is hard to read?  I
agree that peer flapping is a noble cause, but maybe the whole concept
should be in another draft?

-----Original Message-----
From: Tom Petch [mailto:[e-mail]] 
Sent: Wednesday, September 11, 2002 6:01 PM
To: Susan Hares
Cc: idr; Susan Hares; yakov Rekhter; [e-mail]; [e-mail];
randy Bush
Subject: Re: FSM ConnectRetryCnt

Um; thanks for the explanation.  I appreciate I am picky but I would
like a brief sentence in BGP base document as to why we do this, if we
keep the rest of the processing in which I assume we should (?).

Tom Petch
[e-mail]
-----Original Message-----
From: Susan Hares <[e-mail]>
To: Tom Petch <[e-mail]>
Cc: idr <[e-mail]>; Susan Hares <[e-mail]>; yakov Rekhter
<[e-mail]>; [e-mail]
<[e-mail]>; [e-mail] <[e-mail]>; randy Bush
<[e-mail]>
Date: 11 September 2002 21:18
Subject: Re: FSM ConnectRetryCnt


>
>1st - ConnectRetryCnt was included to damp out
>         persistent bgp peer oscillations.
>
>         1) The peer connections would drop due to an error condition
>            (such as a bogus prefix),
>         2) the auto-restart would engage,
>         3) the connection would re-establish,
>         4) the same data would get sent the error would occur, and
>                 the cycle starts with #1
>
>The bgp peer oscillation draft I've written took this information
>out of the BGP specification due to working group consensus
>**AND** the fact it did not match with the current implementations.
>
>Since the persistent route oscillation **is** in some
implementations,
>we put the text off into a separate document.   Divide and conquer
>
>hares-backoff-00.txt
>was my latest draft.  Due to the charter of the WG at this time,
>we cannot include this in the work until we finish the.
>
>The ConnectRetryCnt is cleared upon manual reset, because
>the operators need something to be able to manual stop the
>mechanism to stop the flap.
>
>Does this answer the questions on the draft?
>
>sue
>
>
>06:30 PM 9/11/2002 +0100, Tom Petch wrote:
>>This seems to have lost its purpose (which it had in BGP-17).  It
gets
>>cleared on manual stop, incremented by one when something goes wrong
>>but so what?  An explanation would help.
>>
>>And I think it should be a Session Attribute required for each
>>connection, along with
>>OpenDelayTimer
>>DelayOpenFlag
>>
>>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 MAA05520 for <[e-mail]>; Thu, 12 Sep 2002 12:27:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 06BF291290; Thu, 12 Sep 2002 12:26:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9F219128C; Thu, 12 Sep 2002 12:26:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 32A5091290 for <[e-mail]>; Thu, 12 Sep 2002 12:26:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1E1445DDF4; Thu, 12 Sep 2002 12:26:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id CB86A5DDE2 for <[e-mail]>; Thu, 12 Sep 2002 12:26:48 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CN4V>; Thu, 12 Sep 2002 12:26:48 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: FW: FSM more words 
Date: Thu, 12 Sep 2002 12:26:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

-----Original Message-----
From: Natale, Jonathan 
Sent: Thursday, September 12, 2002 12:23 PM
To: '[e-mail]'
Subject: RE: FSM more words 

I also think that the terms should be consistent.  Curtis, I see your point,
but I also think that by using consistent terms it is easier to search the
doc. 

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Wednesday, September 11, 2002 5:33 PM
To: Tom Petch
Cc: idr; Susan Hares; yakov Rekhter; [e-mail]; [e-mail];
randy Bush
Subject: Re: FSM more words 


In message <013601c259b9$f5fcc340$0301a8c0@tom3>, "Tom Petch" writes:
> In the 26Aug text, I find the timer terminology still confusing.
> Timers can, I find, 
> stop
> start
> restart
> clear
> set
> reset
> expire
> 
> Rich the English language is but I see this as overuse.
> For me, timers
> start, stop, expire

I didn't find the word "reset" in draft-ietf-idr-bgp4-17.tx.

Restarting a time is getting rid of any running timer and starting the
timer from its configured initial value (ie: stop, then start).  That
seems to be entirely consistent with uses of the word restart in other
contexts.

Clear and stop a timer are synonomous.  I can't see how that could not
be obvious.

The word set is used in phrases like "set Hold timer to a large value"
which is not adequately covered by the words start and stop.

> The only further refinement is that they may start with an initial
> value or with the value they had when they were stopped (eg NFL game
> clocks); I do not believe, but cannot be sure, that the last is ever
> used in the FSM.  Which means all we need is
> start with initial value (spell it out just to be sure)
> stop
> expire
> and anything else just confuses - me and I suspect others.
> 
> Tom Petch
> [e-mail]

Just as we can't include a complete TCP tutorial, we can't include
english dictionary entries for every small word used in the document.

I don't see any reason for change.

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 MAA05505 for <[e-mail]>; Thu, 12 Sep 2002 12:26:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BCFDB91245; Thu, 12 Sep 2002 12:26:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8AA699127C; Thu, 12 Sep 2002 12:26:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 51F5091245 for <[e-mail]>; Thu, 12 Sep 2002 12:26:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3D1CC5DDF4; Thu, 12 Sep 2002 12:26:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id E8C135DDE2 for <[e-mail]>; Thu, 12 Sep 2002 12:26:24 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CN4S>; Thu, 12 Sep 2002 12:26:24 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: FSM ConnectRetryCnt 
Date: Thu, 12 Sep 2002 12:26:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

"This is a protocol that has been deployed very successfully for nearly a
decade"

--yes, but not primarily deployed significantly per the rfc.  That's why we
are having this discussion now.

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Wednesday, September 11, 2002 5:47 PM
To: Tom Petch
Cc: idr; Susan Hares; yakov Rekhter; [e-mail]; [e-mail];
randy Bush
Subject: Re: FSM ConnectRetryCnt 


In message <013701c259b9$f764dec0$0301a8c0@tom3>, "Tom Petch" writes:
> This seems to have lost its purpose (which it had in BGP-17).  It gets
> cleared on manual stop, incremented by one when something goes wrong
> but so what?  An explanation would help.

Its something read by the MIB.

> And I think it should be a Session Attribute required for each
> connection, along with
> OpenDelayTimer
> DelayOpenFlag
> 
> Tom Petch
> [e-mail]

We are not here to make arbitrary changes to the protocol just for
personal preferences.  This is a protocol that has been deployed very
successfully for nearly a decade and enjoys extremely widespread use.

The IETF document that describes this protocol was a little
inaccurate, did not reflect current implementations in ways that would
impact interoperability (if implemented exactly as specified) and was
reknown for being difficult to read.  AFAIK these deficiencies in *the
document* are all we are fixing unless there is a very pressing need
to make changes to the protocol.

An example of a pressing need would be the specification of MED
handling leaves open the possiblity for a routing loop but a commonly
implemented change in MED usage fixes the problem.  [already fixed in
bgp-17].

Not to pick on you in particular but things like "I think it would be
nice if the following were included in the open" and "I'd like to
change the semantics of something for no good reason except it looks
cleaner to me" are definitely not going to get considered.  [So please
stop wasting our time - this means you too, Ben - please :-) ].

Curtis


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 MAA04903 for <[e-mail]>; Thu, 12 Sep 2002 12:10:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A37779124A; Thu, 12 Sep 2002 12:09:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66E479127C; Thu, 12 Sep 2002 12:09:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7DF619124A for <[e-mail]>; Thu, 12 Sep 2002 12:09:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 693445DE89; Thu, 12 Sep 2002 12:09:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by segue.merit.edu (Postfix) with ESMTP id BC20F5DDC7 for <[e-mail]>; Thu, 12 Sep 2002 12:09:30 -0400 (EDT)
Received: from doom.twoguys.org by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id JAA05798; Thu, 12 Sep 2002 09:09:27 -0700 (PDT)
Received: (from ghankins@localhost) by doom.twoguys.org (8.11.6/8.11.6) id g8CG9Nx10807 for [e-mail]; Thu, 12 Sep 2002 12:09:23 -0400
Date: Thu, 12 Sep 2002 12:09:23 -0400
From: Greg Hankins <[e-mail]>
To: [e-mail]
Subject: Re: IdleHold
Message-ID: <[e-mail]>
Reply-To: [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Sep 12, 2002 at 03:29:31PM -0400
X-Mailer: Mutt 1.2.5.1i
Sender: [e-mail]
Precedence: bulk

On Thu, Sep 12, 2002 at 03:29:31PM -0400, Susan Hares wrote:
>1st clarification - there is no IdleHold state in BGP.  There is
>an IDLE state with sub-state like features.  Where do you find this
>IdleHold state in the words I've attached?

draft-ietf-idr-bgp4-17 page 34.  It describes a new state, a new timer and
a new flag.  You imply that the state has already been moved to a separate
draft, if so then this is great.

Greg

>At 10:45 AM 9/12/2002 -0400, Greg Hankins wrote:
>>I am still not convinced that IdleHold should be in the new BGP
>>specification.
>>
>>Given that the goal of the WG is to "revise and clarify the base BGP4
>>document" and to "document existing practice", I do not think that it
>>should be included because this doesn't seem to be an existing practice
>>(or at least one practiced by the majority of implementations).
>>
>>I have two questions:
>>
>>1. Which existing implementations support the IdleHold state, its timer
>>    and flag?
>
>***NO*** Implementation support Idle hold state.
>
>Please refer to the hares-backoff draft for two know possibilities.
>GateD by NextHop was the source of one method.  Another method is
>attempting to describe cisco's back-off.   We will look to include others.
>It's a "drafty" draft right now.  Please send me your favorite
>persisent peer oscillation information.
>
>>2. What existing documentation (books/courses/etc) lists IdleHold as a state
>>    in the FSM?
>
>There is no IdleHold state.  There are Idle hold features (see the
>bgp draft-15 for those sub-features described.)
>
>
>>If the answers to these questions are not "the majority", then it isn't
>>an existing practice.  Any implementation that does not support this state
>>is now automatically non-standards compliant.
>>
>>I suggest that this state be documented in a separate draft that addresses
>>stability.
>
>The sub-state within Idle has been moved to the backoffdraft.
>We are taking this approach.  Yakov and I agree that this is a good idea.
>
>
>Hope this helps.   Do give me a call if this is unclear.  Let me know
>if you need the phone number.
>
>Sue
>
>
>
>
>
>
>>Greg
>>
>>--
>>Greg Hankins <[e-mail]> | Riverstone Networks, Inc.
>>Systems Engineering                       | 5200 Great America Parkway
>>http://www.riverstonenet.com/             | Santa Clara, CA 95054
>>[phone]                           | [phone]

>
>
>Note: (this is version 5 of the changes to
>       the text.) 
>
>8.0	BGP Finite State Machine
>
>
>This section specifies the BGP operation in terms of a 
>Finite State Machine (FSM).  The section falls into 2 
>parts:
>
>    1)	Description of Events for the State machine (section 
>        8.1
>    2)	Description of the FSM (section 8.2)
>
>Session Attributes required for each connection are; 
>
>   1)	state
>   2)	Connect Retry timer
>   3)	Hold timer
>   4)	Hold time
>   5)	Keepalive timer
>
>8.1 Events for the BGP FSM
>
>8.1.1   Administrative Events (events 1-5)
>
>Please note that only Event 1 (manual start) and Event 2 
>(manual stop) are mandatory administrative events. All 
>other administrative events are optional.
>
> Event1: Manual start 
>
>	   Definition: Administrator manually starts peer
>                       connection
>	   Status: 	Mandatory
>
> Event2: Manual stop
>
>	   Definition: Local system administrator manually 
>                       stops the peer connection.
>
>	   Status: 	mandatory
>	   
>
> Event3: Automatic Start
>
> 	   Definition: Local system automatically starts the 
>                       BGP peer session
>
>	   Status:     Optional depending on local system
>
> Event4: Manual start with passive Transport Establishment
>
>	   Definition: Administrator manually start the peer
>                       Connection, but has the passive flag 
>                       enabled.  The passive flag indicates 
>                       that the peer will listen prior to 
>                       establishing the connection.
>
>	   Status:     Optional depending on local system
>		
>
> Event5: Automatic start with passive Transport establishment
>
>	  Definition:  Local system automatically starts the
>                       BGP session with the passive flag 
>                       enabled.  The passive flag indicates 
>                       that the peer will listen prior to 
>                       establishing a connection.
>
>	  Status:      Optional depending on local system use
>		       of a passive connection.
>
> Event6: Automatic start with bgp_stop_flap option set
>
>	   Definition: Local system automatically starts the 
>                       BGP peer session with persistent peer 
>                       oscillation damping enabled.  The exact 
>                       method of damping persistent peer 
>                       oscillations is left up to the 
>                       implementation.   These methods of 
>                       damping persistent BGP adjacency 
>                       flapping are outside the scope of this 
>                       document.
> 
>
>           Status: 	Optional, used only if the bgp peer has 
>	  	        Enabled a method of damping persistent
>		        BGP peer flapping.
>
>
> Event7: Auto stop
>
>	   Definition: Local system automatically stops the
>                       BGP peer session.  
>	
>	   Status:     Optional depending on local system
>
>
>8.1.2 Timer Events (events 8-11)
>
> Event8:  idle Hold timer expires 
>
>           Definition: Idle Hold timer expires.  The Idle 
>                       Hold Timer is only used when persistent  
>                       BGP oscillation damping functions are 
>                       enabled.  
>
>           Status: 	Optional.  Used when persistent
>			BGP peer oscillation damping functions
>			are enabled. 
>
>
>
> Event9: connect retry timer expires
>
>           Definition: An event triggered by the expiration of 
>                       the ConnectRetry timer.
>  
>	   Status:     Mandatory
>
> Event10: hold time expires
>
>	   Definition: An event generated when the HoldTimer 
>                       expires.
>
>	   Status:     Mandatory
>
> Event11: keepalive timer expires
>
>	   Definition: A periodic event generated due to the 
>                       expiration of the KeepAlive Timer. 
> 
>	   Status:     Mandatory
>
> Event12: DelayBGP Open timer expires [changed]
>	
>	   Definition: A timer that delays sending of the BGP
>	               Open message for n seconds after the
>                       Transport connection has been completed. 
>
>	   status:     Optional
>
>8.2.3) Tranport Message based (13-16) 
>
> Event13: Transport Connection Indication & valid remote peer[changed]
>
>	   Definition: Event indicating that transport
>                       Request 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.
>
>
>	   Status:     Mandatory
>
> Event14: RCV Transport Connection Indication and Invalid Source or 
>          Destination [changed]
>
>           Definition: Transport request received 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.
>
>	    Status: 	 Mandatory
>	
> Event15: Transport Connection request sent received an ACK.
>
>           Definition: Local system's request to establish a transport
>		       Connection to the remote side received
>		       an ACK.
>
>
>	    Status:    Mandatory
>
> Event16: Transport Connection Confirmed [changed]
>
>	   Definition: The local system has received a Confirmation that
>                       the transport connection has been established by
>		       the remote site. 
>
>	  Status:      Mandatory
>
> Event17: Transport connection fails [changed]
>
>           Definition: This BGP peer receives a transport
>		       connection failure notice.  This
>		       connection notice could be caused by a
>		       Transport disconnect message or a
>		       Timeout in the transport session.
>
>                       If this connection is using TCP, 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
>
>
>8.1.4 BGP Messages (18-27)
>
> Event18: BGPOpen
>
>           Definition:  An event indicating that a valid Open 
>			message has been received.
>
>	   Status: 	Mandatory
>
> Event19: BGPOpen with BGP Delay Open Timer running [changed]
>
>           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. 
>
>	    Status:    Optional
>
> Event20: BGPHeaderErr
>
>	   Definition: BGP message header is not valid.  
>
>	   Status:     Mandatory
>
> Event21: BGPOpenMsgErr 
>	   Definition: An BGP Open message has been received 
>                        with errors. 
> 
>	   Status: 	Mandatory
>
>
> Event22: Open collision discard
>
>           Definition: An event generated administratively 
>                       when a connection Collision has been 
>                       detected while processing an incoming  
>                       Open message. This connection has been 
>                       selected to disconnected.  See section 
>                       6.8 for more information on collision
>	               detection.  
>
>                       Event 22 is an administrative could 
>                       occur if FSM is implemented as two 
>                       linked state machines.  
>
>	  Status:      Optional
>
> Event23: NotifMsgVerErr
>
>	    Definition: An event is generated when a 
>                        NOTIFICIATION message with "version   
>                        error" is received.
>
>	    Status:     Mandatory
>
> Event24: NotifMsg
>
>	    Definition: An event is generated when a 
>                        NOTIFICATION messages is received and
>                        the error code is anything but 	 
>			"version error".
>
>	     Status:	Mandatory
>		        
> Event25: KeepAliveMsg
>
>	    Definition: An event is generated when a KEEPALIVE
>			Message is received.
>
>		Status: Mandatory
>
> Event26: UpdateMsg
>
>	    Definition: An event is generated when a valid 
>			Update Message is received.
>
>		Status: Mandatory
>
> Event27: UpdateMsgErr
>
>	    Definition: An event is generated when an invalid
>			Update message is received.
>
>		Status:	Mandatory
>
> 
>8.2) Description of FSM
>
>
>Idle state
>
>   Initially BGP is in the Idle state.   
>
>   In this state BGP refuses all incoming BGP connections.  No 
>   resources are allocated to the peer.    In response to a 
>   manual start event(Event1) or an automatic start 
>   event(Event3), the local system 
>      -	initializes all BGP resources, 
>      -	sets the Connect retry counter to zero
>      -	starts the ConnectRetry timer with initial value, 
>      -	initiates a transport connection to the other BGP 
>        peer, 
>      -	listens for a connection that may be initiated by 
>        the remote BGP peer, and
>        [Action A in the FSM table]
>      -	changes its state to connect.
>
>  An manual stop event (Event2) is ignored in the Idle state.
>
>  In response to a manual start event with the passive Transport
>  flag (Event 4) or automatic start with the passive Transport flag 
>  (Event 5), the local system:
>      -	initializes all BGP resources,
>      -	sets the connect retry count to zero,
>      -	start the Connect Retry timer with initial value, 
>      -	listens for a connection that may be initiated by 
>        the remote peer
>        [Action B in the FSM table] 
>      -	changes its state to Active.
>
>  The exact value of the ConnectRetry timer is a local 
>  matter, but it should be sufficiently large to allow TCP 
>  initialization.   
>
>  If a persistent BGP peer oscillation damping function is 
>  enabled, two additional events may occur within Idle state:  
>      -	Automatic start with bgp_stop_flap set [Event6],
>      -	Idle Hold Timer expired [Event 8].
>
>  The method of preventing persistent BGP peer oscillation is 
>  outside the scope of this document.
>
>  Any other events [Events 9-27] received in the Idle state, 
>  are noted by the MIB processing as FSM Errors [action V]
>  and the local peer stays in the Idle State.
>
>
>Connect State:
>
>  In this state, BGP is waiting for the transport protocol 
>  connection to be completed.
>
>  If the transport 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: 
>     -	clears the ConnectRetry timer, 
>     -	set the BGP Open Delay timer to the initial 
>        value.
>        [Action ZZ in FSM table]
>
>  If the Delay Open flag is not set, the local system: 
>     - clears the ConnectRetry timer, 
>     - completes BGP initialization
>     - send an Open message to its peer,
>     - sets Hold timer to a large value,
>     - Change the state to Open Sent 
>   [Action H in the FSM table]
>
>  A hold timer value of 4 minutes is suggested.
>
>  If the Open Delay timer expires [Event 12] in the connect 
>  state,
>     - send an Open message to its peer,
>     - set the Hold timer to a large value,
>	[Action H in the FSM Table], and
>     - change the state to Open Sent. 
>
>  If the BGP port receives a Transport connection indication 
>  [Event 13], the Transport connection is processed (actions AA or
>  AB in the FSM table) and the connection remains
>  in the connected state. 
>
>  If the transport connection receives an Transport indication
>  that is invalid or unconfigured. [Event 14]:
>     - the transport connection is rejected.
>	[Action L in the FSM table]
>
>  If the transport connection fails (timeout or transport
>  disconnect) [Event17], the local system:
>      - restarts the ConnectRetry timer, 
>      - continues to listen for a connection that may be 
>        initiated by the remote BGP peer, and
>     [Action G in the FSM table]
>      - changes its state to Active. 
>
>
>  If an Open is received with the BGP Delay Open timer is 
>  running [Event 19], the local system:
>	- clears the connect retry timer (cleared to zero),
>	- completes the BGP initialization, 
>	- Stops and clears the BGP Open Delay timer
>	- Sends an Open message
>
>	[Action H in the FSM table], and
>	- changes its state to Open Confirm.
>
>
> The start events [Event 1, 3-6] are ignored in connect 
> state.
>
> A manual stop event[Event2], the local system:
>       - drops the transport connection, 
>       - releases all BGP resources,
>       - sets connect retry count to zero
>       - resets the connect retry timer (sets to zero)
>      [Action Z in the FSM table]
>       - goes to Idle state.
>
>  In response to the ConnectRetry timer expired event(Event 
>  9), the local system: 
>      - Sets the MIB FSM error information with ConnectRetry 
>        expired, 
>      - drops the transport connection 
>      - restarts the ConnectRetry timer
>      - initiates a transport connection to the other BGP 
>        peer, 
>      - continues to listen for a connection that may be 
>        initiated by the remote BGP peer, and
>      [Action O in the FSM table]
>      - stays in Connect state.
>
> In response to any other events [Events 7-8, 10-11, 18, 20-
> 27] the local system:
>     - resets the connect retry timer (sets to zero),
>     - drops the Transport connection,
>     - release all BGP resources, 
>     - increments the ConnectRetryCnt by 1,
>     - [optionally] performs bgp peer oscillation damping, and
>     [Action D in the FSM table],
>     - goes to Idle state.
>
>
>Active State:
>
> In this state BGP is trying to acquire a peer by listening 
> for and accepting a transport protocol connection.  
>
> A transport connection succeeds [Event 15 or Event 16], the 
> local system: process the transport connection flags
>	- If the BGP delay open flag is set:
>          o clears the ConnectRetry timer, 
>          o completes the BGP initialization,
>          o sets the BGP delay Open timer
>         [Action ZZ]
>
>        - If the BGP delay open flag is not set:
>          o clears the ConnectRetry timer,
>          o completes the BGP initialization, 
>          o sends the Open message to it's peer, 
>          o sets its Hold timer to a large value, 
>         [Action H in the FSM table]
>          and changes its state to OpenSent.  
>
> A Hold timer value of 4 minutes is suggested.  
>
> If the local system receives a valid Transport Indication
> [Event 13], the local system processes the Transport flags
>  (actions aa or ab in FSM section 2.3.4).  
>
> If the local system receives a Transport indication
> that is invalid for this connection [Event 14]:
>      - the transport connection is rejected
>        [Action L in the FSM table]
>
> If the local system receives a Transport connection
> failed [Event 17] (timeout or receives Transport
> disconnect), the local system will:
>	- set Transport disconnect in the MIB reason code,
>	- restart ConnectRetry timer (with initial value)
>	- release all BGP resources
>	- Acknowledge the drop of Transport connection if
>          transport disconnect (If TCP, send a FIN ACK),
>	- Increment ConnectRetryCnt by 1,
>	- perform the BGP peer oscillation damping process [2]
>	[Action Y in the FSM table]
>
> If the local system has the Delay Open timer expired [event 
> 12] local system: 
>        - clears the Connect Retry timer (set to zero),
>	- stops and clears the Delay Open timer (set to zero) 
>        - completes the BGP initialization,
>        - sends the Open message to it's remote peer,
>        - sets it's Hold timer to a large value,
>        [Action H in the FSM table]
>        - and set the state to Open Confirm.
>
> A Hold timer value of 4 minutes is also suggested for this 
> state transition.
>
> If an Open is received with the BGP Delay Open timer is 
> running [Event 19], the local system 
>	- clears the connect retry timer (cleared to zero),
>	- Stops and clears the BGP Open Delay timer  
>	- completes the BGP initialization, 
>	- Stops and clears the BGP Open Delay timer
>	- Sends an Open message
>	- Set the Hold timer to a large value (4 minutes),
>	[Action H in the FSM table], and
>	- changes its state to Open Confirm.
>
>
> In response the ConnectRetry timer expired event[Event9], 
> the local system:
>        - restarts the ConnectRetry timer (with initial value),
>        - initiates a transport connection to the other BGP 
>          peer,
>        - Continues to listen for transport connection that may be 
>          initiated by remote BGP peer, 
>        [Action F in the FSM table]
>	- and changes its state to Connect.  
>
>
> The start events [Event1, 3-6] are ignored in the Active 
> state.
>
> A manual stop event[Event2], the local system:
>        - Sets the administrative down in the MIB reason code,
>	- Sends a notification with a Cease,
>	- If any BGP routes exist, delete the routes
>	- release all BGP resources, 
>	- drops the Transport connection, 
>        - sets connect retry count to zero
>        - resets the connect retry timer (sets to zero)
>        [Action S in the FSM table]
>        - goes to Idle state.
>
> In response to any other event (Events 7-8, 10-11,18, 20-
> 27), the local system:
>        - stores the MIB information to indicate appropriate 
>          error [FSM for Events 7-8, 10-11, 18, 20-27]
>        - reset the connect retry timer (sets to zero),
>        - release all BGP resources, 
>	- drops the transport connection, 
>        - increments the ConnectRetryCnt by one,
>        - optionally performs BGP peer oscillation damping, 
>  	  [Action D in FSM table],
>	- and goes to the idle state
>
>
>Open Sent:
>
> In this state BGP waits for an Open Message from its peer.  
>
> When an OPEN message is received, all fields are checked 
> for correctness.  If there are no errors in the OPEN message 
> [Event 18] the local system:
>       - resets the BGP Delay timer to zero,
>       - reset BGP Connect Timer to zero, 
>       - sends a KEEPALIVE message and
>       - sets a KeepAlive timer (via the text below)
>       - sets the Hold timer according to the negotiated value 
>         (see section 4.2), and 
>         [Action N in the FSM table]
>       - sets the state to Open Confirm.
>
>
> If the negotiated Hold time value is zero, then the Hold 
> Time timer and KeepAlive timers are not started.   If the 
> value of the Autonomous System field is the same as the 
> local Autonomous System number, then the connection is an 
> "internal" connection; otherwise, it is an "external" 
> connection.   (This will impact UPDATE processing as 
> described below.)  
>
>
> If the BGP message header checking [Event20] or OPEN message
> check detects an error (see Section 6.2)[Event21], the local system:
>       - sends a NOTIFICATION message with appropriate error 
>         code, 
>       - reset the connect retry timer (sets to zero),
>       - if there are any routes associated with the BGP session,
>	 delete these routes
>       - release all BGP resources,
>       - drop the transport session 
>       - increments the ConnectRetryCnt by 1, 
>       - bgp peer oscillation damping process,  
>       [Actions I, J in FSM table, depending on error],
>       - and goes to the Idle state.
>
> Collision detection mechanisms (section 6.8) need to be 
> applied when a valid BGP Open is received [Event 18 or 
> Event 19].  Please refer to section 6.8 for the details of 
> the comparison. An administrative collision detect is when 
> BGP implementation determines my means outside the scope of 
> this document that a connection collision has occurred.   
>
> If a connection in Open Sent is determined to be the 
> connection that must be closed, an administrative collision 
> detect [Event 22] is signaled to the state machine. If such 
> an administrative collision detect dump [Event 22] is 
> received in Open Sent, the local system:  
>       - sets MIB state information to 
>         collision detect closure, 
>       - send a NOTIFICATION with a CEASE
>       - resets the connect retry timer,
>       - release all BGP resources,
>       - drop the transport connection,
>       - increments ConnectRetryCnt by 1,
>       - performs any BGP peer oscillation damp process, and
>       [Action R in the FSM],
>       - enters Idle state.
>
>
>  If a NOTIFICATION message is received with a version 
>  error[Event23], Notification message without version number 
>  [Event 24], the local system: 
>       - resets the connect retry timer (sets to zero)
>       - drops the Transport connection,
>       - releases all BGP resources, 
>       - increments the ConnectRetryCnt by 1
>       - process any BGP peer oscillation damping,
>	[Action Y]  
>       - and sets the state to Idle.
>
>
> The Start events [Event1, 3-6] are ignored in the OpenSent 
> state.
>
>  If a manual stop event [Event 2] is issued in Open sent 
> state, the local system:
>	- Sets administrative down reason in MIB reason,
>	- sends the Notification with a cease,
>	- if BGP routes exists, delete the routes,
>	- Release all BGP resources, 
>	- Drops the Transport connection, 
>	- set ConnectRetryCnt to zero, 
>	- resets the Connect Retry timer (set to zero),
>	[Action S in the FSM table], and
>	- transitions to the Idle state.
>
>  If an automatic stop event [Event 7] is issued in Open sent 
>  state, the local system:
>	- Sets administrative down reason in MIB reason,
>	- sends the Notification with a cease,
>	- if any routes are associated with te BGP session,
>	  delete the routes, 
>	- release all the BGP resources
>	- Drops the Transport connection, 
>	- increments the ConnectRetryCnt by 1, 
>	- BGP peer oscillation process [2]
>	[Action C in the FSM table], and
>	- transitions to the Idle state.
>
> If the Hold Timer expires[Event 10], the local system:
>       - set Hold timer expired in MIB Error reason code, 
>       - send a NOTIFICATION message with error code Hold 
>         Timer Expired,
>       - reset the connect retry timer (sets to zero),
>       - releases all BGP resources,
>       - drops the Transport connection, 
>       - increments the ConnectRetryCnt by 1
>         [Action K in the FSM table], and
>	- transitions to the Idle state.
>
>
> If a transport indication is received for valid connection 
> [Event 13] or transport Request Acknowledgement [Event 15]
> is received, or a transport connect confirm [Event 16] is
> received a second TCP session may be in progress.  This
> second TCP session is tracked per the Call Collision 
> processing (section 6.8) until an OPEN message is received.
>
> A TCP connection for an invalid port [Event 14] is ignored. 
>
> If a Transport Failure [Event17], is received from the 
> underlying transport protocol, the local system:
>       - closes the BGP connection, 
>       - restarts the Connect Retry timer, 
>       - and continues to listen for a connection that may be 
>         initiated by the remote BGP peer,
>       [Action O in the FSM table]
>       - and goes into Active state.
>
>
> In response to any other event [Events 8-9, 11-12, 19, 25-27], 
>  the local system:
>	- sends the NOTIFICATION with the Error Code Finite 
>          state machine error,
>        - resets the connect retry timer (sets to zero),
>	- releases all BGP resources
>        - drops the Transport connection, 
>        - increments the ConnectRetryCnt by 1, 
>        - process any bgp peer oscillation damping[2] 
>        [Action E in the FSM table],
>        - and sets the state to idle.
>
>
>Open Confirm State
>
> In this state BGP waits for a KEEPALIVE or NOTIFICATION 
> message.
>
> If the local system receives a KEEPALIVE message[Event 25], 
>        - restarts the Hold timer, 
>          [Action P in the FSM table], and
>        - changes its state to Established. 
>
>
> If the local system receives a NOTIFICATION message [event 
> 23-24] or receives a TCP Disconnect [event 17] from the 
> underlying transport protocol, the local system:  
>        - sets the appropriate MIB information for FSM error, 
>        - resets the connect retry timer (sets the timer to 
>          zero),
>	- releases all BGP resources, 
>        - drops the TCP connection,
>        - increments the ConnectRetryCnt by 1, 
>        [Action Y in the FSM table],
>        - and sets the state to idle.
>
> Any start event [Event1, 3-6] is ignored in the OpenConfirm 
> state.
>
> In response to a manual stop event[Event 2] initiated by 
> the operator, the local system: 
>	- set Administrative down in MIB Reason code,
>        - sends the NOTIFICATION message with Cease, 
>	- if any BGP routes, dete the routes
>        - releases all BGP resources, 
>	- drop the transport connection, 
>        - sets the ConnectRetryCnt to zero
>        - sets the connect retry timer to zero
>        [Action S in the FSM table]
>        - transitions to Idle state.
>
> In response to the Automatic stop event initiated by the 
> system[event 7], the local system:
>        - sets the MIB entry for this peer to administratively 
>          down, 
>        - sends the NOTIFICATION message with Cease,
>	- connect retry timer reset (set to zero)
>	- If any BGP routes exist, delete the routes,
>	- release all BGP resources,
>        - drops the transport connection,
>        - increments the ConnectRetryCnt by 1, 
>        [Action C in the FSM table], and
>        - transitions to the Idle State.
>
> If the Hold Timer expires before a KEEPALIVE message is 
> received [event10], the local system:
>        - set the MIB reason to Hold time expired, 
>        - send the NOTIFICATION message with the error code 
>          set to Hold Time Expired, 
>        - resets the connect retry timer (sets the timer to to 
>          zero),
>	- releases all BGP resources, 
>        - drops the transport connection, 
>        - increments the ConnectRetryCnt by 1 
>          [Action K in the FSM table], 
>        - and sets the state to Idle.
>
>
> If the local system receives a KEEPALIVE timer expires 
> event [Event 11], the system:
>        - sends a KEEPALIVE message,
>        - restarts the Keepalive timer 
>        [Action Q the in FSM table],and 
>        - remains in Open Confirmed state.
>
> In the event of TCP establishment [Event 13], or TCP 
> connection succeeding [Event 15 or Event 16] while in Open 
> Confirm, the local system needs to track the 2nd 
> connection.  
>
> If a TCP connection is attempted to an invalid port [Event 
> 14], the local system will ignore the second connection 
> attempt.  
>
> If an OPEN message is received, all fields are check for 
> correctness.  If the BGP message header checking [Event20] 
> or OPEN message check detects an error (see Section 
> 6.2)[Event21], [the local system:
>        - sends a NOTIFICATION message with appropriate error 
>          code, 
>        - resets the connect retry timer (sets the timer to 
>          zero),
>        - releases all BGP resources, 
>        - drops the TCP connection,
>        - increments the ConnectRetryCnt by 1, 
>        - runs the BGP peer oscillation damping process [2]  
>       [Actions I, J, in the FSM table depending on the error]
>        - and goes to the Idle 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:
>        - sets the Call Collision cease in the MIB reason 
>         code,
>        - sends a Notification with a Cease 
>        - resets the Connect timer (set to zero),
>	- releases all BGP resources,
>	- Drops the TCP connection (send TCP FIN),
>	- increments the ConnectRetryCnt by 1, and
>	- performs any BGP peer oscillation damping process [2].
>	[action 
>
>
> If during the processing of another Open message, the BGP 
> implementation determines my means outside the scope of 
> this document that a connection collision has occurred and 
> this connection is to be closed, the local system will 
> issue a call collision dump [Event 22].  When the local 
> system receives a call collision dump event [Event 22], the 
> local system:
>        - Sets the MIB FSM variable to indicate collision 
>          detected and dump connection.
>        - send a NOTIFICATION with a CEASE
>        - deletes all routes associated with connection,
>        - resets the connect retry timer,
>        - releases all BGP resources
>        - drops all TCP connection,
>        - increments the ConnectRetryCnt by 1, 
>        - and performs any BGP peer oscillation damping,
>        [Action R in the FSM table],
>        - enters Idle state.
>
> In response to any other event [Events 8-9, 12, 19, 26-27], 
> the local system:
>        - sends a NOTIFICATION with a code of Finite State 
>          Machine Error,
>        - resets the connect retry timer (sets to zero)
>        - drops the TCP connection,
>        - releases all BGP resources, 
>        - increments the ConnectRetryCnt by 1, 
>        - performs any BGP peer oscillation damping,
>        [Action E in the FSM table], and 
>        - transitions to Idle state.
>
>
>Established State:
>
> In the Established state BGP can exchange UPDATE, 
> NOTFICATION, and KEEPALIVE messages with its peer.
>
> If the local system receives an UPDATE message [Event26], 
> the local system will:
>	- process the update packet
>	- restarts its Hold timer, if the negotiated Hold Time 
>          value is non-zero.
>	[Action W in the FSM table], and
>	- remain in the Established state.
>
> 
> If the local system receives a NOTIFICATION message 
> [Event23 or Event24] or a disconnect [Event17] from the 
> underlying transport protocol, it:
>	- sets the appropriate error code in MIB reason code,
>	- if any BGP routes exist, delete all BGP routes,  
>        - resets the connect retry timer (sets to zero), 
>        - releases all the BGP resources, 
>	- drops the TCP connection,
>	- increments the ConnectRetryCnt by 1, and 
>       [Action T in the FSM table]   
>	- Goes to the Idle state.
>
>
> If the local system receives a Keepalive message
> [Event 25], the local system will:
>        - restarts its Hold Timer, if the negotiated Hold Time 
>          value is non-zero.
>       [Action P in the FSM table], and
>	- remain in the Established state.
>
> If the local system receives an UPDATE message, and the 
> Update message error handling procedure (see Section 6.3) 
> detects an error [Event27], the local system:
>       - sends a NOTIFICATION message with Update error,
>       - resets the connect retry timer (sets to zero),
>       - drops the TCP connection,
>       - releases all BGP resources, 
>       - increments the ConnectRetryCnt by 1 
>       - performs any BGP peer oscillation damping
>      [Action U in FSM table], 
>       - and goes to Idle state.
>
>
> Any start event (Event 1, 3-6) is ignored in the 
> Established state.
>
> In response to a manual stop event (initiated by an 
> operator)[Event2]:
>        - sets the Administrative stop in MIB reason code, 
>	- sends the NOTIFICATION message with Cease, 
>        - if BGP routes exist, delete the BGP routes, 
>        - release BGP resources,
>	- drop TCP connection, 
>        - set ConnectRetryCnt to zero (0),
>        - reset connect retry timer to zero (0), and
>        [Action S in FSM table]
>        - transition to the Idle.
>
> In response to an automatic stop event initiated by the 
> system (automatic) [Event7], the local system:
>     - sets Administrative Stop in MIB Reason code, 
>     - sends a NOTIFICATION with Cease,
>     - resets the connect retry timer (sets to zero)
>     - deletes all routes associated with bgp peer session,
>     - releases all BGP resources, 
>     - drops the transport connection,   
>     - increments the ConnectRetryCnt by 1, 
>     - performs any BGP peer oscillation damping, and 
>     [Action C in FSM table]
>     - transitions to the idle state.
>
> An example automatic stop event is exceeding the number of 
> prefixes for a given peer and the local system 
> automatically disconnecting the peer.
>
>
> If the Hold timer expires [Event10], the local system:
>      - sends a NOTIFICATION message with Error Code Hold 
>        Timer Expired,
>      - resets the connect retry timer (sets to zero),
>      - releases all BGP resources, 
>      - drops the TCP connection, 
>      - increments the ConnectRetryCnt by 1,  
>      -	performs any BGP peer oscillation damping,
>      [Action M in FSM table] 
>      - and goes to Idle state.
>
> If the KeepAlive timer expires [Event11], the local system 
> sends a KEEPALIVE message, it restarts its KeepAlive timer, 
> unless the negotiated Hold Time value is zero [Action Q].
>
> Each time time the local system sends a KEEPALIVE or UPDATE 
> message, it restarts its KeepAlive timer, unless the 
> negotiated Hold Time value is zero.
>
>
> A transport connection indication [Event 13] received
> for a valid port will cause the 2nd connection to be
> tracked.  A transport connection indications for 
> invalid port [Event 14], will be ignored. 
> 
> In response to a Transport connection succeeds [Event 15
> 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 
> checked to see if it collides (section 6.8) with any other 
> session. If the BGP implementation determines that this 
> connection needs to be terminated, it will process an Call 
> Collision dump event[Event 22].  If this session needs to be 
> terminated, the connection will be terminated by:
>
>     - send a NOTIFICATION with a CEASE
>     - deletes all routes associated with connection,
>     - resets the connect retry timer,
>     - if any BGP routes, delete the routes,
>     - release all BGP resources, 
>     - drops the transport connection,
>     - increments ConnectRetryCnt by 1,
>     - and performs any BGP peer oscillation damping,
>    [Action R in the FSM table],
>     - and enters the Idle state
>
>
> In response to any other event [Events 8-9,12, 19-21] the 
> local system:
>     - sends a NOTIFICATION message with Error Code Finite 
>       State Machine Error,
>     - deletes all routes associated with BGP peer session, 
>     - resets the connect retry timer (sets to zero)
>     - releases all BGP resources,
>     - drops the TCP connection,
>     - increments the ConnectRetryCnt by 1, 
>     - performs any BGP peer oscillation damping, and
>     [Action E in FSM table],
>     - transitions to Idle.
>



-- 
Greg Hankins <[e-mail]> | Riverstone Networks, Inc.
Systems Engineering                       | 5200 Great America Parkway
http://www.riverstonenet.com/             | Santa Clara, CA 95054
[phone]                           | [phone]


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 MAA04894 for <[e-mail]>; Thu, 12 Sep 2002 12:10:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BFFD39128B; Thu, 12 Sep 2002 12:09:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64D2F9124A; Thu, 12 Sep 2002 12:09:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3856891245 for <[e-mail]>; Thu, 12 Sep 2002 12:09:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 243735DE7B; Thu, 12 Sep 2002 12:09:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id D1B4E5DDC7 for <[e-mail]>; Thu, 12 Sep 2002 12:09:20 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CNRX>; Thu, 12 Sep 2002 12:09:20 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: 
Date: Thu, 12 Sep 2002 12:09:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Mr. Rekhter,

In reference to:
"A NOTIFICATION message is sent when an error condition is detected."
(rfc1771)

Technically, this does not necessarily mean that when a NOTIFICATION message
is sent an error condition has been detected.  Is the intent that a
notification necessarily indicates an error?  The problem I have is that,
intuitively, A CEASE is not an error.  What I am getting at is should a peer
that received a CEASE delay the Start event?  If so, then intentional
restarts would/should exponentially delay the peering. This may be a pain,
right?

Thank you very much for your time,
-Jonathan


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA04669 for <[e-mail]>; Thu, 12 Sep 2002 12:04:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 25B7991242; Thu, 12 Sep 2002 12:04:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E583391243; Thu, 12 Sep 2002 12:04:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4546291242 for <[e-mail]>; Thu, 12 Sep 2002 12:04:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0C3635DE65; Thu, 12 Sep 2002 12:04:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 98C9F5DE43 for <[e-mail]>; Thu, 12 Sep 2002 12:04:23 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8CG4Mm52580; Thu, 12 Sep 2002 09:04:22 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Bill Fenner <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP spec and IDR WG charter 
In-Reply-To: Your message of "Fri, 06 Sep 2002 16:51:22 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 12 Sep 2002 09:04:22 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Bill,

> >1. Any reason the charter doesn't include BGP Graceful Restart ?
> >
> >2. Any reason the charter doesn't mention draft-ietf-idr-md5-keys-00.txt ?
> 
> I just modified the current charter (the one you and Sue sent me
> in November last year), which doesn't contain either of these items.
> If Graceful Restart should be in the charter, now would be an ideal time
> to add it.  (Before now would have been an even better time -- it's the
> WG chairs' responsibility to keep the charter and milestones up to date.)

Ok. We'll add it to the charter (as well as other items mentioned by Enke).
  
> I admit I made a mistake forwarding draft-ietf-idr-md5-keys to the
> IESG without it being on the WG charter.  I'll try not to make such
> mistakes in the future.

So, what is the current status on that draft ?
  
> >3. The WG completed the work on the extended communities and submitted 
> >   the draft to the IESG 3 weeks before you informed the WG
> >   about the Routing Area Directors' decision not to forward any 
> >   IDR documents for IESG considerations until the base BGP spec update 
> >   is finished.
> 
> Actually, we're going to include extended communities in the work
> that's held up.  There's something that I didn't understand about the
> IETF process until I became an AD, and although we've tried to explain
> it to some extent (e.g. Thomas and Allison's "life of an I-D" plenary
> presentation last year) it's probably still not widely understood.
> Working Groups submit documents to their ADs; the AD then reviews the
> document, possibly asks the WG for changes, and then submits it to the
> IESG for consideration.  Since I had not yet finished my review of this
> document when we made this decision, we will not be forwarding it to the
> IESG until the base spec is finished.

Ok.

On a related topic, in order for us to put specific dates in the charter
we need to know how long it would take the IESG to process BGP base
spec from the moment the WG would forward the spec to you and Alex.

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 LAA04415 for <[e-mail]>; Thu, 12 Sep 2002 11:55:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 08A8B91241; Thu, 12 Sep 2002 11:55:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C455091242; Thu, 12 Sep 2002 11:55:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A816C91241 for <[e-mail]>; Thu, 12 Sep 2002 11:55:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8FD0B5DDE2; Thu, 12 Sep 2002 11:55:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 49A5F5DDC7 for <[e-mail]>; Thu, 12 Sep 2002 11:55:23 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CNPZ>; Thu, 12 Sep 2002 11:55:19 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: NOTIFICATION message error handling.
Date: Thu, 12 Sep 2002 11:55:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Please change"
"If a peer sends a NOTIFICATION message, and there is an error in that
   message, there is unfortunately no means of reporting this error via
   a subsequent NOTIFICATION message."

To:
"If a peer receives a NOTIFICATION message, and there is an error in that
   message, there is unfortunately no means of reporting this error via
   a subsequent NOTIFICATION message."


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA03888 for <[e-mail]>; Thu, 12 Sep 2002 11:39:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9CBBC91237; Thu, 12 Sep 2002 11:39:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 688A79123E; Thu, 12 Sep 2002 11:39:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 237D591237 for <[e-mail]>; Thu, 12 Sep 2002 11:39:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0D06A5DE6F; Thu, 12 Sep 2002 11:39:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id BAD655DDE2 for <[e-mail]>; Thu, 12 Sep 2002 11:39:30 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CNN4>; Thu, 12 Sep 2002 11:39:30 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: IdleHoldtimer = 2**(ConnectRetryCnt)*60
Date: Thu, 12 Sep 2002 11:39:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

In reference to:

"Upon entering the Idle Hold state, if the IdleHoldTimer exceeds
         the local limit the "Keep Idle" flag is set."

Need to add:
"The "Keep Idle" local limit MAY be configurable", the suggested default
value is 0."

And change:

"IdleHoldtimer = 2**(ConnectRetryCnt)*60"

TO

"IdleHoldtimer = (2**(ConnectRetryCnt) - 1)*60"

Since:
1) Currently, the "Keep Idle" local is not mentioned anywhere else.

2) The current "IdleHoldtimer = 2**(ConnectRetryCnt)*60" formula makes
automated testing difficult, and may lead to some delay in correcting
configuration errors if the remote side can not be reset ("Stop event
initiated by the operator").

3) ***Current implementations accept connections right away*** (this may be
due to a "bug" in which connections are accepted in Idle (???), but this may
be another discussion).

4) Another way of achieving this, instead of defaulting the "Keep Idle"
local limit to zero (but something else about "Keep Idle" local limit needs
to be added no matter what), is to set the ConnectRetryCnt to zero when a
CEASE NOTIFICATION message is received.  But if this is done, the
IdleHoldtimer = 2**(ConnectRetryCnt)*60 should still be changed to
IdleHoldtimer = (2**(ConnectRetryCnt) - 1)*60 .

5) Also, maybe the ConnectRetryCnt should be set to zero upon becoming
established???  This eliminates the need for 4) above.



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA03576 for <[e-mail]>; Thu, 12 Sep 2002 11:30:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1F103912E1; Thu, 12 Sep 2002 11:29:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC3EC912E7; Thu, 12 Sep 2002 11:29:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6D9AE912E1 for <[e-mail]>; Thu, 12 Sep 2002 11:29:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 16C175DE6F; Thu, 12 Sep 2002 11:29:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 7FF0B5DD90 for <[e-mail]>; Thu, 12 Sep 2002 11:29:41 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8CFTZr89446; Thu, 12 Sep 2002 11:29:35 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([65.241.132.110]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g8CFTUG89437; Thu, 12 Sep 2002 11:29:30 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 12 Sep 2002 15:29:31 -0400
To: [e-mail]
From: Susan Hares <[e-mail]>
Subject: Re: IdleHold
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_3939955==_"
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

--=====================_3939955==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

Greg:

1st clarification - there is no IdleHold state in BGP.  There is
an IDLE state with sub-state like features.  Where do you find this
IdleHold state in the words I've attached?

Are we on the same document?


At 10:45 AM 9/12/2002 -0400, Greg Hankins wrote:
>I am still not convinced that IdleHold should be in the new BGP
>specification.
>
>Given that the goal of the WG is to "revise and clarify the base BGP4
>document" and to "document existing practice", I do not think that it
>should be included because this doesn't seem to be an existing practice
>(or at least one practiced by the majority of implementations).
>
>I have two questions:
>
>1. Which existing implementations support the IdleHold state, its timer
>    and flag?

***NO*** Implementation support Idle hold state.

Please refer to the hares-backoff draft for two know possibilities.
GateD by NextHop was the source of one method.  Another method is
attempting to describe cisco's back-off.   We will look to include others.
It's a "drafty" draft right now.  Please send me your favorite
persisent peer oscillation information.

>2. What existing documentation (books/courses/etc) lists IdleHold as a state
>    in the FSM?

There is no IdleHold state.  There are Idle hold features (see the
bgp draft-15 for those sub-features described.)


>If the answers to these questions are not "the majority", then it isn't
>an existing practice.  Any implementation that does not support this state
>is now automatically non-standards compliant.
>
>I suggest that this state be documented in a separate draft that addresses
>stability.

The sub-state within Idle has been moved to the backoffdraft.
We are taking this approach.  Yakov and I agree that this is a good idea.


Hope this helps.   Do give me a call if this is unclear.  Let me know
if you need the phone number.

Sue






>Greg
>
>--
>Greg Hankins <[e-mail]> | Riverstone Networks, Inc.
>Systems Engineering                       | 5200 Great America Parkway
>http://www.riverstonenet.com/             | Santa Clara, CA 95054
>[phone]                           | [phone]

--=====================_3939955==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="FSM-words-05b.txt"



Note: (this is version 5 of the changes to
       the text.) 

8.0	BGP Finite State Machine


This section specifies the BGP operation in terms of a 
Finite State Machine (FSM).  The section falls into 2 
parts:

    1)	Description of Events for the State machine (section 
        8.1
    2)	Description of the FSM (section 8.2)

Session Attributes required for each connection are; 

   1)	state
   2)	Connect Retry timer
   3)	Hold timer
   4)	Hold time
   5)	Keepalive timer

8.1 Events for the BGP FSM

8.1.1   Administrative Events (events 1-5)

Please note that only Event 1 (manual start) and Event 2 
(manual stop) are mandatory administrative events. All 
other administrative events are optional.

 Event1: Manual start 

	   Definition: Administrator manually starts peer
                       connection
	   Status: 	Mandatory

 Event2: Manual stop

	   Definition: Local system administrator manually 
                       stops the peer connection.

	   Status: 	mandatory
	   

 Event3: Automatic Start

 	   Definition: Local system automatically starts the 
                       BGP peer session

	   Status:     Optional depending on local system

 Event4: Manual start with passive Transport Establishment

	   Definition: Administrator manually start the peer
                       Connection, but has the passive flag 
                       enabled.  The passive flag indicates 
                       that the peer will listen prior to 
                       establishing the connection.

	   Status:     Optional depending on local system
		

 Event5: Automatic start with passive Transport establishment

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

	  Status:      Optional depending on local system use
		       of a passive connection.

 Event6: Automatic start with bgp_stop_flap option set

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

           Status: 	Optional, used only if the bgp peer has 
	  	        Enabled a method of damping persistent
		        BGP peer flapping.


 Event7: Auto stop

	   Definition: Local system automatically stops the
                       BGP peer session.  
	
	   Status:     Optional depending on local system


8.1.2 Timer Events (events 8-11)

 Event8:  idle Hold timer expires 

           Definition: Idle Hold timer expires.  The Idle 
                       Hold Timer is only used when persistent  
                       BGP oscillation damping functions are 
                       enabled.  

           Status: 	Optional.  Used when persistent
			BGP peer oscillation damping functions
			are enabled. 



 Event9: connect retry timer expires

           Definition: An event triggered by the expiration of 
                       the ConnectRetry timer.
  
	   Status:     Mandatory

 Event10: hold time expires

	   Definition: An event generated when the HoldTimer 
                       expires.

	   Status:     Mandatory

 Event11: keepalive timer expires

	   Definition: A periodic event generated due to the 
                       expiration of the KeepAlive Timer. 
 
	   Status:     Mandatory

 Event12: DelayBGP Open timer expires [changed]
	
	   Definition: A timer that delays sending of the BGP
	               Open message for n seconds after the
                       Transport connection has been completed. 

	   status:     Optional

8.2.3) Tranport Message based (13-16) 

 Event13: Transport Connection Indication & valid remote peer[changed]

	   Definition: Event indicating that transport
                       Request 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.


	   Status:     Mandatory

 Event14: RCV Transport Connection Indication and Invalid Source or 
          Destination [changed]

           Definition: Transport request received 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.

	    Status: 	 Mandatory
	
 Event15: Transport Connection request sent received an ACK.

           Definition: Local system's request to establish a transport
		       Connection to the remote side received
		       an ACK.


	    Status:    Mandatory

 Event16: Transport Connection Confirmed [changed]

	   Definition: The local system has received a Confirmation that
                       the transport connection has been established by
		       the remote site. 

	  Status:      Mandatory

 Event17: Transport connection fails [changed]

           Definition: This BGP peer receives a transport
		       connection failure notice.  This
		       connection notice could be caused by a
		       Transport disconnect message or a
		       Timeout in the transport session.

                       If this connection is using TCP, 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


8.1.4 BGP Messages (18-27)

 Event18: BGPOpen

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

	   Status: 	Mandatory

 Event19: BGPOpen with BGP Delay Open Timer running [changed]

           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. 

	    Status:    Optional

 Event20: BGPHeaderErr

	   Definition: BGP message header is not valid.  

	   Status:     Mandatory

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


 Event22: Open collision discard

           Definition: An event generated administratively 
                       when a connection Collision has been 
                       detected while processing an incoming  
                       Open message. This connection has been 
                       selected to disconnected.  See section 
                       6.8 for more information on collision
	               detection.  

                       Event 22 is an administrative could 
                       occur if FSM is implemented as two 
                       linked state machines.  

	  Status:      Optional

 Event23: NotifMsgVerErr

	    Definition: An event is generated when a 
                        NOTIFICIATION message with "version   
                        error" is received.

	    Status:     Mandatory

 Event24: NotifMsg

	    Definition: An event is generated when a 
                        NOTIFICATION messages is received and
                        the error code is anything but 	 
			"version error".

	     Status:	Mandatory
		        
 Event25: KeepAliveMsg

	    Definition: An event is generated when a KEEPALIVE
			Message is received.

		Status: Mandatory

 Event26: UpdateMsg

	    Definition: An event is generated when a valid 
			Update Message is received.

		Status: Mandatory

 Event27: UpdateMsgErr

	    Definition: An event is generated when an invalid
			Update message is received.

		Status:	Mandatory

 
8.2) Description of FSM


Idle state

   Initially BGP is in the Idle state.   

   In this state BGP refuses all incoming BGP connections.  No 
   resources are allocated to the peer.    In response to a 
   manual start event(Event1) or an automatic start 
   event(Event3), the local system 
      -	initializes all BGP resources, 
      -	sets the Connect retry counter to zero
      -	starts the ConnectRetry timer with initial value, 
      -	initiates a transport connection to the other BGP 
        peer, 
      -	listens for a connection that may be initiated by 
        the remote BGP peer, and
        [Action A in the FSM table]
      -	changes its state to connect.

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

  In response to a manual start event with the passive Transport
  flag (Event 4) or automatic start with the passive Transport flag 
  (Event 5), the local system:
      -	initializes all BGP resources,
      -	sets the connect retry count to zero,
      -	start the Connect Retry timer with initial value, 
      -	listens for a connection that may be initiated by 
        the remote peer
        [Action B in the FSM table] 
      -	changes its state to Active.

  The exact value of the ConnectRetry timer is a local 
  matter, but it should be sufficiently large to allow TCP 
  initialization.   

  If a persistent BGP peer oscillation damping function is 
  enabled, two additional events may occur within Idle state:  
      -	Automatic start with bgp_stop_flap set [Event6],
      -	Idle Hold Timer expired [Event 8].

  The method of preventing persistent BGP peer oscillation is 
  outside the scope of this document.

  Any other events [Events 9-27] received in the Idle state, 
  are noted by the MIB processing as FSM Errors [action V]
  and the local peer stays in the Idle State.


Connect State:

  In this state, BGP is waiting for the transport protocol 
  connection to be completed.

  If the transport 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: 
     -	clears the ConnectRetry timer, 
     -	set the BGP Open Delay timer to the initial 
        value.
        [Action ZZ in FSM table]

  If the Delay Open flag is not set, the local system: 
     - clears the ConnectRetry timer, 
     - completes BGP initialization
     - send an Open message to its peer,
     - sets Hold timer to a large value,
     - Change the state to Open Sent 
   [Action H in the FSM table]

  A hold timer value of 4 minutes is suggested.

  If the Open Delay timer expires [Event 12] in the connect 
  state,
     - send an Open message to its peer,
     - set the Hold timer to a large value,
	[Action H in the FSM Table], and
     - change the state to Open Sent. 

  If the BGP port receives a Transport connection indication 
  [Event 13], the Transport connection is processed (actions AA or
  AB in the FSM table) and the connection remains
  in the connected state. 

  If the transport connection receives an Transport indication
  that is invalid or unconfigured. [Event 14]:
     - the transport connection is rejected.
	[Action L in the FSM table]

  If the transport connection fails (timeout or transport
  disconnect) [Event17], the local system:
      - restarts the ConnectRetry timer, 
      - continues to listen for a connection that may be 
        initiated by the remote BGP peer, and
     [Action G in the FSM table]
      - changes its state to Active. 


  If an Open is received with the BGP Delay Open timer is 
  running [Event 19], the local system:
	- clears the connect retry timer (cleared to zero),
	- completes the BGP initialization, 
	- Stops and clears the BGP Open Delay timer
	- Sends an Open message

	[Action H in the FSM table], and
	- changes its state to Open Confirm.


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

 A manual stop event[Event2], the local system:
       - drops the transport connection, 
       - releases all BGP resources,
       - sets connect retry count to zero
       - resets the connect retry timer (sets to zero)
      [Action Z in the FSM table]
       - goes to Idle state.

  In response to the ConnectRetry timer expired event(Event 
  9), the local system: 
      - Sets the MIB FSM error information with ConnectRetry 
        expired, 
      - drops the transport connection 
      - restarts the ConnectRetry timer
      - initiates a transport connection to the other BGP 
        peer, 
      - continues to listen for a connection that may be 
        initiated by the remote BGP peer, and
      [Action O in the FSM table]
      - stays in Connect state.

 In response to any other events [Events 7-8, 10-11, 18, 20-
 27] the local system:
     - resets the connect retry timer (sets to zero),
     - drops the Transport connection,
     - release all BGP resources, 
     - increments the ConnectRetryCnt by 1,
     - [optionally] performs bgp peer oscillation damping, and
     [Action D in the FSM table],
     - goes to Idle state.


Active State:

 In this state BGP is trying to acquire a peer by listening 
 for and accepting a transport protocol connection.  

 A transport connection succeeds [Event 15 or Event 16], the 
 local system: process the transport connection flags
	- If the BGP delay open flag is set:
          o clears the ConnectRetry timer, 
          o completes the BGP initialization,
          o sets the BGP delay Open timer
         [Action ZZ]

        - If the BGP delay open flag is not set:
          o clears the ConnectRetry timer,
          o completes the BGP initialization, 
          o sends the Open message to it's peer, 
          o sets its Hold timer to a large value, 
         [Action H in the FSM table]
          and changes its state to OpenSent.  

 A Hold timer value of 4 minutes is suggested.  

 If the local system receives a valid Transport Indication
 [Event 13], the local system processes the Transport flags
  (actions aa or ab in FSM section 2.3.4).  

 If the local system receives a Transport indication
 that is invalid for this connection [Event 14]:
      - the transport connection is rejected
        [Action L in the FSM table]

 If the local system receives a Transport connection
 failed [Event 17] (timeout or receives Transport
 disconnect), the local system will:
	- set Transport disconnect in the MIB reason code,
	- restart ConnectRetry timer (with initial value)
	- release all BGP resources
	- Acknowledge the drop of Transport connection if
          transport disconnect (If TCP, send a FIN ACK),
	- Increment ConnectRetryCnt by 1,
	- perform the BGP peer oscillation damping process [2]
	[Action Y in the FSM table]

 If the local system has the Delay Open timer expired [event 
 12] local system: 
        - clears the Connect Retry timer (set to zero),
	- stops and clears the Delay Open timer (set to zero) 
        - completes the BGP initialization,
        - sends the Open message to it's remote peer,
        - sets it's Hold timer to a large value,
        [Action H in the FSM table]
        - and set the state to Open Confirm.

 A Hold timer value of 4 minutes is also suggested for this 
 state transition.

 If an Open is received with the BGP Delay Open timer is 
 running [Event 19], the local system 
	- clears the connect retry timer (cleared to zero),
	- Stops and clears the BGP Open Delay timer  
	- completes the BGP initialization, 
	- Stops and clears the BGP Open Delay timer
	- Sends an Open message
	- Set the Hold timer to a large value (4 minutes),
	[Action H in the FSM table], and
	- changes its state to Open Confirm.


 In response the ConnectRetry timer expired event[Event9], 
 the local system:
        - restarts the ConnectRetry timer (with initial value),
        - initiates a transport connection to the other BGP 
          peer,
        - Continues to listen for transport connection that may be 
          initiated by remote BGP peer, 
        [Action F in the FSM table]
	- and changes its state to Connect.  


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

 A manual stop event[Event2], the local system:
        - Sets the administrative down in the MIB reason code,
	- Sends a notification with a Cease,
	- If any BGP routes exist, delete the routes
	- release all BGP resources, 
	- drops the Transport connection, 
        - sets connect retry count to zero
        - resets the connect retry timer (sets to zero)
        [Action S in the FSM table]
        - goes to Idle state.

 In response to any other event (Events 7-8, 10-11,18, 20-
 27), the local system:
        - stores the MIB information to indicate appropriate 
          error [FSM for Events 7-8, 10-11, 18, 20-27]
        - reset the connect retry timer (sets to zero),
        - release all BGP resources, 
	- drops the transport connection, 
        - increments the ConnectRetryCnt by one,
        - optionally performs BGP peer oscillation damping, 
  	  [Action D in FSM table],
	- and goes to the idle state


Open Sent:

 In this state BGP waits for an Open Message from its peer.  

 When an OPEN message is received, all fields are checked 
 for correctness.  If there are no errors in the OPEN message 
 [Event 18] the local system:
       - resets the BGP Delay timer to zero,
       - reset BGP Connect Timer to zero, 
       - sends a KEEPALIVE message and
       - sets a KeepAlive timer (via the text below)
       - sets the Hold timer according to the negotiated value 
         (see section 4.2), and 
         [Action N in the FSM table]
       - sets the state to Open Confirm.


 If the negotiated Hold time value is zero, then the Hold 
 Time timer and KeepAlive timers are not started.   If the 
 value of the Autonomous System field is the same as the 
 local Autonomous System number, then the connection is an 
 "internal" connection; otherwise, it is an "external" 
 connection.   (This will impact UPDATE processing as 
 described below.)  


 If the BGP message header checking [Event20] or OPEN message
 check detects an error (see Section 6.2)[Event21], the local system:
       - sends a NOTIFICATION message with appropriate error 
         code, 
       - reset the connect retry timer (sets to zero),
       - if there are any routes associated with the BGP session,
	 delete these routes
       - release all BGP resources,
       - drop the transport session 
       - increments the ConnectRetryCnt by 1, 
       - bgp peer oscillation damping process,  
       [Actions I, J in FSM table, depending on error],
       - and goes to the Idle state.

 Collision detection mechanisms (section 6.8) need to be 
 applied when a valid BGP Open is received [Event 18 or 
 Event 19].  Please refer to section 6.8 for the details of 
 the comparison. An administrative collision detect is when 
 BGP implementation determines my means outside the scope of 
 this document that a connection collision has occurred.   

 If a connection in Open Sent is determined to be the 
 connection that must be closed, an administrative collision 
 detect [Event 22] is signaled to the state machine. If such 
 an administrative collision detect dump [Event 22] is 
 received in Open Sent, the local system:  
       - sets MIB state information to 
         collision detect closure, 
       - send a NOTIFICATION with a CEASE
       - resets the connect retry timer,
       - release all BGP resources,
       - drop the transport connection,
       - increments ConnectRetryCnt by 1,
       - performs any BGP peer oscillation damp process, and
       [Action R in the FSM],
       - enters Idle state.


  If a NOTIFICATION message is received with a version 
  error[Event23], Notification message without version number 
  [Event 24], the local system: 
       - resets the connect retry timer (sets to zero)
       - drops the Transport connection,
       - releases all BGP resources, 
       - increments the ConnectRetryCnt by 1
       - process any BGP peer oscillation damping,
	[Action Y]  
       - and sets the state to Idle.


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

  If a manual stop event [Event 2] is issued in Open sent 
 state, the local system:
	- Sets administrative down reason in MIB reason,
	- sends the Notification with a cease,
	- if BGP routes exists, delete the routes,
	- Release all BGP resources, 
	- Drops the Transport connection, 
	- set ConnectRetryCnt to zero, 
	- resets the Connect Retry timer (set to zero),
	[Action S in the FSM table], and
	- transitions to the Idle state.

  If an automatic stop event [Event 7] is issued in Open sent 
  state, the local system:
	- Sets administrative down reason in MIB reason,
	- sends the Notification with a cease,
	- if any routes are associated with te BGP session,
	  delete the routes, 
	- release all the BGP resources
	- Drops the Transport connection, 
	- increments the ConnectRetryCnt by 1, 
	- BGP peer oscillation process [2]
	[Action C in the FSM table], and
	- transitions to the Idle state.

 If the Hold Timer expires[Event 10], the local system:
       - set Hold timer expired in MIB Error reason code, 
       - send a NOTIFICATION message with error code Hold 
         Timer Expired,
       - reset the connect retry timer (sets to zero),
       - releases all BGP resources,
       - drops the Transport connection, 
       - increments the ConnectRetryCnt by 1
         [Action K in the FSM table], and
	- transitions to the Idle state.


 If a transport indication is received for valid connection 
 [Event 13] or transport Request Acknowledgement [Event 15]
 is received, or a transport connect confirm [Event 16] is
 received a second TCP session may be in progress.  This
 second TCP session is tracked per the Call Collision 
 processing (section 6.8) until an OPEN message is received.

 A TCP connection for an invalid port [Event 14] is ignored. 

 If a Transport Failure [Event17], is received from the 
 underlying transport protocol, the local system:
       - closes the BGP connection, 
       - restarts the Connect Retry timer, 
       - and continues to listen for a connection that may be 
         initiated by the remote BGP peer,
       [Action O in the FSM table]
       - and goes into Active state.


 In response to any other event [Events 8-9, 11-12, 19, 25-27], 
  the local system:
	- sends the NOTIFICATION with the Error Code Finite 
          state machine error,
        - resets the connect retry timer (sets to zero),
	- releases all BGP resources
        - drops the Transport connection, 
        - increments the ConnectRetryCnt by 1, 
        - process any bgp peer oscillation damping[2] 
        [Action E in the FSM table],
        - and sets the state to idle.


Open Confirm State

 In this state BGP waits for a KEEPALIVE or NOTIFICATION 
 message.

 If the local system receives a KEEPALIVE message[Event 25], 
        - restarts the Hold timer, 
          [Action P in the FSM table], and
        - changes its state to Established. 


 If the local system receives a NOTIFICATION message [event 
 23-24] or receives a TCP Disconnect [event 17] from the 
 underlying transport protocol, the local system:  
        - sets the appropriate MIB information for FSM error, 
        - resets the connect retry timer (sets the timer to 
          zero),
	- releases all BGP resources, 
        - drops the TCP connection,
        - increments the ConnectRetryCnt by 1, 
        [Action Y in the FSM table],
        - and sets the state to idle.

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

 In response to a manual stop event[Event 2] initiated by 
 the operator, the local system: 
	- set Administrative down in MIB Reason code,
        - sends the NOTIFICATION message with Cease, 
	- if any BGP routes, dete the routes
        - releases all BGP resources, 
	- drop the transport connection, 
        - sets the ConnectRetryCnt to zero
        - sets the connect retry timer to zero
        [Action S in the FSM table]
        - transitions to Idle state.

 In response to the Automatic stop event initiated by the 
 system[event 7], the local system:
        - sets the MIB entry for this peer to administratively 
          down, 
        - sends the NOTIFICATION message with Cease,
	- connect retry timer reset (set to zero)
	- If any BGP routes exist, delete the routes,
	- release all BGP resources,
        - drops the transport connection,
        - increments the ConnectRetryCnt by 1, 
        [Action C in the FSM table], and
        - transitions to the Idle State.

 If the Hold Timer expires before a KEEPALIVE message is 
 received [event10], the local system:
        - set the MIB reason to Hold time expired, 
        - send the NOTIFICATION message with the error code 
          set to Hold Time Expired, 
        - resets the connect retry timer (sets the timer to to 
          zero),
	- releases all BGP resources, 
        - drops the transport connection, 
        - increments the ConnectRetryCnt by 1 
          [Action K in the FSM table], 
        - and sets the state to Idle.


 If the local system receives a KEEPALIVE timer expires 
 event [Event 11], the system:
        - sends a KEEPALIVE message,
        - restarts the Keepalive timer 
        [Action Q the in FSM table],and 
        - remains in Open Confirmed state.

 In the event of TCP establishment [Event 13], or TCP 
 connection succeeding [Event 15 or Event 16] while in Open 
 Confirm, the local system needs to track the 2nd 
 connection.  

 If a TCP connection is attempted to an invalid port [Event 
 14], the local system will ignore the second connection 
 attempt.  

 If an OPEN message is received, all fields are check for 
 correctness.  If the BGP message header checking [Event20] 
 or OPEN message check detects an error (see Section 
 6.2)[Event21], [the local system:
        - sends a NOTIFICATION message with appropriate error 
          code, 
        - resets the connect retry timer (sets the timer to 
          zero),
        - releases all BGP resources, 
        - drops the TCP connection,
        - increments the ConnectRetryCnt by 1, 
        - runs the BGP peer oscillation damping process [2]  
       [Actions I, J, in the FSM table depending on the error]
        - and goes to the Idle 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:
        - sets the Call Collision cease in the MIB reason 
         code,
        - sends a Notification with a Cease 
        - resets the Connect timer (set to zero),
	- releases all BGP resources,
	- Drops the TCP connection (send TCP FIN),
	- increments the ConnectRetryCnt by 1, and
	- performs any BGP peer oscillation damping process [2].
	[action 


 If during the processing of another Open message, the BGP 
 implementation determines my means outside the scope of 
 this document that a connection collision has occurred and 
 this connection is to be closed, the local system will 
 issue a call collision dump [Event 22].  When the local 
 system receives a call collision dump event [Event 22], the 
 local system:
        - Sets the MIB FSM variable to indicate collision 
          detected and dump connection.
        - send a NOTIFICATION with a CEASE
        - deletes all routes associated with connection,
        - resets the connect retry timer,
        - releases all BGP resources
        - drops all TCP connection,
        - increments the ConnectRetryCnt by 1, 
        - and performs any BGP peer oscillation damping,
        [Action R in the FSM table],
        - enters Idle state.

 In response to any other event [Events 8-9, 12, 19, 26-27], 
 the local system:
        - sends a NOTIFICATION with a code of Finite State 
          Machine Error,
        - resets the connect retry timer (sets to zero)
        - drops the TCP connection,
        - releases all BGP resources, 
        - increments the ConnectRetryCnt by 1, 
        - performs any BGP peer oscillation damping,
        [Action E in the FSM table], and 
        - transitions to Idle state.


Established State:

 In the Established state BGP can exchange UPDATE, 
 NOTFICATION, and KEEPALIVE messages with its peer.

 If the local system receives an UPDATE message [Event26], 
 the local system will:
	- process the update packet
	- restarts its Hold timer, if the negotiated Hold Time 
          value is non-zero.
	[Action W in the FSM table], and
	- remain in the Established state.

 
 If the local system receives a NOTIFICATION message 
 [Event23 or Event24] or a disconnect [Event17] from the 
 underlying transport protocol, it:
	- sets the appropriate error code in MIB reason code,
	- if any BGP routes exist, delete all BGP routes,  
        - resets the connect retry timer (sets to zero), 
        - releases all the BGP resources, 
	- drops the TCP connection,
	- increments the ConnectRetryCnt by 1, and 
       [Action T in the FSM table]   
	- Goes to the Idle state.


 If the local system receives a Keepalive message
 [Event 25], the local system will:
        - restarts its Hold Timer, if the negotiated Hold Time 
          value is non-zero.
       [Action P in the FSM table], and
	- remain in the Established state.

 If the local system receives an UPDATE message, and the 
 Update message error handling procedure (see Section 6.3) 
 detects an error [Event27], the local system:
       - sends a NOTIFICATION message with Update error,
       - resets the connect retry timer (sets to zero),
       - drops the TCP connection,
       - releases all BGP resources, 
       - increments the ConnectRetryCnt by 1 
       - performs any BGP peer oscillation damping
      [Action U in FSM table], 
       - and goes to Idle state.


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

 In response to a manual stop event (initiated by an 
 operator)[Event2]:
        - sets the Administrative stop in MIB reason code, 
	- sends the NOTIFICATION message with Cease, 
        - if BGP routes exist, delete the BGP routes, 
        - release BGP resources,
	- drop TCP connection, 
        - set ConnectRetryCnt to zero (0),
        - reset connect retry timer to zero (0), and
        [Action S in FSM table]
        - transition to the Idle.

 In response to an automatic stop event initiated by the 
 system (automatic) [Event7], the local system:
     - sets Administrative Stop in MIB Reason code, 
     - sends a NOTIFICATION with Cease,
     - resets the connect retry timer (sets to zero)
     - deletes all routes associated with bgp peer session,
     - releases all BGP resources, 
     - drops the transport connection,   
     - increments the ConnectRetryCnt by 1, 
     - performs any BGP peer oscillation damping, and 
     [Action C in FSM table]
     - transitions to the idle state.

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


 If the Hold timer expires [Event10], the local system:
      - sends a NOTIFICATION message with Error Code Hold 
        Timer Expired,
      - resets the connect retry timer (sets to zero),
      - releases all BGP resources, 
      - drops the TCP connection, 
      - increments the ConnectRetryCnt by 1,  
      -	performs any BGP peer oscillation damping,
      [Action M in FSM table] 
      - and goes to Idle state.

 If the KeepAlive timer expires [Event11], the local system 
 sends a KEEPALIVE message, it restarts its KeepAlive timer, 
 unless the negotiated Hold Time value is zero [Action Q].

 Each time time the local system sends a KEEPALIVE or UPDATE 
 message, it restarts its KeepAlive timer, unless the 
 negotiated Hold Time value is zero.


 A transport connection indication [Event 13] received
 for a valid port will cause the 2nd connection to be
 tracked.  A transport connection indications for 
 invalid port [Event 14], will be ignored. 
 
 In response to a Transport connection succeeds [Event 15
 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 
 checked to see if it collides (section 6.8) with any other 
 session. If the BGP implementation determines that this 
 connection needs to be terminated, it will process an Call 
 Collision dump event[Event 22].  If this session needs to be 
 terminated, the connection will be terminated by:

     - send a NOTIFICATION with a CEASE
     - deletes all routes associated with connection,
     - resets the connect retry timer,
     - if any BGP routes, delete the routes,
     - release all BGP resources, 
     - drops the transport connection,
     - increments ConnectRetryCnt by 1,
     - and performs any BGP peer oscillation damping,
    [Action R in the FSM table],
     - and enters the Idle state


 In response to any other event [Events 8-9,12, 19-21] the 
 local system:
     - sends a NOTIFICATION message with Error Code Finite 
       State Machine Error,
     - deletes all routes associated with BGP peer session, 
     - resets the connect retry timer (sets to zero)
     - releases all BGP resources,
     - drops the TCP connection,
     - increments the ConnectRetryCnt by 1, 
     - performs any BGP peer oscillation damping, and
     [Action E in FSM table],
     - transitions to Idle.


--=====================_3939955==_
Content-Type: text/plain; charset="us-ascii"; format=flowed


--=====================_3939955==_--



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA03226 for <[e-mail]>; Thu, 12 Sep 2002 11:20:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1AAD5912DE; Thu, 12 Sep 2002 11:19:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D6250912E1; Thu, 12 Sep 2002 11:19:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CEAA3912DE for <[e-mail]>; Thu, 12 Sep 2002 11:19:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A3FA65DE6F; Thu, 12 Sep 2002 11:19:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by segue.merit.edu (Postfix) with ESMTP id EE2CC5DD90 for <[e-mail]>; Thu, 12 Sep 2002 11:19:53 -0400 (EDT)
Received: from Bemail06.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g8CFDeH28423; Thu, 12 Sep 2002 17:13:40 +0200
Received: from alcatel.be ([138.203.191.116]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002091217192618:6364 ; Thu, 12 Sep 2002 17:19:26 +0200 
Message-ID: <[e-mail]>
Date: Thu, 12 Sep 2002 17:19:22 +0200
From: [e-mail]
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 09/12/2002 17:19:26, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 09/12/2002 17:19:28, Serialize complete at 09/12/2002 17:19:28
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

I tend to agree with this.
please note that EGP is still not depreciated as such (RFC904 is still not
overruled!)

Hans De Vleeschouwer
Alcatel.

Jeffrey Haas wrote:

> On Wed, Sep 11, 2002 at 06:17:27PM -0400, Curtis Villamizar wrote:
> > We might want to say the value EGP in the ORIGIN field (which does
> > mean the EGP protocol, not any EGP type protocol) is depricated since
> > the EGP protocol has been moved to historic but retain the value to
> > document what it used to mean.
>
> I would ask us to consider carefully before deprecating it.
> While no longer used (from what I've seen or heard) as the origin
> of the route being from the EGP protocol, people *are* using it in
> their route-maps to bias route selection.
>
> --
> 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 LAA02910 for <[e-mail]>; Thu, 12 Sep 2002 11:10:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 44FE2912DC; Thu, 12 Sep 2002 11:09:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 07D88912EF; Thu, 12 Sep 2002 11:09:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 41511912DC for <[e-mail]>; Thu, 12 Sep 2002 11:09:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 301045DE70; Thu, 12 Sep 2002 11:09:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id C74BC5DE6F for <[e-mail]>; Thu, 12 Sep 2002 11:09:11 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CNJH>; Thu, 12 Sep 2002 11:09:11 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: "ConnectRetryCnt to zero"
Date: Thu, 12 Sep 2002 11:09:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Please pick one and stick with it:
"ConnectRetryCnt to zero"
"ConnectRetryCnt = 0"


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 KAA02220 for <[e-mail]>; Thu, 12 Sep 2002 10:50:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9385991290; Thu, 12 Sep 2002 10:49:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D88A912D2; Thu, 12 Sep 2002 10:49:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76EC091290 for <[e-mail]>; Thu, 12 Sep 2002 10:48:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5BFBA5DE20; Thu, 12 Sep 2002 10:48:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id A2E7B5DD90 for <[e-mail]>; Thu, 12 Sep 2002 10:48:07 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8CEln688213; Thu, 12 Sep 2002 10:47:49 -0400 (EDT) (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 g8CElkG88206; Thu, 12 Sep 2002 10:47:47 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8CElkB08075; Thu, 12 Sep 2002 10:47:46 -0400 (EDT)
Date: Thu, 12 Sep 2002 10:47:46 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.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 Wed, Sep 11, 2002 at 06:17:27PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 11, 2002 at 06:17:27PM -0400, Curtis Villamizar wrote:
> We might want to say the value EGP in the ORIGIN field (which does
> mean the EGP protocol, not any EGP type protocol) is depricated since
> the EGP protocol has been moved to historic but retain the value to
> document what it used to mean.

I would ask us to consider carefully before deprecating it.
While no longer used (from what I've seen or heard) as the origin
of the route being from the EGP protocol, people *are* using it in
their route-maps to bias route selection.

-- 
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 KAA02123 for <[e-mail]>; Thu, 12 Sep 2002 10:46:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 28CF49128B; Thu, 12 Sep 2002 10:45:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D601F9128E; Thu, 12 Sep 2002 10:45:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EA7F59128B for <[e-mail]>; Thu, 12 Sep 2002 10:45:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D42805DE20; Thu, 12 Sep 2002 10:45:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by segue.merit.edu (Postfix) with ESMTP id 800405DD90 for <[e-mail]>; Thu, 12 Sep 2002 10:45:35 -0400 (EDT)
Received: from doom.twoguys.org by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id HAA28574; Thu, 12 Sep 2002 07:45:34 -0700 (PDT)
Received: (from ghankins@localhost) by doom.twoguys.org (8.11.6/8.11.6) id g8CEjVk10100 for [e-mail]; Thu, 12 Sep 2002 10:45:31 -0400
Date: Thu, 12 Sep 2002 10:45:31 -0400
From: Greg Hankins <[e-mail]>
To: [e-mail]
Subject: IdleHold
Message-ID: <[e-mail]>
Reply-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Mailer: Mutt 1.2.5.1i
Sender: [e-mail]
Precedence: bulk

I am still not convinced that IdleHold should be in the new BGP
specification.

Given that the goal of the WG is to "revise and clarify the base BGP4
document" and to "document existing practice", I do not think that it
should be included because this doesn't seem to be an existing practice
(or at least one practiced by the majority of implementations).

I have two questions:

1. Which existing implementations support the IdleHold state, its timer
   and flag?

2. What existing documentation (books/courses/etc) lists IdleHold as a state
   in the FSM?

If the answers to these questions are not "the majority", then it isn't
an existing practice.  Any implementation that does not support this state
is now automatically non-standards compliant.

I suggest that this state be documented in a separate draft that addresses
stability.

Greg

-- 
Greg Hankins <[e-mail]> | Riverstone Networks, Inc.
Systems Engineering                       | 5200 Great America Parkway
http://www.riverstonenet.com/             | Santa Clara, CA 95054
[phone]                           | [phone]


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA01910 for <[e-mail]>; Thu, 12 Sep 2002 10:39:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6594B9128C; Thu, 12 Sep 2002 10:36:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26DC091290; Thu, 12 Sep 2002 10:36:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1DBD89128C for <[e-mail]>; Thu, 12 Sep 2002 10:36:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 07F665DE20; Thu, 12 Sep 2002 10:36:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mail.alcatel.be (alc250.alcatel.be [195.207.101.250]) by segue.merit.edu (Postfix) with ESMTP id 0BC115DD90 for <[e-mail]>; Thu, 12 Sep 2002 10:36:51 -0400 (EDT)
Received: from Bemail06.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id g8CEUwC09779 for <[e-mail]>; Thu, 12 Sep 2002 16:30:58 +0200
Received: from alcatel.be ([138.203.191.116]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002091216364441:5971 ; Thu, 12 Sep 2002 16:36:44 +0200 
Message-ID: <[e-mail]>
Date: Thu, 12 Sep 2002 16:36:40 +0200
From: [e-mail]
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: BGP mailing list <[e-mail]>
Subject: problem in collision strategy?
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 09/12/2002 16:36:44, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 09/12/2002 16:36:46, Serialize complete at 09/12/2002 16:36:46
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
hi,
<p>recently we encountered a race condition&nbsp; with&nbsp; the collision
detection strategy, which i would like to bring the the attention of the
people working on the new BGP draft for BGP.
<p>The root of the problem seems to be&nbsp; related in the interface between
the TCP layer and BGP layer: when is an event received by the TCP handled
by the BGP?
<p>The situation is described below. It sounds pretty strange, however
it did occur! It took about 100 attempts and sometimes much more to get
out of it.&nbsp; And as&nbsp; far as I can see, nothing happened outside
of the current state machine description, i.e. the currewnt BGP state machine
allowed this to happen.
<p>Regrads,
<br>&nbsp; Hans De Vleeschouwer.
<br>&nbsp;
<p>(in the scenario below time progresses downwards)
<br>&nbsp;
<p><tt>+---------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+---------------+</tt>
<br><tt>! BGP speaker A !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
! BGP speaker B !</tt>
<br><tt>! 10.10.10.10&nbsp;&nbsp; !------------------+ 10.10.11.11&nbsp;&nbsp;
!</tt>
<br><tt>!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</tt>
<br><tt>+---------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+---------------+</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Setup TCP connection 1!</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !===============================>!</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</tt>
<p><tt>BGP speaker 1 initiates a TCP connection towards speaker2</tt>
<br><tt>This action is successfull.</tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp; OPEN
for connection 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !===============================>!</tt>
<p><tt>Speaker 1 being informed that the TCP is up, sends an OPEN</tt>
<br><tt>message for the connection he initiated. The OPEN message</tt>
<br><tt>is NOT yet treated by speaker 2. (probably speaker 2 is not</tt>
<br><tt>yet aware of the connection because he did not check the TCP</tt>
<br><tt>events ).</tt>
<p><tt>The states in BGP are:</tt>
<br><tt>&nbsp;Connection 1: Open Sent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection 1: idle?</tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp; Setup TCP
connection 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&lt;================================!</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</tt>
<p><tt>At this stage, speaker 2 also sets up a TCP connection to speaker
A</tt>
<br><tt>(this happens before the BGP application of speaker 2 is</tt>
<br><tt>aware of the connection of speaker 1).</tt>
<br>&nbsp;
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OPEN for connection 2&nbsp;&nbsp;&nbsp;&nbsp; !</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !================================>!</tt>
<p><tt>Now BGP speaker 1, being informed of a new connection immediatelly</tt>
<br><tt>sends an OPEN message. On Speaker 2 we have either a slow TCP,
a slow BGP</tt>
<br><tt>or a slow link in between (actually it was a test tool, so I do
not know</tt>
<br><tt>really).but in any case it seems that the BGP states now became:</tt>
<p><tt>The states in BGP are:</tt>
<br><tt>&nbsp;Connection 1: Open Sent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection 1: idle?</tt>
<br><tt>&nbsp;Connection 1: Open Sent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection 2: idle?</tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OPEN for connection 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&lt;==================================!</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
!</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
KEEPALIVE for connection 1 !</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !==================================>!</tt>
<p><tt>BGP speaker 2 'wakes up' and responds to connection 1. BGP speaker
1</tt>
<br><tt>who is reacting alert, sends a KEEPALIVE for connection 1</tt>
<br><tt>The states in BGP are:</tt>
<br><tt>&nbsp;Connection 1: Open confirm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection 1: see below</tt>
<br><tt>&nbsp;COnnection 1: Open Sent&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection 2: ?</tt>
<p><tt>AT this stage, the collision detection mechanism starts in BGP</tt>
<br><tt>speaker 1. Since BGP speaker 2 has the highest id, speaker 1 decides</tt>
<br><tt>to tear down his original TCP connection (connection 1).</tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp; KEEPALIVE for
connection 1&nbsp;&nbsp; !</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&lt;===============================!</tt>
<br><tt>&nbsp; Connection 1: gone</tt>
<br><tt>&nbsp; COnnection 2 : Open Sent</tt>
<p><tt>In the mean time BGP speaker 2, not being aware of the fact that</tt>
<br><tt>speaker 1 closed the connection 1 wakes up again, and receives
the</tt>
<br><tt>keealive from speaker 1 , sends back a keepalive and bring the</tt>
<br><tt>connection 1 in establsihed state.(note that on this keepalive
will be</tt>
<br><tt>lost, as the connection is closed.</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection 1: established</tt><tt></tt>
<p><tt>Also at this moment, BGP speaker 2 notices that connection 2 is
up</tt>
<br><tt>and sends an OPEN mesage for connection 2, and trasitions to OPEN
SENT</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Connection 2: OPEN sent.</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OPEN for connection 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; !&lt;====================================!</tt><tt></tt>
<p><tt>BGP speaker 2 then treats the OPEN mesage from speaker 1 (which
arrived</tt>
<br><tt>quite some time ago, but was not treated until now).</tt>
<br><tt>for connection 2.</tt><tt></tt>
<p><tt>This triggers the collision detection in speaker 2. As he still</tt>
<br><tt>believes that connection 1 is established, he decides to close
the connection 2</tt><tt></tt>
<p><tt>The end result is that both connection are cleared.</tt>
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;</html>



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA00418 for <[e-mail]>; Thu, 12 Sep 2002 09:59:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8C6809127C; Thu, 12 Sep 2002 09:58:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E1F291288; Thu, 12 Sep 2002 09:58:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 153319127C for <[e-mail]>; Thu, 12 Sep 2002 09:58:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DF9E05DDE6; Thu, 12 Sep 2002 09:58:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 9AFBA5DD90 for <[e-mail]>; Thu, 12 Sep 2002 09:58:39 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CM0L>; Thu, 12 Sep 2002 09:58:39 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: Goes to IdleHoldstate
Date: Thu, 12 Sep 2002 09:58:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25A64.7EA64310"
Sender: [e-mail]
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C25A64.7EA64310
Content-Type: text/plain

Please change "Goes to IdleHoldstate" to Goes to IdleHold state".


------_=_NextPart_001_01C25A64.7EA64310
Content-Type: text/html

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">


<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Please change "Goes to IdleHoldstate" to Goes to
IdleHold state".</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C25A64.7EA64310--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA03633 for <[e-mail]>; Wed, 11 Sep 2002 20:42:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0314191354; Wed, 11 Sep 2002 20:42:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C243C913D7; Wed, 11 Sep 2002 20:42:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 75DA191354 for <[e-mail]>; Wed, 11 Sep 2002 20:42:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5FC8F5DE29; Wed, 11 Sep 2002 20:42:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from laptoy770.fictitious.org (unknown [209.150.1.238]) by segue.merit.edu (Postfix) with ESMTP id 28FBD5DD8C for <[e-mail]>; Wed, 11 Sep 2002 20:42:27 -0400 (EDT)
Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.11.2/8.11.2) with ESMTP id g8C0h5X43358; Wed, 11 Sep 2002 20:43:06 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-reply-to: Your message of "Wed, 11 Sep 2002 14:14:17 EDT." <[e-mail]> 
Date: Wed, 11 Sep 2002 20:43:05 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> 
> Wishfull thinking is how things get started. Otherwise
> no one ever knows that there is a better way to do something. I am not
> suggesting it be done now, but maybe in the future. Perhaps they should
> be kept as future things. 
> 
> Ben



Ben,

This is an IETF WG mailing list.  We are trying to accomplish a
specific task.  That is updating the BGP protocol spec.  Things that
are out of bounds for change have been clearly and repeatedly stated.

You are consistently wasting the time of hundreds if not thousands of
people reading this list and the dozen or more that are currently
active on this list.  Please use the list to comment on the BGP spec
within the bounds of what we reasonably can be expected to change and
the bounds that the WG chairs have already stated.

Curtis


ps - The WG chairs, ADs, or others can chime in but IMHO the bounds,
stated in part in prior messages, should be the following.

  1) If the document is incorrect, incomplete, or ambiguous, it has a
     flaw and needs to be changed.  Changing the protocol itself,
     except to reflect current implementation of multiple vendors, is
     out of bounds.  [under that assumption that by now we've made the
     implmentations work].  Changes to reflect a single vendor's
     idiosyncracies are out of bounds, particularly if no
     interoperability issues exist.

  2) If the document is unclear to the well qualified reader (one
     possessing a thorough understanding of foundations of this work,
     including IP routing, TCP, TCP programming, and the referenced
     documents) then the document may need to be changed to improve
     clarity.

  3) Editorial or document organization changes that would clearly
     improve clarity of the document in areas where clarity is
     deficient to the well qualified and carefull reader are welcome.
     Addition of background tutorial information is out of bounds.

This may help us make real progress.  In the past we haven't had to
explicitly state this but I think this time we do.  We seem to be
bogged down in minutia.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA02214 for <[e-mail]>; Wed, 11 Sep 2002 19:59:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D8557913D3; Wed, 11 Sep 2002 19:58:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9CDA0913D4; Wed, 11 Sep 2002 19:58:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 516F3913D3 for <[e-mail]>; Wed, 11 Sep 2002 19:58:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2AC0D5DDF6; Wed, 11 Sep 2002 19:58:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from laptoy770.fictitious.org (unknown [209.150.1.238]) by segue.merit.edu (Postfix) with ESMTP id 4AAA35DD8C for <[e-mail]>; Wed, 11 Sep 2002 19:58:50 -0400 (EDT)
Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.11.2/8.11.2) with ESMTP id g8BNxZ843144; Wed, 11 Sep 2002 19:59:35 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-reply-to: Your message of "Wed, 11 Sep 2002 15:52:45 EDT." <[e-mail]> 
Date: Wed, 11 Sep 2002 19:59:35 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Jeffrey Haas writes:
> On Wed, Sep 11, 2002 at 03:43:36PM -0400, Natale, Jonathan wrote:
> > 3. EGP is a messy historical thing, not sure what we can do (ask ISP
> > folks???)
> 
> As best I've heard, no EGP is still being run.  So, its worth
> adding the footnote reference in the section on Origin to 
> clarify that its historical.
> 
> -- 
> Jeff Haas 
> NextHop Technologies


Point of history.

Transition from BGP3 to BGP4 and classless routing was declared "done"
in April or May of 1994.  In April all major providers reported that
the ran BGP4 which meant that classless routes could be advertised and
the classfull routes could be withdrawn.  This went without trouble
and happenned very quickly.  So May is when the CIDR/BGP4 transition
was considered to been completed.  People have been gradually cleaning
up aggregates (and poking new holes in them) ever since.

As far as the Internet (with a big "I") is concerned, NASA was the
last holdout speaking BGP externally in 1994 but retaining some
internal use of EGP until 1995 or 1996 when they finally retired some
no longer supported Proteon routers.  Milo Medin or Jeff Burgan would
know more accurately when these were retired (if ever).

Curtis

ps - we now return you to the normally scheduled non-productive
pettiness.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA01843 for <[e-mail]>; Wed, 11 Sep 2002 19:47:06 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1E38891351; Wed, 11 Sep 2002 19:46:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D06CE913D3; Wed, 11 Sep 2002 19:46:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D521C91351 for <[e-mail]>; Wed, 11 Sep 2002 19:46:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B5E855DDF6; Wed, 11 Sep 2002 19:46:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from laptoy770.fictitious.org (unknown [209.150.1.238]) by segue.merit.edu (Postfix) with ESMTP id 81B875DD8C for <[e-mail]>; Wed, 11 Sep 2002 19:46:07 -0400 (EDT)
Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.11.2/8.11.2) with ESMTP id g8BNko843109; Wed, 11 Sep 2002 19:46:50 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'John G. Scudder'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-reply-to: Your message of "Wed, 11 Sep 2002 14:55:23 EDT." <[e-mail]> 
Date: Wed, 11 Sep 2002 19:46:49 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> > 
> > >  > At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > >>  >6. P. 52, section 9.2.1.1 Change this sentence for clarity,
> > >>  >    "This rate limiting procedure applies on a 
> > per-destination basis,
> > >>  >although 
> > >>  >     the value of MinRouteAdvertisementInterval is set on a
> > >>  per BGP peer
> > >>  >basis."
> > >>  >
> > >>  >  To This:
> > >>  >    "This rate limiting procedure applies on a 
> > per-destination basis,
> > >>  >although
> > >  > >     the value of MinRouteAdvertisementInterval is set on a
> > >>  BGP router (same
> > >>  >     value for all peers) basis."
> > >>
> > >>  I disagree.
> > >why?
> > 
> > Because the proposed text does not correctly describe current 
> > implementations.  You are proposing a change to the protocol, not a 
> > clarification of existing practice.
> Then tell me how I am wrong. 
> 
> I read "per-destination basis" and "per BGP peer basis" as two different
> things. The first term, is the neighbor, the second term is our router. 
> If I was wrong then they both have to say either "per destination basis" or
> "per peer basis" but not both. It confuses the reader, who does not know
> the protocol that way. Remember, assumptions, are sometimes bad.
> 
> Ben



  9.2.1.1 Frequency of Route Advertisement

   The parameter MinRouteAdvertisementInterval determines the minimum
   amount of time that must elapse between advertisement of routes to a
   particular destination from a single BGP speaker. This rate limiting
   procedure applies on a per-destination basis, although the value of
   MinRouteAdvertisementInterval is set on a per BGP peer basis.


MinRouteAdvertisementInterval is applied on a per destination basis.

MinRouteAdvertisementInterval is configured on a per peer basis.

The text is clear.  It matches practice.  

Route flap damping ala rfc2439 is a whole different mechanism but the
base BGP protocol spec does not have to include or even reference
extensions defined in separate documents.

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 TAA00563 for <[e-mail]>; Wed, 11 Sep 2002 19:05:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BB43C9134F; Wed, 11 Sep 2002 19:04:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A66C913D3; Wed, 11 Sep 2002 19:04:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2A5B19134F for <[e-mail]>; Wed, 11 Sep 2002 19:02:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0DC445DDD6; Wed, 11 Sep 2002 19:02:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from laptoy770.fictitious.org (unknown [209.150.1.238]) by segue.merit.edu (Postfix) with ESMTP id 1156D5DD8C for <[e-mail]>; Wed, 11 Sep 2002 19:02:26 -0400 (EDT)
Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.11.2/8.11.2) with ESMTP id g8BN38842929; Wed, 11 Sep 2002 19:03:08 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, Tom Petch <[e-mail]>, idr <[e-mail]>, Susan Hares <[e-mail]>, yakov Rekhter <[e-mail]>, [e-mail], [e-mail], randy Bush <[e-mail]>
Reply-To: [e-mail]
Subject: Re: FSM more words 
In-reply-to: Your message of "Wed, 11 Sep 2002 17:38:21 EDT." <[e-mail]> 
Date: Wed, 11 Sep 2002 19:03:08 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> Curtis:
>   If I were a lawyer I would disagree with you. Cause one small word could
> mean the difference between victory or defeat of a case. Just some thoughts.
> 
> Ben


You are obviously in the wrong profession.  Please consider a change.  :-)

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 SAA29057 for <[e-mail]>; Wed, 11 Sep 2002 18:19:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D9240913D6; Wed, 11 Sep 2002 18:16:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2129913D1; Wed, 11 Sep 2002 18:16:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B1760913D2 for <[e-mail]>; Wed, 11 Sep 2002 18:16:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 91AD65DDF6; Wed, 11 Sep 2002 18:16:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from laptoy770.fictitious.org (unknown [209.150.1.238]) by segue.merit.edu (Postfix) with ESMTP id 523BF5DDF2 for <[e-mail]>; Wed, 11 Sep 2002 18:16:43 -0400 (EDT)
Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.11.2/8.11.2) with ESMTP id g8BMHR842251; Wed, 11 Sep 2002 18:17:27 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Abarbanel, Benjamin'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-reply-to: Your message of "Wed, 11 Sep 2002 13:46:45 EDT." <[e-mail]> 
Date: Wed, 11 Sep 2002 18:17:27 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> (your page nums are wrong)
> 
> 1. agree, but cap. Is not a msg type
> 2. agree
> 3. disagree, but maybe:
> IGP = network was explicitly introduced into bgp (network cmd)
> INCOMPLETE = network was implicitly introduced into bgp (redistribute)
> EGP = other
> Also, maybe a discussion/reference on how this is used in decision process.
> (I have seen folks infer that EGP == EBGP, so this has been a source of
> confusion.  May add a note that this is historic???  What do operators use
> Origin = EGP for??? (comments?))
> 4. disagree (covered elsewhere)


We might want to say the value EGP in the ORIGIN field (which does
mean the EGP protocol, not any EGP type protocol) is depricated since
the EGP protocol has been moved to historic but retain the value to
document what it used to mean.

Curtis

ps - Page numbers should be taken from the .txt file.  All other
formats are supplemental and only the .txt file is authoritative.
[Easier to grep too.]


> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Wednesday, September 11, 2002 10:59 AM
> To: '[e-mail]'
> Subject: Review of draft-ietf-idr-bgp4-17.txt
> 
> Part I:
> 
> Editorial Comments:
> ===================
> 1. P. 7 Type: Need to add the new message types such as, Capability
> Negotiations (RFC2842), Route Refresh, etc.
> 
> 2. P. 9, right after "This document defines the following optional
> parameters:"
> Need to mention possible options, such as: Capabilitites (RFC2842),
> Multiprotocol extensions (RFC2858), Route Refresh (RFC2918).
> 
> 3. P. 13, EGP, are there other EGP protocols other than BGP that are in use?
> If not, change EGP to BGP.
> 
> 4. P.23, change the following: 
> 
> "The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
>  links to discriminate among multiple exit or entry points to the same
>  neighboring AS ..."
> 
>  To the following:
> 
> "The MULTI_EXIT_DISC is an optional non-transitive attribute which may be
> used on external (inter-AS) links to discriminate among multiple exit or
> entry points to the same neighboring AS ..."
> 
> 5. In section 8, there are a number of Timers, Counters, etc. that need to
> be explicitly defined before they are used by the FSM. Perhaps these
> definitions should go in the Glossary section.
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA28829 for <[e-mail]>; Wed, 11 Sep 2002 18:11:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9F5939134C; Wed, 11 Sep 2002 18:11:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 708A69134D; Wed, 11 Sep 2002 18:11:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 386689134C for <[e-mail]>; Wed, 11 Sep 2002 18:11:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1BAD25DDF6; Wed, 11 Sep 2002 18:11:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from laptoy770.fictitious.org (unknown [209.150.1.238]) by segue.merit.edu (Postfix) with ESMTP id 13FBF5DDF2 for <[e-mail]>; Wed, 11 Sep 2002 18:11:39 -0400 (EDT)
Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.11.2/8.11.2) with ESMTP id g8BMCO842202; Wed, 11 Sep 2002 18:12:24 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Jeffrey Haas'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: your mail 
In-reply-to: Your message of "Wed, 11 Sep 2002 13:43:18 EDT." <[e-mail]> 
Date: Wed, 11 Sep 2002 18:12:23 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> My point is that no one "reads from a peer", that is physically impossible.
> If there are many other ways to skin the cat, then mention like this,
> "reads from a peer socket/stream/session/etc." just to be technically
> correct.
> 
> Ben


It if physically impossible to "read from a peer" which also makes it
painfully obvious that what is meant is "read from the socket for the
TCP connection that is associated with the BGP session for a specific
peer".

The latter is unambiguous even to the complete idiot but overly wordy
for anyone with an understanding of what a protocol based on TCP
entails.  The former is short and it is unambiguous for the intended
audience of the BGP protocol spec.

Curtis

ps - Please stop wasting our time.  Please be sure that your comments
are regarding something that is incorrect, incomplete, ambiguous, or
unclear when read from the standpoint of a person well versed in IP
routing, TCP, and TCP programming.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA28793 for <[e-mail]>; Wed, 11 Sep 2002 18:10:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9CCB19134B; Wed, 11 Sep 2002 18:10:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63C629134C; Wed, 11 Sep 2002 18:10:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1D77C9134B for <[e-mail]>; Wed, 11 Sep 2002 18:10:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EB35C5DDF6; Wed, 11 Sep 2002 18:10:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from nemesis.systems.pipex.net (nemesis.systems.pipex.net [62.241.160.8]) by segue.merit.edu (Postfix) with ESMTP id A09355DDF2 for <[e-mail]>; Wed, 11 Sep 2002 18:10:26 -0400 (EDT)
Received: from tom3 (userbl30.uk.uudial.com [62.188.144.137]) by nemesis.systems.pipex.net (Postfix) with SMTP id 5B0ED160080F6; Wed, 11 Sep 2002 23:10:22 +0100 (BST)
Message-ID: <00e401c259df$9eb77f00$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Susan Hares" <[e-mail]>
Cc: "idr" <[e-mail]>, "Susan Hares" <[e-mail]>, "yakov Rekhter" <[e-mail]>, <[e-mail]>, <[e-mail]>, "randy Bush" <[e-mail]>
Subject: Re: FSM ConnectRetryCnt
Date: Wed, 11 Sep 2002 23:01:08 +0100
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

Um; thanks for the explanation.  I appreciate I am picky but I would
like a brief sentence in BGP base document as to why we do this, if we
keep the rest of the processing in which I assume we should (?).

Tom Petch
[e-mail]
-----Original Message-----
From: Susan Hares <[e-mail]>
To: Tom Petch <[e-mail]>
Cc: idr <[e-mail]>; Susan Hares <[e-mail]>; yakov Rekhter
<[e-mail]>; [e-mail]
<[e-mail]>; [e-mail] <[e-mail]>; randy Bush
<[e-mail]>
Date: 11 September 2002 21:18
Subject: Re: FSM ConnectRetryCnt


>
>1st - ConnectRetryCnt was included to damp out
>         persistent bgp peer oscillations.
>
>         1) The peer connections would drop due to an error condition
>            (such as a bogus prefix),
>         2) the auto-restart would engage,
>         3) the connection would re-establish,
>         4) the same data would get sent the error would occur, and
>                 the cycle starts with #1
>
>The bgp peer oscillation draft I've written took this information
>out of the BGP specification due to working group consensus
>**AND** the fact it did not match with the current implementations.
>
>Since the persistent route oscillation **is** in some
implementations,
>we put the text off into a separate document.   Divide and conquer
>
>hares-backoff-00.txt
>was my latest draft.  Due to the charter of the WG at this time,
>we cannot include this in the work until we finish the.
>
>The ConnectRetryCnt is cleared upon manual reset, because
>the operators need something to be able to manual stop the
>mechanism to stop the flap.
>
>Does this answer the questions on the draft?
>
>sue
>
>
>06:30 PM 9/11/2002 +0100, Tom Petch wrote:
>>This seems to have lost its purpose (which it had in BGP-17).  It
gets
>>cleared on manual stop, incremented by one when something goes wrong
>>but so what?  An explanation would help.
>>
>>And I think it should be a Session Attribute required for each
>>connection, along with
>>OpenDelayTimer
>>DelayOpenFlag
>>
>>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 RAA28356 for <[e-mail]>; Wed, 11 Sep 2002 17:58:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 812BE91348; Wed, 11 Sep 2002 17:57:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5454E9134B; Wed, 11 Sep 2002 17:57:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2A66691348 for <[e-mail]>; Wed, 11 Sep 2002 17:57:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 199635DE13; Wed, 11 Sep 2002 17:57:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id B0B015DDF2 for <[e-mail]>; Wed, 11 Sep 2002 17:57:42 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BLvXm93798; Wed, 11 Sep 2002 14:57:33 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: "Tom Petch" <[e-mail]>, "idr" <[e-mail]>, "Susan Hares" <[e-mail]>, [e-mail], [e-mail], "randy Bush" <[e-mail]>
Subject: Re: FSM ConnectRetryCnt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 17:46:32 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 14:57:33 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Curtis,

> In message <013701c259b9$f764dec0$0301a8c0@tom3>, "Tom Petch" writes:
> > This seems to have lost its purpose (which it had in BGP-17).  It gets
> > cleared on manual stop, incremented by one when something goes wrong
> > but so what?  An explanation would help.
> 
> Its something read by the MIB.
> 
> > And I think it should be a Session Attribute required for each
> > connection, along with
> > OpenDelayTimer
> > DelayOpenFlag
> > 
> > Tom Petch
> > [e-mail]
> 
> We are not here to make arbitrary changes to the protocol just for
> personal preferences.  This is a protocol that has been deployed very
> successfully for nearly a decade and enjoys extremely widespread use.
> 
> The IETF document that describes this protocol was a little
> inaccurate, did not reflect current implementations in ways that would
> impact interoperability (if implemented exactly as specified) and was
> reknown for being difficult to read.  AFAIK these deficiencies in *the
> document* are all we are fixing unless there is a very pressing need
> to make changes to the protocol.
> 
> An example of a pressing need would be the specification of MED
> handling leaves open the possiblity for a routing loop but a commonly
> implemented change in MED usage fixes the problem.  [already fixed in
> bgp-17].
> 
> Not to pick on you in particular but things like "I think it would be
> nice if the following were included in the open" and "I'd like to
> change the semantics of something for no good reason except it looks
> cleaner to me" are definitely not going to get considered.  [So please
> stop wasting our time - this means you too, Ben - please :-) ].

Just one (minor) addition - even if one has "good reason", we can't change 
the semantics if such change contradicts what is widely deployed today.

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 RAA28000 for <[e-mail]>; Wed, 11 Sep 2002 17:46:54 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A6B329134A; Wed, 11 Sep 2002 17:46:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8B0E913D0; Wed, 11 Sep 2002 17:46:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D8329134A for <[e-mail]>; Wed, 11 Sep 2002 17:45:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 677535DD8C; Wed, 11 Sep 2002 17:45:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from laptoy770.fictitious.org (unknown [209.150.1.238]) by segue.merit.edu (Postfix) with ESMTP id 740975DE16 for <[e-mail]>; Wed, 11 Sep 2002 17:45:47 -0400 (EDT)
Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.11.2/8.11.2) with ESMTP id g8BLkW842153; Wed, 11 Sep 2002 17:46:33 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Tom Petch" <[e-mail]>
Cc: "idr" <[e-mail]>, "Susan Hares" <[e-mail]>, "yakov Rekhter" <[e-mail]>, [e-mail], [e-mail], "randy Bush" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: FSM ConnectRetryCnt 
In-reply-to: Your message of "Wed, 11 Sep 2002 18:30:18 BST." <013701c259b9$f764dec0$0301a8c0@tom3> 
Date: Wed, 11 Sep 2002 17:46:32 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <013701c259b9$f764dec0$0301a8c0@tom3>, "Tom Petch" writes:
> This seems to have lost its purpose (which it had in BGP-17).  It gets
> cleared on manual stop, incremented by one when something goes wrong
> but so what?  An explanation would help.

Its something read by the MIB.

> And I think it should be a Session Attribute required for each
> connection, along with
> OpenDelayTimer
> DelayOpenFlag
> 
> Tom Petch
> [e-mail]

We are not here to make arbitrary changes to the protocol just for
personal preferences.  This is a protocol that has been deployed very
successfully for nearly a decade and enjoys extremely widespread use.

The IETF document that describes this protocol was a little
inaccurate, did not reflect current implementations in ways that would
impact interoperability (if implemented exactly as specified) and was
reknown for being difficult to read.  AFAIK these deficiencies in *the
document* are all we are fixing unless there is a very pressing need
to make changes to the protocol.

An example of a pressing need would be the specification of MED
handling leaves open the possiblity for a routing loop but a commonly
implemented change in MED usage fixes the problem.  [already fixed in
bgp-17].

Not to pick on you in particular but things like "I think it would be
nice if the following were included in the open" and "I'd like to
change the semantics of something for no good reason except it looks
cleaner to me" are definitely not going to get considered.  [So please
stop wasting our time - this means you too, Ben - please :-) ].

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 RAA27710 for <[e-mail]>; Wed, 11 Sep 2002 17:38:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BE62491347; Wed, 11 Sep 2002 17:38:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 876C99134A; Wed, 11 Sep 2002 17:38:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9244C91347 for <[e-mail]>; Wed, 11 Sep 2002 17:38:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7D1F95DE00; Wed, 11 Sep 2002 17:38:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 05A2D5DD8C for <[e-mail]>; Wed, 11 Sep 2002 17:38:34 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA06626; Wed, 11 Sep 2002 17:38:21 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA23935; Wed, 11 Sep 2002 17:38:23 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DR728>; Wed, 11 Sep 2002 17:38:22 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Tom Petch <[e-mail]>
Cc: idr <[e-mail]>, Susan Hares <[e-mail]>, yakov Rekhter <[e-mail]>, [e-mail], [e-mail], randy Bush <[e-mail]>
Subject: RE: FSM more words 
Date: Wed, 11 Sep 2002 17:38:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Curtis:
  If I were a lawyer I would disagree with you. Cause one small word could
mean the difference between victory or defeat of a case. Just some thoughts.

Ben

> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 5:33 PM
> To: Tom Petch
> Cc: idr; Susan Hares; yakov Rekhter; [e-mail];
> [e-mail]; randy Bush
> Subject: Re: FSM more words 
> 
> 
> 
> In message <013601c259b9$f5fcc340$0301a8c0@tom3>, "Tom Petch" writes:
> > In the 26Aug text, I find the timer terminology still confusing.
> > Timers can, I find, 
> > stop
> > start
> > restart
> > clear
> > set
> > reset
> > expire
> > 
> > Rich the English language is but I see this as overuse.
> > For me, timers
> > start, stop, expire
> 
> I didn't find the word "reset" in draft-ietf-idr-bgp4-17.tx.
> 
> Restarting a time is getting rid of any running timer and starting the
> timer from its configured initial value (ie: stop, then start).  That
> seems to be entirely consistent with uses of the word restart in other
> contexts.
> 
> Clear and stop a timer are synonomous.  I can't see how that could not
> be obvious.
> 
> The word set is used in phrases like "set Hold timer to a large value"
> which is not adequately covered by the words start and stop.
> 
> > The only further refinement is that they may start with an initial
> > value or with the value they had when they were stopped (eg NFL game
> > clocks); I do not believe, but cannot be sure, that the last is ever
> > used in the FSM.  Which means all we need is
> > start with initial value (spell it out just to be sure)
> > stop
> > expire
> > and anything else just confuses - me and I suspect others.
> > 
> > Tom Petch
> > [e-mail]
> 
> Just as we can't include a complete TCP tutorial, we can't include
> english dictionary entries for every small word used in the document.
> 
> I don't see any reason for change.
> 
> 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 RAA27613 for <[e-mail]>; Wed, 11 Sep 2002 17:35:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0EB0A912D1; Wed, 11 Sep 2002 17:34:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D59BD913D1; Wed, 11 Sep 2002 17:34:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 50848912D1 for <[e-mail]>; Wed, 11 Sep 2002 17:32:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 316F35DDA4; Wed, 11 Sep 2002 17:32:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from laptoy770.fictitious.org (unknown [209.150.1.238]) by segue.merit.edu (Postfix) with ESMTP id 49C145DD8C for <[e-mail]>; Wed, 11 Sep 2002 17:32:38 -0400 (EDT)
Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.11.2/8.11.2) with ESMTP id g8BLXN842123; Wed, 11 Sep 2002 17:33:24 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Tom Petch" <[e-mail]>
Cc: "idr" <[e-mail]>, "Susan Hares" <[e-mail]>, "yakov Rekhter" <[e-mail]>, [e-mail], [e-mail], "randy Bush" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: FSM more words 
In-reply-to: Your message of "Wed, 11 Sep 2002 18:29:45 BST." <013601c259b9$f5fcc340$0301a8c0@tom3> 
Date: Wed, 11 Sep 2002 17:33:23 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <013601c259b9$f5fcc340$0301a8c0@tom3>, "Tom Petch" writes:
> In the 26Aug text, I find the timer terminology still confusing.
> Timers can, I find, 
> stop
> start
> restart
> clear
> set
> reset
> expire
> 
> Rich the English language is but I see this as overuse.
> For me, timers
> start, stop, expire

I didn't find the word "reset" in draft-ietf-idr-bgp4-17.tx.

Restarting a time is getting rid of any running timer and starting the
timer from its configured initial value (ie: stop, then start).  That
seems to be entirely consistent with uses of the word restart in other
contexts.

Clear and stop a timer are synonomous.  I can't see how that could not
be obvious.

The word set is used in phrases like "set Hold timer to a large value"
which is not adequately covered by the words start and stop.

> The only further refinement is that they may start with an initial
> value or with the value they had when they were stopped (eg NFL game
> clocks); I do not believe, but cannot be sure, that the last is ever
> used in the FSM.  Which means all we need is
> start with initial value (spell it out just to be sure)
> stop
> expire
> and anything else just confuses - me and I suspect others.
> 
> Tom Petch
> [e-mail]

Just as we can't include a complete TCP tutorial, we can't include
english dictionary entries for every small word used in the document.

I don't see any reason for change.

Curtis


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 RAA27606 for <[e-mail]>; Wed, 11 Sep 2002 17:35:25 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0F812913CF; Wed, 11 Sep 2002 17:34:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6BE6913D0; Wed, 11 Sep 2002 17:34:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 40BEB913CF for <[e-mail]>; Wed, 11 Sep 2002 17:33:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 238EB5DDA4; Wed, 11 Sep 2002 17:33:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id A360E5DD8C for <[e-mail]>; Wed, 11 Sep 2002 17:33:45 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA06504; Wed, 11 Sep 2002 17:33:40 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA23376; Wed, 11 Sep 2002 17:33:43 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DR7DV>; Wed, 11 Sep 2002 17:33:42 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "'Justin Fletcher'" <[e-mail]>, [e-mail]
Cc: Alex Zinin <[e-mail]>, Yakov Rekhter <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 17:33:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Maybe Appendix 6 Needs to turn into another draft. It does have usefull
information for newbies.

I will go along with this plan, if people wont mind.

Ben

> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 5:29 PM
> To: 'Justin Fletcher'; [e-mail]
> Cc: Alex Zinin; Yakov Rekhter; Abarbanel, Benjamin
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> I agree, the entire section should be removed.
> 
> -----Original Message-----
> From: Justin Fletcher [mailto:[e-mail]] 
> Sent: Wednesday, September 11, 2002 5:01 PM
> To: [e-mail]
> Cc: Alex Zinin; Yakov Rekhter; Abarbanel, Benjamin
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> 
> On Wed, 2002-09-11 at 13:30, Curtis Villamizar wrote:
> > 
> > In message <[e-mail]>, Alex Zinin writes:
> > > Yakov, Ben-
> > > 
> > >  I thought section 6.2 "Processing Messages on a Stream Protocol"
> > >  actually talked about these things...
> > > 
> > > -- 
> > > Alex
> > 
> > 
> > A you suggesting we turn the terse reminder in the appendix into a
> > full TCP programming tutorial?
> > 
> > Maybe we should just change that section to.
> > 
> >   6.2  Processing Messages on a Stream Protocol
> > 
> >      BGP uses TCP as a transport mechanism.  If you are unsure as to
> >      how to handle asynchronous reads and writes on TCP 
> sockets please
> >      refer to Unix Network Programming [RWStevens] or other
> >      introductory text for programming techniques for the operating
> >      system and TCP implementation that you are using.
> > 
> > That would save having to rewrite major parts of Stevens 
> work into the
> > BGP spec.
> > 
> > Curtis
> 
> Perhaps the entire section should be deleted as beyond scope.
> 
> Justin Fletcher
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA27437 for <[e-mail]>; Wed, 11 Sep 2002 17:29:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4BEBF913CD; Wed, 11 Sep 2002 17:29:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14967913CE; Wed, 11 Sep 2002 17:29:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C6D09913CD for <[e-mail]>; Wed, 11 Sep 2002 17:29:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B2ECD5DDF5; Wed, 11 Sep 2002 17:29:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 66C325DD8C for <[e-mail]>; Wed, 11 Sep 2002 17:29:04 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CKNR>; Wed, 11 Sep 2002 17:29:00 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Justin Fletcher'" <[e-mail]>, [e-mail]
Cc: Alex Zinin <[e-mail]>, Yakov Rekhter <[e-mail]>, "Abarbanel,     Benjamin" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 17:28:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I agree, the entire section should be removed.

-----Original Message-----
From: Justin Fletcher [mailto:[e-mail]] 
Sent: Wednesday, September 11, 2002 5:01 PM
To: [e-mail]
Cc: Alex Zinin; Yakov Rekhter; Abarbanel, Benjamin
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt

On Wed, 2002-09-11 at 13:30, Curtis Villamizar wrote:
> 
> In message <[e-mail]>, Alex Zinin writes:
> > Yakov, Ben-
> > 
> >  I thought section 6.2 "Processing Messages on a Stream Protocol"
> >  actually talked about these things...
> > 
> > -- 
> > Alex
> 
> 
> A you suggesting we turn the terse reminder in the appendix into a
> full TCP programming tutorial?
> 
> Maybe we should just change that section to.
> 
>   6.2  Processing Messages on a Stream Protocol
> 
>      BGP uses TCP as a transport mechanism.  If you are unsure as to
>      how to handle asynchronous reads and writes on TCP sockets please
>      refer to Unix Network Programming [RWStevens] or other
>      introductory text for programming techniques for the operating
>      system and TCP implementation that you are using.
> 
> That would save having to rewrite major parts of Stevens work into the
> BGP spec.
> 
> Curtis

Perhaps the entire section should be deleted as beyond scope.

Justin Fletcher



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA27348 for <[e-mail]>; Wed, 11 Sep 2002 17:26:36 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 97F2B913CA; Wed, 11 Sep 2002 17:25:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62A4D913CD; Wed, 11 Sep 2002 17:25:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F365913CA for <[e-mail]>; Wed, 11 Sep 2002 17:25:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 25CBA5DDF5; Wed, 11 Sep 2002 17:25:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id A5DE55DD8C for <[e-mail]>; Wed, 11 Sep 2002 17:25:57 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA06190; Wed, 11 Sep 2002 17:25:53 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA22347; Wed, 11 Sep 2002 17:25:55 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DR66N>; Wed, 11 Sep 2002 17:25:55 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Justin Fletcher'" <[e-mail]>, [e-mail], Alex Zinin <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
Date: Wed, 11 Sep 2002 17:25:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov,

I dont want this thread to turn into being absurd. So lets drop the topic
I dont think we are getting anywhere here.

I just made an innocent comment about fixing the meaning of some text. I
apologize to all those who are offended by my review of the spec.


Thank You,
Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 5:22 PM
> To: Abarbanel, Benjamin
> Cc: 'Yakov Rekhter'; 'Justin Fletcher'; [e-mail]; Alex Zinin
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> 
> 
> > Just common sense, knowing how BGP, TCP and sockets work. I 
> guess I made
> > too a general statement, 
> 
> I think you are correct on this.
> 
> >                             maybe I should have said all 
> implementations
> > I looked at do it this way. 
> 
> That would certainly be more accurate. It would be even better if you
> would say how many implementations you looked at.
> 
> Yakov.
>   
> > > -----Original Message-----
> > > From: Yakov Rekhter [mailto:[e-mail]]
> > > Sent: Wednesday, September 11, 2002 5:09 PM
> > > To: Abarbanel, Benjamin
> > > Cc: 'Justin Fletcher'; [e-mail]; Alex Zinin
> > > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> > > 
> > > 
> > > Ben,
> > > 
> > > > At some point the wisdom of the day was to put this in. 
> Now its too
> > > > implementation specific, and people want to remove it. 
> When in fact 
> > > > everyone who builds BGP code does it this way.
> > > 
> > > Are you 100% sure that "everyone who builds BGP code does it 
> > > this way" ?
> > > (Did you actually check this with *everyone* who builds BGP ?)
> > > 
> > > Yakov.
> > > 
> > > > I see no reason why section Appendix 6.2 should be deleted. 
> > > > 
> > > > Thank You,
> > > > Ben
> > > > 
> > > > > -----Original Message-----
> > > > > From: Justin Fletcher [mailto:[e-mail]]
> > > > > Sent: Wednesday, September 11, 2002 5:01 PM
> > > > > To: [e-mail]
> > > > > Cc: Alex Zinin; Yakov Rekhter; Abarbanel, Benjamin
> > > > > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> > > > > 
> > > > > 
> > > > > On Wed, 2002-09-11 at 13:30, Curtis Villamizar wrote:
> > > > > > 
> > > > > > In message <[e-mail]>, Alex 
> > > Zinin writes:
> > > > > > > Yakov, Ben-
> > > > > > > 
> > > > > > >  I thought section 6.2 "Processing Messages on a 
> > > Stream Protocol"
> > > > > > >  actually talked about these things...
> > > > > > > 
> > > > > > > -- 
> > > > > > > Alex
> > > > > > 
> > > > > > 
> > > > > > A you suggesting we turn the terse reminder in the 
> > > appendix into a
> > > > > > full TCP programming tutorial?
> > > > > > 
> > > > > > Maybe we should just change that section to.
> > > > > > 
> > > > > >   6.2  Processing Messages on a Stream Protocol
> > > > > > 
> > > > > >      BGP uses TCP as a transport mechanism.  If you are 
> > > unsure as to
> > > > > >      how to handle asynchronous reads and writes on TCP 
> > > > > sockets please
> > > > > >      refer to Unix Network Programming [RWStevens] or other
> > > > > >      introductory text for programming techniques for 
> > > the operating
> > > > > >      system and TCP implementation that you are using.
> > > > > > 
> > > > > > That would save having to rewrite major parts of Stevens 
> > > > > work into the
> > > > > > BGP spec.
> > > > > > 
> > > > > > Curtis
> > > > > 
> > > > > Perhaps the entire section should be deleted as beyond scope.
> > > > > 
> > > > > Justin Fletcher
> > > > > 
> > > > > 
> > > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA27155 for <[e-mail]>; Wed, 11 Sep 2002 17:21:58 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CEECC91346; Wed, 11 Sep 2002 17:21:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A21D1913CA; Wed, 11 Sep 2002 17:21:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5DC2891346 for <[e-mail]>; Wed, 11 Sep 2002 17:21:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3D2F05DDF2; Wed, 11 Sep 2002 17:21:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 9D29B5DD8C for <[e-mail]>; Wed, 11 Sep 2002 17:21:40 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BLLXm90636; Wed, 11 Sep 2002 14:21:33 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, "'Justin Fletcher'" <[e-mail]>, [e-mail], Alex Zinin <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 17:12:59 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 14:21:33 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Just common sense, knowing how BGP, TCP and sockets work. I guess I made
> too a general statement, 

I think you are correct on this.

>                             maybe I should have said all implementations
> I looked at do it this way. 

That would certainly be more accurate. It would be even better if you
would say how many implementations you looked at.

Yakov.
  
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Wednesday, September 11, 2002 5:09 PM
> > To: Abarbanel, Benjamin
> > Cc: 'Justin Fletcher'; [e-mail]; Alex Zinin
> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> > 
> > 
> > Ben,
> > 
> > > At some point the wisdom of the day was to put this in. Now its too
> > > implementation specific, and people want to remove it. When in fact 
> > > everyone who builds BGP code does it this way.
> > 
> > Are you 100% sure that "everyone who builds BGP code does it 
> > this way" ?
> > (Did you actually check this with *everyone* who builds BGP ?)
> > 
> > Yakov.
> > 
> > > I see no reason why section Appendix 6.2 should be deleted. 
> > > 
> > > Thank You,
> > > Ben
> > > 
> > > > -----Original Message-----
> > > > From: Justin Fletcher [mailto:[e-mail]]
> > > > Sent: Wednesday, September 11, 2002 5:01 PM
> > > > To: [e-mail]
> > > > Cc: Alex Zinin; Yakov Rekhter; Abarbanel, Benjamin
> > > > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> > > > 
> > > > 
> > > > On Wed, 2002-09-11 at 13:30, Curtis Villamizar wrote:
> > > > > 
> > > > > In message <[e-mail]>, Alex 
> > Zinin writes:
> > > > > > Yakov, Ben-
> > > > > > 
> > > > > >  I thought section 6.2 "Processing Messages on a 
> > Stream Protocol"
> > > > > >  actually talked about these things...
> > > > > > 
> > > > > > -- 
> > > > > > Alex
> > > > > 
> > > > > 
> > > > > A you suggesting we turn the terse reminder in the 
> > appendix into a
> > > > > full TCP programming tutorial?
> > > > > 
> > > > > Maybe we should just change that section to.
> > > > > 
> > > > >   6.2  Processing Messages on a Stream Protocol
> > > > > 
> > > > >      BGP uses TCP as a transport mechanism.  If you are 
> > unsure as to
> > > > >      how to handle asynchronous reads and writes on TCP 
> > > > sockets please
> > > > >      refer to Unix Network Programming [RWStevens] or other
> > > > >      introductory text for programming techniques for 
> > the operating
> > > > >      system and TCP implementation that you are using.
> > > > > 
> > > > > That would save having to rewrite major parts of Stevens 
> > > > work into the
> > > > > BGP spec.
> > > > > 
> > > > > Curtis
> > > > 
> > > > Perhaps the entire section should be deleted as beyond scope.
> > > > 
> > > > Justin Fletcher
> > > > 
> > > > 
> > 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA27128 for <[e-mail]>; Wed, 11 Sep 2002 17:21:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1D46A91343; Wed, 11 Sep 2002 17:20:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE377913CA; Wed, 11 Sep 2002 17:20:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B7C091343 for <[e-mail]>; Wed, 11 Sep 2002 17:20:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 591645DDE1; Wed, 11 Sep 2002 17:20:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 0FDFE5DD8C for <[e-mail]>; Wed, 11 Sep 2002 17:20:35 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CKMY>; Wed, 11 Sep 2002 17:20:30 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Next hop for redistributed routes
Date: Wed, 11 Sep 2002 17:20:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I propose adding:

"When announcing a locally 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 address of the interface that is
used to reach the peer)."

AFTER

"When sending a message to an internal peer, 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."


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA26886 for <[e-mail]>; Wed, 11 Sep 2002 17:13:36 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 666DE913C8; Wed, 11 Sep 2002 17:13:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B463913C9; Wed, 11 Sep 2002 17:13:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 40680913C8 for <[e-mail]>; Wed, 11 Sep 2002 17:13:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2D2FD5DDD3; Wed, 11 Sep 2002 17:13:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id AD1E25DD8C for <[e-mail]>; Wed, 11 Sep 2002 17:13:03 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA05767; Wed, 11 Sep 2002 17:12:59 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA20783; Wed, 11 Sep 2002 17:13:01 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DR6NS>; Wed, 11 Sep 2002 17:13:00 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Justin Fletcher'" <[e-mail]>, [e-mail], Alex Zinin <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
Date: Wed, 11 Sep 2002 17:12:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Just common sense, knowing how BGP, TCP and sockets work. I guess I made
too a general statement, maybe I should have said all implementations
I looked at do it this way. Or is it TCP 101 as Curtis called it.



> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 5:09 PM
> To: Abarbanel, Benjamin
> Cc: 'Justin Fletcher'; [e-mail]; Alex Zinin
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> 
> 
> Ben,
> 
> > At some point the wisdom of the day was to put this in. Now its too
> > implementation specific, and people want to remove it. When in fact 
> > everyone who builds BGP code does it this way.
> 
> Are you 100% sure that "everyone who builds BGP code does it 
> this way" ?
> (Did you actually check this with *everyone* who builds BGP ?)
> 
> Yakov.
> 
> > I see no reason why section Appendix 6.2 should be deleted. 
> > 
> > Thank You,
> > Ben
> > 
> > > -----Original Message-----
> > > From: Justin Fletcher [mailto:[e-mail]]
> > > Sent: Wednesday, September 11, 2002 5:01 PM
> > > To: [e-mail]
> > > Cc: Alex Zinin; Yakov Rekhter; Abarbanel, Benjamin
> > > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> > > 
> > > 
> > > On Wed, 2002-09-11 at 13:30, Curtis Villamizar wrote:
> > > > 
> > > > In message <[e-mail]>, Alex 
> Zinin writes:
> > > > > Yakov, Ben-
> > > > > 
> > > > >  I thought section 6.2 "Processing Messages on a 
> Stream Protocol"
> > > > >  actually talked about these things...
> > > > > 
> > > > > -- 
> > > > > Alex
> > > > 
> > > > 
> > > > A you suggesting we turn the terse reminder in the 
> appendix into a
> > > > full TCP programming tutorial?
> > > > 
> > > > Maybe we should just change that section to.
> > > > 
> > > >   6.2  Processing Messages on a Stream Protocol
> > > > 
> > > >      BGP uses TCP as a transport mechanism.  If you are 
> unsure as to
> > > >      how to handle asynchronous reads and writes on TCP 
> > > sockets please
> > > >      refer to Unix Network Programming [RWStevens] or other
> > > >      introductory text for programming techniques for 
> the operating
> > > >      system and TCP implementation that you are using.
> > > > 
> > > > That would save having to rewrite major parts of Stevens 
> > > work into the
> > > > BGP spec.
> > > > 
> > > > Curtis
> > > 
> > > Perhaps the entire section should be deleted as beyond scope.
> > > 
> > > Justin Fletcher
> > > 
> > > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA26848 for <[e-mail]>; Wed, 11 Sep 2002 17:12:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D59BB913C7; Wed, 11 Sep 2002 17:11:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A04E7913C8; Wed, 11 Sep 2002 17:11:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76C0F913C7 for <[e-mail]>; Wed, 11 Sep 2002 17:11:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5ECFF5DDD3; Wed, 11 Sep 2002 17:11:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id EF4BF5DD8C for <[e-mail]>; Wed, 11 Sep 2002 17:11:46 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BLBdm89608; Wed, 11 Sep 2002 14:11:39 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: Justin Fletcher <[e-mail]>, [e-mail], Alex Zinin <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 17:07:14 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 14:11:39 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> Yakov,
>   Dont we need the WG ADS approval to remove sections from the document?
>   (e.g. FSM Section to be deleted)

I don't recall seeing this requirement in the RFCs that document
the IETF process.

Yakov.

> 
> Ben
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Wednesday, September 11, 2002 5:04 PM
> > To: Justin Fletcher
> > Cc: [e-mail]; Alex Zinin; Abarbanel, Benjamin
> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> > 
> > 
> > Justin,
> > 
> > > > >  I thought section 6.2 "Processing Messages on a Stream 
> > Protocol"
> > > > >  actually talked about these things...
> > > > > 
> > > > > -- 
> > > > > Alex
> > > > 
> > > > 
> > > > A you suggesting we turn the terse reminder in the appendix into a
> > > > full TCP programming tutorial?
> > > > 
> > > > Maybe we should just change that section to.
> > > > 
> > > >   6.2  Processing Messages on a Stream Protocol
> > > > 
> > > >      BGP uses TCP as a transport mechanism.  If you are 
> > unsure as to
> > > >      how to handle asynchronous reads and writes on TCP 
> > sockets please
> > > >      refer to Unix Network Programming [RWStevens] or other
> > > >      introductory text for programming techniques for the 
> > operating
> > > >      system and TCP implementation that you are using.
> > > > 
> > > > That would save having to rewrite major parts of Stevens 
> > work into the
> > > > BGP spec.
> > > > 
> > > > Curtis
> > > 
> > > Perhaps the entire section should be deleted as beyond scope.
> > 
> > That would be fine too.
> > 
> > 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 RAA26768 for <[e-mail]>; Wed, 11 Sep 2002 17:10:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8DD1A913C3; Wed, 11 Sep 2002 17:09:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5EAAB913C7; Wed, 11 Sep 2002 17:09:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2CF42913C3 for <[e-mail]>; Wed, 11 Sep 2002 17:09:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 144075DDD3; Wed, 11 Sep 2002 17:09:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id AB9C15DD8C for <[e-mail]>; Wed, 11 Sep 2002 17:09:30 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BL96m89399; Wed, 11 Sep 2002 14:09:06 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Justin Fletcher'" <[e-mail]>, [e-mail], Alex Zinin <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 17:04:10 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 14:09:06 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> At some point the wisdom of the day was to put this in. Now its too
> implementation specific, and people want to remove it. When in fact 
> everyone who builds BGP code does it this way.

Are you 100% sure that "everyone who builds BGP code does it this way" ?
(Did you actually check this with *everyone* who builds BGP ?)

Yakov.

> I see no reason why section Appendix 6.2 should be deleted. 
> 
> Thank You,
> Ben
> 
> > -----Original Message-----
> > From: Justin Fletcher [mailto:[e-mail]]
> > Sent: Wednesday, September 11, 2002 5:01 PM
> > To: [e-mail]
> > Cc: Alex Zinin; Yakov Rekhter; Abarbanel, Benjamin
> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> > 
> > 
> > On Wed, 2002-09-11 at 13:30, Curtis Villamizar wrote:
> > > 
> > > In message <[e-mail]>, Alex Zinin writes:
> > > > Yakov, Ben-
> > > > 
> > > >  I thought section 6.2 "Processing Messages on a Stream Protocol"
> > > >  actually talked about these things...
> > > > 
> > > > -- 
> > > > Alex
> > > 
> > > 
> > > A you suggesting we turn the terse reminder in the appendix into a
> > > full TCP programming tutorial?
> > > 
> > > Maybe we should just change that section to.
> > > 
> > >   6.2  Processing Messages on a Stream Protocol
> > > 
> > >      BGP uses TCP as a transport mechanism.  If you are unsure as to
> > >      how to handle asynchronous reads and writes on TCP 
> > sockets please
> > >      refer to Unix Network Programming [RWStevens] or other
> > >      introductory text for programming techniques for the operating
> > >      system and TCP implementation that you are using.
> > > 
> > > That would save having to rewrite major parts of Stevens 
> > work into the
> > > BGP spec.
> > > 
> > > Curtis
> > 
> > Perhaps the entire section should be deleted as beyond scope.
> > 
> > Justin Fletcher
> > 
> > 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA26647 for <[e-mail]>; Wed, 11 Sep 2002 17:07:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 47299913C0; Wed, 11 Sep 2002 17:07:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1B13913C7; Wed, 11 Sep 2002 17:07:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 687CE913C0 for <[e-mail]>; Wed, 11 Sep 2002 17:07:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2FD855DDD3; Wed, 11 Sep 2002 17:07:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 7A11E5DDF8 for <[e-mail]>; Wed, 11 Sep 2002 17:07:21 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA05503; Wed, 11 Sep 2002 17:07:17 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA20075; Wed, 11 Sep 2002 17:07:19 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DR6H9>; Wed, 11 Sep 2002 17:07:16 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, Justin Fletcher <[e-mail]>
Cc: [e-mail], Alex Zinin <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
Date: Wed, 11 Sep 2002 17:07:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov,
  Dont we need the WG ADS approval to remove sections from the document?

  (e.g. FSM Section to be deleted)

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 5:04 PM
> To: Justin Fletcher
> Cc: [e-mail]; Alex Zinin; Abarbanel, Benjamin
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> 
> 
> Justin,
> 
> > > >  I thought section 6.2 "Processing Messages on a Stream 
> Protocol"
> > > >  actually talked about these things...
> > > > 
> > > > -- 
> > > > Alex
> > > 
> > > 
> > > A you suggesting we turn the terse reminder in the appendix into a
> > > full TCP programming tutorial?
> > > 
> > > Maybe we should just change that section to.
> > > 
> > >   6.2  Processing Messages on a Stream Protocol
> > > 
> > >      BGP uses TCP as a transport mechanism.  If you are 
> unsure as to
> > >      how to handle asynchronous reads and writes on TCP 
> sockets please
> > >      refer to Unix Network Programming [RWStevens] or other
> > >      introductory text for programming techniques for the 
> operating
> > >      system and TCP implementation that you are using.
> > > 
> > > That would save having to rewrite major parts of Stevens 
> work into the
> > > BGP spec.
> > > 
> > > Curtis
> > 
> > Perhaps the entire section should be deleted as beyond scope.
> 
> That would be fine too.
> 
> 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 RAA26580 for <[e-mail]>; Wed, 11 Sep 2002 17:05:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9D34F913C6; Wed, 11 Sep 2002 17:04:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 78A6F913C3; Wed, 11 Sep 2002 17:04:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 21C3B913C0 for <[e-mail]>; Wed, 11 Sep 2002 17:03:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 022FF5DDD3; Wed, 11 Sep 2002 17:03:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 992EA5DD8C for <[e-mail]>; Wed, 11 Sep 2002 17:03:43 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BL3bm89043; Wed, 11 Sep 2002 14:03:37 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Justin Fletcher <[e-mail]>
Cc: [e-mail], Alex Zinin <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "11 Sep 2002 14:00:35 PDT." <1031778035.8884.19.camel@riga> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 14:03:37 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Justin,

> > >  I thought section 6.2 "Processing Messages on a Stream Protocol"
> > >  actually talked about these things...
> > > 
> > > -- 
> > > Alex
> > 
> > 
> > A you suggesting we turn the terse reminder in the appendix into a
> > full TCP programming tutorial?
> > 
> > Maybe we should just change that section to.
> > 
> >   6.2  Processing Messages on a Stream Protocol
> > 
> >      BGP uses TCP as a transport mechanism.  If you are unsure as to
> >      how to handle asynchronous reads and writes on TCP sockets please
> >      refer to Unix Network Programming [RWStevens] or other
> >      introductory text for programming techniques for the operating
> >      system and TCP implementation that you are using.
> > 
> > That would save having to rewrite major parts of Stevens work into the
> > BGP spec.
> > 
> > Curtis
> 
> Perhaps the entire section should be deleted as beyond scope.

That would be fine too.

Yakov.


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 RAA26570 for <[e-mail]>; Wed, 11 Sep 2002 17:05:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4EC24913C5; Wed, 11 Sep 2002 17:04:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D52E913C3; Wed, 11 Sep 2002 17:04:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E0E2E913CA for <[e-mail]>; Wed, 11 Sep 2002 17:04:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CB4EA5DDD3; Wed, 11 Sep 2002 17:04:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 594DD5DD8C for <[e-mail]>; Wed, 11 Sep 2002 17:04:15 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA05302; Wed, 11 Sep 2002 17:04:10 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA19573; Wed, 11 Sep 2002 17:04:12 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DR6DZ>; Wed, 11 Sep 2002 17:04:11 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Justin Fletcher'" <[e-mail]>, [e-mail]
Cc: Alex Zinin <[e-mail]>, Yakov Rekhter <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 17:04:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

At some point the wisdom of the day was to put this in. Now its too
implementation specific, and people want to remove it. When in fact 
everyone who builds BGP code does it this way.

I see no reason why section Appendix 6.2 should be deleted. 

Thank You,
Ben

> -----Original Message-----
> From: Justin Fletcher [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 5:01 PM
> To: [e-mail]
> Cc: Alex Zinin; Yakov Rekhter; Abarbanel, Benjamin
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> On Wed, 2002-09-11 at 13:30, Curtis Villamizar wrote:
> > 
> > In message <[e-mail]>, Alex Zinin writes:
> > > Yakov, Ben-
> > > 
> > >  I thought section 6.2 "Processing Messages on a Stream Protocol"
> > >  actually talked about these things...
> > > 
> > > -- 
> > > Alex
> > 
> > 
> > A you suggesting we turn the terse reminder in the appendix into a
> > full TCP programming tutorial?
> > 
> > Maybe we should just change that section to.
> > 
> >   6.2  Processing Messages on a Stream Protocol
> > 
> >      BGP uses TCP as a transport mechanism.  If you are unsure as to
> >      how to handle asynchronous reads and writes on TCP 
> sockets please
> >      refer to Unix Network Programming [RWStevens] or other
> >      introductory text for programming techniques for the operating
> >      system and TCP implementation that you are using.
> > 
> > That would save having to rewrite major parts of Stevens 
> work into the
> > BGP spec.
> > 
> > Curtis
> 
> Perhaps the entire section should be deleted as beyond scope.
> 
> Justin Fletcher
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA26468 for <[e-mail]>; Wed, 11 Sep 2002 17:02:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A691F91344; Wed, 11 Sep 2002 17:01:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CEA75913C0; Wed, 11 Sep 2002 17:01:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B994491344 for <[e-mail]>; Wed, 11 Sep 2002 17:00:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9906B5DDD1; Wed, 11 Sep 2002 17:00:38 -0400 (EDT)
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 503775DD8C for <[e-mail]>; Wed, 11 Sep 2002 17:00:38 -0400 (EDT)
Received: from riga ([10.0.0.25]) by earthquake.proficient.net with Microsoft SMTPSVC(5.0.2195.4905); Wed, 11 Sep 2002 14:00:36 -0700
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
From: Justin Fletcher <[e-mail]>
To: [e-mail]
Cc: Alex Zinin <[e-mail]>, Yakov Rekhter <[e-mail]>, "Abarbanel,     Benjamin" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) 
Date: 11 Sep 2002 14:00:35 -0700
Message-Id: <1031778035.8884.19.camel@riga>
Mime-Version: 1.0
X-OriginalArrivalTime: 11 Sep 2002 21:00:36.0777 (UTC) FILETIME=[46EF8190:01C259D6]
Sender: [e-mail]
Precedence: bulk

On Wed, 2002-09-11 at 13:30, Curtis Villamizar wrote:
> 
> In message <[e-mail]>, Alex Zinin writes:
> > Yakov, Ben-
> > 
> >  I thought section 6.2 "Processing Messages on a Stream Protocol"
> >  actually talked about these things...
> > 
> > -- 
> > Alex
> 
> 
> A you suggesting we turn the terse reminder in the appendix into a
> full TCP programming tutorial?
> 
> Maybe we should just change that section to.
> 
>   6.2  Processing Messages on a Stream Protocol
> 
>      BGP uses TCP as a transport mechanism.  If you are unsure as to
>      how to handle asynchronous reads and writes on TCP sockets please
>      refer to Unix Network Programming [RWStevens] or other
>      introductory text for programming techniques for the operating
>      system and TCP implementation that you are using.
> 
> That would save having to rewrite major parts of Stevens work into the
> BGP spec.
> 
> Curtis

Perhaps the entire section should be deleted as beyond scope.

Justin Fletcher




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA26086 for <[e-mail]>; Wed, 11 Sep 2002 16:51:24 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4AB6891345; Wed, 11 Sep 2002 16:51:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 057C2913C0; Wed, 11 Sep 2002 16:51:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0A59391345 for <[e-mail]>; Wed, 11 Sep 2002 16:51:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E1EC95DDDB; Wed, 11 Sep 2002 16:51:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 6D64A5DD8C for <[e-mail]>; Wed, 11 Sep 2002 16:51:03 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA04384; Wed, 11 Sep 2002 16:51:00 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA14873; Wed, 11 Sep 2002 16:51:02 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DRZPL>; Wed, 11 Sep 2002 16:50:34 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Susan Hares'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 16:50:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Thats fine.

Thank you
Ben

> -----Original Message-----
> From: Susan Hares [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 8:27 PM
> To: Abarbanel, Benjamin
> Cc: '[e-mail]'
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> Ben:
> 
> My earlier understanding is that we would add the Route Refresh
> and Capabilities in a 2nd round.  This matches my understanding of the
> charter.
> 
> Sue
> 
> At 10:58 AM 9/11/2002 -0400, Abarbanel, Benjamin wrote:
> >Part I:
> >
> >Editorial Comments:
> >===================
> >1. P. 7 Type: Need to add the new message types such as, Capability
> >Negotiations (RFC2842), Route Refresh, etc.
> >
> >2. P. 9, right after "This document defines the following optional
> >parameters:"
> >Need to mention possible options, such as: Capabilitites (RFC2842),
> >Multiprotocol extensions (RFC2858), Route Refresh (RFC2918).
> >
> >3. P. 13, EGP, are there other EGP protocols other than BGP 
> that are in use?
> >If not, change EGP to BGP.
> >
> >4. P.23, change the following:
> >
> >"The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
> >  links to discriminate among multiple exit or entry points 
> to the same
> >  neighboring AS ..."
> >
> >  To the following:
> >
> >"The MULTI_EXIT_DISC is an optional non-transitive attribute 
> which may be
> >used on external (inter-AS) links to discriminate among 
> multiple exit or
> >entry points to the same neighboring AS ..."
> >
> >5. In section 8, there are a number of Timers, Counters, 
> etc. that need to
> >be explicitly defined before they are used by the FSM. Perhaps these
> >definitions should go in the Glossary section.
> 
> 


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 QAA26055 for <[e-mail]>; Wed, 11 Sep 2002 16:50:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 63A7A913C1; Wed, 11 Sep 2002 16:49:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2135791345; Wed, 11 Sep 2002 16:49:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A6A9F913C0 for <[e-mail]>; Wed, 11 Sep 2002 16:47:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 916385DDB1; Wed, 11 Sep 2002 16:47:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 102985DD8C for <[e-mail]>; Wed, 11 Sep 2002 16:47:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA04252; Wed, 11 Sep 2002 16:47:40 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA14151; Wed, 11 Sep 2002 16:47:42 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DRZ22>; Wed, 11 Sep 2002 16:47:41 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "'John G. Scudder'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 16:47:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id QAA26055

Jonathan:
Jonathan:

Thank You, I thought my memory served me right. Its amazing how people
keep telling me I am wrong and at the end, I usually am right. 
Wow, you made my day.

I have to confess, I have been BGP bread on Cisco way of doing things.

Ben

> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 4:27 PM
> To: 'John G. Scudder'; Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> Abe,
> 
> In reference to:
>  "This rate limiting procedure applies on a per-destination 
> basis, although
> the value of MinRouteAdvertisementInterval is set on a per 
> BGP peer basis.
> 
> Is ok the way it is.  True, "per-destination basis" and "per 
> BGP peer basis"
> are two different things.  The above is saying that the VALUE 
> is set per
> peer.  But separate timers are applied to each route.  When a timer
> (associated with a route) hits the value (associated with a 
> peer) then that
> route may be sent to that peer.
> 
> My understanding of IOS is that there is, in fact, one timer 
> for the whole
> box for all routes and all peers (I think the peers might be 
> out of synch,
> at least it seems to me they should be).  I don't see a CLI 
> cmd for this
> timer (and in fact requiring this timer to be configurable 
> was removed in
> the Draft).  But this is an implementation detail anyway.  
> 
> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]] 
> Sent: Wednesday, September 11, 2002 3:10 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
> 
> At 2:55 PM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >  > >  > At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >>  >>  >6. P. 52, section 9.2.1.1 Change this sentence for clarity,
> >>  >>  >    "This rate limiting procedure applies on a
> >>  per-destination basis,
> >>  >>  >although 
> >>  >>  >     the value of MinRouteAdvertisementInterval is set on a
> >>  >>  per BGP peer
> >>  >>  >basis."
> >>  >>  >
> >>  >>  >  To This:
> >>  >>  >    "This rate limiting procedure applies on a
> >>  per-destination basis,
> >>  >>  >although
> >>  >  > >     the value of MinRouteAdvertisementInterval is set on a
> >>  >>  BGP router (same
> >>  >>  >     value for all peers) basis."
> >>  >>
> >>  >>  I disagree.
> >>  >why?
> >>
> >>  Because the proposed text does not correctly describe current
> >>  implementations.  You are proposing a change to the 
> protocol, not a
> >>  clarification of existing practice.
> >Then tell me how I am wrong.
> 
> I'm sorry but I'm not sure how much plainer I can put it.  The text 
> as written reflects reality for various implementations -- there's a 
> value you can set on a per-peer basis to limit the rate at which you 
> advertise changed routes to that peer.  The text you have proposed 
> says "same value for all peers" in so many words.  In point of fact, 
> implementations need not and typically do not force the same value to 
> be used for all peers.
> 
> >I read "per-destination basis" and "per BGP peer basis" as 
> two different
> >things. The first term, is the neighbor, the second term is 
> our router.
> >If I was wrong then they both have to say either "per 
> destination basis" or
> >"per peer basis" but not both. It confuses the reader, who 
> does not know
> >the protocol that way. Remember, assumptions, are sometimes bad.
> 
> I don't quite follow what your understanding of the original text is. 
> The "destination" being referred to is an NLRI.  This is consistent 
> with how the word "destination" is used throughout the document.  The 
> "BGP peer" referred to is, well, a BGP peer of our router.  If there 
> is further clarification required on this point perhaps we should 
> take it off-list.
> 
> --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 QAA26050 for <[e-mail]>; Wed, 11 Sep 2002 16:50:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9EC1A913C2; Wed, 11 Sep 2002 16:49:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 576BE913C0; Wed, 11 Sep 2002 16:49:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C003B913C5 for <[e-mail]>; Wed, 11 Sep 2002 16:49:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A42365DDDB; Wed, 11 Sep 2002 16:49:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 2E81D5DD8C for <[e-mail]>; Wed, 11 Sep 2002 16:49:41 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA04324; Wed, 11 Sep 2002 16:49:38 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA14430; Wed, 11 Sep 2002 16:49:40 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DRZKL>; Wed, 11 Sep 2002 16:49:39 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "'John G. Scudder'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 16:49:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id QAA26050

 
> 
> Abe,
> 
> In reference to:
>  "This rate limiting procedure applies on a per-destination 
> basis, although
> the value of MinRouteAdvertisementInterval is set on a per 
> BGP peer basis.
> 
> Is ok the way it is.  True, "per-destination basis" and "per 
> BGP peer basis"
> are two different things.  The above is saying that the VALUE 
> is set per
> peer.  But separate timers are applied to each route.  When a timer
> (associated with a route) hits the value (associated with a 
> peer) then that
> route may be sent to that peer.
> 
> My understanding of IOS is that there is, in fact, one timer 
> for the whole
> box for all routes and all peers (I think the peers might be 
> out of synch,
> at least it seems to me they should be).  I don't see a CLI 
> cmd for this
> timer (and in fact requiring this timer to be configurable 
> was removed in
> the Draft).  But this is an implementation detail anyway.  
> 

Then maybe, the configurable assumption of whether its per route, 
peer, or box should be removed from the spec.

Ben

> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]] 
> Sent: Wednesday, September 11, 2002 3:10 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
> 
> At 2:55 PM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >  > >  > At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >>  >>  >6. P. 52, section 9.2.1.1 Change this sentence for clarity,
> >>  >>  >    "This rate limiting procedure applies on a
> >>  per-destination basis,
> >>  >>  >although 
> >>  >>  >     the value of MinRouteAdvertisementInterval is set on a
> >>  >>  per BGP peer
> >>  >>  >basis."
> >>  >>  >
> >>  >>  >  To This:
> >>  >>  >    "This rate limiting procedure applies on a
> >>  per-destination basis,
> >>  >>  >although
> >>  >  > >     the value of MinRouteAdvertisementInterval is set on a
> >>  >>  BGP router (same
> >>  >>  >     value for all peers) basis."
> >>  >>
> >>  >>  I disagree.
> >>  >why?
> >>
> >>  Because the proposed text does not correctly describe current
> >>  implementations.  You are proposing a change to the 
> protocol, not a
> >>  clarification of existing practice.
> >Then tell me how I am wrong.
> 
> I'm sorry but I'm not sure how much plainer I can put it.  The text 
> as written reflects reality for various implementations -- there's a 
> value you can set on a per-peer basis to limit the rate at which you 
> advertise changed routes to that peer.  The text you have proposed 
> says "same value for all peers" in so many words.  In point of fact, 
> implementations need not and typically do not force the same value to 
> be used for all peers.
> 
> >I read "per-destination basis" and "per BGP peer basis" as 
> two different
> >things. The first term, is the neighbor, the second term is 
> our router.
> >If I was wrong then they both have to say either "per 
> destination basis" or
> >"per peer basis" but not both. It confuses the reader, who 
> does not know
> >the protocol that way. Remember, assumptions, are sometimes bad.
> 
> I don't quite follow what your understanding of the original text is. 
> The "destination" being referred to is an NLRI.  This is consistent 
> with how the word "destination" is used throughout the document.  The 
> "BGP peer" referred to is, well, a BGP peer of our router.  If there 
> is further clarification required on this point perhaps we should 
> take it off-list.
> 
> --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 QAA25656 for <[e-mail]>; Wed, 11 Sep 2002 16:39:06 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5D4A291340; Wed, 11 Sep 2002 16:38:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E4B43913C2; Wed, 11 Sep 2002 16:38:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8143D913C1 for <[e-mail]>; Wed, 11 Sep 2002 16:38:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6993B5DDDB; Wed, 11 Sep 2002 16:38:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id C0F2D5DD8C for <[e-mail]>; Wed, 11 Sep 2002 16:38:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA03664; Wed, 11 Sep 2002 16:38:40 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA12833; Wed, 11 Sep 2002 16:38:42 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DRY95>; Wed, 11 Sep 2002 16:38:41 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
Date: Wed, 11 Sep 2002 16:38:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Curtis:
 Its already in the spec look at Appendix 6.2 from day one.

Thank You,
Ben

> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 4:08 PM
> To: Abarbanel, Benjamin
> Cc: 'Yakov Rekhter'; '[e-mail]'
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> 
> 
> 
> In message 
> <[e-mail]>, 
> "Abarbanel, Benjamin" writes:
> > Yakov:
> >   That may be true, but I have seen in a couple of BGP 
> implementations
> > handling the socket level that the BGP code had to 
> reassemble the logical
> > packet. TCP did not do it. 
> > 
> > What I mean the application code had to read from the 
> socket several times
> > to get the entire packet and reassemble it, before passing 
> it to the BGP
> > state 
> > machine.
> > 
> > Ben
> 
> 
> Ben,
> 
> This is C network coding 101.  It doesn't need to be in the spec.  If
> you know how to write C code for sockets for any purpose, it can be
> applied to BGP.
> 
> We also shouldn't have to specify that writes should be non-blocking.
> 
> We also don't need to specify that you should watch for EWOULDBLOCK on
> writes and that some OS retrun EAGAIN instead.
> 
> We also don't need to specify that EWOULDBLOCK is broken on some
> versions of some OS (not an *ix) and doesn't write anything if the
> whole write doesn't fit in the available socket buffer.
> 
> We don't need to explain that after a partial read rather than hang on
> the socket waiting for more input you should use the select system
> call, or the poll system call for sys5ish OS, or whatever m$soft uses.
> 
> ... etc.
> 
> 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 QAA25596 for <[e-mail]>; Wed, 11 Sep 2002 16:37:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 72236913BC; Wed, 11 Sep 2002 16:36:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3157F913C0; Wed, 11 Sep 2002 16:36:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 24100913BC for <[e-mail]>; Wed, 11 Sep 2002 16:36:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0ECE35DDD1; Wed, 11 Sep 2002 16:36:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 828115DD8C for <[e-mail]>; Wed, 11 Sep 2002 16:36:36 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA03563; Wed, 11 Sep 2002 16:36:34 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA12356; Wed, 11 Sep 2002 16:36:36 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DRY7F>; Wed, 11 Sep 2002 16:36:35 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 16:36:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

You guys are pretty funny, some extensions are OK to cover in this spec and
others are not. Comon, give me break.

Ben

> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 3:44 PM
> To: 'Abarbanel, Benjamin'; Natale, Jonathan; '[e-mail]'
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> 1. Aahhh...DYNAMIC capabability.  So this makes me say that 
> this is beyond
> the scope of the base doc.
> 
> 3. EGP is a messy historical thing, not sure what we can do (ask ISP
> folks???)
> 
> 4. No, the "optional non-transitive" type descriptions are in another
> section.
> 
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Wednesday, September 11, 2002 2:01 PM
> To: 'Natale, Jonathan'; Abarbanel, Benjamin; '[e-mail]'
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
> 
> Natale:
> 
> > 
> > (your page nums are wrong)
> > 
> > 1. agree, but cap. Is not a msg type
>  
> This is taken from draft-ietf-idr-dynamic-cap-02.txt:
> 
> "5. Capability Message
> 
>    The CAPABILITY Message is a new BGP message type with type code 6.
>    In addition to the fixed-size BGP header [BGP-4], the CAPABILITY
>    message contains one or more of the following tuples:"
> 
> > 2. agree
> > 3. disagree, but maybe:
> > IGP = network was explicitly introduced into bgp (network cmd)
> > INCOMPLETE = network was implicitly introduced into bgp 
> (redistribute)
> > EGP = other
> > Also, maybe a discussion/reference on how this is used in 
> > decision process.
> > (I have seen folks infer that EGP == EBGP, so this has been a 
> > source of
> > confusion.  May add a note that this is historic???  What do 
> > operators use
> > Origin = EGP for??? (comments?))
> 
> To make a long story short, there is no other EGP in use other BGP
> so why bother mentioning it. I dont hear anyone calling for another
> EGP protocol as a standard Inter-AS protocol.
> 
> As far as I know the original EGP protocol was flawed and BGP 
> corrected
> a number of problems. So why bother with it?
> 
> > 4. disagree (covered elsewhere)
> >
> How can you disagree with this? This is what MED is. All 
> other attributes
> have the type described in the same place where I want MED to do.
> 
> Ben  
> > -----Original Message-----
> > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > Sent: Wednesday, September 11, 2002 10:59 AM
> > To: '[e-mail]'
> > Subject: Review of draft-ietf-idr-bgp4-17.txt
> > 
> > Part I:
> > 
> > Editorial Comments:
> > ===================
> > 1. P. 7 Type: Need to add the new message types such as, Capability
> > Negotiations (RFC2842), Route Refresh, etc.
> > 
> > 2. P. 9, right after "This document defines the following optional
> > parameters:"
> > Need to mention possible options, such as: Capabilitites (RFC2842),
> > Multiprotocol extensions (RFC2858), Route Refresh (RFC2918).
> > 
> > 3. P. 13, EGP, are there other EGP protocols other than BGP 
> > that are in use?
> > If not, change EGP to BGP.
> > 
> > 4. P.23, change the following: 
> > 
> > "The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
> >  links to discriminate among multiple exit or entry points 
> to the same
> >  neighboring AS ..."
> > 
> >  To the following:
> > 
> > "The MULTI_EXIT_DISC is an optional non-transitive attribute 
> > which may be
> > used on external (inter-AS) links to discriminate among 
> > multiple exit or
> > entry points to the same neighboring AS ..."
> > 
> > 5. In section 8, there are a number of Timers, Counters, etc. 
> > that need to
> > be explicitly defined before they are used by the FSM. Perhaps these
> > definitions should go in the Glossary section.
> > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA25548 for <[e-mail]>; Wed, 11 Sep 2002 16:35:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BAE5F913B4; Wed, 11 Sep 2002 16:35:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84457913C0; Wed, 11 Sep 2002 16:35:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B98FF913B4 for <[e-mail]>; Wed, 11 Sep 2002 16:35:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A1FA25DDEB; Wed, 11 Sep 2002 16:35:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id E3E995DDDB for <[e-mail]>; Wed, 11 Sep 2002 16:35:23 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA03494; Wed, 11 Sep 2002 16:35:21 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA11946; Wed, 11 Sep 2002 16:35:21 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DRYY1>; Wed, 11 Sep 2002 16:35:20 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'John G. Scudder'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 16:35:19 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id QAA25548

OK, 



> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 3:10 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> At 2:55 PM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >  > >  > At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >>  >>  >6. P. 52, section 9.2.1.1 Change this sentence for clarity,
> >>  >>  >    "This rate limiting procedure applies on a
> >>  per-destination basis,
> >>  >>  >although 
> >>  >>  >     the value of MinRouteAdvertisementInterval is set on a
> >>  >>  per BGP peer
> >>  >>  >basis."
> >>  >>  >
> >>  >>  >  To This:
> >>  >>  >    "This rate limiting procedure applies on a
> >>  per-destination basis,
> >>  >>  >although
> >>  >  > >     the value of MinRouteAdvertisementInterval is set on a
> >>  >>  BGP router (same
> >>  >>  >     value for all peers) basis."
> >>  >>
> >>  >>  I disagree.
> >>  >why?
> >>
> >>  Because the proposed text does not correctly describe current
> >>  implementations.  You are proposing a change to the 
> protocol, not a
> >>  clarification of existing practice.
> >Then tell me how I am wrong.
> 
> I'm sorry but I'm not sure how much plainer I can put it.  The text 
> as written reflects reality for various implementations -- there's a 
> value you can set on a per-peer basis to limit the rate at which you 
> advertise changed routes to that peer.  The text you have proposed 
> says "same value for all peers" in so many words.  In point of fact, 
> implementations need not and typically do not force the same value to 
> be used for all peers.
> 
> >I read "per-destination basis" and "per BGP peer basis" as 
> two different
> >things. The first term, is the neighbor, the second term is 
> our router.
> >If I was wrong then they both have to say either "per 
> destination basis" or
> >"per peer basis" but not both. It confuses the reader, who 
> does not know
> >the protocol that way. Remember, assumptions, are sometimes bad.
> 
> I don't quite follow what your understanding of the original text is. 
> The "destination" being referred to is an NLRI.  This is consistent 
> with how the word "destination" is used throughout the document.  The 
> "BGP peer" referred to is, well, a BGP peer of our router.  If there 
> is further clarification required on this point perhaps we should 
> take it off-list.
> 
> --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 QAA25543 for <[e-mail]>; Wed, 11 Sep 2002 16:35:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B663D913BB; Wed, 11 Sep 2002 16:34:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 173E9913B4; Wed, 11 Sep 2002 16:34:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98787913BB for <[e-mail]>; Wed, 11 Sep 2002 16:32:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 831CB5DDDB; Wed, 11 Sep 2002 16:32:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id E876E5DDD1 for <[e-mail]>; Wed, 11 Sep 2002 16:32:19 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BKW0m86058; Wed, 11 Sep 2002 13:32:00 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: Alex Zinin <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 16:30:11 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 13:32:00 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Curtis,

> In message <[e-mail]>, Alex Zinin writes:
> > Yakov, Ben-
> > 
> >  I thought section 6.2 "Processing Messages on a Stream Protocol"
> >  actually talked about these things...
> > 
> > -- 
> > Alex
> 
> 
> A you suggesting we turn the terse reminder in the appendix into a
> full TCP programming tutorial?
> 
> Maybe we should just change that section to.
> 
>   6.2  Processing Messages on a Stream Protocol
> 
>      BGP uses TCP as a transport mechanism.  If you are unsure as to
>      how to handle asynchronous reads and writes on TCP sockets please
>      refer to Unix Network Programming [RWStevens] or other
>      introductory text for programming techniques for the operating
>      system and TCP implementation that you are using.
> 
> That would save having to rewrite major parts of Stevens work into the
> BGP spec.

Seems like an excellent suggestions !!!

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 QAA25516 for <[e-mail]>; Wed, 11 Sep 2002 16:35:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 12A3E913B8; Wed, 11 Sep 2002 16:31:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F251A913BB; Wed, 11 Sep 2002 16:31:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 524EC913B8 for <[e-mail]>; Wed, 11 Sep 2002 16:31:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E612E5DDD1; Wed, 11 Sep 2002 16:31:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from laptoy770.fictitious.org (unknown [209.150.1.238]) by segue.merit.edu (Postfix) with ESMTP id E8AF85DD8C for <[e-mail]>; Wed, 11 Sep 2002 16:31:46 -0400 (EDT)
Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.11.2/8.11.2) with ESMTP id g8BKWW841991; Wed, 11 Sep 2002 16:32:32 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-reply-to: Your message of "Wed, 11 Sep 2002 08:48:20 PDT." <[e-mail]> 
Date: Wed, 11 Sep 2002 16:32:32 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Yakov Rekhter writes
:
> Ben,
> 
> > I realize if we do what I suggest, there will have to be a transition
> > period where the two types are in the same message as well as separate
> > messages. If they are in the same message, we need to keep the existing
> > rules, until everyone (?) upgrades, then we can obsolete these rules.
> 
> Please bear in mind that the spec is about what is *currently* deployed.
> As such any change to the base spec that required upgrades/transition
> is outside the scope of the current discussion.
> 
> Yakov.


If no one other than Ben sees reason to change this I suggest we
declare consensus on this with one disenting opinion and move on.

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 QAA25367 for <[e-mail]>; Wed, 11 Sep 2002 16:29:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CE134913B3; Wed, 11 Sep 2002 16:29:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94DCB913B4; Wed, 11 Sep 2002 16:29:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 50C3F913B3 for <[e-mail]>; Wed, 11 Sep 2002 16:29:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3C9A75DDDB; Wed, 11 Sep 2002 16:29:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from laptoy770.fictitious.org (unknown [209.150.1.238]) by segue.merit.edu (Postfix) with ESMTP id 398955DD8C for <[e-mail]>; Wed, 11 Sep 2002 16:29:33 -0400 (EDT)
Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.11.2/8.11.2) with ESMTP id g8BKUB841972; Wed, 11 Sep 2002 16:30:11 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, "Abarbanel,     Benjamin" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-reply-to: Your message of "Wed, 11 Sep 2002 17:40:00 +0200." <[e-mail]> 
Date: Wed, 11 Sep 2002 16:30:11 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Alex Zinin writes:
> Yakov, Ben-
> 
>  I thought section 6.2 "Processing Messages on a Stream Protocol"
>  actually talked about these things...
> 
> -- 
> Alex


A you suggesting we turn the terse reminder in the appendix into a
full TCP programming tutorial?

Maybe we should just change that section to.

  6.2  Processing Messages on a Stream Protocol

     BGP uses TCP as a transport mechanism.  If you are unsure as to
     how to handle asynchronous reads and writes on TCP sockets please
     refer to Unix Network Programming [RWStevens] or other
     introductory text for programming techniques for the operating
     system and TCP implementation that you are using.

That would save having to rewrite major parts of Stevens work into the
BGP spec.

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 QAA25306 for <[e-mail]>; Wed, 11 Sep 2002 16:27:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 59207913B2; Wed, 11 Sep 2002 16:27:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A11A913B3; Wed, 11 Sep 2002 16:27:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B186913B2 for <[e-mail]>; Wed, 11 Sep 2002 16:27:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3014A5DDD3; Wed, 11 Sep 2002 16:27:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id D5B765DD8C for <[e-mail]>; Wed, 11 Sep 2002 16:27:19 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CKG3>; Wed, 11 Sep 2002 16:27:19 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'John G. Scudder'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 16:27:11 -0400
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id QAA25306

Abe,

In reference to:
 "This rate limiting procedure applies on a per-destination basis, although
the value of MinRouteAdvertisementInterval is set on a per BGP peer basis.

Is ok the way it is.  True, "per-destination basis" and "per BGP peer basis"
are two different things.  The above is saying that the VALUE is set per
peer.  But separate timers are applied to each route.  When a timer
(associated with a route) hits the value (associated with a peer) then that
route may be sent to that peer.

My understanding of IOS is that there is, in fact, one timer for the whole
box for all routes and all peers (I think the peers might be out of synch,
at least it seems to me they should be).  I don't see a CLI cmd for this
timer (and in fact requiring this timer to be configurable was removed in
the Draft).  But this is an implementation detail anyway.  

-----Original Message-----
From: John G. Scudder [mailto:[e-mail]] 
Sent: Wednesday, September 11, 2002 3:10 PM
To: Abarbanel, Benjamin
Cc: [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt

At 2:55 PM -0400 9/11/02, Abarbanel, Benjamin wrote:
>  > >  > At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>>  >>  >6. P. 52, section 9.2.1.1 Change this sentence for clarity,
>>  >>  >    "This rate limiting procedure applies on a
>>  per-destination basis,
>>  >>  >although 
>>  >>  >     the value of MinRouteAdvertisementInterval is set on a
>>  >>  per BGP peer
>>  >>  >basis."
>>  >>  >
>>  >>  >  To This:
>>  >>  >    "This rate limiting procedure applies on a
>>  per-destination basis,
>>  >>  >although
>>  >  > >     the value of MinRouteAdvertisementInterval is set on a
>>  >>  BGP router (same
>>  >>  >     value for all peers) basis."
>>  >>
>>  >>  I disagree.
>>  >why?
>>
>>  Because the proposed text does not correctly describe current
>>  implementations.  You are proposing a change to the protocol, not a
>>  clarification of existing practice.
>Then tell me how I am wrong.

I'm sorry but I'm not sure how much plainer I can put it.  The text 
as written reflects reality for various implementations -- there's a 
value you can set on a per-peer basis to limit the rate at which you 
advertise changed routes to that peer.  The text you have proposed 
says "same value for all peers" in so many words.  In point of fact, 
implementations need not and typically do not force the same value to 
be used for all peers.

>I read "per-destination basis" and "per BGP peer basis" as two different
>things. The first term, is the neighbor, the second term is our router.
>If I was wrong then they both have to say either "per destination basis" or
>"per peer basis" but not both. It confuses the reader, who does not know
>the protocol that way. Remember, assumptions, are sometimes bad.

I don't quite follow what your understanding of the original text is. 
The "destination" being referred to is an NLRI.  This is consistent 
with how the word "destination" is used throughout the document.  The 
"BGP peer" referred to is, well, a BGP peer of our router.  If there 
is further clarification required on this point perhaps we should 
take it off-list.

--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 QAA25283 for <[e-mail]>; Wed, 11 Sep 2002 16:27:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 276CE9133F; Wed, 11 Sep 2002 16:27:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EAD54913B2; Wed, 11 Sep 2002 16:27:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 267E69133F for <[e-mail]>; Wed, 11 Sep 2002 16:27:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 153A25DDE1; Wed, 11 Sep 2002 16:27:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 50F9F5DDD3 for <[e-mail]>; Wed, 11 Sep 2002 16:27:00 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8BKQxY67647; Wed, 11 Sep 2002 16:26:59 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([65.241.132.110]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g8BKQtG67640; Wed, 11 Sep 2002 16:26:55 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 11 Sep 2002 20:26:54 -0400
To: "Abarbanel, Benjamin" <[e-mail]>
From: Susan Hares <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail] re.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Ben:

My earlier understanding is that we would add the Route Refresh
and Capabilities in a 2nd round.  This matches my understanding of the
charter.

Sue

At 10:58 AM 9/11/2002 -0400, Abarbanel, Benjamin wrote:
>Part I:
>
>Editorial Comments:
>===================
>1. P. 7 Type: Need to add the new message types such as, Capability
>Negotiations (RFC2842), Route Refresh, etc.
>
>2. P. 9, right after "This document defines the following optional
>parameters:"
>Need to mention possible options, such as: Capabilitites (RFC2842),
>Multiprotocol extensions (RFC2858), Route Refresh (RFC2918).
>
>3. P. 13, EGP, are there other EGP protocols other than BGP that are in use?
>If not, change EGP to BGP.
>
>4. P.23, change the following:
>
>"The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
>  links to discriminate among multiple exit or entry points to the same
>  neighboring AS ..."
>
>  To the following:
>
>"The MULTI_EXIT_DISC is an optional non-transitive attribute which may be
>used on external (inter-AS) links to discriminate among multiple exit or
>entry points to the same neighboring AS ..."
>
>5. In section 8, there are a number of Timers, Counters, etc. that need to
>be explicitly defined before they are used by the FSM. Perhaps these
>definitions should go in the Glossary section.




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 QAA25104 for <[e-mail]>; Wed, 11 Sep 2002 16:23:24 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 92B53913B7; Wed, 11 Sep 2002 16:22:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7366913B4; Wed, 11 Sep 2002 16:22:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 863F9913B8 for <[e-mail]>; Wed, 11 Sep 2002 16:21:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 62AE45DDD3; Wed, 11 Sep 2002 16:21:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from laptoy770.fictitious.org (unknown [209.150.1.238]) by segue.merit.edu (Postfix) with ESMTP id E39795DD8C for <[e-mail]>; Wed, 11 Sep 2002 16:21:39 -0400 (EDT)
Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.11.2/8.11.2) with ESMTP id g8BKML841948; Wed, 11 Sep 2002 16:22:21 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, "'Kaarthik Sivakumar'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-reply-to: Your message of "Wed, 11 Sep 2002 11:38:36 EDT." <[e-mail]> 
Date: Wed, 11 Sep 2002 16:22:21 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> I realize if we do what I suggest, there will have to be a transition
> period where the two types are in the same message as well as separate
> messages. If they are in the same message, we need to keep the existing
> rules, until everyone (?) upgrades, then we can obsolete these rules.
> 
> Ben


The existing rules are very clear.

Summarized:

  If an UPDATE contains only a withdraw for a prefix, then withdraw
  whatever route the peer had previously sent.

  If an UPDATE contains the prefix only in the NRLI section, replace
  whatever route had previously been advertised by the peer or add a
  route if there was no previous route, in both cases adding a route
  with the current attributes.

  Don't put the same prefix in the same in both the withdraw and NRLI
  section of the same update.

  If you receive an UPDATE with the same prefix in both the withdraw
  and NRLI, ignore the withdraw.  [Some older implementations thought
  this was a good way to say "delete then add".]

  Process UPDATEs from the same peer in the order received.

These are the existing rules and we have found no reason to change
them in almost a decade of use.  If they are not written down clearly
there could be reason to clarify the text, but that doesn't seem to be
the case.

Curtis


> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Wednesday, September 11, 2002 11:34 AM
> > To: Abarbanel, Benjamin
> > Cc: 'Kaarthik Sivakumar'; '[e-mail]'
> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> > 
> > 
> > Ben,
> > 
> > > No it means if they are placed in different messages and 
> > sent in the order 
> > > that the source router wants the destination router to 
> > execute them. 
> > > 
> > > It just makes the messages simpler, requiring less rules of 
> > processing.
> > 
> > it also makes the case where they are in the same message unspecified.
> >   
> > > Ben
> > > 
> > > > -----Original Message-----
> > > > From: Kaarthik Sivakumar [mailto:[e-mail]]
> > > > Sent: Wednesday, September 11, 2002 11:12 AM
> > > > To: Abarbanel, Benjamin
> > > > Cc: '[e-mail]'
> > > > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> > > > 
> > > > 
> > > > >>> "BA" == Benjamin Abarbanel <Abarbanel> writes:
> > > > 
> > > > [...]
> > > > 
> > > > BA> 4. P.16, last paragraph in section 4.3 as stated,
> > > > BA>  "An UPDATE message should not include the same address 
> > > > prefix in the
> > > > BA>   WITHDRAWN ROUTES and Network Layer Reachability 
> > > > Information fields,
> > > > BA>   however a BGP speaker MUST be able to process UPDATE 
> > > > messages in this
> > > > BA>   form. A BGP speaker should treat an UPDATE message of 
> > > > this form as if
> > > > BA>   the WITHDRAWN ROUTES doesn't contain the address prefix."
> > > >               
> > > > BA> This complexity could have been avoided if withdrawn 
> > > > routes and NRLI
> > > > BA> prefixes with their attributes were mutually exclusive of 
> > > > each other and
> > > > BA> appeared in different update messages. If that was the 
> > > > case, the priority of
> > > > BA> which field to process first would have been as simple as 
> > > > using "first come,
> > > > BA> first served" message processing approach.
> > > > 
> > > > What you suggest isnt the same as what is there now. The 
> > draft says
> > > > that NLRI has higher preference to a WITHDRAWN prefix and 
> > this makes
> > > > the behavior predictable. In what you suggest the behavior isnt
> > > > predictable. Or is it? Hmm .. Maybe I am mistaken here, 
> > but it doesnt
> > > > seem like the same thing.
> > > > 
> > > > Kaarthik
> > > > 
> > 
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA24587 for <[e-mail]>; Wed, 11 Sep 2002 16:07:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A67D091336; Wed, 11 Sep 2002 16:07:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61067913B2; Wed, 11 Sep 2002 16:07:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CDB7F91336 for <[e-mail]>; Wed, 11 Sep 2002 16:07:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B7E7E5DDD1; Wed, 11 Sep 2002 16:07:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from laptoy770.fictitious.org (unknown [209.150.1.238]) by segue.merit.edu (Postfix) with ESMTP id D87AA5DD8C for <[e-mail]>; Wed, 11 Sep 2002 16:07:08 -0400 (EDT)
Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.11.2/8.11.2) with ESMTP id g8BK7r841913; Wed, 11 Sep 2002 16:07:53 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-reply-to: Your message of "Wed, 11 Sep 2002 11:30:29 EDT." <[e-mail]> 
Date: Wed, 11 Sep 2002 16:07:53 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> Yakov:
>   That may be true, but I have seen in a couple of BGP implementations
> handling the socket level that the BGP code had to reassemble the logical
> packet. TCP did not do it. 
> 
> What I mean the application code had to read from the socket several times
> to get the entire packet and reassemble it, before passing it to the BGP
> state 
> machine.
> 
> Ben


Ben,

This is C network coding 101.  It doesn't need to be in the spec.  If
you know how to write C code for sockets for any purpose, it can be
applied to BGP.

We also shouldn't have to specify that writes should be non-blocking.

We also don't need to specify that you should watch for EWOULDBLOCK on
writes and that some OS retrun EAGAIN instead.

We also don't need to specify that EWOULDBLOCK is broken on some
versions of some OS (not an *ix) and doesn't write anything if the
whole write doesn't fit in the available socket buffer.

We don't need to explain that after a partial read rather than hang on
the socket waiting for more input you should use the select system
call, or the poll system call for sys5ish OS, or whatever m$soft uses.

... etc.

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 PAA24085 for <[e-mail]>; Wed, 11 Sep 2002 15:53:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5CA0F91327; Wed, 11 Sep 2002 15:52:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29DDF9132E; Wed, 11 Sep 2002 15:52:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1E3F491327 for <[e-mail]>; Wed, 11 Sep 2002 15:52:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E84E35DDA4; Wed, 11 Sep 2002 15:52:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 1292C5DD8C for <[e-mail]>; Wed, 11 Sep 2002 15:52:51 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8BJqmR66507; Wed, 11 Sep 2002 15:52:48 -0400 (EDT) (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 g8BJqjG66500; Wed, 11 Sep 2002 15:52:45 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8BJqj503093; Wed, 11 Sep 2002 15:52:45 -0400 (EDT)
Date: Wed, 11 Sep 2002 15:52:45 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.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 Wed, Sep 11, 2002 at 03:43:36PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 11, 2002 at 03:43:36PM -0400, Natale, Jonathan wrote:
> 3. EGP is a messy historical thing, not sure what we can do (ask ISP
> folks???)

As best I've heard, no EGP is still being run.  So, its worth
adding the footnote reference in the section on Origin to 
clarify that its historical.

-- 
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 PAA23789 for <[e-mail]>; Wed, 11 Sep 2002 15:44:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B55D2913AE; Wed, 11 Sep 2002 15:43:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86037913AF; Wed, 11 Sep 2002 15:43:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 25C80913AE for <[e-mail]>; Wed, 11 Sep 2002 15:43:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0C57B5DDC2; Wed, 11 Sep 2002 15:43:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id B22CB5DDB1 for <[e-mail]>; Wed, 11 Sep 2002 15:43:38 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CJ0P>; Wed, 11 Sep 2002 15:43:38 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 15:43:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

1. Aahhh...DYNAMIC capabability.  So this makes me say that this is beyond
the scope of the base doc.

3. EGP is a messy historical thing, not sure what we can do (ask ISP
folks???)

4. No, the "optional non-transitive" type descriptions are in another
section.

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Wednesday, September 11, 2002 2:01 PM
To: 'Natale, Jonathan'; Abarbanel, Benjamin; '[e-mail]'
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt

Natale:

> 
> (your page nums are wrong)
> 
> 1. agree, but cap. Is not a msg type
 
This is taken from draft-ietf-idr-dynamic-cap-02.txt:

"5. Capability Message

   The CAPABILITY Message is a new BGP message type with type code 6.
   In addition to the fixed-size BGP header [BGP-4], the CAPABILITY
   message contains one or more of the following tuples:"

> 2. agree
> 3. disagree, but maybe:
> IGP = network was explicitly introduced into bgp (network cmd)
> INCOMPLETE = network was implicitly introduced into bgp (redistribute)
> EGP = other
> Also, maybe a discussion/reference on how this is used in 
> decision process.
> (I have seen folks infer that EGP == EBGP, so this has been a 
> source of
> confusion.  May add a note that this is historic???  What do 
> operators use
> Origin = EGP for??? (comments?))

To make a long story short, there is no other EGP in use other BGP
so why bother mentioning it. I dont hear anyone calling for another
EGP protocol as a standard Inter-AS protocol.

As far as I know the original EGP protocol was flawed and BGP corrected
a number of problems. So why bother with it?

> 4. disagree (covered elsewhere)
>
How can you disagree with this? This is what MED is. All other attributes
have the type described in the same place where I want MED to do.

Ben  
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Wednesday, September 11, 2002 10:59 AM
> To: '[e-mail]'
> Subject: Review of draft-ietf-idr-bgp4-17.txt
> 
> Part I:
> 
> Editorial Comments:
> ===================
> 1. P. 7 Type: Need to add the new message types such as, Capability
> Negotiations (RFC2842), Route Refresh, etc.
> 
> 2. P. 9, right after "This document defines the following optional
> parameters:"
> Need to mention possible options, such as: Capabilitites (RFC2842),
> Multiprotocol extensions (RFC2858), Route Refresh (RFC2918).
> 
> 3. P. 13, EGP, are there other EGP protocols other than BGP 
> that are in use?
> If not, change EGP to BGP.
> 
> 4. P.23, change the following: 
> 
> "The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
>  links to discriminate among multiple exit or entry points to the same
>  neighboring AS ..."
> 
>  To the following:
> 
> "The MULTI_EXIT_DISC is an optional non-transitive attribute 
> which may be
> used on external (inter-AS) links to discriminate among 
> multiple exit or
> entry points to the same neighboring AS ..."
> 
> 5. In section 8, there are a number of Timers, Counters, etc. 
> that need to
> be explicitly defined before they are used by the FSM. Perhaps these
> definitions should go in the Glossary section.
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA22709 for <[e-mail]>; Wed, 11 Sep 2002 15:12:15 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EE341913AC; Wed, 11 Sep 2002 15:10:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AEFDC913B0; Wed, 11 Sep 2002 15:10:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CB74913AC for <[e-mail]>; Wed, 11 Sep 2002 15:10:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5A4325DDC2; Wed, 11 Sep 2002 15:10:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id 9DC105DDB1 for <[e-mail]>; Wed, 11 Sep 2002 15:10:20 -0400 (EDT)
Received: from [192.168.42.10] (dhcp-171-69-182-131.cisco.com [171.69.182.131]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA20148; Wed, 11 Sep 2002 15:10:18 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a44b9a542fb6b15@[192.168.42.10]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 11 Sep 2002 15:10:13 -0400
To: "Abarbanel, Benjamin" <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Cc: [e-mail]
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id PAA22709

At 2:55 PM -0400 9/11/02, Abarbanel, Benjamin wrote:
>  > >  > At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>>  >>  >6. P. 52, section 9.2.1.1 Change this sentence for clarity,
>>  >>  >    "This rate limiting procedure applies on a
>>  per-destination basis,
>>  >>  >although 
>>  >>  >     the value of MinRouteAdvertisementInterval is set on a
>>  >>  per BGP peer
>>  >>  >basis."
>>  >>  >
>>  >>  >  To This:
>>  >>  >    "This rate limiting procedure applies on a
>>  per-destination basis,
>>  >>  >although
>>  >  > >     the value of MinRouteAdvertisementInterval is set on a
>>  >>  BGP router (same
>>  >>  >     value for all peers) basis."
>>  >>
>>  >>  I disagree.
>>  >why?
>>
>>  Because the proposed text does not correctly describe current
>>  implementations.  You are proposing a change to the protocol, not a
>>  clarification of existing practice.
>Then tell me how I am wrong.

I'm sorry but I'm not sure how much plainer I can put it.  The text 
as written reflects reality for various implementations -- there's a 
value you can set on a per-peer basis to limit the rate at which you 
advertise changed routes to that peer.  The text you have proposed 
says "same value for all peers" in so many words.  In point of fact, 
implementations need not and typically do not force the same value to 
be used for all peers.

>I read "per-destination basis" and "per BGP peer basis" as two different
>things. The first term, is the neighbor, the second term is our router.
>If I was wrong then they both have to say either "per destination basis" or
>"per peer basis" but not both. It confuses the reader, who does not know
>the protocol that way. Remember, assumptions, are sometimes bad.

I don't quite follow what your understanding of the original text is. 
The "destination" being referred to is an NLRI.  This is consistent 
with how the word "destination" is used throughout the document.  The 
"BGP peer" referred to is, well, a BGP peer of our router.  If there 
is further clarification required on this point perhaps we should 
take it off-list.

--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 PAA22429 for <[e-mail]>; Wed, 11 Sep 2002 15:06:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 48E3C91320; Wed, 11 Sep 2002 15:06:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1417F913A8; Wed, 11 Sep 2002 15:06:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B593291320 for <[e-mail]>; Wed, 11 Sep 2002 15:06:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A5B655DDB1; Wed, 11 Sep 2002 15:06:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 9FF8F5DD8C for <[e-mail]>; Wed, 11 Sep 2002 15:06:07 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CJZ3>; Wed, 11 Sep 2002 15:06:07 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 15:06:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Agreed, it should be fixed.  I still don't think we need to discuss
re-assembly, but if it is there, fine. (maybe I missed the whole point)

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Wednesday, September 11, 2002 2:56 PM
To: 'John G. Scudder'; Abarbanel, Benjamin
Cc: [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt

Thank You

Ben

> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 2:51 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> At 2:43 PM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >The point is the application has to reassemble the packet, not TCP.
> 
> I think the crux of the confusion is in the use of the word "packet". 
> BGP doesn't know from packets, which have a specific network-layer 
> meaning.  It uses messages, or what some folks like to call protocol 
> data units (PDUs).
> 
> So actually, there is something to be fixed here.  In section 4.3, 
> second line of first paragraph, s/UPDATE packet/UPDATE message/. 
> That's the only misuse of "packet" I found in a quick grep of the 
> document.
> 
> --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 OAA22115 for <[e-mail]>; Wed, 11 Sep 2002 14:56:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A8EB09132A; Wed, 11 Sep 2002 14:56:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70640913A7; Wed, 11 Sep 2002 14:56:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1B5ED9132A for <[e-mail]>; Wed, 11 Sep 2002 14:56:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0AB305DDA4; Wed, 11 Sep 2002 14:56:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 8B0515DDA2 for <[e-mail]>; Wed, 11 Sep 2002 14:56:29 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA27799; Wed, 11 Sep 2002 14:56:27 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA23096; Wed, 11 Sep 2002 14:56:28 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DRTPQ>; Wed, 11 Sep 2002 14:56:27 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'John G. Scudder'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 14:56:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Thank You

Ben

> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 2:51 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> At 2:43 PM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >The point is the application has to reassemble the packet, not TCP.
> 
> I think the crux of the confusion is in the use of the word "packet". 
> BGP doesn't know from packets, which have a specific network-layer 
> meaning.  It uses messages, or what some folks like to call protocol 
> data units (PDUs).
> 
> So actually, there is something to be fixed here.  In section 4.3, 
> second line of first paragraph, s/UPDATE packet/UPDATE message/. 
> That's the only misuse of "packet" I found in a quick grep of the 
> document.
> 
> --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 OAA22070 for <[e-mail]>; Wed, 11 Sep 2002 14:55:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1ADC29131F; Wed, 11 Sep 2002 14:55:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D835291323; Wed, 11 Sep 2002 14:55:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C06149131F for <[e-mail]>; Wed, 11 Sep 2002 14:55:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id AC5295DDA2; Wed, 11 Sep 2002 14:55:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 36D5A5DD8C for <[e-mail]>; Wed, 11 Sep 2002 14:55:26 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA27730; Wed, 11 Sep 2002 14:55:23 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA22888; Wed, 11 Sep 2002 14:55:25 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DRTNX>; Wed, 11 Sep 2002 14:55:24 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'John G. Scudder'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 14:55:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id OAA22070

John:

> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 2:44 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> At 1:27 PM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >  > At 10:45 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >>  >5. P. 20 Its not stated how we delete or modify Path
> >>  Attributes associated
> >>  >with NLRI prefixes.
> >>
> >>  This is implicit in the definition of "route", which discussion I
> >>  will not repeat here, plus withdraw/replace behavior.  
> IMO we don't
> >>  need to further belabor the point in the spec (which is 
> already wordy
> >>  enough and then some).
> >>
> >I disagree, there is an assumption how one would delete or 
> replace say
> >optional attributes, but no direct way of doing it.
> 
> True that there is no direct way of doing it.  There are a lot of 
> other things that can't be done in BGP.  I don't think we need to 
> start listing them or we'll never be done.  (Oh, too late for that!)
> 
I think its a fair request, if there are cases like this they should be
documented as well, as Yakov, said describe what is done.

> >  > At 10:58 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >>  >3. P. 13, EGP, are there other EGP protocols other than BGP
> >>  that are in use?
> >>  >If not, change EGP to BGP.
> >>
> >>  From the references section:
> >>
> >>      [1] Mills, D., "Exterior Gateway Protocol Formal 
> Specification",
> >>      RFC904, April 1984.
> >>
> >>  I suppose it might not hurt to stick a "[1]" in the origin code
> >>  section to add clarity.  The conflation of EGP-the-protocol and
> >>  EGP-the-class-of-protocols is unfortunate, but we're stuck with it
> >  > now.
> >>
> >Yes, but does anyone use this form of EGP?
> 
> I very much doubt it but that in no way detracts from the fact that 
> that _is_ what the code means, for historic reasons related to the 
> transition from an EGP-based Internet to a BGP-based one.
> 
I very believe the Chair wants to document what is, not what is historical.

> In essence the origin code is just another way of biasing a route's 
> preference, and is used as such in operation.
> 
> >  > At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >>  >6. P. 52, section 9.2.1.1 Change this sentence for clarity,
> >>  >    "This rate limiting procedure applies on a 
> per-destination basis,
> >>  >although 
> >>  >     the value of MinRouteAdvertisementInterval is set on a
> >>  per BGP peer
> >>  >basis."
> >>  >
> >>  >  To This:
> >>  >    "This rate limiting procedure applies on a 
> per-destination basis,
> >>  >although
> >  > >     the value of MinRouteAdvertisementInterval is set on a
> >>  BGP router (same
> >>  >     value for all peers) basis."
> >>
> >>  I disagree.
> >why?
> 
> Because the proposed text does not correctly describe current 
> implementations.  You are proposing a change to the protocol, not a 
> clarification of existing practice.
Then tell me how I am wrong. 

I read "per-destination basis" and "per BGP peer basis" as two different
things. The first term, is the neighbor, the second term is our router. 
If I was wrong then they both have to say either "per destination basis" or
"per peer basis" but not both. It confuses the reader, who does not know
the protocol that way. Remember, assumptions, are sometimes bad.

Ben
 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA21974 for <[e-mail]>; Wed, 11 Sep 2002 14:52:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D7C9C9131B; Wed, 11 Sep 2002 14:52:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A70E39131F; Wed, 11 Sep 2002 14:52:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9559F9131B for <[e-mail]>; Wed, 11 Sep 2002 14:52:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 74B605DDC6; Wed, 11 Sep 2002 14:52:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id AAC5A5DDA2 for <[e-mail]>; Wed, 11 Sep 2002 14:52:17 -0400 (EDT)
Received: from [192.168.42.10] (dhcp-171-69-182-131.cisco.com [171.69.182.131]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA19390; Wed, 11 Sep 2002 14:52:15 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a42b9a53fa2a211@[192.168.42.10]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 11 Sep 2002 14:51:21 -0400
To: "Abarbanel, Benjamin" <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 2:43 PM -0400 9/11/02, Abarbanel, Benjamin wrote:
>The point is the application has to reassemble the packet, not TCP.

I think the crux of the confusion is in the use of the word "packet". 
BGP doesn't know from packets, which have a specific network-layer 
meaning.  It uses messages, or what some folks like to call protocol 
data units (PDUs).

So actually, there is something to be fixed here.  In section 4.3, 
second line of first paragraph, s/UPDATE packet/UPDATE message/. 
That's the only misuse of "packet" I found in a quick grep of the 
document.

--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 OAA21695 for <[e-mail]>; Wed, 11 Sep 2002 14:44:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 56EDF913A4; Wed, 11 Sep 2002 14:44:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD813913A7; Wed, 11 Sep 2002 14:44:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C33F8913A4 for <[e-mail]>; Wed, 11 Sep 2002 14:44:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B284A5DE5E; Wed, 11 Sep 2002 14:44:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id EA1D55DDA2 for <[e-mail]>; Wed, 11 Sep 2002 14:44:04 -0400 (EDT)
Received: from [192.168.42.10] (dhcp-171-69-182-131.cisco.com [171.69.182.131]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA19030; Wed, 11 Sep 2002 14:43:56 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a3fb9a5397e31c2@[192.168.42.10]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 11 Sep 2002 14:43:51 -0400
To: "Abarbanel, Benjamin" <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Cc: [e-mail]
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id OAA21695

At 1:27 PM -0400 9/11/02, Abarbanel, Benjamin wrote:
>  > At 10:45 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>>  >5. P. 20 Its not stated how we delete or modify Path
>>  Attributes associated
>>  >with NLRI prefixes.
>>
>>  This is implicit in the definition of "route", which discussion I
>>  will not repeat here, plus withdraw/replace behavior.  IMO we don't
>>  need to further belabor the point in the spec (which is already wordy
>>  enough and then some).
>>
>I disagree, there is an assumption how one would delete or replace say
>optional attributes, but no direct way of doing it.

True that there is no direct way of doing it.  There are a lot of 
other things that can't be done in BGP.  I don't think we need to 
start listing them or we'll never be done.  (Oh, too late for that!)

>  > At 10:58 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>>  >3. P. 13, EGP, are there other EGP protocols other than BGP
>>  that are in use?
>>  >If not, change EGP to BGP.
>>
>>  From the references section:
>>
>>      [1] Mills, D., "Exterior Gateway Protocol Formal Specification",
>>      RFC904, April 1984.
>>
>>  I suppose it might not hurt to stick a "[1]" in the origin code
>>  section to add clarity.  The conflation of EGP-the-protocol and
>>  EGP-the-class-of-protocols is unfortunate, but we're stuck with it
>  > now.
>>
>Yes, but does anyone use this form of EGP?

I very much doubt it but that in no way detracts from the fact that 
that _is_ what the code means, for historic reasons related to the 
transition from an EGP-based Internet to a BGP-based one.

In essence the origin code is just another way of biasing a route's 
preference, and is used as such in operation.

>  > At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>>  >6. P. 52, section 9.2.1.1 Change this sentence for clarity,
>>  >    "This rate limiting procedure applies on a per-destination basis,
>>  >although 
>>  >     the value of MinRouteAdvertisementInterval is set on a
>>  per BGP peer
>>  >basis."
>>  >
>>  >  To This:
>>  >    "This rate limiting procedure applies on a per-destination basis,
>>  >although
>  > >     the value of MinRouteAdvertisementInterval is set on a
>>  BGP router (same
>>  >     value for all peers) basis."
>>
>>  I disagree.
>why?

Because the proposed text does not correctly describe current 
implementations.  You are proposing a change to the protocol, not a 
clarification of existing practice.

--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 OAA21687 for <[e-mail]>; Wed, 11 Sep 2002 14:44:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4269D91319; Wed, 11 Sep 2002 14:43:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D94C9131D; Wed, 11 Sep 2002 14:43:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1A5AB91319 for <[e-mail]>; Wed, 11 Sep 2002 14:43:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 01D7E5DE5E; Wed, 11 Sep 2002 14:43:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 8151E5DDA2 for <[e-mail]>; Wed, 11 Sep 2002 14:43:42 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA26759; Wed, 11 Sep 2002 14:43:40 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA19715; Wed, 11 Sep 2002 14:43:42 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DRSPR>; Wed, 11 Sep 2002 14:43:41 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
Date: Wed, 11 Sep 2002 14:43:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

The point is the application has to reassemble the packet, not TCP.

It is well covered in section 6.2 Appendix 6.

Ben

BTW. The smoke and dust has already settled on this point. I agree to
say I have no issue, other than to ask that a pointer to Appendix 6.2
be placed in the place where I saw it was missing.

> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 2:38 PM
> To: 'Abarbanel, Benjamin'; 'Yakov Rekhter'
> Cc: '[e-mail]'
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
> 
> 
> Huh?  Seems like a violation of basic TCP concepts!  Do you 
> mean the entire
> MESSAGE?  That would make sense and I think the draft already 
> mentions that
> you should not do anything until the whole msg is read.  It should be
> understood (from TCP concepts) that the msg can get chopped up and/or
> concatenated.  Maybe I missed the point.
> 
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Wednesday, September 11, 2002 11:30 AM
> To: 'Yakov Rekhter'; Abarbanel, Benjamin
> Cc: '[e-mail]'
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
> 
> Yakov:
>   That may be true, but I have seen in a couple of BGP implementations
> handling the socket level that the BGP code had to reassemble 
> the logical
> packet. TCP did not do it. 
> 
> What I mean the application code had to read from the socket 
> several times
> to get the entire packet and reassemble it, before passing it 
> to the BGP
> state 
> machine.
> 
> Ben
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Wednesday, September 11, 2002 11:26 AM
> > To: Abarbanel, Benjamin
> > Cc: '[e-mail]'
> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> > 
> > 
> > Ben,
> > 
> > > Part I.
> > > 
> > > Technical Comments:
> > > ===================
> > > 1. P.6  section 4. Message Formats, its possible for the 
> > source BGP peer IP
> > > layer to fragment a message such that the receiving BGP 
> > peer socket layer
> > > would have to reassemble it. Need to mention this, since 
> > BGP implementations
> > > are required to do this.  
> > 
> > *BGP* implementations are *not* required to perform any 
> > message reassembly.
> > (remember this is BGP spec, not TCP and/or IP spec).
> > 
> > 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 OAA21613 for <[e-mail]>; Wed, 11 Sep 2002 14:41:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 894F2913A9; Wed, 11 Sep 2002 14:38:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 52761913A8; Wed, 11 Sep 2002 14:38:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A2CF913A7 for <[e-mail]>; Wed, 11 Sep 2002 14:38:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 584715DE5E; Wed, 11 Sep 2002 14:38:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id D1D815DDA2 for <[e-mail]>; Wed, 11 Sep 2002 14:38:42 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA26442; Wed, 11 Sep 2002 14:38:35 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA18812; Wed, 11 Sep 2002 14:38:36 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DRS2F>; Wed, 11 Sep 2002 14:38:35 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 14:38:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Jeff:
 My comments for the future changes are not based on EGO but Common 
Sense. Sometimes, experience == Common_Sense.

I am not saying that all the great BGP Wizards of the decade could not
think of it, just that no one raised them as issues.

End of Editorial
Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 2:35 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> On Wed, Sep 11, 2002 at 02:14:17PM -0400, Abarbanel, Benjamin wrote:
> > Wishfull thinking is how things get started. Otherwise
> > no one ever knows that there is a better way to do 
> something. I am not
> > suggesting it be done now, but maybe in the future. Perhaps 
> they should
> > be kept as future things. 
> 
> "Nobody, but nobody, who attempts to bend the entire world to his
> will could possibly be accused of having a small ego.
> 
> "The reasonable man adapts himself to the world; the unreasonable
> one persists in trying to adapt the world to himself.  Therefore
> all progress depends on the unreasonable man."
>                 -- George Bernard Shaw
> 
> I keep waiting for Allegro to make a shirt that replaces "world"
> with "BGP specification".
> 
> -- 
> 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 OAA21513 for <[e-mail]>; Wed, 11 Sep 2002 14:38:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1615991315; Wed, 11 Sep 2002 14:38:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D046B91316; Wed, 11 Sep 2002 14:38:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3CA9891315 for <[e-mail]>; Wed, 11 Sep 2002 14:38:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2972F5DE5E; Wed, 11 Sep 2002 14:38:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id B03365DDA2 for <[e-mail]>; Wed, 11 Sep 2002 14:38:06 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CJTB>; Wed, 11 Sep 2002 14:38:06 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
Date: Wed, 11 Sep 2002 14:38:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Huh?  Seems like a violation of basic TCP concepts!  Do you mean the entire
MESSAGE?  That would make sense and I think the draft already mentions that
you should not do anything until the whole msg is read.  It should be
understood (from TCP concepts) that the msg can get chopped up and/or
concatenated.  Maybe I missed the point.

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Wednesday, September 11, 2002 11:30 AM
To: 'Yakov Rekhter'; Abarbanel, Benjamin
Cc: '[e-mail]'
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 

Yakov:
  That may be true, but I have seen in a couple of BGP implementations
handling the socket level that the BGP code had to reassemble the logical
packet. TCP did not do it. 

What I mean the application code had to read from the socket several times
to get the entire packet and reassemble it, before passing it to the BGP
state 
machine.

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 11:26 AM
> To: Abarbanel, Benjamin
> Cc: '[e-mail]'
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> 
> 
> Ben,
> 
> > Part I.
> > 
> > Technical Comments:
> > ===================
> > 1. P.6  section 4. Message Formats, its possible for the 
> source BGP peer IP
> > layer to fragment a message such that the receiving BGP 
> peer socket layer
> > would have to reassemble it. Need to mention this, since 
> BGP implementations
> > are required to do this.  
> 
> *BGP* implementations are *not* required to perform any 
> message reassembly.
> (remember this is BGP spec, not TCP and/or IP spec).
> 
> 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 OAA21370 for <[e-mail]>; Wed, 11 Sep 2002 14:35:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 33ADA913A6; Wed, 11 Sep 2002 14:34:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E67A8913AE; Wed, 11 Sep 2002 14:34:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C3968913A6 for <[e-mail]>; Wed, 11 Sep 2002 14:34:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id AC4445DDE5; Wed, 11 Sep 2002 14:34:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id DD3A05DDA2 for <[e-mail]>; Wed, 11 Sep 2002 14:34:34 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8BIYX863760; Wed, 11 Sep 2002 14:34:33 -0400 (EDT) (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 g8BIYUG63753; Wed, 11 Sep 2002 14:34:30 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8BIYUh02472; Wed, 11 Sep 2002 14:34:30 -0400 (EDT)
Date: Wed, 11 Sep 2002 14:34:30 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.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 Wed, Sep 11, 2002 at 02:14:17PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 11, 2002 at 02:14:17PM -0400, Abarbanel, Benjamin wrote:
> Wishfull thinking is how things get started. Otherwise
> no one ever knows that there is a better way to do something. I am not
> suggesting it be done now, but maybe in the future. Perhaps they should
> be kept as future things. 

"Nobody, but nobody, who attempts to bend the entire world to his
will could possibly be accused of having a small ego.

"The reasonable man adapts himself to the world; the unreasonable
one persists in trying to adapt the world to himself.  Therefore
all progress depends on the unreasonable man."
                -- George Bernard Shaw

I keep waiting for Allegro to make a shirt that replaces "world"
with "BGP specification".

-- 
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 OAA21114 for <[e-mail]>; Wed, 11 Sep 2002 14:26:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3B5339139F; Wed, 11 Sep 2002 14:26:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08438913A2; Wed, 11 Sep 2002 14:26:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6B229139F for <[e-mail]>; Wed, 11 Sep 2002 14:26:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BCED45DE59; Wed, 11 Sep 2002 14:26:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 026F45DDA2 for <[e-mail]>; Wed, 11 Sep 2002 14:26:11 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8BIQ7n63370; Wed, 11 Sep 2002 14:26:07 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([65.241.132.110]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g8BIQ3G63362; Wed, 11 Sep 2002 14:26:03 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 11 Sep 2002 18:26:02 -0400
To: "Tom Petch" <[e-mail]>
From: Susan Hares <[e-mail]>
Subject: Re: FSM words - state changes
Cc: "idr" <[e-mail]>, "Susan Hares" <[e-mail]>, "yakov Rekhter" <[e-mail]>, <[e-mail]>, <[e-mail]>, "randy Bush" <[e-mail]>
In-Reply-To: <013801c259b9$f84839e0$0301a8c0@tom3>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Tom:

Would you send the specific text you are referring to?
You can send it to me privately if you wish.

Sue

At 06:36 PM 9/11/2002 +0100, Tom Petch wrote:
>In most places, the actions taken on the receipt of an event include
>what the new state will be or that it remains unchanged.  But there
>are a signficant number of places where this is not done (eg Connect
>state events 14, 15, 16).  I would like to see consistency, always
>specify the new/unchanged state.  Else I may be misreading it.
>
>I can give you a list if you want or else you put in all you can find
>and I will feedback any apparent omissions.
>
>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 OAA21030 for <[e-mail]>; Wed, 11 Sep 2002 14:23:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 19103913A5; Wed, 11 Sep 2002 14:22:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9FA1913AC; Wed, 11 Sep 2002 14:22:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AECA0913A5 for <[e-mail]>; Wed, 11 Sep 2002 14:22:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 908085DE59; Wed, 11 Sep 2002 14:22:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 1CA085DDA2 for <[e-mail]>; Wed, 11 Sep 2002 14:22:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA25433; Wed, 11 Sep 2002 14:22:40 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA15932; Wed, 11 Sep 2002 14:22:42 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DRRNX>; Wed, 11 Sep 2002 14:22:41 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
Date: Wed, 11 Sep 2002 14:22:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov,

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 2:20 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> 
> 
> Ben,
> 
> > > From: Yakov Rekhter [mailto:[e-mail]]
> > > Sent: Wednesday, September 11, 2002 2:05 PM
> > > To: Abarbanel, Benjamin
> > > Cc: [e-mail]
> > > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> > > 
> > > 
> > > Ben,
> > > 
> > > > > As a general comment, if you are going to split up your 
> > > remarks into 
> > > > > many tiny messages it would be very helpful if you would use 
> > > > > descriptive subjects.  Also, FYI you seem to have an 
> > > off-by-one error 
> > > > > in your reading of the page numbers.
> > > > >
> > > > Then I would need to place each item in a separate message, 
> > > as you saw
> > > > I grouped them as 5 issues per message. Per request 
> from the ADS.
> > > > The subjects they cover could vary thus making the 
> > > description not bound to
> > > > one thing. Sorry.
> > > > 
> > > > I used the page number printed on the page not the word 
> > > processor generated
> > > > one. If I missed it, sorry.
> > > >  
> > > > > This message aggregates my replies to all your 
> messages with the 
> > > > > subject "Review of draft-ietf-idr-bgp4-17.txt".
> > > > > 
> > > > > At 10:35 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > > > > >4. In many places in the document the term Transport 
> > > > > Connection is used, and
> > > > > >in the FSM area the term TCP Connection is used. One generic 
> > > > > term should be
> > > > > >used   throughout the document in case a different transport 
> > > > > (like SCTP) is
> > > > > >used to service the BGP sessions.
> > > > > 
> > > > > As Yakov mentioned earlier, BGP is not actually 
> > > > > transport-independent.  This might equally well argue 
> in favor of 
> > > > > dropping the "transport connection" pretense and just 
> > > saying "TCP" 
> > > > > throughout (applies to the FSM too, BTW).
> > > > > 
> > > > In the FSM draft, there is an effort to abstract things to 
> > > only mention
> > > > "transport connection" not "TCP", in this spec its the 
> > > other way around. We
> > > > clearly need a common way of describing the transport 
> layer in all
> > > > BGP protocol related specs.
> > > 
> > > Please ask the author(s) of the FSM draft to use TCP.
> > >   
> > If the author who happens to be the Co Chair is reading 
> this message.
> > The job is done already.
> > 
> > > > > A future protocol based on BGP 4 might be transport 
> independent 
> > > > > and/or run over SCTP, but I think that is far beyond 
> our current 
> > > > > scope.
> > > >  
> > > > Agreed, but IMHO, the BGP spec should describe the protocol 
> > > independent
> > > > of its use of the TCP layer and its details. But I think,
> > > > its so dependent on it now, that you almost have to redo 
> > > the BGP protocol
> > > > description to use a different transport layer (SCTP).  
> > > 
> > > With this in mind can we keep the comments focuses on 
> > > reality, and not 
> > > on what one would wish for.
> > >   
> > > [clipped...]
> > > 
> > > > > At 10:45 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > > > > >This complexity could have been avoided if withdrawn 
> > > routes and NRLI
> > > > > >prefixes with their attributes were mutually exclusive of 
> > > > > each other and
> > > > > >appeared in different update messages. If that was the case, 
> > > > > the priority of
> > > > > >which field to process first would have been as simple as 
> > > > > using "first come,
> > > > > >first served" message processing approach.
> > > > > 
> > > > > If wishes were horses, beggars would ride.  There are 
> > > plenty of ugly 
> > > > > bits of the protocol which I'd change if we had a clean 
> > > slate.  But 
> > > > > surely something this fundamental to the operation of the 
> > > > > protocol-as-deployed is not open for revision right now?
> > > >  
> > > > I threw this one out, just to see if anything can be done. 
> > > Knowing full 
> > > > well you guys will do nothing. But we can wish can't we?
> > > 
> > > One can certainly wish, but this is outside the scope of 
> the current
> > > discussion. So, while commenting on the base spec please avoid
> > > including wishes in your comments.
> > >   
> > > [clipped...]
> > > 
> > > > > At 10:52 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > > > > >4. P. 31, section 6.8, Please rewrite this sentence from:
> > > > > >    "Comparing BGP Identifiers is done by treating them as 
> > > > > >     (4-octet long) unsigned integers."
> > > > > >  To This:
> > > > > >    "Comparing BGP Identifiers is done by treating them as 
> > > > > >     large numbers based
> > > > > >     on their IP Address type (e.g. IPv4, IPv6, etc.)."
> > > > > 
> > > > > The BGP identifier is a 4-byte quantity, not a variable 
> > > quantity.  I 
> > > > > think the sentence is fine as written.
> > > > >
> > > > I was thinking of IPv6 in which case a message format 
> > > change would be
> > > > required. My thinking is based on using full IPv6 routable 
> > > addresses 
> > > > for the BGP Identifier. 
> > > 
> > > Since it requires message format change, it is outside the scope
> > > of the current discussion. 
> > >
> > > > BTW I do not agree with the IPv6 Router-ID draft proposed 
> > > by someone.
> > > 
> > > What that has to do with the comments on the base BGP spec ?
> > 
> > Nothing, just an opinion on what was proposed.
> >  
> > > Yakov.
> > >
> > 
> > Wishfull thinking is how things get started. Otherwise
> > no one ever knows that there is a better way to do 
> something. I am not
> > suggesting it be done now, but maybe in the future. Perhaps 
> they should
> > be kept as future things. 
> 
> Or perhaps they should be kept as future comments (to be 
> posted to the list
> once we'll finish with the base spec).
> 
Thats fine.

Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA21021 for <[e-mail]>; Wed, 11 Sep 2002 14:23:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E62F39139A; Wed, 11 Sep 2002 14:21:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A12B0913A3; Wed, 11 Sep 2002 14:21:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 591359139A for <[e-mail]>; Wed, 11 Sep 2002 14:21:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4286F5DE59; Wed, 11 Sep 2002 14:21:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id AC2955DDA2 for <[e-mail]>; Wed, 11 Sep 2002 14:21:25 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BILGm71149; Wed, 11 Sep 2002 11:21:16 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, "'John G. Scudder'" <[e-mail]>, [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 14:15:25 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 11:21:16 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> > Ben and John,
> > 
> > [clipped...]
> > 
> > > > At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > > > >8. Since there is going to be an FSM spec, do we need to have FSM
> > > > >    descriptions in this spec. Maybe the FSM section should 
> > > > be delete.
> > > > 
> > > > Yep.
> > > > 
> > > OK.
> > 
> > Just to make clear, are you suggesting to take section 8 ("8. 
> > BGP Finite State machine.") out of the base spec draft ?
> > 
> Yes, or when the FSM draft becomes a WG document.

I'd like to hear comments from the ADs (Alex and Bill) on this proposal.

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 OAA20860 for <[e-mail]>; Wed, 11 Sep 2002 14:20:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 91A1D913A0; Wed, 11 Sep 2002 14:20:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED0B4913A2; Wed, 11 Sep 2002 14:20:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AFC26913A0 for <[e-mail]>; Wed, 11 Sep 2002 14:19:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7D8735DDEE; Wed, 11 Sep 2002 14:19:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id E44D15DDA2 for <[e-mail]>; Wed, 11 Sep 2002 14:19:53 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BIJpm70986; Wed, 11 Sep 2002 11:19:51 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 14:14:17 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 11:19:51 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Wednesday, September 11, 2002 2:05 PM
> > To: Abarbanel, Benjamin
> > Cc: [e-mail]
> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> > 
> > 
> > Ben,
> > 
> > > > As a general comment, if you are going to split up your 
> > remarks into 
> > > > many tiny messages it would be very helpful if you would use 
> > > > descriptive subjects.  Also, FYI you seem to have an 
> > off-by-one error 
> > > > in your reading of the page numbers.
> > > >
> > > Then I would need to place each item in a separate message, 
> > as you saw
> > > I grouped them as 5 issues per message. Per request from the ADS.
> > > The subjects they cover could vary thus making the 
> > description not bound to
> > > one thing. Sorry.
> > > 
> > > I used the page number printed on the page not the word 
> > processor generated
> > > one. If I missed it, sorry.
> > >  
> > > > This message aggregates my replies to all your messages with the 
> > > > subject "Review of draft-ietf-idr-bgp4-17.txt".
> > > > 
> > > > At 10:35 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > > > >4. In many places in the document the term Transport 
> > > > Connection is used, and
> > > > >in the FSM area the term TCP Connection is used. One generic 
> > > > term should be
> > > > >used   throughout the document in case a different transport 
> > > > (like SCTP) is
> > > > >used to service the BGP sessions.
> > > > 
> > > > As Yakov mentioned earlier, BGP is not actually 
> > > > transport-independent.  This might equally well argue in favor of 
> > > > dropping the "transport connection" pretense and just 
> > saying "TCP" 
> > > > throughout (applies to the FSM too, BTW).
> > > > 
> > > In the FSM draft, there is an effort to abstract things to 
> > only mention
> > > "transport connection" not "TCP", in this spec its the 
> > other way around. We
> > > clearly need a common way of describing the transport layer in all
> > > BGP protocol related specs.
> > 
> > Please ask the author(s) of the FSM draft to use TCP.
> >   
> If the author who happens to be the Co Chair is reading this message.
> The job is done already.
> 
> > > > A future protocol based on BGP 4 might be transport independent 
> > > > and/or run over SCTP, but I think that is far beyond our current 
> > > > scope.
> > >  
> > > Agreed, but IMHO, the BGP spec should describe the protocol 
> > independent
> > > of its use of the TCP layer and its details. But I think,
> > > its so dependent on it now, that you almost have to redo 
> > the BGP protocol
> > > description to use a different transport layer (SCTP).  
> > 
> > With this in mind can we keep the comments focuses on 
> > reality, and not 
> > on what one would wish for.
> >   
> > [clipped...]
> > 
> > > > At 10:45 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > > > >This complexity could have been avoided if withdrawn 
> > routes and NRLI
> > > > >prefixes with their attributes were mutually exclusive of 
> > > > each other and
> > > > >appeared in different update messages. If that was the case, 
> > > > the priority of
> > > > >which field to process first would have been as simple as 
> > > > using "first come,
> > > > >first served" message processing approach.
> > > > 
> > > > If wishes were horses, beggars would ride.  There are 
> > plenty of ugly 
> > > > bits of the protocol which I'd change if we had a clean 
> > slate.  But 
> > > > surely something this fundamental to the operation of the 
> > > > protocol-as-deployed is not open for revision right now?
> > >  
> > > I threw this one out, just to see if anything can be done. 
> > Knowing full 
> > > well you guys will do nothing. But we can wish can't we?
> > 
> > One can certainly wish, but this is outside the scope of the current
> > discussion. So, while commenting on the base spec please avoid
> > including wishes in your comments.
> >   
> > [clipped...]
> > 
> > > > At 10:52 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > > > >4. P. 31, section 6.8, Please rewrite this sentence from:
> > > > >    "Comparing BGP Identifiers is done by treating them as 
> > > > >     (4-octet long) unsigned integers."
> > > > >  To This:
> > > > >    "Comparing BGP Identifiers is done by treating them as 
> > > > >     large numbers based
> > > > >     on their IP Address type (e.g. IPv4, IPv6, etc.)."
> > > > 
> > > > The BGP identifier is a 4-byte quantity, not a variable 
> > quantity.  I 
> > > > think the sentence is fine as written.
> > > >
> > > I was thinking of IPv6 in which case a message format 
> > change would be
> > > required. My thinking is based on using full IPv6 routable 
> > addresses 
> > > for the BGP Identifier. 
> > 
> > Since it requires message format change, it is outside the scope
> > of the current discussion. 
> >
> > > BTW I do not agree with the IPv6 Router-ID draft proposed 
> > by someone.
> > 
> > What that has to do with the comments on the base BGP spec ?
> 
> Nothing, just an opinion on what was proposed.
>  
> > Yakov.
> >
> 
> Wishfull thinking is how things get started. Otherwise
> no one ever knows that there is a better way to do something. I am not
> suggesting it be done now, but maybe in the future. Perhaps they should
> be kept as future things. 

Or perhaps they should be kept as future comments (to be posted to the list
once we'll finish with the base spec).

Yakov.


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 OAA20854 for <[e-mail]>; Wed, 11 Sep 2002 14:20:15 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C68E59139B; Wed, 11 Sep 2002 14:19:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4D839139F; Wed, 11 Sep 2002 14:19:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 675279139B for <[e-mail]>; Wed, 11 Sep 2002 14:17:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4C3F15DDE5; Wed, 11 Sep 2002 14:17:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id C48AD5DDA2 for <[e-mail]>; Wed, 11 Sep 2002 14:17:35 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA24764; Wed, 11 Sep 2002 14:17:33 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA12701; Wed, 11 Sep 2002 14:17:28 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DRQQ9>; Wed, 11 Sep 2002 14:15:26 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'John G. Scudder'" <[e-mail]>, [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
Date: Wed, 11 Sep 2002 14:15:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov:
 
> Ben and John,
> 
> [clipped...]
> 
> > > At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > > >8. Since there is going to be an FSM spec, do we need to have FSM
> > > >    descriptions in this spec. Maybe the FSM section should 
> > > be delete.
> > > 
> > > Yep.
> > > 
> > OK.
> 
> Just to make clear, are you suggesting to take section 8 ("8. 
> BGP Finite 
> State machine.") out of the base spec draft ?
> 
Yes, or when the FSM draft becomes a WG document.

Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA20701 for <[e-mail]>; Wed, 11 Sep 2002 14:14:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4181191397; Wed, 11 Sep 2002 14:14:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C61F9139A; Wed, 11 Sep 2002 14:14:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F339291397 for <[e-mail]>; Wed, 11 Sep 2002 14:14:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CB1605DE61; Wed, 11 Sep 2002 14:14:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 552C85DE3A for <[e-mail]>; Wed, 11 Sep 2002 14:14:20 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA24412; Wed, 11 Sep 2002 14:14:18 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA12016; Wed, 11 Sep 2002 14:14:19 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DRQKK>; Wed, 11 Sep 2002 14:14:18 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
Date: Wed, 11 Sep 2002 14:14:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov:

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 2:05 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> 
> 
> Ben,
> 
> > > As a general comment, if you are going to split up your 
> remarks into 
> > > many tiny messages it would be very helpful if you would use 
> > > descriptive subjects.  Also, FYI you seem to have an 
> off-by-one error 
> > > in your reading of the page numbers.
> > >
> > Then I would need to place each item in a separate message, 
> as you saw
> > I grouped them as 5 issues per message. Per request from the ADS.
> > The subjects they cover could vary thus making the 
> description not bound to
> > one thing. Sorry.
> > 
> > I used the page number printed on the page not the word 
> processor generated
> > one. If I missed it, sorry.
> >  
> > > This message aggregates my replies to all your messages with the 
> > > subject "Review of draft-ietf-idr-bgp4-17.txt".
> > > 
> > > At 10:35 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > > >4. In many places in the document the term Transport 
> > > Connection is used, and
> > > >in the FSM area the term TCP Connection is used. One generic 
> > > term should be
> > > >used   throughout the document in case a different transport 
> > > (like SCTP) is
> > > >used to service the BGP sessions.
> > > 
> > > As Yakov mentioned earlier, BGP is not actually 
> > > transport-independent.  This might equally well argue in favor of 
> > > dropping the "transport connection" pretense and just 
> saying "TCP" 
> > > throughout (applies to the FSM too, BTW).
> > > 
> > In the FSM draft, there is an effort to abstract things to 
> only mention
> > "transport connection" not "TCP", in this spec its the 
> other way around. We
> > clearly need a common way of describing the transport layer in all
> > BGP protocol related specs.
> 
> Please ask the author(s) of the FSM draft to use TCP.
>   
If the author who happens to be the Co Chair is reading this message.
The job is done already.

> > > A future protocol based on BGP 4 might be transport independent 
> > > and/or run over SCTP, but I think that is far beyond our current 
> > > scope.
> >  
> > Agreed, but IMHO, the BGP spec should describe the protocol 
> independent
> > of its use of the TCP layer and its details. But I think,
> > its so dependent on it now, that you almost have to redo 
> the BGP protocol
> > description to use a different transport layer (SCTP).  
> 
> With this in mind can we keep the comments focuses on 
> reality, and not 
> on what one would wish for.
>   
> [clipped...]
> 
> > > At 10:45 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > > >This complexity could have been avoided if withdrawn 
> routes and NRLI
> > > >prefixes with their attributes were mutually exclusive of 
> > > each other and
> > > >appeared in different update messages. If that was the case, 
> > > the priority of
> > > >which field to process first would have been as simple as 
> > > using "first come,
> > > >first served" message processing approach.
> > > 
> > > If wishes were horses, beggars would ride.  There are 
> plenty of ugly 
> > > bits of the protocol which I'd change if we had a clean 
> slate.  But 
> > > surely something this fundamental to the operation of the 
> > > protocol-as-deployed is not open for revision right now?
> >  
> > I threw this one out, just to see if anything can be done. 
> Knowing full 
> > well you guys will do nothing. But we can wish can't we?
> 
> One can certainly wish, but this is outside the scope of the current
> discussion. So, while commenting on the base spec please avoid
> including wishes in your comments.
>   
> [clipped...]
> 
> > > At 10:52 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > > >4. P. 31, section 6.8, Please rewrite this sentence from:
> > > >    "Comparing BGP Identifiers is done by treating them as 
> > > >     (4-octet long) unsigned integers."
> > > >  To This:
> > > >    "Comparing BGP Identifiers is done by treating them as 
> > > >     large numbers based
> > > >     on their IP Address type (e.g. IPv4, IPv6, etc.)."
> > > 
> > > The BGP identifier is a 4-byte quantity, not a variable 
> quantity.  I 
> > > think the sentence is fine as written.
> > >
> > I was thinking of IPv6 in which case a message format 
> change would be
> > required. My thinking is based on using full IPv6 routable 
> addresses 
> > for the BGP Identifier. 
> 
> Since it requires message format change, it is outside the scope
> of the current discussion. 
>
> > BTW I do not agree with the IPv6 Router-ID draft proposed 
> by someone.
> 
> What that has to do with the comments on the base BGP spec ?
>
Nothing, just an opinion on what was proposed.
 
> Yakov.
>

Wishfull thinking is how things get started. Otherwise
no one ever knows that there is a better way to do something. I am not
suggesting it be done now, but maybe in the future. Perhaps they should
be kept as future things. 

Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA20572 for <[e-mail]>; Wed, 11 Sep 2002 14:10:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 487BF91312; Wed, 11 Sep 2002 14:10:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15B9491397; Wed, 11 Sep 2002 14:10:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C361791312 for <[e-mail]>; Wed, 11 Sep 2002 14:09:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A78EF5DE5E; Wed, 11 Sep 2002 14:09:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 1CE615DE5A for <[e-mail]>; Wed, 11 Sep 2002 14:09:59 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BI9gm70096; Wed, 11 Sep 2002 11:09:42 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'John G. Scudder'" <[e-mail]>, [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 13:27:47 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 11:09:42 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben and John,

[clipped...]

> > At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > >8. Since there is going to be an FSM spec, do we need to have FSM
> > >    descriptions in this spec. Maybe the FSM section should 
> > be delete.
> > 
> > Yep.
> > 
> OK.

Just to make clear, are you suggesting to take section 8 ("8. BGP Finite 
State machine.") out of the base spec draft ?

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 OAA20401 for <[e-mail]>; Wed, 11 Sep 2002 14:06:27 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 03E7C91394; Wed, 11 Sep 2002 14:05:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6B5991397; Wed, 11 Sep 2002 14:05:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76C5191394 for <[e-mail]>; Wed, 11 Sep 2002 14:05:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 62E2D5DE5A; Wed, 11 Sep 2002 14:05:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 053D95DE4A for <[e-mail]>; Wed, 11 Sep 2002 14:05:02 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BI50m69553; Wed, 11 Sep 2002 11:05:00 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 13:27:47 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 11:05:00 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> > As a general comment, if you are going to split up your remarks into 
> > many tiny messages it would be very helpful if you would use 
> > descriptive subjects.  Also, FYI you seem to have an off-by-one error 
> > in your reading of the page numbers.
> >
> Then I would need to place each item in a separate message, as you saw
> I grouped them as 5 issues per message. Per request from the ADS.
> The subjects they cover could vary thus making the description not bound to
> one thing. Sorry.
> 
> I used the page number printed on the page not the word processor generated
> one. If I missed it, sorry.
>  
> > This message aggregates my replies to all your messages with the 
> > subject "Review of draft-ietf-idr-bgp4-17.txt".
> > 
> > At 10:35 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > >4. In many places in the document the term Transport 
> > Connection is used, and
> > >in the FSM area the term TCP Connection is used. One generic 
> > term should be
> > >used   throughout the document in case a different transport 
> > (like SCTP) is
> > >used to service the BGP sessions.
> > 
> > As Yakov mentioned earlier, BGP is not actually 
> > transport-independent.  This might equally well argue in favor of 
> > dropping the "transport connection" pretense and just saying "TCP" 
> > throughout (applies to the FSM too, BTW).
> > 
> In the FSM draft, there is an effort to abstract things to only mention
> "transport connection" not "TCP", in this spec its the other way around. We
> clearly need a common way of describing the transport layer in all
> BGP protocol related specs.

Please ask the author(s) of the FSM draft to use TCP.
  
> > A future protocol based on BGP 4 might be transport independent 
> > and/or run over SCTP, but I think that is far beyond our current 
> > scope.
>  
> Agreed, but IMHO, the BGP spec should describe the protocol independent
> of its use of the TCP layer and its details. But I think,
> its so dependent on it now, that you almost have to redo the BGP protocol
> description to use a different transport layer (SCTP).  

With this in mind can we keep the comments focuses on reality, and not 
on what one would wish for.
  
[clipped...]

> > At 10:45 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > >This complexity could have been avoided if withdrawn routes and NRLI
> > >prefixes with their attributes were mutually exclusive of 
> > each other and
> > >appeared in different update messages. If that was the case, 
> > the priority of
> > >which field to process first would have been as simple as 
> > using "first come,
> > >first served" message processing approach.
> > 
> > If wishes were horses, beggars would ride.  There are plenty of ugly 
> > bits of the protocol which I'd change if we had a clean slate.  But 
> > surely something this fundamental to the operation of the 
> > protocol-as-deployed is not open for revision right now?
>  
> I threw this one out, just to see if anything can be done. Knowing full 
> well you guys will do nothing. But we can wish can't we?

One can certainly wish, but this is outside the scope of the current
discussion. So, while commenting on the base spec please avoid
including wishes in your comments.
  
[clipped...]

> > At 10:52 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> > >4. P. 31, section 6.8, Please rewrite this sentence from:
> > >    "Comparing BGP Identifiers is done by treating them as 
> > >     (4-octet long) unsigned integers."
> > >  To This:
> > >    "Comparing BGP Identifiers is done by treating them as 
> > >     large numbers based
> > >     on their IP Address type (e.g. IPv4, IPv6, etc.)."
> > 
> > The BGP identifier is a 4-byte quantity, not a variable quantity.  I 
> > think the sentence is fine as written.
> >
> I was thinking of IPv6 in which case a message format change would be
> required. My thinking is based on using full IPv6 routable addresses 
> for the BGP Identifier. 

Since it requires message format change, it is outside the scope
of the current discussion. 

> BTW I do not agree with the IPv6 Router-ID draft proposed by someone.

What that has to do with the comments on the base BGP spec ?

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 OAA20348 for <[e-mail]>; Wed, 11 Sep 2002 14:04:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C257691396; Wed, 11 Sep 2002 14:01:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 092599139A; Wed, 11 Sep 2002 14:01:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9836691396 for <[e-mail]>; Wed, 11 Sep 2002 14:00:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 66CD15DEDD; Wed, 11 Sep 2002 14:00:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id DAA665DE3A for <[e-mail]>; Wed, 11 Sep 2002 14:00:51 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA22165; Wed, 11 Sep 2002 14:00:49 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA07642; Wed, 11 Sep 2002 14:00:51 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DRPSH>; Wed, 11 Sep 2002 14:00:50 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 14:00:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Natale:

> 
> (your page nums are wrong)
> 
> 1. agree, but cap. Is not a msg type
 
This is taken from draft-ietf-idr-dynamic-cap-02.txt:

"5. Capability Message

   The CAPABILITY Message is a new BGP message type with type code 6.
   In addition to the fixed-size BGP header [BGP-4], the CAPABILITY
   message contains one or more of the following tuples:"

> 2. agree
> 3. disagree, but maybe:
> IGP = network was explicitly introduced into bgp (network cmd)
> INCOMPLETE = network was implicitly introduced into bgp (redistribute)
> EGP = other
> Also, maybe a discussion/reference on how this is used in 
> decision process.
> (I have seen folks infer that EGP == EBGP, so this has been a 
> source of
> confusion.  May add a note that this is historic???  What do 
> operators use
> Origin = EGP for??? (comments?))

To make a long story short, there is no other EGP in use other BGP
so why bother mentioning it. I dont hear anyone calling for another
EGP protocol as a standard Inter-AS protocol.

As far as I know the original EGP protocol was flawed and BGP corrected
a number of problems. So why bother with it?

> 4. disagree (covered elsewhere)
>
How can you disagree with this? This is what MED is. All other attributes
have the type described in the same place where I want MED to do.

Ben  
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Wednesday, September 11, 2002 10:59 AM
> To: '[e-mail]'
> Subject: Review of draft-ietf-idr-bgp4-17.txt
> 
> Part I:
> 
> Editorial Comments:
> ===================
> 1. P. 7 Type: Need to add the new message types such as, Capability
> Negotiations (RFC2842), Route Refresh, etc.
> 
> 2. P. 9, right after "This document defines the following optional
> parameters:"
> Need to mention possible options, such as: Capabilitites (RFC2842),
> Multiprotocol extensions (RFC2858), Route Refresh (RFC2918).
> 
> 3. P. 13, EGP, are there other EGP protocols other than BGP 
> that are in use?
> If not, change EGP to BGP.
> 
> 4. P.23, change the following: 
> 
> "The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
>  links to discriminate among multiple exit or entry points to the same
>  neighboring AS ..."
> 
>  To the following:
> 
> "The MULTI_EXIT_DISC is an optional non-transitive attribute 
> which may be
> used on external (inter-AS) links to discriminate among 
> multiple exit or
> entry points to the same neighboring AS ..."
> 
> 5. In section 8, there are a number of Timers, Counters, etc. 
> that need to
> be explicitly defined before they are used by the FSM. Perhaps these
> definitions should go in the Glossary section.
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA19824 for <[e-mail]>; Wed, 11 Sep 2002 13:49:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8B32591310; Wed, 11 Sep 2002 13:48:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3195991391; Wed, 11 Sep 2002 13:48:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E95C59138D for <[e-mail]>; Wed, 11 Sep 2002 13:47:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C59315DE3A; Wed, 11 Sep 2002 13:47:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 510DA5DDEE for <[e-mail]>; Wed, 11 Sep 2002 13:47:43 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21337; Wed, 11 Sep 2002 13:47:40 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA05569; Wed, 11 Sep 2002 13:47:36 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DRPAW>; Wed, 11 Sep 2002 13:47:34 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: your mail
Date: Wed, 11 Sep 2002 13:47:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Thats fine, if all agree.

Remember, we are just trying to clear up vague language.

Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 1:45 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: your mail
> 
> 
> On Wed, Sep 11, 2002 at 01:43:18PM -0400, Abarbanel, Benjamin wrote:
> > My point is that no one "reads from a peer", that is 
> physically impossible.
> > If there are many other ways to skin the cat, then mention 
> like this,
> > "reads from a peer socket/stream/session/etc." just to be 
> technically
> > correct.
> reads data from the transport connection with the peer.
> 
> > Ben
> 
> -- 
> 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 NAA19814 for <[e-mail]>; Wed, 11 Sep 2002 13:49:01 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5F7C59130E; Wed, 11 Sep 2002 13:47:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2692A91310; Wed, 11 Sep 2002 13:47:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 68B409130E for <[e-mail]>; Wed, 11 Sep 2002 13:46:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5574D5DE3A; Wed, 11 Sep 2002 13:46:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 0C6125DDEE for <[e-mail]>; Wed, 11 Sep 2002 13:46:59 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CJLL>; Wed, 11 Sep 2002 13:46:55 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 13:46:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

(your page nums are wrong)

1. agree, but cap. Is not a msg type
2. agree
3. disagree, but maybe:
IGP = network was explicitly introduced into bgp (network cmd)
INCOMPLETE = network was implicitly introduced into bgp (redistribute)
EGP = other
Also, maybe a discussion/reference on how this is used in decision process.
(I have seen folks infer that EGP == EBGP, so this has been a source of
confusion.  May add a note that this is historic???  What do operators use
Origin = EGP for??? (comments?))
4. disagree (covered elsewhere)

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Wednesday, September 11, 2002 10:59 AM
To: '[e-mail]'
Subject: Review of draft-ietf-idr-bgp4-17.txt

Part I:

Editorial Comments:
===================
1. P. 7 Type: Need to add the new message types such as, Capability
Negotiations (RFC2842), Route Refresh, etc.

2. P. 9, right after "This document defines the following optional
parameters:"
Need to mention possible options, such as: Capabilitites (RFC2842),
Multiprotocol extensions (RFC2858), Route Refresh (RFC2918).

3. P. 13, EGP, are there other EGP protocols other than BGP that are in use?
If not, change EGP to BGP.

4. P.23, change the following: 

"The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
 links to discriminate among multiple exit or entry points to the same
 neighboring AS ..."

 To the following:

"The MULTI_EXIT_DISC is an optional non-transitive attribute which may be
used on external (inter-AS) links to discriminate among multiple exit or
entry points to the same neighboring AS ..."

5. In section 8, there are a number of Timers, Counters, etc. that need to
be explicitly defined before they are used by the FSM. Perhaps these
definitions should go in the Glossary section.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA19736 for <[e-mail]>; Wed, 11 Sep 2002 13:46:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 47F0D91387; Wed, 11 Sep 2002 13:45:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C415A9138D; Wed, 11 Sep 2002 13:45:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED1A491387 for <[e-mail]>; Wed, 11 Sep 2002 13:45:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 876F35DE5A; Wed, 11 Sep 2002 13:45:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 6B3DC5DDEE for <[e-mail]>; Wed, 11 Sep 2002 13:45:06 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8BHj4r61845; Wed, 11 Sep 2002 13:45:04 -0400 (EDT) (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 g8BHj1G61838; Wed, 11 Sep 2002 13:45:01 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8BHj1K02054; Wed, 11 Sep 2002 13:45:01 -0400 (EDT)
Date: Wed, 11 Sep 2002 13:45:01 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: your mail
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 Wed, Sep 11, 2002 at 01:43:18PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 11, 2002 at 01:43:18PM -0400, Abarbanel, Benjamin wrote:
> My point is that no one "reads from a peer", that is physically impossible.
> If there are many other ways to skin the cat, then mention like this,
> "reads from a peer socket/stream/session/etc." just to be technically
> correct.

reads data from the transport connection with the peer.

> Ben

-- 
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 NAA19686 for <[e-mail]>; Wed, 11 Sep 2002 13:44:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5E2AD913A1; Wed, 11 Sep 2002 13:43:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 313D4913A0; Wed, 11 Sep 2002 13:43:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E4B0391396 for <[e-mail]>; Wed, 11 Sep 2002 13:43:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D26D25DE59; Wed, 11 Sep 2002 13:43:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 5EE535DDEE for <[e-mail]>; Wed, 11 Sep 2002 13:43:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21027; Wed, 11 Sep 2002 13:43:20 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04687; Wed, 11 Sep 2002 13:43:21 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DR3Y5>; Wed, 11 Sep 2002 13:43:20 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: your mail
Date: Wed, 11 Sep 2002 13:43:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

My point is that no one "reads from a peer", that is physically impossible.
If there are many other ways to skin the cat, then mention like this,
"reads from a peer socket/stream/session/etc." just to be technically
correct.

Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 1:40 PM
> To: Abarbanel, Benjamin
> Cc: '[e-mail]'
> Subject: Re: your mail
> 
> 
> If I read this correctly to being a diff on just "socket", I'd
> recommend against the change.
> 
> Could be streams.
> Could be foo.
> 
> The fact that we mention blocking transport stream connections at
> all seems a bit silly - its an implementation detail.  But
> at least that section makes a pretense at "these are things that
> we've learned..."
> 
> On Wed, Sep 11, 2002 at 12:09:22PM -0400, Abarbanel, Benjamin wrote:
> > On p. 61, section 6.2
> > I will like to rephrase for clarity this:
> > 
> > "An implementation that would "hang" the routing 
> information process while
> > trying to read from a peer could set up a message buffer 
> (4096 bytes) per
> > peer and fill it with data as available until a complete 
> message has been
> > received. "
> > 
> > To This:
> > 
> > "An implementation that would "hang" the routing 
> information process while
> > trying to read from a peer socket could set up a message 
> buffer (4096 bytes)
> > per peer and fill it with data as available until a 
> complete message has
> > been
> > received. "
> > 
> > Thanks,
> > Ben
> > 
> 
> -- 
> Jeff Haas 
> NextHop Technologies
> 


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 NAA19670 for <[e-mail]>; Wed, 11 Sep 2002 13:44:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1BC2A9138C; Wed, 11 Sep 2002 13:41:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 531DF9138E; Wed, 11 Sep 2002 13:41:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F08949138C for <[e-mail]>; Wed, 11 Sep 2002 13:40:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9497D5DEC7; Wed, 11 Sep 2002 13:40:55 -0400 (EDT)
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 49B205DE5A for <[e-mail]>; Wed, 11 Sep 2002 13:40:55 -0400 (EDT)
Received: from tom3 (userbm12.uk.uudial.com [62.188.144.218]) by colossus.systems.pipex.net (Postfix) with SMTP id 7463616000650; Wed, 11 Sep 2002 18:40:53 +0100 (BST)
Message-ID: <013801c259b9$f84839e0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>, "Susan Hares" <[e-mail]>
Cc: "yakov Rekhter" <[e-mail]>, <[e-mail]>, <[e-mail]>, "randy Bush" <[e-mail]>
Subject: FSM words - state changes
Date: Wed, 11 Sep 2002 18:36:42 +0100
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

In most places, the actions taken on the receipt of an event include
what the new state will be or that it remains unchanged.  But there
are a signficant number of places where this is not done (eg Connect
state events 14, 15, 16).  I would like to see consistency, always
specify the new/unchanged state.  Else I may be misreading it.

I can give you a list if you want or else you put in all you can find
and I will feedback any apparent omissions.

Tom Petch
[e-mail]








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 NAA19648 for <[e-mail]>; Wed, 11 Sep 2002 13:44:16 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5E5789138A; Wed, 11 Sep 2002 13:41:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA93B9130E; Wed, 11 Sep 2002 13:41:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA4249138A for <[e-mail]>; Wed, 11 Sep 2002 13:40:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C83745DE54; Wed, 11 Sep 2002 13:40:53 -0400 (EDT)
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 95E9E5DDEE for <[e-mail]>; Wed, 11 Sep 2002 13:40:53 -0400 (EDT)
Received: from tom3 (userbm12.uk.uudial.com [62.188.144.218]) by colossus.systems.pipex.net (Postfix) with SMTP id 40A6016000587; Wed, 11 Sep 2002 18:40:51 +0100 (BST)
Message-ID: <013701c259b9$f764dec0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>, "Susan Hares" <[e-mail]>
Cc: "yakov Rekhter" <[e-mail]>, <[e-mail]>, <[e-mail]>, "randy Bush" <[e-mail]>
Subject: FSM ConnectRetryCnt
Date: Wed, 11 Sep 2002 18:30:18 +0100
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

This seems to have lost its purpose (which it had in BGP-17).  It gets
cleared on manual stop, incremented by one when something goes wrong
but so what?  An explanation would help.

And I think it should be a Session Attribute required for each
connection, along with
OpenDelayTimer
DelayOpenFlag

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 NAA19617 for <[e-mail]>; Wed, 11 Sep 2002 13:43:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7B1569138F; Wed, 11 Sep 2002 13:41:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4EB439138E; Wed, 11 Sep 2002 13:41:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2BCB19130E for <[e-mail]>; Wed, 11 Sep 2002 13:40:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0A28E5DE54; Wed, 11 Sep 2002 13:40:52 -0400 (EDT)
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 C87305DDEE for <[e-mail]>; Wed, 11 Sep 2002 13:40:51 -0400 (EDT)
Received: from tom3 (userbm12.uk.uudial.com [62.188.144.218]) by colossus.systems.pipex.net (Postfix) with SMTP id 0CC9A160006A4; Wed, 11 Sep 2002 18:40:48 +0100 (BST)
Message-ID: <013601c259b9$f5fcc340$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "idr" <[e-mail]>, "Susan Hares" <[e-mail]>
Cc: "yakov Rekhter" <[e-mail]>, <[e-mail]>, <[e-mail]>, "randy Bush" <[e-mail]>
Subject: FSM more words
Date: Wed, 11 Sep 2002 18:29:45 +0100
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

In the 26Aug text, I find the timer terminology still confusing.
Timers can, I find, 
stop
start
restart
clear
set
reset
expire

Rich the English language is but I see this as overuse.
For me, timers
start, stop, expire
The only further refinement is that they may start with an initial
value or with the value they had when they were stopped (eg NFL game
clocks); I do not believe, but cannot be sure, that the last is ever
used in the FSM.  Which means all we need is
start with initial value (spell it out just to be sure)
stop
expire
and anything else just confuses - me and I suspect others.

Tom Petch
[e-mail]






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 NAA19548 for <[e-mail]>; Wed, 11 Sep 2002 13:41:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1012791311; Wed, 11 Sep 2002 13:40:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD0EB91387; Wed, 11 Sep 2002 13:40:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B94B91311 for <[e-mail]>; Wed, 11 Sep 2002 13:40:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4ECFA5DE54; Wed, 11 Sep 2002 13:40:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id E52CD5DDEE for <[e-mail]>; Wed, 11 Sep 2002 13:40:06 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8BHe4m61382; Wed, 11 Sep 2002 13:40:04 -0400 (EDT) (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 g8BHe1G61375; Wed, 11 Sep 2002 13:40:01 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8BHe1j01973; Wed, 11 Sep 2002 13:40:01 -0400 (EDT)
Date: Wed, 11 Sep 2002 13:40:01 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: your mail
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 Wed, Sep 11, 2002 at 12:09:22PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

If I read this correctly to being a diff on just "socket", I'd
recommend against the change.

Could be streams.
Could be foo.

The fact that we mention blocking transport stream connections at
all seems a bit silly - its an implementation detail.  But
at least that section makes a pretense at "these are things that
we've learned..."

On Wed, Sep 11, 2002 at 12:09:22PM -0400, Abarbanel, Benjamin wrote:
> On p. 61, section 6.2
> I will like to rephrase for clarity this:
> 
> "An implementation that would "hang" the routing information process while
> trying to read from a peer could set up a message buffer (4096 bytes) per
> peer and fill it with data as available until a complete message has been
> received. "
> 
> To This:
> 
> "An implementation that would "hang" the routing information process while
> trying to read from a peer socket could set up a message buffer (4096 bytes)
> per peer and fill it with data as available until a complete message has
> been
> received. "
> 
> Thanks,
> Ben
> 

-- 
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 NAA19319 for <[e-mail]>; Wed, 11 Sep 2002 13:35:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D4D3291399; Wed, 11 Sep 2002 13:32:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E263791395; Wed, 11 Sep 2002 13:32:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 09BB4913F4 for <[e-mail]>; Wed, 11 Sep 2002 13:30:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F28EB5DE59; Wed, 11 Sep 2002 13:30:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 4A9D15DE4F for <[e-mail]>; Wed, 11 Sep 2002 13:30:19 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA20156; Wed, 11 Sep 2002 13:30:16 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA02397; Wed, 11 Sep 2002 13:30:17 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DR3FC>; Wed, 11 Sep 2002 13:30:16 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Mathew Richardson'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 13:30:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Mathew Richardson [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 1:12 PM
> To: Abarbanel, Benjamin
> Cc: '[e-mail]'
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> > Abarbanel, Benjamin <[e-mail]> [Wed, 
> Sep 11, 2002 at 10:52:33AM -0400]:
> >Part II.
> >
> >Technical Comments:
> >===================
> >
> >1. P.28, 2nd to last paragraph. The line that reads, "To be 
> semantically
> >correct, the IP address in the NEXT_HOP must not be the IP 
> address of the
> >receiving speaker, and the NEXT_HOP IP address must either 
> be the sender's
> >IP address (used to establish the BGP session), or the 
> interface associated
> >with the NEXT_HOP IP address must share a common subnet with 
> the receiving
> >BGP speaker..."
> >
> >This is not always true, what if the current ASBR BGP router 
> is advertising
> >an external AS route (to a IBGP Peer) whose NEXT_HOP IP 
> address is the IP
> >address of the EBGP peer in the other AS?
> 
> See the sentence immediately prior to the one you don't 
> like... it reads:
> 
>    Semantic correctness applies only to the external BGP
>    links, and only when the sender and the receiving speaker 
> are one IP
>    hop away from each other
> 
> <snip>
> 
> >4. P. 31, section 6.8, Please rewrite this sentence from:
> >   "Comparing BGP Identifiers is done by treating them as 
> (4-octet long)
> >    unsigned integers."
> >             
> > To This:
> >   "Comparing BGP Identifiers is done by treating them as 
> large numbers
> >based 
> >    on their IP Address type (e.g. IPv4, IPv6, etc.)."
> 
> The BGP Identifier is 4 octets...
> 
> >5. P.46, last sentence, "However, corresponding unresolvable 
> routes SHOULD
> >be kept in the Adj-RIBs-In."  It would helpful if the author 
> states why
> >unresolvable routes should be kept in Adj-RIBs-In?
> 
> In case they become resolvable...

Then the point that the peer will not refresh the route if we drop 
them (unless we use Route Refresh) because they are unreachable should be
made.

> 
> mrr
> 

All other points have already been answered.

Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA19291 for <[e-mail]>; Wed, 11 Sep 2002 13:34:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 678B2913E6; Wed, 11 Sep 2002 13:28:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2668B91399; Wed, 11 Sep 2002 13:28:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C9C69913E6 for <[e-mail]>; Wed, 11 Sep 2002 13:27:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B4F1E5DE59; Wed, 11 Sep 2002 13:27:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 6AFC75DDEE for <[e-mail]>; Wed, 11 Sep 2002 13:27:50 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA20032; Wed, 11 Sep 2002 13:27:48 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA01966; Wed, 11 Sep 2002 13:27:49 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <SW7DR3BL>; Wed, 11 Sep 2002 13:27:48 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'John G. Scudder'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 13:27:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

John,

 
 
> As a general comment, if you are going to split up your remarks into 
> many tiny messages it would be very helpful if you would use 
> descriptive subjects.  Also, FYI you seem to have an off-by-one error 
> in your reading of the page numbers.
>
Then I would need to place each item in a separate message, as you saw
I grouped them as 5 issues per message. Per request from the ADS.
The subjects they cover could vary thus making the description not bound to
one thing. Sorry.

I used the page number printed on the page not the word processor generated
one. If I missed it, sorry.
 
> This message aggregates my replies to all your messages with the 
> subject "Review of draft-ietf-idr-bgp4-17.txt".
> 
> At 10:35 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >4. In many places in the document the term Transport 
> Connection is used, and
> >in the FSM area the term TCP Connection is used. One generic 
> term should be
> >used   throughout the document in case a different transport 
> (like SCTP) is
> >used to service the BGP sessions.
> 
> As Yakov mentioned earlier, BGP is not actually 
> transport-independent.  This might equally well argue in favor of 
> dropping the "transport connection" pretense and just saying "TCP" 
> throughout (applies to the FSM too, BTW).
> 
In the FSM draft, there is an effort to abstract things to only mention
"transport connection" not "TCP", in this spec its the other way around. We
clearly need a common way of describing the transport layer in all
BGP protocol related specs.

> A future protocol based on BGP 4 might be transport independent 
> and/or run over SCTP, but I think that is far beyond our current 
> scope.
> 
Agreed, but IMHO, the BGP spec should describe the protocol independent
of its use of the TCP layer and its details. But I think,
its so dependent on it now, that you almost have to redo the BGP protocol
description to use a different transport layer (SCTP).  

> At 10:45 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >1. P.6  section 4. Message Formats, its possible for the 
> source BGP peer IP
> >layer to fragment a message such that the receiving BGP peer 
> socket layer
> >would have to reassemble it. Need to mention this, since BGP 
> implementations
> >are required to do this.
> 
> Seems to me that this is out of the scope of BGP.  It's a transport 
> and network layer thing.
> 
Incorrect if you followed the previous messages here, Look at Appendix 6,
section 6.2.

> At 10:45 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >This complexity could have been avoided if withdrawn routes and NRLI
> >prefixes with their attributes were mutually exclusive of 
> each other and
> >appeared in different update messages. If that was the case, 
> the priority of
> >which field to process first would have been as simple as 
> using "first come,
> >first served" message processing approach.
> 
> If wishes were horses, beggars would ride.  There are plenty of ugly 
> bits of the protocol which I'd change if we had a clean slate.  But 
> surely something this fundamental to the operation of the 
> protocol-as-deployed is not open for revision right now?
> 
I threw this one out, just to see if anything can be done. Knowing full 
well you guys will do nothing. But we can wish can't we?

> At 10:45 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >5. P. 20 Its not stated how we delete or modify Path 
> Attributes associated
> >with NLRI prefixes.
> 
> This is implicit in the definition of "route", which discussion I 
> will not repeat here, plus withdraw/replace behavior.  IMO we don't 
> need to further belabor the point in the spec (which is already wordy 
> enough and then some).
> 
I disagree, there is an assumption how one would delete or replace say
optional attributes, but no direct way of doing it. I think a good 
implementation spec does not require its reader to guess how to do 
something.

> At 10:52 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >1. P.28, 2nd to last paragraph. The line that reads, "To be 
> semantically
> >correct, the IP address in the NEXT_HOP must not be the IP 
> address of the
> >receiving speaker, and the NEXT_HOP IP address must either 
> be the sender's
> >IP address (used to establish the BGP session), or the 
> interface associated
> >with the NEXT_HOP IP address must share a common subnet with 
> the receiving
> >BGP speaker..."
> >
> >This is not always true, what if the current ASBR BGP router 
> is advertising
> >an external AS route (to a IBGP Peer) whose NEXT_HOP IP 
> address is the IP
> >address of the EBGP peer in the other AS?
> 
> Doesn't apply.  Right before the text you quoted is this: "Semantic 
> correctness applies only to the external BGP links, and only when the 
> sender and the receiving speaker are one IP hop away from each other."
> 
OK, I withdraw the issue.

> At 10:52 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >2. P. 29, Section 6.3. Add this rule near the attribute rules.
> >"Multiple prefixes that require the same attribute type with 
> different
> >values must never appear in the same update message".
> 
> This is implicit in the message format and therefore redundant -- you 
> don't have to forbid something which is just plain impossible.  IMO 
> redundancy is to be avoided, eschewed and shunned except where the 
> point being emphasized is subtle and easily missed (which does not 
> apply in this case IMO).
>
This rule just adds another flavor to the use of attributes. I agree it 
would be silly, since you would need duplicate attributes with different
values to coexist in the same message. I'll accept your point. 
 
> At 10:52 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >3. P. 29, Section 6.5, Please rewrite this sentence from:
> >     "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 ..."
> >
> >  To This:
> >     "If a system does not receive successive KEEPALIVE and/or UPDATE
> >      and/or any other BGP message within the period 
> specified in the Hold
> >      Time field of the OPEN message ..."
> 
> I disagree as previously discussed (see archives, I won't 
> repeat myself here).

Again, it opens the door to new features and functionality that the current
door is closed. I agree we can argue on this till the cows come home.
This one is up to the BGP ADS to decide.

> 
> If this change were to be made anyway, it would be important to 
> update the language of 4.4 ("KEEPALIVE Message Format") to make clear 
> that only updates and keepalives can be relied upon to reset the hold 
> time.
> 
> At 10:52 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >4. P. 31, section 6.8, Please rewrite this sentence from:
> >    "Comparing BGP Identifiers is done by treating them as 
> (4-octet long)
> >     unsigned integers."
> >             
> >  To This:
> >    "Comparing BGP Identifiers is done by treating them as 
> large numbers
> >based
> >     on their IP Address type (e.g. IPv4, IPv6, etc.)."
> 
> The BGP identifier is a 4-byte quantity, not a variable quantity.  I 
> think the sentence is fine as written.
>
I was thinking of IPv6 in which case a message format change would be
required. My thinking is based on using full IPv6 routable addresses 
for the BGP Identifier. BTW I do not agree with the IPv6 Router-ID
draft proposed by someone.
 
> At 10:58 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >3. P. 13, EGP, are there other EGP protocols other than BGP 
> that are in use?
> >If not, change EGP to BGP.
> 
> From the references section:
> 
>     [1] Mills, D., "Exterior Gateway Protocol Formal Specification",
>     RFC904, April 1984.
> 
> I suppose it might not hurt to stick a "[1]" in the origin code 
> section to add clarity.  The conflation of EGP-the-protocol and 
> EGP-the-class-of-protocols is unfortunate, but we're stuck with it 
> now.
> 
Yes, but does anyone use this form of EGP?

> At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >4. P. 50,  line, "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 (see 9.2)."
> >
> >Would like to rephrase the sentence for clarity,
> >"If a route in Loc-RIB is excluded from a particular 
> Adj-RIB-Out and was
> >previously advertised via Adj-RIB-Out, it must be withdrawn 
> from service by
> >means of an UPDATE message (see 9.2)."
> 
> If we're going for total claribility here, I would like to ask what 
> other way there is to advertise a route, since the proposed wording 
> implies that there are options other than placing it in Adj-RIB-Out. 
> I'd say either s/via Adj-RIB-Out// or simply keep the original 
> wording.
>
 OK, I withdraw the comment.
 
> At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >5. P. 50, section 9.1.4, The two fragments of this sentence 
> are redundant
> >and don't say anything new or simplify the content. Just 
> keep one fragment.
> >"A route describing a smaller set of destinations (a longer 
> prefix) is said
> >to be more specific than a route describing a larger set of 
> destinations (a
> >shorted prefix); similarly, a route describing a larger set 
> of destinations
> >(a shorter prefix) is said to be less specific than a route 
> describing a
> >smaller set of destinations (a longer prefix)."
> 
> I'm glad we seem to agree about the undesirability of redundancy. 
> However I would say that in this case, while the sentence is 
> uncomfortably wordy every part of it contributes.  The first clause 
> defines "more specific" the second, "less specific".
> 
> I'll grant you that the third and fourth parentheses could be dropped.
> 
Great!

> At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >6. P. 52, section 9.2.1.1 Change this sentence for clarity,
> >    "This rate limiting procedure applies on a per-destination basis,
> >although 
> >     the value of MinRouteAdvertisementInterval is set on a 
> per BGP peer
> >basis."
> >
> >  To This:
> >    "This rate limiting procedure applies on a per-destination basis,
> >although   
> >     the value of MinRouteAdvertisementInterval is set on a 
> BGP router (same
> >     value for all peers) basis."
> 
> I disagree.
why?
> 
> At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
> >8. Since there is going to be an FSM spec, do we need to have FSM
> >    descriptions in this spec. Maybe the FSM section should 
> be delete.
> 
> Yep.
> 
OK.

> 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 NAA18933 for <[e-mail]>; Wed, 11 Sep 2002 13:23:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E399D913AA; Wed, 11 Sep 2002 13:17:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 72D86913A9; Wed, 11 Sep 2002 13:17:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7521891399 for <[e-mail]>; Wed, 11 Sep 2002 13:16:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 666DE5DE43; Wed, 11 Sep 2002 13:16:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id AC5D85DDEE for <[e-mail]>; Wed, 11 Sep 2002 13:16:25 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8BHGKn60020; Wed, 11 Sep 2002 13:16:20 -0400 (EDT) (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 g8BHGHG60012; Wed, 11 Sep 2002 13:16:17 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g8BHGHD27435; Wed, 11 Sep 2002 13:16:17 -0400 (EDT)
Date: Wed, 11 Sep 2002 13:16:17 -0400
From: Mathew Richardson <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
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

> Abarbanel, Benjamin <[e-mail]> [Wed, Sep 11, 2002 at 10:58:34AM -0400]:
>Part I:
>
>Editorial Comments:
>===================
>1. P. 7 Type: Need to add the new message types such as, Capability
>Negotiations (RFC2842), Route Refresh, etc.

These are outside the scope of the base document.

>2. P. 9, right after "This document defines the following optional
>parameters:"
>Need to mention possible options, such as: Capabilitites (RFC2842),
>Multiprotocol extensions (RFC2858), Route Refresh (RFC2918).

There is already an example given, although it certainly wouldn't hurt
to add references.

>3. P. 13, EGP, are there other EGP protocols other than BGP that are in use?
>If not, change EGP to BGP.

This refers to _the_ EGP protocol, not to _an_ EGP protocol.

<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 NAA18670 for <[e-mail]>; Wed, 11 Sep 2002 13:16:15 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1F64F91389; Wed, 11 Sep 2002 13:12:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D433591393; Wed, 11 Sep 2002 13:12:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 20A5091389 for <[e-mail]>; Wed, 11 Sep 2002 13:12:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0CCBE5DE59; Wed, 11 Sep 2002 13:12:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 490725DE43 for <[e-mail]>; Wed, 11 Sep 2002 13:12:30 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8BHCRJ59739; Wed, 11 Sep 2002 13:12:27 -0400 (EDT) (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 g8BHCNG59727; Wed, 11 Sep 2002 13:12:23 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g8BHCNU27275; Wed, 11 Sep 2002 13:12:23 -0400 (EDT)
Date: Wed, 11 Sep 2002 13:12:23 -0400
From: Mathew Richardson <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
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

> Abarbanel, Benjamin <[e-mail]> [Wed, Sep 11, 2002 at 10:52:33AM -0400]:
>Part II.
>
>Technical Comments:
>===================
>
>1. P.28, 2nd to last paragraph. The line that reads, "To be semantically
>correct, the IP address in the NEXT_HOP must not be the IP address of the
>receiving speaker, and the NEXT_HOP IP address must either be the sender's
>IP address (used to establish the BGP session), or the interface associated
>with the NEXT_HOP IP address must share a common subnet with the receiving
>BGP speaker..."
>
>This is not always true, what if the current ASBR BGP router is advertising
>an external AS route (to a IBGP Peer) whose NEXT_HOP IP address is the IP
>address of the EBGP peer in the other AS?

See the sentence immediately prior to the one you don't like... it reads:

   Semantic correctness applies only to the external BGP
   links, and only when the sender and the receiving speaker are one IP
   hop away from each other

<snip>

>4. P. 31, section 6.8, Please rewrite this sentence from:
>   "Comparing BGP Identifiers is done by treating them as (4-octet long)
>    unsigned integers."
>             
> To This:
>   "Comparing BGP Identifiers is done by treating them as large numbers
>based 
>    on their IP Address type (e.g. IPv4, IPv6, etc.)."

The BGP Identifier is 4 octets...

>5. P.46, last sentence, "However, corresponding unresolvable routes SHOULD
>be kept in the Adj-RIBs-In."  It would helpful if the author states why
>unresolvable routes should be kept in Adj-RIBs-In?

In case they become resolvable...

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 MAA18019 for <[e-mail]>; Wed, 11 Sep 2002 12:56:01 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8B7A991309; Wed, 11 Sep 2002 12:55:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5090791382; Wed, 11 Sep 2002 12:55:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F215191309 for <[e-mail]>; Wed, 11 Sep 2002 12:55:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D651A5DE59; Wed, 11 Sep 2002 12:55:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id 518C65DE3A for <[e-mail]>; Wed, 11 Sep 2002 12:55:24 -0400 (EDT)
Received: from [192.168.42.10] (dhcp-171-69-182-131.cisco.com [171.69.182.131]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA13506; Wed, 11 Sep 2002 12:55:21 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a3bb9a523c71adf@[192.168.42.10]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 11 Sep 2002 12:55:16 -0400
To: "Abarbanel, Benjamin" <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
Cc: [e-mail]
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id MAA18019

Ben,

As a general comment, if you are going to split up your remarks into 
many tiny messages it would be very helpful if you would use 
descriptive subjects.  Also, FYI you seem to have an off-by-one error 
in your reading of the page numbers.

This message aggregates my replies to all your messages with the 
subject "Review of draft-ietf-idr-bgp4-17.txt".

At 10:35 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>4. In many places in the document the term Transport Connection is used, and
>in the FSM area the term TCP Connection is used. One generic term should be
>used   throughout the document in case a different transport (like SCTP) is
>used to service the BGP sessions.

As Yakov mentioned earlier, BGP is not actually 
transport-independent.  This might equally well argue in favor of 
dropping the "transport connection" pretense and just saying "TCP" 
throughout (applies to the FSM too, BTW).

A future protocol based on BGP 4 might be transport independent 
and/or run over SCTP, but I think that is far beyond our current 
scope.

At 10:45 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>1. P.6  section 4. Message Formats, its possible for the source BGP peer IP
>layer to fragment a message such that the receiving BGP peer socket layer
>would have to reassemble it. Need to mention this, since BGP implementations
>are required to do this.

Seems to me that this is out of the scope of BGP.  It's a transport 
and network layer thing.

At 10:45 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>This complexity could have been avoided if withdrawn routes and NRLI
>prefixes with their attributes were mutually exclusive of each other and
>appeared in different update messages. If that was the case, the priority of
>which field to process first would have been as simple as using "first come,
>first served" message processing approach.

If wishes were horses, beggars would ride.  There are plenty of ugly 
bits of the protocol which I'd change if we had a clean slate.  But 
surely something this fundamental to the operation of the 
protocol-as-deployed is not open for revision right now?

At 10:45 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>5. P. 20 Its not stated how we delete or modify Path Attributes associated
>with NLRI prefixes.

This is implicit in the definition of "route", which discussion I 
will not repeat here, plus withdraw/replace behavior.  IMO we don't 
need to further belabor the point in the spec (which is already wordy 
enough and then some).

At 10:52 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>1. P.28, 2nd to last paragraph. The line that reads, "To be semantically
>correct, the IP address in the NEXT_HOP must not be the IP address of the
>receiving speaker, and the NEXT_HOP IP address must either be the sender's
>IP address (used to establish the BGP session), or the interface associated
>with the NEXT_HOP IP address must share a common subnet with the receiving
>BGP speaker..."
>
>This is not always true, what if the current ASBR BGP router is advertising
>an external AS route (to a IBGP Peer) whose NEXT_HOP IP address is the IP
>address of the EBGP peer in the other AS?

Doesn't apply.  Right before the text you quoted is this: "Semantic 
correctness applies only to the external BGP links, and only when the 
sender and the receiving speaker are one IP hop away from each other."

At 10:52 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>2. P. 29, Section 6.3. Add this rule near the attribute rules.
>"Multiple prefixes that require the same attribute type with different
>values must never appear in the same update message".

This is implicit in the message format and therefore redundant -- you 
don't have to forbid something which is just plain impossible.  IMO 
redundancy is to be avoided, eschewed and shunned except where the 
point being emphasized is subtle and easily missed (which does not 
apply in this case IMO).

At 10:52 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>3. P. 29, Section 6.5, Please rewrite this sentence from:
>     "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 ..."
>
>  To This:
>     "If a system does not receive successive KEEPALIVE and/or UPDATE
>      and/or any other BGP message within the period specified in the Hold
>      Time field of the OPEN message ..."

I disagree as previously discussed (see archives, I won't repeat myself here).

If this change were to be made anyway, it would be important to 
update the language of 4.4 ("KEEPALIVE Message Format") to make clear 
that only updates and keepalives can be relied upon to reset the hold 
time.

At 10:52 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>4. P. 31, section 6.8, Please rewrite this sentence from:
>    "Comparing BGP Identifiers is done by treating them as (4-octet long)
>     unsigned integers."
>             
>  To This:
>    "Comparing BGP Identifiers is done by treating them as large numbers
>based
>     on their IP Address type (e.g. IPv4, IPv6, etc.)."

The BGP identifier is a 4-byte quantity, not a variable quantity.  I 
think the sentence is fine as written.

At 10:58 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>3. P. 13, EGP, are there other EGP protocols other than BGP that are in use?
>If not, change EGP to BGP.

>From the references section:

    [1] Mills, D., "Exterior Gateway Protocol Formal Specification",
    RFC904, April 1984.

I suppose it might not hurt to stick a "[1]" in the origin code 
section to add clarity.  The conflation of EGP-the-protocol and 
EGP-the-class-of-protocols is unfortunate, but we're stuck with it 
now.

At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>4. P. 50,  line, "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 (see 9.2)."
>
>Would like to rephrase the sentence for clarity,
>"If a route in Loc-RIB is excluded from a particular Adj-RIB-Out and was
>previously advertised via Adj-RIB-Out, it must be withdrawn from service by
>means of an UPDATE message (see 9.2)."

If we're going for total claribility here, I would like to ask what 
other way there is to advertise a route, since the proposed wording 
implies that there are options other than placing it in Adj-RIB-Out. 
I'd say either s/via Adj-RIB-Out// or simply keep the original 
wording.

At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>5. P. 50, section 9.1.4, The two fragments of this sentence are redundant
>and don't say anything new or simplify the content. Just keep one fragment.
>"A route describing a smaller set of destinations (a longer prefix) is said
>to be more specific than a route describing a larger set of destinations (a
>shorted prefix); similarly, a route describing a larger set of destinations
>(a shorter prefix) is said to be less specific than a route describing a
>smaller set of destinations (a longer prefix)."

I'm glad we seem to agree about the undesirability of redundancy. 
However I would say that in this case, while the sentence is 
uncomfortably wordy every part of it contributes.  The first clause 
defines "more specific" the second, "less specific".

I'll grant you that the third and fourth parentheses could be dropped.

At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>6. P. 52, section 9.2.1.1 Change this sentence for clarity,
>    "This rate limiting procedure applies on a per-destination basis,
>although 
>     the value of MinRouteAdvertisementInterval is set on a per BGP peer
>basis."
>
>  To This:
>    "This rate limiting procedure applies on a per-destination basis,
>although   
>     the value of MinRouteAdvertisementInterval is set on a BGP router (same
>     value for all peers) basis."

I disagree.

At 11:05 AM -0400 9/11/02, Abarbanel, Benjamin wrote:
>8. Since there is going to be an FSM spec, do we need to have FSM
>    descriptions in this spec. Maybe the FSM section should be delete.

Yep.

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 MAA17237 for <[e-mail]>; Wed, 11 Sep 2002 12:32:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0E38C91304; Wed, 11 Sep 2002 12:31:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B934A91383; Wed, 11 Sep 2002 12:31:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5880691304 for <[e-mail]>; Wed, 11 Sep 2002 12:31:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 360475DE43; Wed, 11 Sep 2002 12:31:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 9FBD55DDEE for <[e-mail]>; Wed, 11 Sep 2002 12:31:02 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BGV1m60496; Wed, 11 Sep 2002 09:31:01 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: [e-mail]
Subject: Re: Tracking the discussion on the spec 
In-Reply-To: Your message of "Tue, 10 Sep 2002 19:00:19 +0200." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 09:31:01 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Alex,

> Folks-
> 
>  Regarding how the discussion on the list regarding the spec is
>  organized, I'd like to suggest that a list of issues is maintained
>  and periodically posted to the WG (with the latest ver potentially
>  published on the web somewhere). Each issue brought up in the WG
>  should be put on this list. Information regarding each item on the
>  list should be sufficient to understand its nature, what was the WG
>  consensus regarding it with required pointers to messages, quotes,
>  or new text.
> 
>  Periodic posting to the WG mailing list should ensure that there are
>  no dropped packets (we're all human) and that the WG consensus is
>  properly reflected and documented.
> 
>  The list may be maintained either by the WG chairs or by a volunteer
>  who works closely with them.
> 
>  Another suggestion would be to explicitly verify consensus in the
>  cases where the discussion stalls and the agreement is not clear.
>  Again periodic posting of the issue list should help ensure that
>  we don't drop things here.

This is an excellent suggestion. All we need is a volunteer to do
this. With this in mind Sue and myself asking folks who would be
willing to do this to respond to myself and 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 MAA17125 for <[e-mail]>; Wed, 11 Sep 2002 12:28:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5135A91303; Wed, 11 Sep 2002 12:27:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A53591304; Wed, 11 Sep 2002 12:27:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E066791303 for <[e-mail]>; Wed, 11 Sep 2002 12:27:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CB0FB5DE3D; Wed, 11 Sep 2002 12:27:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 3F7455DDEE for <[e-mail]>; Wed, 11 Sep 2002 12:27:46 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BGRjm60189; Wed, 11 Sep 2002 09:27:45 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Working Group last call 
In-Reply-To: Your message of "Tue, 10 Sep 2002 18:23:42 +0200." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 09:27:45 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Alex,

> Yakov,
> 
>   I'd like to ask the WG chairs to extend the comment period
>   for at least another two weeks--as I indicated in one of my
>   messages earlier, I'm hearing that people are in deadlines
>   and ask for more time to review.

The WG chairs are pleased to grant the two weeks extension (from 9/9 
to 9/23).

Please track down those people who indicated that two weeks would
not be enough. We are counting on you to get the comments from these 
people in as early as possible.

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 MAA16469 for <[e-mail]>; Wed, 11 Sep 2002 12:10:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6701C912FF; Wed, 11 Sep 2002 12:09:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3422D91303; Wed, 11 Sep 2002 12:09:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 52FF4912FF for <[e-mail]>; Wed, 11 Sep 2002 12:09:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3E22A5DE36; Wed, 11 Sep 2002 12:09:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id B51A85DE30 for <[e-mail]>; Wed, 11 Sep 2002 12:09:24 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA16048 for <[e-mail]>; Wed, 11 Sep 2002 12:09:22 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA19561 for <[e-mail]>; Wed, 11 Sep 2002 12:09:24 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QSPL9>; Wed, 11 Sep 2002 12:09:23 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: 
Date: Wed, 11 Sep 2002 12:09:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

On p. 61, section 6.2
I will like to rephrase for clarity this:

"An implementation that would "hang" the routing information process while
trying to read from a peer could set up a message buffer (4096 bytes) per
peer and fill it with data as available until a complete message has been
received. "

To This:

"An implementation that would "hang" the routing information process while
trying to read from a peer socket could set up a message buffer (4096 bytes)
per peer and fill it with data as available until a complete message has
been
received. "

Thanks,
Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA16206 for <[e-mail]>; Wed, 11 Sep 2002 12:02:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7E3579139D; Wed, 11 Sep 2002 12:00:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1FD6913A0; Wed, 11 Sep 2002 12:00:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2BAE99139D for <[e-mail]>; Wed, 11 Sep 2002 12:00:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 132785DE3D; Wed, 11 Sep 2002 12:00:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 8E80F5DE36 for <[e-mail]>; Wed, 11 Sep 2002 12:00:48 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA15585; Wed, 11 Sep 2002 12:00:46 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA18273; Wed, 11 Sep 2002 12:00:48 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QSPBS>; Wed, 11 Sep 2002 12:00:47 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>, "'Alex Zinin'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 12:00:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

NO its Appendix 6, LOL......Sheesh.

> -----Original Message-----
> From: Abarbanel, Benjamin 
> Sent: Wednesday, September 11, 2002 11:59 AM
> To: Abarbanel, Benjamin; 'Alex Zinin'; 'Yakov Rekhter'
> Cc: '[e-mail]'
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> Actually that was Appendix 4 not 1, I think a TOC will bring out these
> numbering problems right away.
> 
> Ben
> 
> > -----Original Message-----
> > From: Abarbanel, Benjamin 
> > Sent: Wednesday, September 11, 2002 11:50 AM
> > To: 'Alex Zinin'; Yakov Rekhter
> > Cc: Abarbanel, Benjamin; '[e-mail]'
> > Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
> > 
> > 
> > Alex:
> >   YOu are correct, I must have missed the appendix when I 
> > read the core
> > sections. Perhaps a pointer to the appendix that talks 
> about this will
> > be helpfull.
> > 
> > BTW there are two section 6.2 in the spec, one called 
> > "6.2 OPEN message error handling", and the other called
> > "6.2 Processing Messages on a Stream Protocol".
> > 
> > Using same type of sections number in Appendix A is not 
> > good. Especially if you search for strings.
> > 
> > I will renumber the Appendix 1 and use letters like
> > Appendix A, sections to A1, A6.2, etc.
> > 
> > Ben
> > 
> > > -----Original Message-----
> > > From: Alex Zinin [mailto:[e-mail]]
> > > Sent: Wednesday, September 11, 2002 11:40 AM
> > > To: Yakov Rekhter
> > > Cc: Abarbanel, Benjamin; '[e-mail]'
> > > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> > > 
> > > 
> > > Yakov, Ben-
> > > 
> > >  I thought section 6.2 "Processing Messages on a Stream Protocol"
> > >  actually talked about these things...
> > > 
> > > -- 
> > > Alex
> > > 
> > > Wednesday, September 11, 2002, 5:36:47 PM, Yakov Rekhter wrote:
> > > > Ben,
> > > 
> > > >> Yakov:
> > > >>   That may be true, but I have seen in a couple of BGP 
> > > implementations
> > > >> handling the socket level that the BGP code had to 
> > > reassemble the logical
> > > >> packet. TCP did not do it. 
> > > >> 
> > > >> What I mean the application code had to read from the 
> > > socket several times
> > > >> to get the entire packet and reassemble it, before passing 
> > > it to the BGP
> > > >> state machine.
> > > 
> > > > This is purely an *implementation* issue, and as such is not
> > > > subject to standardization.
> > > 
> > > > Yakov.
> > > 
> > > >> 
> > > >> Ben
> > > >> 
> > > >> > -----Original Message-----
> > > >> > From: Yakov Rekhter [mailto:[e-mail]]
> > > >> > Sent: Wednesday, September 11, 2002 11:26 AM
> > > >> > To: Abarbanel, Benjamin
> > > >> > Cc: '[e-mail]'
> > > >> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> > > >> > 
> > > >> > 
> > > >> > Ben,
> > > >> > 
> > > >> > > Part I.
> > > >> > > 
> > > >> > > Technical Comments:
> > > >> > > ===================
> > > >> > > 1. P.6  section 4. Message Formats, its possible for the 
> > > >> > source BGP peer IP
> > > >> > > layer to fragment a message such that the receiving BGP 
> > > >> > peer socket layer
> > > >> > > would have to reassemble it. Need to mention this, since 
> > > >> > BGP implementations
> > > >> > > are required to do this.  
> > > >> > 
> > > >> > *BGP* implementations are *not* required to perform any 
> > > >> > message reassembly.
> > > >> > (remember this is BGP spec, not TCP and/or IP spec).
> > > >> > 
> > > >> > 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 MAA16193 for <[e-mail]>; Wed, 11 Sep 2002 12:02:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3D63E91392; Wed, 11 Sep 2002 11:59:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F29A291394; Wed, 11 Sep 2002 11:59:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1F18A91392 for <[e-mail]>; Wed, 11 Sep 2002 11:59:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DF6E45DE4D; Wed, 11 Sep 2002 11:59:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 5D72E5DE43 for <[e-mail]>; Wed, 11 Sep 2002 11:59:27 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA15501; Wed, 11 Sep 2002 11:59:25 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18047; Wed, 11 Sep 2002 11:59:26 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QS30W>; Wed, 11 Sep 2002 11:59:26 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>, "'Alex Zinin'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 11:59:24 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Actually that was Appendix 4 not 1, I think a TOC will bring out these
numbering problems right away.

Ben

> -----Original Message-----
> From: Abarbanel, Benjamin 
> Sent: Wednesday, September 11, 2002 11:50 AM
> To: 'Alex Zinin'; Yakov Rekhter
> Cc: Abarbanel, Benjamin; '[e-mail]'
> Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> Alex:
>   YOu are correct, I must have missed the appendix when I 
> read the core
> sections. Perhaps a pointer to the appendix that talks about this will
> be helpfull.
> 
> BTW there are two section 6.2 in the spec, one called 
> "6.2 OPEN message error handling", and the other called
> "6.2 Processing Messages on a Stream Protocol".
> 
> Using same type of sections number in Appendix A is not 
> good. Especially if you search for strings.
> 
> I will renumber the Appendix 1 and use letters like
> Appendix A, sections to A1, A6.2, etc.
> 
> Ben
> 
> > -----Original Message-----
> > From: Alex Zinin [mailto:[e-mail]]
> > Sent: Wednesday, September 11, 2002 11:40 AM
> > To: Yakov Rekhter
> > Cc: Abarbanel, Benjamin; '[e-mail]'
> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> > 
> > 
> > Yakov, Ben-
> > 
> >  I thought section 6.2 "Processing Messages on a Stream Protocol"
> >  actually talked about these things...
> > 
> > -- 
> > Alex
> > 
> > Wednesday, September 11, 2002, 5:36:47 PM, Yakov Rekhter wrote:
> > > Ben,
> > 
> > >> Yakov:
> > >>   That may be true, but I have seen in a couple of BGP 
> > implementations
> > >> handling the socket level that the BGP code had to 
> > reassemble the logical
> > >> packet. TCP did not do it. 
> > >> 
> > >> What I mean the application code had to read from the 
> > socket several times
> > >> to get the entire packet and reassemble it, before passing 
> > it to the BGP
> > >> state machine.
> > 
> > > This is purely an *implementation* issue, and as such is not
> > > subject to standardization.
> > 
> > > Yakov.
> > 
> > >> 
> > >> Ben
> > >> 
> > >> > -----Original Message-----
> > >> > From: Yakov Rekhter [mailto:[e-mail]]
> > >> > Sent: Wednesday, September 11, 2002 11:26 AM
> > >> > To: Abarbanel, Benjamin
> > >> > Cc: '[e-mail]'
> > >> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> > >> > 
> > >> > 
> > >> > Ben,
> > >> > 
> > >> > > Part I.
> > >> > > 
> > >> > > Technical Comments:
> > >> > > ===================
> > >> > > 1. P.6  section 4. Message Formats, its possible for the 
> > >> > source BGP peer IP
> > >> > > layer to fragment a message such that the receiving BGP 
> > >> > peer socket layer
> > >> > > would have to reassemble it. Need to mention this, since 
> > >> > BGP implementations
> > >> > > are required to do this.  
> > >> > 
> > >> > *BGP* implementations are *not* required to perform any 
> > >> > message reassembly.
> > >> > (remember this is BGP spec, not TCP and/or IP spec).
> > >> > 
> > >> > 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 LAA15858 for <[e-mail]>; Wed, 11 Sep 2002 11:52:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B18D99137F; Wed, 11 Sep 2002 11:51:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84CA491380; Wed, 11 Sep 2002 11:51:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7094B9137F for <[e-mail]>; Wed, 11 Sep 2002 11:51:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 638D05DE49; Wed, 11 Sep 2002 11:51:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id E4B2F5DE43 for <[e-mail]>; Wed, 11 Sep 2002 11:51:46 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14975; Wed, 11 Sep 2002 11:51:44 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA16555; Wed, 11 Sep 2002 11:51:46 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QS3TB>; Wed, 11 Sep 2002 11:51:45 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
Date: Wed, 11 Sep 2002 11:51:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Just wanted to say what would improve it. I realize its difficult 
to change very basic and implemented features.

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 11:48 AM
> To: Abarbanel, Benjamin
> Cc: '[e-mail]'
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> 
> 
> Ben,
> 
> > I realize if we do what I suggest, there will have to be a 
> transition
> > period where the two types are in the same message as well 
> as separate
> > messages. If they are in the same message, we need to keep 
> the existing
> > rules, until everyone (?) upgrades, then we can obsolete 
> these rules.
> 
> Please bear in mind that the spec is about what is 
> *currently* deployed.
> As such any change to the base spec that required upgrades/transition
> is outside the scope of the current discussion.
> 
> Yakov.
> 
> > 
> > Ben
> > 
> > > -----Original Message-----
> > > From: Yakov Rekhter [mailto:[e-mail]]
> > > Sent: Wednesday, September 11, 2002 11:34 AM
> > > To: Abarbanel, Benjamin
> > > Cc: 'Kaarthik Sivakumar'; '[e-mail]'
> > > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> > > 
> > > 
> > > Ben,
> > > 
> > > > No it means if they are placed in different messages and 
> > > sent in the order 
> > > > that the source router wants the destination router to 
> > > execute them. 
> > > > 
> > > > It just makes the messages simpler, requiring less rules of 
> > > processing.
> > > 
> > > it also makes the case where they are in the same message 
> unspecified.
> > >   
> > > > Ben
> > > > 
> > > > > -----Original Message-----
> > > > > From: Kaarthik Sivakumar [mailto:[e-mail]]
> > > > > Sent: Wednesday, September 11, 2002 11:12 AM
> > > > > To: Abarbanel, Benjamin
> > > > > Cc: '[e-mail]'
> > > > > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> > > > > 
> > > > > 
> > > > > >>> "BA" == Benjamin Abarbanel <Abarbanel> writes:
> > > > > 
> > > > > [...]
> > > > > 
> > > > > BA> 4. P.16, last paragraph in section 4.3 as stated,
> > > > > BA>  "An UPDATE message should not include the same address 
> > > > > prefix in the
> > > > > BA>   WITHDRAWN ROUTES and Network Layer Reachability 
> > > > > Information fields,
> > > > > BA>   however a BGP speaker MUST be able to process UPDATE 
> > > > messages in this
> > > > > BA>   form. A BGP speaker should treat an UPDATE message of 
> > > > > this form as if
> > > > > BA>   the WITHDRAWN ROUTES doesn't contain the 
> address prefix."
> > > > >               
> > > > > BA> This complexity could have been avoided if withdrawn 
> > > > > routes and NRLI
> > > > > BA> prefixes with their attributes were mutually exclusive of 
> > > > > each other and
> > > > > BA> appeared in different update messages. If that was the 
> > > > > case, the priority of
> > > > > BA> which field to process first would have been as simple as 
> > > > > using "first come,
> > > > > BA> first served" message processing approach.
> > > > > 
> > > > > What you suggest isnt the same as what is there now. The 
> > > draft says
> > > > > that NLRI has higher preference to a WITHDRAWN prefix and 
> > > this makes
> > > > > the behavior predictable. In what you suggest the 
> behavior isnt
> > > > > predictable. Or is it? Hmm .. Maybe I am mistaken here, 
> > > but it doesnt
> > > > > seem like the same thing.
> > > > > 
> > > > > Kaarthik
> > > > > 
> > > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA15796 for <[e-mail]>; Wed, 11 Sep 2002 11:50:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EBA339137E; Wed, 11 Sep 2002 11:50:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BCD3C9137F; Wed, 11 Sep 2002 11:50:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5A06B9137E for <[e-mail]>; Wed, 11 Sep 2002 11:50:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 48BB25DE49; Wed, 11 Sep 2002 11:50:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id C67315DE43 for <[e-mail]>; Wed, 11 Sep 2002 11:50:30 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14891; Wed, 11 Sep 2002 11:50:28 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA16275; Wed, 11 Sep 2002 11:50:30 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QS3QR>; Wed, 11 Sep 2002 11:50:29 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Alex Zinin'" <[e-mail]>, Yakov Rekhter <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 11:50:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Alex:
  YOu are correct, I must have missed the appendix when I read the core
sections. Perhaps a pointer to the appendix that talks about this will
be helpfull.

BTW there are two section 6.2 in the spec, one called 
"6.2 OPEN message error handling", and the other called
"6.2 Processing Messages on a Stream Protocol".

Using same type of sections number in Appendix A is not 
good. Especially if you search for strings.

I will renumber the Appendix 1 and use letters like
Appendix A, sections to A1, A6.2, etc.

Ben

> -----Original Message-----
> From: Alex Zinin [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 11:40 AM
> To: Yakov Rekhter
> Cc: Abarbanel, Benjamin; '[e-mail]'
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> Yakov, Ben-
> 
>  I thought section 6.2 "Processing Messages on a Stream Protocol"
>  actually talked about these things...
> 
> -- 
> Alex
> 
> Wednesday, September 11, 2002, 5:36:47 PM, Yakov Rekhter wrote:
> > Ben,
> 
> >> Yakov:
> >>   That may be true, but I have seen in a couple of BGP 
> implementations
> >> handling the socket level that the BGP code had to 
> reassemble the logical
> >> packet. TCP did not do it. 
> >> 
> >> What I mean the application code had to read from the 
> socket several times
> >> to get the entire packet and reassemble it, before passing 
> it to the BGP
> >> state machine.
> 
> > This is purely an *implementation* issue, and as such is not
> > subject to standardization.
> 
> > Yakov.
> 
> >> 
> >> Ben
> >> 
> >> > -----Original Message-----
> >> > From: Yakov Rekhter [mailto:[e-mail]]
> >> > Sent: Wednesday, September 11, 2002 11:26 AM
> >> > To: Abarbanel, Benjamin
> >> > Cc: '[e-mail]'
> >> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> >> > 
> >> > 
> >> > Ben,
> >> > 
> >> > > Part I.
> >> > > 
> >> > > Technical Comments:
> >> > > ===================
> >> > > 1. P.6  section 4. Message Formats, its possible for the 
> >> > source BGP peer IP
> >> > > layer to fragment a message such that the receiving BGP 
> >> > peer socket layer
> >> > > would have to reassemble it. Need to mention this, since 
> >> > BGP implementations
> >> > > are required to do this.  
> >> > 
> >> > *BGP* implementations are *not* required to perform any 
> >> > message reassembly.
> >> > (remember this is BGP spec, not TCP and/or IP spec).
> >> > 
> >> > 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 LAA15741 for <[e-mail]>; Wed, 11 Sep 2002 11:50:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B204C9137D; Wed, 11 Sep 2002 11:49:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8355C9137F; Wed, 11 Sep 2002 11:49:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE7D19137D for <[e-mail]>; Wed, 11 Sep 2002 11:48:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A0C285DE30; Wed, 11 Sep 2002 11:48:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 0DC865DE3D for <[e-mail]>; Wed, 11 Sep 2002 11:48:22 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BFmKm57285; Wed, 11 Sep 2002 08:48:20 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 11:38:36 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 08:48:20 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> I realize if we do what I suggest, there will have to be a transition
> period where the two types are in the same message as well as separate
> messages. If they are in the same message, we need to keep the existing
> rules, until everyone (?) upgrades, then we can obsolete these rules.

Please bear in mind that the spec is about what is *currently* deployed.
As such any change to the base spec that required upgrades/transition
is outside the scope of the current discussion.

Yakov.

> 
> Ben
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Wednesday, September 11, 2002 11:34 AM
> > To: Abarbanel, Benjamin
> > Cc: 'Kaarthik Sivakumar'; '[e-mail]'
> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> > 
> > 
> > Ben,
> > 
> > > No it means if they are placed in different messages and 
> > sent in the order 
> > > that the source router wants the destination router to 
> > execute them. 
> > > 
> > > It just makes the messages simpler, requiring less rules of 
> > processing.
> > 
> > it also makes the case where they are in the same message unspecified.
> >   
> > > Ben
> > > 
> > > > -----Original Message-----
> > > > From: Kaarthik Sivakumar [mailto:[e-mail]]
> > > > Sent: Wednesday, September 11, 2002 11:12 AM
> > > > To: Abarbanel, Benjamin
> > > > Cc: '[e-mail]'
> > > > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> > > > 
> > > > 
> > > > >>> "BA" == Benjamin Abarbanel <Abarbanel> writes:
> > > > 
> > > > [...]
> > > > 
> > > > BA> 4. P.16, last paragraph in section 4.3 as stated,
> > > > BA>  "An UPDATE message should not include the same address 
> > > > prefix in the
> > > > BA>   WITHDRAWN ROUTES and Network Layer Reachability 
> > > > Information fields,
> > > > BA>   however a BGP speaker MUST be able to process UPDATE 
> > > messages in this
> > > > BA>   form. A BGP speaker should treat an UPDATE message of 
> > > > this form as if
> > > > BA>   the WITHDRAWN ROUTES doesn't contain the address prefix."
> > > >               
> > > > BA> This complexity could have been avoided if withdrawn 
> > > > routes and NRLI
> > > > BA> prefixes with their attributes were mutually exclusive of 
> > > > each other and
> > > > BA> appeared in different update messages. If that was the 
> > > > case, the priority of
> > > > BA> which field to process first would have been as simple as 
> > > > using "first come,
> > > > BA> first served" message processing approach.
> > > > 
> > > > What you suggest isnt the same as what is there now. The 
> > draft says
> > > > that NLRI has higher preference to a WITHDRAWN prefix and 
> > this makes
> > > > the behavior predictable. In what you suggest the behavior isnt
> > > > predictable. Or is it? Hmm .. Maybe I am mistaken here, 
> > but it doesnt
> > > > seem like the same thing.
> > > > 
> > > > Kaarthik
> > > > 
> > 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA15734 for <[e-mail]>; Wed, 11 Sep 2002 11:50:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2CBFF9138B; Wed, 11 Sep 2002 11:49:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECE7B91384; Wed, 11 Sep 2002 11:49:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E6A959137E for <[e-mail]>; Wed, 11 Sep 2002 11:49:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C43665DE43; Wed, 11 Sep 2002 11:49:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 681905DE30 for <[e-mail]>; Wed, 11 Sep 2002 11:49:19 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BFnHm57374; Wed, 11 Sep 2002 08:49:17 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 11:40:01 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 08:49:17 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> Actually, I would venture to say that all BGP implementations that use the
> basic UNIX TCP/IP paradigm have to do this. If I am wrong, anyone please
> correct me.

Using UNIX TCP/IP paradigm is *not* a requirement for a BGP implementation.

Yakov.

> 
> Ben
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Wednesday, September 11, 2002 11:37 AM
> > To: Abarbanel, Benjamin
> > Cc: '[e-mail]'
> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> > 
> > 
> > Ben,
> > 
> > > Yakov:
> > >   That may be true, but I have seen in a couple of BGP 
> > implementations
> > > handling the socket level that the BGP code had to 
> > reassemble the logical
> > > packet. TCP did not do it. 
> > > 
> > > What I mean the application code had to read from the 
> > socket several times
> > > to get the entire packet and reassemble it, before passing 
> > it to the BGP
> > > state machine.
> > 
> > This is purely an *implementation* issue, and as such is not
> > subject to standardization.
> > 
> > Yakov.
> > 
> > > 
> > > Ben
> > > 
> > > > -----Original Message-----
> > > > From: Yakov Rekhter [mailto:[e-mail]]
> > > > Sent: Wednesday, September 11, 2002 11:26 AM
> > > > To: Abarbanel, Benjamin
> > > > Cc: '[e-mail]'
> > > > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> > > > 
> > > > 
> > > > Ben,
> > > > 
> > > > > Part I.
> > > > > 
> > > > > Technical Comments:
> > > > > ===================
> > > > > 1. P.6  section 4. Message Formats, its possible for the 
> > > > source BGP peer IP
> > > > > layer to fragment a message such that the receiving BGP 
> > > > peer socket layer
> > > > > would have to reassemble it. Need to mention this, since 
> > > > BGP implementations
> > > > > are required to do this.  
> > > > 
> > > > *BGP* implementations are *not* required to perform any 
> > > > message reassembly.
> > > > (remember this is BGP spec, not TCP and/or IP spec).
> > > > 
> > > > 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 LAA15503 for <[e-mail]>; Wed, 11 Sep 2002 11:42:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 96F96912FB; Wed, 11 Sep 2002 11:42:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 686329136B; Wed, 11 Sep 2002 11:42:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D73F6912FB for <[e-mail]>; Wed, 11 Sep 2002 11:41:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BB2295DE3C; Wed, 11 Sep 2002 11:41:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 8AAAB5DE30 for <[e-mail]>; Wed, 11 Sep 2002 11:41:58 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17p9cp-0001gj-00; Wed, 11 Sep 2002 08:41:56 -0700
Date: Wed, 11 Sep 2002 17:40:00 +0200
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Yakov, Ben-

 I thought section 6.2 "Processing Messages on a Stream Protocol"
 actually talked about these things...

-- 
Alex

Wednesday, September 11, 2002, 5:36:47 PM, Yakov Rekhter wrote:
> Ben,

>> Yakov:
>>   That may be true, but I have seen in a couple of BGP implementations
>> handling the socket level that the BGP code had to reassemble the logical
>> packet. TCP did not do it. 
>> 
>> What I mean the application code had to read from the socket several times
>> to get the entire packet and reassemble it, before passing it to the BGP
>> state machine.

> This is purely an *implementation* issue, and as such is not
> subject to standardization.

> Yakov.

>> 
>> Ben
>> 
>> > -----Original Message-----
>> > From: Yakov Rekhter [mailto:[e-mail]]
>> > Sent: Wednesday, September 11, 2002 11:26 AM
>> > To: Abarbanel, Benjamin
>> > Cc: '[e-mail]'
>> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
>> > 
>> > 
>> > Ben,
>> > 
>> > > Part I.
>> > > 
>> > > Technical Comments:
>> > > ===================
>> > > 1. P.6  section 4. Message Formats, its possible for the 
>> > source BGP peer IP
>> > > layer to fragment a message such that the receiving BGP 
>> > peer socket layer
>> > > would have to reassemble it. Need to mention this, since 
>> > BGP implementations
>> > > are required to do this.  
>> > 
>> > *BGP* implementations are *not* required to perform any 
>> > message reassembly.
>> > (remember this is BGP spec, not TCP and/or IP spec).
>> > 
>> > 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 LAA15446 for <[e-mail]>; Wed, 11 Sep 2002 11:40:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E034B912FD; Wed, 11 Sep 2002 11:40:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1ADE9136B; Wed, 11 Sep 2002 11:40:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 81ABC912FD for <[e-mail]>; Wed, 11 Sep 2002 11:40:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5F2FD5DE30; Wed, 11 Sep 2002 11:40:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id CBD5E5DE49 for <[e-mail]>; Wed, 11 Sep 2002 11:40:04 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14276; Wed, 11 Sep 2002 11:40:02 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14352; Wed, 11 Sep 2002 11:40:02 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QSN09>; Wed, 11 Sep 2002 11:40:02 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
Date: Wed, 11 Sep 2002 11:40:01 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Actually, I would venture to say that all BGP implementations that use the
basic UNIX TCP/IP paradigm have to do this. If I am wrong, anyone please
correct me.

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 11:37 AM
> To: Abarbanel, Benjamin
> Cc: '[e-mail]'
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> 
> 
> Ben,
> 
> > Yakov:
> >   That may be true, but I have seen in a couple of BGP 
> implementations
> > handling the socket level that the BGP code had to 
> reassemble the logical
> > packet. TCP did not do it. 
> > 
> > What I mean the application code had to read from the 
> socket several times
> > to get the entire packet and reassemble it, before passing 
> it to the BGP
> > state machine.
> 
> This is purely an *implementation* issue, and as such is not
> subject to standardization.
> 
> Yakov.
> 
> > 
> > Ben
> > 
> > > -----Original Message-----
> > > From: Yakov Rekhter [mailto:[e-mail]]
> > > Sent: Wednesday, September 11, 2002 11:26 AM
> > > To: Abarbanel, Benjamin
> > > Cc: '[e-mail]'
> > > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> > > 
> > > 
> > > Ben,
> > > 
> > > > Part I.
> > > > 
> > > > Technical Comments:
> > > > ===================
> > > > 1. P.6  section 4. Message Formats, its possible for the 
> > > source BGP peer IP
> > > > layer to fragment a message such that the receiving BGP 
> > > peer socket layer
> > > > would have to reassemble it. Need to mention this, since 
> > > BGP implementations
> > > > are required to do this.  
> > > 
> > > *BGP* implementations are *not* required to perform any 
> > > message reassembly.
> > > (remember this is BGP spec, not TCP and/or IP spec).
> > > 
> > > 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 LAA15396 for <[e-mail]>; Wed, 11 Sep 2002 11:38:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 63BE69137C; Wed, 11 Sep 2002 11:38:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 28E9D9136B; Wed, 11 Sep 2002 11:38:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 688C49137E for <[e-mail]>; Wed, 11 Sep 2002 11:38:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5623A5DE30; Wed, 11 Sep 2002 11:38:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id C2B475DE3D for <[e-mail]>; Wed, 11 Sep 2002 11:38:38 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14167; Wed, 11 Sep 2002 11:38:36 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14106; Wed, 11 Sep 2002 11:38:37 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QSN9D>; Wed, 11 Sep 2002 11:38:36 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Kaarthik Sivakumar'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
Date: Wed, 11 Sep 2002 11:38:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I realize if we do what I suggest, there will have to be a transition
period where the two types are in the same message as well as separate
messages. If they are in the same message, we need to keep the existing
rules, until everyone (?) upgrades, then we can obsolete these rules.

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 11:34 AM
> To: Abarbanel, Benjamin
> Cc: 'Kaarthik Sivakumar'; '[e-mail]'
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> 
> 
> Ben,
> 
> > No it means if they are placed in different messages and 
> sent in the order 
> > that the source router wants the destination router to 
> execute them. 
> > 
> > It just makes the messages simpler, requiring less rules of 
> processing.
> 
> it also makes the case where they are in the same message unspecified.
>   
> > Ben
> > 
> > > -----Original Message-----
> > > From: Kaarthik Sivakumar [mailto:[e-mail]]
> > > Sent: Wednesday, September 11, 2002 11:12 AM
> > > To: Abarbanel, Benjamin
> > > Cc: '[e-mail]'
> > > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> > > 
> > > 
> > > >>> "BA" == Benjamin Abarbanel <Abarbanel> writes:
> > > 
> > > [...]
> > > 
> > > BA> 4. P.16, last paragraph in section 4.3 as stated,
> > > BA>  "An UPDATE message should not include the same address 
> > > prefix in the
> > > BA>   WITHDRAWN ROUTES and Network Layer Reachability 
> > > Information fields,
> > > BA>   however a BGP speaker MUST be able to process UPDATE 
> > > messages in this
> > > BA>   form. A BGP speaker should treat an UPDATE message of 
> > > this form as if
> > > BA>   the WITHDRAWN ROUTES doesn't contain the address prefix."
> > >               
> > > BA> This complexity could have been avoided if withdrawn 
> > > routes and NRLI
> > > BA> prefixes with their attributes were mutually exclusive of 
> > > each other and
> > > BA> appeared in different update messages. If that was the 
> > > case, the priority of
> > > BA> which field to process first would have been as simple as 
> > > using "first come,
> > > BA> first served" message processing approach.
> > > 
> > > What you suggest isnt the same as what is there now. The 
> draft says
> > > that NLRI has higher preference to a WITHDRAWN prefix and 
> this makes
> > > the behavior predictable. In what you suggest the behavior isnt
> > > predictable. Or is it? Hmm .. Maybe I am mistaken here, 
> but it doesnt
> > > seem like the same thing.
> > > 
> > > Kaarthik
> > > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA15346 for <[e-mail]>; Wed, 11 Sep 2002 11:37:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3D6A7912F1; Wed, 11 Sep 2002 11:36:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF0F791380; Wed, 11 Sep 2002 11:36:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9E091912F1 for <[e-mail]>; Wed, 11 Sep 2002 11:36:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 869C55DE3D; Wed, 11 Sep 2002 11:36:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 2C12E5DE30 for <[e-mail]>; Wed, 11 Sep 2002 11:36:49 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BFalm56431; Wed, 11 Sep 2002 08:36:47 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 11:30:29 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 08:36:47 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> Yakov:
>   That may be true, but I have seen in a couple of BGP implementations
> handling the socket level that the BGP code had to reassemble the logical
> packet. TCP did not do it. 
> 
> What I mean the application code had to read from the socket several times
> to get the entire packet and reassemble it, before passing it to the BGP
> state machine.

This is purely an *implementation* issue, and as such is not
subject to standardization.

Yakov.

> 
> Ben
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Wednesday, September 11, 2002 11:26 AM
> > To: Abarbanel, Benjamin
> > Cc: '[e-mail]'
> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> > 
> > 
> > Ben,
> > 
> > > Part I.
> > > 
> > > Technical Comments:
> > > ===================
> > > 1. P.6  section 4. Message Formats, its possible for the 
> > source BGP peer IP
> > > layer to fragment a message such that the receiving BGP 
> > peer socket layer
> > > would have to reassemble it. Need to mention this, since 
> > BGP implementations
> > > are required to do this.  
> > 
> > *BGP* implementations are *not* required to perform any 
> > message reassembly.
> > (remember this is BGP spec, not TCP and/or IP spec).
> > 
> > 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 LAA15338 for <[e-mail]>; Wed, 11 Sep 2002 11:37:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 89911912EE; Wed, 11 Sep 2002 11:34:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 568D4912F1; Wed, 11 Sep 2002 11:34:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 75B47912EE for <[e-mail]>; Wed, 11 Sep 2002 11:34:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 584ED5DE3C; Wed, 11 Sep 2002 11:34:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id F04105DE30 for <[e-mail]>; Wed, 11 Sep 2002 11:34:37 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BFYTm56350; Wed, 11 Sep 2002 08:34:29 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Kaarthik Sivakumar'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 11:14:39 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 08:34:29 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> No it means if they are placed in different messages and sent in the order 
> that the source router wants the destination router to execute them. 
> 
> It just makes the messages simpler, requiring less rules of processing.

it also makes the case where they are in the same message unspecified.
  
> Ben
> 
> > -----Original Message-----
> > From: Kaarthik Sivakumar [mailto:[e-mail]]
> > Sent: Wednesday, September 11, 2002 11:12 AM
> > To: Abarbanel, Benjamin
> > Cc: '[e-mail]'
> > Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> > 
> > 
> > >>> "BA" == Benjamin Abarbanel <Abarbanel> writes:
> > 
> > [...]
> > 
> > BA> 4. P.16, last paragraph in section 4.3 as stated,
> > BA>  "An UPDATE message should not include the same address 
> > prefix in the
> > BA>   WITHDRAWN ROUTES and Network Layer Reachability 
> > Information fields,
> > BA>   however a BGP speaker MUST be able to process UPDATE 
> > messages in this
> > BA>   form. A BGP speaker should treat an UPDATE message of 
> > this form as if
> > BA>   the WITHDRAWN ROUTES doesn't contain the address prefix."
> >               
> > BA> This complexity could have been avoided if withdrawn 
> > routes and NRLI
> > BA> prefixes with their attributes were mutually exclusive of 
> > each other and
> > BA> appeared in different update messages. If that was the 
> > case, the priority of
> > BA> which field to process first would have been as simple as 
> > using "first come,
> > BA> first served" message processing approach.
> > 
> > What you suggest isnt the same as what is there now. The draft says
> > that NLRI has higher preference to a WITHDRAWN prefix and this makes
> > the behavior predictable. In what you suggest the behavior isnt
> > predictable. Or is it? Hmm .. Maybe I am mistaken here, but it doesnt
> > seem like the same thing.
> > 
> > Kaarthik
> > 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA15115 for <[e-mail]>; Wed, 11 Sep 2002 11:31:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BC5E2912ED; Wed, 11 Sep 2002 11:30:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8FDFB912EE; Wed, 11 Sep 2002 11:30:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 30511912ED for <[e-mail]>; Wed, 11 Sep 2002 11:30:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1A3F25DE36; Wed, 11 Sep 2002 11:30:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 92E705DE30 for <[e-mail]>; Wed, 11 Sep 2002 11:30:31 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA13544; Wed, 11 Sep 2002 11:30:29 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA12416; Wed, 11 Sep 2002 11:30:30 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QSNPA>; Wed, 11 Sep 2002 11:30:30 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt 
Date: Wed, 11 Sep 2002 11:30:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov:
  That may be true, but I have seen in a couple of BGP implementations
handling the socket level that the BGP code had to reassemble the logical
packet. TCP did not do it. 

What I mean the application code had to read from the socket several times
to get the entire packet and reassemble it, before passing it to the BGP
state 
machine.

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 11:26 AM
> To: Abarbanel, Benjamin
> Cc: '[e-mail]'
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
> 
> 
> Ben,
> 
> > Part I.
> > 
> > Technical Comments:
> > ===================
> > 1. P.6  section 4. Message Formats, its possible for the 
> source BGP peer IP
> > layer to fragment a message such that the receiving BGP 
> peer socket layer
> > would have to reassemble it. Need to mention this, since 
> BGP implementations
> > are required to do this.  
> 
> *BGP* implementations are *not* required to perform any 
> message reassembly.
> (remember this is BGP spec, not TCP and/or IP spec).
> 
> 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 LAA14968 for <[e-mail]>; Wed, 11 Sep 2002 11:26:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5CB40912E5; Wed, 11 Sep 2002 11:26:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29C67912ED; Wed, 11 Sep 2002 11:26:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 09BD4912E5 for <[e-mail]>; Wed, 11 Sep 2002 11:26:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EB1445DE36; Wed, 11 Sep 2002 11:26:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 6170F5DE30 for <[e-mail]>; Wed, 11 Sep 2002 11:26:08 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8BFQ6m55805; Wed, 11 Sep 2002 08:26:06 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt 
In-Reply-To: Your message of "Wed, 11 Sep 2002 10:45:06 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 11 Sep 2002 08:26:06 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> Part I.
> 
> Technical Comments:
> ===================
> 1. P.6  section 4. Message Formats, its possible for the source BGP peer IP
> layer to fragment a message such that the receiving BGP peer socket layer
> would have to reassemble it. Need to mention this, since BGP implementations
> are required to do this.  

*BGP* implementations are *not* required to perform any message reassembly.
(remember this is BGP spec, not TCP and/or IP spec).

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 LAA14577 for <[e-mail]>; Wed, 11 Sep 2002 11:15:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 265A3912E0; Wed, 11 Sep 2002 11:14:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5CA0912E2; Wed, 11 Sep 2002 11:14:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 066B4912E0 for <[e-mail]>; Wed, 11 Sep 2002 11:14:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E29C65DE43; Wed, 11 Sep 2002 11:14:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 296D45DE30 for <[e-mail]>; Wed, 11 Sep 2002 11:14:45 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA12133; Wed, 11 Sep 2002 11:14:42 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA08853; Wed, 11 Sep 2002 11:14:43 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QSMQ1>; Wed, 11 Sep 2002 11:14:42 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Kaarthik Sivakumar'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 11:14:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

No it means if they are placed in different messages and sent in the order 
that the source router wants the destination router to execute them. 

It just makes the messages simpler, requiring less rules of processing.

Ben

> -----Original Message-----
> From: Kaarthik Sivakumar [mailto:[e-mail]]
> Sent: Wednesday, September 11, 2002 11:12 AM
> To: Abarbanel, Benjamin
> Cc: '[e-mail]'
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
> 
> 
> >>> "BA" == Benjamin Abarbanel <Abarbanel> writes:
> 
> [...]
> 
> BA> 4. P.16, last paragraph in section 4.3 as stated,
> BA>  "An UPDATE message should not include the same address 
> prefix in the
> BA>   WITHDRAWN ROUTES and Network Layer Reachability 
> Information fields,
> BA>   however a BGP speaker MUST be able to process UPDATE 
> messages in this
> BA>   form. A BGP speaker should treat an UPDATE message of 
> this form as if
> BA>   the WITHDRAWN ROUTES doesn't contain the address prefix."
>               
> BA> This complexity could have been avoided if withdrawn 
> routes and NRLI
> BA> prefixes with their attributes were mutually exclusive of 
> each other and
> BA> appeared in different update messages. If that was the 
> case, the priority of
> BA> which field to process first would have been as simple as 
> using "first come,
> BA> first served" message processing approach.
> 
> What you suggest isnt the same as what is there now. The draft says
> that NLRI has higher preference to a WITHDRAWN prefix and this makes
> the behavior predictable. In what you suggest the behavior isnt
> predictable. Or is it? Hmm .. Maybe I am mistaken here, but it doesnt
> seem like the same thing.
> 
> Kaarthik
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA14485 for <[e-mail]>; Wed, 11 Sep 2002 11:12:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BE8A0912DD; Wed, 11 Sep 2002 11:12:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 920F2912DF; Wed, 11 Sep 2002 11:12:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8A51D912DD for <[e-mail]>; Wed, 11 Sep 2002 11:11:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 708CD5DE49; Wed, 11 Sep 2002 11:11:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by segue.merit.edu (Postfix) with ESMTP id 108815DE43 for <[e-mail]>; Wed, 11 Sep 2002 11:11:59 -0400 (EDT)
Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g8BFBqa55336; Wed, 11 Sep 2002 11:11:52 -0400 (EDT)
Received: from coors.torrentnet.com (coors.torrentnet.com [4.21.152.11]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g8BFBqI67416; Wed, 11 Sep 2002 11:11:52 -0400 (EDT)
Received: (from kaarthik@localhost) by coors.torrentnet.com (8.11.2/8.11.2) id g8BFBqJ84745; Wed, 11 Sep 2002 11:11:52 -0400 (EDT)
X-Authentication-Warning: coors.torrentnet.com: kaarthik set sender to [e-mail] using -f
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: Re: Review of draft-ietf-idr-bgp4-17.txt
References: <[e-mail]>
From: Kaarthik Sivakumar <[e-mail]>
In-Reply-To: <[e-mail]>
Date: 11 Sep 2002 11:11:51 -0400
Message-ID: <[e-mail]>
Lines: 24
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Channel Islands)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

>>> "BA" == Benjamin Abarbanel <Abarbanel> writes:

[...]

BA> 4. P.16, last paragraph in section 4.3 as stated,
BA>  "An UPDATE message should not include the same address prefix in the
BA>   WITHDRAWN ROUTES and Network Layer Reachability Information fields,
BA>   however a BGP speaker MUST be able to process UPDATE messages in this
BA>   form. A BGP speaker should treat an UPDATE message of this form as if
BA>   the WITHDRAWN ROUTES doesn't contain the address prefix."
              
BA> This complexity could have been avoided if withdrawn routes and NRLI
BA> prefixes with their attributes were mutually exclusive of each other and
BA> appeared in different update messages. If that was the case, the priority of
BA> which field to process first would have been as simple as using "first come,
BA> first served" message processing approach.

What you suggest isnt the same as what is there now. The draft says
that NLRI has higher preference to a WITHDRAWN prefix and this makes
the behavior predictable. In what you suggest the behavior isnt
predictable. Or is it? Hmm .. Maybe I am mistaken here, but it doesnt
seem like the same thing.

Kaarthik


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA14319 for <[e-mail]>; Wed, 11 Sep 2002 11:07:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E5862912DA; Wed, 11 Sep 2002 11:06:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB0F7912DB; Wed, 11 Sep 2002 11:06:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 47FC6912DA for <[e-mail]>; Wed, 11 Sep 2002 11:06:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 393C05DE43; Wed, 11 Sep 2002 11:06:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id BF3EE5DE30 for <[e-mail]>; Wed, 11 Sep 2002 11:06:36 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8BF6Vq54585; Wed, 11 Sep 2002 11:06:31 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([65.241.132.110]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g8BF6RG54578; Wed, 11 Sep 2002 11:06:28 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Wed, 11 Sep 2002 23:06:23 -0400
To: Manav Bhatia <[e-mail]>
From: Susan Hares <[e-mail]>
Subject: Re: Hold Timer
Cc: [e-mail]
In-Reply-To: <02a101c25950$042e63c0$[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Manav:

Per the charter suggested by the ADS, this subject is off the
text until we get to Route Refresh, Dynamic Capabilities, etc.
If you have concerns about the charter's order, please comment
on the charter discussion.

As you stated, I answered this question earlier on the mail list.
Was there a reason you raised this question again?

Sue

At 10:29 AM 9/11/2002 +0530, Manav Bhatia wrote:
>Folks,
>In the current FSM text we restart the KeepAlive timer only when we receive
>KEEPALIVE and UPDATE messages from the remote peer. It was discussed some
>time back on the list that we can do the same for other valid non
>destructive BGP packets. I find this missing in the new draft and wanted to
>know as to when is this being planned to be included in the base spec?
>
>If this is not supposed to be a part of the base spec as most of these
>additonal non destructive packets (Route Refresh, Dynamic Cap, INFORM) fall
>out of the scope of that draft then where do we intend to capture this (the
>base spec or the drafts introducing such messages)?
>
>Regards,
>Manav




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA14286 for <[e-mail]>; Wed, 11 Sep 2002 11:06:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5AD3D912D9; Wed, 11 Sep 2002 11:05:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 221B7912DA; Wed, 11 Sep 2002 11:05:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0049B912D9 for <[e-mail]>; Wed, 11 Sep 2002 11:05:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DC1CA5DE43; Wed, 11 Sep 2002 11:05:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 5F8125DE30 for <[e-mail]>; Wed, 11 Sep 2002 11:05:50 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA11466 for <[e-mail]>; Wed, 11 Sep 2002 11:05:48 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA07149 for <[e-mail]>; Wed, 11 Sep 2002 11:05:49 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QSMB4>; Wed, 11 Sep 2002 11:05:48 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 11:05:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Part II:

Editorial Comments:
===================

1. P. 41. Typing error, "Each time time the local system...".

2. Section 9.1, Need to have Adj-RIB-In, Adj-RIB-Out, and Loc-RIB in the
glossary, so when they are used in section 9.1, it is well understood what
they are.

3. P. 45, Phase I, There is no definition of what are unfeasible routes? Are
they the same as withdrawn routes? If so, the two should be combined to one
name.

4. P. 50,  line, "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 (see 9.2)."

Would like to rephrase the sentence for clarity,
"If a route in Loc-RIB is excluded from a particular Adj-RIB-Out and was
previously advertised via Adj-RIB-Out, it must be withdrawn from service by
means of an UPDATE message (see 9.2)."

5. P. 50, section 9.1.4, The two fragments of this sentence are redundant
and don't say anything new or simplify the content. Just keep one fragment.
"A route describing a smaller set of destinations (a longer prefix) is said
to be more specific than a route describing a larger set of destinations (a
shorted prefix); similarly, a route describing a larger set of destinations
(a shorter prefix) is said to be less specific than a route describing a
smaller set of destinations (a longer prefix)."

6. P. 52, section 9.2.1.1 Change this sentence for clarity,
   "This rate limiting procedure applies on a per-destination basis,
although  
    the value of MinRouteAdvertisementInterval is set on a per BGP peer
basis."

 To This:
   "This rate limiting procedure applies on a per-destination basis,
although    
    the value of MinRouteAdvertisementInterval is set on a BGP router (same 
    value for all peers) basis."

7. P. 61, item 6.4. Although all the BGP protocol interfacing timers are  
   mentioned, there are a few FSM internal timers mentioned in the spec that

   need to be covered  here as well.

8. Since there is going to be an FSM spec, do we need to have FSM 
   descriptions in this spec. Maybe the FSM section should be delete.

Overall Comment:
================
Spec is well written for its technical content, buts needs a little more
structure for the various types of sections it has. Implying moving 
and recombining sections into key sections, (e.g. Update message processing
and its fields should be combined).


Thats all Folks!




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA13999 for <[e-mail]>; Wed, 11 Sep 2002 10:59:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D1257912D8; Wed, 11 Sep 2002 10:58:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E404912D9; Wed, 11 Sep 2002 10:58:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B5052912D8 for <[e-mail]>; Wed, 11 Sep 2002 10:58:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9FB315DE3D; Wed, 11 Sep 2002 10:58:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 28B135DE30 for <[e-mail]>; Wed, 11 Sep 2002 10:58:39 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10866 for <[e-mail]>; Wed, 11 Sep 2002 10:58:36 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA04833 for <[e-mail]>; Wed, 11 Sep 2002 10:58:38 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QSLK9>; Wed, 11 Sep 2002 10:58:37 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 10:58:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Part I:

Editorial Comments:
===================
1. P. 7 Type: Need to add the new message types such as, Capability
Negotiations (RFC2842), Route Refresh, etc.

2. P. 9, right after "This document defines the following optional
parameters:"
Need to mention possible options, such as: Capabilitites (RFC2842),
Multiprotocol extensions (RFC2858), Route Refresh (RFC2918).

3. P. 13, EGP, are there other EGP protocols other than BGP that are in use?
If not, change EGP to BGP.

4. P.23, change the following: 

"The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
 links to discriminate among multiple exit or entry points to the same
 neighboring AS ..."

 To the following:

"The MULTI_EXIT_DISC is an optional non-transitive attribute which may be
used on external (inter-AS) links to discriminate among multiple exit or
entry points to the same neighboring AS ..."

5. In section 8, there are a number of Timers, Counters, etc. that need to
be explicitly defined before they are used by the FSM. Perhaps these
definitions should go in the Glossary section.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA13824 for <[e-mail]>; Wed, 11 Sep 2002 10:53:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 62A43912D7; Wed, 11 Sep 2002 10:52:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2FDD3912D8; Wed, 11 Sep 2002 10:52:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4CD75912D7 for <[e-mail]>; Wed, 11 Sep 2002 10:52:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3D9F25DE36; Wed, 11 Sep 2002 10:52:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id BAB4D5DE30 for <[e-mail]>; Wed, 11 Sep 2002 10:52:35 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10397 for <[e-mail]>; Wed, 11 Sep 2002 10:52:33 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03841 for <[e-mail]>; Wed, 11 Sep 2002 10:52:35 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QSLDH>; Wed, 11 Sep 2002 10:52:34 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 10:52:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Part II.

Technical Comments:
===================

1. P.28, 2nd to last paragraph. The line that reads, "To be semantically
correct, the IP address in the NEXT_HOP must not be the IP address of the
receiving speaker, and the NEXT_HOP IP address must either be the sender's
IP address (used to establish the BGP session), or the interface associated
with the NEXT_HOP IP address must share a common subnet with the receiving
BGP speaker..."

This is not always true, what if the current ASBR BGP router is advertising
an external AS route (to a IBGP Peer) whose NEXT_HOP IP address is the IP
address of the EBGP peer in the other AS?

2. P. 29, Section 6.3. Add this rule near the attribute rules.
"Multiple prefixes that require the same attribute type with different
values must never appear in the same update message".

3. P. 29, Section 6.5, Please rewrite this sentence from:
    "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 ..."

 To This:
    "If a system does not receive successive KEEPALIVE and/or UPDATE
     and/or any other BGP message within the period specified in the Hold
     Time field of the OPEN message ..."
4. P. 31, section 6.8, Please rewrite this sentence from:
   "Comparing BGP Identifiers is done by treating them as (4-octet long)
    unsigned integers."
             
 To This:
   "Comparing BGP Identifiers is done by treating them as large numbers
based 
    on their IP Address type (e.g. IPv4, IPv6, etc.)."

5. P.46, last sentence, "However, corresponding unresolvable routes SHOULD
be kept in the Adj-RIBs-In."  It would helpful if the author states why
unresolvable routes should be kept in Adj-RIBs-In?





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA13574 for <[e-mail]>; Wed, 11 Sep 2002 10:46:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 874C3912D6; Wed, 11 Sep 2002 10:45:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18792912D7; Wed, 11 Sep 2002 10:45:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 41C67912D6 for <[e-mail]>; Wed, 11 Sep 2002 10:45:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CB0EB5DE39; Wed, 11 Sep 2002 10:45:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id E3F065DE36 for <[e-mail]>; Wed, 11 Sep 2002 10:45:09 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA09684 for <[e-mail]>; Wed, 11 Sep 2002 10:45:07 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02084 for <[e-mail]>; Wed, 11 Sep 2002 10:45:08 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QSK41>; Wed, 11 Sep 2002 10:45:07 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 10:45:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Part I.

Technical Comments:
===================
1. P.6  section 4. Message Formats, its possible for the source BGP peer IP
layer to fragment a message such that the receiving BGP peer socket layer
would have to reassemble it. Need to mention this, since BGP implementations
are required to do this.  

2. P. 10, "Authentication Data:" section you might want to add this,
It is also possible to use MD5 (RFC2385) at the transport layer to validate
the entire BGP message.

3. P. 12, right after "Path Attributes". The following sentence should be
added to this section to clarify the scope of the Path Attribute field.
"All attributes in the Path Attribute field represent the characteristics of
all the route prefixes defined in the NLRI field of the message".

4. P.16, last paragraph in section 4.3 as stated,
 "An UPDATE message should not include the same address prefix in the
  WITHDRAWN ROUTES and Network Layer Reachability Information fields,
  however a BGP speaker MUST be able to process UPDATE messages in this
  form. A BGP speaker should treat an UPDATE message of this form as if
  the WITHDRAWN ROUTES doesn't contain the address prefix."
              
This complexity could have been avoided if withdrawn routes and NRLI
prefixes with their attributes were mutually exclusive of each other and
appeared in different update messages. If that was the case, the priority of
which field to process first would have been as simple as using "first come,
first served" message processing approach.

5. P. 20 Its not stated how we delete or modify Path Attributes associated
with NLRI prefixes.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA13278 for <[e-mail]>; Wed, 11 Sep 2002 10:35:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 97217912D5; Wed, 11 Sep 2002 10:35:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 603D5912D6; Wed, 11 Sep 2002 10:35:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7AF81912D5 for <[e-mail]>; Wed, 11 Sep 2002 10:35:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 646FD5DE39; Wed, 11 Sep 2002 10:35:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id E3B1B5DE36 for <[e-mail]>; Wed, 11 Sep 2002 10:35:18 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08669 for <[e-mail]>; Wed, 11 Sep 2002 10:35:17 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29660 for <[e-mail]>; Wed, 11 Sep 2002 10:35:18 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QSKBM>; Wed, 11 Sep 2002 10:35:17 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 10:35:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

General Comment:

4. In many places in the document the term Transport Connection is used, and
in the FSM area the term TCP Connection is used. One generic term should be
used   throughout the document in case a different transport (like SCTP) is
used to service the BGP sessions.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA13252 for <[e-mail]>; Wed, 11 Sep 2002 10:35:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 101A1912D4; Wed, 11 Sep 2002 10:34:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BFBCD912D6; Wed, 11 Sep 2002 10:34:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EBCED912D4 for <[e-mail]>; Wed, 11 Sep 2002 10:33:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D27A25DE37; Wed, 11 Sep 2002 10:33:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 0D2BF5DE36 for <[e-mail]>; Wed, 11 Sep 2002 10:33:29 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08545 for <[e-mail]>; Wed, 11 Sep 2002 10:33:26 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29379 for <[e-mail]>; Wed, 11 Sep 2002 10:33:28 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QSJ0J>; Wed, 11 Sep 2002 10:33:27 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Review of draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 10:33:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

General Comment:

3. All BGP Extensions described in other documents that made it to RFC
status should be at least referenced in the Reference section P.64. This is
justifiable since it's the core BGP standard spec.


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 KAA13223 for <[e-mail]>; Wed, 11 Sep 2002 10:34:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 20E4F912D0; Wed, 11 Sep 2002 10:32:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D822F912D1; Wed, 11 Sep 2002 10:32:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A0FDF912D0 for <[e-mail]>; Wed, 11 Sep 2002 10:31:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 877485DE37; Wed, 11 Sep 2002 10:31:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 14D055DE36 for <[e-mail]>; Wed, 11 Sep 2002 10:31:57 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08377 for <[e-mail]>; Wed, 11 Sep 2002 10:31:55 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29014 for <[e-mail]>; Wed, 11 Sep 2002 10:31:56 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QSJ72>; Wed, 11 Sep 2002 10:31:55 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Review Comments:  draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 10:31:54 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

General Comment:

2. Paths, Routes, and Prefixes need to be defined in the spec early on (like
in a glossary), so it is obvious what is implied. 


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 KAA13170 for <[e-mail]>; Wed, 11 Sep 2002 10:34:30 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 18C0D912CF; Wed, 11 Sep 2002 10:31:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0300A912D0; Wed, 11 Sep 2002 10:31:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9BE36912CF for <[e-mail]>; Wed, 11 Sep 2002 10:31:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7FE715DE39; Wed, 11 Sep 2002 10:31:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 0E5D65DE37 for <[e-mail]>; Wed, 11 Sep 2002 10:31:16 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08323 for <[e-mail]>; Wed, 11 Sep 2002 10:31:13 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA28867 for <[e-mail]>; Wed, 11 Sep 2002 10:31:15 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QSJ6D>; Wed, 11 Sep 2002 10:31:14 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Review Comments:  draft-ietf-idr-bgp4-17.txt
Date: Wed, 11 Sep 2002 10:31:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

General Comment:

1. Document needs, Table of Contents, Glossary, and Index


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA11553 for <[e-mail]>; Wed, 11 Sep 2002 09:49:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2EBBF912CB; Wed, 11 Sep 2002 09:49:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F251B912CF; Wed, 11 Sep 2002 09:49:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5361A912CB for <[e-mail]>; Wed, 11 Sep 2002 09:48:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 328AA5DE30; Wed, 11 Sep 2002 09:48:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id DEDF95DD92 for <[e-mail]>; Wed, 11 Sep 2002 09:48:09 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1C2LA>; Wed, 11 Sep 2002 09:48:09 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: next hop for originated route
Date: Wed, 11 Sep 2002 09:48:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25999.DC875440"
Sender: [e-mail]
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C25999.DC875440
Content-Type: text/plain

Current implementation uses the next hop that exists for the route in 

its originating protocol except if the route gets aggregated or (of 

course) if it is advertised to the <next-hop> peer, in which case it 

is set to self.

 

For the purpose of documenting current behavior, maybe this should be added 

as a "SHOULD".  I must admit however that I cannot see any detrimental
effect

if the next hop is simply set to self, so maybe it should be a "MAY".

But currently it is not mentioned at all, which leads to confusion.

 

Comments?


------_=_NextPart_001_01C25999.DC875440
Content-Type: text/html

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">


<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>Current implementation uses
the next hop that exists for the route in </span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>its originating protocol
except if the route gets aggregated or (of </span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>course) if it is advertised
to the &lt;next-hop&gt; peer, in which case it </span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>is set to self.</span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>&nbsp;</span></font></p>

<p class=MsoNormal style='text-autospace:none'><font size=2 face="Courier New"><span
style='font-size:10.0pt;font-family:"Courier New"'>For the purpose of
documenting current behavior, maybe this should be added </span></font></p>

<p class=MsoNormal><font size=2 face="Courier New"><span style='font-size:10.0pt;
font-family:"Courier New"'>as a &quot;SHOULD&quot;.&nbsp; I must admit however that
I cannot see any detrimental effect</span></font></p>

<p class=MsoNormal><font size=2 face="Courier New"><span style='font-size:10.0pt;
font-family:"Courier New"'>if the next hop is simply set to self, so maybe it
should be a "MAY".</span></font></p>

<p class=MsoNormal><font size=2 face="Courier New"><span style='font-size:10.0pt;
font-family:"Courier New"'>But currently it is not mentioned at all, which
leads to confusion.</span></font></p>

<p class=MsoNormal><font size=2 face="Courier New"><span style='font-size:10.0pt;
font-family:"Courier New"'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face="Courier New"><span style='font-size:10.0pt;
font-family:"Courier New"'>Comments?</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C25999.DC875440--


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 IAA08216 for <[e-mail]>; Wed, 11 Sep 2002 08:05:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9F25C9137A; Wed, 11 Sep 2002 08:04:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC3E091378; Wed, 11 Sep 2002 08:04:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D06F912C7 for <[e-mail]>; Wed, 11 Sep 2002 08:01:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 867DA5DDF8; Wed, 11 Sep 2002 08:01:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 576DA5DD92 for <[e-mail]>; Wed, 11 Sep 2002 08:01:46 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17p6Bh-000ELy-00; Wed, 11 Sep 2002 05:01:43 -0700
Date: Tue, 10 Sep 2002 19:14:55 +0200
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: "Michael C. Cambria" <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: Re: Preferred method for sending review comments (Was Re: Using extended attribute length field)
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> Abarbanel, Benjamin wrote:
>> Michael and All:
>>   Although I have been guilty of discussing very detail topics on the
>> spec one at a time, on this list. I think sending a burst of detail review
>> issues one per message is somewhat not very productive

> It doesn't matter to me.  Alex Zinin sent proxy messages to the list 
> (one at a time) for discussion.  I thought that was "the way" the ADs 
> wanted it.

This is a type of detail usually left to WG, so don't read too much
into it ;) However, I personally find it much better when every issue
is discussed in its own thread--easier to discuss and keep track of. I
asked the isis-update design team to work in this mode and it proved
very productive.

Alex




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA08200 for <[e-mail]>; Wed, 11 Sep 2002 08:05:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 06CB791379; Wed, 11 Sep 2002 08:02:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7690D912C8; Wed, 11 Sep 2002 08:01:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7027C912C7 for <[e-mail]>; Wed, 11 Sep 2002 08:01:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4F7EF5DE36; Wed, 11 Sep 2002 08:01:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 20D255DD92 for <[e-mail]>; Wed, 11 Sep 2002 08:01:39 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17p6Bd-000ELy-00 for [e-mail]; Wed, 11 Sep 2002 05:01:38 -0700
Date: Tue, 10 Sep 2002 19:00:19 +0200
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: Tracking the discussion on the spec
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Folks-

 Regarding how the discussion on the list regarding the spec is
 organized, I'd like to suggest that a list of issues is maintained
 and periodically posted to the WG (with the latest ver potentially
 published on the web somewhere). Each issue brought up in the WG
 should be put on this list. Information regarding each item on the
 list should be sufficient to understand its nature, what was the WG
 consensus regarding it with required pointers to messages, quotes,
 or new text.

 Periodic posting to the WG mailing list should ensure that there are
 no dropped packets (we're all human) and that the WG consensus is
 properly reflected and documented.

 The list may be maintained either by the WG chairs or by a volunteer
 who works closely with them.

 Another suggestion would be to explicitly verify consensus in the
 cases where the discussion stalls and the agreement is not clear.
 Again periodic posting of the issue list should help ensure that
 we don't drop things here.

 Thanks a lot.
 
-- 
Alex




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA24509 for <[e-mail]>; Wed, 11 Sep 2002 01:00:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CFA60912BF; Wed, 11 Sep 2002 00:59:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B432912C0; Wed, 11 Sep 2002 00:59:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5A798912BF for <[e-mail]>; Wed, 11 Sep 2002 00:59:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 39B8E5DE3E; Wed, 11 Sep 2002 00:59:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from realname (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id D48AE5DE26 for <[e-mail]>; Wed, 11 Sep 2002 00:59:39 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) id <[e-mail]> for [e-mail]; Wed, 11 Sep 2002 14:04:00 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 11 Sep 2002 14:04:00 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 11 Sep 2002 14:04:25 +0900 (KST)
Date: Wed, 11 Sep 2002 10:29:29 +0530
From: Manav Bhatia <[e-mail]>
Subject: Hold Timer
To: [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <02a101c25950$042e63c0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,
In the current FSM text we restart the KeepAlive timer only when we receive
KEEPALIVE and UPDATE messages from the remote peer. It was discussed some
time back on the list that we can do the same for other valid non
destructive BGP packets. I find this missing in the new draft and wanted to
know as to when is this being planned to be included in the base spec?

If this is not supposed to be a part of the base spec as most of these
additonal non destructive packets (Route Refresh, Dynamic Cap, INFORM) fall
out of the scope of that draft then where do we intend to capture this (the
base spec or the drafts introducing such messages)?

Regards,
Manav



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA17197 for <[e-mail]>; Tue, 10 Sep 2002 21:21:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2E8A591360; Tue, 10 Sep 2002 21:20:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 03C9791361; Tue, 10 Sep 2002 21:20:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76B1F91360 for <[e-mail]>; Tue, 10 Sep 2002 21:20:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0AA5A5DE12; Tue, 10 Sep 2002 21:20:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from laptoy770.fictitious.org (unknown [209.150.1.238]) by segue.merit.edu (Postfix) with ESMTP id 500505DD90 for <[e-mail]>; Tue, 10 Sep 2002 21:20:51 -0400 (EDT)
Received: from laptoy770.fictitious.org (localhost [127.0.0.1]) by laptoy770.fictitious.org (8.11.2/8.11.2) with ESMTP id g8B1Lc740689; Tue, 10 Sep 2002 21:21:38 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: 
In-reply-to: Your message of "Tue, 10 Sep 2002 17:43:38 EDT." <[e-mail]> 
Date: Tue, 10 Sep 2002 21:21:38 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

Your point seems to be that the text could be modified since its under
some conditions it is OK to aggregated MED and NH prior to export.  I
think it may be best if we leave the MED statement alone or only
change it minimally since it can get you into trouble.  Unless I'm
missing something we can probably relax or eliminate the NH statement.
See below for why.

Curtis

ps - sorry for the length of this.


In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> Currently routes with different meds can be aggregated.  Bug CSCds88309
> requests a switch to stop this.  

I haven't read Cisco's bug report and Cisco behaviour and Cisco bug
reports do not define the spec.  If there is a good reason for the bug
report (like doing so breaks something) then the circumstances and
consequences of the breakage might be of interest to this list.

> Any comments on the NEXT_HOP/aggregate issue?

In both cases, the aggregation should not affect the route decision.

MED is used in local route decisions.  So if EBGP MED is configured to
be ignored, you can get away with aggregation before export into IBGP.
If MED is used just to pick the next hop, then it would be OK to
aggregate then export to IBGP.  In both of these cases, you could get
route decision differences and a route loop if not all routers are
configured the same.  That is why the spec prohibits it.  If EBGP MEDs
and IBGP MEDs are compared, then aggregating before injecting into
IBGP would alter the route decision so don't aggreagate.  The one safe
place to aggregate MED is export to EBGP peers as I indicated below.

With next hop, you can aggregate all you want if you configure
next-hop-self (the "unless" part of case 1 in "5.1.3 NEXT_HOP")
because then the NH are the same.  For EBGP, if you are not doing
third party routes, the NH advertised to the peer are always identical
so you can aggregate.  Both of these cases fall under "its the same so
aggregate".  For what would otherwise be third party EBGP routes, you
could get away with aggregating as long as you didn't mind forwarding
out the same interface to what would have been the third party, and
your peer isn't going to be upset (doesn't have a business reason to
be upset) about you taking a third party route and putting it into an
aggregate, thereby hiding it (can cause unintended, meaning "unpaid
for" transit causing some upset peers at protocol level 8).

There may be no harm done in aggregating different NH together except
for the third party EBGP issue.

Many protocol implementations allow you to just about aggregate
anything before moving the routes into anything else.  That was a goal
of the gated "aggregate" protocol in the config (that was never fully
acheived).  In doing that you provide the user with flexibility but
also the ability to do harmfull things and the ability to violate some
protocol specs.  That doesn't mean the specs should be changed to
reflect that an implementation provides a means to violate it.

In general certain things with BGP can get you into trouble but also
could be done safely if consistently configured and done carefully
enough.  We used to refer to this as "among consenting adults" but
didn't find a good way to word a general "among consenting adults"
exception into the spec.  It was easier to say "don't do that" for
situations that usually got you into trouble.  If we started
enumerating cases in which certain restrictions could be ignored, in
addition to bloating the document, we were also not entirely sure we'd
cover all of the cases and get it exactly right.  Under what
circumstances MED and NEXT_HOP can be aggregated may be one such case
were you could get into trouble and the best thing to say is "don't do
that".

Curtis


> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]] 
> Sent: Monday, September 09, 2002 11:37 PM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: 
> 
> 
> In message
> <[e-mail]
> ks.com>, "Natale, Jonathan" writes:
> > What is the purpose of:
> > 
> > Routes that have the following attributes shall not be aggregated
> >    unless the corresponding attributes of each route are identical:
> >    MULTI_EXIT_DISC, NEXT_HOP.
> > 
> > The major vendor has a bug/request to add a knob to do the MULTI_EXIT_DISC
> > part (CSCds88309).  The only reason for the second part I have heard has
> to
> > do with RPF (can't recall details).  But basically I see no reason for
> doing
> > either part and I don't think any implementations do either anyway.
> > 
> > I propose that the reason for these limits be added to the text or remove
> > the text altogether.
> > 
> > Also, is shall not == MUST???
> 
> 
> EBGP routes with MULTI_EXIT_DISC can't be aggregated before using the
> route or injecting into IBGP since doing so could alter the decision.
> 
> Routes with MED can be aggregated before export since the incoming MED
> does not affect the value of the outgoing MED (if used the exported
> MED is either configured or based on IGP cost).
> 
> At worst the AS SET might be affected (in a subtly flawed
> inplementation) but with AA being used almost exclusively this is a
> complete non-issue (in practice).  If properly implemented the
> selection would preceed entry into the RIB and the aggregate formed in
> the Adj-Rib_out would be based on those "best routes" in the RIB so
> there would be no affect on AS SET.
> 
> 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 RAA10354 for <[e-mail]>; Tue, 10 Sep 2002 17:48:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E61C4912B5; Tue, 10 Sep 2002 17:45:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 377239135B; Tue, 10 Sep 2002 17:45:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B2ED5912B5 for <[e-mail]>; Tue, 10 Sep 2002 17:43:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9BFDC5DE2C; Tue, 10 Sep 2002 17:43:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 5383A5DDF3 for <[e-mail]>; Tue, 10 Sep 2002 17:43:44 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CFVL>; Tue, 10 Sep 2002 17:43:43 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: 
Date: Tue, 10 Sep 2002 17:43:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Currently routes with different meds can be aggregated.  Bug CSCds88309
requests a switch to stop this.  

Any comments on the NEXT_HOP/aggregate issue?

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Monday, September 09, 2002 11:37 PM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: 


In message
<[e-mail]
ks.com>, "Natale, Jonathan" writes:
> What is the purpose of:
> 
> Routes that have the following attributes shall not be aggregated
>    unless the corresponding attributes of each route are identical:
>    MULTI_EXIT_DISC, NEXT_HOP.
> 
> The major vendor has a bug/request to add a knob to do the MULTI_EXIT_DISC
> part (CSCds88309).  The only reason for the second part I have heard has
to
> do with RPF (can't recall details).  But basically I see no reason for
doing
> either part and I don't think any implementations do either anyway.
> 
> I propose that the reason for these limits be added to the text or remove
> the text altogether.
> 
> Also, is shall not == MUST???


EBGP routes with MULTI_EXIT_DISC can't be aggregated before using the
route or injecting into IBGP since doing so could alter the decision.

Routes with MED can be aggregated before export since the incoming MED
does not affect the value of the outgoing MED (if used the exported
MED is either configured or based on IGP cost).

At worst the AS SET might be affected (in a subtly flawed
inplementation) but with AA being used almost exclusively this is a
complete non-issue (in practice).  If properly implemented the
selection would preceed entry into the RIB and the aggregate formed in
the Adj-Rib_out would be based on those "best routes" in the RIB so
there would be no affect on AS SET.

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 RAA09726 for <[e-mail]>; Tue, 10 Sep 2002 17:28:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 03D5A91350; Tue, 10 Sep 2002 17:27:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65D199137C; Tue, 10 Sep 2002 17:27:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1D0E091350 for <[e-mail]>; Tue, 10 Sep 2002 17:27:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0178A5DE2D; Tue, 10 Sep 2002 17:27:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id AF10F5DE18 for <[e-mail]>; Tue, 10 Sep 2002 17:27:44 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CFS7>; Tue, 10 Sep 2002 17:27:44 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: bgp draft review 
Date: Tue, 10 Sep 2002 17:27:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Ironic that the only one that actually gets jitter is not mentioned in the
draft.  That is my point.  Are we only changing urgent things?

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Tuesday, September 10, 2002 4:10 PM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: bgp draft review 


In message
<[e-mail]
ks.com>, "Natale, Jonathan" writes:
> I propose that 
> 
> "jitter should be applied to the
>    timers associated with MinASOriginationInterval, Keepalive, and
>    MinRouteAdvertisementInterval"
> 
> Be changed to:
> 
> "jitter should be applied to the
>    timers associated with ConnectRetry timer"
> 
> This reflects current implementation, right?


Implementation should add some jitter to all of these.  Its not a
extremely urgent matter so the word "should" is just fine.

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 OAA03912 for <[e-mail]>; Tue, 10 Sep 2002 14:35:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9470091293; Tue, 10 Sep 2002 14:34:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BB3691249; Tue, 10 Sep 2002 14:34:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 45B9091294 for <[e-mail]>; Tue, 10 Sep 2002 14:34:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 32BD95DE0E; Tue, 10 Sep 2002 14:34:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id D32EC5DD90 for <[e-mail]>; Tue, 10 Sep 2002 14:34:53 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8AIYpm79030; Tue, 10 Sep 2002 11:34:51 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Tom Petch" <[e-mail]>
Cc: [e-mail]
Subject: Re: Review: Section 2, TCP Port 179 
In-Reply-To: Your message of "Tue, 10 Sep 2002 19:19:02 BST." <017901c258f6$8e223200$0301a8c0@tom3> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 10 Sep 2002 11:34:51 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Tom,

> In much of the FSM, the text is transport neutral, moving TCP
> implementation details to footnotes.  Which I like and think we should
> take on board in this instance.
> 
> Or should abandon and take out the references to TP IND, TP REQ and
> such like.

Pleas keep in mind the following from the spec:

   BGP uses TCP [4] as its transport protocol. 
    ....

                              In the following descriptions the phrase
   "transport protocol connection" can be understood to refer to a TCP
   connection.

So, (a) BGP is *not* transport neutral, and (b) the term "transport
protocol connection" could be used throughout the text interchangeably
with "TCP connection".

Yakov.
  
> 
> Tom Petch, Network Consultant
> [e-mail]
> +(44) 192 575 3018
> -----Original Message-----
> From: Susan Hares <[e-mail]>
> To: [e-mail] <[e-mail]>
> Cc: Natale, Jonathan <[e-mail]>; 'John G. Scudder'
> <[e-mail]>; [e-mail] <[e-mail]>
> Date: 10 September 2002 18:46
> Subject: Re: Review: Section 2, TCP Port 179
> 
> 
> >Could you clarify the question, accept or no by referring to
> >the exact test in the FSM words?
> >
> >Thanks,
> >
> >Sue
> >
> >At 10:12 AM 9/10/2002 -0700, [e-mail] wrote:
> >>Ok, so we can tweak the spec to say "BGP listens on TCP port 179."
> Instead
> >>of "BGP uses TCP port 179 for establishing its connections."
> >>
> >>As for the FSM Idle state accept or no, do you have some proposed
> text,
> >>Jonathan?
> >>
> >>Andrew
> >>
> >>On Tue, Sep 10, 2002 at 08:31:37AM -0400, Natale, Jonathan wrote:
> >> > Delivered-To: [e-mail]
> >> > Delivered-To: [e-mail]
> >> > Delivered-To: [e-mail]
> >> > From: "Natale, Jonathan" <[e-mail]>
> >> > To: "'John G. Scudder'" <[e-mail]>,
> [e-mail]
> >> > Cc: [e-mail]
> >> > Subject: RE: Review: Section 2, TCP Port 179
> >> > Date: Tue, 10 Sep 2002 08:31:37 -0400
> >> > X-Mailer: Internet Mail Service (5.5.2653.19)
> >> > Precedence: bulk
> >> > X-OriginalArrivalTime: 10 Sep 2002 12:33:54.0309 (UTC)
> >> FILETIME=[533D4B50:01C258C6]
> >> >
> >> > I agree.  Let's not make this a TCP tutorial.  Maybe add
> reference to 1 or
> >> > more TCP RFCs???
> >> >
> >> > Also,  If not already done, I think whether or not to accept
> incoming
> >> > connects on 179 while in Idle should be clarified--some/most
> >> implementations
> >> > do, others do not.
> >> >
> >> > -----Original Message-----
> >> > From: John G. Scudder [mailto:[e-mail]]
> >> > Sent: Monday, September 09, 2002 5:10 PM
> >> > To: [e-mail]
> >> > Cc: [e-mail]
> >> > Subject: Re: Review: Section 2, TCP Port 179
> >> >
> >> > At 11:41 AM -0700 9/9/02, [e-mail] wrote:
> >> > >Ok, so we have two options:
> >> > >
> >> > >"BGP listens on TCP port 179."
> >> > >
> >> > >Which leaves the transmit port undefined. Or:
> >> > >
> >> > >"BGP listens on TCP port 179 and transmits from an
> implemetation-dependent
> >> > >port."
> >> > >
> >> > >Thinking of a new operational network engineer reading the spec,
> the
> >> latter
> >> > >seems more clear.  What do you think as an implementor?
> >> >
> >> > Brevity is the soul of wit.  I prefer the former option.  Anyone
> who
> >> > is a little bit familiar with TCP should understand that only the
> >> > listen port needs to be 179.  As Yakov points out, it's a _BGP_
> spec
> >> > and IMO doesn't need to be a TCP tutorial.
> >> >
> >> > (Furthermore, the second statement is technically incorrect
> because
> >> > one of the two BGP speakers in any connection will be sourcing
> its
> >> > traffic from port 179.)
> >> >
> >> > Regards,
> >> >
> >> > --John
> >
> >
> 


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 OAA03905 for <[e-mail]>; Tue, 10 Sep 2002 14:35:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id ABE3891245; Tue, 10 Sep 2002 14:34:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 717FC91295; Tue, 10 Sep 2002 14:34:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A2D5591245 for <[e-mail]>; Tue, 10 Sep 2002 14:32:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8990D5DDD3; Tue, 10 Sep 2002 14:32:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id C415D5DD90 for <[e-mail]>; Tue, 10 Sep 2002 14:32:48 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8AIWlG28650; Tue, 10 Sep 2002 14:32:47 -0400 (EDT) (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 g8AIWiG28643; Tue, 10 Sep 2002 14:32:44 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8AIWic23406; Tue, 10 Sep 2002 14:32:44 -0400 (EDT)
Date: Tue, 10 Sep 2002 14:32:44 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: admin dist/gp spec proposal
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, Sep 10, 2002 at 10:47:46AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Tue, Sep 10, 2002 at 10:47:46AM -0700, Yakov Rekhter wrote:
> > When something makes it into a document, hopefully its painfully
> > obvious why its in there.  When its not painfully obvious, the wisdom
> > that was behind why it ended up in the document must sometimes
> > be rediscovered if its not spelled out plainly.
> 
> Let's remember that a protocol spec needn't always say "why" for 
> everything. 

Please note I didn't say where this wisdom should be documented.
For example, 1772-1774 have some of this wisdom for 1771.

> 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 OAA03755 for <[e-mail]>; Tue, 10 Sep 2002 14:32:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 93EEA91244; Tue, 10 Sep 2002 14:30:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2CCC891245; Tue, 10 Sep 2002 14:30:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 455B291244 for <[e-mail]>; Tue, 10 Sep 2002 14:30:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 198495DE0F; Tue, 10 Sep 2002 14:30:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 5CCAD5DDD3 for <[e-mail]>; Tue, 10 Sep 2002 14:30:23 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8AIUD528530; Tue, 10 Sep 2002 14:30:13 -0400 (EDT) (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 g8AIUAG28522; Tue, 10 Sep 2002 14:30:10 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8AIUAw23398; Tue, 10 Sep 2002 14:30:10 -0400 (EDT)
Date: Tue, 10 Sep 2002 14:30:10 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Proxy: comments on section 9.1.3
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, Sep 10, 2002 at 02:17:11PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Sep 10, 2002 at 02:17:11PM -0400, Curtis Villamizar wrote:
> That is not how route is defined.  It is a single NRLI and path
> attributes.  A route is defined as reaching multiple destinations,
> where destinations means hosts.

[...]

> You are referring to 3.1 which maybe isn't clear enough.
> 
>  3.1 Routes: Advertisement and Storage
> 
>    For the purpose of this protocol, a route is defined as a unit of
>    information that pairs a set of destinations with the attributes of a

Note *set*.

Thus, I expect that a "route" consists of one or more destinations
in the NLRI with path attributes.

-- 
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 OAA03748 for <[e-mail]>; Tue, 10 Sep 2002 14:31:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CDC1E9124A; Tue, 10 Sep 2002 14:31:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94E9D91249; Tue, 10 Sep 2002 14:31:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5A37791245 for <[e-mail]>; Tue, 10 Sep 2002 14:31:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 30E2C5DE0E; Tue, 10 Sep 2002 14:31:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from roam (unknown [193.0.9.125]) by segue.merit.edu (Postfix) with ESMTP id CDB9A5DDD3 for <[e-mail]>; Tue, 10 Sep 2002 14:31:36 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17opnO-000Adp-00; Tue, 10 Sep 2002 11:31:31 -0700
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Yakov Rekhter <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>, [e-mail], [e-mail]
Subject: Re: admin dist/gp spec proposal 
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 10 Sep 2002 11:31:31 -0700
Sender: [e-mail]
Precedence: bulk

>> When something makes it into a document, hopefully its painfully
>> obvious why its in there.  When its not painfully obvious, the wisdom
>> that was behind why it ended up in the document must sometimes
>> be rediscovered if its not spelled out plainly.
> Let's remember that a protocol spec needn't always say "why" for 
> everything. 

glad you two agree.  indeed, when it's really obvious to a new reader,
it need not.

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 OAA03478 for <[e-mail]>; Tue, 10 Sep 2002 14:22:27 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0A42A91243; Tue, 10 Sep 2002 14:22:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C60EF91244; Tue, 10 Sep 2002 14:22:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C83291243 for <[e-mail]>; Tue, 10 Sep 2002 14:22:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3AA105DE0F; Tue, 10 Sep 2002 14:22:06 -0400 (EDT)
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 E467E5DD90 for <[e-mail]>; Tue, 10 Sep 2002 14:22:05 -0400 (EDT)
Received: from tom3 (userbz54.uk.uudial.com [62.188.150.23]) by shockwave.systems.pipex.net (Postfix) with SMTP id C22EF16000CCD; Tue, 10 Sep 2002 19:22:01 +0100 (BST)
Message-ID: <017901c258f6$8e223200$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: <[e-mail]>, "Susan Hares" <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, "'John G. Scudder'" <[e-mail]>, <[e-mail]>
Subject: Re: Review: Section 2, TCP Port 179
Date: Tue, 10 Sep 2002 19:19:02 +0100
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

And ....

In much of the FSM, the text is transport neutral, moving TCP
implementation details to footnotes.  Which I like and think we should
take on board in this instance.

Or should abandon and take out the references to TP IND, TP REQ and
such like.


Tom Petch, Network Consultant
[e-mail]
+(44) 192 575 3018
-----Original Message-----
From: Susan Hares <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: Natale, Jonathan <[e-mail]>; 'John G. Scudder'
<[e-mail]>; [e-mail] <[e-mail]>
Date: 10 September 2002 18:46
Subject: Re: Review: Section 2, TCP Port 179


>Could you clarify the question, accept or no by referring to
>the exact test in the FSM words?
>
>Thanks,
>
>Sue
>
>At 10:12 AM 9/10/2002 -0700, [e-mail] wrote:
>>Ok, so we can tweak the spec to say "BGP listens on TCP port 179."
Instead
>>of "BGP uses TCP port 179 for establishing its connections."
>>
>>As for the FSM Idle state accept or no, do you have some proposed
text,
>>Jonathan?
>>
>>Andrew
>>
>>On Tue, Sep 10, 2002 at 08:31:37AM -0400, Natale, Jonathan wrote:
>> > Delivered-To: [e-mail]
>> > Delivered-To: [e-mail]
>> > Delivered-To: [e-mail]
>> > From: "Natale, Jonathan" <[e-mail]>
>> > To: "'John G. Scudder'" <[e-mail]>,
[e-mail]
>> > Cc: [e-mail]
>> > Subject: RE: Review: Section 2, TCP Port 179
>> > Date: Tue, 10 Sep 2002 08:31:37 -0400
>> > X-Mailer: Internet Mail Service (5.5.2653.19)
>> > Precedence: bulk
>> > X-OriginalArrivalTime: 10 Sep 2002 12:33:54.0309 (UTC)
>> FILETIME=[533D4B50:01C258C6]
>> >
>> > I agree.  Let's not make this a TCP tutorial.  Maybe add
reference to 1 or
>> > more TCP RFCs???
>> >
>> > Also,  If not already done, I think whether or not to accept
incoming
>> > connects on 179 while in Idle should be clarified--some/most
>> implementations
>> > do, others do not.
>> >
>> > -----Original Message-----
>> > From: John G. Scudder [mailto:[e-mail]]
>> > Sent: Monday, September 09, 2002 5:10 PM
>> > To: [e-mail]
>> > Cc: [e-mail]
>> > Subject: Re: Review: Section 2, TCP Port 179
>> >
>> > At 11:41 AM -0700 9/9/02, [e-mail] wrote:
>> > >Ok, so we have two options:
>> > >
>> > >"BGP listens on TCP port 179."
>> > >
>> > >Which leaves the transmit port undefined. Or:
>> > >
>> > >"BGP listens on TCP port 179 and transmits from an
implemetation-dependent
>> > >port."
>> > >
>> > >Thinking of a new operational network engineer reading the spec,
the
>> latter
>> > >seems more clear.  What do you think as an implementor?
>> >
>> > Brevity is the soul of wit.  I prefer the former option.  Anyone
who
>> > is a little bit familiar with TCP should understand that only the
>> > listen port needs to be 179.  As Yakov points out, it's a _BGP_
spec
>> > and IMO doesn't need to be a TCP tutorial.
>> >
>> > (Furthermore, the second statement is technically incorrect
because
>> > one of the two BGP speakers in any connection will be sourcing
its
>> > traffic from port 179.)
>> >
>> > 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 NAA02650 for <[e-mail]>; Tue, 10 Sep 2002 13:57:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 05F1991242; Tue, 10 Sep 2002 13:57:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDB5C91243; Tue, 10 Sep 2002 13:57:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D04191242 for <[e-mail]>; Tue, 10 Sep 2002 13:57:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7B7915DE0E; Tue, 10 Sep 2002 13:57:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 1EB0A5DD90 for <[e-mail]>; Tue, 10 Sep 2002 13:57:28 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8AHv3m74901; Tue, 10 Sep 2002 10:57:03 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'John G. Scudder'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Review: Section 2, TCP Port 179 
In-Reply-To: Your message of "Tue, 10 Sep 2002 08:31:37 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 10 Sep 2002 10:57:03 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> I agree.  Let's not make this a TCP tutorial.  Maybe add reference to 1 or
> more TCP RFCs???
> 

It is already in the spec (see the Reference section):

   [4] Postel, J., "Transmission Control Protocol - DARPA Internet
   Program Protocol Specification", RFC793, September 1981.

Yakov.

> Also,  If not already done, I think whether or not to accept incoming
> connects on 179 while in Idle should be clarified--some/most implementations
> do, others do not.
> 
> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]] 
> Sent: Monday, September 09, 2002 5:10 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Review: Section 2, TCP Port 179
> 
> At 11:41 AM -0700 9/9/02, [e-mail] wrote:
> >Ok, so we have two options:
> >
> >"BGP listens on TCP port 179."
> >
> >Which leaves the transmit port undefined. Or:
> >
> >"BGP listens on TCP port 179 and transmits from an implemetation-dependent
> >port."
> >
> >Thinking of a new operational network engineer reading the spec, the latter
> >seems more clear.  What do you think as an implementor?
> 
> Brevity is the soul of wit.  I prefer the former option.  Anyone who 
> is a little bit familiar with TCP should understand that only the 
> listen port needs to be 179.  As Yakov points out, it's a _BGP_ spec 
> and IMO doesn't need to be a TCP tutorial.
> 
> (Furthermore, the second statement is technically incorrect because 
> one of the two BGP speakers in any connection will be sourcing its 
> traffic from port 179.)
> 
> 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 NAA02416 for <[e-mail]>; Tue, 10 Sep 2002 13:50:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 90DF891241; Tue, 10 Sep 2002 13:49:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60B469123F; Tue, 10 Sep 2002 13:49:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7C2A29133D for <[e-mail]>; Tue, 10 Sep 2002 13:47:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 53D845DE0E; Tue, 10 Sep 2002 13:47:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id ECD145DD90 for <[e-mail]>; Tue, 10 Sep 2002 13:47:55 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8AHlkm73783; Tue, 10 Sep 2002 10:47:46 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: admin dist/gp spec proposal 
In-Reply-To: Your message of "Tue, 10 Sep 2002 10:19:55 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 10 Sep 2002 10:47:46 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> Not specifically picking on you Curtis, but having had essentially
> the same conversation three times yesterday:
> 
> On Mon, Sep 09, 2002 at 06:27:34PM -0400, Curtis Villamizar wrote:
> > Some of us
> > have been looking at BGP4 for over 8 years and do try to remain
> > patient with newbies.  When the newbies are clueless, return to
> > discussions that occurred and were resolved years ago, and vigorously
> > make incorrect assertions it makes it harder to maintain patience.
> 
> When something makes it into a document, hopefully its painfully
> obvious why its in there.  When its not painfully obvious, the wisdom
> that was behind why it ended up in the document must sometimes
> be rediscovered if its not spelled out plainly.

Let's remember that a protocol spec needn't always say "why" for 
everything. 

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 NAA02271 for <[e-mail]>; Tue, 10 Sep 2002 13:46:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6239B9133E; Tue, 10 Sep 2002 13:46:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB1D291350; Tue, 10 Sep 2002 13:46:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BC0789133E for <[e-mail]>; Tue, 10 Sep 2002 13:45:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A8ECC5DE0E; Tue, 10 Sep 2002 13:45:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id E34F25DDC2 for <[e-mail]>; Tue, 10 Sep 2002 13:45:47 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8AHjki26994; Tue, 10 Sep 2002 13:45:46 -0400 (EDT) (envelope-from [e-mail])
Received: from SKH.nexthop.com ([65.241.132.110]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g8AHjhG26987; Tue, 10 Sep 2002 13:45:43 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Tue, 10 Sep 2002 13:45:22 -0400
To: [e-mail]
From: Susan Hares <[e-mail]>
Subject: Re: Review: Section 2, TCP Port 179
Cc: "Natale, Jonathan" <[e-mail]>, "'John G. Scudder'" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Could you clarify the question, accept or no by referring to
the exact test in the FSM words?

Thanks,

Sue

At 10:12 AM 9/10/2002 -0700, [e-mail] wrote:
>Ok, so we can tweak the spec to say "BGP listens on TCP port 179." Instead
>of "BGP uses TCP port 179 for establishing its connections."
>
>As for the FSM Idle state accept or no, do you have some proposed text,
>Jonathan?
>
>Andrew
>
>On Tue, Sep 10, 2002 at 08:31:37AM -0400, Natale, Jonathan wrote:
> > Delivered-To: [e-mail]
> > Delivered-To: [e-mail]
> > Delivered-To: [e-mail]
> > From: "Natale, Jonathan" <[e-mail]>
> > To: "'John G. Scudder'" <[e-mail]>, [e-mail]
> > Cc: [e-mail]
> > Subject: RE: Review: Section 2, TCP Port 179
> > Date: Tue, 10 Sep 2002 08:31:37 -0400
> > X-Mailer: Internet Mail Service (5.5.2653.19)
> > Precedence: bulk
> > X-OriginalArrivalTime: 10 Sep 2002 12:33:54.0309 (UTC) 
> FILETIME=[533D4B50:01C258C6]
> >
> > I agree.  Let's not make this a TCP tutorial.  Maybe add reference to 1 or
> > more TCP RFCs???
> >
> > Also,  If not already done, I think whether or not to accept incoming
> > connects on 179 while in Idle should be clarified--some/most 
> implementations
> > do, others do not.
> >
> > -----Original Message-----
> > From: John G. Scudder [mailto:[e-mail]]
> > Sent: Monday, September 09, 2002 5:10 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: Review: Section 2, TCP Port 179
> >
> > At 11:41 AM -0700 9/9/02, [e-mail] wrote:
> > >Ok, so we have two options:
> > >
> > >"BGP listens on TCP port 179."
> > >
> > >Which leaves the transmit port undefined. Or:
> > >
> > >"BGP listens on TCP port 179 and transmits from an implemetation-dependent
> > >port."
> > >
> > >Thinking of a new operational network engineer reading the spec, the 
> latter
> > >seems more clear.  What do you think as an implementor?
> >
> > Brevity is the soul of wit.  I prefer the former option.  Anyone who
> > is a little bit familiar with TCP should understand that only the
> > listen port needs to be 179.  As Yakov points out, it's a _BGP_ spec
> > and IMO doesn't need to be a TCP tutorial.
> >
> > (Furthermore, the second statement is technically incorrect because
> > one of the two BGP speakers in any connection will be sourcing its
> > traffic from port 179.)
> >
> > 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 NAA02173 for <[e-mail]>; Tue, 10 Sep 2002 13:43:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C6E589123E; Tue, 10 Sep 2002 13:43:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94D5A9133D; Tue, 10 Sep 2002 13:43:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A4F1C9123E for <[e-mail]>; Tue, 10 Sep 2002 13:43:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8DCD55DDC2; Tue, 10 Sep 2002 13:43:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 18AF55DD90 for <[e-mail]>; Tue, 10 Sep 2002 13:43:13 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA25623; Tue, 10 Sep 2002 13:43:11 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA06962; Tue, 10 Sep 2002 13:43:11 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QRN3F>; Tue, 10 Sep 2002 13:43:11 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Russ White'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal
Date: Tue, 10 Sep 2002 13:43:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Agreed


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Tuesday, September 10, 2002 1:21 PM
> To: Abarbanel, Benjamin
> Cc: 'Russ White'; '[e-mail]'; 'Yakov Rekhter'; Natale,
> Jonathan; [e-mail]
> Subject: Re: admin dist/gp spec proposal
> 
> 
> > For me its the NMS point of view, where its the address of 
> a node which
> > is independent of a given interface and protocol and allows 
> the NMS system
> > the ability to keep track of routing information in that 
> node as well as
> > assist in keeping track which node/router owns which 
> routes. Interworking
> > and networking/reachability capabilities are biproducts of 
> this feature.
> > 
> > It seems silly to me to have one Router-ID value for BGP, 
> another value
> > for Router-ID for OSPF, a third value for ISIS and so on. 
> It makes the
> > number meaningless when view from the big cloud in the sky 
> called NMS.
> 
> Not necessaraly a problem from an NMS standpoint, a bit of a hassle to
> list multiple ID's for the same router, but not impossible.  Plus,
> most operators already have one ID for the router, before any MUSTs
> have been specified.
> 
> More importantly, let's move this to a BCP document.  Yakov has a good
> point, referencing this isn't absolutely necessary to create good,
> interoperable Base BGP implementations.  We can stick this in another
> document, and things will be a lot clearer, and we can make 
> more progress
> on getting the Base spec out.
> 
> 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 NAA01669 for <[e-mail]>; Tue, 10 Sep 2002 13:28:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A858C91337; Tue, 10 Sep 2002 13:27:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7BB3F9133D; Tue, 10 Sep 2002 13:27:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 26FAD91337 for <[e-mail]>; Tue, 10 Sep 2002 13:27:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EB3B05DE21; Tue, 10 Sep 2002 13:27:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 92E2D5DE1C for <[e-mail]>; Tue, 10 Sep 2002 13:27:56 -0400 (EDT)
Received: from redback.com (yoo-hoo.redback.com [155.53.12.43]) by prattle.redback.com (Postfix) with ESMTP id 0F1BA1531CA; Tue, 10 Sep 2002 10:27:55 -0700 (PDT)
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'John G. Scudder'" <[e-mail]>, [e-mail]
Subject: Re: Router ID 
In-reply-to: Mail from "Abarbanel, Benjamin" <[e-mail]>  dated Tue, 10 Sep 2002 12:41:36 EDT <[e-mail]> 
Date: Tue, 10 Sep 2002 10:27:54 -0700
From: Naiming Shen <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

I hope this will be the LAST. I think you got a point that all the
process identifier "usually" should be the same(except for isis, which
has a 6 byte id, but it has a way to make a 4 byte bogus one), and
there is no reason not to make them the same. but there are cases
where the IDs should not be the same. If you have multiple OSPF processes
running on the router, it's an advantage to make them diff ids. when
you want to setup lsp tunnels, you know exactly which OSPF instance
the rsvp is interacted with. so from protocol point of view, there
should be no requirement on this issue.

 ] Hopefully in closing this thread. 
 ] 
 ] I retract what I said about a must for BGP Identifier being routable.
 ] I should have said "should" be made routable. My thinking is based on
 ] using the loopback address for the router-ID/BGP ID, making it interface
 ] independent and thus provide greater reachability. Also, from NMS point of
 ] view make the router-ID more reachable via a loopback address. So on and so
 ] on ...
 ] 
 ] Thank you for this informative discussion on BGP-Identifiers and router-ID.
 ] 
 ] Ben
 ] 
 ] > -----Original Message-----
 ] > From: John G. Scudder [mailto:[e-mail]]
 ] > Sent: Tuesday, September 10, 2002 12:10 PM
 ] > To: Abarbanel, Benjamin
 ] > Cc: [e-mail]
 ] > Subject: RE: Router ID
 ] > 
 ] > 
 ] > At 11:58 AM -0400 9/10/02, Abarbanel, Benjamin wrote:
 ] > >This is taken out of RFC1771 and current BGP draft 17.
 ] > >
 ] > >"BGP Identifier:
 ] > >
 ] > >          This 4-octet unsigned integer indicates the BGP 
 ] > Identifier of
 ] > >          the sender. A given BGP speaker sets the value of its BGP
 ] > >          Identifier to an IP address assigned to that BGP 
 ] > speaker.  "
 ] > >
 ] > >Most IP addresses I am familiar with are routable.
 ] > 
 ] > Well, sure.  That is quite different from your assertion that the 
 ] > "BGP Identifier must be routable for the protocol to work," however. 
 ] > The fact is, that statement is incorrect in practice and even in 
 ] > theory (nowhere does the spec enforce or even strictly speaking 
 ] > mandate the routability of the identifier).
 ] > 
 ] > >If not, the description
 ] > >should not read "IP address", but only "4-octet unsigned integer".
 ] > 
 ] > Just so.  In fact Enke pointed this out several days ago:
 ] > 
 ] > At 11:49 PM -0700 9/6/02, Enke Chen wrote:
 ] > >Indeed, and please take note of the IDR WG draft on the BGP 
 ] > Identifier:
 ] > >
 ] > >      draft-ietf-idr-bgp-identifier-00.txt
 ] > 
 ] >  From the abstract:
 ] > 
 ] >     this document relaxes the definition of the
 ] >     BGP Identifier to be a 4-octet unsigned, non-zero integer
 ] > 
 ] > At 11:59 AM -0400 9/10/02, Abarbanel, Benjamin wrote:
 ] > >   Can we end this thread, it does not look like we are getting
 > >any closure on this topic.
 ] > 
 ] > An excellent suggestion.
 ] > 
 ] > --John
 ] > 

- Naiming


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA01596 for <[e-mail]>; Tue, 10 Sep 2002 13:25:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 63DC59133B; Tue, 10 Sep 2002 13:24:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B06B91356; Tue, 10 Sep 2002 13:24:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 08A659133B for <[e-mail]>; Tue, 10 Sep 2002 13:24:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E607B5DE1C; Tue, 10 Sep 2002 13:24:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 59C4A5DE18 for <[e-mail]>; Tue, 10 Sep 2002 13:24:40 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id KAA07402; Tue, 10 Sep 2002 10:21:12 -0700 (PDT)
Date: Tue, 10 Sep 2002 10:21:12 -0700
From: [e-mail]
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Russ White'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: Re: admin dist/gp spec proposal
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, Sep 10, 2002 at 11:34:05AM -0400
Sender: [e-mail]
Precedence: bulk

> For me its the NMS point of view, where its the address of a node which
> is independent of a given interface and protocol and allows the NMS system
> the ability to keep track of routing information in that node as well as
> assist in keeping track which node/router owns which routes. Interworking
> and networking/reachability capabilities are biproducts of this feature.
> 
> It seems silly to me to have one Router-ID value for BGP, another value
> for Router-ID for OSPF, a third value for ISIS and so on. It makes the
> number meaningless when view from the big cloud in the sky called NMS.

Not necessaraly a problem from an NMS standpoint, a bit of a hassle to
list multiple ID's for the same router, but not impossible.  Plus,
most operators already have one ID for the router, before any MUSTs
have been specified.

More importantly, let's move this to a BCP document.  Yakov has a good
point, referencing this isn't absolutely necessary to create good,
interoperable Base BGP implementations.  We can stick this in another
document, and things will be a lot clearer, and we can make more progress
on getting the Base spec out.

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 NAA01276 for <[e-mail]>; Tue, 10 Sep 2002 13:16:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EA17E91332; Tue, 10 Sep 2002 13:16:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9189E91335; Tue, 10 Sep 2002 13:16:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BB97B91332 for <[e-mail]>; Tue, 10 Sep 2002 13:15:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9B8435DE0E; Tue, 10 Sep 2002 13:15:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 3E6EE5DDC2 for <[e-mail]>; Tue, 10 Sep 2002 13:15:59 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id KAA07288; Tue, 10 Sep 2002 10:12:53 -0700 (PDT)
Date: Tue, 10 Sep 2002 10:12:53 -0700
From: [e-mail]
To: "Natale, Jonathan" <[e-mail]>
Cc: "'John G. Scudder'" <[e-mail]>, [e-mail]
Subject: Re: Review: Section 2, TCP Port 179
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, Sep 10, 2002 at 08:31:37AM -0400
Sender: [e-mail]
Precedence: bulk

Ok, so we can tweak the spec to say "BGP listens on TCP port 179." Instead
of "BGP uses TCP port 179 for establishing its connections."  

As for the FSM Idle state accept or no, do you have some proposed text, 
Jonathan?

Andrew

On Tue, Sep 10, 2002 at 08:31:37AM -0400, Natale, Jonathan wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> From: "Natale, Jonathan" <[e-mail]>
> To: "'John G. Scudder'" <[e-mail]>, [e-mail]
> Cc: [e-mail]
> Subject: RE: Review: Section 2, TCP Port 179
> Date: Tue, 10 Sep 2002 08:31:37 -0400
> X-Mailer: Internet Mail Service (5.5.2653.19)
> Precedence: bulk
> X-OriginalArrivalTime: 10 Sep 2002 12:33:54.0309 (UTC) FILETIME=[533D4B50:01C258C6]
> 
> I agree.  Let's not make this a TCP tutorial.  Maybe add reference to 1 or
> more TCP RFCs???
> 
> Also,  If not already done, I think whether or not to accept incoming
> connects on 179 while in Idle should be clarified--some/most implementations
> do, others do not.
> 
> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]] 
> Sent: Monday, September 09, 2002 5:10 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Review: Section 2, TCP Port 179
> 
> At 11:41 AM -0700 9/9/02, [e-mail] wrote:
> >Ok, so we have two options:
> >
> >"BGP listens on TCP port 179."
> >
> >Which leaves the transmit port undefined. Or:
> >
> >"BGP listens on TCP port 179 and transmits from an implemetation-dependent
> >port."
> >
> >Thinking of a new operational network engineer reading the spec, the latter
> >seems more clear.  What do you think as an implementor?
> 
> Brevity is the soul of wit.  I prefer the former option.  Anyone who 
> is a little bit familiar with TCP should understand that only the 
> listen port needs to be 179.  As Yakov points out, it's a _BGP_ spec 
> and IMO doesn't need to be a TCP tutorial.
> 
> (Furthermore, the second statement is technically incorrect because 
> one of the two BGP speakers in any connection will be sourcing its 
> traffic from port 179.)
> 
> 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 NAA01009 for <[e-mail]>; Tue, 10 Sep 2002 13:09:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 20DB691237; Tue, 10 Sep 2002 13:09:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0E429123D; Tue, 10 Sep 2002 13:09:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A3DD891237 for <[e-mail]>; Tue, 10 Sep 2002 13:09:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 929555DE12; Tue, 10 Sep 2002 13:09:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 4C0B85DE0E for <[e-mail]>; Tue, 10 Sep 2002 13:09:18 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1C13V>; Tue, 10 Sep 2002 13:09:17 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: bgp draft comments 
Date: Tue, 10 Sep 2002 13:09:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

1)
IOS does not allow a /32 to kill an interface, other implementations do.  If
you do allow it then it opens up an easy way to kill a router (assuming the
router does not filter it).

2)
I was not referring to overlapping routes.  Prior to the new feature below,
it was not possible to advertise 1.1/16 if you did not have 1.1/16 in the
routing table but did have 1/8 in the routing table.


-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Monday, September 09, 2002 11:41 PM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: bgp draft comments 


In message
<[e-mail]
ks.com>, "Natale, Jonathan" writes:
> 
> Maybe disallowing the installation of more specific routes of a direcly
> attached networks.  This is a mis-config, but the more graceful way of
> handling it seems to be to ignore the route, or only re-advertise it
(don't
> install it). This seems like a job for the INFORM.

In practice this is done (rarely).  For example, any BSD system allows
a /32 to override the subnet of a local interface.

> Also, related to the above, what about allowing the
> advertisement/origination of more specific routes of a locally reachable
> route?  This seems to be legitimate, but is not allowed explicitly in the
> draft.  Also it is referred to at
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122
> t/122t11/ft11bpri.htm so there seems to be a need/current implementation. 

Where is this prohibited?  Overlapping routes are used all the time.

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 MAA00138 for <[e-mail]>; Tue, 10 Sep 2002 12:44:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0D60D91331; Tue, 10 Sep 2002 12:41:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0CCA91332; Tue, 10 Sep 2002 12:41:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 03EF091331 for <[e-mail]>; Tue, 10 Sep 2002 12:41:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E60015DDC5; Tue, 10 Sep 2002 12:41:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 711ED5DDC2 for <[e-mail]>; Tue, 10 Sep 2002 12:41:38 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA22076; Tue, 10 Sep 2002 12:41:36 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA27362; Tue, 10 Sep 2002 12:41:37 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QRLK1>; Tue, 10 Sep 2002 12:41:37 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'John G. Scudder'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Router ID
Date: Tue, 10 Sep 2002 12:41:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hopefully in closing this thread. 

I retract what I said about a must for BGP Identifier being routable.
I should have said "should" be made routable. My thinking is based on
using the loopback address for the router-ID/BGP ID, making it interface
independent and thus provide greater reachability. Also, from NMS point of
view make the router-ID more reachable via a loopback address. So on and so
on ...

Thank you for this informative discussion on BGP-Identifiers and router-ID.

Ben

> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]]
> Sent: Tuesday, September 10, 2002 12:10 PM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: RE: Router ID
> 
> 
> At 11:58 AM -0400 9/10/02, Abarbanel, Benjamin wrote:
> >This is taken out of RFC1771 and current BGP draft 17.
> >
> >"BGP Identifier:
> >
> >          This 4-octet unsigned integer indicates the BGP 
> Identifier of
> >          the sender. A given BGP speaker sets the value of its BGP
> >          Identifier to an IP address assigned to that BGP 
> speaker.  "
> >
> >Most IP addresses I am familiar with are routable.
> 
> Well, sure.  That is quite different from your assertion that the 
> "BGP Identifier must be routable for the protocol to work," however. 
> The fact is, that statement is incorrect in practice and even in 
> theory (nowhere does the spec enforce or even strictly speaking 
> mandate the routability of the identifier).
> 
> >If not, the description
> >should not read "IP address", but only "4-octet unsigned integer".
> 
> Just so.  In fact Enke pointed this out several days ago:
> 
> At 11:49 PM -0700 9/6/02, Enke Chen wrote:
> >Indeed, and please take note of the IDR WG draft on the BGP 
> Identifier:
> >
> >      draft-ietf-idr-bgp-identifier-00.txt
> 
>  From the abstract:
> 
>     this document relaxes the definition of the
>     BGP Identifier to be a 4-octet unsigned, non-zero integer
> 
> At 11:59 AM -0400 9/10/02, Abarbanel, Benjamin wrote:
> >   Can we end this thread, it does not look like we are getting
> >any closure on this topic.
> 
> An excellent suggestion.
> 
> --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 MAA29562 for <[e-mail]>; Tue, 10 Sep 2002 12:25:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8F45491314; Tue, 10 Sep 2002 12:25:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 563049132C; Tue, 10 Sep 2002 12:25:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1DE6691314 for <[e-mail]>; Tue, 10 Sep 2002 12:25:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 078275DE0E; Tue, 10 Sep 2002 12:25:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id C69945DDC2 for <[e-mail]>; Tue, 10 Sep 2002 12:25:25 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17onpM-0000Fc-00; Tue, 10 Sep 2002 09:25:25 -0700
Date: Tue, 10 Sep 2002 18:23:42 +0200
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Working Group last call
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Yakov,

  I'd like to ask the WG chairs to extend the comment period
  for at least another two weeks--as I indicated in one of my
  messages earlier, I'm hearing that people are in deadlines
  and ask for more time to review.

  Request to the reviewers: folks, please do engage in the
  review of the FSM text, it is a very important part of
  the spec.

  Thank you.
  
-- 
Alex

Monday, September 09, 2002, 7:18:43 PM, Yakov Rekhter wrote:
> Folks,

> Please note that the comment period on the BGP FSM text (the one
> proposed by Sue in her e-mail to this list on 8/26) ends today.

> 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 MAA29304 for <[e-mail]>; Tue, 10 Sep 2002 12:18:25 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 44EA791339; Tue, 10 Sep 2002 12:16:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 798DE9133B; Tue, 10 Sep 2002 12:16:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5057691339 for <[e-mail]>; Tue, 10 Sep 2002 12:16:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3D7065DE0D; Tue, 10 Sep 2002 12:16:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 11AC85DDC2 for <[e-mail]>; Tue, 10 Sep 2002 12:16:38 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17ongp-000PmR-00; Tue, 10 Sep 2002 09:16:36 -0700
Date: Tue, 10 Sep 2002 18:14:57 +0200
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP spec and IDR WG charter
In-Reply-To: <[e-mail]>
References: <000401c25820$97519860$0301a8c0@tom3> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Jeff, Tom-

> Its always best to just republish them - or excerpts from the archives.

Correct. We better err on this side than on the side
of people not feeling comfortable of speaking up.

> In general, unless I see (in the case of the base draft) Yakov say
> "I'll add this in", I assume it didn't get in.
> And even then I check to see if it did. :-)

I'll send a message with my proposal on this.

Alex


> On Mon, Sep 09, 2002 at 05:42:41PM +0100, Tom Petch wrote:
>> I have a very practical problem that some of the issues coming up now
>> did come up nine months ago and did reach a rough consensus.  Any
>> chance of a draft with those in?  It would make moving forward much
>> easier.
>> 
>> 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 MAA29123 for <[e-mail]>; Tue, 10 Sep 2002 12:15:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2E6C991329; Tue, 10 Sep 2002 12:12:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D76EC9132B; Tue, 10 Sep 2002 12:12:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6707E91329 for <[e-mail]>; Tue, 10 Sep 2002 12:12:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 55B0D5DE14; Tue, 10 Sep 2002 12:12:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 2A3B95DE0D for <[e-mail]>; Tue, 10 Sep 2002 12:12:45 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17ond4-000PYF-00; Tue, 10 Sep 2002 09:12:43 -0700
Date: Tue, 10 Sep 2002 18:11:01 +0200
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: Bill Fenner <[e-mail]>, [e-mail]
Subject: Re: BGP spec and IDR WG charter
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Yakov,

> When should we expect you to send the message explaining the details
> on how the team will do its work ?

Below I include the message that I sent on Sep 5th regarding
this part. To summarize, at this stage I asked the reviewers
to post their comments to the WG list or to us personally
so we can proxy-fwd them to the list.

Alex


This is a forwarded message
From: Alex Zinin <[e-mail]>
To: [e-mail]
Cc: 
Date: Thursday, September 05, 2002, 12:40:23 AM
Subject: BGP spec and IDR WG charter

===8<==============Original message text===============
Folks-

Regarding the review team mentioned below--

Friday, August 23, 2002, 1:11:10 AM, Bill Fenner wrote:
...
> [**] In further support of the goal of having a quality specification
> that reflects current reality, the ADs have been working on assembling
> a team of reviewers that consists primarily of protocol implementors,
> who have committed their time to examine the spec.  We will be
> sending another message to this list explaining the details of how
> this team will do its work.

--today I have pinged about a dozen people who promised to commit
some time to review the spec, and asked them to help with the FSM
text review posted by Sue. Hopefully we will see more activity
on the list in the following two weeks and later when the complete
spec goes for the LC.

For people who have not been explicitly pinged and who feel capable of
contributing to the protocol specification--please consider this
message as the invitation from the ADs to review the spec and provide
your commets. Please send your comments to the list, or (if you do
not feel comfortable speaking up on the list for some reason), send
them to the chairs and/or the ADs instead, we'll be able to function
as proxy if valid issues are raised.

A small request to the reviewers--when looking at the spec, please
evaluate it from the perspective of being sufficient to implement the
protocol if the reader is not familiar with the protocol, whether it
really reflects what your code is doing or what you know other
implementations do, whether one would need to reverse engineer things
to write an implementation, etc.

Cheers,
Alex



===8<===========End of original message text===========




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA28965 for <[e-mail]>; Tue, 10 Sep 2002 12:10:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5F78891325; Tue, 10 Sep 2002 12:09:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E84C91326; Tue, 10 Sep 2002 12:09:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D858891325 for <[e-mail]>; Tue, 10 Sep 2002 12:09:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C7A6D5DE0D; Tue, 10 Sep 2002 12:09:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id 11DFE5DDC2 for <[e-mail]>; Tue, 10 Sep 2002 12:09:56 -0400 (EDT)
Received: from [192.168.42.10] (dhcp-171-69-182-131.cisco.com [171.69.182.131]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id MAA10362; Tue, 10 Sep 2002 12:09:54 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a1ab9a3c7ad15ee@[192.168.42.10]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 10 Sep 2002 12:09:41 -0400
To: "Abarbanel, Benjamin" <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: RE: Router ID
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 11:58 AM -0400 9/10/02, Abarbanel, Benjamin wrote:
>This is taken out of RFC1771 and current BGP draft 17.
>
>"BGP Identifier:
>
>          This 4-octet unsigned integer indicates the BGP Identifier of
>          the sender. A given BGP speaker sets the value of its BGP
>          Identifier to an IP address assigned to that BGP speaker.  "
>
>Most IP addresses I am familiar with are routable.

Well, sure.  That is quite different from your assertion that the 
"BGP Identifier must be routable for the protocol to work," however. 
The fact is, that statement is incorrect in practice and even in 
theory (nowhere does the spec enforce or even strictly speaking 
mandate the routability of the identifier).

>If not, the description
>should not read "IP address", but only "4-octet unsigned integer".

Just so.  In fact Enke pointed this out several days ago:

At 11:49 PM -0700 9/6/02, Enke Chen wrote:
>Indeed, and please take note of the IDR WG draft on the BGP Identifier:
>
>      draft-ietf-idr-bgp-identifier-00.txt

 From the abstract:

    this document relaxes the definition of the
    BGP Identifier to be a 4-octet unsigned, non-zero integer

At 11:59 AM -0400 9/10/02, Abarbanel, Benjamin wrote:
>   Can we end this thread, it does not look like we are getting
>any closure on this topic.

An excellent suggestion.

--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 MAA28737 for <[e-mail]>; Tue, 10 Sep 2002 12:02:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5E34191322; Tue, 10 Sep 2002 11:59:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2760291325; Tue, 10 Sep 2002 11:59:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 97E4591322 for <[e-mail]>; Tue, 10 Sep 2002 11:59:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 74A195DDC5; Tue, 10 Sep 2002 11:59:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id EE3225DDC2 for <[e-mail]>; Tue, 10 Sep 2002 11:59:50 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA19264; Tue, 10 Sep 2002 11:59:49 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18805; Tue, 10 Sep 2002 11:59:49 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QRJBW>; Tue, 10 Sep 2002 11:59:49 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>, "'John G. Scudder'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Router ID
Date: Tue, 10 Sep 2002 11:59:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

To All:
  Can we end this thread, it does not look like we are getting
any closure on this topic.

Thank You,
Ben

> -----Original Message-----
> From: Abarbanel, Benjamin 
> Sent: Tuesday, September 10, 2002 11:59 AM
> To: 'John G. Scudder'; Abarbanel, Benjamin
> Cc: '[e-mail]'
> Subject: RE: Router ID
> 
> 
>  
> This is taken out of RFC1771 and current BGP draft 17.
> 
> "BGP Identifier:
> 
>          This 4-octet unsigned integer indicates the BGP Identifier of
>          the sender. A given BGP speaker sets the value of its BGP
>          Identifier to an IP address assigned to that BGP speaker.  "
> 
> Most IP addresses I am familiar with are routable. If not, 
> the description
> should not read "IP address", but only "4-octet unsigned integer".
> 
> Ben
> 
> > -----Original Message-----
> > From: John G. Scudder [mailto:[e-mail]]
> > Sent: Tuesday, September 10, 2002 11:41 AM
> > To: Abarbanel, Benjamin
> > Cc: '[e-mail]'
> > Subject: Re: Router ID
> > 
> > 
> > At 10:28 AM -0400 9/10/02, Abarbanel, Benjamin wrote:
> > >  Clearly, BGP Identifier must be routable for the protocol to
> > >  work and the session to be Established.
> > 
> > This is incorrect for several implementations with which I am 
> > familiar.
> > 
> > --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 LAA28582 for <[e-mail]>; Tue, 10 Sep 2002 11:59:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EB0F69131E; Tue, 10 Sep 2002 11:59:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B235391321; Tue, 10 Sep 2002 11:59:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C302A9131E for <[e-mail]>; Tue, 10 Sep 2002 11:59:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A5DEC5DE0E; Tue, 10 Sep 2002 11:59:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 2E8825DDC5 for <[e-mail]>; Tue, 10 Sep 2002 11:59:02 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA19232; Tue, 10 Sep 2002 11:58:59 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18713; Tue, 10 Sep 2002 11:59:00 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QRJBD>; Tue, 10 Sep 2002 11:59:00 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'John G. Scudder'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Router ID
Date: Tue, 10 Sep 2002 11:58:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

 
This is taken out of RFC1771 and current BGP draft 17.

"BGP Identifier:

         This 4-octet unsigned integer indicates the BGP Identifier of
         the sender. A given BGP speaker sets the value of its BGP
         Identifier to an IP address assigned to that BGP speaker.  "

Most IP addresses I am familiar with are routable. If not, the description
should not read "IP address", but only "4-octet unsigned integer".

Ben

> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]]
> Sent: Tuesday, September 10, 2002 11:41 AM
> To: Abarbanel, Benjamin
> Cc: '[e-mail]'
> Subject: Re: Router ID
> 
> 
> At 10:28 AM -0400 9/10/02, Abarbanel, Benjamin wrote:
> >  Clearly, BGP Identifier must be routable for the protocol to
> >  work and the session to be Established.
> 
> This is incorrect for several implementations with which I am 
> familiar.
> 
> --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 LAA28040 for <[e-mail]>; Tue, 10 Sep 2002 11:42:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9C4789131C; Tue, 10 Sep 2002 11:41:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B9269131E; Tue, 10 Sep 2002 11:41:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6643A9131C for <[e-mail]>; Tue, 10 Sep 2002 11:41:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 735E15DE0E; Tue, 10 Sep 2002 11:41:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id BA6A25DDF2 for <[e-mail]>; Tue, 10 Sep 2002 11:41:36 -0400 (EDT)
Received: from [192.168.42.10] (dhcp-171-69-182-131.cisco.com [171.69.182.131]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA09004; Tue, 10 Sep 2002 11:41:34 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a17b9a3c297e4cc@[192.168.42.10]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 10 Sep 2002 11:41:22 -0400
To: "Abarbanel, Benjamin" <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: Router ID
Cc: "'[e-mail]'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 10:28 AM -0400 9/10/02, Abarbanel, Benjamin wrote:
>  Clearly, BGP Identifier must be routable for the protocol to
>  work and the session to be Established.

This is incorrect for several implementations with which I am familiar.

--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 LAA27999 for <[e-mail]>; Tue, 10 Sep 2002 11:40:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4220091318; Tue, 10 Sep 2002 11:40:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D9C99131C; Tue, 10 Sep 2002 11:40:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1603091318 for <[e-mail]>; Tue, 10 Sep 2002 11:40:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 03FE05DDF2; Tue, 10 Sep 2002 11:40:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 7D7955DDC5 for <[e-mail]>; Tue, 10 Sep 2002 11:40:10 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17647; Tue, 10 Sep 2002 11:40:08 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA14607; Tue, 10 Sep 2002 11:40:09 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QR2B6>; Tue, 10 Sep 2002 11:40:08 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Russ White'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Tue, 10 Sep 2002 11:40:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Russ White [mailto:[e-mail]]
> Sent: Tuesday, September 10, 2002 11:13 AM
> To: Abarbanel, Benjamin
> Cc: '[e-mail]'; 'Yakov Rekhter'; Natale, Jonathan;
> [e-mail]
> Subject: RE: admin dist/gp spec proposal 
> 
> 
> 
> > Could you give me an example where 2 BGP processes interact
> > with 1 OSPF process. Also an example where 2 OSPF processes
> > interact with 1 BGP Process.
> 
> The second is more plausible. I won't say it's common, but it is
> very possible on every implementation I know of. For instance,
> I've seen networks with two OSPF processes terminating in a
> single router, with redistribution, and a single BGP process on
> top of both. It would be simple to set up:
> 
> !
> router bgp 100
>  <stuff here>
> !
> router ospf 100
>  <stuff here>
> !
> router ospf 200
>  <stuff here>
> 
> Another instance to consider is on a PE, where I would think this
> could be very common. You're carrying multiple OSPF instances to
> customers, and then a "real" igp instance for your internal
> cloud, and then a single bgp instance. Does it matter if all
> these instances share the same router id, or not? In practice,
> they never have.
> 
> It appears that setting up a requirement that the router id's in
> all routing processes, for this and other reasons (such as the
> instance given of IS-IS with longer router id's), simply isn't
> possible.
> 
> :-)
> 
> Russ
> 
> 
As a PE you are talking about VPNs, using the same Router ID for each
OSPF instance in each VPN. That should not pose any problems, should it?

Since your example, there is a process ID defined in the config above. 
Internal to the implementation that could be used to identify which routes
belong to which instance of OSPF, even if they have the same router-ID
externally to the box. 
> 
> __________________________________
> [e-mail] CCIE <>< Grace Alone
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA27852 for <[e-mail]>; Tue, 10 Sep 2002 11:35:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1EF599131A; Tue, 10 Sep 2002 11:35:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA21891318; Tue, 10 Sep 2002 11:35:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 559B59131A for <[e-mail]>; Tue, 10 Sep 2002 11:34:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3CF325DDF2; Tue, 10 Sep 2002 11:34:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id B30E75DDC5 for <[e-mail]>; Tue, 10 Sep 2002 11:34:07 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA17152; Tue, 10 Sep 2002 11:34:05 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA13385; Tue, 10 Sep 2002 11:34:06 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QRHZM>; Tue, 10 Sep 2002 11:34:06 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Russ White'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Tue, 10 Sep 2002 11:34:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

For me its the NMS point of view, where its the address of a node which
is independent of a given interface and protocol and allows the NMS system
the ability to keep track of routing information in that node as well as
assist in keeping track which node/router owns which routes. Interworking
and networking/reachability capabilities are biproducts of this feature.

It seems silly to me to have one Router-ID value for BGP, another value
for Router-ID for OSPF, a third value for ISIS and so on. It makes the
number meaningless when view from the big cloud in the sky called NMS.

IMHO, You see I came from the old X.25, Fram Relay world.

Ben

> -----Original Message-----
> From: Russ White [mailto:[e-mail]]
> Sent: Tuesday, September 10, 2002 11:24 AM
> To: Abarbanel, Benjamin
> Cc: '[e-mail]'; 'Yakov Rekhter'; Natale, Jonathan;
> [e-mail]
> Subject: RE: admin dist/gp spec proposal 
> 
> 
> 
> > It appears that setting up a requirement that the router id's in
> > all routing processes, for this and other reasons (such as the
>                        ^
>                       match
> 
> > instance given of IS-IS with longer router id's), simply isn't
> > possible.
> 
> This all comes back to a fundamental question of what the router
> id really identifies.
> 
> :-)
> 
> Russ
> 
> 
> 
> __________________________________
> [e-mail] CCIE <>< Grace Alone
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA27628 for <[e-mail]>; Tue, 10 Sep 2002 11:30:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1ABD591313; Tue, 10 Sep 2002 11:29:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D84699131C; Tue, 10 Sep 2002 11:29:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6E0A91313 for <[e-mail]>; Tue, 10 Sep 2002 11:29:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C0FC85DDF2; Tue, 10 Sep 2002 11:29:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 137EF5DDC5 for <[e-mail]>; Tue, 10 Sep 2002 11:29:33 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8AFTEj21847; Tue, 10 Sep 2002 11:29:14 -0400 (EDT) (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 g8AFTBG21840; Tue, 10 Sep 2002 11:29:11 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8AFTB921164; Tue, 10 Sep 2002 11:29:11 -0400 (EDT)
Date: Tue, 10 Sep 2002 11:29:10 -0400
From: Jeffrey Haas <[e-mail]>
To: Russ White <[e-mail]>
Cc: [e-mail]
Subject: Re: admin dist/gp spec proposal
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, Sep 10, 2002 at 11:24:21AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Sep 10, 2002 at 11:24:21AM -0400, Russ White wrote:
> This all comes back to a fundamental question of what the router
> id really identifies.

A protocol specific identifier. :-)

The fact that various proposals over the years have used it 
for synchronization between protocols is useful to know.
Knowing if its still useful (example pro and con) are interesting to see. 

> Russ

-- 
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 LAA27473 for <[e-mail]>; Tue, 10 Sep 2002 11:24:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A57A791306; Tue, 10 Sep 2002 11:24:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C90091307; Tue, 10 Sep 2002 11:24:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DD65F91306 for <[e-mail]>; Tue, 10 Sep 2002 11:24:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B68FF5DDF2; Tue, 10 Sep 2002 11:24:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 40AE75DE0E for <[e-mail]>; Tue, 10 Sep 2002 11:24:30 -0400 (EDT)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA01384; Tue, 10 Sep 2002 11:24:21 -0400 (EDT)
Date: Tue, 10 Sep 2002 11:24:21 -0400 (EDT)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> It appears that setting up a requirement that the router id's in
> all routing processes, for this and other reasons (such as the
                       ^
                      match

> instance given of IS-IS with longer router id's), simply isn't
> possible.

This all comes back to a fundamental question of what the router
id really identifies.

:-)

Russ



__________________________________
[e-mail] CCIE <>< Grace Alone




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA27123 for <[e-mail]>; Tue, 10 Sep 2002 11:13:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2CBB191305; Tue, 10 Sep 2002 11:13:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3F5A91306; Tue, 10 Sep 2002 11:13:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 68B2691305 for <[e-mail]>; Tue, 10 Sep 2002 11:13:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 569675DE0F; Tue, 10 Sep 2002 11:13:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id D36455DDEA for <[e-mail]>; Tue, 10 Sep 2002 11:13:16 -0400 (EDT)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA00776; Tue, 10 Sep 2002 11:13:08 -0400 (EDT)
Date: Tue, 10 Sep 2002 11:13:08 -0400 (EDT)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Could you give me an example where 2 BGP processes interact
> with 1 OSPF process. Also an example where 2 OSPF processes
> interact with 1 BGP Process.

The second is more plausible. I won't say it's common, but it is
very possible on every implementation I know of. For instance,
I've seen networks with two OSPF processes terminating in a
single router, with redistribution, and a single BGP process on
top of both. It would be simple to set up:

!
router bgp 100
 <stuff here>
!
router ospf 100
 <stuff here>
!
router ospf 200
 <stuff here>

Another instance to consider is on a PE, where I would think this
could be very common. You're carrying multiple OSPF instances to
customers, and then a "real" igp instance for your internal
cloud, and then a single bgp instance. Does it matter if all
these instances share the same router id, or not? In practice,
they never have.

It appears that setting up a requirement that the router id's in
all routing processes, for this and other reasons (such as the
instance given of IS-IS with longer router id's), simply isn't
possible.

:-)

Russ



__________________________________
[e-mail] CCIE <>< Grace Alone




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA26942 for <[e-mail]>; Tue, 10 Sep 2002 11:07:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5238891302; Tue, 10 Sep 2002 11:07:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 217D191305; Tue, 10 Sep 2002 11:07:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2692B91302 for <[e-mail]>; Tue, 10 Sep 2002 11:07:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E53105DDEA; Tue, 10 Sep 2002 11:07:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 372715DDC5 for <[e-mail]>; Tue, 10 Sep 2002 11:07:05 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8AF6xS20868; Tue, 10 Sep 2002 11:06:59 -0400 (EDT) (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 g8AF6uG20861; Tue, 10 Sep 2002 11:06:56 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8AF6uB20678; Tue, 10 Sep 2002 11:06:56 -0400 (EDT)
Date: Tue, 10 Sep 2002 11:06:56 -0400
From: Jeffrey Haas <[e-mail]>
To: "Michael C. Cambria" <[e-mail]>
Cc: [e-mail]
Subject: Re: Extending AS_PATH attribute length en route
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
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Tue, Sep 10, 2002 at 10:34:41AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Sep 10, 2002 at 10:34:41AM -0400, Michael C. Cambria wrote:
> When implemeting, automated tools test for edge conditions.  So in the 
> QA lab, we _will_ see full path attributes, log this fact and then ?

IMO, do not propagate the route since you can't.

> MikeC

-- 
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 LAA26693 for <[e-mail]>; Tue, 10 Sep 2002 11:00:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3FD6E912FE; Tue, 10 Sep 2002 11:00:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC5A791300; Tue, 10 Sep 2002 11:00:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C570B912FE for <[e-mail]>; Tue, 10 Sep 2002 11:00:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 078C55DE0E; Tue, 10 Sep 2002 11:00:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 17DBA5DDC5 for <[e-mail]>; Tue, 10 Sep 2002 11:00:01 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14171; Tue, 10 Sep 2002 10:59:59 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA05657; Tue, 10 Sep 2002 11:00:00 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QRF7X>; Tue, 10 Sep 2002 10:59:59 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Russ White'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Tue, 10 Sep 2002 10:59:58 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Russ:

 
> Note: You cannot know, for certain, that you can have the same
> router id in all routing protocol processes. For instance, most
> implementations allow multiple processes of any given
> protocol. What if you have two bgp processes, and one ospf
> process--how would you share the router id's in this case? Or
> (more common) two ospf processes, and one bgp process? Which
> router id goes on which process?
> 
> Basically, the router id for BGP should be left as a standalone
> entity, and we shouldn't worry about it's interaction with other
> protocols, if at all possible.
> 
 
Could you give me an example where 2 BGP processes interact with 1 OSPF
process. Also an example where 2 OSPF processes interact with 1 BGP Process.


Frankly, I would want to pair up 1 BGP process with 1 OSPF process for
virtual routing sake, and another virtual routing instance of 1 BGP process
with 1 OSPF process. Thereby if each pair had a unique routable router-ID
that is shared between its OSPF and BGP component, it will not pose any
confusion. 

I agree, any other mix is a problem.

Ben

> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA26360 for <[e-mail]>; Tue, 10 Sep 2002 10:50:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1B675912FA; Tue, 10 Sep 2002 10:50:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DCFB9912FC; Tue, 10 Sep 2002 10:50:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 41D71912FA for <[e-mail]>; Tue, 10 Sep 2002 10:50:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 205985DE0E; Tue, 10 Sep 2002 10:50:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id 9EBF25DDC5 for <[e-mail]>; Tue, 10 Sep 2002 10:50:22 -0400 (EDT)
Received: from fid4.com (mcambria3.avayactc.com [199.93.239.107]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g8AEmGuo003747 for <[e-mail]>; Tue, 10 Sep 2002 10:48:16 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Tue, 10 Sep 2002 10:34:41 -0400
From: "Michael C. Cambria" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020819
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Extending AS_PATH attribute length en route
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Jeffrey Haas wrote:
> On Tue, Sep 10, 2002 at 09:48:25AM -0400, Michael C. Cambria wrote:
> 
>>Regardless, what to do when the (1 or 2 octet) length is used up should 
>>be specified.
> 
> 
> The more general overflow case is what you're talking about here.

Yes (adding another path segment is quite clear).

> It *might* not be appropropriate to deal with this since each
> implementation may choose to do deal with this in its own way.
> For the mandatory attributes, you have to be able to deal with
> overflows.  But if you're getting an AS Path that big, something
> has gone insane.

If the received path attribute total was only 1 octet,

When implemeting, automated tools test for edge conditions.  So in the 
QA lab, we _will_ see full path attributes, log this fact and then ?

MikeC



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA26342 for <[e-mail]>; Tue, 10 Sep 2002 10:50:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E580D912F9; Tue, 10 Sep 2002 10:49:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9EAD4912FC; Tue, 10 Sep 2002 10:49:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 47B7C912F9 for <[e-mail]>; Tue, 10 Sep 2002 10:49:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 34B265DE0E; Tue, 10 Sep 2002 10:49:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id AAE8E5DE1A for <[e-mail]>; Tue, 10 Sep 2002 10:49:45 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA13136; Tue, 10 Sep 2002 10:49:43 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02730; Tue, 10 Sep 2002 10:49:44 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QRFDY>; Tue, 10 Sep 2002 10:49:44 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Natale, Jonathan'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Tue, 10 Sep 2002 10:49:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Curtis:
  The comment I made was as a response to a joke message posted. I think
you are reading these messages out of sequence. I realize you are trying
to catch up with a bunch of messages posted in the past few days.

On a second note, the ADs had posted an invitation to all IDR list members
to review the latest RFC1771 draft, called "draft-ietf-idr-bgp4-17.txt".
Some people are new to this list and are giving the spec its most fresh
and open minded review possible. After all that is what the ADs asked for,
at the end of this effort, hopefully the spec would be much more user
friendly and correct as to current implemenatations, and properly states
what is, should, and must be done in BGP.

Ben



> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Monday, September 09, 2002 6:28 PM
> To: Abarbanel, Benjamin
> Cc: 'Natale, Jonathan'; 'Jeffrey Haas'; [e-mail]
> Subject: Re: admin dist/gp spec proposal 
> 
> 
> 
> In message 
> <[e-mail]>, 
> "Abarbanel, Benjamin" writes:
> > This is turning into a joke, do we want to tie loose ends or not?
> > 
> > :-)
> 
> 
> Yes but we don't want to put nonsense into the document.  Some of us
> have been looking at BGP4 for over 8 years and do try to remain
> patient with newbies.  When the newbies are clueless, return to
> discussions that occurred and were resolved years ago, and vigorously
> make incorrect assertions it makes it harder to maintain patience.
> We're doing just fine so far.  :-)
> 
> 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 KAA26001 for <[e-mail]>; Tue, 10 Sep 2002 10:38:25 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CE148912F7; Tue, 10 Sep 2002 10:38:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 915CF912F8; Tue, 10 Sep 2002 10:38:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 56E4A912F7 for <[e-mail]>; Tue, 10 Sep 2002 10:38:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3AD6C5DE0E; Tue, 10 Sep 2002 10:38:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id E3B595DDC5 for <[e-mail]>; Tue, 10 Sep 2002 10:38:03 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CDZ1>; Tue, 10 Sep 2002 10:38:03 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: NEXT_HOP to internal peer
Date: Tue, 10 Sep 2002 10:38:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Current implementation uses the next hop that exists for the route in its
originating protocol except if the route gets aggregated or (of course) if
it is advertised to the <next-hop> peer, in which case it is set to self.

For the purpose of documenting current behavior, this should be added as a
"SHOULD".


-----Original Message-----
From: Michael C. Cambria [mailto:[e-mail]] 
Sent: Monday, September 09, 2002 8:36 PM
To: [e-mail]
Subject: NEXT_HOP to internal peer


Hi,

Does BGP4 allow a local BGP speaker to advertise locally originated 
routes, via iBGP, to other BGP speakers in the AS?

If so, when sending a locally originated route to an internal peer, what 
should NEXT_HOP be set to?  The text below is specific when propergating 
a route that already contains NEXT_HOP, but nothing is said about when 
originating a route:

        1) When sending a message to an internal peer, 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.

Thanks,
MikeC


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA25926 for <[e-mail]>; Tue, 10 Sep 2002 10:36:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id AE84D912F6; Tue, 10 Sep 2002 10:35:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7DF6C912F7; Tue, 10 Sep 2002 10:35:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A0CA912F6 for <[e-mail]>; Tue, 10 Sep 2002 10:35:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4B0DF5DE0E; Tue, 10 Sep 2002 10:35:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id BE2A05DDC5 for <[e-mail]>; Tue, 10 Sep 2002 10:35:30 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8AEZN119818; Tue, 10 Sep 2002 10:35:23 -0400 (EDT) (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 g8AEZKG19811; Tue, 10 Sep 2002 10:35:20 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8AEZKo20286; Tue, 10 Sep 2002 10:35:20 -0400 (EDT)
Date: Tue, 10 Sep 2002 10:35:20 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Proxy: comments on section 9.1.3
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, Sep 09, 2002 at 04:23:07PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Curtis,

On Mon, Sep 09, 2002 at 04:23:07PM -0400, Curtis Villamizar wrote:
> I think I covered this accurately and completely enough.  Maybe we
> should put something in the document.  I don't care much if we use
> NRLI or prefix as the key when defining what a route is.  NRLI leaves
> open use of BGP for non-IP purposes.

the point of confusion is over "route".  We define "route"
as being multiple NLRI with a given set of path attributes.
Since this is mentioned in the singular it is not unreasonable,
English-wise, to assume that its an atomic entity and you should
operate on the whole thing.

If you then try to carry this definition throughout the whole document -
multiple NLRI and a set of path attributes - then you run into trouble.

Thats all I'm saying.

If it still sounds like I'm speaking nonsense, I'll gather all of the
references together as an example.

> 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 KAA25691 for <[e-mail]>; Tue, 10 Sep 2002 10:30:06 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 85C6D912F4; Tue, 10 Sep 2002 10:29:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4EE20912F5; Tue, 10 Sep 2002 10:29:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 47258912F4 for <[e-mail]>; Tue, 10 Sep 2002 10:29:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2CDA75DE0F; Tue, 10 Sep 2002 10:29:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 73B9F5DE0E for <[e-mail]>; Tue, 10 Sep 2002 10:29:33 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8AETRw19707; Tue, 10 Sep 2002 10:29:27 -0400 (EDT) (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 g8AETOG19700; Tue, 10 Sep 2002 10:29:24 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8AETOg20251; Tue, 10 Sep 2002 10:29:24 -0400 (EDT)
Date: Tue, 10 Sep 2002 10:29:24 -0400
From: Jeffrey Haas <[e-mail]>
To: "Michael C. Cambria" <[e-mail]>
Cc: [e-mail]
Subject: Re: Extending AS_PATH attribute length en route
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, Sep 10, 2002 at 09:48:25AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Sep 10, 2002 at 09:48:25AM -0400, Michael C. Cambria wrote:
> Regardless, what to do when the (1 or 2 octet) length is used up should 
> be specified.

The more general overflow case is what you're talking about here.

It *might* not be appropropriate to deal with this since each
implementation may choose to do deal with this in its own way.

For the mandatory attributes, you have to be able to deal with
overflows.  But if you're getting an AS Path that big, something
has gone insane.

For optional attributes, you may be able to discard some of them -
for example, communities.

> MikeC

-- 
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 KAA25659 for <[e-mail]>; Tue, 10 Sep 2002 10:29:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 55592912F3; Tue, 10 Sep 2002 10:28:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E733912F4; Tue, 10 Sep 2002 10:28:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 20DFB912F3 for <[e-mail]>; Tue, 10 Sep 2002 10:28:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 03B035DE0E; Tue, 10 Sep 2002 10:28:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 803325DDC5 for <[e-mail]>; Tue, 10 Sep 2002 10:28:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA10985 for <[e-mail]>; Tue, 10 Sep 2002 10:28:50 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27681 for <[e-mail]>; Tue, 10 Sep 2002 10:28:51 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QRD0K>; Tue, 10 Sep 2002 10:28:50 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Router ID 
Date: Tue, 10 Sep 2002 10:28:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

 
 Clearly, the OSPF Router ID does not have to be routable by 
 design on its own. Its TE/MPLS Router ID must be routable. 
 If the OSPF administrator chose an IP Routable number for the 
 non-TE OSPF router ID, it would NOT break non-TE OSPF. 
 
 Clearly, BGP Identifier must be routable for the protocol to 
 work and the session to be Established.
 
 Clearly, ISIS SYSTEM-ID is not routable in the IP world, but 
 its IP TE/MPLS Router-ID must be routable. 
 
 Requiring people to chose routable IP address in protocols 
 like OSPF makes a lot of sense. The only issue is existing OSPF 
 deployments will have to renumber their OSPF routers. I can understand 
 the reluctance to do so.
 
 But as a standards body and one that hopefully recommends the 
 proper way to build networks in the most idealistic environments, I 
 would suggest that the Router ID definition be brought closer to
convergence 
 than is currently done.
 
 Getting of the soap box,
 Ben
 
 P.S. I think Yakov's idea of writing a draft regarding this 
 topic is a good one. You guys want to co-author it?
 
> > -----Original Message-----
> > From: Natale, Jonathan [mailto:[e-mail]]
> > Sent: Tuesday, September 10, 2002 10:12 AM
> > To: [e-mail]
> > Subject: RE: admin dist/gp spec proposal 
> > 
> > 
> > "If the matching route is learned from an OSPF neighbor, its 
> > OSPF router ID
> > must match the BGP router ID of the iBGP neighbor."
> > -- http://www.cisco.com/warp/public/459/25.shtml
> > 
> > 
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:[e-mail]] 
> > Sent: Monday, September 09, 2002 6:11 PM
> > To: Abarbanel, Benjamin
> > Cc: 'Natale, Jonathan'; 'Yakov Rekhter'; [e-mail]
> > Subject: Re: admin dist/gp spec proposal 
> > 
> > 
> > In message
> > <[e-mail]>, 
> > "Abarbanel, Benjamin" writes:
> > > 
> > >  
> > > > 
> > > > Not that I am aware of.  There certainly is a case where they 
> > > > must be the
> > > > same (cisco bgp w/ ospf, don't know all the details of 
> > > > how/why).  
> > > 
> > > RFC1745, and RFC1403 tell you why they must be the same.
> > 
> > These documents are both historic.  In a prior message I 
> mentioned but
> > did not give the details as to why this practice (injecting BGP into
> > OSPF ala RFC1745) could be extremely harmfull.
> > 
> > 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 KAA25598 for <[e-mail]>; Tue, 10 Sep 2002 10:27:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E029C912EF; Tue, 10 Sep 2002 10:26:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3B33912F3; Tue, 10 Sep 2002 10:26:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8833D912EF for <[e-mail]>; Tue, 10 Sep 2002 10:26:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 745C75DE14; Tue, 10 Sep 2002 10:26:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id B7D815DE0F for <[e-mail]>; Tue, 10 Sep 2002 10:26:55 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8AEQtQ19612 for [e-mail]; Tue, 10 Sep 2002 10:26:55 -0400 (EDT) (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 g8AEQqG19605 for <[e-mail]>; Tue, 10 Sep 2002 10:26:52 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8AEQq520241 for [e-mail]; Tue, 10 Sep 2002 10:26:52 -0400 (EDT)
Date: Tue, 10 Sep 2002 10:26:52 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Re: admin dist/gp spec proposal
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, Sep 10, 2002 at 06:48:32AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Sep 10, 2002 at 06:48:32AM -0700, Yakov Rekhter wrote:
> With this in mind I would suggest that the folks who are interested
> in documenting relation between BGP Identifier and router identifiers
> used by other protocols (e.g., OSPF Router ID) should produce an internet 
> draft, and submit it to the IDR WG with the goal of publishing it as a BCP.

And whilst doing so, think of other things that belong in the replacement
for rfc 1772. 

You've all read that, haven't you? :-)

> 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 KAA25570 for <[e-mail]>; Tue, 10 Sep 2002 10:26:30 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7552B912EC; Tue, 10 Sep 2002 10:21:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 20158912F4; Tue, 10 Sep 2002 10:21:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4AF21912EC for <[e-mail]>; Tue, 10 Sep 2002 10:21:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 352415DE14; Tue, 10 Sep 2002 10:21:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id E04965DE0F for <[e-mail]>; Tue, 10 Sep 2002 10:21:13 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CDX1>; Tue, 10 Sep 2002 10:21:13 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: bgp draft review 
Date: Tue, 10 Sep 2002 10:21:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

OK, But is there a reference to docs regarding operational issue?  Should
there be?

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Monday, September 09, 2002 6:19 PM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: bgp draft review 


In message
<[e-mail]
ks.com>, "Natale, Jonathan" writes:
> 
> What about explicitly disallowing private addresses?

You can use private addresses and BGP but in the public Internet your
BGP speaking peers won't be happy about you advertising them to their
routers.  This is an operational issue outside of the scope of the
protocol definition.

Curtis


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 KAA25381 for <[e-mail]>; Tue, 10 Sep 2002 10:20:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 83415912EA; Tue, 10 Sep 2002 10:20:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 54C1D912EB; Tue, 10 Sep 2002 10:20:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C3F2912EA for <[e-mail]>; Tue, 10 Sep 2002 10:20:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4FFEB5DDC5; Tue, 10 Sep 2002 10:20:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id C44225DE0E for <[e-mail]>; Tue, 10 Sep 2002 10:20:05 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g8AEJwX19381; Tue, 10 Sep 2002 10:19:58 -0400 (EDT) (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 g8AEJtG19374; Tue, 10 Sep 2002 10:19:55 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g8AEJtV20184; Tue, 10 Sep 2002 10:19:55 -0400 (EDT)
Date: Tue, 10 Sep 2002 10:19:55 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: admin dist/gp spec proposal
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, Sep 09, 2002 at 06:27:34PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Not specifically picking on you Curtis, but having had essentially
the same conversation three times yesterday:

On Mon, Sep 09, 2002 at 06:27:34PM -0400, Curtis Villamizar wrote:
> Some of us
> have been looking at BGP4 for over 8 years and do try to remain
> patient with newbies.  When the newbies are clueless, return to
> discussions that occurred and were resolved years ago, and vigorously
> make incorrect assertions it makes it harder to maintain patience.

When something makes it into a document, hopefully its painfully
obvious why its in there.  When its not painfully obvious, the wisdom
that was behind why it ended up in the document must sometimes
be rediscovered if its not spelled out plainly.

The attempts to rediscover that are very educational for newbies, but
frustrating for our "elders".  No FAQ, lots of silly questions. :-)

> 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 KAA25060 for <[e-mail]>; Tue, 10 Sep 2002 10:12:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CF575912E7; Tue, 10 Sep 2002 10:12:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0C5B912E9; Tue, 10 Sep 2002 10:12:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 64513912E7 for <[e-mail]>; Tue, 10 Sep 2002 10:12:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 53C415DE02; Tue, 10 Sep 2002 10:12:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 06D8B5DDC5 for <[e-mail]>; Tue, 10 Sep 2002 10:12:14 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CDV6>; Tue, 10 Sep 2002 10:12:13 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Tue, 10 Sep 2002 10:12:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

"If the matching route is learned from an OSPF neighbor, its OSPF router ID
must match the BGP router ID of the iBGP neighbor."
-- http://www.cisco.com/warp/public/459/25.shtml


-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Monday, September 09, 2002 6:11 PM
To: Abarbanel, Benjamin
Cc: 'Natale, Jonathan'; 'Yakov Rekhter'; [e-mail]
Subject: Re: admin dist/gp spec proposal 


In message
<[e-mail]>, 
"Abarbanel, Benjamin" writes:
> 
>  
> > 
> > Not that I am aware of.  There certainly is a case where they 
> > must be the
> > same (cisco bgp w/ ospf, don't know all the details of 
> > how/why).  
> 
> RFC1745, and RFC1403 tell you why they must be the same.

These documents are both historic.  In a prior message I mentioned but
did not give the details as to why this practice (injecting BGP into
OSPF ala RFC1745) could be extremely harmfull.

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 KAA24826 for <[e-mail]>; Tue, 10 Sep 2002 10:09:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 158EE912E8; Tue, 10 Sep 2002 10:08:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2D4E912E7; Tue, 10 Sep 2002 10:08:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 71C9F912E8 for <[e-mail]>; Tue, 10 Sep 2002 10:08:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3792E5DE02; Tue, 10 Sep 2002 10:08:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id D7F0C5DE08 for <[e-mail]>; Tue, 10 Sep 2002 10:08:52 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CDV1>; Tue, 10 Sep 2002 10:08:52 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Tue, 10 Sep 2002 10:08:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Ok, good examples.  But they still should be the same. (this horse is dead)

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Monday, September 09, 2002 5:58 PM
To: Natale, Jonathan
Cc: 'Abarbanel, Benjamin'; 'Yakov Rekhter'; [e-mail]
Subject: Re: admin dist/gp spec proposal 


In message
<[e-mail]
ks.com>, "Natale, Jonathan" writes:
> > > 
> > > " BTW. BGP Identifier is a vague way of naming what we know as the
> > >   Router-ID in all other IP related protocols."
> > 
> > This is *technically* incorrect. 
> >
> Is there a case where the BGP Identifier, should or must be different than
> the Router-ID for the routing system to work correctly?
> 
> Ben

No, but you can configure then to be different and things still do
work.  One possible reason to configure them differently would be if
your IGP was ISIS and the router ID was an NSAP, not supported by BGP
as a BGP Identifier.  Another is you have an existing OSPF network and
want to add BGP and your OSPf routers were numbered sequentially
(router IDs are not routable).

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 KAA24729 for <[e-mail]>; Tue, 10 Sep 2002 10:05:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E15A6912E4; Tue, 10 Sep 2002 10:05:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8B45912E7; Tue, 10 Sep 2002 10:05:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 43908912E4 for <[e-mail]>; Tue, 10 Sep 2002 10:05:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 280515DE02; Tue, 10 Sep 2002 10:05:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id D68935DDC5 for <[e-mail]>; Tue, 10 Sep 2002 10:05:32 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CD4Q>; Tue, 10 Sep 2002 10:05:32 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: admin dist/gp spec proposal 
Date: Tue, 10 Sep 2002 10:05:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

12.0.0.1 is not the loopback
127.0.0.1 is 1 loopback. Any 127.x.x.x is a loopback.  
I think you missed the point.  The IOS loopback interface != IP loopback
address.
I agree, there may be more than 1 id, buut why would you.  Again, the word
is "SHOULD" (not "MUST").  Or are you proposing that only musts be added???

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Monday, September 09, 2002 5:55 PM
To: Natale, Jonathan
Cc: 'Abarbanel, Benjamin'; '[e-mail]'
Subject: Re: admin dist/gp spec proposal 


In message
<[e-mail]
ks.com>, "Natale, Jonathan" writes:
> 
> What I would like to see:
> 1 and only 1 router id per router (for all protocols) which is set equal
to
> the 1 and only 1 circuitless ip address(Bay/Wellfleet term, aka cisco
> "loopback"--a term I don't like since it is often confused with loopback
> address 127.x.x.x) which is an address officially assigned to the box
(e.g.
> no rfc1918/"private address", martian, nor multicast allowed) which cannot
> be changed unless all routing protocols are restarted (obviously the admin
> should be warned of this restart).


FYI - loopback is the name derived from BSD and the loopback address
has the address of 12.0.0.1 plus at least one alias if the BSD host
has more than one interface and supports specific applications which
can bind the client (connect rather than listen/accept) side of a TCP
connection to the loopback.  A corrent IBGP implementation is one such
application.  Circuitless was later invented by clueless over at Bay
rather than using existing and long standing terminology (I was Bay's
main BGP customer at the time so I can say that as much as anyone).

There is no requirement for 1 and only 1 router id per router.  Get
used to it.  It is considered best practice though.

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 KAA24696 for <[e-mail]>; Tue, 10 Sep 2002 10:04:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 693F4912E1; Tue, 10 Sep 2002 10:04:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 346B7912E4; Tue, 10 Sep 2002 10:04:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 37137912E1 for <[e-mail]>; Tue, 10 Sep 2002 10:04:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1737C5DE02; Tue, 10 Sep 2002 10:04:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id 943435DDC5 for <[e-mail]>; Tue, 10 Sep 2002 10:04:06 -0400 (EDT)
Received: from fid4.com (mcambria3.avayactc.com [199.93.239.107]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g8AE20uo003645 for <[e-mail]>; Tue, 10 Sep 2002 10:02:00 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Tue, 10 Sep 2002 09:48:25 -0400
From: "Michael C. Cambria" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020819
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Extending AS_PATH attribute length en route
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hi,

The draft doesn't say what an implementation should do when the total
length of the path attribute used up.  (i.e. the entire 1 or 2 octect
field is used up.)  When propergating to a peer, if the addition of
another AS would overflow the total length of the attribute, what should
be done?

Could a solution be to let an implementation change a received
unextended AS_PATH attribute length, when propergating, from 0 to
1 so that the total length of the attribute can hold greater than 255
octets?

Regardless, what to do when the (1 or 2 octet) length is used up should 
be specified.

MikeC






Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA24461 for <[e-mail]>; Tue, 10 Sep 2002 09:58:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9E55A912DE; Tue, 10 Sep 2002 09:58:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67777912E1; Tue, 10 Sep 2002 09:58:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2516A912DE for <[e-mail]>; Tue, 10 Sep 2002 09:58:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0D1E95DE02; Tue, 10 Sep 2002 09:58:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id BC7075DDC5 for <[e-mail]>; Tue, 10 Sep 2002 09:58:32 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CDS0>; Tue, 10 Sep 2002 09:58:32 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Tue, 10 Sep 2002 09:58:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Isn't that what "SHOULD" means???

Why does it need to be routable?

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Monday, September 09, 2002 5:44 PM
To: Abarbanel, Benjamin
Cc: 'Yakov Rekhter'; Natale, Jonathan; [e-mail]
Subject: Re: admin dist/gp spec proposal 


In message
<[e-mail]>, 
"Abarbanel, Benjamin" writes:
> 
>          ... The value of the BGP Identifier is 
>          determined on startup and is the same for every local interface 
>          and every BGP peer and other IP related protocols. See [x],[y]
for 
>          more details on Router-ID useage between BGP and other
protocols."
> 
> Where x = RFC1403,
>       y = RFC1745


This is not true so we can't add it.  The OSPF router-id and BGP
Identifier can be different (the OSPF router id need not be a routable
address and the BGP Identifier must be a routable address).  It is a
good idea to make the OSPF router-id routable and make it the BGP
Identifier take on the same value but not a requirement.

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 JAA24371 for <[e-mail]>; Tue, 10 Sep 2002 09:56:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B26D1912DC; Tue, 10 Sep 2002 09:55:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7FDBB912DE; Tue, 10 Sep 2002 09:55:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 51CF9912DC for <[e-mail]>; Tue, 10 Sep 2002 09:55:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3A3C55DE02; Tue, 10 Sep 2002 09:55:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id E1BF85DDC5 for <[e-mail]>; Tue, 10 Sep 2002 09:55:42 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CDSR>; Tue, 10 Sep 2002 09:55:42 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: bgp spec proposal 
Date: Tue, 10 Sep 2002 09:55:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

So we agree that it should be a SHOULD, not a must.

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Monday, September 09, 2002 5:17 PM
To: Natale, Jonathan
Cc: 'Yakov Rekhter'; Mathew Richardson; [e-mail]
Subject: Re: bgp spec proposal 


In message
<[e-mail]
ks.com>, "Natale, Jonathan" writes:
> Which brings up another point:  What about the obscure rule that OSPF/BGP
> router IDs should match?  Should this be added? 

BCP material.  This is not a protocol requirement, just a good idea.
The router ID should also be a loopback interface, but that too is not
a protocol requirement.

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 JAA24168 for <[e-mail]>; Tue, 10 Sep 2002 09:49:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1DD3F912D2; Tue, 10 Sep 2002 09:48:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D949E912DC; Tue, 10 Sep 2002 09:48:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 22FA4912D2 for <[e-mail]>; Tue, 10 Sep 2002 09:48:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0A7DF5DDF2; Tue, 10 Sep 2002 09:48:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 8F8335DDC5 for <[e-mail]>; Tue, 10 Sep 2002 09:48:33 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8ADmWm52179; Tue, 10 Sep 2002 06:48:32 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: admin dist/gp spec proposal 
In-Reply-To: Your message of "Tue, 10 Sep 2002 09:19:25 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 10 Sep 2002 06:48:32 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> I agree, it mention that the BGP Router ID *should*
> match the Router ID as used by the other routing protocols.
> 
> Let's here the reasons why it should not be mentioned (other than the
> draconian fact that this is a bgp and only bgp spec)...

As Curtis said in his e-mail:

  It is really not a protocol requirement.  It is a good practice, but
  if we document all good (and bad) practices for using BGP we'd have a
  huge document.
  ...

  It is best that the applicability statement or other BCP document the
  good and bad practices for using BGP.  How to configure router IDs to
  maintain the sanity of your operations staff is usage of BGP.

With this in mind I would suggest that the folks who are interested
in documenting relation between BGP Identifier and router identifiers
used by other protocols (e.g., OSPF Router ID) should produce an internet 
draft, and submit it to the IDR WG with the goal of publishing it as a BCP.

Yakov.

> -----Original Message-----
> From: Manav Bhatia [mailto:[e-mail]] 
> Sent: Monday, September 09, 2002 4:00 AM
> To: Yakov Rekhter; Natale, Jonathan
> Cc: 'Abarbanel, Benjamin'; [e-mail]
> Subject: Re: admin dist/gp spec proposal
> 
> Yakov and others,
> draft-ietf-isis-traffic-04.txt states that if some router advertises the
> router ID TLV (containing the 4-octet router ID of the router originating
> the LSP) in its LSP, and if it also advertises BGP routes with the BGP next
> hop set to the BGP router ID (which is what is usually done), then in such
> cases, the TE router ID should match the BGP router ID.
> 
> I think this warrants the need to mention that the BGP Router ID *should*
> match the Router ID as used by the other routing protocols. Moreover i dont
> see any need for the router IDs to *not* match for the BGP and IGPs and i
> am sure that there will not be any operators assigning different Router IDs
> for the same.
> 
> Or am i missing something here?
> 
> Manav
> 
> ----- Original Message -----
> From: "Yakov Rekhter" <[e-mail]>
> To: "Natale, Jonathan" <[e-mail]>
> Cc: "'Abarbanel, Benjamin'" <[e-mail]>;
> <[e-mail]>
> Sent: Saturday, September 07, 2002 1:13 AM
> Subject: Re: admin dist/gp spec proposal
> 
> 
> | Natale,
> |
> | > 1745 and 1403 are historic
> |
> | correct. And with this in mind I would suggest we stop reference/pointing
> | to them.
> |
> | Yakov.
> |
> | > -----Original Message-----
> | > From: Abarbanel, Benjamin [mailto:[e-mail]]
> | > Sent: Friday, September 06, 2002 3:38 PM
> | > To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Yakov Rekhter'
> | > Cc: [e-mail]
> | > Subject: RE: admin dist/gp spec proposal
> | >
> | >
> | >
> | > >
> | > > Not that I am aware of.  There certainly is a case where they
> | > > must be the
> | > > same (cisco bgp w/ ospf, don't know all the details of
> | > > how/why).
> | >
> | > RFC1745, and RFC1403 tell you why they must be the same.
> | >
> | > > Maybe the local admin method of numbering is more versatile by
> allowing
> | > > them to be different.  I think they should MUST be the same and in
> some
> | > > implementation they are (gated, bay).
> | > >
> | > > -----Original Message-----
> | > > From: Abarbanel, Benjamin [mailto:[e-mail]]
> | > > Sent: Friday, September 06, 2002 3:29 PM
> | > > To: 'Yakov Rekhter'; Abarbanel, Benjamin
> | > > Cc: Natale, Jonathan; [e-mail]
> | > > Subject: RE: admin dist/gp spec proposal
> | > >
> | > >
> | > > >
> | > > > > I would like to rephrase my statement on one sentence.
> | > > > >
> | > > > > " BTW. BGP Identifier is a vague way of naming what we know as
> the
> | > > > >   Router-ID in all other IP related protocols."
> | > > >
> | > > > This is *technically* incorrect.
> | > > >
> | > > Is there a case where the BGP Identifier, should or must be
> | > > different than
> | > > the Router-ID for the routing system to work correctly?
> | > >
> | > > Ben
> | > >
> | > >
> | > > >
> | > > > >
> | > > > >
> | > > > > > -----Original Message-----
> | > > > > > From: Abarbanel, Benjamin
> | > > [mailto:[e-mail]]
> | > > > > > Sent: Friday, September 06, 2002 3:01 PM
> | > > > > > To: 'Yakov Rekhter'; Natale, Jonathan
> | > > > > > Cc: [e-mail]
> | > > > > > Subject: RE: admin dist/gp spec proposal
> | > > > > >
> | > > > > >
> | > > > > > Yakov:
> | > > > > >   There is no reference to RFC1812 in the reference section
> | > > > > > nor references
> | > > > > > to this spec where appropriate in the BGP relevant
> | > > > > > discussions. As was
> | > > > > > earlier mentioned. At least we need to tie the thread
> | > > > between the two
> | > > > > > specs so people know what the assumptions are.
> | > > > > >
> | > > > > > BTW. BGP Identifier is a very misleading way of naming what
> | > > > > > we know as the
> | > > > > > Router ID in all other protocols. I would like to suggest we
> | > > > > > enhance its
> | > > > > > description as follows:
> | > > > > >
> | > > > > > Current statement:
> | > > > > > ==================
> | > > > > > "BGP Identifier:
> | > > > > >
> | > > > >          This 4-octet unsigned integer indicates the BGP
> | > > > Identifier of
> | > > > > >          the sender. A given BGP speaker sets the value
> | > > of its BGP
> | > > > > >          Identifier to an IP address assigned to that BGP
> | > > > > > speaker.  The
> | > > > > >          value of the BGP Identifier is determined on startup
> | > > > > > and is the
> | > > > > >          same for every local interface and every BGP peer. "
> | > > > > >
> | > > > > > New Statement:
> | > > > > > ==============
> | > > > > > "BGP Identifier:
> | > > > > >
> | > > > > >          This 4-octet unsigned integer indicates the BGP
> | > > > Identifier of
> | > > > > >          the sender. A given BGP speaker sets the value
> | > > of its BGP
> | > > > > >          Identifier also known as the Router-ID, to an IP
> | > > > > > address assigned
> | > > > > >          to that BGP speaker. The value of the BGP
> | > > Identifier is
> | > > > > >          determined on startup and is the same for every
> | > > > > > local interface
> | > > > > >          and every BGP peer and other IP related protocols.
> | > > > > > See [x],[y] for
> | > > > > >          more details on Router-ID useage between BGP and
> | > > > > > other protocols."
> | > > > > >
> | > > > > > Where x = RFC1403,
> | > > > > >       y = RFC1745
> | > > > > >
> | > > > > > Ben
> | > > > > > > -----Original Message-----
> | > > > > > > From: Yakov Rekhter [mailto:[e-mail]]
> | > > > > > > Sent: Friday, September 06, 2002 2:31 PM
> | > > > > > > To: Natale, Jonathan
> | > > > > > > Cc: [e-mail]
> | > > > > > > Subject: Re: admin dist/gp spec proposal
> | > > > > > >
> | > > > > > >
> | > > > > > > Natale,
> | > > > > > >
> | > > > > > > >
> | > > > > > > >
> | > > > > > > > -----Original Message-----
> | > > > > > > > From: Abarbanel, Benjamin
> | > > > [mailto:[e-mail]]
> | > > > > > > > Sent: Friday, September 06, 2002 1:49 PM
> | > > > > > > > To: 'Natale, Jonathan'
> | > > > > > > > Subject: RE: admin dist/gp spec proposal
> | > > > > > > >
> | > > > > > > > Jonathan:
> | > > > > > > > Forward this message to the IDR list. I think we
> | > > dropped off.
> | > > > > > > >
> | > > > > > > > Ben
> | > > > > > > >
> | > > > > > > > > -----Original Message-----
> | > > > > > > > > From: Natale, Jonathan [mailto:[e-mail]]
> | > > > > > > > > Sent: Friday, September 06, 2002 1:46 PM
> | > > > > > > > > To: 'Abarbanel, Benjamin'
> | > > > > > > > > Subject: RE: admin dist/gp spec proposal
> | > > > > > > > >
> | > > > > > > > >
> | > > > > > > > > I agree.  The default values of the various
> | > > > protocols as they
> | > > > > > > > > are currently
> | > > > > > > > > implemented make sense:
> | > > > > > > > > Connected
> | > > > > > > > > Static
> | > > > > > > > > Ebgp
> | > > > > > > > > Igp's
> | > > > > > > > > Ibgp
> | > > > > > > > >
> | > > > > > > > > ...they should be documented in 1812 ideally, but
> | > > > putting it
> | > > > > > > > > in 1771 would
> | > > > > > > > > not hurt.  Added a phrase to indicate that they
> | > > may be user
> | > > > > > > > > configurable is
> | > > > > > > > > good too.
> | > > > > > >
> | > > > > > > Perhaps it is time to update 1812. But let's not use BGP
> | > > > > > > spec as a replacement for updating 1812 - it is not.
> | > > > > > >
> | > > > > > > Yakov.
> | > > > > > >
> | > > > > > > > >
> | > > > > > > > > -----Original Message-----
> | > > > > > > > > From: Abarbanel, Benjamin
> | > > > > [mailto:[e-mail]]
> | > > > > > > > Sent: Friday, September 06, 2002 11:39 AM
> | > > > > > > > To: 'Mathew Richardson'; Natale, Jonathan
> | > > > > > > > Cc: [e-mail]
> | > > > > > > > Subject: RE: admin dist/gp spec proposal
> | > > > > > > >
> | > >
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA23336 for <[e-mail]>; Tue, 10 Sep 2002 09:24:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1BB8491292; Tue, 10 Sep 2002 09:23:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3786912CC; Tue, 10 Sep 2002 09:23:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2595591292 for <[e-mail]>; Tue, 10 Sep 2002 09:23:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0E2925DE02; Tue, 10 Sep 2002 09:23:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id B093B5DDF2 for <[e-mail]>; Tue, 10 Sep 2002 09:23:54 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CD35>; Tue, 10 Sep 2002 09:23:54 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: admin dist/gp spec proposal
Date: Tue, 10 Sep 2002 09:23:50 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Er, "it SHOULD mention that", sorry for the typo.

-----Original Message-----
From: Natale, Jonathan [mailto:[e-mail]] 
Sent: Tuesday, September 10, 2002 9:19 AM
To: [e-mail]
Subject: RE: admin dist/gp spec proposal

I agree, it mention that the BGP Router ID *should*
match the Router ID as used by the other routing protocols.

Let's here the reasons why it should not be mentioned (other than the
draconian fact that this is a bgp and only bgp spec)...



-----Original Message-----
From: Manav Bhatia [mailto:[e-mail]] 
Sent: Monday, September 09, 2002 4:00 AM
To: Yakov Rekhter; Natale, Jonathan
Cc: 'Abarbanel, Benjamin'; [e-mail]
Subject: Re: admin dist/gp spec proposal

Yakov and others,
draft-ietf-isis-traffic-04.txt states that if some router advertises the
router ID TLV (containing the 4-octet router ID of the router originating
the LSP) in its LSP, and if it also advertises BGP routes with the BGP next
hop set to the BGP router ID (which is what is usually done), then in such
cases, the TE router ID should match the BGP router ID.

I think this warrants the need to mention that the BGP Router ID *should*
match the Router ID as used by the other routing protocols. Moreover i dont
see any need for the router IDs to *not* match for the BGP and IGPs and i
am sure that there will not be any operators assigning different Router IDs
for the same.

Or am i missing something here?

Manav

----- Original Message -----
From: "Yakov Rekhter" <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Abarbanel, Benjamin'" <[e-mail]>;
<[e-mail]>
Sent: Saturday, September 07, 2002 1:13 AM
Subject: Re: admin dist/gp spec proposal


| Natale,
|
| > 1745 and 1403 are historic
|
| correct. And with this in mind I would suggest we stop reference/pointing
| to them.
|
| Yakov.
|
| > -----Original Message-----
| > From: Abarbanel, Benjamin [mailto:[e-mail]]
| > Sent: Friday, September 06, 2002 3:38 PM
| > To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Yakov Rekhter'
| > Cc: [e-mail]
| > Subject: RE: admin dist/gp spec proposal
| >
| >
| >
| > >
| > > Not that I am aware of.  There certainly is a case where they
| > > must be the
| > > same (cisco bgp w/ ospf, don't know all the details of
| > > how/why).
| >
| > RFC1745, and RFC1403 tell you why they must be the same.
| >
| > > Maybe the local admin method of numbering is more versatile by
allowing
| > > them to be different.  I think they should MUST be the same and in
some
| > > implementation they are (gated, bay).
| > >
| > > -----Original Message-----
| > > From: Abarbanel, Benjamin [mailto:[e-mail]]
| > > Sent: Friday, September 06, 2002 3:29 PM
| > > To: 'Yakov Rekhter'; Abarbanel, Benjamin
| > > Cc: Natale, Jonathan; [e-mail]
| > > Subject: RE: admin dist/gp spec proposal
| > >
| > >
| > > >
| > > > > I would like to rephrase my statement on one sentence.
| > > > >
| > > > > " BTW. BGP Identifier is a vague way of naming what we know as
the
| > > > >   Router-ID in all other IP related protocols."
| > > >
| > > > This is *technically* incorrect.
| > > >
| > > Is there a case where the BGP Identifier, should or must be
| > > different than
| > > the Router-ID for the routing system to work correctly?
| > >
| > > Ben
| > >
| > >
| > > >
| > > > >
| > > > >
| > > > > > -----Original Message-----
| > > > > > From: Abarbanel, Benjamin
| > > [mailto:[e-mail]]
| > > > > > Sent: Friday, September 06, 2002 3:01 PM
| > > > > > To: 'Yakov Rekhter'; Natale, Jonathan
| > > > > > Cc: [e-mail]
| > > > > > Subject: RE: admin dist/gp spec proposal
| > > > > >
| > > > > >
| > > > > > Yakov:
| > > > > >   There is no reference to RFC1812 in the reference section
| > > > > > nor references
| > > > > > to this spec where appropriate in the BGP relevant
| > > > > > discussions. As was
| > > > > > earlier mentioned. At least we need to tie the thread
| > > > between the two
| > > > > > specs so people know what the assumptions are.
| > > > > >
| > > > > > BTW. BGP Identifier is a very misleading way of naming what
| > > > > > we know as the
| > > > > > Router ID in all other protocols. I would like to suggest we
| > > > > > enhance its
| > > > > > description as follows:
| > > > > >
| > > > > > Current statement:
| > > > > > ==================
| > > > > > "BGP Identifier:
| > > > > >
| > > > >          This 4-octet unsigned integer indicates the BGP
| > > > Identifier of
| > > > > >          the sender. A given BGP speaker sets the value
| > > of its BGP
| > > > > >          Identifier to an IP address assigned to that BGP
| > > > > > speaker.  The
| > > > > >          value of the BGP Identifier is determined on startup
| > > > > > and is the
| > > > > >          same for every local interface and every BGP peer. "
| > > > > >
| > > > > > New Statement:
| > > > > > ==============
| > > > > > "BGP Identifier:
| > > > > >
| > > > > >          This 4-octet unsigned integer indicates the BGP
| > > > Identifier of
| > > > > >          the sender. A given BGP speaker sets the value
| > > of its BGP
| > > > > >          Identifier also known as the Router-ID, to an IP
| > > > > > address assigned
| > > > > >          to that BGP speaker. The value of the BGP
| > > Identifier is
| > > > > >          determined on startup and is the same for every
| > > > > > local interface
| > > > > >          and every BGP peer and other IP related protocols.
| > > > > > See [x],[y] for
| > > > > >          more details on Router-ID useage between BGP and
| > > > > > other protocols."
| > > > > >
| > > > > > Where x = RFC1403,
| > > > > >       y = RFC1745
| > > > > >
| > > > > > Ben
| > > > > > > -----Original Message-----
| > > > > > > From: Yakov Rekhter [mailto:[e-mail]]
| > > > > > > Sent: Friday, September 06, 2002 2:31 PM
| > > > > > > To: Natale, Jonathan
| > > > > > > Cc: [e-mail]
| > > > > > > Subject: Re: admin dist/gp spec proposal
| > > > > > >
| > > > > > >
| > > > > > > Natale,
| > > > > > >
| > > > > > > >
| > > > > > > >
| > > > > > > > -----Original Message-----
| > > > > > > > From: Abarbanel, Benjamin
| > > > [mailto:[e-mail]]
| > > > > > > > Sent: Friday, September 06, 2002 1:49 PM
| > > > > > > > To: 'Natale, Jonathan'
| > > > > > > > Subject: RE: admin dist/gp spec proposal
| > > > > > > >
| > > > > > > > Jonathan:
| > > > > > > > Forward this message to the IDR list. I think we
| > > dropped off.
| > > > > > > >
| > > > > > > > Ben
| > > > > > > >
| > > > > > > > > -----Original Message-----
| > > > > > > > > From: Natale, Jonathan [mailto:[e-mail]]
| > > > > > > > > Sent: Friday, September 06, 2002 1:46 PM
| > > > > > > > > To: 'Abarbanel, Benjamin'
| > > > > > > > > Subject: RE: admin dist/gp spec proposal
| > > > > > > > >
| > > > > > > > >
| > > > > > > > > I agree.  The default values of the various
| > > > protocols as they
| > > > > > > > > are currently
| > > > > > > > > implemented make sense:
| > > > > > > > > Connected
| > > > > > > > > Static
| > > > > > > > > Ebgp
| > > > > > > > > Igp's
| > > > > > > > > Ibgp
| > > > > > > > >
| > > > > > > > > ...they should be documented in 1812 ideally, but
| > > > putting it
| > > > > > > > > in 1771 would
| > > > > > > > > not hurt.  Added a phrase to indicate that they
| > > may be user
| > > > > > > > > configurable is
| > > > > > > > > good too.
| > > > > > >
| > > > > > > Perhaps it is time to update 1812. But let's not use BGP
| > > > > > > spec as a replacement for updating 1812 - it is not.
| > > > > > >
| > > > > > > Yakov.
| > > > > > >
| > > > > > > > >
| > > > > > > > > -----Original Message-----
| > > > > > > > > From: Abarbanel, Benjamin
| > > > > [mailto:[e-mail]]
| > > > > > > > Sent: Friday, September 06, 2002 11:39 AM
| > > > > > > > To: 'Mathew Richardson'; Natale, Jonathan
| > > > > > > > Cc: [e-mail]
| > > > > > > > Subject: RE: admin dist/gp spec proposal
| > > > > > > >
| > >


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA23249 for <[e-mail]>; Tue, 10 Sep 2002 09:21:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E449D91290; Tue, 10 Sep 2002 09:19:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A59F891291; Tue, 10 Sep 2002 09:19:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A585591290 for <[e-mail]>; Tue, 10 Sep 2002 09:19:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 23D545DDF2; Tue, 10 Sep 2002 09:19:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id C383A5DDC5 for <[e-mail]>; Tue, 10 Sep 2002 09:19:31 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CDN8>; Tue, 10 Sep 2002 09:19:31 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: admin dist/gp spec proposal
Date: Tue, 10 Sep 2002 09:19:25 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I agree, it mention that the BGP Router ID *should*
match the Router ID as used by the other routing protocols.

Let's here the reasons why it should not be mentioned (other than the
draconian fact that this is a bgp and only bgp spec)...



-----Original Message-----
From: Manav Bhatia [mailto:[e-mail]] 
Sent: Monday, September 09, 2002 4:00 AM
To: Yakov Rekhter; Natale, Jonathan
Cc: 'Abarbanel, Benjamin'; [e-mail]
Subject: Re: admin dist/gp spec proposal

Yakov and others,
draft-ietf-isis-traffic-04.txt states that if some router advertises the
router ID TLV (containing the 4-octet router ID of the router originating
the LSP) in its LSP, and if it also advertises BGP routes with the BGP next
hop set to the BGP router ID (which is what is usually done), then in such
cases, the TE router ID should match the BGP router ID.

I think this warrants the need to mention that the BGP Router ID *should*
match the Router ID as used by the other routing protocols. Moreover i dont
see any need for the router IDs to *not* match for the BGP and IGPs and i
am sure that there will not be any operators assigning different Router IDs
for the same.

Or am i missing something here?

Manav

----- Original Message -----
From: "Yakov Rekhter" <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Abarbanel, Benjamin'" <[e-mail]>;
<[e-mail]>
Sent: Saturday, September 07, 2002 1:13 AM
Subject: Re: admin dist/gp spec proposal


| Natale,
|
| > 1745 and 1403 are historic
|
| correct. And with this in mind I would suggest we stop reference/pointing
| to them.
|
| Yakov.
|
| > -----Original Message-----
| > From: Abarbanel, Benjamin [mailto:[e-mail]]
| > Sent: Friday, September 06, 2002 3:38 PM
| > To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Yakov Rekhter'
| > Cc: [e-mail]
| > Subject: RE: admin dist/gp spec proposal
| >
| >
| >
| > >
| > > Not that I am aware of.  There certainly is a case where they
| > > must be the
| > > same (cisco bgp w/ ospf, don't know all the details of
| > > how/why).
| >
| > RFC1745, and RFC1403 tell you why they must be the same.
| >
| > > Maybe the local admin method of numbering is more versatile by
allowing
| > > them to be different.  I think they should MUST be the same and in
some
| > > implementation they are (gated, bay).
| > >
| > > -----Original Message-----
| > > From: Abarbanel, Benjamin [mailto:[e-mail]]
| > > Sent: Friday, September 06, 2002 3:29 PM
| > > To: 'Yakov Rekhter'; Abarbanel, Benjamin
| > > Cc: Natale, Jonathan; [e-mail]
| > > Subject: RE: admin dist/gp spec proposal
| > >
| > >
| > > >
| > > > > I would like to rephrase my statement on one sentence.
| > > > >
| > > > > " BTW. BGP Identifier is a vague way of naming what we know as
the
| > > > >   Router-ID in all other IP related protocols."
| > > >
| > > > This is *technically* incorrect.
| > > >
| > > Is there a case where the BGP Identifier, should or must be
| > > different than
| > > the Router-ID for the routing system to work correctly?
| > >
| > > Ben
| > >
| > >
| > > >
| > > > >
| > > > >
| > > > > > -----Original Message-----
| > > > > > From: Abarbanel, Benjamin
| > > [mailto:[e-mail]]
| > > > > > Sent: Friday, September 06, 2002 3:01 PM
| > > > > > To: 'Yakov Rekhter'; Natale, Jonathan
| > > > > > Cc: [e-mail]
| > > > > > Subject: RE: admin dist/gp spec proposal
| > > > > >
| > > > > >
| > > > > > Yakov:
| > > > > >   There is no reference to RFC1812 in the reference section
| > > > > > nor references
| > > > > > to this spec where appropriate in the BGP relevant
| > > > > > discussions. As was
| > > > > > earlier mentioned. At least we need to tie the thread
| > > > between the two
| > > > > > specs so people know what the assumptions are.
| > > > > >
| > > > > > BTW. BGP Identifier is a very misleading way of naming what
| > > > > > we know as the
| > > > > > Router ID in all other protocols. I would like to suggest we
| > > > > > enhance its
| > > > > > description as follows:
| > > > > >
| > > > > > Current statement:
| > > > > > ==================
| > > > > > "BGP Identifier:
| > > > > >
| > > > >          This 4-octet unsigned integer indicates the BGP
| > > > Identifier of
| > > > > >          the sender. A given BGP speaker sets the value
| > > of its BGP
| > > > > >          Identifier to an IP address assigned to that BGP
| > > > > > speaker.  The
| > > > > >          value of the BGP Identifier is determined on startup
| > > > > > and is the
| > > > > >          same for every local interface and every BGP peer. "
| > > > > >
| > > > > > New Statement:
| > > > > > ==============
| > > > > > "BGP Identifier:
| > > > > >
| > > > > >          This 4-octet unsigned integer indicates the BGP
| > > > Identifier of
| > > > > >          the sender. A given BGP speaker sets the value
| > > of its BGP
| > > > > >          Identifier also known as the Router-ID, to an IP
| > > > > > address assigned
| > > > > >          to that BGP speaker. The value of the BGP
| > > Identifier is
| > > > > >          determined on startup and is the same for every
| > > > > > local interface
| > > > > >          and every BGP peer and other IP related protocols.
| > > > > > See [x],[y] for
| > > > > >          more details on Router-ID useage between BGP and
| > > > > > other protocols."
| > > > > >
| > > > > > Where x = RFC1403,
| > > > > >       y = RFC1745
| > > > > >
| > > > > > Ben
| > > > > > > -----Original Message-----
| > > > > > > From: Yakov Rekhter [mailto:[e-mail]]
| > > > > > > Sent: Friday, September 06, 2002 2:31 PM
| > > > > > > To: Natale, Jonathan
| > > > > > > Cc: [e-mail]
| > > > > > > Subject: Re: admin dist/gp spec proposal
| > > > > > >
| > > > > > >
| > > > > > > Natale,
| > > > > > >
| > > > > > > >
| > > > > > > >
| > > > > > > > -----Original Message-----
| > > > > > > > From: Abarbanel, Benjamin
| > > > [mailto:[e-mail]]
| > > > > > > > Sent: Friday, September 06, 2002 1:49 PM
| > > > > > > > To: 'Natale, Jonathan'
| > > > > > > > Subject: RE: admin dist/gp spec proposal
| > > > > > > >
| > > > > > > > Jonathan:
| > > > > > > > Forward this message to the IDR list. I think we
| > > dropped off.
| > > > > > > >
| > > > > > > > Ben
| > > > > > > >
| > > > > > > > > -----Original Message-----
| > > > > > > > > From: Natale, Jonathan [mailto:[e-mail]]
| > > > > > > > > Sent: Friday, September 06, 2002 1:46 PM
| > > > > > > > > To: 'Abarbanel, Benjamin'
| > > > > > > > > Subject: RE: admin dist/gp spec proposal
| > > > > > > > >
| > > > > > > > >
| > > > > > > > > I agree.  The default values of the various
| > > > protocols as they
| > > > > > > > > are currently
| > > > > > > > > implemented make sense:
| > > > > > > > > Connected
| > > > > > > > > Static
| > > > > > > > > Ebgp
| > > > > > > > > Igp's
| > > > > > > > > Ibgp
| > > > > > > > >
| > > > > > > > > ...they should be documented in 1812 ideally, but
| > > > putting it
| > > > > > > > > in 1771 would
| > > > > > > > > not hurt.  Added a phrase to indicate that they
| > > may be user
| > > > > > > > > configurable is
| > > > > > > > > good too.
| > > > > > >
| > > > > > > Perhaps it is time to update 1812. But let's not use BGP
| > > > > > > spec as a replacement for updating 1812 - it is not.
| > > > > > >
| > > > > > > Yakov.
| > > > > > >
| > > > > > > > >
| > > > > > > > > -----Original Message-----
| > > > > > > > > From: Abarbanel, Benjamin
| > > > > [mailto:[e-mail]]
| > > > > > > > Sent: Friday, September 06, 2002 11:39 AM
| > > > > > > > To: 'Mathew Richardson'; Natale, Jonathan
| > > > > > > > Cc: [e-mail]
| > > > > > > > Subject: RE: admin dist/gp spec proposal
| > > > > > > >
| > >



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA22763 for <[e-mail]>; Tue, 10 Sep 2002 09:05:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 943E791239; Tue, 10 Sep 2002 09:04:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 623229128F; Tue, 10 Sep 2002 09:04:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 231D891239 for <[e-mail]>; Tue, 10 Sep 2002 09:04:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 10A825DDF3; Tue, 10 Sep 2002 09:04:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id BAD175DDF2 for <[e-mail]>; Tue, 10 Sep 2002 09:04:51 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CDL0>; Tue, 10 Sep 2002 09:04:51 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Michael C. Cambria'" <[e-mail]>, [e-mail]
Subject: RE: Review Comments: Section 4.3: Description of AS_PATH length
Date: Tue, 10 Sep 2002 09:04:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I think an ASCII art example diagram would be good here (the old sniffer
decoded it incorrectly, so IT HAS confused people).

-----Original Message-----
From: Michael C. Cambria [mailto:[e-mail]] 
Sent: Saturday, September 07, 2002 5:27 PM
To: [e-mail]
Subject: Review Comments: Section 4.3: Description of AS_PATH length


 From a first time reader point of view ...

Length fields elsewhere in the draft specify the number of bytes that a 
variable length field uses.  For AS_PATH, length is used as the number 
of 2 byte AS numbers.  In the interest of not having to check other 
sources to be sure, should the descripton of path segment value:

"The path segment value field contains one or more AS numbers, each 
encoded as a 2-octets long field."

explicitly mention the number of bytes used by the variable length field?

Or, make the description of length explicitly mention that it is not the 
length of the variable length field as is the case with other length fields?

MikeC


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA22464 for <[e-mail]>; Tue, 10 Sep 2002 08:57:21 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B67529128E; Tue, 10 Sep 2002 08:56:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7FF319128F; Tue, 10 Sep 2002 08:56:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3B31B9128E for <[e-mail]>; Tue, 10 Sep 2002 08:56:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 11F415DDF1; Tue, 10 Sep 2002 08:56:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id BC9C95DDC5 for <[e-mail]>; Tue, 10 Sep 2002 08:56:41 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CDLB>; Tue, 10 Sep 2002 08:56:41 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Michael C. Cambria'" <[e-mail]>, [e-mail]
Subject: RE: Review: Comments:  Section 4.3: UPDATE min length
Date: Tue, 10 Sep 2002 08:56:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Right.

" The minimum length of the UPDATE message is 23 octets -- 19 octets
   for the fixed header + 2 octets for the Withdrawn Routes Length + 2
   octets for the Total Path Attribute Length (the value of Withdrawn
   Routes Length is 0 and the value of Total Path Attribute Length is
   0)."

Should be moved up to just after

"... the Total Path Attribute Length field and the
         Withdrawn Routes Length field."

And

" the value of Withdrawn
   Routes Length is 0 and the value of Total Path Attribute Length is
   0)."

Should be changed to 

" the min. value of Withdrawn
   Routes Length is 0 and the min. value of Total Path Attribute Length is
   0)."

-----Original Message-----
From: Michael C. Cambria [mailto:[e-mail]] 
Sent: Saturday, September 07, 2002 1:02 PM
To: [e-mail]
Subject: Review: Comments: Section 4.3: UPDATE min length


The text about the mimimum length, at first look, gives the impression 
that it is still part of the NLRI field description and/or the Path 
Attributes section.  A new "subsection" or heading of some sort would be 
helpfull in switching context back to the UPDATE message as a whole and 
not the path attributes field anymore.

MikeC


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA22280 for <[e-mail]>; Tue, 10 Sep 2002 08:50:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EDD149128B; Tue, 10 Sep 2002 08:50:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B513A9128E; Tue, 10 Sep 2002 08:50:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3D8099128B for <[e-mail]>; Tue, 10 Sep 2002 08:50:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 11A4E5DDF1; Tue, 10 Sep 2002 08:50:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id B8A1D5DDC5 for <[e-mail]>; Tue, 10 Sep 2002 08:50:31 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CDKT>; Tue, 10 Sep 2002 08:50:31 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: Review: Section 4.3 - Path Attributes
Date: Tue, 10 Sep 2002 08:50:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

True, the path attribute 
field itself can be left out.  The text should be changed.

-----Original Message-----
From: Michael C. Cambria [mailto:[e-mail]] 
Sent: Saturday, September 07, 2002 12:59 PM
To: [e-mail]
Subject: Review: Section 4.3 - Path Attributes


 From a first time reader point of view ...

The top of page 13 says:

"A variable length sequence of path attributes is present in every UPDATE."

Is this really true, given that later, in the second to last paragraph 
of this section (4.3):

"An UPDATE message might advertise only routes to be withdrawn from 
service, in which case it will not include path attributes or Network 
Layer Reachability Information."

This could be confusing to a first time reader.

The path attribute length is present in every UPDATE, the path attribute 
field itself can be left out, both according to the description of the 
minimum length of the UPDATE message and (implied?) in the picture of 
the UPDATE message at the beginning of section 4.3.

MikeC


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA22168 for <[e-mail]>; Tue, 10 Sep 2002 08:46:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5A7C991288; Tue, 10 Sep 2002 08:45:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1AD39128B; Tue, 10 Sep 2002 08:45:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 870C691288 for <[e-mail]>; Tue, 10 Sep 2002 08:45:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B6DD75DE08; Tue, 10 Sep 2002 08:45:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id C7DA75DE02 for <[e-mail]>; Tue, 10 Sep 2002 08:45:10 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CDJX>; Tue, 10 Sep 2002 08:45:10 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: bgp draft review
Date: Tue, 10 Sep 2002 08:45:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I propose that 

"jitter should be applied to the
   timers associated with MinASOriginationInterval, Keepalive, and
   MinRouteAdvertisementInterval"

Be changed to:

"jitter should be applied to the
   timers associated with ConnectRetry timer"

This reflects current implementation, right?


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA21816 for <[e-mail]>; Tue, 10 Sep 2002 08:36:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6A6819128C; Tue, 10 Sep 2002 08:35:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E7D39128B; Tue, 10 Sep 2002 08:35:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B51B91288 for <[e-mail]>; Tue, 10 Sep 2002 08:35:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3DAD05DE02; Tue, 10 Sep 2002 08:35:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id BA1985DDF2 for <[e-mail]>; Tue, 10 Sep 2002 08:35:35 -0400 (EDT)
Received: from fid4.com (mcambria.fid4.com [172.16.6.1]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g8ACXTuo003509 for <[e-mail]>; Tue, 10 Sep 2002 08:33:29 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Tue, 10 Sep 2002 08:33:29 -0400
From: "Michael C. Cambria" <[e-mail]>
Organization: U n o r g a n i z e d
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020818
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Review: Section 2, TCP Port 179
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Curtis Villamizar wrote:

> 

>  though some minor editorial changes could be made.

Which is all the original message (and most I've sent) asked for.

MikeC




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA21794 for <[e-mail]>; Tue, 10 Sep 2002 08:35:36 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A800691285; Tue, 10 Sep 2002 08:35:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6566C91288; Tue, 10 Sep 2002 08:35:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 18A5E91285 for <[e-mail]>; Tue, 10 Sep 2002 08:35:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E83375DDF2; Tue, 10 Sep 2002 08:35:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id A43015DDF1 for <[e-mail]>; Tue, 10 Sep 2002 08:35:20 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CD2M>; Tue, 10 Sep 2002 08:35:20 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: bgp draft review
Date: Tue, 10 Sep 2002 08:35:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C258C6.817CBDC0"
Sender: [e-mail]
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C258C6.817CBDC0
Content-Type: text/plain

Please add a table a contents, and please rename the 6.x sections in
appendix so they are not confused with the regular 6.x sections.


------_=_NextPart_001_01C258C6.817CBDC0
Content-Type: text/html

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">


<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Please add a table a contents, and please rename the 6.x sections
in appendix so they are not confused with the regular 6.x sections.</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C258C6.817CBDC0--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA21694 for <[e-mail]>; Tue, 10 Sep 2002 08:32:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1744F91236; Tue, 10 Sep 2002 08:31:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30C6391285; Tue, 10 Sep 2002 08:31:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4385291236 for <[e-mail]>; Tue, 10 Sep 2002 08:31:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 20A315DE08; Tue, 10 Sep 2002 08:31:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id BFA7D5DDF1 for <[e-mail]>; Tue, 10 Sep 2002 08:31:40 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CDH0>; Tue, 10 Sep 2002 08:31:40 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'John G. Scudder'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Review: Section 2, TCP Port 179
Date: Tue, 10 Sep 2002 08:31:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I agree.  Let's not make this a TCP tutorial.  Maybe add reference to 1 or
more TCP RFCs???

Also,  If not already done, I think whether or not to accept incoming
connects on 179 while in Idle should be clarified--some/most implementations
do, others do not.

-----Original Message-----
From: John G. Scudder [mailto:[e-mail]] 
Sent: Monday, September 09, 2002 5:10 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: Review: Section 2, TCP Port 179

At 11:41 AM -0700 9/9/02, [e-mail] wrote:
>Ok, so we have two options:
>
>"BGP listens on TCP port 179."
>
>Which leaves the transmit port undefined. Or:
>
>"BGP listens on TCP port 179 and transmits from an implemetation-dependent
>port."
>
>Thinking of a new operational network engineer reading the spec, the latter
>seems more clear.  What do you think as an implementor?

Brevity is the soul of wit.  I prefer the former option.  Anyone who 
is a little bit familiar with TCP should understand that only the 
listen port needs to be 179.  As Yakov points out, it's a _BGP_ spec 
and IMO doesn't need to be a TCP tutorial.

(Furthermore, the second statement is technically incorrect because 
one of the two BGP speakers in any connection will be sourcing its 
traffic from port 179.)

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 IAA21327 for <[e-mail]>; Tue, 10 Sep 2002 08:21:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DFFCB91234; Tue, 10 Sep 2002 08:21:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADE7491236; Tue, 10 Sep 2002 08:21:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5EA7E91234 for <[e-mail]>; Tue, 10 Sep 2002 08:21:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 47A5F5DE02; Tue, 10 Sep 2002 08:21:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id EF8365DD8E for <[e-mail]>; Tue, 10 Sep 2002 08:21:20 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1CDGF>; Tue, 10 Sep 2002 08:21:20 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Enke Chen'" <[e-mail]>, Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Tue, 10 Sep 2002 08:21:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I propose that any 32bit number be accepted as the received
id/aggregator/etc. but disallow the user from locally setting the
id/aggregator/etc to a non-valid host address (0.0.0.0, 255.255.255.255,
127.x.x.x, (>=224.x.x.x) since some implementation may not peer with these
numbers (due to RFC1771 compliance).

I also think it should [still] be recommended to locally set the bgp id ==
the ospf id == a (preferably globally/officially assigned)
circuitless/boxwide/loopback address, and that this should be
configured/implemented such that a reboot will not change the number.

-----Original Message-----
From: Enke Chen [mailto:[e-mail]] 
Sent: Saturday, September 07, 2002 2:50 AM
To: Jeffrey Haas
Cc: [e-mail]; [e-mail]
Subject: Re: admin dist/gp spec proposal 

Jeff:

> Date: Fri, 6 Sep 2002 16:05:02 -0400
> From: Jeffrey Haas <[e-mail]>
> To: "Natale, Jonathan" <[e-mail]>
> Cc: [e-mail]
> Subject: Re: admin dist/gp spec proposal
> Message-ID: <[e-mail]>
> References:
<[e-mail]>
> 

[snip]

> I should also point out that we have had the BGP Identifier arguments
> before.  We are trending this away from an actual IP to just an
> Identifer, which makes usage of it in ipv6 networks easier.

Indeed, and please take note of the IDR WG draft on the BGP Identifier:

     draft-ietf-idr-bgp-identifier-00.txt

-- Enke


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA28267 for <[e-mail]>; Mon, 9 Sep 2002 20:38:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A0C8991250; Mon,  9 Sep 2002 20:38:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6A5F491284; Mon,  9 Sep 2002 20:38:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E143991250 for <[e-mail]>; Mon,  9 Sep 2002 20:38:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CFD7F5DDD9; Mon,  9 Sep 2002 20:38:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id 501575DD8F for <[e-mail]>; Mon,  9 Sep 2002 20:38:01 -0400 (EDT)
Received: from fid4.com (mcambria.fid4.com [172.16.8.1]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g8A0Zvuo002485 for <[e-mail]>; Mon, 9 Sep 2002 20:35:57 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Mon, 09 Sep 2002 20:35:57 -0400
From: "Michael C. Cambria" <[e-mail]>
Organization: U n o r g a n i z e d
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020818
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: NEXT_HOP to internal peer
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hi,

Does BGP4 allow a local BGP speaker to advertise locally originated 
routes, via iBGP, to other BGP speakers in the AS?

If so, when sending a locally originated route to an internal peer, what 
should NEXT_HOP be set to?  The text below is specific when propergating 
a route that already contains NEXT_HOP, but nothing is said about when 
originating a route:

        1) When sending a message to an internal peer, 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.

Thanks,
MikeC



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 TAA25038 for <[e-mail]>; Mon, 9 Sep 2002 19:20:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 27D8891218; Mon,  9 Sep 2002 19:19:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB7DB91281; Mon,  9 Sep 2002 19:19:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 63D0591218 for <[e-mail]>; Mon,  9 Sep 2002 19:19:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4FFCB5DDDA; Mon,  9 Sep 2002 19:19:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 083075DD8F for <[e-mail]>; Mon,  9 Sep 2002 19:19:56 -0400 (EDT)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id TAA03385; Mon, 9 Sep 2002 19:19:46 -0400 (EDT)
Date: Mon, 9 Sep 2002 19:19:46 -0400 (EDT)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Therefore, the IETF specs should be written that say what can
> be done and suggest what should be done in building a stable
> network.

But this wouldn't be a part of the base BGP spec.

Note: You cannot know, for certain, that you can have the same
router id in all routing protocol processes. For instance, most
implementations allow multiple processes of any given
protocol. What if you have two bgp processes, and one ospf
process--how would you share the router id's in this case? Or
(more common) two ospf processes, and one bgp process? Which
router id goes on which process?

Basically, the router id for BGP should be left as a standalone
entity, and we shouldn't worry about it's interaction with other
protocols, if at all possible.

:-)

Russ


__________________________________
[e-mail] CCIE <>< Grace Alone




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA22694 for <[e-mail]>; Mon, 9 Sep 2002 18:26:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 799E19127C; Mon,  9 Sep 2002 18:26:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 495579127D; Mon,  9 Sep 2002 18:26:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 57A739127C for <[e-mail]>; Mon,  9 Sep 2002 18:25:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 48DAC5DDD0; Mon,  9 Sep 2002 18:25:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id C86235DD8F for <[e-mail]>; Mon,  9 Sep 2002 18:25:58 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA11642; Mon, 9 Sep 2002 18:25:56 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA11801; Mon, 9 Sep 2002 18:25:58 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QQR1P>; Mon, 9 Sep 2002 18:25:57 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Mon, 9 Sep 2002 18:25:56 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Curtis:
  The problem is, most major vendors allow you to redistribute routes from
BGP to OSPF via a configuration policy. Even if that is a bad idea, it is
allowed and can be done by anyone. Good or bad, it is provided to the
operator.
Therefore, the IETF specs should be written that say what can be done and
suggest what should be done in building a stable network. 

I agree with you its a bad ideas to redistribute BGP into OSPF if there are
alot of BGP routes involved. Aggregation policies might help reduce the
number
of routes redistributed. 

Ben



> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Monday, September 09, 2002 6:17 PM
> To: Abarbanel, Benjamin
> Cc: 'Yakov Rekhter'; Natale, Jonathan; [e-mail]
> Subject: Re: admin dist/gp spec proposal 
> 
> 
> 
> In message 
> <[e-mail]>, 
> "Abarbanel, Benjamin" writes:
> > Is there something that replaces them to go to for 
> technical correctness?
> 
> They are considered hazardous waste generated by the IDR WG.  RFC1745
> was an attempt to avoid the need for IBGP and use OSPF flooding.  Some
> ideas work out, some don't.  With Opaque LSAs and some modification to
> the periodic expiration of LSA (BGP into OSPF generates a huge number
> of LSAs, making it toxic) it might be made to work.  There is no
> replacement.  Most people, once they understand both OSPF and BGP
> don't see a need for a replacement to describe current usage.
> 
> 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 SAA22325 for <[e-mail]>; Mon, 9 Sep 2002 18:19:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 859FB91279; Mon,  9 Sep 2002 18:17:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 597B29127A; Mon,  9 Sep 2002 18:17:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6E39591279 for <[e-mail]>; Mon,  9 Sep 2002 18:17:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 551265DECE; Mon,  9 Sep 2002 18:17:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id D55075DDD8 for <[e-mail]>; Mon,  9 Sep 2002 18:17:22 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA11458; Mon, 9 Sep 2002 18:17:19 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA10752; Mon, 9 Sep 2002 18:17:21 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QQQ64>; Mon, 9 Sep 2002 18:17:21 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Natale, Jonathan'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Mon, 9 Sep 2002 18:17:20 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

 
> > > Not that I am aware of.  There certainly is a case where they 
> > > must be the
> > > same (cisco bgp w/ ospf, don't know all the details of 
> > > how/why).  
> > 
> > RFC1745, and RFC1403 tell you why they must be the same.
> 
> These documents are both historic.  In a prior message I mentioned but
> did not give the details as to why this practice (injecting BGP into
> OSPF ala RFC1745) could be extremely harmfull.
> 
> Curtis

I agree about BGP into OSPF, but what about the other way around?

Ben
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA22141 for <[e-mail]>; Mon, 9 Sep 2002 18:17:06 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 49F1B91278; Mon,  9 Sep 2002 18:16:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1199091279; Mon,  9 Sep 2002 18:15:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB66C91278 for <[e-mail]>; Mon,  9 Sep 2002 18:15:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C54105DDBE; Mon,  9 Sep 2002 18:15:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 4FDE65DDA2 for <[e-mail]>; Mon,  9 Sep 2002 18:15:58 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA11423; Mon, 9 Sep 2002 18:15:55 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA10618; Mon, 9 Sep 2002 18:15:57 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QQQ50>; Mon, 9 Sep 2002 18:15:57 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: admin dist/gp spec proposal 
Date: Mon, 9 Sep 2002 18:15:56 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I was stuck in the BGP world too long. I forgot that OSPF has a non-routable
Router-ID address. I do remember that the OSPF TE router address must be
routable in its TE extensions, though.

ISIS SYSTEM ID does not count, but the IPv4/IPv6 TE router-ID for it in the
TE
extensions must be routable right? 

a little excerpt from ISIS TE spec:

"6.0 The Traffic Engineering router ID TLV

   The Traffic Engineering router ID TLV is TLV type 134.

   The router ID TLV contains the 4-octet router ID of the router
   originating the LSP.  This is useful in several regards:

   For traffic engineering, it guarantees that we have a single stable
   address that can always be referenced in a path that will be
   reachable from multiple hops away, regardless of the state of the
   node's interfaces.

   If OSPF is also active in the domain, traffic engineering can compute
   the mapping between the OSPF and IS-IS topologies.

   If a router advertises the Traffic Engineering router ID TLV in its
   LSP, and if it advertises BGP routes with the BGP next hop attribute
   set to the BGP router ID, in that case the Traffic Engineering router
   ID should be the same as the BGP router ID.

   Implementations MUST NOT inject a /32 prefix for the router ID into
   their forwarding table, because this can lead to forwarding loops
   when interacting with systems that do not support this TLV."

Ben

P.S. The problem is we have too many different ways to do this. We should
have
one method and one mechanism it will make interworking with other protocols
much
more simpler to do.

> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Monday, September 09, 2002 5:58 PM
> To: Natale, Jonathan
> Cc: 'Abarbanel, Benjamin'; 'Yakov Rekhter'; [e-mail]
> Subject: Re: admin dist/gp spec proposal 
> 
> 
> 
> In message 
> <[e-mail]
> ks.com>, "Natale, Jonathan" writes:
> > > > 
> > > > " BTW. BGP Identifier is a vague way of naming what we 
> know as the
> > > >   Router-ID in all other IP related protocols."
> > > 
> > > This is *technically* incorrect. 
> > >
> > Is there a case where the BGP Identifier, should or must be 
> different than
> > the Router-ID for the routing system to work correctly?
> > 
> > Ben
> 
> No, but you can configure then to be different and things still do
> work.  One possible reason to configure them differently would be if
> your IGP was ISIS and the router ID was an NSAP, not supported by BGP
> as a BGP Identifier.  Another is you have an existing OSPF network and
> want to add BGP and your OSPf routers were numbered sequentially
> (router IDs are not routable).
> 
> 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 RAA21008 for <[e-mail]>; Mon, 9 Sep 2002 17:53:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1BE8E91247; Mon,  9 Sep 2002 17:53:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D195091272; Mon,  9 Sep 2002 17:53:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E1EA291247 for <[e-mail]>; Mon,  9 Sep 2002 17:53:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BFC9C5DECE; Mon,  9 Sep 2002 17:53:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 4C65D5DEBC for <[e-mail]>; Mon,  9 Sep 2002 17:53:04 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA10843; Mon, 9 Sep 2002 17:53:01 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA08369; Mon, 9 Sep 2002 17:53:03 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QQQL5>; Mon, 9 Sep 2002 17:53:02 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Mon, 9 Sep 2002 17:53:01 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Agreed.

Ben

> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Monday, September 09, 2002 5:44 PM
> To: Abarbanel, Benjamin
> Cc: 'Yakov Rekhter'; Natale, Jonathan; [e-mail]
> Subject: Re: admin dist/gp spec proposal 
> 
> 
> 
> In message 
> <[e-mail]>, 
> "Abarbanel, Benjamin" writes:
> > 
> >          ... The value of the BGP Identifier is 
> >          determined on startup and is the same for every 
> local interface 
> >          and every BGP peer and other IP related protocols. 
> See [x],[y] for 
> >          more details on Router-ID useage between BGP and 
> other protocols."
> > 
> > Where x = RFC1403,
> >       y = RFC1745
> 
> 
> This is not true so we can't add it.  The OSPF router-id and BGP
> Identifier can be different (the OSPF router id need not be a routable
> address and the BGP Identifier must be a routable address).  It is a
> good idea to make the OSPF router-id routable and make it the BGP
> Identifier take on the same value but not a requirement.
> 
> 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 RAA19351 for <[e-mail]>; Mon, 9 Sep 2002 17:13:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 03A6691271; Mon,  9 Sep 2002 17:10:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD34591272; Mon,  9 Sep 2002 17:10:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 30CE091271 for <[e-mail]>; Mon,  9 Sep 2002 17:10:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1F9385DEC5; Mon,  9 Sep 2002 17:10:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (router.cisco.com [171.69.182.20]) by segue.merit.edu (Postfix) with ESMTP id 5D3825DD91 for <[e-mail]>; Mon,  9 Sep 2002 17:10:18 -0400 (EDT)
Received: from [192.168.42.10] (dhcp-171-69-182-131.cisco.com [171.69.182.131]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA25553; Mon, 9 Sep 2002 17:10:11 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a08b9a29d54646e@[192.168.42.10]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 9 Sep 2002 17:09:41 -0400
To: [e-mail]
From: "John G. Scudder" <[e-mail]>
Subject: Re: Review: Section 2, TCP Port 179
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 11:41 AM -0700 9/9/02, [e-mail] wrote:
>Ok, so we have two options:
>
>"BGP listens on TCP port 179."
>
>Which leaves the transmit port undefined. Or:
>
>"BGP listens on TCP port 179 and transmits from an implemetation-dependent
>port."
>
>Thinking of a new operational network engineer reading the spec, the latter
>seems more clear.  What do you think as an implementor?

Brevity is the soul of wit.  I prefer the former option.  Anyone who 
is a little bit familiar with TCP should understand that only the 
listen port needs to be 179.  As Yakov points out, it's a _BGP_ spec 
and IMO doesn't need to be a TCP tutorial.

(Furthermore, the second statement is technically incorrect because 
one of the two BGP speakers in any connection will be sourcing its 
traffic from port 179.)

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 QAA17952 for <[e-mail]>; Mon, 9 Sep 2002 16:34:21 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3510D9126E; Mon,  9 Sep 2002 16:31:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E51C991270; Mon,  9 Sep 2002 16:31:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7814A9126E for <[e-mail]>; Mon,  9 Sep 2002 16:31:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D67D85DD91; Mon,  9 Sep 2002 16:30:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 8BE0D5DF88 for <[e-mail]>; Mon,  9 Sep 2002 16:15:30 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g89KFBu00137; Mon, 9 Sep 2002 16:15:11 -0400 (EDT) (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 g89KF8G00130; Mon, 9 Sep 2002 16:15:08 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g89KF8d27072; Mon, 9 Sep 2002 16:15:08 -0400 (EDT)
Date: Mon, 9 Sep 2002 16:15:08 -0400
From: Mathew Richardson <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Michael C. Cambria'" <[e-mail]>, [e-mail]
Subject: Re: Review: Section 2, TCP Port 179
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

> Abarbanel, Benjamin <[e-mail]> [Mon, Sep 09, 2002 at 03:08:56PM -0400]:
>Michael:
>
>  This issue with the recieve on port 179 and transmit from port X for BGP 
>goes back to the Client-Server model in TCP. If you look at Stevens book, a
>Server should not transmit from a well known port it is trying to establish
>many sessions on with its clients.  Therefore, the assumption in the BGP
>spec is that it must be a unique number for each BGP peer the current peer
>has a session with.

<snip>

I don't believe that this assumption is present in the spec, and I
don't think we want to add it.  It should be sufficient to note that
BGP listens for TCP connections on port 179, and the set of ports
from which BGP initiates TCP connections is a local matter.

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 QAA17823 for <[e-mail]>; Mon, 9 Sep 2002 16:31:54 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E13959126C; Mon,  9 Sep 2002 16:31:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6FEDC9126F; Mon,  9 Sep 2002 16:31:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE5A19126C for <[e-mail]>; Mon,  9 Sep 2002 16:30:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5A9E35DF0E; Mon,  9 Sep 2002 16:30:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 7784B5DF9E for <[e-mail]>; Mon,  9 Sep 2002 16:15:48 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA05485; Mon, 9 Sep 2002 16:15:27 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA21272; Mon, 9 Sep 2002 16:15:29 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QQMMM>; Mon, 9 Sep 2002 16:15:28 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: admin dist/gp spec proposal
Date: Mon, 9 Sep 2002 16:15:27 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Jeff:

 
> 
> On Mon, Sep 09, 2002 at 02:45:11PM -0400, Abarbanel, Benjamin wrote:
> > The only thing I want to add about the definition of the 
> BGP Identifier, if 
> > we choose to keep it separate from the Router-ID, is that 
> its value should
> > be
> > a routable/reachable IP address in the network where BGP operates.
> 
> Two comments:
> 1. If its v6 only, there may be no v4 address to reach.

Then the value should be routable in the IPv6 Cloud. The router that has
a dual stack should have two values for the BGP Identifier, one for IPv4
which is common across all routing protocols, and one for IPv6 also common
across all routing protocols. The BGP router should know based on operator 
configuration, what address family its peer is using and use it accordingly.

> 2. While it is a *nicety* that we can use the identifier in the one
>    place it shows up globally (aggregator) to determine what router
>    did the work, the only requirement is that it be a valid 
> BGP Identifier
>    for purposes of dealing with loop detection and route selection.
> 

Dont forget Interworking with other protocols. 

> However, if its going to be ipv4, it doesn't hurt to recommend that it
> have a real IP address.  Note that it might very well be a rfc1918 
> address.
> 
> > Ben
> 
> -- 
> 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 QAA17739 for <[e-mail]>; Mon, 9 Sep 2002 16:29:16 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EC6C09126B; Mon,  9 Sep 2002 16:28:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B20C49126C; Mon,  9 Sep 2002 16:28:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A9FB49126B for <[e-mail]>; Mon,  9 Sep 2002 16:28:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 91B645DDB5; Mon,  9 Sep 2002 16:28:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 155C55DDA7 for <[e-mail]>; Mon,  9 Sep 2002 16:28:37 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA06255; Mon, 9 Sep 2002 16:28:33 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA23641; Mon, 9 Sep 2002 16:28:34 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QQM0R>; Mon, 9 Sep 2002 16:28:33 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Jeffrey Haas <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, "'Natale, Jonathan'" <[e-mail]>, "'Mathew Richardson'" <[e-mail]>, [e-mail]
Subject: RE: Proxy: comments on section 9.1.3 
Date: Mon, 9 Sep 2002 16:28:32 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Curtis:
  I like simple things, I would prefer if you can condense this page long
description involving everything to a single sentence and tell us what it
is.

Thanks in advance,
Ben

> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Monday, September 09, 2002 4:23 PM
> To: Jeffrey Haas
> Cc: Abarbanel, Benjamin; 'Natale, Jonathan'; 'Mathew Richardson';
> [e-mail]
> Subject: Re: Proxy: comments on section 9.1.3 
> 
> 
> 
> In message <[e-mail]>, Jeffrey Haas writes:
> > IMHO:
> > A prefix implies a prefix and its associated prefix length.
> > A destination implies an associated nexthop.
> > A route is a destination for a particular protocol.  A route
> > may have additional properties that are protocol specific.
> > 
> > The base bgp document (sec 3.1) has always had the 
> unfortunate wording
> > implying that a route is a path attribute set and multiple NLRI.
> > 
> > On Fri, Sep 06, 2002 at 11:26:15AM -0400, Abarbanel, Benjamin wrote:
> > > A route is not a route, unless you have a Next Hop 
> address. How can 
> > > you get from point A to point B without a (Next Hop) 
> delivary router?
> > > 
> > > IMHO, 
> > > Ben
> > 
> > -- 
> > Jeff Haas 
> > NextHop Technologies
> 
> 
> Jeff,
> 
> I know that you know what you are talking about but maybe some on this
> thread are on thinner ice.
> 
> It was confusion over terminology that gave us some of the goofy
> acronyms (NRLI and LIS come to mind) that could be better served by
> clearly defining the common terms.
> 
> For the purpose of discussion we could use the following.  If we
> really have to (someone insists on it) we could put something like
> this in the document.
> 
>   An IP address is a 32 bit quantitiy for IPv6, the full 128 bit
>   address for IPv6.  Shorthand notations exist which may omit some
>   zero bytes.
> 
>   An IP Prefix includes both an address and a prefix length.  Bits
>   beyond the prefix length are not part of the prefix.  A common
>   notation for IP interfaces on broadcase or NBMA media lists the full
>   (32 bit significant) IP address of the interface and the prefix
>   length of the network.  This is just a shorthand notation providing
>   two peices of information, and is made possible because a correctly
>   configured numbered IP interface falls within the the prefix of
>   network to which the interface is attached (or one of the prefixes
>   if multiple the network has multiple prefixes, such as occurs during
>   renumebering).
> 
>   A route in the RIB consists of an IP prefix and the information
>   needed for forwarding.  The RIB provides a mapping in which the IP
>   prefix is the key or index field for the mapping.  In the case of
>   BGP the forwarding information would be the next hop.  In the case
>   of MPLS an MPLS label stack might serve this purpose.  A route is
>   considered unique if the prefixes match.  For the purpose of
>   discussing BGP, the case of multipath or QoS enabled route can be
>   considered to be one route formed from more than one source with
>   more complex forwarding information, such as more than one next hop
>   for a multipath route and possibly additional information such as
>   load balancing ratios or association between other qualifiers (such
>   as DHCP) and forwarding information.
> 
> In BGP-speak prefix == NRLI and prefix is the key field for a route
> (unique routes don't have the same key).  Multipath and QoS might be
> interesting (note I said might and I don't want to debate that here)
> but is outside of the scope of the BGP protocol spec and is only
> mentioned to avoid confusion that could arise from terminology that
> didn't account for multipath, and other route qualifiers.
> 
> I think I covered this accurately and completely enough.  Maybe we
> should put something in the document.  I don't care much if we use
> NRLI or prefix as the key when defining what a route is.  NRLI leaves
> open use of BGP for non-IP purposes.
> 
> Curtis
> 
> ps - I hope this shed some light rather than just added noise.
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA17665 for <[e-mail]>; Mon, 9 Sep 2002 16:26:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1AC029126A; Mon,  9 Sep 2002 16:26:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DEAB19126B; Mon,  9 Sep 2002 16:26:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EEF5C9126A for <[e-mail]>; Mon,  9 Sep 2002 16:26:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CB6D85DFA3; Mon,  9 Sep 2002 16:26:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 14DBF5DEB9 for <[e-mail]>; Mon,  9 Sep 2002 16:26:04 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA05660; Mon, 9 Sep 2002 16:18:37 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA21923; Mon, 9 Sep 2002 16:18:38 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QQMSQ>; Mon, 9 Sep 2002 16:18:37 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Mathew Richardson'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Michael C. Cambria'" <[e-mail]>, [e-mail]
Subject: RE: Review: Section 2, TCP Port 179
Date: Mon, 9 Sep 2002 16:18:35 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> >
> >  This issue with the recieve on port 179 and transmit from 
> port X for BGP 
> >goes back to the Client-Server model in TCP. If you look at 
> Stevens book, a
> >Server should not transmit from a well known port it is 
> trying to establish
> >many sessions on with its clients.  Therefore, the 
> assumption in the BGP
> >spec is that it must be a unique number for each BGP peer 
> the current peer
> >has a session with.
> 
> <snip>
> 
> I don't believe that this assumption is present in the spec, and I
> don't think we want to add it.  It should be sufficient to note that
> BGP listens for TCP connections on port 179, and the set of ports
> from which BGP initiates TCP connections is a local matter.
> 

That is fine by me. I only mentioned it, because all implementations
must know this fact or BGP wont work.

Its amazing what a couple of words can accomplish in a document.

Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA16883 for <[e-mail]>; Mon, 9 Sep 2002 16:01:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9C2D291269; Mon,  9 Sep 2002 16:00:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3BEC09126A; Mon,  9 Sep 2002 16:00:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 067B491269 for <[e-mail]>; Mon,  9 Sep 2002 16:00:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 565145DDB8; Mon,  9 Sep 2002 16:00:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 6131A5DDB5 for <[e-mail]>; Mon,  9 Sep 2002 16:00:14 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g89K07D99420; Mon, 9 Sep 2002 16:00:07 -0400 (EDT) (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 g89K04G99413; Mon, 9 Sep 2002 16:00:04 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g89K04M17583; Mon, 9 Sep 2002 16:00:04 -0400 (EDT)
Date: Mon, 9 Sep 2002 16:00:04 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: admin dist/gp spec proposal
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, Sep 09, 2002 at 02:45:11PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Sep 09, 2002 at 02:45:11PM -0400, Abarbanel, Benjamin wrote:
> The only thing I want to add about the definition of the BGP Identifier, if 
> we choose to keep it separate from the Router-ID, is that its value should
> be
> a routable/reachable IP address in the network where BGP operates.

Two comments:
1. If its v6 only, there may be no v4 address to reach.
2. While it is a *nicety* that we can use the identifier in the one
   place it shows up globally (aggregator) to determine what router
   did the work, the only requirement is that it be a valid BGP Identifier
   for purposes of dealing with loop detection and route selection.

However, if its going to be ipv4, it doesn't hurt to recommend that it
have a real IP address.  Note that it might very well be a rfc1918 
address.

> Ben

-- 
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 PAA15255 for <[e-mail]>; Mon, 9 Sep 2002 15:09:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 110A691267; Mon,  9 Sep 2002 15:09:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0E5391268; Mon,  9 Sep 2002 15:08:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E950E91267 for <[e-mail]>; Mon,  9 Sep 2002 15:08:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C8EDE5DE72; Mon,  9 Sep 2002 15:08:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 51E835DDB5 for <[e-mail]>; Mon,  9 Sep 2002 15:08:58 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA00109; Mon, 9 Sep 2002 15:08:55 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA05259; Mon, 9 Sep 2002 15:08:57 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QQ2S2>; Mon, 9 Sep 2002 15:08:56 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Michael C. Cambria'" <[e-mail]>, [e-mail]
Subject: RE: Review: Section 2, TCP Port 179
Date: Mon, 9 Sep 2002 15:08:56 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Michael:

  This issue with the recieve on port 179 and transmit from port X for BGP 
goes back to the Client-Server model in TCP. If you look at Stevens book, a
Server should not transmit from a well known port it is trying to establish
many sessions on with its clients.  Therefore, the assumption in the BGP
spec is that it must be a unique number for each BGP peer the current peer
has a session with.

Ben


> -----Original Message-----
> From: Michael C. Cambria [mailto:[e-mail]]
> Sent: Monday, September 09, 2002 2:39 PM
> To: [e-mail]
> Subject: Re: Review: Section 2, TCP Port 179
> 
> 
> 
> 
> [e-mail] wrote:
> > Ok, so we have two options:
> > 
> > "BGP listens on TCP port 179."
> > 
> > Which leaves the transmit port undefined. Or:
> > 
> > "BGP listens on TCP port 179 and transmits from an 
> implemetation-dependent
> > port."
> > 
> > Thinking of a new operational network engineer reading the 
> spec, the latter
> > seems more clear.  What do you think as an implementor?
> 
> As an implementor, I'd just want to know what was legal.
> 
> Thus, with the suggested changes, if I picked 179 to transmit on, and 
> the peer had a stack that didn't implement the TCP simultaneous open 
> properly, it will be unambigous as to which was not complient.
> 
> MikeC
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA14714 for <[e-mail]>; Mon, 9 Sep 2002 14:55:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EE3CD91266; Mon,  9 Sep 2002 14:55:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9E4C91267; Mon,  9 Sep 2002 14:54:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D58F91266 for <[e-mail]>; Mon,  9 Sep 2002 14:54:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7920E5DDD3; Mon,  9 Sep 2002 14:54:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id F15A65DDB5 for <[e-mail]>; Mon,  9 Sep 2002 14:54:57 -0400 (EDT)
Received: from fid4.com (mcambria3.avayactc.com [199.93.239.107]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g89Iqtuo002082 for <[e-mail]>; Mon, 9 Sep 2002 14:52:55 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Mon, 09 Sep 2002 14:39:16 -0400
From: "Michael C. Cambria" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020819
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Review: Section 2, TCP Port 179
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

[e-mail] wrote:
> Ok, so we have two options:
> 
> "BGP listens on TCP port 179."
> 
> Which leaves the transmit port undefined. Or:
> 
> "BGP listens on TCP port 179 and transmits from an implemetation-dependent
> port."
> 
> Thinking of a new operational network engineer reading the spec, the latter
> seems more clear.  What do you think as an implementor?

As an implementor, I'd just want to know what was legal.

Thus, with the suggested changes, if I picked 179 to transmit on, and 
the peer had a stack that didn't implement the TCP simultaneous open 
properly, it will be unambigous as to which was not complient.

MikeC



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA14675 for <[e-mail]>; Mon, 9 Sep 2002 14:54:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BA8E49125C; Mon,  9 Sep 2002 14:53:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C0F491266; Mon,  9 Sep 2002 14:53:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 363A29125C for <[e-mail]>; Mon,  9 Sep 2002 14:53:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0F0445DE38; Mon,  9 Sep 2002 14:53:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id A42B35DDB5 for <[e-mail]>; Mon,  9 Sep 2002 14:53:51 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id LAA19627; Mon, 9 Sep 2002 11:50:46 -0700 (PDT)
Date: Mon, 9 Sep 2002 11:50:46 -0700
From: [e-mail]
To: Yakov Rekhter <[e-mail]>
Cc: Manav Bhatia <[e-mail]>, "Natale, Jonathan" <[e-mail]>, "'Abarbanel, Benjamin'" <[e-mail]>, [e-mail]
Subject: Re: admin dist/gp spec proposal
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, Sep 09, 2002 at 11:49:38AM -0700
Sender: [e-mail]
Precedence: bulk

Ah, sorry Yakov, I hadn't gotten to that thread in my mail yet.  Ok,
out-of-scope for the Base Spec., we'll save it for later.

Andrew

On Mon, Sep 09, 2002 at 11:49:38AM -0700, Yakov Rekhter wrote:
> To: [e-mail]
> cc: Manav Bhatia <[e-mail]>, Yakov Rekhter <[e-mail]>,
>    "Natale, Jonathan" <[e-mail]>,
>    "'Abarbanel,
>     Benjamin'" <[e-mail]>, [e-mail]
> Subject: Re: admin dist/gp spec proposal 
> In-Reply-To: Your message of "Mon, 09 Sep 2002 11:36:39 PDT."
>              <[e-mail]> 
> Date: Mon, 09 Sep 2002 11:49:38 -0700
> From: Yakov Rekhter <[e-mail]>
> 
> Andrew,
> 
> > So, how about this text as a middle ground:
> > 
> > BGP Identifier:
> > 
> >          This 4-octet unsigned integer indicates the BGP Identifier of
> >          the sender. A given BGP speaker sets the value of its BGP
> >          Identifier to an IP address assigned to that BGP speaker.  The
> >          value of the BGP Identifier is determined on startup and is the
> >          same for every local interface and every BGP peer.  BGP Identifier
> >          is analogous to the Router ID field present in ISIS or OSPF.  
> >          BGP Identifier and Router ID SHOULD be the same.
> 
> Please read the attached.
> 
> Yakov.
> ------------------------------------------------------------------
> Date:    Fri, 06 Sep 2002 12:59:07 PDT
> To:      [e-mail]
> From:    Yakov Rekhter <[e-mail]>
> Subject: BGP base spec
> 
> Folks,
> 
> The spec is *limited* to BGP protocol. It does *NOT* include
> interaction between BGP and other protocols (e.g., OSPF, ISIS,
> RIP). Therefore such issues as relation between BGP Identifier and
> OSPF Router ID, redistribution of routing information between BGP
> and any other protocol, route selection in the presence of multiple
> protocols, etc... are outside the scope of this spec.  Please keep
> this in mind when sending your comments on the base spec.
> 
> 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 OAA14626 for <[e-mail]>; Mon, 9 Sep 2002 14:52:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2E71D91265; Mon,  9 Sep 2002 14:50:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFD2891266; Mon,  9 Sep 2002 14:50:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 10AE191265 for <[e-mail]>; Mon,  9 Sep 2002 14:50:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F04585DDD3; Mon,  9 Sep 2002 14:50:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 9414D5DDB5 for <[e-mail]>; Mon,  9 Sep 2002 14:50:13 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g89Incm84992; Mon, 9 Sep 2002 11:49:38 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: Manav Bhatia <[e-mail]>, Yakov Rekhter <[e-mail]>, "Natale, Jonathan" <[e-mail]>, "'Abarbanel,     Benjamin'" <[e-mail]>, [e-mail]
Subject: Re: admin dist/gp spec proposal 
In-Reply-To: Your message of "Mon, 09 Sep 2002 11:36:39 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 09 Sep 2002 11:49:38 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Andrew,

> So, how about this text as a middle ground:
> 
> BGP Identifier:
> 
>          This 4-octet unsigned integer indicates the BGP Identifier of
>          the sender. A given BGP speaker sets the value of its BGP
>          Identifier to an IP address assigned to that BGP speaker.  The
>          value of the BGP Identifier is determined on startup and is the
>          same for every local interface and every BGP peer.  BGP Identifier
>          is analogous to the Router ID field present in ISIS or OSPF.  
>          BGP Identifier and Router ID SHOULD be the same.

Please read the attached.

Yakov.
------------------------------------------------------------------
Date:    Fri, 06 Sep 2002 12:59:07 PDT
To:      [e-mail]
From:    Yakov Rekhter <[e-mail]>
Subject: BGP base spec

Folks,

The spec is *limited* to BGP protocol. It does *NOT* include
interaction between BGP and other protocols (e.g., OSPF, ISIS,
RIP). Therefore such issues as relation between BGP Identifier and
OSPF Router ID, redistribution of routing information between BGP
and any other protocol, route selection in the presence of multiple
protocols, etc... are outside the scope of this spec.  Please keep
this in mind when sending your comments on the base spec.

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 OAA14449 for <[e-mail]>; Mon, 9 Sep 2002 14:46:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CA58791263; Mon,  9 Sep 2002 14:45:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C16091264; Mon,  9 Sep 2002 14:45:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7AA6991263 for <[e-mail]>; Mon,  9 Sep 2002 14:45:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9356B5DE38; Mon,  9 Sep 2002 14:45:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id D82C55DDB5 for <[e-mail]>; Mon,  9 Sep 2002 14:45:14 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA28485; Mon, 9 Sep 2002 14:45:11 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA00129; Mon, 9 Sep 2002 14:45:13 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QQHKR>; Mon, 9 Sep 2002 14:45:12 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Manav Bhatia <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, "Natale, Jonathan" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal
Date: Mon, 9 Sep 2002 14:45:11 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

The only thing I want to add about the definition of the BGP Identifier, if 
we choose to keep it separate from the Router-ID, is that its value should
be
a routable/reachable IP address in the network where BGP operates.

Ben
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Monday, September 09, 2002 2:37 PM
> To: Manav Bhatia
> Cc: Yakov Rekhter; Natale, Jonathan; 'Abarbanel, Benjamin';
> [e-mail]
> Subject: Re: admin dist/gp spec proposal
> 
> 
> So, how about this text as a middle ground:
> 
> BGP Identifier:
> 
>          This 4-octet unsigned integer indicates the BGP Identifier of
>          the sender. A given BGP speaker sets the value of its BGP
>          Identifier to an IP address assigned to that BGP 
> speaker.  The
>          value of the BGP Identifier is determined on startup 
> and is the
>          same for every local interface and every BGP peer.  
> BGP Identifier
>          is analogous to the Router ID field present in ISIS 
> or OSPF.  
>          BGP Identifier and Router ID SHOULD be the same.
> 
> Andrew
> 
> On Mon, Sep 09, 2002 at 01:30:24PM +0530, Manav Bhatia wrote:
> > Delivered-To: [e-mail]
> > Delivered-To: [e-mail]
> > Delivered-To: [e-mail]
> > Date: Mon, 09 Sep 2002 13:30:24 +0530
> > From: Manav Bhatia <[e-mail]>
> > Subject: Re: admin dist/gp spec proposal
> > To: Yakov Rekhter <[e-mail]>,
> >    "Natale, Jonathan" <[e-mail]>
> > Cc: "'Abarbanel, Benjamin'" 
> <[e-mail]>, [e-mail]
> > Reply-To: Manav Bhatia <[e-mail]>
> > X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
> > X-Mailer: Microsoft Outlook Express 6.00.2600.0000
> > X-Priority: 3
> > X-MSMail-priority: Normal
> > Precedence: bulk
> > X-OriginalArrivalTime: 09 Sep 2002 08:03:27.0102 (UTC) 
> FILETIME=[60A841E0:01C257D7]
> > 
> > Yakov and others,
> > draft-ietf-isis-traffic-04.txt states that if some router 
> advertises the
> > router ID TLV (containing the 4-octet router ID of the 
> router originating
> > the LSP) in its LSP, and if it also advertises BGP routes 
> with the BGP next
> > hop set to the BGP router ID (which is what is usually 
> done), then in such
> > cases, the TE router ID should match the BGP router ID.
> > 
> > I think this warrants the need to mention that the BGP 
> Router ID *should*
> > match the Router ID as used by the other routing protocols. 
> Moreover i dont
> > see any need for the router IDs to *not* match for the BGP 
> and IGPs and i
> > am sure that there will not be any operators assigning 
> different Router IDs
> > for the same.
> > 
> > Or am i missing something here?
> > 
> > Manav
> > 
> > ----- Original Message -----
> > From: "Yakov Rekhter" <[e-mail]>
> > To: "Natale, Jonathan" <[e-mail]>
> > Cc: "'Abarbanel, Benjamin'" <[e-mail]>;
> > <[e-mail]>
> > Sent: Saturday, September 07, 2002 1:13 AM
> > Subject: Re: admin dist/gp spec proposal
> > 
> > 
> > | Natale,
> > |
> > | > 1745 and 1403 are historic
> > |
> > | correct. And with this in mind I would suggest we stop 
> reference/pointing
> > | to them.
> > |
> > | Yakov.
> > |
> > | > -----Original Message-----
> > | > From: Abarbanel, Benjamin 
> [mailto:[e-mail]]
> > | > Sent: Friday, September 06, 2002 3:38 PM
> > | > To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Yakov Rekhter'
> > | > Cc: [e-mail]
> > | > Subject: RE: admin dist/gp spec proposal
> > | >
> > | >
> > | >
> > | > >
> > | > > Not that I am aware of.  There certainly is a case where they
> > | > > must be the
> > | > > same (cisco bgp w/ ospf, don't know all the details of
> > | > > how/why).
> > | >
> > | > RFC1745, and RFC1403 tell you why they must be the same.
> > | >
> > | > > Maybe the local admin method of numbering is more versatile by
> > allowing
> > | > > them to be different.  I think they should MUST be 
> the same and in
> > some
> > | > > implementation they are (gated, bay).
> > | > >
> > | > > -----Original Message-----
> > | > > From: Abarbanel, Benjamin 
> [mailto:[e-mail]]
> > | > > Sent: Friday, September 06, 2002 3:29 PM
> > | > > To: 'Yakov Rekhter'; Abarbanel, Benjamin
> > | > > Cc: Natale, Jonathan; [e-mail]
> > | > > Subject: RE: admin dist/gp spec proposal
> > | > >
> > | > >
> > | > > >
> > | > > > > I would like to rephrase my statement on one sentence.
> > | > > > >
> > | > > > > " BTW. BGP Identifier is a vague way of naming 
> what we know as
> > the
> > | > > > >   Router-ID in all other IP related protocols."
> > | > > >
> > | > > > This is *technically* incorrect.
> > | > > >
> > | > > Is there a case where the BGP Identifier, should or must be
> > | > > different than
> > | > > the Router-ID for the routing system to work correctly?
> > | > >
> > | > > Ben
> > | > >
> > | > >
> > | > > >
> > | > > > >
> > | > > > >
> > | > > > > > -----Original Message-----
> > | > > > > > From: Abarbanel, Benjamin
> > | > > [mailto:[e-mail]]
> > | > > > > > Sent: Friday, September 06, 2002 3:01 PM
> > | > > > > > To: 'Yakov Rekhter'; Natale, Jonathan
> > | > > > > > Cc: [e-mail]
> > | > > > > > Subject: RE: admin dist/gp spec proposal
> > | > > > > >
> > | > > > > >
> > | > > > > > Yakov:
> > | > > > > >   There is no reference to RFC1812 in the 
> reference section
> > | > > > > > nor references
> > | > > > > > to this spec where appropriate in the BGP relevant
> > | > > > > > discussions. As was
> > | > > > > > earlier mentioned. At least we need to tie the thread
> > | > > > between the two
> > | > > > > > specs so people know what the assumptions are.
> > | > > > > >
> > | > > > > > BTW. BGP Identifier is a very misleading way of 
> naming what
> > | > > > > > we know as the
> > | > > > > > Router ID in all other protocols. I would like 
> to suggest we
> > | > > > > > enhance its
> > | > > > > > description as follows:
> > | > > > > >
> > | > > > > > Current statement:
> > | > > > > > ==================
> > | > > > > > "BGP Identifier:
> > | > > > > >
> > | > > > >          This 4-octet unsigned integer indicates the BGP
> > | > > > Identifier of
> > | > > > > >          the sender. A given BGP speaker sets the value
> > | > > of its BGP
> > | > > > > >          Identifier to an IP address assigned 
> to that BGP
> > | > > > > > speaker.  The
> > | > > > > >          value of the BGP Identifier is 
> determined on startup
> > | > > > > > and is the
> > | > > > > >          same for every local interface and 
> every BGP peer. "
> > | > > > > >
> > | > > > > > New Statement:
> > | > > > > > ==============
> > | > > > > > "BGP Identifier:
> > | > > > > >
> > | > > > > >          This 4-octet unsigned integer indicates the BGP
> > | > > > Identifier of
> > | > > > > >          the sender. A given BGP speaker sets the value
> > | > > of its BGP
> > | > > > > >          Identifier also known as the 
> Router-ID, to an IP
> > | > > > > > address assigned
> > | > > > > >          to that BGP speaker. The value of the BGP
> > | > > Identifier is
> > | > > > > >          determined on startup and is the same for every
> > | > > > > > local interface
> > | > > > > >          and every BGP peer and other IP 
> related protocols.
> > | > > > > > See [x],[y] for
> > | > > > > >          more details on Router-ID useage 
> between BGP and
> > | > > > > > other protocols."
> > | > > > > >
> > | > > > > > Where x = RFC1403,
> > | > > > > >       y = RFC1745
> > | > > > > >
> > | > > > > > Ben
> > | > > > > > > -----Original Message-----
> > | > > > > > > From: Yakov Rekhter [mailto:[e-mail]]
> > | > > > > > > Sent: Friday, September 06, 2002 2:31 PM
> > | > > > > > > To: Natale, Jonathan
> > | > > > > > > Cc: [e-mail]
> > | > > > > > > Subject: Re: admin dist/gp spec proposal
> > | > > > > > >
> > | > > > > > >
> > | > > > > > > Natale,
> > | > > > > > >
> > | > > > > > > >
> > | > > > > > > >
> > | > > > > > > > -----Original Message-----
> > | > > > > > > > From: Abarbanel, Benjamin
> > | > > > [mailto:[e-mail]]
> > | > > > > > > > Sent: Friday, September 06, 2002 1:49 PM
> > | > > > > > > > To: 'Natale, Jonathan'
> > | > > > > > > > Subject: RE: admin dist/gp spec proposal
> > | > > > > > > >
> > | > > > > > > > Jonathan:
> > | > > > > > > > Forward this message to the IDR list. I think we
> > | > > dropped off.
> > | > > > > > > >
> > | > > > > > > > Ben
> > | > > > > > > >
> > | > > > > > > > > -----Original Message-----
> > | > > > > > > > > From: Natale, Jonathan 
[mailto:[e-mail]]
> | > > > > > > > > Sent: Friday, September 06, 2002 1:46 PM
> | > > > > > > > > To: 'Abarbanel, Benjamin'
> | > > > > > > > > Subject: RE: admin dist/gp spec proposal
> | > > > > > > > >
> | > > > > > > > >
> | > > > > > > > > I agree.  The default values of the various
> | > > > protocols as they
> | > > > > > > > > are currently
> | > > > > > > > > implemented make sense:
> | > > > > > > > > Connected
> | > > > > > > > > Static
> | > > > > > > > > Ebgp
> | > > > > > > > > Igp's
> | > > > > > > > > Ibgp
> | > > > > > > > >
> | > > > > > > > > ...they should be documented in 1812 ideally, but
> | > > > putting it
> | > > > > > > > > in 1771 would
> | > > > > > > > > not hurt.  Added a phrase to indicate that they
> | > > may be user
> | > > > > > > > > configurable is
> | > > > > > > > > good too.
> | > > > > > >
> | > > > > > > Perhaps it is time to update 1812. But let's not use BGP
> | > > > > > > spec as a replacement for updating 1812 - it is not.
> | > > > > > >
> | > > > > > > Yakov.
> | > > > > > >
> | > > > > > > > >
> | > > > > > > > > -----Original Message-----
> | > > > > > > > > From: Abarbanel, Benjamin
> | > > > > [mailto:[e-mail]]
> | > > > > > > > Sent: Friday, September 06, 2002 11:39 AM
> | > > > > > > > To: 'Mathew Richardson'; Natale, Jonathan
> | > > > > > > > Cc: [e-mail]
> | > > > > > > > Subject: RE: admin dist/gp spec proposal
> | > > > > > > >
> | > >
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA14326 for <[e-mail]>; Mon, 9 Sep 2002 14:44:30 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6CD7391262; Mon,  9 Sep 2002 14:44:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3276C91263; Mon,  9 Sep 2002 14:44:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4CEB791262 for <[e-mail]>; Mon,  9 Sep 2002 14:44:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3A2065DDB5; Mon,  9 Sep 2002 14:44:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id A4C865DE47 for <[e-mail]>; Mon,  9 Sep 2002 14:44:04 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id LAA19488; Mon, 9 Sep 2002 11:41:09 -0700 (PDT)
Date: Mon, 9 Sep 2002 11:41:09 -0700
From: [e-mail]
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Review: Section 2, TCP Port 179
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
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Sep 09, 2002 at 02:36:53PM -0400
Sender: [e-mail]
Precedence: bulk

Ok, so we have two options:

"BGP listens on TCP port 179."

Which leaves the transmit port undefined. Or:

"BGP listens on TCP port 179 and transmits from an implemetation-dependent
port."

Thinking of a new operational network engineer reading the spec, the latter
seems more clear.  What do you think as an implementor?

Andrew

> On Mon, Sep 09, 2002 at 11:29:15AM -0700, [e-mail] wrote:
> > It would be simple enough to change the text to "BGP listens on TCP
> > port 179, and transmits from an implementation-dependant port above
> > 1024."
> > 
> > Do you think that would help clear things up?
> 
> I would just document the listening port.  The convention of stuff > 1024
> usually applies to end-hosts.
> 
> > 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 OAA14212 for <[e-mail]>; Mon, 9 Sep 2002 14:40:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CAF3E91261; Mon,  9 Sep 2002 14:39:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47E4B91262; Mon,  9 Sep 2002 14:39:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6BE291261 for <[e-mail]>; Mon,  9 Sep 2002 14:39:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C12985DDD2; Mon,  9 Sep 2002 14:39:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 6658C5DDB5 for <[e-mail]>; Mon,  9 Sep 2002 14:39:50 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id LAA19423; Mon, 9 Sep 2002 11:36:39 -0700 (PDT)
Date: Mon, 9 Sep 2002 11:36:39 -0700
From: [e-mail]
To: Manav Bhatia <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, "Natale, Jonathan" <[e-mail]>, "'Abarbanel, Benjamin'" <[e-mail]>, [e-mail]
Subject: Re: admin dist/gp spec proposal
Message-ID: <[e-mail]>
References: <[e-mail]> <028201c257d6$f5142070$[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: <028201c257d6$f5142070$[e-mail]>; from [e-mail] on Mon, Sep 09, 2002 at 01:30:24PM +0530
Sender: [e-mail]
Precedence: bulk

So, how about this text as a middle ground:

BGP Identifier:

         This 4-octet unsigned integer indicates the BGP Identifier of
         the sender. A given BGP speaker sets the value of its BGP
         Identifier to an IP address assigned to that BGP speaker.  The
         value of the BGP Identifier is determined on startup and is the
         same for every local interface and every BGP peer.  BGP Identifier
         is analogous to the Router ID field present in ISIS or OSPF.  
         BGP Identifier and Router ID SHOULD be the same.

Andrew

On Mon, Sep 09, 2002 at 01:30:24PM +0530, Manav Bhatia wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Date: Mon, 09 Sep 2002 13:30:24 +0530
> From: Manav Bhatia <[e-mail]>
> Subject: Re: admin dist/gp spec proposal
> To: Yakov Rekhter <[e-mail]>,
>    "Natale, Jonathan" <[e-mail]>
> Cc: "'Abarbanel, Benjamin'" <[e-mail]>, [e-mail]
> Reply-To: Manav Bhatia <[e-mail]>
> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
> X-Mailer: Microsoft Outlook Express 6.00.2600.0000
> X-Priority: 3
> X-MSMail-priority: Normal
> Precedence: bulk
> X-OriginalArrivalTime: 09 Sep 2002 08:03:27.0102 (UTC) FILETIME=[60A841E0:01C257D7]
> 
> Yakov and others,
> draft-ietf-isis-traffic-04.txt states that if some router advertises the
> router ID TLV (containing the 4-octet router ID of the router originating
> the LSP) in its LSP, and if it also advertises BGP routes with the BGP next
> hop set to the BGP router ID (which is what is usually done), then in such
> cases, the TE router ID should match the BGP router ID.
> 
> I think this warrants the need to mention that the BGP Router ID *should*
> match the Router ID as used by the other routing protocols. Moreover i dont
> see any need for the router IDs to *not* match for the BGP and IGPs and i
> am sure that there will not be any operators assigning different Router IDs
> for the same.
> 
> Or am i missing something here?
> 
> Manav
> 
> ----- Original Message -----
> From: "Yakov Rekhter" <[e-mail]>
> To: "Natale, Jonathan" <[e-mail]>
> Cc: "'Abarbanel, Benjamin'" <[e-mail]>;
> <[e-mail]>
> Sent: Saturday, September 07, 2002 1:13 AM
> Subject: Re: admin dist/gp spec proposal
> 
> 
> | Natale,
> |
> | > 1745 and 1403 are historic
> |
> | correct. And with this in mind I would suggest we stop reference/pointing
> | to them.
> |
> | Yakov.
> |
> | > -----Original Message-----
> | > From: Abarbanel, Benjamin [mailto:[e-mail]]
> | > Sent: Friday, September 06, 2002 3:38 PM
> | > To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Yakov Rekhter'
> | > Cc: [e-mail]
> | > Subject: RE: admin dist/gp spec proposal
> | >
> | >
> | >
> | > >
> | > > Not that I am aware of.  There certainly is a case where they
> | > > must be the
> | > > same (cisco bgp w/ ospf, don't know all the details of
> | > > how/why).
> | >
> | > RFC1745, and RFC1403 tell you why they must be the same.
> | >
> | > > Maybe the local admin method of numbering is more versatile by
> allowing
> | > > them to be different.  I think they should MUST be the same and in
> some
> | > > implementation they are (gated, bay).
> | > >
> | > > -----Original Message-----
> | > > From: Abarbanel, Benjamin [mailto:[e-mail]]
> | > > Sent: Friday, September 06, 2002 3:29 PM
> | > > To: 'Yakov Rekhter'; Abarbanel, Benjamin
> | > > Cc: Natale, Jonathan; [e-mail]
> | > > Subject: RE: admin dist/gp spec proposal
> | > >
> | > >
> | > > >
> | > > > > I would like to rephrase my statement on one sentence.
> | > > > >
> | > > > > " BTW. BGP Identifier is a vague way of naming what we know as
> the
> | > > > >   Router-ID in all other IP related protocols."
> | > > >
> | > > > This is *technically* incorrect.
> | > > >
> | > > Is there a case where the BGP Identifier, should or must be
> | > > different than
> | > > the Router-ID for the routing system to work correctly?
> | > >
> | > > Ben
> | > >
> | > >
> | > > >
> | > > > >
> | > > > >
> | > > > > > -----Original Message-----
> | > > > > > From: Abarbanel, Benjamin
> | > > [mailto:[e-mail]]
> | > > > > > Sent: Friday, September 06, 2002 3:01 PM
> | > > > > > To: 'Yakov Rekhter'; Natale, Jonathan
> | > > > > > Cc: [e-mail]
> | > > > > > Subject: RE: admin dist/gp spec proposal
> | > > > > >
> | > > > > >
> | > > > > > Yakov:
> | > > > > >   There is no reference to RFC1812 in the reference section
> | > > > > > nor references
> | > > > > > to this spec where appropriate in the BGP relevant
> | > > > > > discussions. As was
> | > > > > > earlier mentioned. At least we need to tie the thread
> | > > > between the two
> | > > > > > specs so people know what the assumptions are.
> | > > > > >
> | > > > > > BTW. BGP Identifier is a very misleading way of naming what
> | > > > > > we know as the
> | > > > > > Router ID in all other protocols. I would like to suggest we
> | > > > > > enhance its
> | > > > > > description as follows:
> | > > > > >
> | > > > > > Current statement:
> | > > > > > ==================
> | > > > > > "BGP Identifier:
> | > > > > >
> | > > > >          This 4-octet unsigned integer indicates the BGP
> | > > > Identifier of
> | > > > > >          the sender. A given BGP speaker sets the value
> | > > of its BGP
> | > > > > >          Identifier to an IP address assigned to that BGP
> | > > > > > speaker.  The
> | > > > > >          value of the BGP Identifier is determined on startup
> | > > > > > and is the
> | > > > > >          same for every local interface and every BGP peer. "
> | > > > > >
> | > > > > > New Statement:
> | > > > > > ==============
> | > > > > > "BGP Identifier:
> | > > > > >
> | > > > > >          This 4-octet unsigned integer indicates the BGP
> | > > > Identifier of
> | > > > > >          the sender. A given BGP speaker sets the value
> | > > of its BGP
> | > > > > >          Identifier also known as the Router-ID, to an IP
> | > > > > > address assigned
> | > > > > >          to that BGP speaker. The value of the BGP
> | > > Identifier is
> | > > > > >          determined on startup and is the same for every
> | > > > > > local interface
> | > > > > >          and every BGP peer and other IP related protocols.
> | > > > > > See [x],[y] for
> | > > > > >          more details on Router-ID useage between BGP and
> | > > > > > other protocols."
> | > > > > >
> | > > > > > Where x = RFC1403,
> | > > > > >       y = RFC1745
> | > > > > >
> | > > > > > Ben
> | > > > > > > -----Original Message-----
> | > > > > > > From: Yakov Rekhter [mailto:[e-mail]]
> | > > > > > > Sent: Friday, September 06, 2002 2:31 PM
> | > > > > > > To: Natale, Jonathan
> | > > > > > > Cc: [e-mail]
> | > > > > > > Subject: Re: admin dist/gp spec proposal
> | > > > > > >
> | > > > > > >
> | > > > > > > Natale,
> | > > > > > >
> | > > > > > > >
> | > > > > > > >
> | > > > > > > > -----Original Message-----
> | > > > > > > > From: Abarbanel, Benjamin
> | > > > [mailto:[e-mail]]
> | > > > > > > > Sent: Friday, September 06, 2002 1:49 PM
> | > > > > > > > To: 'Natale, Jonathan'
> | > > > > > > > Subject: RE: admin dist/gp spec proposal
> | > > > > > > >
> | > > > > > > > Jonathan:
> | > > > > > > > Forward this message to the IDR list. I think we
> | > > dropped off.
> | > > > > > > >
> | > > > > > > > Ben
> | > > > > > > >
> | > > > > > > > > -----Original Message-----
> | > > > > > > > > From: Natale, Jonathan [mailto:[e-mail]]
> | > > > > > > > > Sent: Friday, September 06, 2002 1:46 PM
> | > > > > > > > > To: 'Abarbanel, Benjamin'
> | > > > > > > > > Subject: RE: admin dist/gp spec proposal
> | > > > > > > > >
> | > > > > > > > >
> | > > > > > > > > I agree.  The default values of the various
> | > > > protocols as they
> | > > > > > > > > are currently
> | > > > > > > > > implemented make sense:
> | > > > > > > > > Connected
> | > > > > > > > > Static
> | > > > > > > > > Ebgp
> | > > > > > > > > Igp's
> | > > > > > > > > Ibgp
> | > > > > > > > >
> | > > > > > > > > ...they should be documented in 1812 ideally, but
> | > > > putting it
> | > > > > > > > > in 1771 would
> | > > > > > > > > not hurt.  Added a phrase to indicate that they
> | > > may be user
> | > > > > > > > > configurable is
> | > > > > > > > > good too.
> | > > > > > >
> | > > > > > > Perhaps it is time to update 1812. But let's not use BGP
> | > > > > > > spec as a replacement for updating 1812 - it is not.
> | > > > > > >
> | > > > > > > Yakov.
> | > > > > > >
> | > > > > > > > >
> | > > > > > > > > -----Original Message-----
> | > > > > > > > > From: Abarbanel, Benjamin
> | > > > > [mailto:[e-mail]]
> | > > > > > > > Sent: Friday, September 06, 2002 11:39 AM
> | > > > > > > > To: 'Mathew Richardson'; Natale, Jonathan
> | > > > > > > > Cc: [e-mail]
> | > > > > > > > Subject: RE: admin dist/gp spec proposal
> | > > > > > > >
> | > >
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA14122 for <[e-mail]>; Mon, 9 Sep 2002 14:37:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9F73491260; Mon,  9 Sep 2002 14:37:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 671B091261; Mon,  9 Sep 2002 14:37:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6110791260 for <[e-mail]>; Mon,  9 Sep 2002 14:37:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4FC595DDD2; Mon,  9 Sep 2002 14:37:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 941D55DDB5 for <[e-mail]>; Mon,  9 Sep 2002 14:37:02 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g89Ib0c96216; Mon, 9 Sep 2002 14:37:00 -0400 (EDT) (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 g89IarG96190; Mon, 9 Sep 2002 14:36:53 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g89Iard16702; Mon, 9 Sep 2002 14:36:53 -0400 (EDT)
Date: Mon, 9 Sep 2002 14:36:53 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Review: Section 2, TCP Port 179
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, Sep 09, 2002 at 11:29:15AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Sep 09, 2002 at 11:29:15AM -0700, [e-mail] wrote:
> It would be simple enough to change the text to "BGP listens on TCP
> port 179, and transmits from an implementation-dependant port above
> 1024."
> 
> Do you think that would help clear things up?

I would just document the listening port.  The convention of stuff > 1024
usually applies to end-hosts.

> 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 OAA14035 for <[e-mail]>; Mon, 9 Sep 2002 14:34:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A9CFE9125F; Mon,  9 Sep 2002 14:34:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79A4C91260; Mon,  9 Sep 2002 14:34:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B3F8B9125F for <[e-mail]>; Mon,  9 Sep 2002 14:32:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9C2D75DE38; Mon,  9 Sep 2002 14:32:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 3E5D85DDD3 for <[e-mail]>; Mon,  9 Sep 2002 14:32:19 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id LAA19315; Mon, 9 Sep 2002 11:29:15 -0700 (PDT)
Date: Mon, 9 Sep 2002 11:29:15 -0700
From: [e-mail]
To: "Michael C. Cambria" <[e-mail]>
Cc: [e-mail]
Subject: Re: Review: Section 2, TCP Port 179
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 Sat, Sep 07, 2002 at 10:08:07AM -0400
Sender: [e-mail]
Precedence: bulk

It would be simple enough to change the text to "BGP listens on TCP
port 179, and transmits from an implementation-dependant port above
1024."

Do you think that would help clear things up?

Andrew

On Sat, Sep 07, 2002 at 10:08:07AM -0400, Michael C. Cambria wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Date: Sat, 07 Sep 2002 10:08:07 -0400
> From: "Michael C. Cambria" <[e-mail]>
> Organization: U n o r g a n i z e d
> User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020818
> X-Accept-Language: en-us, en
> To: [e-mail]
> Subject: Review: Section 2, TCP Port 179
> Precedence: bulk
> X-OriginalArrivalTime: 07 Sep 2002 14:12:54.0296 (UTC) FILETIME=[A8822180:01C25678]
> 
> 
> "BGP uses TCP port 179 for establishing its connections"
> 
>  From a first time reader point of view ....  does this mean both the 
> source and destination use port 179?
> 
> Intuition (and a quick look at /etc/services) should make it clear that 
> BGP listens on TCP port 179, but shouldn't the draft make clear what can 
> and cannot be used for the source port?
> 
> MikeC


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA11534 for <[e-mail]>; Mon, 9 Sep 2002 13:19:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3681D91253; Mon,  9 Sep 2002 13:18:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0452591254; Mon,  9 Sep 2002 13:18:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7F60E91253 for <[e-mail]>; Mon,  9 Sep 2002 13:18:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 64A7D5DDCB; Mon,  9 Sep 2002 13:18:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id CB0F05DDB5 for <[e-mail]>; Mon,  9 Sep 2002 13:18:43 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g89HIhm73147; Mon, 9 Sep 2002 10:18:43 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Working Group last call 
In-Reply-To: Your message of "Mon, 26 Aug 2002 14:12:28 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 09 Sep 2002 10:18:43 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

Please note that the comment period on the BGP FSM text (the one
proposed by Sue in her e-mail to this list on 8/26) ends today.

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 NAA10983 for <[e-mail]>; Mon, 9 Sep 2002 13:02:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9F30391250; Mon,  9 Sep 2002 12:59:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6653191251; Mon,  9 Sep 2002 12:59:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 14C4E91250 for <[e-mail]>; Mon,  9 Sep 2002 12:59:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F2C085DE47; Mon,  9 Sep 2002 12:59:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 427195DDB5 for <[e-mail]>; Mon,  9 Sep 2002 12:59:51 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g89Gxkh92173; Mon, 9 Sep 2002 12:59:47 -0400 (EDT) (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 g89GxiG92166; Mon, 9 Sep 2002 12:59:44 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g89Gxim15826; Mon, 9 Sep 2002 12:59:44 -0400 (EDT)
Date: Mon, 9 Sep 2002 12:59:44 -0400
From: Jeffrey Haas <[e-mail]>
To: Tom Petch <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP spec and IDR WG charter
Message-ID: <[e-mail]>
References: <000401c25820$97519860$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: <000401c25820$97519860$0301a8c0@tom3>; from [e-mail] on Mon, Sep 09, 2002 at 05:42:41PM +0100
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Its always best to just republish them - or excerpts from the archives.

In general, unless I see (in the case of the base draft) Yakov say
"I'll add this in", I assume it didn't get in.
And even then I check to see if it did. :-)

On Mon, Sep 09, 2002 at 05:42:41PM +0100, Tom Petch wrote:
> I have a very practical problem that some of the issues coming up now
> did come up nine months ago and did reach a rough consensus.  Any
> chance of a draft with those in?  It would make moving forward much
> easier.
> 
> Tom Petch
> [e-mail]

-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA10569 for <[e-mail]>; Mon, 9 Sep 2002 12:51:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5CF5B9124E; Mon,  9 Sep 2002 12:50:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 229599124F; Mon,  9 Sep 2002 12:50:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CFBEC9124E for <[e-mail]>; Mon,  9 Sep 2002 12:50:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id ADD125DDC8; Mon,  9 Sep 2002 12:50:28 -0400 (EDT)
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 7E2AD5DDB5 for <[e-mail]>; Mon,  9 Sep 2002 12:50:28 -0400 (EDT)
Received: from tom3 (usermi07.uk.uudial.com [62.188.122.191]) by shockwave.systems.pipex.net (Postfix) with SMTP id D5C9116000DDB; Mon,  9 Sep 2002 17:50:24 +0100 (BST)
Message-ID: <000401c25820$97519860$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Alex Zinin" <[e-mail]>, <[e-mail]>
Subject: Re: BGP spec and IDR WG charter
Date: Mon, 9 Sep 2002 17:42:41 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: [e-mail]
Precedence: bulk

I have a very practical problem that some of the issues coming up now
did come up nine months ago and did reach a rough consensus.  Any
chance of a draft with those in?  It would make moving forward much
easier.

Tom Petch
[e-mail]

---Original Message-----
From: Alex Zinin <[e-mail]>
To: [e-mail] <[e-mail]>
Date: 04 September 2002 23:42
Subject: Re: BGP spec and IDR WG charter


>Folks-
>
>Regarding the review team mentioned below--
>
>Friday, August 23, 2002, 1:11:10 AM, Bill Fenner wrote:
>...
>> [**] In further support of the goal of having a quality
specification
>> that reflects current reality, the ADs have been working on
assembling
>> a team of reviewers that consists primarily of protocol
implementors,
>> who have committed their time to examine the spec.  We will be
>> sending another message to this list explaining the details of how
>> this team will do its work.
>
>--today I have pinged about a dozen people who promised to commit
>some time to review the spec, and asked them to help with the FSM
>text review posted by Sue. Hopefully we will see more activity
>on the list in the following two weeks and later when the complete
>spec goes for the LC.
>
>For people who have not been explicitly pinged and who feel capable
of
>contributing to the protocol specification--please consider this
>message as the invitation from the ADs to review the spec and provide
>your comments. Please send your comments to the list, or (if you do
>not feel comfortable speaking up on the list for some reason), send
>them to the chairs and/or the ADs instead, we'll be able to function
>as proxy if valid issues are raised.
>
>A small request to the reviewers--when looking at the spec, please
>evaluate it from the perspective of being sufficient to implement the
>protocol if the reader is not familiar with the protocol, whether it
>really reflects what your code is doing or what you know other
>implementations do, whether one would need to reverse engineer things
>to write an implementation, etc.
>
>Cheers,
>Alex
>
>



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA07800 for <[e-mail]>; Mon, 9 Sep 2002 11:28:16 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F091391252; Mon,  9 Sep 2002 11:27:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A997191255; Mon,  9 Sep 2002 11:27:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EA96291252 for <[e-mail]>; Mon,  9 Sep 2002 11:27:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D4D525DDD6; Mon,  9 Sep 2002 11:27:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 254CD5DDBF for <[e-mail]>; Mon,  9 Sep 2002 11:27:28 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g89FRMV89683; Mon, 9 Sep 2002 11:27:22 -0400 (EDT) (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 g89FRJG89676; Mon, 9 Sep 2002 11:27:19 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g89FRJV06206; Mon, 9 Sep 2002 11:27:19 -0400 (EDT)
Date: Mon, 9 Sep 2002 11:27:19 -0400
From: Mathew Richardson <[e-mail]>
To: "Michael C. Cambria" <[e-mail]>
Cc: [e-mail]
Subject: Re: Using extended attribute length field
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

> Michael C. Cambria <[e-mail]> [Sat, Sep 07, 2002 at 10:44:21PM -0400]:
>
>draft-ieft-idr-bgp4-17 doesn't say to only use an extended attribute 
>length when the length of the attribute is larger than what will fix in 
>one octet.  Should it?

No.

>Is an implementation complient that uses a 2 octet length when one would 
>suffice?

<snip>

I would think so, yes... certainly, any robust implementation will accept
such length fields.

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 LAA07783 for <[e-mail]>; Mon, 9 Sep 2002 11:27:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E8B809124D; Mon,  9 Sep 2002 11:25:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA45F9124C; Mon,  9 Sep 2002 11:25:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9355C9124D for <[e-mail]>; Mon,  9 Sep 2002 11:25:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 79BD05DDD6; Mon,  9 Sep 2002 11:25:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id BB04B5DDBF for <[e-mail]>; Mon,  9 Sep 2002 11:25:05 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g89FOxB89635; Mon, 9 Sep 2002 11:24:59 -0400 (EDT) (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 g89FOuG89628; Mon, 9 Sep 2002 11:24:56 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g89FOuh06194; Mon, 9 Sep 2002 11:24:56 -0400 (EDT)
Date: Mon, 9 Sep 2002 11:24:56 -0400
From: Mathew Richardson <[e-mail]>
To: "Michael C. Cambria" <[e-mail]>
Cc: [e-mail]
Subject: Re: Review comment: bottom of page 16
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

> Michael C. Cambria <[e-mail]> [Sat, Sep 07, 2002 at 10:33:33PM -0400]:
>
>The description of the NLRI prefix field in update reads as if there are 
> multiple prefixes per field.
>
>"The Prefix field contains IP address prefixes ..."
>
>Shouldn't this say "contains an IP address prefix ..."

<snip>

Yes.

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 LAA07671 for <[e-mail]>; Mon, 9 Sep 2002 11:24:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 63B1391247; Mon,  9 Sep 2002 11:24:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D6099124B; Mon,  9 Sep 2002 11:24:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B27A891247 for <[e-mail]>; Mon,  9 Sep 2002 11:24:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A03085DDBF; Mon,  9 Sep 2002 11:24:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id D3A335DE5C for <[e-mail]>; Mon,  9 Sep 2002 11:24:25 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g89FOE289585; Mon, 9 Sep 2002 11:24:14 -0400 (EDT) (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 g89FOBG89578; Mon, 9 Sep 2002 11:24:11 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g89FOBW06188; Mon, 9 Sep 2002 11:24:11 -0400 (EDT)
Date: Mon, 9 Sep 2002 11:24:10 -0400
From: Mathew Richardson <[e-mail]>
To: "Michael C. Cambria" <[e-mail]>
Cc: [e-mail]
Subject: Re: Review Comments: Section 4.3: "route" vs. destination - withdraw
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

> Michael C. Cambria <[e-mail]> [Sat, Sep 07, 2002 at 01:35:26PM -0400]:
>
>From a first time reader point of view ...
>
>When I read these two paragraphs at the end of section 4.3:
>
>"An UPDATE message can list multiple routes to be withdrawn from 
>service.  Each such route is identified by its destination (expressed as 
>an IP prefix), which unambiguously identifies the route in the context 
>of the BGP speaker - BGP speaker connection to which it has been 
>previously advertised.
>
>An UPDATE message might advertise only routes to be withdrawn from 
>service, in which case it will not include path attributes or Network 
>Layer Reachability Information. Conversely, it may advertise only a 
>feasible route, in which case the WITHDRAWN ROUTES field need not be 
>present."
>
>It reads as if one must withdraw the _set of destinations_ advertised 
>with the route instead of just one or more destinations since route is 
>defined in section 3.1 as:
>
>"For the purpose of this protocol, a route is defined as a unit of 
>information that pairs a set of destinations with the attributes of a 
>path to those destinations.  The set of destinations are the systems 
>whose IP addresses are reported in the Network Layer Reachability 
>Information (NLRI) field and the path is the information reported in the 
>path attributes field of the same UPDATE message."

<snip>

Since this definition seems to result in a lot of confusion, how about
changing the definition of route as follows:

  "For the purpose of this protocol, a route is defined as a unit of
  information that pairs a set of destinations with the attributes of a
  path to those destinations.  The set of destinations are systems whose
  IP addresses are reported in one prefix present in the Network Layer
  Reachability Information (NLRI) field of an UPDATE and the path is the
  information reported in the path attributes field of the same UPDATE
  message.

  This definition allows multiple routes to be advertised in a single
  UPDATE message by including multiple prefixes in the NLRI field of
  the UPDATE.  All such prefixes must be associated with the same set
  of path attributes."

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 LAA07484 for <[e-mail]>; Mon, 9 Sep 2002 11:19:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E535D91240; Mon,  9 Sep 2002 11:18:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E215991246; Mon,  9 Sep 2002 11:18:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 65A4591240 for <[e-mail]>; Mon,  9 Sep 2002 11:17:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4B7E85DDBF; Mon,  9 Sep 2002 11:17:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id DD2D35DDB6 for <[e-mail]>; Mon,  9 Sep 2002 11:17:36 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g89FHZm63056; Mon, 9 Sep 2002 08:17:35 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Bill Fenner <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP spec and IDR WG charter 
In-Reply-To: Your message of "Thu, 22 Aug 2002 16:11:10 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 09 Sep 2002 08:17:35 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Bill,

> Dear IDR WG,
> 
>   After some consideration, the Routing Area Directors have decided
> not to forward any IDR documents for IESG consideration until the
> base BGP spec update is finished.[*]  Despite the best efforts of all
> involved, the spec update has been taking an incredible amount of
> time.  We take this step in order to focus all possible resources
> of the WG community on the BGP spec update.
> 
>   This may seem like a negative action.  On the contrary, it is
> meant to support the accomplishment of the working group's goals.[**]
> The milestone for the submission of the BGP4 draft to the IESG
> was scheduled for January 2002.
> 
>   Attached is a proposed update for the IDR working group charter.
> Note that we just made up the dates in the goals and milestones,
> and the WG should come up with realistic ones.
> 
>   Bill and Alex
> 
> [*] "finished" means, in this case, WG consensus, WG Last Call,
> AD Review, IETF Last Call, and IESG approval for publication.
> 
> [**] In further support of the goal of having a quality specification
> that reflects current reality, the ADs have been working on assembling
> a team of reviewers that consists primarily of protocol implementors,
> who have committed their time to examine the spec.  We will be
> sending another message to this list explaining the details of how
> this team will do its work.

When should we expect you to send the message explaining the details
on how the team will do its work ?

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 KAA06095 for <[e-mail]>; Mon, 9 Sep 2002 10:37:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4CA1691235; Mon,  9 Sep 2002 10:36:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1EA379123B; Mon,  9 Sep 2002 10:36:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7F5E191235 for <[e-mail]>; Mon,  9 Sep 2002 10:36:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6364B5DE2E; Mon,  9 Sep 2002 10:36:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id E16EF5DDD6 for <[e-mail]>; Mon,  9 Sep 2002 10:36:36 -0400 (EDT)
Received: from fid4.com (mcambria3.avayactc.com [199.93.239.107]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g89EYXuo001752; Mon, 9 Sep 2002 10:34:33 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Mon, 09 Sep 2002 10:20:53 -0400
From: "Michael C. Cambria" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020819
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Preferred method for sending review comments (Was Re: Using extended attribute length field)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Abarbanel, Benjamin wrote:
> Michael and All:
>   Although I have been guilty of discussing very detail topics on the
> spec one at a time, on this list. I think sending a burst of detail review
> issues one per message is somewhat not very productive

It doesn't matter to me.  Alex Zinin sent proxy messages to the list 
(one at a time) for discussion.  I thought that was "the way" the ADs 
wanted it.

MikeC



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA05628 for <[e-mail]>; Mon, 9 Sep 2002 10:22:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7B9CE91247; Mon,  9 Sep 2002 10:17:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F32F91250; Mon,  9 Sep 2002 10:17:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C8E5B91247 for <[e-mail]>; Mon,  9 Sep 2002 10:16:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A3FFD5DDB7; Mon,  9 Sep 2002 10:16:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 298DA5DDB6 for <[e-mail]>; Mon,  9 Sep 2002 10:16:58 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07734; Mon, 9 Sep 2002 10:16:56 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA25769; Mon, 9 Sep 2002 10:16:57 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QPXCK>; Mon, 9 Sep 2002 10:16:56 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Manav Bhatia'" <[e-mail]>, Yakov Rekhter <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal
Date: Mon, 9 Sep 2002 10:16:54 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Can someone on this list tell me, why BGP Identifier must be defined
differently
than the Router ID, and show some examples where its technically sensible to
diverge it from the Router ID?

Ben

> -----Original Message-----
> From: Manav Bhatia [mailto:[e-mail]]
> Sent: Monday, September 09, 2002 4:00 AM
> To: Yakov Rekhter; Natale, Jonathan
> Cc: 'Abarbanel, Benjamin'; [e-mail]
> Subject: Re: admin dist/gp spec proposal
> 
> 
> Yakov and others,
> draft-ietf-isis-traffic-04.txt states that if some router 
> advertises the
> router ID TLV (containing the 4-octet router ID of the router 
> originating
> the LSP) in its LSP, and if it also advertises BGP routes 
> with the BGP next
> hop set to the BGP router ID (which is what is usually done), 
> then in such
> cases, the TE router ID should match the BGP router ID.
> 
> I think this warrants the need to mention that the BGP Router 
> ID *should*
> match the Router ID as used by the other routing protocols. 
> Moreover i dont
> see any need for the router IDs to *not* match for the BGP 
> and IGPs and i
> am sure that there will not be any operators assigning 
> different Router IDs
> for the same.
> 
> Or am i missing something here?
> 
> Manav
> 
> ----- Original Message -----
> From: "Yakov Rekhter" <[e-mail]>
> To: "Natale, Jonathan" <[e-mail]>
> Cc: "'Abarbanel, Benjamin'" <[e-mail]>;
> <[e-mail]>
> Sent: Saturday, September 07, 2002 1:13 AM
> Subject: Re: admin dist/gp spec proposal
> 
> 
> | Natale,
> |
> | > 1745 and 1403 are historic
> |
> | correct. And with this in mind I would suggest we stop 
> reference/pointing
> | to them.
> |
> | Yakov.
> |
> | > -----Original Message-----
> | > From: Abarbanel, Benjamin [mailto:[e-mail]]
> | > Sent: Friday, September 06, 2002 3:38 PM
> | > To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Yakov Rekhter'
> | > Cc: [e-mail]
> | > Subject: RE: admin dist/gp spec proposal
> | >
> | >
> | >
> | > >
> | > > Not that I am aware of.  There certainly is a case where they
> | > > must be the
> | > > same (cisco bgp w/ ospf, don't know all the details of
> | > > how/why).
> | >
> | > RFC1745, and RFC1403 tell you why they must be the same.
> | >
> | > > Maybe the local admin method of numbering is more versatile by
> allowing
> | > > them to be different.  I think they should MUST be the 
> same and in
> some
> | > > implementation they are (gated, bay).
> | > >
> | > > -----Original Message-----
> | > > From: Abarbanel, Benjamin 
> [mailto:[e-mail]]
> | > > Sent: Friday, September 06, 2002 3:29 PM
> | > > To: 'Yakov Rekhter'; Abarbanel, Benjamin
> | > > Cc: Natale, Jonathan; [e-mail]
> | > > Subject: RE: admin dist/gp spec proposal
> | > >
> | > >
> | > > >
> | > > > > I would like to rephrase my statement on one sentence.
> | > > > >
> | > > > > " BTW. BGP Identifier is a vague way of naming what 
> we know as
> the
> | > > > >   Router-ID in all other IP related protocols."
> | > > >
> | > > > This is *technically* incorrect.
> | > > >
> | > > Is there a case where the BGP Identifier, should or must be
> | > > different than
> | > > the Router-ID for the routing system to work correctly?
> | > >
> | > > Ben
> | > >
> | > >
> | > > >
> | > > > >
> | > > > >
> | > > > > > -----Original Message-----
> | > > > > > From: Abarbanel, Benjamin
> | > > [mailto:[e-mail]]
> | > > > > > Sent: Friday, September 06, 2002 3:01 PM
> | > > > > > To: 'Yakov Rekhter'; Natale, Jonathan
> | > > > > > Cc: [e-mail]
> | > > > > > Subject: RE: admin dist/gp spec proposal
> | > > > > >
> | > > > > >
> | > > > > > Yakov:
> | > > > > >   There is no reference to RFC1812 in the 
> reference section
> | > > > > > nor references
> | > > > > > to this spec where appropriate in the BGP relevant
> | > > > > > discussions. As was
> | > > > > > earlier mentioned. At least we need to tie the thread
> | > > > between the two
> | > > > > > specs so people know what the assumptions are.
> | > > > > >
> | > > > > > BTW. BGP Identifier is a very misleading way of 
> naming what
> | > > > > > we know as the
> | > > > > > Router ID in all other protocols. I would like to 
> suggest we
> | > > > > > enhance its
> | > > > > > description as follows:
> | > > > > >
> | > > > > > Current statement:
> | > > > > > ==================
> | > > > > > "BGP Identifier:
> | > > > > >
> | > > > >          This 4-octet unsigned integer indicates the BGP
> | > > > Identifier of
> | > > > > >          the sender. A given BGP speaker sets the value
> | > > of its BGP
> | > > > > >          Identifier to an IP address assigned to that BGP
> | > > > > > speaker.  The
> | > > > > >          value of the BGP Identifier is 
> determined on startup
> | > > > > > and is the
> | > > > > >          same for every local interface and every 
> BGP peer. "
> | > > > > >
> | > > > > > New Statement:
> | > > > > > ==============
> | > > > > > "BGP Identifier:
> | > > > > >
> | > > > > >          This 4-octet unsigned integer indicates the BGP
> | > > > Identifier of
> | > > > > >          the sender. A given BGP speaker sets the value
> | > > of its BGP
> | > > > > >          Identifier also known as the Router-ID, to an IP
> | > > > > > address assigned
> | > > > > >          to that BGP speaker. The value of the BGP
> | > > Identifier is
> | > > > > >          determined on startup and is the same for every
> | > > > > > local interface
> | > > > > >          and every BGP peer and other IP related 
> protocols.
> | > > > > > See [x],[y] for
> | > > > > >          more details on Router-ID useage between BGP and
> | > > > > > other protocols."
> | > > > > >
> | > > > > > Where x = RFC1403,
> | > > > > >       y = RFC1745
> | > > > > >
> | > > > > > Ben
> | > > > > > > -----Original Message-----
> | > > > > > > From: Yakov Rekhter [mailto:[e-mail]]
> | > > > > > > Sent: Friday, September 06, 2002 2:31 PM
> | > > > > > > To: Natale, Jonathan
> | > > > > > > Cc: [e-mail]
> | > > > > > > Subject: Re: admin dist/gp spec proposal
> | > > > > > >
> | > > > > > >
> | > > > > > > Natale,
> | > > > > > >
> | > > > > > > >
> | > > > > > > >
> | > > > > > > > -----Original Message-----
> | > > > > > > > From: Abarbanel, Benjamin
> | > > > [mailto:[e-mail]]
> | > > > > > > > Sent: Friday, September 06, 2002 1:49 PM
> | > > > > > > > To: 'Natale, Jonathan'
> | > > > > > > > Subject: RE: admin dist/gp spec proposal
> | > > > > > > >
> | > > > > > > > Jonathan:
> | > > > > > > > Forward this message to the IDR list. I think we
> | > > dropped off.
> | > > > > > > >
> | > > > > > > > Ben
> | > > > > > > >
> | > > > > > > > > -----Original Message-----
> | > > > > > > > > From: Natale, Jonathan 
[mailto:[e-mail]]
| > > > > > > > > Sent: Friday, September 06, 2002 1:46 PM
| > > > > > > > > To: 'Abarbanel, Benjamin'
| > > > > > > > > Subject: RE: admin dist/gp spec proposal
| > > > > > > > >
| > > > > > > > >
| > > > > > > > > I agree.  The default values of the various
| > > > protocols as they
| > > > > > > > > are currently
| > > > > > > > > implemented make sense:
| > > > > > > > > Connected
| > > > > > > > > Static
| > > > > > > > > Ebgp
| > > > > > > > > Igp's
| > > > > > > > > Ibgp
| > > > > > > > >
| > > > > > > > > ...they should be documented in 1812 ideally, but
| > > > putting it
| > > > > > > > > in 1771 would
| > > > > > > > > not hurt.  Added a phrase to indicate that they
| > > may be user
| > > > > > > > > configurable is
| > > > > > > > > good too.
| > > > > > >
| > > > > > > Perhaps it is time to update 1812. But let's not use BGP
| > > > > > > spec as a replacement for updating 1812 - it is not.
| > > > > > >
| > > > > > > Yakov.
| > > > > > >
| > > > > > > > >
| > > > > > > > > -----Original Message-----
| > > > > > > > > From: Abarbanel, Benjamin
| > > > > [mailto:[e-mail]]
| > > > > > > > Sent: Friday, September 06, 2002 11:39 AM
| > > > > > > > To: 'Mathew Richardson'; Natale, Jonathan
| > > > > > > > Cc: [e-mail]
| > > > > > > > Subject: RE: admin dist/gp spec proposal
| > > > > > > >
| > >



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA05436 for <[e-mail]>; Mon, 9 Sep 2002 10:15:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9502E91235; Mon,  9 Sep 2002 10:13:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43CAD9123B; Mon,  9 Sep 2002 10:13:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F7E191235 for <[e-mail]>; Mon,  9 Sep 2002 10:13:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 832725DD9D; Mon,  9 Sep 2002 10:13:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 085FD5DDB6 for <[e-mail]>; Mon,  9 Sep 2002 10:13:17 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA07380; Mon, 9 Sep 2002 10:13:14 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA25065; Mon, 9 Sep 2002 10:13:15 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QPW9R>; Mon, 9 Sep 2002 10:13:15 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Michael C. Cambria'" <[e-mail]>, [e-mail]
Subject: RE: Using extended attribute length field
Date: Mon, 9 Sep 2002 10:13:14 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Michael and All:
  Although I have been guilty of discussing very detail topics on the
spec one at a time, on this list. I think sending a burst of detail review
issues one per message is somewhat not very productive. If we could compose
all
of them in one message or send them in one message with an attached text or
Word file, it will make following these issues more constructive. 

Thanks, just another guy in the crowd,

Best Regards,
Ben

> -----Original Message-----
> From: Michael C. Cambria [mailto:[e-mail]]
> Sent: Saturday, September 07, 2002 10:44 PM
> To: [e-mail]
> Subject: Using extended attribute length field
> 
> 
> 
> draft-ieft-idr-bgp4-17 doesn't say to only use an extended attribute 
> length when the length of the attribute is larger than what 
> will fix in 
> one octet.  Should it?
> 
> Is an implementation complient that uses a 2 octet length 
> when one would 
> suffice?
> 
> MikeC
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA23577 for <[e-mail]>; Mon, 9 Sep 2002 04:01:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7F9AD91216; Mon,  9 Sep 2002 04:00:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38BF69121A; Mon,  9 Sep 2002 04:00:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2722391216 for <[e-mail]>; Mon,  9 Sep 2002 04:00:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6E8FD5DDA1; Mon,  9 Sep 2002 04:00:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from realname (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id DB7825DD8D for <[e-mail]>; Mon,  9 Sep 2002 04:00:30 -0400 (EDT)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) id <[e-mail]> for [e-mail]; Mon, 09 Sep 2002 17:04:47 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTP id <[e-mail]> for [e-mail]; Mon, 09 Sep 2002 17:04:46 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 (built Sep  5 2001)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 09 Sep 2002 17:05:10 +0900 (KST)
Date: Mon, 09 Sep 2002 13:30:24 +0530
From: Manav Bhatia <[e-mail]>
Subject: Re: admin dist/gp spec proposal
To: Yakov Rekhter <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'Abarbanel, Benjamin'" <[e-mail]>, [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <028201c257d6$f5142070$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Yakov and others,
draft-ietf-isis-traffic-04.txt states that if some router advertises the
router ID TLV (containing the 4-octet router ID of the router originating
the LSP) in its LSP, and if it also advertises BGP routes with the BGP next
hop set to the BGP router ID (which is what is usually done), then in such
cases, the TE router ID should match the BGP router ID.

I think this warrants the need to mention that the BGP Router ID *should*
match the Router ID as used by the other routing protocols. Moreover i dont
see any need for the router IDs to *not* match for the BGP and IGPs and i
am sure that there will not be any operators assigning different Router IDs
for the same.

Or am i missing something here?

Manav

----- Original Message -----
From: "Yakov Rekhter" <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Abarbanel, Benjamin'" <[e-mail]>;
<[e-mail]>
Sent: Saturday, September 07, 2002 1:13 AM
Subject: Re: admin dist/gp spec proposal


| Natale,
|
| > 1745 and 1403 are historic
|
| correct. And with this in mind I would suggest we stop reference/pointing
| to them.
|
| Yakov.
|
| > -----Original Message-----
| > From: Abarbanel, Benjamin [mailto:[e-mail]]
| > Sent: Friday, September 06, 2002 3:38 PM
| > To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Yakov Rekhter'
| > Cc: [e-mail]
| > Subject: RE: admin dist/gp spec proposal
| >
| >
| >
| > >
| > > Not that I am aware of.  There certainly is a case where they
| > > must be the
| > > same (cisco bgp w/ ospf, don't know all the details of
| > > how/why).
| >
| > RFC1745, and RFC1403 tell you why they must be the same.
| >
| > > Maybe the local admin method of numbering is more versatile by
allowing
| > > them to be different.  I think they should MUST be the same and in
some
| > > implementation they are (gated, bay).
| > >
| > > -----Original Message-----
| > > From: Abarbanel, Benjamin [mailto:[e-mail]]
| > > Sent: Friday, September 06, 2002 3:29 PM
| > > To: 'Yakov Rekhter'; Abarbanel, Benjamin
| > > Cc: Natale, Jonathan; [e-mail]
| > > Subject: RE: admin dist/gp spec proposal
| > >
| > >
| > > >
| > > > > I would like to rephrase my statement on one sentence.
| > > > >
| > > > > " BTW. BGP Identifier is a vague way of naming what we know as
the
| > > > >   Router-ID in all other IP related protocols."
| > > >
| > > > This is *technically* incorrect.
| > > >
| > > Is there a case where the BGP Identifier, should or must be
| > > different than
| > > the Router-ID for the routing system to work correctly?
| > >
| > > Ben
| > >
| > >
| > > >
| > > > >
| > > > >
| > > > > > -----Original Message-----
| > > > > > From: Abarbanel, Benjamin
| > > [mailto:[e-mail]]
| > > > > > Sent: Friday, September 06, 2002 3:01 PM
| > > > > > To: 'Yakov Rekhter'; Natale, Jonathan
| > > > > > Cc: [e-mail]
| > > > > > Subject: RE: admin dist/gp spec proposal
| > > > > >
| > > > > >
| > > > > > Yakov:
| > > > > >   There is no reference to RFC1812 in the reference section
| > > > > > nor references
| > > > > > to this spec where appropriate in the BGP relevant
| > > > > > discussions. As was
| > > > > > earlier mentioned. At least we need to tie the thread
| > > > between the two
| > > > > > specs so people know what the assumptions are.
| > > > > >
| > > > > > BTW. BGP Identifier is a very misleading way of naming what
| > > > > > we know as the
| > > > > > Router ID in all other protocols. I would like to suggest we
| > > > > > enhance its
| > > > > > description as follows:
| > > > > >
| > > > > > Current statement:
| > > > > > ==================
| > > > > > "BGP Identifier:
| > > > > >
| > > > >          This 4-octet unsigned integer indicates the BGP
| > > > Identifier of
| > > > > >          the sender. A given BGP speaker sets the value
| > > of its BGP
| > > > > >          Identifier to an IP address assigned to that BGP
| > > > > > speaker.  The
| > > > > >          value of the BGP Identifier is determined on startup
| > > > > > and is the
| > > > > >          same for every local interface and every BGP peer. "
| > > > > >
| > > > > > New Statement:
| > > > > > ==============
| > > > > > "BGP Identifier:
| > > > > >
| > > > > >          This 4-octet unsigned integer indicates the BGP
| > > > Identifier of
| > > > > >          the sender. A given BGP speaker sets the value
| > > of its BGP
| > > > > >          Identifier also known as the Router-ID, to an IP
| > > > > > address assigned
| > > > > >          to that BGP speaker. The value of the BGP
| > > Identifier is
| > > > > >          determined on startup and is the same for every
| > > > > > local interface
| > > > > >          and every BGP peer and other IP related protocols.
| > > > > > See [x],[y] for
| > > > > >          more details on Router-ID useage between BGP and
| > > > > > other protocols."
| > > > > >
| > > > > > Where x = RFC1403,
| > > > > >       y = RFC1745
| > > > > >
| > > > > > Ben
| > > > > > > -----Original Message-----
| > > > > > > From: Yakov Rekhter [mailto:[e-mail]]
| > > > > > > Sent: Friday, September 06, 2002 2:31 PM
| > > > > > > To: Natale, Jonathan
| > > > > > > Cc: [e-mail]
| > > > > > > Subject: Re: admin dist/gp spec proposal
| > > > > > >
| > > > > > >
| > > > > > > Natale,
| > > > > > >
| > > > > > > >
| > > > > > > >
| > > > > > > > -----Original Message-----
| > > > > > > > From: Abarbanel, Benjamin
| > > > [mailto:[e-mail]]
| > > > > > > > Sent: Friday, September 06, 2002 1:49 PM
| > > > > > > > To: 'Natale, Jonathan'
| > > > > > > > Subject: RE: admin dist/gp spec proposal
| > > > > > > >
| > > > > > > > Jonathan:
| > > > > > > > Forward this message to the IDR list. I think we
| > > dropped off.
| > > > > > > >
| > > > > > > > Ben
| > > > > > > >
| > > > > > > > > -----Original Message-----
| > > > > > > > > From: Natale, Jonathan [mailto:[e-mail]]
| > > > > > > > > Sent: Friday, September 06, 2002 1:46 PM
| > > > > > > > > To: 'Abarbanel, Benjamin'
| > > > > > > > > Subject: RE: admin dist/gp spec proposal
| > > > > > > > >
| > > > > > > > >
| > > > > > > > > I agree.  The default values of the various
| > > > protocols as they
| > > > > > > > > are currently
| > > > > > > > > implemented make sense:
| > > > > > > > > Connected
| > > > > > > > > Static
| > > > > > > > > Ebgp
| > > > > > > > > Igp's
| > > > > > > > > Ibgp
| > > > > > > > >
| > > > > > > > > ...they should be documented in 1812 ideally, but
| > > > putting it
| > > > > > > > > in 1771 would
| > > > > > > > > not hurt.  Added a phrase to indicate that they
| > > may be user
| > > > > > > > > configurable is
| > > > > > > > > good too.
| > > > > > >
| > > > > > > Perhaps it is time to update 1812. But let's not use BGP
| > > > > > > spec as a replacement for updating 1812 - it is not.
| > > > > > >
| > > > > > > Yakov.
| > > > > > >
| > > > > > > > >
| > > > > > > > > -----Original Message-----
| > > > > > > > > From: Abarbanel, Benjamin
| > > > > [mailto:[e-mail]]
| > > > > > > > Sent: Friday, September 06, 2002 11:39 AM
| > > > > > > > To: 'Mathew Richardson'; Natale, Jonathan
| > > > > > > > Cc: [e-mail]
| > > > > > > > Subject: RE: admin dist/gp spec proposal
| > > > > > > >
| > >




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA09741 for <[e-mail]>; Sun, 8 Sep 2002 21:04:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 656259120F; Sun,  8 Sep 2002 21:04:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3BA891212; Sun,  8 Sep 2002 21:03:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 90E8F9120F for <[e-mail]>; Sun,  8 Sep 2002 21:02:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 632BA5DE52; Sun,  8 Sep 2002 21:02:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id D86785DE1B for <[e-mail]>; Sun,  8 Sep 2002 21:02:07 -0400 (EDT)
Received: from fid4.com (mcambria.fid4.com [172.16.6.1]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g89108uo000724 for <[e-mail]>; Sun, 8 Sep 2002 21:00:09 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sun, 08 Sep 2002 21:00:08 -0400
From: "Michael C. Cambria" <[e-mail]>
Organization: U n o r g a n i z e d
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020818
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Review Comment: Origin Attribute pg 14
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Editorial suggestion:

Consider adding a reference to RFC904(?) after "learned via the EGP 
protocol"

MikeC



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA29776 for <[e-mail]>; Sat, 7 Sep 2002 23:49:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9296A9122C; Sat,  7 Sep 2002 23:49:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D81F9122D; Sat,  7 Sep 2002 23:48:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B474D9122C for <[e-mail]>; Sat,  7 Sep 2002 23:47:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 85C1C5DED6; Sat,  7 Sep 2002 23:47:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 46FF95DEB8 for <[e-mail]>; Sat,  7 Sep 2002 23:47:27 -0400 (EDT)
Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 8B6D54BA214; Sat,  7 Sep 2002 20:47:26 -0700 (PDT)
Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 1C56B7E6C1; Sat,  7 Sep 2002 20:47:25 -0700 (PDT)
To: "Michael C. Cambria" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Using extended attribute length field 
In-Reply-To: Message from "Michael C. Cambria" <[e-mail]>  of "Sat, 07 Sep 2002 22:44:21 EDT." <[e-mail]> 
Date: Sat, 07 Sep 2002 20:47:25 -0700
From: Enke Chen <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Message-ID: <[e-mail]>
> Date: Sat, 07 Sep 2002 22:44:21 -0400
> From: "Michael C. Cambria" <[e-mail]>
> To: [e-mail]
> Subject: Using extended attribute length field
> 
> draft-ieft-idr-bgp4-17 doesn't say to only use an extended attribute 
> length when the length of the attribute is larger than what will fix in 
> one octet.  Should it?

No, it should not. You might want to read the IDR mailing list archive
on this topic.

> 
> Is an implementation complient that uses a 2 octet length when one would 
> suffice?

Yes.

-- Enke




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA25780 for <[e-mail]>; Sat, 7 Sep 2002 22:49:15 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 23BBA9122B; Sat,  7 Sep 2002 22:48:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C026A9122E; Sat,  7 Sep 2002 22:48:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 545B691228 for <[e-mail]>; Sat,  7 Sep 2002 22:47:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 31EEF5DEC4; Sat,  7 Sep 2002 22:47:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id AAC3D5DE57 for <[e-mail]>; Sat,  7 Sep 2002 22:47:04 -0400 (EDT)
Received: from fid4.com (mcambria.fid4.com [172.16.6.1]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g882iL5S020703 for <[e-mail]>; Sat, 7 Sep 2002 22:44:21 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sat, 07 Sep 2002 22:44:21 -0400
From: "Michael C. Cambria" <[e-mail]>
Organization: U n o r g a n i z e d
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020818
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Using extended attribute length field
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

draft-ieft-idr-bgp4-17 doesn't say to only use an extended attribute 
length when the length of the attribute is larger than what will fix in 
one octet.  Should it?

Is an implementation complient that uses a 2 octet length when one would 
suffice?

MikeC



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA24784 for <[e-mail]>; Sat, 7 Sep 2002 22:36:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 03A8091224; Sat,  7 Sep 2002 22:36:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C360B91228; Sat,  7 Sep 2002 22:36:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C01191224 for <[e-mail]>; Sat,  7 Sep 2002 22:36:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4DAD75DEB8; Sat,  7 Sep 2002 22:36:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id BB6E45DE57 for <[e-mail]>; Sat,  7 Sep 2002 22:36:16 -0400 (EDT)
Received: from fid4.com (mcambria.fid4.com [172.16.8.1]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g882XX5S020689 for <[e-mail]>; Sat, 7 Sep 2002 22:33:33 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sat, 07 Sep 2002 22:33:33 -0400
From: "Michael C. Cambria" <[e-mail]>
Organization: U n o r g a n i z e d
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020818
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Review comment: bottom of page 16
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

The description of the NLRI prefix field in update reads as if there are 
  multiple prefixes per field.

"The Prefix field contains IP address prefixes ..."

Shouldn't this say "contains an IP address prefix ...", similar to the 
description of the withdrawn routes field?  e.g. each single prefix is 
preceeded by a length.

MikeC



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA22116 for <[e-mail]>; Sat, 7 Sep 2002 21:39:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8D1A59120D; Sat,  7 Sep 2002 21:38:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D06991222; Sat,  7 Sep 2002 21:38:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 141FF9120D for <[e-mail]>; Sat,  7 Sep 2002 21:38:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EB7DF5DEB5; Sat,  7 Sep 2002 21:38:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id 6F8355DE06 for <[e-mail]>; Sat,  7 Sep 2002 21:38:32 -0400 (EDT)
Received: from fid4.com (mcambria.fid4.com [172.16.8.1]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g881Zn5S020633 for <[e-mail]>; Sat, 7 Sep 2002 21:35:49 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sat, 07 Sep 2002 21:35:49 -0400
From: "Michael C. Cambria" <[e-mail]>
Organization: U n o r g a n i z e d
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020818
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Review Comments: Section 4.3: "route" vs. destination - withdraw
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Clarification on what I wrote:
> 
>  From a first time reader point of view ...
> 
> When I read these two paragraphs at the end of section 4.3:
> 
> "An UPDATE message can list multiple routes to be withdrawn from 
> service.  Each such route is identified by its destination (expressed as 
> an IP prefix), which unambiguously identifies the route in the context 
> of the BGP speaker - BGP speaker connection to which it has been 
> previously advertised.
> 
> An UPDATE message might advertise only routes to be withdrawn from 
> service, in which case it will not include path attributes or Network 
> Layer Reachability Information. Conversely, it may advertise only a 
> feasible route, in which case the WITHDRAWN ROUTES field need not be 
> present."
> 
> It reads as if one must withdraw the _set of destinations_ advertised 
> with the route instead of just one or more destinations since route is 
> defined in section 3.1 as:

I meant to say, the *same* set of destinations as those advertised 
initially.  For example, NLRI with dest-a, dest-b and dest-c with the 
same attributes is a "route".  The withdrawal of the "route" can be read 
as one must withdraw all destinations originally advertised for that 
route (dest-a, dest-b, dest-c) as a unit.

A first time reader could be left wondering if the above must be the 
case, or it is valid for an implementation to withdraw just one of these 
destinations (e.g. dest-b), leaving the others (dest-a, dest-c) 
reachable with their attributes intact.

If there is no relationship between destinations when advertised as a 
set of destinations in a route and those destinations that can be 
withdrawn should be explicitly stated.  Otherwise, the draft should call 
out that it is not legal to withdraw one prefix only in the set of 
prefixes advertised as previously as route.

> "For the purpose of this protocol, a route is defined as a unit of 
> information that pairs a set of destinations with the attributes of a 
> path to those destinations.  The set of destinations are the systems 
> whose IP addresses are reported in the Network Layer Reachability 
> Information (NLRI) field and the path is the information reported in the 
> path attributes field of the same UPDATE message."
> 
> 
> Shouldn't the text change "routes" to destinations, or to prefixes?



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA08604 for <[e-mail]>; Sat, 7 Sep 2002 17:30:21 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B329491214; Sat,  7 Sep 2002 17:29:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 810DA91222; Sat,  7 Sep 2002 17:29:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2DBF091214 for <[e-mail]>; Sat,  7 Sep 2002 17:29:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 120B65DE98; Sat,  7 Sep 2002 17:29:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id 892945DE7A for <[e-mail]>; Sat,  7 Sep 2002 17:29:51 -0400 (EDT)
Received: from fid4.com (mcambria.fid4.com [172.16.6.1]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g87LR95S020403 for <[e-mail]>; Sat, 7 Sep 2002 17:27:09 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sat, 07 Sep 2002 17:27:09 -0400
From: "Michael C. Cambria" <[e-mail]>
Organization: U n o r g a n i z e d
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020818
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Review Comments: Section 4.3: Description of AS_PATH length
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

 From a first time reader point of view ...

Length fields elsewhere in the draft specify the number of bytes that a 
variable length field uses.  For AS_PATH, length is used as the number 
of 2 byte AS numbers.  In the interest of not having to check other 
sources to be sure, should the descripton of path segment value:

"The path segment value field contains one or more AS numbers, each 
encoded as a 2-octets long field."

explicitly mention the number of bytes used by the variable length field?

Or, make the description of length explicitly mention that it is not the 
length of the variable length field as is the case with other length fields?

MikeC



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA27352 for <[e-mail]>; Sat, 7 Sep 2002 14:04:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 986F991201; Sat,  7 Sep 2002 14:04:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 87E1A91222; Sat,  7 Sep 2002 14:04:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6941691201 for <[e-mail]>; Sat,  7 Sep 2002 14:02:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2F5A25DE96; Sat,  7 Sep 2002 14:02:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mail-blue.research.att.com (H-135-207-30-102.research.att.com [135.207.30.102]) by segue.merit.edu (Postfix) with ESMTP id 0C4E85DE8A for <[e-mail]>; Sat,  7 Sep 2002 14:02:21 -0400 (EDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 8F5884CF2A; Sat,  7 Sep 2002 14:02:15 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA09636; Sat, 7 Sep 2002 14:02:15 -0400 (EDT)
From: Bill Fenner <[e-mail]>
Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id LAA18731; Sat, 7 Sep 2002 11:02:14 -0700 (PDT)
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: [e-mail]
Subject: Re: BGP spec and IDR WG charter
Cc: [e-mail]
Date: Sat, 7 Sep 2002 11:02:14 -0700
Versions: dmail (solaris) 2.5a/makemail 2.9d
Sender: [e-mail]
Precedence: bulk

>Considering your statement, I suppose that all the IDR WG drafts
>that are currently not listed in the WG charter need to be added
>to avoid mistakes/delays in the future. Is this correct?

Yup.  The charter that was agreed upon last year says that all WG
work needs to be listed in the charter and agreed to by the IESG.

  Bill


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 NAA25775 for <[e-mail]>; Sat, 7 Sep 2002 13:38:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3DAB99135B; Sat,  7 Sep 2002 13:37:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0ED589135C; Sat,  7 Sep 2002 13:37:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BA9359135B for <[e-mail]>; Sat,  7 Sep 2002 13:37:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9442D5DE87; Sat,  7 Sep 2002 13:37:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id 1E4945DE79 for <[e-mail]>; Sat,  7 Sep 2002 13:37:43 -0400 (EDT)
Received: from fid4.com (mcambria.fid4.com [172.16.6.1]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g87HZ15S020164 for <[e-mail]>; Sat, 7 Sep 2002 13:35:01 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sat, 07 Sep 2002 13:35:01 -0400
From: "Michael C. Cambria" <[e-mail]>
Organization: U n o r g a n i z e d
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020818
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Review Comments: Section 4.3: "routes" vs. destinations - advertise
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

 From a first time reader point of view ...

Since:

"For the purpose of this protocol, a route is defined as a unit of 
information that pairs a set of destinations with the attributes of a 
path to those destinations.  The set of destinations are the systems 
whose IP addresses are reported in the Network Layer Reachability 
Information (NLRI) field and the path is the information reported in the 
path attributes field of the same UPDATE message."

When I read section 4.3:

"An UPDATE message is used to advertise feasible routes sharing common 
   path attribute to a peer, or to withdraw multiple unfeasible routes 
   from service (see 3.1)."

Shouldn't the text read "... advertise feasible [prefixes | 
destinations] sharing common path attribute(S)to a peer ...", because:

1) A route is defined as quoted above from section 3.1?

or since ...

"An UPDATE message can advertise at most one set of path attributes, but 
multiple destinations ..."

2) make "routes" in the orignal singular.

MikeC



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA25764 for <[e-mail]>; Sat, 7 Sep 2002 13:38:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 04B9B9135C; Sat,  7 Sep 2002 13:38:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C365B9135D; Sat,  7 Sep 2002 13:38:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 720339135C for <[e-mail]>; Sat,  7 Sep 2002 13:38:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 264C45DE87; Sat,  7 Sep 2002 13:38:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id A4C995DE79 for <[e-mail]>; Sat,  7 Sep 2002 13:38:07 -0400 (EDT)
Received: from fid4.com (mcambria.fid4.com [172.16.6.1]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g87HZQ5S020170 for <[e-mail]>; Sat, 7 Sep 2002 13:35:26 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sat, 07 Sep 2002 13:35:26 -0400
From: "Michael C. Cambria" <[e-mail]>
Organization: U n o r g a n i z e d
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020818
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Review Comments: Section 4.3: "route" vs. destination - withdraw
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

 From a first time reader point of view ...

When I read these two paragraphs at the end of section 4.3:

"An UPDATE message can list multiple routes to be withdrawn from 
service.  Each such route is identified by its destination (expressed as 
an IP prefix), which unambiguously identifies the route in the context 
of the BGP speaker - BGP speaker connection to which it has been 
previously advertised.

An UPDATE message might advertise only routes to be withdrawn from 
service, in which case it will not include path attributes or Network 
Layer Reachability Information. Conversely, it may advertise only a 
feasible route, in which case the WITHDRAWN ROUTES field need not be 
present."

It reads as if one must withdraw the _set of destinations_ advertised 
with the route instead of just one or more destinations since route is 
defined in section 3.1 as:

"For the purpose of this protocol, a route is defined as a unit of 
information that pairs a set of destinations with the attributes of a 
path to those destinations.  The set of destinations are the systems 
whose IP addresses are reported in the Network Layer Reachability 
Information (NLRI) field and the path is the information reported in the 
path attributes field of the same UPDATE message."


Shouldn't the text change "routes" to destinations, or to prefixes?

MikeC



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 NAA24728 for <[e-mail]>; Sat, 7 Sep 2002 13:04:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D9BD991359; Sat,  7 Sep 2002 13:04:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CA899135C; Sat,  7 Sep 2002 13:03:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F18AA91359 for <[e-mail]>; Sat,  7 Sep 2002 13:02:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C68C45DE79; Sat,  7 Sep 2002 13:02:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id 449005DE6D for <[e-mail]>; Sat,  7 Sep 2002 13:02:09 -0400 (EDT)
Received: from fid4.com (mcambria.fid4.com [172.16.8.1]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g87GxR5S020110 for <[e-mail]>; Sat, 7 Sep 2002 12:59:27 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sat, 07 Sep 2002 12:59:27 -0400
From: "Michael C. Cambria" <[e-mail]>
Organization: U n o r g a n i z e d
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020818
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Review: Section 4.3 - Path Attributes
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

 From a first time reader point of view ...

The top of page 13 says:

"A variable length sequence of path attributes is present in every UPDATE."

Is this really true, given that later, in the second to last paragraph 
of this section (4.3):

"An UPDATE message might advertise only routes to be withdrawn from 
service, in which case it will not include path attributes or Network 
Layer Reachability Information."

This could be confusing to a first time reader.

The path attribute length is present in every UPDATE, the path attribute 
field itself can be left out, both according to the description of the 
minimum length of the UPDATE message and (implied?) in the picture of 
the UPDATE message at the beginning of section 4.3.

MikeC



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA24710 for <[e-mail]>; Sat, 7 Sep 2002 13:04:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2AF909121E; Sat,  7 Sep 2002 13:04:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C67CD9135B; Sat,  7 Sep 2002 13:04:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BB0D19121E for <[e-mail]>; Sat,  7 Sep 2002 13:04:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A1AC25DE79; Sat,  7 Sep 2002 13:04:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id 1E5A45DE6D for <[e-mail]>; Sat,  7 Sep 2002 13:04:16 -0400 (EDT)
Received: from fid4.com (mcambria.fid4.com [172.16.6.1]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g87H1Y5S020123 for <[e-mail]>; Sat, 7 Sep 2002 13:01:35 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sat, 07 Sep 2002 13:01:34 -0400
From: "Michael C. Cambria" <[e-mail]>
Organization: U n o r g a n i z e d
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020818
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Review: Comments:  Section 4.3: UPDATE min length
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

The text about the mimimum length, at first look, gives the impression 
that it is still part of the NLRI field description and/or the Path 
Attributes section.  A new "subsection" or heading of some sort would be 
helpfull in switching context back to the UPDATE message as a whole and 
not the path attributes field anymore.

MikeC



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA17169 for <[e-mail]>; Sat, 7 Sep 2002 10:36:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DCF0F91357; Sat,  7 Sep 2002 10:36:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DE5491358; Sat,  7 Sep 2002 10:36:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5BA0191357 for <[e-mail]>; Sat,  7 Sep 2002 10:36:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 412095DE07; Sat,  7 Sep 2002 10:36:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id B88665DDE2 for <[e-mail]>; Sat,  7 Sep 2002 10:36:09 -0400 (EDT)
Received: from fid4.com (mcambria.fid4.com [172.16.8.1]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g87EXT5S019969 for <[e-mail]>; Sat, 7 Sep 2002 10:33:29 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sat, 07 Sep 2002 10:33:28 -0400
From: "Michael C. Cambria" <[e-mail]>
Organization: U n o r g a n i z e d
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020818
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Review: Section 4.2 Hold Timer
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

To a first time reader...

The description of Hold Time in the Open Message Format, reads as if 
there are zero seconds between messages.

Should the text at the top of page 38 (FSM Open Sent) be duplicated here 
(or at least mention that zero means its "turned off" and not zero seconds)?

Another possibility would be to move the descripton of Hold Time use 
completely to page 38, and leave just the format and values to this section.

MikeC




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA16284 for <[e-mail]>; Sat, 7 Sep 2002 10:11:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 577F491356; Sat,  7 Sep 2002 10:10:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26A8191357; Sat,  7 Sep 2002 10:10:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE93E91356 for <[e-mail]>; Sat,  7 Sep 2002 10:10:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CBBC05DE94; Sat,  7 Sep 2002 10:10:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mcambria.fid4.com (h006097296569.ne.client2.attbi.com [66.30.202.75]) by segue.merit.edu (Postfix) with ESMTP id 56DFA5DDE2 for <[e-mail]>; Sat,  7 Sep 2002 10:10:49 -0400 (EDT)
Received: from fid4.com (mcambria.fid4.com [172.16.6.1]) by mcambria.fid4.com (8.12.5/8.11.6) with ESMTP id g87E885S019939 for <[e-mail]>; Sat, 7 Sep 2002 10:08:08 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Sat, 07 Sep 2002 10:08:07 -0400
From: "Michael C. Cambria" <[e-mail]>
Organization: U n o r g a n i z e d
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.0) Gecko/20020818
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Review: Section 2, TCP Port 179
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

"BGP uses TCP port 179 for establishing its connections"

 From a first time reader point of view ....  does this mean both the 
source and destination use port 179?

Intuition (and a quick look at /etc/services) should make it clear that 
BGP listens on TCP port 179, but shouldn't the draft make clear what can 
and cannot be used for the source port?

MikeC



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA12673 for <[e-mail]>; Sat, 7 Sep 2002 08:21:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C5EB991229; Sat,  7 Sep 2002 08:20:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8FC9591356; Sat,  7 Sep 2002 08:20:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 07A7B91229 for <[e-mail]>; Sat,  7 Sep 2002 08:20:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D6E815DE8E; Sat,  7 Sep 2002 08:20:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 608235DDE2 for <[e-mail]>; Sat,  7 Sep 2002 08:20:55 -0400 (EDT)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA01226; Sat, 7 Sep 2002 08:20:52 -0400 (EDT)
Date: Sat, 7 Sep 2002 08:20:52 -0400 (EDT)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, Mathew Richardson <[e-mail]>, [e-mail]
Subject: Re: bgp spec proposal 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

And further, the only RFC (that I know of) which requires this
has been moved to historical status.

Russ

On Fri, 6 Sep 2002, Yakov Rekhter wrote:

> > Which brings up another point:  What about the obscure rule that OSPF/BGP
> > router IDs should match?  Should this be added? 
> 
> No, as this belongs to OSPF/BGP interaction, and interaction
> between BGP and OSPF (as well as interaction between BGP and
> any other protocols) is outside the scope of this document.
> 
> Yakov.
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]] 
> > Sent: Friday, September 06, 2002 11:32 AM
> > To: Mathew Richardson
> > Cc: Natale, Jonathan; [e-mail]
> > Subject: Re: admin dist/gp spec proposal 
> > 
> > Mathew,
> > 
> > > > Natale, Jonathan <[e-mail]> [Fri, Sep 06, 2002 at
> > 10:53:40
> > AM -0400]:
> > > >Add sect. in bgp draft stating that ebgp routes should be preferred over
> > any
> > > >igp routes and any igp routes should be preferred over ibgp routes.  The
> > > >exception to this is igp summary routes may be preferred over ebgp
> > routes.
> > > 
> > > The EBGP vs. IBGP is already covered in section 9.1.2.2.  As to how
> > > BGP and non-BGP routes interact, I suspect that that really should remain
> > > largely a local policy matter.  A BCP is probably in order (does one
> > > on this topic already exist?)
> > 
> > The only document that was trying to address the issue of how BGP and 
> > non-BGP routes interact (BGP/OSPF interaction) was moved to Historic
> > some time ago.
> > 
> > Yakov.
> 

__________________________________
[e-mail] CCIE <>< Grace Alone




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA02491 for <[e-mail]>; Sat, 7 Sep 2002 03:08:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2E25C91213; Sat,  7 Sep 2002 03:08:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02CFE91356; Sat,  7 Sep 2002 03:07:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C251091213 for <[e-mail]>; Sat,  7 Sep 2002 03:03:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8AE6B5DF84; Sat,  7 Sep 2002 03:03:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 588255DE73 for <[e-mail]>; Sat,  7 Sep 2002 03:03:51 -0400 (EDT)
Received: from popserv2.redback.com (popserv2.redback.com [155.53.12.59]) by prattle.redback.com (Postfix) with ESMTP id A9E691DCC6C; Sat,  7 Sep 2002 00:03:50 -0700 (PDT)
Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv2.redback.com (Postfix) with ESMTP id 1B4FC979C1; Sat,  7 Sep 2002 00:03:49 -0700 (PDT)
To: Bill Fenner <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: BGP spec and IDR WG charter 
In-Reply-To: Message from Bill Fenner <[e-mail]>  of "Fri, 06 Sep 2002 16:51:22 PDT." <[e-mail]> 
Date: Sat, 07 Sep 2002 00:03:49 -0700
From: Enke Chen <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Bill,

> To: [e-mail]
> Subject: Re: BGP spec and IDR WG charter
> Cc: [e-mail]
> Date: Fri, 6 Sep 2002 16:51:22 -0700
> Versions: dmail (solaris) 2.5a/makemail 2.9d
> Sender: [e-mail]

[snip]

> 
> I admit I made a mistake forwarding draft-ietf-idr-md5-keys to the
> IESG without it being on the WG charter.  I'll try not to make such
> mistakes in the future.

There are several other IDR WG drafts that are not listed in the
charter, for example:

    draft-ietf-idr-cease-subcode-01.txt
    draft-ietf-idr-bgp-identifier-00.txt
    ....

Considering your statement, I suppose that all the IDR WG drafts
that are currently not listed in the WG charter need to be added
to avoid mistakes/delays in the future. Is this correct?

-- Enke





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA01775 for <[e-mail]>; Sat, 7 Sep 2002 02:50:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 89CFA9120F; Sat,  7 Sep 2002 02:49:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BCC591213; Sat,  7 Sep 2002 02:49:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5FBC69120F for <[e-mail]>; Sat,  7 Sep 2002 02:49:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3F1095DE85; Sat,  7 Sep 2002 02:49:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from prattle.redback.com (prattle.redback.com [155.53.12.9]) by segue.merit.edu (Postfix) with ESMTP id 141595DE73 for <[e-mail]>; Sat,  7 Sep 2002 02:49:50 -0400 (EDT)
Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 86AE81DCC6C; Fri,  6 Sep 2002 23:49:49 -0700 (PDT)
Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id EA44F7E6C1; Fri,  6 Sep 2002 23:49:48 -0700 (PDT)
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: admin dist/gp spec proposal 
In-Reply-To: Message from Jeffrey Haas <[e-mail]>  of "Fri, 06 Sep 2002 16:05:02 EDT." <[e-mail]> 
Date: Fri, 06 Sep 2002 23:49:48 -0700
From: Enke Chen <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff:

> Date: Fri, 6 Sep 2002 16:05:02 -0400
> From: Jeffrey Haas <[e-mail]>
> To: "Natale, Jonathan" <[e-mail]>
> Cc: [e-mail]
> Subject: Re: admin dist/gp spec proposal
> Message-ID: <[e-mail]>
> References: <[e-mail]>
> 

[snip]

> I should also point out that we have had the BGP Identifier arguments
> before.  We are trending this away from an actual IP to just an
> Identifer, which makes usage of it in ipv6 networks easier.

Indeed, and please take note of the IDR WG draft on the BGP Identifier:

     draft-ietf-idr-bgp-identifier-00.txt

-- Enke


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA16332 for <[e-mail]>; Fri, 6 Sep 2002 19:52:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 33E4491352; Fri,  6 Sep 2002 19:51:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C678291355; Fri,  6 Sep 2002 19:51:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 228CA91352 for <[e-mail]>; Fri,  6 Sep 2002 19:51:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 050025DE68; Fri,  6 Sep 2002 19:51:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by segue.merit.edu (Postfix) with ESMTP id C96D45DE1F for <[e-mail]>; Fri,  6 Sep 2002 19:51:29 -0400 (EDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 41EDA4CE7D; Fri,  6 Sep 2002 19:51:24 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id TAA02572; Fri, 6 Sep 2002 19:51:23 -0400 (EDT)
From: Bill Fenner <[e-mail]>
Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id QAA10182; Fri, 6 Sep 2002 16:51:22 -0700 (PDT)
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: [e-mail]
Subject: Re: BGP spec and IDR WG charter
Cc: [e-mail]
Date: Fri, 6 Sep 2002 16:51:22 -0700
Versions: dmail (solaris) 2.5a/makemail 2.9d
Sender: [e-mail]
Precedence: bulk

>1. Any reason the charter doesn't include BGP Graceful Restart ?
>
>2. Any reason the charter doesn't mention draft-ietf-idr-md5-keys-00.txt ?

I just modified the current charter (the one you and Sue sent me
in November last year), which doesn't contain either of these items.
If Graceful Restart should be in the charter, now would be an ideal time
to add it.  (Before now would have been an even better time -- it's the
WG chairs' responsibility to keep the charter and milestones up to date.)

I admit I made a mistake forwarding draft-ietf-idr-md5-keys to the
IESG without it being on the WG charter.  I'll try not to make such
mistakes in the future.

>3. The WG completed the work on the extended communities and submitted 
>   the draft to the IESG 3 weeks before you informed the WG
>   about the Routing Area Directors' decision not to forward any 
>   IDR documents for IESG considerations until the base BGP spec update 
>   is finished.

Actually, we're going to include extended communities in the work
that's held up.  There's something that I didn't understand about the
IETF process until I became an AD, and although we've tried to explain
it to some extent (e.g. Thomas and Allison's "life of an I-D" plenary
presentation last year) it's probably still not widely understood.
Working Groups submit documents to their ADs; the AD then reviews the
document, possibly asks the WG for changes, and then submits it to the
IESG for consideration.  Since I had not yet finished my review of this
document when we made this decision, we will not be forwarding it to the
IESG until the base spec is finished.

  Bill


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA08605 for <[e-mail]>; Fri, 6 Sep 2002 16:12:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 34B1B9133E; Fri,  6 Sep 2002 16:12:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05D6D9133F; Fri,  6 Sep 2002 16:12:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA3739133E for <[e-mail]>; Fri,  6 Sep 2002 16:12:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CA8C25DF65; Fri,  6 Sep 2002 16:12:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 401A05DE69 for <[e-mail]>; Fri,  6 Sep 2002 16:12:11 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g86KCAm26230; Fri, 6 Sep 2002 13:12:10 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: bgp draft review 
In-Reply-To: Your message of "Fri, 06 Sep 2002 15:46:01 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 06 Sep 2002 13:12:10 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Natale,

> What about explicitly disallowing private addresses?

why ?

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 QAA08339 for <[e-mail]>; Fri, 6 Sep 2002 16:05:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B1CB09133B; Fri,  6 Sep 2002 16:05:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E4419133E; Fri,  6 Sep 2002 16:05:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1CDA99133B for <[e-mail]>; Fri,  6 Sep 2002 16:05:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 04A5D5DE69; Fri,  6 Sep 2002 16:05:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 7778C5DE58 for <[e-mail]>; Fri,  6 Sep 2002 16:05:06 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g86K55w40459; Fri, 6 Sep 2002 16:05:05 -0400 (EDT) (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 g86K52G40452; Fri, 6 Sep 2002 16:05:02 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g86K52k04946; Fri, 6 Sep 2002 16:05:02 -0400 (EDT)
Date: Fri, 6 Sep 2002 16:05:02 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: admin dist/gp spec proposal
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 Fri, Sep 06, 2002 at 03:34:32PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Gentles,

Please strip off the additional people in the replies.  Two copies
of each e-mail to the list is excessive.

On Fri, Sep 06, 2002 at 03:34:32PM -0400, Natale, Jonathan wrote:
> Not that I am aware of.  There certainly is a case where they must be the
> same (cisco bgp w/ ospf, don't know all the details of how/why).  Maybe the
> local admin method of numbering is more versatile by allowing them to be
> different.  I think they should MUST be the same and in some implementation
> they are (gated, bay).

In the case of GateD, there's no integral reason why they *must* be
the same number.  It just is.  It probably makes the documentation
people happier. :-)

I should also point out that we have had the BGP Identifier arguments
before.  We are trending this away from an actual IP to just an
Identifer, which makes usage of it in ipv6 networks easier.

Please note the draft:
draft-dupont-durand-idr-ipv6-bgp-routerid-01.txt
(I don't know if this has been updated and is probably expired now.)

If being a general identifier is *not* going to be our trend,
I need to know for the MIB. :-)

-- 
Jeff Haas 
NextHop Technologies


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 QAA08332 for <[e-mail]>; Fri, 6 Sep 2002 16:05:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 51AF69133D; Fri,  6 Sep 2002 16:05:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 047229133C; Fri,  6 Sep 2002 16:05:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 385489133B for <[e-mail]>; Fri,  6 Sep 2002 16:05:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 221335DE58; Fri,  6 Sep 2002 16:05:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id CCA1A5DE69 for <[e-mail]>; Fri,  6 Sep 2002 16:05:04 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BWYK>; Fri, 6 Sep 2002 16:05:04 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: bgp draft comments
Date: Fri, 6 Sep 2002 16:04:57 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C255E0.ACC0D8B0"
Sender: [e-mail]
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C255E0.ACC0D8B0
Content-Type: text/plain

Maybe disallowing the installation of more specific routes of a direcly
attached networks.  This is a mis-config, but the more graceful way of
handling it seems to be to ignore the route, or only re-advertise it (don't
install it). This seems like a job for the INFORM.

 

Also, related to the above, what about allowing the
advertisement/origination of more specific routes of a locally reachable
route?  This seems to be legitimate, but is not allowed explicitly in the
draft.  Also it is referred to at
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122
t/122t11/ft11bpri.htm so there seems to be a need/current implementation. 


------_=_NextPart_001_01C255E0.ACC0D8B0
Content-Type: text/html

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">


<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Maybe disallowing the installation of more specific routes
of a direcly attached networks.&nbsp; This is a mis-config, but the more
graceful way of handling it seems to be to ignore the route, or only re-advertise
it (don't install it). This seems like a job for the INFORM.</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Also, related to the above, what about allowing the
advertisement/origination of more specific routes of a locally reachable route?&nbsp;
This seems to be legitimate, but is not allowed explicitly in the draft.&nbsp;
Also it is referred to at http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t11/ft11bpri.htm
so there seems to be a need/current implementation. </span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C255E0.ACC0D8B0--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA08131 for <[e-mail]>; Fri, 6 Sep 2002 15:59:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D19769133A; Fri,  6 Sep 2002 15:59:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9CBD69133B; Fri,  6 Sep 2002 15:59:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 78D7A9133A for <[e-mail]>; Fri,  6 Sep 2002 15:59:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 60AB75DF65; Fri,  6 Sep 2002 15:59:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id C8C4C5DEFA for <[e-mail]>; Fri,  6 Sep 2002 15:59:07 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g86Jx7m25045 for <[e-mail]>; Fri, 6 Sep 2002 12:59:07 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: BGP base spec
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 06 Sep 2002 12:59:07 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

The spec is *limited* to BGP protocol. It does *NOT* include
interaction between BGP and other protocols (e.g., OSPF, ISIS,
RIP). Therefore such issues as relation between BGP Identifier and
OSPF Router ID, redistribution of routing information between BGP
and any other protocol, route selection in the presence of multiple
protocols, etc... are outside the scope of this spec.  Please keep
this in mind when sending your comments on the base spec.

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 PAA08095 for <[e-mail]>; Fri, 6 Sep 2002 15:58:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 34E2591339; Fri,  6 Sep 2002 15:56:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1ECF9133B; Fri,  6 Sep 2002 15:56:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C52DF91339 for <[e-mail]>; Fri,  6 Sep 2002 15:56:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B289F5DF65; Fri,  6 Sep 2002 15:56:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 2D9235DE58 for <[e-mail]>; Fri,  6 Sep 2002 15:56:53 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06760; Fri, 6 Sep 2002 15:56:50 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA28255; Fri, 6 Sep 2002 15:56:52 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68Q3PLM>; Fri, 6 Sep 2002 15:56:51 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>
Cc: [e-mail]
Subject: RE: admin dist/gp spec proposal
Date: Fri, 6 Sep 2002 15:56:48 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

This is turning into a joke, do we want to tie loose ends or not?

:-)

> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Friday, September 06, 2002 3:50 PM
> To: 'Jeffrey Haas'
> Cc: [e-mail]
> Subject: RE: admin dist/gp spec proposal
> 
> 
> Possibly in 1812 (next life???)
> 
> :-)
> 
> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]] 
> Sent: Friday, September 06, 2002 3:48 PM
> To: Natale, Jonathan
> Subject: Re: admin dist/gp spec proposal
> 
> On Fri, Sep 06, 2002 at 01:54:23PM -0400, Natale, Jonathan wrote:
> > Right.  The bgp route will be the active route in the routing table
> > precisely because it (the ebgp learn route) has a lower 
> admin dist than
> the
> > igp learned route (which it would have got from the other 
> bgp router (both
> > bgp routers redistribute the route to igp so both also 
> receive it via
> igp)).
> 
> Oh.  Thats what I thought.
> 
> I never had much cause to inject my bgp routes into my igp so some
> of the consequences of that didn't make sense.
> 
> In discussing this with Matt, we seem to agree that talking about
> this in some document makes sense, but not in the base document.
> Do you agree?
> 
> -- 
> 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 PAA07926 for <[e-mail]>; Fri, 6 Sep 2002 15:52:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D378A91335; Fri,  6 Sep 2002 15:52:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0B6491336; Fri,  6 Sep 2002 15:52:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5333791335 for <[e-mail]>; Fri,  6 Sep 2002 15:52:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 383F25DEFA; Fri,  6 Sep 2002 15:52:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id C8CDE5DE58 for <[e-mail]>; Fri,  6 Sep 2002 15:52:34 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BWW3>; Fri, 6 Sep 2002 15:52:34 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Fri, 6 Sep 2002 15:52:28 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

That's what I was going to say.  Maybe this can be slated for rfc1812 [in
the next life].

:-)

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Friday, September 06, 2002 3:48 PM
To: Abarbanel, Benjamin
Cc: Natale, Jonathan; [e-mail]
Subject: Re: admin dist/gp spec proposal 

> Is there something that replaces them to go to for technical correctness?

not to my knowledge.

Yakov.

> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Friday, September 06, 2002 3:43 PM
> > To: Natale, Jonathan
> > Cc: 'Abarbanel, Benjamin'; [e-mail]
> > Subject: Re: admin dist/gp spec proposal 
> > 
> > 
> > Natale,
> > 
> > > 1745 and 1403 are historic
> > 
> > correct. And with this in mind I would suggest we stop 
> > reference/pointing
> > to them.
> > 
> > Yakov.
> > 
> > > -----Original Message-----
> > > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > > Sent: Friday, September 06, 2002 3:38 PM
> > > To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Yakov Rekhter'
> > > Cc: [e-mail]
> > > Subject: RE: admin dist/gp spec proposal 
> > > 
> > > 
> > >  
> > > > 
> > > > Not that I am aware of.  There certainly is a case where they 
> > > > must be the
> > > > same (cisco bgp w/ ospf, don't know all the details of 
> > > > how/why).  
> > > 
> > > RFC1745, and RFC1403 tell you why they must be the same.
> > > 
> > > > Maybe the local admin method of numbering is more 
> > versatile by allowing 
> > > > them to be different.  I think they should MUST be the 
> > same and in some 
> > > > implementation they are (gated, bay).
> > > > 
> > > > -----Original Message-----
> > > > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > > > Sent: Friday, September 06, 2002 3:29 PM
> > > > To: 'Yakov Rekhter'; Abarbanel, Benjamin
> > > > Cc: Natale, Jonathan; [e-mail]
> > > > Subject: RE: admin dist/gp spec proposal 
> > > > 
> > > > 
> > > > > 
> > > > > > I would like to rephrase my statement on one sentence.
> > > > > > 
> > > > > > " BTW. BGP Identifier is a vague way of naming what 
> > we know as the
> > > > > >   Router-ID in all other IP related protocols."
> > > > > 
> > > > > This is *technically* incorrect. 
> > > > >
> > > > Is there a case where the BGP Identifier, should or must be 
> > > > different than
> > > > the Router-ID for the routing system to work correctly?
> > > > 
> > > > Ben
> > > > 
> > > >  
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Abarbanel, Benjamin 
> > > > [mailto:[e-mail]]
> > > > > > > Sent: Friday, September 06, 2002 3:01 PM
> > > > > > > To: 'Yakov Rekhter'; Natale, Jonathan
> > > > > > > Cc: [e-mail]
> > > > > > > Subject: RE: admin dist/gp spec proposal 
> > > > > > > 
> > > > > > > 
> > > > > > > Yakov:
> > > > > > >   There is no reference to RFC1812 in the reference section 
> > > > > > > nor references 
> > > > > > > to this spec where appropriate in the BGP relevant 
> > > > > > > discussions. As was 
> > > > > > > earlier mentioned. At least we need to tie the thread 
> > > > > between the two
> > > > > > > specs so people know what the assumptions are.  
> > > > > > > 
> > > > > > > BTW. BGP Identifier is a very misleading way of naming what 
> > > > > > > we know as the
> > > > > > > Router ID in all other protocols. I would like to 
> > suggest we 
> > > > > > > enhance its 
> > > > > > > description as follows:
> > > > > > > 
> > > > > > > Current statement:
> > > > > > > ==================
> > > > > > > "BGP Identifier:
> > > > > > 
> > > > > >          This 4-octet unsigned integer indicates the BGP 
> > > > > Identifier of
> > > > > > >          the sender. A given BGP speaker sets the value 
> > > > of its BGP
> > > > > > >          Identifier to an IP address assigned to that BGP 
> > > > > > > speaker.  The
> > > > > > >          value of the BGP Identifier is determined 
> > on startup 
> > > > > > > and is the
> > > > > > >          same for every local interface and every 
> > BGP peer. "
> > > > > > > 
> > > > > > > New Statement:
> > > > > > > ==============
> > > > > > > "BGP Identifier:
> > > > > > > 
> > > > > > >          This 4-octet unsigned integer indicates the BGP 
> > > > > Identifier of
> > > > > > >          the sender. A given BGP speaker sets the value 
> > > > of its BGP
> > > > > > >          Identifier also known as the Router-ID, to an IP 
> > > > > > > address assigned 
> > > > > > >          to that BGP speaker. The value of the BGP 
> > > > Identifier is 
> > > > > > >          determined on startup and is the same for every 
> > > > > > > local interface 
> > > > > > >          and every BGP peer and other IP related protocols. 
> > > > > > > See [x],[y] for 
> > > > > > >          more details on Router-ID useage between BGP and 
> > > > > > > other protocols."
> > > > > > > 
> > > > > > > Where x = RFC1403,
> > > > > > >       y = RFC1745
> > > > > > > 
> > > > > > > Ben
> > > > > > > > -----Original Message-----
> > > > > > > > From: Yakov Rekhter [mailto:[e-mail]]
> > > > > > > > Sent: Friday, September 06, 2002 2:31 PM
> > > > > > > > To: Natale, Jonathan
> > > > > > > > Cc: [e-mail]
> > > > > > > > Subject: Re: admin dist/gp spec proposal 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Natale,
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Abarbanel, Benjamin 
> > > > > [mailto:[e-mail]] 
> > > > > > > > > Sent: Friday, September 06, 2002 1:49 PM
> > > > > > > > > To: 'Natale, Jonathan'
> > > > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > > > 
> > > > > > > > > Jonathan:
> > > > > > > > > Forward this message to the IDR list. I think we 
> > > > dropped off.
> > > > > > > > > 
> > > > > > > > > Ben
> > > > > > > > > 
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Natale, Jonathan 
> > [mailto:[e-mail]]
> > > > > > > > > > Sent: Friday, September 06, 2002 1:46 PM
> > > > > > > > > > To: 'Abarbanel, Benjamin'
> > > > > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > I agree.  The default values of the various 
> > > > > protocols as they 
> > > > > > > > > > are currently
> > > > > > > > > > implemented make sense:
> > > > > > > > > > Connected
> > > > > > > > > > Static
> > > > > > > > > > Ebgp
> > > > > > > > > > Igp's
> > > > > > > > > > Ibgp
> > > > > > > > > > 
> > > > > > > > > > ...they should be documented in 1812 ideally, but 
> > > > > putting it 
> > > > > > > > > > in 1771 would
> > > > > > > > > > not hurt.  Added a phrase to indicate that they 
> > > > may be user 
> > > > > > > > > > configurable is
> > > > > > > > > > good too.
> > > > > > > > 
> > > > > > > > Perhaps it is time to update 1812. But let's not use BGP
> > > > > > > > spec as a replacement for updating 1812 - it is not.
> > > > > > > > 
> > > > > > > > Yakov.
> > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Abarbanel, Benjamin 
> > > > > > [mailto:[e-mail]] 
> > > > > > > > > Sent: Friday, September 06, 2002 11:39 AM
> > > > > > > > > To: 'Mathew Richardson'; Natale, Jonathan
> > > > > > > > > Cc: [e-mail]
> > > > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > >  
> > > > > > > > > > 
> > > > > > > > > > > Natale, Jonathan <[e-mail]> 
> > > > > [Fri, Sep 06, 
> > > > > > > > > > 2002 at 10:53:40AM -0400]:
> > > > > > > > > > >Add sect. in bgp draft stating that ebgp routes 
> > > > should be 
> > > > > > > > > > preferred over any
> > > > > > > > > > >igp routes and any igp routes should be preferred 
> > > > > over ibgp 
> > > > > > > > > routes.  The
> > > > > > > > > > >exception to this is igp summary routes may 
> > be preferred 
> > > > > > > > > > over ebgp routes.
> > > > > > > > > > 
> > > > > > > > > > The EBGP vs. IBGP is already covered in section 
> > > > > > > 9.1.2.2.  As to how
> > > > > > > > > > BGP and non-BGP routes interact, I suspect that 
> > > > that really 
> > > > > > > > > > should remain
> > > > > > > > > > largely a local policy matter.  A BCP is probably in 
> > > > > > > order (does one
> > > > > > > > > > on this topic already exist?)
> > > > > > > > > >
> > > > > > > > > Clearly the BGP and non-BGP route competition 
> > for dominance 
> > > > > > > > > in the routing
> > > > > > > > > table is firstly, defaulted and secondly policy 
> > > > over-written 
> > > > > > > > > by a local
> > > > > > > > > router administrator.  Just some mention of operational 
> > > > > > > > > impact by turning 
> > > > > > > > > some policy knobs and changing certain route selection 
> > > > > > > > > decisions and their 
> > > > > > > > > control plane impacts will be nice. Maybe this 
> > belongs in a 
> > > > > > > > different spec.
> > > > > > > > > 
> > > > > > > > > I find spreading the knowledge across many specs a bit 
> > > > > > > inconvenient.
> > > > > > > > > 
> > > > > > > > > IMHO,
> > > > > > > > > Ben
> > > > > > > > > 
> > > > > > > 
> > > > > 
> > > > 
> > 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA07858 for <[e-mail]>; Fri, 6 Sep 2002 15:52:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A825791337; Fri,  6 Sep 2002 15:51:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 56E6F91338; Fri,  6 Sep 2002 15:51:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CF00791337 for <[e-mail]>; Fri,  6 Sep 2002 15:51:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B108E5DEFA; Fri,  6 Sep 2002 15:51:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id EA8725DE58 for <[e-mail]>; Fri,  6 Sep 2002 15:51:46 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g86JpgS40012; Fri, 6 Sep 2002 15:51:42 -0400 (EDT) (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 g86JpcG40000; Fri, 6 Sep 2002 15:51:38 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g86JpcR26416; Fri, 6 Sep 2002 15:51:38 -0400 (EDT)
Date: Fri, 6 Sep 2002 15:51:38 -0400
From: "'Mathew Richardson'" <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "Cambria, Mike" <[e-mail]>, "'Abarbanel, Benjamin'" <[e-mail]>, [e-mail]
Subject: Re: Proxy: comments on section 9.1.3
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

> Natale, Jonathan <[e-mail]> [Fri, Sep 06, 2002 at 02:14:53PM -0400]:
>I don't think that is necessary.  Somewhere (not sure where) it already says
>there can only be 1 best route, right?

yes, but it certainly doesn't hurt to make things explicit.

>-----Original Message-----
>From: 'Mathew Richardson' [mailto:[e-mail]] 
>Sent: Friday, September 06, 2002 12:18 PM
>To: Cambria, Mike
>Cc: 'Abarbanel, Benjamin'; [e-mail]
>Subject: Re: Proxy: comments on section 9.1.3
>
>> Cambria, Mike <[e-mail]> [Fri, Sep 06, 2002 at 11:53:53AM
>-0400]:
>>
>>(Pretending that I'm) reading the draft for the first time...
>>
>>Your comment:
>>
>>Somewhere in section 9.1.x, Do we want to mention the fact that the best 
>>Loc-RIB BGP route for a given destination is still advertised to outgoing 
>>peers via the Adj-RIB-out after it passes the outbound policy filtering,
>>even though it is not really used for forwarding?
>>
>>and the text in 9.1.3 can be read as a contraction of section 2 (when only
>>considering the base document, no route reflectors, route servers etc.):
>>
>>"... one must focus on the rule that a BGP speaker advertises to its peers
>>(other BGP speakers which it communicates with) in neighboring ASs only
>>those routes that it itself uses."
>
>I thought that that was in there somewhere :)  I guess I've just gotten
>in to the bad habit of skipping the intro and going straight to the
>"good stuff" :)
>
>>If, in the scope of an implementation of only what is specified in this
>>draft, one can advertise to a peer what is in Loc-RIB but not the Route
>>Table, the text in section 2 should be clarified.  Otherwise, the text in
>>9.1.3 (and your comment) should be clarified, as it doesn't mention
>anything
>>about the route table.
>
>How about changing the paragraph after c) in 9.1.2 to:
>
>  The local speaker SHALL then install that route in the Loc-RIB,
>  replacing any route to the same destination that is currently being
>  held in the Loc-RIB.  This route SHALL then also be installed in
>  the BGP speakers forwarding table.
>
><snip>
>
>I personally much prefer this.  It helps keep the base spec focused
>on describing the base protocol.
>
>mrr

mrr


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 PAA07850 for <[e-mail]>; Fri, 6 Sep 2002 15:52:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 09B4891334; Fri,  6 Sep 2002 15:51:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C705191335; Fri,  6 Sep 2002 15:51:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2D4F791334 for <[e-mail]>; Fri,  6 Sep 2002 15:51:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 14A805DEFA; Fri,  6 Sep 2002 15:51:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id BE4505DE58 for <[e-mail]>; Fri,  6 Sep 2002 15:51:41 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06411; Fri, 6 Sep 2002 15:51:39 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA27226; Fri, 6 Sep 2002 15:51:41 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68Q3PDL>; Fri, 6 Sep 2002 15:51:40 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Fri, 6 Sep 2002 15:51:37 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

So how can I be technically incorrect?

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Friday, September 06, 2002 3:48 PM
> To: Abarbanel, Benjamin
> Cc: Natale, Jonathan; [e-mail]
> Subject: Re: admin dist/gp spec proposal 
> 
> 
> > Is there something that replaces them to go to for 
> technical correctness?
> 
> not to my knowledge.
> 
> Yakov.
> 
> > 
> > > -----Original Message-----
> > > From: Yakov Rekhter [mailto:[e-mail]]
> > > Sent: Friday, September 06, 2002 3:43 PM
> > > To: Natale, Jonathan
> > > Cc: 'Abarbanel, Benjamin'; [e-mail]
> > > Subject: Re: admin dist/gp spec proposal 
> > > 
> > > 
> > > Natale,
> > > 
> > > > 1745 and 1403 are historic
> > > 
> > > correct. And with this in mind I would suggest we stop 
> > > reference/pointing
> > > to them.
> > > 
> > > Yakov.
> > > 
> > > > -----Original Message-----
> > > > From: Abarbanel, Benjamin 
> [mailto:[e-mail]] 
> > > > Sent: Friday, September 06, 2002 3:38 PM
> > > > To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Yakov Rekhter'
> > > > Cc: [e-mail]
> > > > Subject: RE: admin dist/gp spec proposal 
> > > > 
> > > > 
> > > >  
> > > > > 
> > > > > Not that I am aware of.  There certainly is a case where they 
> > > > > must be the
> > > > > same (cisco bgp w/ ospf, don't know all the details of 
> > > > > how/why).  
> > > > 
> > > > RFC1745, and RFC1403 tell you why they must be the same.
> > > > 
> > > > > Maybe the local admin method of numbering is more 
> > > versatile by allowing 
> > > > > them to be different.  I think they should MUST be the 
> > > same and in some 
> > > > > implementation they are (gated, bay).
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Abarbanel, Benjamin 
> [mailto:[e-mail]] 
> > > > > Sent: Friday, September 06, 2002 3:29 PM
> > > > > To: 'Yakov Rekhter'; Abarbanel, Benjamin
> > > > > Cc: Natale, Jonathan; [e-mail]
> > > > > Subject: RE: admin dist/gp spec proposal 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > > I would like to rephrase my statement on one sentence.
> > > > > > > 
> > > > > > > " BTW. BGP Identifier is a vague way of naming what 
> > > we know as the
> > > > > > >   Router-ID in all other IP related protocols."
> > > > > > 
> > > > > > This is *technically* incorrect. 
> > > > > >
> > > > > Is there a case where the BGP Identifier, should or must be 
> > > > > different than
> > > > > the Router-ID for the routing system to work correctly?
> > > > > 
> > > > > Ben
> > > > > 
> > > > >  
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Abarbanel, Benjamin 
> > > > > [mailto:[e-mail]]
> > > > > > > > Sent: Friday, September 06, 2002 3:01 PM
> > > > > > > > To: 'Yakov Rekhter'; Natale, Jonathan
> > > > > > > > Cc: [e-mail]
> > > > > > > > Subject: RE: admin dist/gp spec proposal 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Yakov:
> > > > > > > >   There is no reference to RFC1812 in the 
> reference section 
> > > > > > > > nor references 
> > > > > > > > to this spec where appropriate in the BGP relevant 
> > > > > > > > discussions. As was 
> > > > > > > > earlier mentioned. At least we need to tie the thread 
> > > > > > between the two
> > > > > > > > specs so people know what the assumptions are.  
> > > > > > > > 
> > > > > > > > BTW. BGP Identifier is a very misleading way of 
> naming what 
> > > > > > > > we know as the
> > > > > > > > Router ID in all other protocols. I would like to 
> > > suggest we 
> > > > > > > > enhance its 
> > > > > > > > description as follows:
> > > > > > > > 
> > > > > > > > Current statement:
> > > > > > > > ==================
> > > > > > > > "BGP Identifier:
> > > > > > > 
> > > > > > >          This 4-octet unsigned integer indicates the BGP 
> > > > > > Identifier of
> > > > > > > >          the sender. A given BGP speaker sets the value 
> > > > > of its BGP
> > > > > > > >          Identifier to an IP address assigned 
> to that BGP 
> > > > > > > > speaker.  The
> > > > > > > >          value of the BGP Identifier is determined 
> > > on startup 
> > > > > > > > and is the
> > > > > > > >          same for every local interface and every 
> > > BGP peer. "
> > > > > > > > 
> > > > > > > > New Statement:
> > > > > > > > ==============
> > > > > > > > "BGP Identifier:
> > > > > > > > 
> > > > > > > >          This 4-octet unsigned integer 
> indicates the BGP 
> > > > > > Identifier of
> > > > > > > >          the sender. A given BGP speaker sets the value 
> > > > > of its BGP
> > > > > > > >          Identifier also known as the 
> Router-ID, to an IP 
> > > > > > > > address assigned 
> > > > > > > >          to that BGP speaker. The value of the BGP 
> > > > > Identifier is 
> > > > > > > >          determined on startup and is the same 
> for every 
> > > > > > > > local interface 
> > > > > > > >          and every BGP peer and other IP 
> related protocols. 
> > > > > > > > See [x],[y] for 
> > > > > > > >          more details on Router-ID useage 
> between BGP and 
> > > > > > > > other protocols."
> > > > > > > > 
> > > > > > > > Where x = RFC1403,
> > > > > > > >       y = RFC1745
> > > > > > > > 
> > > > > > > > Ben
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Yakov Rekhter [mailto:[e-mail]]
> > > > > > > > > Sent: Friday, September 06, 2002 2:31 PM
> > > > > > > > > To: Natale, Jonathan
> > > > > > > > > Cc: [e-mail]
> > > > > > > > > Subject: Re: admin dist/gp spec proposal 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Natale,
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Abarbanel, Benjamin 
> > > > > > [mailto:[e-mail]] 
> > > > > > > > > > Sent: Friday, September 06, 2002 1:49 PM
> > > > > > > > > > To: 'Natale, Jonathan'
> > > > > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > > > > 
> > > > > > > > > > Jonathan:
> > > > > > > > > > Forward this message to the IDR list. I think we 
> > > > > dropped off.
> > > > > > > > > > 
> > > > > > > > > > Ben
> > > > > > > > > > 
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: Natale, Jonathan 
> > > [mailto:[e-mail]]
> > > > > > > > > > > Sent: Friday, September 06, 2002 1:46 PM
> > > > > > > > > > > To: 'Abarbanel, Benjamin'
> > > > > > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > I agree.  The default values of the various 
> > > > > > protocols as they 
> > > > > > > > > > > are currently
> > > > > > > > > > > implemented make sense:
> > > > > > > > > > > Connected
> > > > > > > > > > > Static
> > > > > > > > > > > Ebgp
> > > > > > > > > > > Igp's
> > > > > > > > > > > Ibgp
> > > > > > > > > > > 
> > > > > > > > > > > ...they should be documented in 1812 ideally, but 
> > > > > > putting it 
> > > > > > > > > > > in 1771 would
> > > > > > > > > > > not hurt.  Added a phrase to indicate that they 
> > > > > may be user 
> > > > > > > > > > > configurable is
> > > > > > > > > > > good too.
> > > > > > > > > 
> > > > > > > > > Perhaps it is time to update 1812. But let's 
> not use BGP
> > > > > > > > > spec as a replacement for updating 1812 - it is not.
> > > > > > > > > 
> > > > > > > > > Yakov.
> > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > -----Original Message-----
> > > > > > > > > > > From: Abarbanel, Benjamin 
> > > > > > > [mailto:[e-mail]] 
> > > > > > > > > > Sent: Friday, September 06, 2002 11:39 AM
> > > > > > > > > > To: 'Mathew Richardson'; Natale, Jonathan
> > > > > > > > > > Cc: [e-mail]
> > > > > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > >  
> > > > > > > > > > > 
> > > > > > > > > > > > Natale, Jonathan <[e-mail]> 
> > > > > > [Fri, Sep 06, 
> > > > > > > > > > > 2002 at 10:53:40AM -0400]:
> > > > > > > > > > > >Add sect. in bgp draft stating that ebgp routes 
> > > > > should be 
> > > > > > > > > > > preferred over any
> > > > > > > > > > > >igp routes and any igp routes should be 
> preferred 
> > > > > > over ibgp 
> > > > > > > > > > routes.  The
> > > > > > > > > > > >exception to this is igp summary routes may 
> > > be preferred 
> > > > > > > > > > > over ebgp routes.
> > > > > > > > > > > 
> > > > > > > > > > > The EBGP vs. IBGP is already covered in section 
> > > > > > > > 9.1.2.2.  As to how
> > > > > > > > > > > BGP and non-BGP routes interact, I suspect that 
> > > > > that really 
> > > > > > > > > > > should remain
> > > > > > > > > > > largely a local policy matter.  A BCP is 
> probably in 
> > > > > > > > order (does one
> > > > > > > > > > > on this topic already exist?)
> > > > > > > > > > >
> > > > > > > > > > Clearly the BGP and non-BGP route competition 
> > > for dominance 
> > > > > > > > > > in the routing
> > > > > > > > > > table is firstly, defaulted and secondly policy 
> > > > > over-written 
> > > > > > > > > > by a local
> > > > > > > > > > router administrator.  Just some mention of 
> operational 
> > > > > > > > > > impact by turning 
> > > > > > > > > > some policy knobs and changing certain 
> route selection 
> > > > > > > > > > decisions and their 
> > > > > > > > > > control plane impacts will be nice. Maybe this 
> > > belongs in a 
> > > > > > > > > different spec.
> > > > > > > > > > 
> > > > > > > > > > I find spreading the knowledge across many 
> specs a bit 
> > > > > > > > inconvenient.
> > > > > > > > > > 
> > > > > > > > > > IMHO,
> > > > > > > > > > Ben
> > > > > > > > > > 
> > > > > > > > 
> > > > > > 
> > > > > 
> > > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA07796 for <[e-mail]>; Fri, 6 Sep 2002 15:50:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D592491330; Fri,  6 Sep 2002 15:50:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A4D6991334; Fri,  6 Sep 2002 15:50:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1B88391330 for <[e-mail]>; Fri,  6 Sep 2002 15:50:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 00D725DEFA; Fri,  6 Sep 2002 15:50:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id AD9095DE58 for <[e-mail]>; Fri,  6 Sep 2002 15:50:04 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BWWA>; Fri, 6 Sep 2002 15:50:04 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>
Cc: [e-mail]
Subject: RE: admin dist/gp spec proposal
Date: Fri, 6 Sep 2002 15:50:03 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Possibly in 1812 (next life???)

:-)

-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Friday, September 06, 2002 3:48 PM
To: Natale, Jonathan
Subject: Re: admin dist/gp spec proposal

On Fri, Sep 06, 2002 at 01:54:23PM -0400, Natale, Jonathan wrote:
> Right.  The bgp route will be the active route in the routing table
> precisely because it (the ebgp learn route) has a lower admin dist than
the
> igp learned route (which it would have got from the other bgp router (both
> bgp routers redistribute the route to igp so both also receive it via
igp)).

Oh.  Thats what I thought.

I never had much cause to inject my bgp routes into my igp so some
of the consequences of that didn't make sense.

In discussing this with Matt, we seem to agree that talking about
this in some document makes sense, but not in the base document.
Do you agree?

-- 
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 PAA07773 for <[e-mail]>; Fri, 6 Sep 2002 15:50:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C070A9132D; Fri,  6 Sep 2002 15:49:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7116B91330; Fri,  6 Sep 2002 15:49:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15AE39132D for <[e-mail]>; Fri,  6 Sep 2002 15:47:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E7E415DEFA; Fri,  6 Sep 2002 15:47:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 734F35DE58 for <[e-mail]>; Fri,  6 Sep 2002 15:47:52 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g86Jlnm24325; Fri, 6 Sep 2002 12:47:49 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: Re: admin dist/gp spec proposal 
In-Reply-To: Your message of "Fri, 06 Sep 2002 15:45:39 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 06 Sep 2002 12:47:49 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Is there something that replaces them to go to for technical correctness?

not to my knowledge.

Yakov.

> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Friday, September 06, 2002 3:43 PM
> > To: Natale, Jonathan
> > Cc: 'Abarbanel, Benjamin'; [e-mail]
> > Subject: Re: admin dist/gp spec proposal 
> > 
> > 
> > Natale,
> > 
> > > 1745 and 1403 are historic
> > 
> > correct. And with this in mind I would suggest we stop 
> > reference/pointing
> > to them.
> > 
> > Yakov.
> > 
> > > -----Original Message-----
> > > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > > Sent: Friday, September 06, 2002 3:38 PM
> > > To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Yakov Rekhter'
> > > Cc: [e-mail]
> > > Subject: RE: admin dist/gp spec proposal 
> > > 
> > > 
> > >  
> > > > 
> > > > Not that I am aware of.  There certainly is a case where they 
> > > > must be the
> > > > same (cisco bgp w/ ospf, don't know all the details of 
> > > > how/why).  
> > > 
> > > RFC1745, and RFC1403 tell you why they must be the same.
> > > 
> > > > Maybe the local admin method of numbering is more 
> > versatile by allowing 
> > > > them to be different.  I think they should MUST be the 
> > same and in some 
> > > > implementation they are (gated, bay).
> > > > 
> > > > -----Original Message-----
> > > > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > > > Sent: Friday, September 06, 2002 3:29 PM
> > > > To: 'Yakov Rekhter'; Abarbanel, Benjamin
> > > > Cc: Natale, Jonathan; [e-mail]
> > > > Subject: RE: admin dist/gp spec proposal 
> > > > 
> > > > 
> > > > > 
> > > > > > I would like to rephrase my statement on one sentence.
> > > > > > 
> > > > > > " BTW. BGP Identifier is a vague way of naming what 
> > we know as the
> > > > > >   Router-ID in all other IP related protocols."
> > > > > 
> > > > > This is *technically* incorrect. 
> > > > >
> > > > Is there a case where the BGP Identifier, should or must be 
> > > > different than
> > > > the Router-ID for the routing system to work correctly?
> > > > 
> > > > Ben
> > > > 
> > > >  
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Abarbanel, Benjamin 
> > > > [mailto:[e-mail]]
> > > > > > > Sent: Friday, September 06, 2002 3:01 PM
> > > > > > > To: 'Yakov Rekhter'; Natale, Jonathan
> > > > > > > Cc: [e-mail]
> > > > > > > Subject: RE: admin dist/gp spec proposal 
> > > > > > > 
> > > > > > > 
> > > > > > > Yakov:
> > > > > > >   There is no reference to RFC1812 in the reference section 
> > > > > > > nor references 
> > > > > > > to this spec where appropriate in the BGP relevant 
> > > > > > > discussions. As was 
> > > > > > > earlier mentioned. At least we need to tie the thread 
> > > > > between the two
> > > > > > > specs so people know what the assumptions are.  
> > > > > > > 
> > > > > > > BTW. BGP Identifier is a very misleading way of naming what 
> > > > > > > we know as the
> > > > > > > Router ID in all other protocols. I would like to 
> > suggest we 
> > > > > > > enhance its 
> > > > > > > description as follows:
> > > > > > > 
> > > > > > > Current statement:
> > > > > > > ==================
> > > > > > > "BGP Identifier:
> > > > > > 
> > > > > >          This 4-octet unsigned integer indicates the BGP 
> > > > > Identifier of
> > > > > > >          the sender. A given BGP speaker sets the value 
> > > > of its BGP
> > > > > > >          Identifier to an IP address assigned to that BGP 
> > > > > > > speaker.  The
> > > > > > >          value of the BGP Identifier is determined 
> > on startup 
> > > > > > > and is the
> > > > > > >          same for every local interface and every 
> > BGP peer. "
> > > > > > > 
> > > > > > > New Statement:
> > > > > > > ==============
> > > > > > > "BGP Identifier:
> > > > > > > 
> > > > > > >          This 4-octet unsigned integer indicates the BGP 
> > > > > Identifier of
> > > > > > >          the sender. A given BGP speaker sets the value 
> > > > of its BGP
> > > > > > >          Identifier also known as the Router-ID, to an IP 
> > > > > > > address assigned 
> > > > > > >          to that BGP speaker. The value of the BGP 
> > > > Identifier is 
> > > > > > >          determined on startup and is the same for every 
> > > > > > > local interface 
> > > > > > >          and every BGP peer and other IP related protocols. 
> > > > > > > See [x],[y] for 
> > > > > > >          more details on Router-ID useage between BGP and 
> > > > > > > other protocols."
> > > > > > > 
> > > > > > > Where x = RFC1403,
> > > > > > >       y = RFC1745
> > > > > > > 
> > > > > > > Ben
> > > > > > > > -----Original Message-----
> > > > > > > > From: Yakov Rekhter [mailto:[e-mail]]
> > > > > > > > Sent: Friday, September 06, 2002 2:31 PM
> > > > > > > > To: Natale, Jonathan
> > > > > > > > Cc: [e-mail]
> > > > > > > > Subject: Re: admin dist/gp spec proposal 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Natale,
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Abarbanel, Benjamin 
> > > > > [mailto:[e-mail]] 
> > > > > > > > > Sent: Friday, September 06, 2002 1:49 PM
> > > > > > > > > To: 'Natale, Jonathan'
> > > > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > > > 
> > > > > > > > > Jonathan:
> > > > > > > > > Forward this message to the IDR list. I think we 
> > > > dropped off.
> > > > > > > > > 
> > > > > > > > > Ben
> > > > > > > > > 
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Natale, Jonathan 
> > [mailto:[e-mail]]
> > > > > > > > > > Sent: Friday, September 06, 2002 1:46 PM
> > > > > > > > > > To: 'Abarbanel, Benjamin'
> > > > > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > I agree.  The default values of the various 
> > > > > protocols as they 
> > > > > > > > > > are currently
> > > > > > > > > > implemented make sense:
> > > > > > > > > > Connected
> > > > > > > > > > Static
> > > > > > > > > > Ebgp
> > > > > > > > > > Igp's
> > > > > > > > > > Ibgp
> > > > > > > > > > 
> > > > > > > > > > ...they should be documented in 1812 ideally, but 
> > > > > putting it 
> > > > > > > > > > in 1771 would
> > > > > > > > > > not hurt.  Added a phrase to indicate that they 
> > > > may be user 
> > > > > > > > > > configurable is
> > > > > > > > > > good too.
> > > > > > > > 
> > > > > > > > Perhaps it is time to update 1812. But let's not use BGP
> > > > > > > > spec as a replacement for updating 1812 - it is not.
> > > > > > > > 
> > > > > > > > Yakov.
> > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Abarbanel, Benjamin 
> > > > > > [mailto:[e-mail]] 
> > > > > > > > > Sent: Friday, September 06, 2002 11:39 AM
> > > > > > > > > To: 'Mathew Richardson'; Natale, Jonathan
> > > > > > > > > Cc: [e-mail]
> > > > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > >  
> > > > > > > > > > 
> > > > > > > > > > > Natale, Jonathan <[e-mail]> 
> > > > > [Fri, Sep 06, 
> > > > > > > > > > 2002 at 10:53:40AM -0400]:
> > > > > > > > > > >Add sect. in bgp draft stating that ebgp routes 
> > > > should be 
> > > > > > > > > > preferred over any
> > > > > > > > > > >igp routes and any igp routes should be preferred 
> > > > > over ibgp 
> > > > > > > > > routes.  The
> > > > > > > > > > >exception to this is igp summary routes may 
> > be preferred 
> > > > > > > > > > over ebgp routes.
> > > > > > > > > > 
> > > > > > > > > > The EBGP vs. IBGP is already covered in section 
> > > > > > > 9.1.2.2.  As to how
> > > > > > > > > > BGP and non-BGP routes interact, I suspect that 
> > > > that really 
> > > > > > > > > > should remain
> > > > > > > > > > largely a local policy matter.  A BCP is probably in 
> > > > > > > order (does one
> > > > > > > > > > on this topic already exist?)
> > > > > > > > > >
> > > > > > > > > Clearly the BGP and non-BGP route competition 
> > for dominance 
> > > > > > > > > in the routing
> > > > > > > > > table is firstly, defaulted and secondly policy 
> > > > over-written 
> > > > > > > > > by a local
> > > > > > > > > router administrator.  Just some mention of operational 
> > > > > > > > > impact by turning 
> > > > > > > > > some policy knobs and changing certain route selection 
> > > > > > > > > decisions and their 
> > > > > > > > > control plane impacts will be nice. Maybe this 
> > belongs in a 
> > > > > > > > different spec.
> > > > > > > > > 
> > > > > > > > > I find spreading the knowledge across many specs a bit 
> > > > > > > inconvenient.
> > > > > > > > > 
> > > > > > > > > IMHO,
> > > > > > > > > Ben
> > > > > > > > > 
> > > > > > > 
> > > > > 
> > > > 
> > 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA07758 for <[e-mail]>; Fri, 6 Sep 2002 15:49:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A882F91332; Fri,  6 Sep 2002 15:47:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF45B91330; Fri,  6 Sep 2002 15:46:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 37FEC91334 for <[e-mail]>; Fri,  6 Sep 2002 15:46:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1E8BF5DEFA; Fri,  6 Sep 2002 15:46:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id CA8545DE58 for <[e-mail]>; Fri,  6 Sep 2002 15:46:04 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BWV3>; Fri, 6 Sep 2002 15:46:04 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: bgp draft review
Date: Fri, 6 Sep 2002 15:46:01 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C255DE.07673460"
Sender: [e-mail]
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C255DE.07673460
Content-Type: text/plain

What about explicitly disallowing private addresses?


------_=_NextPart_001_01C255DE.07673460
Content-Type: text/html

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">


<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>What about explicitly disallowing private addresses?</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C255DE.07673460--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA07695 for <[e-mail]>; Fri, 6 Sep 2002 15:47:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7F78B91331; Fri,  6 Sep 2002 15:46:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8ACCC91332; Fri,  6 Sep 2002 15:46:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E9A4F91331 for <[e-mail]>; Fri,  6 Sep 2002 15:45:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D33FD5DEFA; Fri,  6 Sep 2002 15:45:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 89A9C5DE58 for <[e-mail]>; Fri,  6 Sep 2002 15:45:41 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA06047; Fri, 6 Sep 2002 15:45:39 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA26156; Fri, 6 Sep 2002 15:45:40 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68Q336C>; Fri, 6 Sep 2002 15:45:40 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Fri, 6 Sep 2002 15:45:39 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Is there something that replaces them to go to for technical correctness?

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Friday, September 06, 2002 3:43 PM
> To: Natale, Jonathan
> Cc: 'Abarbanel, Benjamin'; [e-mail]
> Subject: Re: admin dist/gp spec proposal 
> 
> 
> Natale,
> 
> > 1745 and 1403 are historic
> 
> correct. And with this in mind I would suggest we stop 
> reference/pointing
> to them.
> 
> Yakov.
> 
> > -----Original Message-----
> > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > Sent: Friday, September 06, 2002 3:38 PM
> > To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Yakov Rekhter'
> > Cc: [e-mail]
> > Subject: RE: admin dist/gp spec proposal 
> > 
> > 
> >  
> > > 
> > > Not that I am aware of.  There certainly is a case where they 
> > > must be the
> > > same (cisco bgp w/ ospf, don't know all the details of 
> > > how/why).  
> > 
> > RFC1745, and RFC1403 tell you why they must be the same.
> > 
> > > Maybe the local admin method of numbering is more 
> versatile by allowing 
> > > them to be different.  I think they should MUST be the 
> same and in some 
> > > implementation they are (gated, bay).
> > > 
> > > -----Original Message-----
> > > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > > Sent: Friday, September 06, 2002 3:29 PM
> > > To: 'Yakov Rekhter'; Abarbanel, Benjamin
> > > Cc: Natale, Jonathan; [e-mail]
> > > Subject: RE: admin dist/gp spec proposal 
> > > 
> > > 
> > > > 
> > > > > I would like to rephrase my statement on one sentence.
> > > > > 
> > > > > " BTW. BGP Identifier is a vague way of naming what 
> we know as the
> > > > >   Router-ID in all other IP related protocols."
> > > > 
> > > > This is *technically* incorrect. 
> > > >
> > > Is there a case where the BGP Identifier, should or must be 
> > > different than
> > > the Router-ID for the routing system to work correctly?
> > > 
> > > Ben
> > > 
> > >  
> > > > 
> > > > > 
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Abarbanel, Benjamin 
> > > [mailto:[e-mail]]
> > > > > > Sent: Friday, September 06, 2002 3:01 PM
> > > > > > To: 'Yakov Rekhter'; Natale, Jonathan
> > > > > > Cc: [e-mail]
> > > > > > Subject: RE: admin dist/gp spec proposal 
> > > > > > 
> > > > > > 
> > > > > > Yakov:
> > > > > >   There is no reference to RFC1812 in the reference section 
> > > > > > nor references 
> > > > > > to this spec where appropriate in the BGP relevant 
> > > > > > discussions. As was 
> > > > > > earlier mentioned. At least we need to tie the thread 
> > > > between the two
> > > > > > specs so people know what the assumptions are.  
> > > > > > 
> > > > > > BTW. BGP Identifier is a very misleading way of naming what 
> > > > > > we know as the
> > > > > > Router ID in all other protocols. I would like to 
> suggest we 
> > > > > > enhance its 
> > > > > > description as follows:
> > > > > > 
> > > > > > Current statement:
> > > > > > ==================
> > > > > > "BGP Identifier:
> > > > > > 
> > > > >          This 4-octet unsigned integer indicates the BGP 
> > > > Identifier of
> > > > > >          the sender. A given BGP speaker sets the value 
> > > of its BGP
> > > > > >          Identifier to an IP address assigned to that BGP 
> > > > > > speaker.  The
> > > > > >          value of the BGP Identifier is determined 
> on startup 
> > > > > > and is the
> > > > > >          same for every local interface and every 
> BGP peer. "
> > > > > > 
> > > > > > New Statement:
> > > > > > ==============
> > > > > > "BGP Identifier:
> > > > > > 
> > > > > >          This 4-octet unsigned integer indicates the BGP 
> > > > Identifier of
> > > > > >          the sender. A given BGP speaker sets the value 
> > > of its BGP
> > > > > >          Identifier also known as the Router-ID, to an IP 
> > > > > > address assigned 
> > > > > >          to that BGP speaker. The value of the BGP 
> > > Identifier is 
> > > > > >          determined on startup and is the same for every 
> > > > > > local interface 
> > > > > >          and every BGP peer and other IP related protocols. 
> > > > > > See [x],[y] for 
> > > > > >          more details on Router-ID useage between BGP and 
> > > > > > other protocols."
> > > > > > 
> > > > > > Where x = RFC1403,
> > > > > >       y = RFC1745
> > > > > > 
> > > > > > Ben
> > > > > > > -----Original Message-----
> > > > > > > From: Yakov Rekhter [mailto:[e-mail]]
> > > > > > > Sent: Friday, September 06, 2002 2:31 PM
> > > > > > > To: Natale, Jonathan
> > > > > > > Cc: [e-mail]
> > > > > > > Subject: Re: admin dist/gp spec proposal 
> > > > > > > 
> > > > > > > 
> > > > > > > Natale,
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Abarbanel, Benjamin 
> > > > [mailto:[e-mail]] 
> > > > > > > > Sent: Friday, September 06, 2002 1:49 PM
> > > > > > > > To: 'Natale, Jonathan'
> > > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > > 
> > > > > > > > Jonathan:
> > > > > > > > Forward this message to the IDR list. I think we 
> > > dropped off.
> > > > > > > > 
> > > > > > > > Ben
> > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Natale, Jonathan 
> [mailto:[e-mail]]
> > > > > > > > > Sent: Friday, September 06, 2002 1:46 PM
> > > > > > > > > To: 'Abarbanel, Benjamin'
> > > > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > I agree.  The default values of the various 
> > > > protocols as they 
> > > > > > > > > are currently
> > > > > > > > > implemented make sense:
> > > > > > > > > Connected
> > > > > > > > > Static
> > > > > > > > > Ebgp
> > > > > > > > > Igp's
> > > > > > > > > Ibgp
> > > > > > > > > 
> > > > > > > > > ...they should be documented in 1812 ideally, but 
> > > > putting it 
> > > > > > > > > in 1771 would
> > > > > > > > > not hurt.  Added a phrase to indicate that they 
> > > may be user 
> > > > > > > > > configurable is
> > > > > > > > > good too.
> > > > > > > 
> > > > > > > Perhaps it is time to update 1812. But let's not use BGP
> > > > > > > spec as a replacement for updating 1812 - it is not.
> > > > > > > 
> > > > > > > Yakov.
> > > > > > > 
> > > > > > > > > 
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Abarbanel, Benjamin 
> > > > > [mailto:[e-mail]] 
> > > > > > > > Sent: Friday, September 06, 2002 11:39 AM
> > > > > > > > To: 'Mathew Richardson'; Natale, Jonathan
> > > > > > > > Cc: [e-mail]
> > > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > >  
> > > > > > > > > 
> > > > > > > > > > Natale, Jonathan <[e-mail]> 
> > > > [Fri, Sep 06, 
> > > > > > > > > 2002 at 10:53:40AM -0400]:
> > > > > > > > > >Add sect. in bgp draft stating that ebgp routes 
> > > should be 
> > > > > > > > > preferred over any
> > > > > > > > > >igp routes and any igp routes should be preferred 
> > > > over ibgp 
> > > > > > > > > routes.  The
> > > > > > > > > >exception to this is igp summary routes may 
> be preferred 
> > > > > > > > > over ebgp routes.
> > > > > > > > > 
> > > > > > > > > The EBGP vs. IBGP is already covered in section 
> > > > > > 9.1.2.2.  As to how
> > > > > > > > > BGP and non-BGP routes interact, I suspect that 
> > > that really 
> > > > > > > > > should remain
> > > > > > > > > largely a local policy matter.  A BCP is probably in 
> > > > > > order (does one
> > > > > > > > > on this topic already exist?)
> > > > > > > > >
> > > > > > > > Clearly the BGP and non-BGP route competition 
> for dominance 
> > > > > > > > in the routing
> > > > > > > > table is firstly, defaulted and secondly policy 
> > > over-written 
> > > > > > > > by a local
> > > > > > > > router administrator.  Just some mention of operational 
> > > > > > > > impact by turning 
> > > > > > > > some policy knobs and changing certain route selection 
> > > > > > > > decisions and their 
> > > > > > > > control plane impacts will be nice. Maybe this 
> belongs in a 
> > > > > > > different spec.
> > > > > > > > 
> > > > > > > > I find spreading the knowledge across many specs a bit 
> > > > > > inconvenient.
> > > > > > > > 
> > > > > > > > IMHO,
> > > > > > > > Ben
> > > > > > > > 
> > > > > > 
> > > > 
> > > 
> 


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 PAA07578 for <[e-mail]>; Fri, 6 Sep 2002 15:43:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DF2CA91329; Fri,  6 Sep 2002 15:43:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A643E9132B; Fri,  6 Sep 2002 15:43:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C05691329 for <[e-mail]>; Fri,  6 Sep 2002 15:43:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5B8A35DF65; Fri,  6 Sep 2002 15:43:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id DA4E95DE58 for <[e-mail]>; Fri,  6 Sep 2002 15:43:01 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA05913; Fri, 6 Sep 2002 15:42:59 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA25778; Fri, 6 Sep 2002 15:43:01 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68Q33YM>; Fri, 6 Sep 2002 15:42:59 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>, "'Natale, Jonathan'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: admin dist/gp spec proposal 
Date: Fri, 6 Sep 2002 15:42:58 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

This is out of RFC1403:

"3. BGP Identifier and OSPF router ID

   The BGP identifier MUST be the same as the OSPF router id at all
   times that the router is up.

   This characteristic is required for two reasons."

This is out of RFC1745:

"3. BGP/IDRP Identifier and OSPF router ID

   The BGP/IDRP identifier MUST be the same as the OSPF router id at all
   times that the router is up."

Ben

> -----Original Message-----
> From: Abarbanel, Benjamin 
> Sent: Friday, September 06, 2002 3:38 PM
> To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Yakov Rekhter'
> Cc: [e-mail]
> Subject: RE: admin dist/gp spec proposal 
> 
> 
> 
>  
> > 
> > Not that I am aware of.  There certainly is a case where they 
> > must be the
> > same (cisco bgp w/ ospf, don't know all the details of 
> > how/why).  
> 
> RFC1745, and RFC1403 tell you why they must be the same.
> 
> > Maybe the local admin method of numbering is more versatile 
> by allowing 
> > them to be different.  I think they should MUST be the same 
> and in some 
> > implementation they are (gated, bay).
> > 
> > -----Original Message-----
> > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > Sent: Friday, September 06, 2002 3:29 PM
> > To: 'Yakov Rekhter'; Abarbanel, Benjamin
> > Cc: Natale, Jonathan; [e-mail]
> > Subject: RE: admin dist/gp spec proposal 
> > 
> > 
> > > 
> > > > I would like to rephrase my statement on one sentence.
> > > > 
> > > > " BTW. BGP Identifier is a vague way of naming what we 
> know as the
> > > >   Router-ID in all other IP related protocols."
> > > 
> > > This is *technically* incorrect. 
> > >
> > Is there a case where the BGP Identifier, should or must be 
> > different than
> > the Router-ID for the routing system to work correctly?
> > 
> > Ben
> > 
> >  
> > > 
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Abarbanel, Benjamin 
> > [mailto:[e-mail]]
> > > > > Sent: Friday, September 06, 2002 3:01 PM
> > > > > To: 'Yakov Rekhter'; Natale, Jonathan
> > > > > Cc: [e-mail]
> > > > > Subject: RE: admin dist/gp spec proposal 
> > > > > 
> > > > > 
> > > > > Yakov:
> > > > >   There is no reference to RFC1812 in the reference section 
> > > > > nor references 
> > > > > to this spec where appropriate in the BGP relevant 
> > > > > discussions. As was 
> > > > > earlier mentioned. At least we need to tie the thread 
> > > between the two
> > > > > specs so people know what the assumptions are.  
> > > > > 
> > > > > BTW. BGP Identifier is a very misleading way of naming what 
> > > > > we know as the
> > > > > Router ID in all other protocols. I would like to suggest we 
> > > > > enhance its 
> > > > > description as follows:
> > > > > 
> > > > > Current statement:
> > > > > ==================
> > > > > "BGP Identifier:
> > > > > 
> > > > >          This 4-octet unsigned integer indicates the BGP 
> > > Identifier of
> > > > >          the sender. A given BGP speaker sets the value 
> > of its BGP
> > > > >          Identifier to an IP address assigned to that BGP 
> > > > > speaker.  The
> > > > >          value of the BGP Identifier is determined on startup 
> > > > > and is the
> > > > >          same for every local interface and every BGP peer. "
> > > > > 
> > > > > New Statement:
> > > > > ==============
> > > > > "BGP Identifier:
> > > > > 
> > > > >          This 4-octet unsigned integer indicates the BGP 
> > > Identifier of
> > > > >          the sender. A given BGP speaker sets the value 
> > of its BGP
> > > > >          Identifier also known as the Router-ID, to an IP 
> > > > > address assigned 
> > > > >          to that BGP speaker. The value of the BGP 
> > Identifier is 
> > > > >          determined on startup and is the same for every 
> > > > > local interface 
> > > > >          and every BGP peer and other IP related protocols. 
> > > > > See [x],[y] for 
> > > > >          more details on Router-ID useage between BGP and 
> > > > > other protocols."
> > > > > 
> > > > > Where x = RFC1403,
> > > > >       y = RFC1745
> > > > > 
> > > > > Ben
> > > > > > -----Original Message-----
> > > > > > From: Yakov Rekhter [mailto:[e-mail]]
> > > > > > Sent: Friday, September 06, 2002 2:31 PM
> > > > > > To: Natale, Jonathan
> > > > > > Cc: [e-mail]
> > > > > > Subject: Re: admin dist/gp spec proposal 
> > > > > > 
> > > > > > 
> > > > > > Natale,
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Abarbanel, Benjamin 
> > > [mailto:[e-mail]] 
> > > > > > > Sent: Friday, September 06, 2002 1:49 PM
> > > > > > > To: 'Natale, Jonathan'
> > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > 
> > > > > > > Jonathan:
> > > > > > > Forward this message to the IDR list. I think we 
> > dropped off.
> > > > > > > 
> > > > > > > Ben
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Natale, Jonathan 
> [mailto:[e-mail]]
> > > > > > > > Sent: Friday, September 06, 2002 1:46 PM
> > > > > > > > To: 'Abarbanel, Benjamin'
> > > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > > 
> > > > > > > > 
> > > > > > > > I agree.  The default values of the various 
> > > protocols as they 
> > > > > > > > are currently
> > > > > > > > implemented make sense:
> > > > > > > > Connected
> > > > > > > > Static
> > > > > > > > Ebgp
> > > > > > > > Igp's
> > > > > > > > Ibgp
> > > > > > > > 
> > > > > > > > ...they should be documented in 1812 ideally, but 
> > > putting it 
> > > > > > > > in 1771 would
> > > > > > > > not hurt.  Added a phrase to indicate that they 
> > may be user 
> > > > > > > > configurable is
> > > > > > > > good too.
> > > > > > 
> > > > > > Perhaps it is time to update 1812. But let's not use BGP
> > > > > > spec as a replacement for updating 1812 - it is not.
> > > > > > 
> > > > > > Yakov.
> > > > > > 
> > > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Abarbanel, Benjamin 
> > > > [mailto:[e-mail]] 
> > > > > > > Sent: Friday, September 06, 2002 11:39 AM
> > > > > > > To: 'Mathew Richardson'; Natale, Jonathan
> > > > > > > Cc: [e-mail]
> > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > >  
> > > > > > > > 
> > > > > > > > > Natale, Jonathan <[e-mail]> 
> > > [Fri, Sep 06, 
> > > > > > > > 2002 at 10:53:40AM -0400]:
> > > > > > > > >Add sect. in bgp draft stating that ebgp routes 
> > should be 
> > > > > > > > preferred over any
> > > > > > > > >igp routes and any igp routes should be preferred 
> > > over ibgp 
> > > > > > > > routes.  The
> > > > > > > > >exception to this is igp summary routes may be 
> preferred 
> > > > > > > > over ebgp routes.
> > > > > > > > 
> > > > > > > > The EBGP vs. IBGP is already covered in section 
> > > > > 9.1.2.2.  As to how
> > > > > > > > BGP and non-BGP routes interact, I suspect that 
> > that really 
> > > > > > > > should remain
> > > > > > > > largely a local policy matter.  A BCP is probably in 
> > > > > order (does one
> > > > > > > > on this topic already exist?)
> > > > > > > >
> > > > > > > Clearly the BGP and non-BGP route competition for 
> dominance 
> > > > > > > in the routing
> > > > > > > table is firstly, defaulted and secondly policy 
> > over-written 
> > > > > > > by a local
> > > > > > > router administrator.  Just some mention of operational 
> > > > > > > impact by turning 
> > > > > > > some policy knobs and changing certain route selection 
> > > > > > > decisions and their 
> > > > > > > control plane impacts will be nice. Maybe this 
> belongs in a 
> > > > > > > different spec.
> > > > > > > 
> > > > > > > I find spreading the knowledge across many specs a bit 
> > > > > inconvenient.
> > > > > > > 
> > > > > > > IMHO,
> > > > > > > Ben
> > > > > > > 
> > > > > 
> > > 
> > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA07570 for <[e-mail]>; Fri, 6 Sep 2002 15:43:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 206FB9132B; Fri,  6 Sep 2002 15:43:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFC859132D; Fri,  6 Sep 2002 15:43:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 705599132B for <[e-mail]>; Fri,  6 Sep 2002 15:43:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5DBFC5DF65; Fri,  6 Sep 2002 15:43:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id C1A605DEFA for <[e-mail]>; Fri,  6 Sep 2002 15:43:19 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g86JhHm23886; Fri, 6 Sep 2002 12:43:17 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Abarbanel, Benjamin'" <[e-mail]>, [e-mail]
Subject: Re: admin dist/gp spec proposal 
In-Reply-To: Your message of "Fri, 06 Sep 2002 15:40:43 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 06 Sep 2002 12:43:17 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Natale,

> 1745 and 1403 are historic

correct. And with this in mind I would suggest we stop reference/pointing
to them.

Yakov.

> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Friday, September 06, 2002 3:38 PM
> To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Yakov Rekhter'
> Cc: [e-mail]
> Subject: RE: admin dist/gp spec proposal 
> 
> 
>  
> > 
> > Not that I am aware of.  There certainly is a case where they 
> > must be the
> > same (cisco bgp w/ ospf, don't know all the details of 
> > how/why).  
> 
> RFC1745, and RFC1403 tell you why they must be the same.
> 
> > Maybe the local admin method of numbering is more versatile by allowing 
> > them to be different.  I think they should MUST be the same and in some 
> > implementation they are (gated, bay).
> > 
> > -----Original Message-----
> > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > Sent: Friday, September 06, 2002 3:29 PM
> > To: 'Yakov Rekhter'; Abarbanel, Benjamin
> > Cc: Natale, Jonathan; [e-mail]
> > Subject: RE: admin dist/gp spec proposal 
> > 
> > 
> > > 
> > > > I would like to rephrase my statement on one sentence.
> > > > 
> > > > " BTW. BGP Identifier is a vague way of naming what we know as the
> > > >   Router-ID in all other IP related protocols."
> > > 
> > > This is *technically* incorrect. 
> > >
> > Is there a case where the BGP Identifier, should or must be 
> > different than
> > the Router-ID for the routing system to work correctly?
> > 
> > Ben
> > 
> >  
> > > 
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Abarbanel, Benjamin 
> > [mailto:[e-mail]]
> > > > > Sent: Friday, September 06, 2002 3:01 PM
> > > > > To: 'Yakov Rekhter'; Natale, Jonathan
> > > > > Cc: [e-mail]
> > > > > Subject: RE: admin dist/gp spec proposal 
> > > > > 
> > > > > 
> > > > > Yakov:
> > > > >   There is no reference to RFC1812 in the reference section 
> > > > > nor references 
> > > > > to this spec where appropriate in the BGP relevant 
> > > > > discussions. As was 
> > > > > earlier mentioned. At least we need to tie the thread 
> > > between the two
> > > > > specs so people know what the assumptions are.  
> > > > > 
> > > > > BTW. BGP Identifier is a very misleading way of naming what 
> > > > > we know as the
> > > > > Router ID in all other protocols. I would like to suggest we 
> > > > > enhance its 
> > > > > description as follows:
> > > > > 
> > > > > Current statement:
> > > > > ==================
> > > > > "BGP Identifier:
> > > > > 
> > > >          This 4-octet unsigned integer indicates the BGP 
> > > Identifier of
> > > > >          the sender. A given BGP speaker sets the value 
> > of its BGP
> > > > >          Identifier to an IP address assigned to that BGP 
> > > > > speaker.  The
> > > > >          value of the BGP Identifier is determined on startup 
> > > > > and is the
> > > > >          same for every local interface and every BGP peer. "
> > > > > 
> > > > > New Statement:
> > > > > ==============
> > > > > "BGP Identifier:
> > > > > 
> > > > >          This 4-octet unsigned integer indicates the BGP 
> > > Identifier of
> > > > >          the sender. A given BGP speaker sets the value 
> > of its BGP
> > > > >          Identifier also known as the Router-ID, to an IP 
> > > > > address assigned 
> > > > >          to that BGP speaker. The value of the BGP 
> > Identifier is 
> > > > >          determined on startup and is the same for every 
> > > > > local interface 
> > > > >          and every BGP peer and other IP related protocols. 
> > > > > See [x],[y] for 
> > > > >          more details on Router-ID useage between BGP and 
> > > > > other protocols."
> > > > > 
> > > > > Where x = RFC1403,
> > > > >       y = RFC1745
> > > > > 
> > > > > Ben
> > > > > > -----Original Message-----
> > > > > > From: Yakov Rekhter [mailto:[e-mail]]
> > > > > > Sent: Friday, September 06, 2002 2:31 PM
> > > > > > To: Natale, Jonathan
> > > > > > Cc: [e-mail]
> > > > > > Subject: Re: admin dist/gp spec proposal 
> > > > > > 
> > > > > > 
> > > > > > Natale,
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Abarbanel, Benjamin 
> > > [mailto:[e-mail]] 
> > > > > > > Sent: Friday, September 06, 2002 1:49 PM
> > > > > > > To: 'Natale, Jonathan'
> > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > 
> > > > > > > Jonathan:
> > > > > > > Forward this message to the IDR list. I think we 
> > dropped off.
> > > > > > > 
> > > > > > > Ben
> > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Natale, Jonathan [mailto:[e-mail]]
> > > > > > > > Sent: Friday, September 06, 2002 1:46 PM
> > > > > > > > To: 'Abarbanel, Benjamin'
> > > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > > 
> > > > > > > > 
> > > > > > > > I agree.  The default values of the various 
> > > protocols as they 
> > > > > > > > are currently
> > > > > > > > implemented make sense:
> > > > > > > > Connected
> > > > > > > > Static
> > > > > > > > Ebgp
> > > > > > > > Igp's
> > > > > > > > Ibgp
> > > > > > > > 
> > > > > > > > ...they should be documented in 1812 ideally, but 
> > > putting it 
> > > > > > > > in 1771 would
> > > > > > > > not hurt.  Added a phrase to indicate that they 
> > may be user 
> > > > > > > > configurable is
> > > > > > > > good too.
> > > > > > 
> > > > > > Perhaps it is time to update 1812. But let's not use BGP
> > > > > > spec as a replacement for updating 1812 - it is not.
> > > > > > 
> > > > > > Yakov.
> > > > > > 
> > > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Abarbanel, Benjamin 
> > > > [mailto:[e-mail]] 
> > > > > > > Sent: Friday, September 06, 2002 11:39 AM
> > > > > > > To: 'Mathew Richardson'; Natale, Jonathan
> > > > > > > Cc: [e-mail]
> > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > >  
> > > > > > > > 
> > > > > > > > > Natale, Jonathan <[e-mail]> 
> > > [Fri, Sep 06, 
> > > > > > > > 2002 at 10:53:40AM -0400]:
> > > > > > > > >Add sect. in bgp draft stating that ebgp routes 
> > should be 
> > > > > > > > preferred over any
> > > > > > > > >igp routes and any igp routes should be preferred 
> > > over ibgp 
> > > > > > > > routes.  The
> > > > > > > > >exception to this is igp summary routes may be preferred 
> > > > > > > > over ebgp routes.
> > > > > > > > 
> > > > > > > > The EBGP vs. IBGP is already covered in section 
> > > > > 9.1.2.2.  As to how
> > > > > > > > BGP and non-BGP routes interact, I suspect that 
> > that really 
> > > > > > > > should remain
> > > > > > > > largely a local policy matter.  A BCP is probably in 
> > > > > order (does one
> > > > > > > > on this topic already exist?)
> > > > > > > >
> > > > > > > Clearly the BGP and non-BGP route competition for dominance 
> > > > > > > in the routing
> > > > > > > table is firstly, defaulted and secondly policy 
> > over-written 
> > > > > > > by a local
> > > > > > > router administrator.  Just some mention of operational 
> > > > > > > impact by turning 
> > > > > > > some policy knobs and changing certain route selection 
> > > > > > > decisions and their 
> > > > > > > control plane impacts will be nice. Maybe this belongs in a 
> > > > > > different spec.
> > > > > > > 
> > > > > > > I find spreading the knowledge across many specs a bit 
> > > > > inconvenient.
> > > > > > > 
> > > > > > > IMHO,
> > > > > > > Ben
> > > > > > > 
> > > > > 
> > > 
> > 


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 PAA07522 for <[e-mail]>; Fri, 6 Sep 2002 15:41:58 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E13049132F; Fri,  6 Sep 2002 15:38:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 11F539132D; Fri,  6 Sep 2002 15:38:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B14AD9132F for <[e-mail]>; Fri,  6 Sep 2002 15:38:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9C1875DEFA; Fri,  6 Sep 2002 15:38:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 22FDE5DE58 for <[e-mail]>; Fri,  6 Sep 2002 15:38:10 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA05584; Fri, 6 Sep 2002 15:38:07 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24833; Fri, 6 Sep 2002 15:38:09 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68Q33S4>; Fri, 6 Sep 2002 15:38:08 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Fri, 6 Sep 2002 15:38:07 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

 
> 
> Not that I am aware of.  There certainly is a case where they 
> must be the
> same (cisco bgp w/ ospf, don't know all the details of 
> how/why).  

RFC1745, and RFC1403 tell you why they must be the same.

> Maybe the local admin method of numbering is more versatile by allowing 
> them to be different.  I think they should MUST be the same and in some 
> implementation they are (gated, bay).
> 
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Friday, September 06, 2002 3:29 PM
> To: 'Yakov Rekhter'; Abarbanel, Benjamin
> Cc: Natale, Jonathan; [e-mail]
> Subject: RE: admin dist/gp spec proposal 
> 
> 
> > 
> > > I would like to rephrase my statement on one sentence.
> > > 
> > > " BTW. BGP Identifier is a vague way of naming what we know as the
> > >   Router-ID in all other IP related protocols."
> > 
> > This is *technically* incorrect. 
> >
> Is there a case where the BGP Identifier, should or must be 
> different than
> the Router-ID for the routing system to work correctly?
> 
> Ben
> 
>  
> > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Abarbanel, Benjamin 
> [mailto:[e-mail]]
> > > > Sent: Friday, September 06, 2002 3:01 PM
> > > > To: 'Yakov Rekhter'; Natale, Jonathan
> > > > Cc: [e-mail]
> > > > Subject: RE: admin dist/gp spec proposal 
> > > > 
> > > > 
> > > > Yakov:
> > > >   There is no reference to RFC1812 in the reference section 
> > > > nor references 
> > > > to this spec where appropriate in the BGP relevant 
> > > > discussions. As was 
> > > > earlier mentioned. At least we need to tie the thread 
> > between the two
> > > > specs so people know what the assumptions are.  
> > > > 
> > > > BTW. BGP Identifier is a very misleading way of naming what 
> > > > we know as the
> > > > Router ID in all other protocols. I would like to suggest we 
> > > > enhance its 
> > > > description as follows:
> > > > 
> > > > Current statement:
> > > > ==================
> > > > "BGP Identifier:
> > > > 
> > > >          This 4-octet unsigned integer indicates the BGP 
> > Identifier of
> > > >          the sender. A given BGP speaker sets the value 
> of its BGP
> > > >          Identifier to an IP address assigned to that BGP 
> > > > speaker.  The
> > > >          value of the BGP Identifier is determined on startup 
> > > > and is the
> > > >          same for every local interface and every BGP peer. "
> > > > 
> > > > New Statement:
> > > > ==============
> > > > "BGP Identifier:
> > > > 
> > > >          This 4-octet unsigned integer indicates the BGP 
> > Identifier of
> > > >          the sender. A given BGP speaker sets the value 
> of its BGP
> > > >          Identifier also known as the Router-ID, to an IP 
> > > > address assigned 
> > > >          to that BGP speaker. The value of the BGP 
> Identifier is 
> > > >          determined on startup and is the same for every 
> > > > local interface 
> > > >          and every BGP peer and other IP related protocols. 
> > > > See [x],[y] for 
> > > >          more details on Router-ID useage between BGP and 
> > > > other protocols."
> > > > 
> > > > Where x = RFC1403,
> > > >       y = RFC1745
> > > > 
> > > > Ben
> > > > > -----Original Message-----
> > > > > From: Yakov Rekhter [mailto:[e-mail]]
> > > > > Sent: Friday, September 06, 2002 2:31 PM
> > > > > To: Natale, Jonathan
> > > > > Cc: [e-mail]
> > > > > Subject: Re: admin dist/gp spec proposal 
> > > > > 
> > > > > 
> > > > > Natale,
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Abarbanel, Benjamin 
> > [mailto:[e-mail]] 
> > > > > > Sent: Friday, September 06, 2002 1:49 PM
> > > > > > To: 'Natale, Jonathan'
> > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > 
> > > > > > Jonathan:
> > > > > > Forward this message to the IDR list. I think we 
> dropped off.
> > > > > > 
> > > > > > Ben
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Natale, Jonathan [mailto:[e-mail]]
> > > > > > > Sent: Friday, September 06, 2002 1:46 PM
> > > > > > > To: 'Abarbanel, Benjamin'
> > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > 
> > > > > > > 
> > > > > > > I agree.  The default values of the various 
> > protocols as they 
> > > > > > > are currently
> > > > > > > implemented make sense:
> > > > > > > Connected
> > > > > > > Static
> > > > > > > Ebgp
> > > > > > > Igp's
> > > > > > > Ibgp
> > > > > > > 
> > > > > > > ...they should be documented in 1812 ideally, but 
> > putting it 
> > > > > > > in 1771 would
> > > > > > > not hurt.  Added a phrase to indicate that they 
> may be user 
> > > > > > > configurable is
> > > > > > > good too.
> > > > > 
> > > > > Perhaps it is time to update 1812. But let's not use BGP
> > > > > spec as a replacement for updating 1812 - it is not.
> > > > > 
> > > > > Yakov.
> > > > > 
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Abarbanel, Benjamin 
> > > [mailto:[e-mail]] 
> > > > > > Sent: Friday, September 06, 2002 11:39 AM
> > > > > > To: 'Mathew Richardson'; Natale, Jonathan
> > > > > > Cc: [e-mail]
> > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >  
> > > > > > > 
> > > > > > > > Natale, Jonathan <[e-mail]> 
> > [Fri, Sep 06, 
> > > > > > > 2002 at 10:53:40AM -0400]:
> > > > > > > >Add sect. in bgp draft stating that ebgp routes 
> should be 
> > > > > > > preferred over any
> > > > > > > >igp routes and any igp routes should be preferred 
> > over ibgp 
> > > > > > > routes.  The
> > > > > > > >exception to this is igp summary routes may be preferred 
> > > > > > > over ebgp routes.
> > > > > > > 
> > > > > > > The EBGP vs. IBGP is already covered in section 
> > > > 9.1.2.2.  As to how
> > > > > > > BGP and non-BGP routes interact, I suspect that 
> that really 
> > > > > > > should remain
> > > > > > > largely a local policy matter.  A BCP is probably in 
> > > > order (does one
> > > > > > > on this topic already exist?)
> > > > > > >
> > > > > > Clearly the BGP and non-BGP route competition for dominance 
> > > > > > in the routing
> > > > > > table is firstly, defaulted and secondly policy 
> over-written 
> > > > > > by a local
> > > > > > router administrator.  Just some mention of operational 
> > > > > > impact by turning 
> > > > > > some policy knobs and changing certain route selection 
> > > > > > decisions and their 
> > > > > > control plane impacts will be nice. Maybe this belongs in a 
> > > > > > different spec.
> > > > > > 
> > > > > > I find spreading the knowledge across many specs a bit 
> > > > inconvenient.
> > > > > > 
> > > > > > IMHO,
> > > > > > Ben
> > > > > > 
> > > > 
> > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA07516 for <[e-mail]>; Fri, 6 Sep 2002 15:41:54 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 80B6B9132C; Fri,  6 Sep 2002 15:41:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B37191335; Fri,  6 Sep 2002 15:41:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 941369132C for <[e-mail]>; Fri,  6 Sep 2002 15:40:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3AC345DEFA; Fri,  6 Sep 2002 15:40:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id D1DD15DE58 for <[e-mail]>; Fri,  6 Sep 2002 15:40:53 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BW4P>; Fri, 6 Sep 2002 15:40:53 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>
Cc: [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Fri, 6 Sep 2002 15:40:43 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

1745 and 1403 are historic


-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Friday, September 06, 2002 3:38 PM
To: 'Natale, Jonathan'; Abarbanel, Benjamin; 'Yakov Rekhter'
Cc: [e-mail]
Subject: RE: admin dist/gp spec proposal 


 
> 
> Not that I am aware of.  There certainly is a case where they 
> must be the
> same (cisco bgp w/ ospf, don't know all the details of 
> how/why).  

RFC1745, and RFC1403 tell you why they must be the same.

> Maybe the local admin method of numbering is more versatile by allowing 
> them to be different.  I think they should MUST be the same and in some 
> implementation they are (gated, bay).
> 
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Friday, September 06, 2002 3:29 PM
> To: 'Yakov Rekhter'; Abarbanel, Benjamin
> Cc: Natale, Jonathan; [e-mail]
> Subject: RE: admin dist/gp spec proposal 
> 
> 
> > 
> > > I would like to rephrase my statement on one sentence.
> > > 
> > > " BTW. BGP Identifier is a vague way of naming what we know as the
> > >   Router-ID in all other IP related protocols."
> > 
> > This is *technically* incorrect. 
> >
> Is there a case where the BGP Identifier, should or must be 
> different than
> the Router-ID for the routing system to work correctly?
> 
> Ben
> 
>  
> > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Abarbanel, Benjamin 
> [mailto:[e-mail]]
> > > > Sent: Friday, September 06, 2002 3:01 PM
> > > > To: 'Yakov Rekhter'; Natale, Jonathan
> > > > Cc: [e-mail]
> > > > Subject: RE: admin dist/gp spec proposal 
> > > > 
> > > > 
> > > > Yakov:
> > > >   There is no reference to RFC1812 in the reference section 
> > > > nor references 
> > > > to this spec where appropriate in the BGP relevant 
> > > > discussions. As was 
> > > > earlier mentioned. At least we need to tie the thread 
> > between the two
> > > > specs so people know what the assumptions are.  
> > > > 
> > > > BTW. BGP Identifier is a very misleading way of naming what 
> > > > we know as the
> > > > Router ID in all other protocols. I would like to suggest we 
> > > > enhance its 
> > > > description as follows:
> > > > 
> > > > Current statement:
> > > > ==================
> > > > "BGP Identifier:
> > > > 
> > > >          This 4-octet unsigned integer indicates the BGP 
> > Identifier of
> > > >          the sender. A given BGP speaker sets the value 
> of its BGP
> > > >          Identifier to an IP address assigned to that BGP 
> > > > speaker.  The
> > > >          value of the BGP Identifier is determined on startup 
> > > > and is the
> > > >          same for every local interface and every BGP peer. "
> > > > 
> > > > New Statement:
> > > > ==============
> > > > "BGP Identifier:
> > > > 
> > > >          This 4-octet unsigned integer indicates the BGP 
> > Identifier of
> > > >          the sender. A given BGP speaker sets the value 
> of its BGP
> > > >          Identifier also known as the Router-ID, to an IP 
> > > > address assigned 
> > > >          to that BGP speaker. The value of the BGP 
> Identifier is 
> > > >          determined on startup and is the same for every 
> > > > local interface 
> > > >          and every BGP peer and other IP related protocols. 
> > > > See [x],[y] for 
> > > >          more details on Router-ID useage between BGP and 
> > > > other protocols."
> > > > 
> > > > Where x = RFC1403,
> > > >       y = RFC1745
> > > > 
> > > > Ben
> > > > > -----Original Message-----
> > > > > From: Yakov Rekhter [mailto:[e-mail]]
> > > > > Sent: Friday, September 06, 2002 2:31 PM
> > > > > To: Natale, Jonathan
> > > > > Cc: [e-mail]
> > > > > Subject: Re: admin dist/gp spec proposal 
> > > > > 
> > > > > 
> > > > > Natale,
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Abarbanel, Benjamin 
> > [mailto:[e-mail]] 
> > > > > > Sent: Friday, September 06, 2002 1:49 PM
> > > > > > To: 'Natale, Jonathan'
> > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > 
> > > > > > Jonathan:
> > > > > > Forward this message to the IDR list. I think we 
> dropped off.
> > > > > > 
> > > > > > Ben
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Natale, Jonathan [mailto:[e-mail]]
> > > > > > > Sent: Friday, September 06, 2002 1:46 PM
> > > > > > > To: 'Abarbanel, Benjamin'
> > > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > > 
> > > > > > > 
> > > > > > > I agree.  The default values of the various 
> > protocols as they 
> > > > > > > are currently
> > > > > > > implemented make sense:
> > > > > > > Connected
> > > > > > > Static
> > > > > > > Ebgp
> > > > > > > Igp's
> > > > > > > Ibgp
> > > > > > > 
> > > > > > > ...they should be documented in 1812 ideally, but 
> > putting it 
> > > > > > > in 1771 would
> > > > > > > not hurt.  Added a phrase to indicate that they 
> may be user 
> > > > > > > configurable is
> > > > > > > good too.
> > > > > 
> > > > > Perhaps it is time to update 1812. But let's not use BGP
> > > > > spec as a replacement for updating 1812 - it is not.
> > > > > 
> > > > > Yakov.
> > > > > 
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Abarbanel, Benjamin 
> > > [mailto:[e-mail]] 
> > > > > > Sent: Friday, September 06, 2002 11:39 AM
> > > > > > To: 'Mathew Richardson'; Natale, Jonathan
> > > > > > Cc: [e-mail]
> > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > >  
> > > > > > > 
> > > > > > > > Natale, Jonathan <[e-mail]> 
> > [Fri, Sep 06, 
> > > > > > > 2002 at 10:53:40AM -0400]:
> > > > > > > >Add sect. in bgp draft stating that ebgp routes 
> should be 
> > > > > > > preferred over any
> > > > > > > >igp routes and any igp routes should be preferred 
> > over ibgp 
> > > > > > > routes.  The
> > > > > > > >exception to this is igp summary routes may be preferred 
> > > > > > > over ebgp routes.
> > > > > > > 
> > > > > > > The EBGP vs. IBGP is already covered in section 
> > > > 9.1.2.2.  As to how
> > > > > > > BGP and non-BGP routes interact, I suspect that 
> that really 
> > > > > > > should remain
> > > > > > > largely a local policy matter.  A BCP is probably in 
> > > > order (does one
> > > > > > > on this topic already exist?)
> > > > > > >
> > > > > > Clearly the BGP and non-BGP route competition for dominance 
> > > > > > in the routing
> > > > > > table is firstly, defaulted and secondly policy 
> over-written 
> > > > > > by a local
> > > > > > router administrator.  Just some mention of operational 
> > > > > > impact by turning 
> > > > > > some policy knobs and changing certain route selection 
> > > > > > decisions and their 
> > > > > > control plane impacts will be nice. Maybe this belongs in a 
> > > > > > different spec.
> > > > > > 
> > > > > > I find spreading the knowledge across many specs a bit 
> > > > inconvenient.
> > > > > > 
> > > > > > IMHO,
> > > > > > Ben
> > > > > > 
> > > > 
> > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA07282 for <[e-mail]>; Fri, 6 Sep 2002 15:36:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 660E591328; Fri,  6 Sep 2002 15:35:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 334A391329; Fri,  6 Sep 2002 15:35:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2387B91328 for <[e-mail]>; Fri,  6 Sep 2002 15:34:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 042C15DF49; Fri,  6 Sep 2002 15:34:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id AAFFB5DE58 for <[e-mail]>; Fri,  6 Sep 2002 15:34:33 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BWTR>; Fri, 6 Sep 2002 15:34:33 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Fri, 6 Sep 2002 15:34:32 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Not that I am aware of.  There certainly is a case where they must be the
same (cisco bgp w/ ospf, don't know all the details of how/why).  Maybe the
local admin method of numbering is more versatile by allowing them to be
different.  I think they should MUST be the same and in some implementation
they are (gated, bay).

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Friday, September 06, 2002 3:29 PM
To: 'Yakov Rekhter'; Abarbanel, Benjamin
Cc: Natale, Jonathan; [e-mail]
Subject: RE: admin dist/gp spec proposal 


> 
> > I would like to rephrase my statement on one sentence.
> > 
> > " BTW. BGP Identifier is a vague way of naming what we know as the
> >   Router-ID in all other IP related protocols."
> 
> This is *technically* incorrect. 
>
Is there a case where the BGP Identifier, should or must be different than
the Router-ID for the routing system to work correctly?

Ben

 
> 
> > 
> > 
> > > -----Original Message-----
> > > From: Abarbanel, Benjamin [mailto:[e-mail]]
> > > Sent: Friday, September 06, 2002 3:01 PM
> > > To: 'Yakov Rekhter'; Natale, Jonathan
> > > Cc: [e-mail]
> > > Subject: RE: admin dist/gp spec proposal 
> > > 
> > > 
> > > Yakov:
> > >   There is no reference to RFC1812 in the reference section 
> > > nor references 
> > > to this spec where appropriate in the BGP relevant 
> > > discussions. As was 
> > > earlier mentioned. At least we need to tie the thread 
> between the two
> > > specs so people know what the assumptions are.  
> > > 
> > > BTW. BGP Identifier is a very misleading way of naming what 
> > > we know as the
> > > Router ID in all other protocols. I would like to suggest we 
> > > enhance its 
> > > description as follows:
> > > 
> > > Current statement:
> > > ==================
> > > "BGP Identifier:
> > > 
> > >          This 4-octet unsigned integer indicates the BGP 
> Identifier of
> > >          the sender. A given BGP speaker sets the value of its BGP
> > >          Identifier to an IP address assigned to that BGP 
> > > speaker.  The
> > >          value of the BGP Identifier is determined on startup 
> > > and is the
> > >          same for every local interface and every BGP peer. "
> > > 
> > > New Statement:
> > > ==============
> > > "BGP Identifier:
> > > 
> > >          This 4-octet unsigned integer indicates the BGP 
> Identifier of
> > >          the sender. A given BGP speaker sets the value of its BGP
> > >          Identifier also known as the Router-ID, to an IP 
> > > address assigned 
> > >          to that BGP speaker. The value of the BGP Identifier is 
> > >          determined on startup and is the same for every 
> > > local interface 
> > >          and every BGP peer and other IP related protocols. 
> > > See [x],[y] for 
> > >          more details on Router-ID useage between BGP and 
> > > other protocols."
> > > 
> > > Where x = RFC1403,
> > >       y = RFC1745
> > > 
> > > Ben
> > > > -----Original Message-----
> > > > From: Yakov Rekhter [mailto:[e-mail]]
> > > > Sent: Friday, September 06, 2002 2:31 PM
> > > > To: Natale, Jonathan
> > > > Cc: [e-mail]
> > > > Subject: Re: admin dist/gp spec proposal 
> > > > 
> > > > 
> > > > Natale,
> > > > 
> > > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Abarbanel, Benjamin 
> [mailto:[e-mail]] 
> > > > > Sent: Friday, September 06, 2002 1:49 PM
> > > > > To: 'Natale, Jonathan'
> > > > > Subject: RE: admin dist/gp spec proposal
> > > > > 
> > > > > Jonathan:
> > > > > Forward this message to the IDR list. I think we dropped off.
> > > > > 
> > > > > Ben
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Natale, Jonathan [mailto:[e-mail]]
> > > > > > Sent: Friday, September 06, 2002 1:46 PM
> > > > > > To: 'Abarbanel, Benjamin'
> > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > 
> > > > > > 
> > > > > > I agree.  The default values of the various 
> protocols as they 
> > > > > > are currently
> > > > > > implemented make sense:
> > > > > > Connected
> > > > > > Static
> > > > > > Ebgp
> > > > > > Igp's
> > > > > > Ibgp
> > > > > > 
> > > > > > ...they should be documented in 1812 ideally, but 
> putting it 
> > > > > > in 1771 would
> > > > > > not hurt.  Added a phrase to indicate that they may be user 
> > > > > > configurable is
> > > > > > good too.
> > > > 
> > > > Perhaps it is time to update 1812. But let's not use BGP
> > > > spec as a replacement for updating 1812 - it is not.
> > > > 
> > > > Yakov.
> > > > 
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Abarbanel, Benjamin 
> > [mailto:[e-mail]] 
> > > > > Sent: Friday, September 06, 2002 11:39 AM
> > > > > To: 'Mathew Richardson'; Natale, Jonathan
> > > > > Cc: [e-mail]
> > > > > Subject: RE: admin dist/gp spec proposal
> > > > > 
> > > > > 
> > > > > 
> > > > >  
> > > > > > 
> > > > > > > Natale, Jonathan <[e-mail]> 
> [Fri, Sep 06, 
> > > > > > 2002 at 10:53:40AM -0400]:
> > > > > > >Add sect. in bgp draft stating that ebgp routes should be 
> > > > > > preferred over any
> > > > > > >igp routes and any igp routes should be preferred 
> over ibgp 
> > > > > > routes.  The
> > > > > > >exception to this is igp summary routes may be preferred 
> > > > > > over ebgp routes.
> > > > > > 
> > > > > > The EBGP vs. IBGP is already covered in section 
> > > 9.1.2.2.  As to how
> > > > > > BGP and non-BGP routes interact, I suspect that that really 
> > > > > > should remain
> > > > > > largely a local policy matter.  A BCP is probably in 
> > > order (does one
> > > > > > on this topic already exist?)
> > > > > >
> > > > > Clearly the BGP and non-BGP route competition for dominance 
> > > > > in the routing
> > > > > table is firstly, defaulted and secondly policy over-written 
> > > > > by a local
> > > > > router administrator.  Just some mention of operational 
> > > > > impact by turning 
> > > > > some policy knobs and changing certain route selection 
> > > > > decisions and their 
> > > > > control plane impacts will be nice. Maybe this belongs in a 
> > > > > different spec.
> > > > > 
> > > > > I find spreading the knowledge across many specs a bit 
> > > inconvenient.
> > > > > 
> > > > > IMHO,
> > > > > Ben
> > > > > 
> > > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA07112 for <[e-mail]>; Fri, 6 Sep 2002 15:30:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A97FF91326; Fri,  6 Sep 2002 15:29:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 769F491327; Fri,  6 Sep 2002 15:29:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 17E6791326 for <[e-mail]>; Fri,  6 Sep 2002 15:29:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 06B595DEFA; Fri,  6 Sep 2002 15:29:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id AFFE35DE58 for <[e-mail]>; Fri,  6 Sep 2002 15:29:53 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BWTA>; Fri, 6 Sep 2002 15:29:53 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: admin dist/gp spec proposal 
Date: Fri, 6 Sep 2002 15:29:43 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

"IP address assigned to that BGP speaker" is misleading.

Current implementation(s):
ID can be any 32 bit number except martians (0.0.0.0 255.255.255.255
127.x.x.x.x) and multicasts (>=224).x.x.x (it does NOT need to be an
interface's IP)

It may or may not be the same as other routing protocol's (OSPF) ID.

Changing it manually will cause all peers to be reset (without any warning).

Will be elected as... (should be a local matter, so I'll skip the details)

What I would like to see:
1 and only 1 router id per router (for all protocols) which is set equal to
the 1 and only 1 circuitless ip address(Bay/Wellfleet term, aka cisco
"loopback"--a term I don't like since it is often confused with loopback
address 127.x.x.x) which is an address officially assigned to the box (e.g.
no rfc1918/"private address", martian, nor multicast allowed) which cannot
be changed unless all routing protocols are restarted (obviously the admin
should be warned of this restart).

 

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Friday, September 06, 2002 3:01 PM
To: 'Yakov Rekhter'; Natale, Jonathan
Cc: [e-mail]
Subject: RE: admin dist/gp spec proposal 

Yakov:
  There is no reference to RFC1812 in the reference section nor references 
to this spec where appropriate in the BGP relevant discussions. As was 
earlier mentioned. At least we need to tie the thread between the two
specs so people know what the assumptions are.  

BTW. BGP Identifier is a very misleading way of naming what we know as the
Router ID in all other protocols. I would like to suggest we enhance its 
description as follows:

Current statement:
==================
"BGP Identifier:

         This 4-octet unsigned integer indicates the BGP Identifier of
         the sender. A given BGP speaker sets the value of its BGP
         Identifier to an IP address assigned to that BGP speaker.  The
         value of the BGP Identifier is determined on startup and is the
         same for every local interface and every BGP peer. "

New Statement:
==============
"BGP Identifier:

         This 4-octet unsigned integer indicates the BGP Identifier of
         the sender. A given BGP speaker sets the value of its BGP
         Identifier also known as the Router-ID, to an IP address assigned 
         to that BGP speaker. The value of the BGP Identifier is 
         determined on startup and is the same for every local interface 
         and every BGP peer and other IP related protocols. See [x],[y] for 
         more details on Router-ID useage between BGP and other protocols."

Where x = RFC1403,
      y = RFC1745

Ben
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Friday, September 06, 2002 2:31 PM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: admin dist/gp spec proposal 
> 
> 
> Natale,
> 
> > 
> > 
> > -----Original Message-----
> > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > Sent: Friday, September 06, 2002 1:49 PM
> > To: 'Natale, Jonathan'
> > Subject: RE: admin dist/gp spec proposal
> > 
> > Jonathan:
> > Forward this message to the IDR list. I think we dropped off.
> > 
> > Ben
> > 
> > > -----Original Message-----
> > > From: Natale, Jonathan [mailto:[e-mail]]
> > > Sent: Friday, September 06, 2002 1:46 PM
> > > To: 'Abarbanel, Benjamin'
> > > Subject: RE: admin dist/gp spec proposal
> > > 
> > > 
> > > I agree.  The default values of the various protocols as they 
> > > are currently
> > > implemented make sense:
> > > Connected
> > > Static
> > > Ebgp
> > > Igp's
> > > Ibgp
> > > 
> > > ...they should be documented in 1812 ideally, but putting it 
> > > in 1771 would
> > > not hurt.  Added a phrase to indicate that they may be user 
> > > configurable is
> > > good too.
> 
> Perhaps it is time to update 1812. But let's not use BGP
> spec as a replacement for updating 1812 - it is not.
> 
> Yakov.
> 
> > > 
> > > -----Original Message-----
> > > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > > Sent: Friday, September 06, 2002 11:39 AM
> > > To: 'Mathew Richardson'; Natale, Jonathan
> > > Cc: [e-mail]
> > > Subject: RE: admin dist/gp spec proposal
> > > 
> > > 
> > > 
> > >  
> > > > 
> > > > > Natale, Jonathan <[e-mail]> [Fri, Sep 06, 
> > > > 2002 at 10:53:40AM -0400]:
> > > > >Add sect. in bgp draft stating that ebgp routes should be 
> > > > preferred over any
> > > > >igp routes and any igp routes should be preferred over ibgp 
> > > > routes.  The
> > > > >exception to this is igp summary routes may be preferred 
> > > > over ebgp routes.
> > > > 
> > > > The EBGP vs. IBGP is already covered in section 
> 9.1.2.2.  As to how
> > > > BGP and non-BGP routes interact, I suspect that that really 
> > > > should remain
> > > > largely a local policy matter.  A BCP is probably in 
> order (does one
> > > > on this topic already exist?)
> > > >
> > > Clearly the BGP and non-BGP route competition for dominance 
> > > in the routing
> > > table is firstly, defaulted and secondly policy over-written 
> > > by a local
> > > router administrator.  Just some mention of operational 
> > > impact by turning 
> > > some policy knobs and changing certain route selection 
> > > decisions and their 
> > > control plane impacts will be nice. Maybe this belongs in a 
> > > different spec.
> > > 
> > > I find spreading the knowledge across many specs a bit 
> inconvenient.
> > > 
> > > IMHO,
> > > Ben
> > > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA07064 for <[e-mail]>; Fri, 6 Sep 2002 15:29:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BA14F91325; Fri,  6 Sep 2002 15:28:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D69A91326; Fri,  6 Sep 2002 15:28:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7BB8891325 for <[e-mail]>; Fri,  6 Sep 2002 15:28:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6421C5DEFA; Fri,  6 Sep 2002 15:28:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id E0A555DE58 for <[e-mail]>; Fri,  6 Sep 2002 15:28:35 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA04603; Fri, 6 Sep 2002 15:28:33 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA22174; Fri, 6 Sep 2002 15:28:35 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68Q3N9K>; Fri, 6 Sep 2002 15:28:34 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Fri, 6 Sep 2002 15:28:32 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> 
> > I would like to rephrase my statement on one sentence.
> > 
> > " BTW. BGP Identifier is a vague way of naming what we know as the
> >   Router-ID in all other IP related protocols."
> 
> This is *technically* incorrect. 
>
Is there a case where the BGP Identifier, should or must be different than
the Router-ID for the routing system to work correctly?

Ben

 
> 
> > 
> > 
> > > -----Original Message-----
> > > From: Abarbanel, Benjamin [mailto:[e-mail]]
> > > Sent: Friday, September 06, 2002 3:01 PM
> > > To: 'Yakov Rekhter'; Natale, Jonathan
> > > Cc: [e-mail]
> > > Subject: RE: admin dist/gp spec proposal 
> > > 
> > > 
> > > Yakov:
> > >   There is no reference to RFC1812 in the reference section 
> > > nor references 
> > > to this spec where appropriate in the BGP relevant 
> > > discussions. As was 
> > > earlier mentioned. At least we need to tie the thread 
> between the two
> > > specs so people know what the assumptions are.  
> > > 
> > > BTW. BGP Identifier is a very misleading way of naming what 
> > > we know as the
> > > Router ID in all other protocols. I would like to suggest we 
> > > enhance its 
> > > description as follows:
> > > 
> > > Current statement:
> > > ==================
> > > "BGP Identifier:
> > > 
> > >          This 4-octet unsigned integer indicates the BGP 
> Identifier of
> > >          the sender. A given BGP speaker sets the value of its BGP
> > >          Identifier to an IP address assigned to that BGP 
> > > speaker.  The
> > >          value of the BGP Identifier is determined on startup 
> > > and is the
> > >          same for every local interface and every BGP peer. "
> > > 
> > > New Statement:
> > > ==============
> > > "BGP Identifier:
> > > 
> > >          This 4-octet unsigned integer indicates the BGP 
> Identifier of
> > >          the sender. A given BGP speaker sets the value of its BGP
> > >          Identifier also known as the Router-ID, to an IP 
> > > address assigned 
> > >          to that BGP speaker. The value of the BGP Identifier is 
> > >          determined on startup and is the same for every 
> > > local interface 
> > >          and every BGP peer and other IP related protocols. 
> > > See [x],[y] for 
> > >          more details on Router-ID useage between BGP and 
> > > other protocols."
> > > 
> > > Where x = RFC1403,
> > >       y = RFC1745
> > > 
> > > Ben
> > > > -----Original Message-----
> > > > From: Yakov Rekhter [mailto:[e-mail]]
> > > > Sent: Friday, September 06, 2002 2:31 PM
> > > > To: Natale, Jonathan
> > > > Cc: [e-mail]
> > > > Subject: Re: admin dist/gp spec proposal 
> > > > 
> > > > 
> > > > Natale,
> > > > 
> > > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Abarbanel, Benjamin 
> [mailto:[e-mail]] 
> > > > > Sent: Friday, September 06, 2002 1:49 PM
> > > > > To: 'Natale, Jonathan'
> > > > > Subject: RE: admin dist/gp spec proposal
> > > > > 
> > > > > Jonathan:
> > > > > Forward this message to the IDR list. I think we dropped off.
> > > > > 
> > > > > Ben
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Natale, Jonathan [mailto:[e-mail]]
> > > > > > Sent: Friday, September 06, 2002 1:46 PM
> > > > > > To: 'Abarbanel, Benjamin'
> > > > > > Subject: RE: admin dist/gp spec proposal
> > > > > > 
> > > > > > 
> > > > > > I agree.  The default values of the various 
> protocols as they 
> > > > > > are currently
> > > > > > implemented make sense:
> > > > > > Connected
> > > > > > Static
> > > > > > Ebgp
> > > > > > Igp's
> > > > > > Ibgp
> > > > > > 
> > > > > > ...they should be documented in 1812 ideally, but 
> putting it 
> > > > > > in 1771 would
> > > > > > not hurt.  Added a phrase to indicate that they may be user 
> > > > > > configurable is
> > > > > > good too.
> > > > 
> > > > Perhaps it is time to update 1812. But let's not use BGP
> > > > spec as a replacement for updating 1812 - it is not.
> > > > 
> > > > Yakov.
> > > > 
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Abarbanel, Benjamin 
> > [mailto:[e-mail]] 
> > > > > Sent: Friday, September 06, 2002 11:39 AM
> > > > > To: 'Mathew Richardson'; Natale, Jonathan
> > > > > Cc: [e-mail]
> > > > > Subject: RE: admin dist/gp spec proposal
> > > > > 
> > > > > 
> > > > > 
> > > > >  
> > > > > > 
> > > > > > > Natale, Jonathan <[e-mail]> 
> [Fri, Sep 06, 
> > > > > > 2002 at 10:53:40AM -0400]:
> > > > > > >Add sect. in bgp draft stating that ebgp routes should be 
> > > > > > preferred over any
> > > > > > >igp routes and any igp routes should be preferred 
> over ibgp 
> > > > > > routes.  The
> > > > > > >exception to this is igp summary routes may be preferred 
> > > > > > over ebgp routes.
> > > > > > 
> > > > > > The EBGP vs. IBGP is already covered in section 
> > > 9.1.2.2.  As to how
> > > > > > BGP and non-BGP routes interact, I suspect that that really 
> > > > > > should remain
> > > > > > largely a local policy matter.  A BCP is probably in 
> > > order (does one
> > > > > > on this topic already exist?)
> > > > > >
> > > > > Clearly the BGP and non-BGP route competition for dominance 
> > > > > in the routing
> > > > > table is firstly, defaulted and secondly policy over-written 
> > > > > by a local
> > > > > router administrator.  Just some mention of operational 
> > > > > impact by turning 
> > > > > some policy knobs and changing certain route selection 
> > > > > decisions and their 
> > > > > control plane impacts will be nice. Maybe this belongs in a 
> > > > > different spec.
> > > > > 
> > > > > I find spreading the knowledge across many specs a bit 
> > > inconvenient.
> > > > > 
> > > > > IMHO,
> > > > > Ben
> > > > > 
> > > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA06851 for <[e-mail]>; Fri, 6 Sep 2002 15:22:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B91FA91322; Fri,  6 Sep 2002 15:21:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 884D991325; Fri,  6 Sep 2002 15:21:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 501FB91322 for <[e-mail]>; Fri,  6 Sep 2002 15:21:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3CAF15DEFA; Fri,  6 Sep 2002 15:21:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id A0E9A5DE58 for <[e-mail]>; Fri,  6 Sep 2002 15:21:47 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g86JLjm22512; Fri, 6 Sep 2002 12:21:45 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: Re: admin dist/gp spec proposal 
In-Reply-To: Your message of "Fri, 06 Sep 2002 15:12:14 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 06 Sep 2002 12:21:45 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I would like to rephrase my statement on one sentence.
> 
> " BTW. BGP Identifier is a vague way of naming what we know as the
>   Router-ID in all other IP related protocols."

This is *technically* incorrect. 

Yakov.

> Ben
> 
> 
> > -----Original Message-----
> > From: Abarbanel, Benjamin [mailto:[e-mail]]
> > Sent: Friday, September 06, 2002 3:01 PM
> > To: 'Yakov Rekhter'; Natale, Jonathan
> > Cc: [e-mail]
> > Subject: RE: admin dist/gp spec proposal 
> > 
> > 
> > Yakov:
> >   There is no reference to RFC1812 in the reference section 
> > nor references 
> > to this spec where appropriate in the BGP relevant 
> > discussions. As was 
> > earlier mentioned. At least we need to tie the thread between the two
> > specs so people know what the assumptions are.  
> > 
> > BTW. BGP Identifier is a very misleading way of naming what 
> > we know as the
> > Router ID in all other protocols. I would like to suggest we 
> > enhance its 
> > description as follows:
> > 
> > Current statement:
> > ==================
> > "BGP Identifier:
> > 
> >          This 4-octet unsigned integer indicates the BGP Identifier of
> >          the sender. A given BGP speaker sets the value of its BGP
> >          Identifier to an IP address assigned to that BGP 
> > speaker.  The
> >          value of the BGP Identifier is determined on startup 
> > and is the
> >          same for every local interface and every BGP peer. "
> > 
> > New Statement:
> > ==============
> > "BGP Identifier:
> > 
> >          This 4-octet unsigned integer indicates the BGP Identifier of
> >          the sender. A given BGP speaker sets the value of its BGP
> >          Identifier also known as the Router-ID, to an IP 
> > address assigned 
> >          to that BGP speaker. The value of the BGP Identifier is 
> >          determined on startup and is the same for every 
> > local interface 
> >          and every BGP peer and other IP related protocols. 
> > See [x],[y] for 
> >          more details on Router-ID useage between BGP and 
> > other protocols."
> > 
> > Where x = RFC1403,
> >       y = RFC1745
> > 
> > Ben
> > > -----Original Message-----
> > > From: Yakov Rekhter [mailto:[e-mail]]
> > > Sent: Friday, September 06, 2002 2:31 PM
> > > To: Natale, Jonathan
> > > Cc: [e-mail]
> > > Subject: Re: admin dist/gp spec proposal 
> > > 
> > > 
> > > Natale,
> > > 
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > > > Sent: Friday, September 06, 2002 1:49 PM
> > > > To: 'Natale, Jonathan'
> > > > Subject: RE: admin dist/gp spec proposal
> > > > 
> > > > Jonathan:
> > > > Forward this message to the IDR list. I think we dropped off.
> > > > 
> > > > Ben
> > > > 
> > > > > -----Original Message-----
> > > > > From: Natale, Jonathan [mailto:[e-mail]]
> > > > > Sent: Friday, September 06, 2002 1:46 PM
> > > > > To: 'Abarbanel, Benjamin'
> > > > > Subject: RE: admin dist/gp spec proposal
> > > > > 
> > > > > 
> > > > > I agree.  The default values of the various protocols as they 
> > > > > are currently
> > > > > implemented make sense:
> > > > > Connected
> > > > > Static
> > > > > Ebgp
> > > > > Igp's
> > > > > Ibgp
> > > > > 
> > > > > ...they should be documented in 1812 ideally, but putting it 
> > > > > in 1771 would
> > > > > not hurt.  Added a phrase to indicate that they may be user 
> > > > > configurable is
> > > > > good too.
> > > 
> > > Perhaps it is time to update 1812. But let's not use BGP
> > > spec as a replacement for updating 1812 - it is not.
> > > 
> > > Yakov.
> > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Abarbanel, Benjamin 
> [mailto:[e-mail]] 
> > > > Sent: Friday, September 06, 2002 11:39 AM
> > > > To: 'Mathew Richardson'; Natale, Jonathan
> > > > Cc: [e-mail]
> > > > Subject: RE: admin dist/gp spec proposal
> > > > 
> > > > 
> > > > 
> > > >  
> > > > > 
> > > > > > Natale, Jonathan <[e-mail]> [Fri, Sep 06, 
> > > > > 2002 at 10:53:40AM -0400]:
> > > > > >Add sect. in bgp draft stating that ebgp routes should be 
> > > > > preferred over any
> > > > > >igp routes and any igp routes should be preferred over ibgp 
> > > > > routes.  The
> > > > > >exception to this is igp summary routes may be preferred 
> > > > > over ebgp routes.
> > > > > 
> > > > > The EBGP vs. IBGP is already covered in section 
> > 9.1.2.2.  As to how
> > > > > BGP and non-BGP routes interact, I suspect that that really 
> > > > > should remain
> > > > > largely a local policy matter.  A BCP is probably in 
> > order (does one
> > > > > on this topic already exist?)
> > > > >
> > > > Clearly the BGP and non-BGP route competition for dominance 
> > > > in the routing
> > > > table is firstly, defaulted and secondly policy over-written 
> > > > by a local
> > > > router administrator.  Just some mention of operational 
> > > > impact by turning 
> > > > some policy knobs and changing certain route selection 
> > > > decisions and their 
> > > > control plane impacts will be nice. Maybe this belongs in a 
> > > > different spec.
> > > > 
> > > > I find spreading the knowledge across many specs a bit 
> > inconvenient.
> > > > 
> > > > IMHO,
> > > > Ben
> > > > 
> > 


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 PAA06516 for <[e-mail]>; Fri, 6 Sep 2002 15:13:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CB5F09131E; Fri,  6 Sep 2002 15:12:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 947D091322; Fri,  6 Sep 2002 15:12:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8AF849131E for <[e-mail]>; Fri,  6 Sep 2002 15:12:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 798255DEFA; Fri,  6 Sep 2002 15:12:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 056D55DED9 for <[e-mail]>; Fri,  6 Sep 2002 15:12:17 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03470; Fri, 6 Sep 2002 15:12:14 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA18726; Fri, 6 Sep 2002 15:12:16 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68Q3NDY>; Fri, 6 Sep 2002 15:12:14 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Fri, 6 Sep 2002 15:12:14 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I would like to rephrase my statement on one sentence.

" BTW. BGP Identifier is a vague way of naming what we know as the
  Router-ID in all other IP related protocols."

Ben


> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]]
> Sent: Friday, September 06, 2002 3:01 PM
> To: 'Yakov Rekhter'; Natale, Jonathan
> Cc: [e-mail]
> Subject: RE: admin dist/gp spec proposal 
> 
> 
> Yakov:
>   There is no reference to RFC1812 in the reference section 
> nor references 
> to this spec where appropriate in the BGP relevant 
> discussions. As was 
> earlier mentioned. At least we need to tie the thread between the two
> specs so people know what the assumptions are.  
> 
> BTW. BGP Identifier is a very misleading way of naming what 
> we know as the
> Router ID in all other protocols. I would like to suggest we 
> enhance its 
> description as follows:
> 
> Current statement:
> ==================
> "BGP Identifier:
> 
>          This 4-octet unsigned integer indicates the BGP Identifier of
>          the sender. A given BGP speaker sets the value of its BGP
>          Identifier to an IP address assigned to that BGP 
> speaker.  The
>          value of the BGP Identifier is determined on startup 
> and is the
>          same for every local interface and every BGP peer. "
> 
> New Statement:
> ==============
> "BGP Identifier:
> 
>          This 4-octet unsigned integer indicates the BGP Identifier of
>          the sender. A given BGP speaker sets the value of its BGP
>          Identifier also known as the Router-ID, to an IP 
> address assigned 
>          to that BGP speaker. The value of the BGP Identifier is 
>          determined on startup and is the same for every 
> local interface 
>          and every BGP peer and other IP related protocols. 
> See [x],[y] for 
>          more details on Router-ID useage between BGP and 
> other protocols."
> 
> Where x = RFC1403,
>       y = RFC1745
> 
> Ben
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Friday, September 06, 2002 2:31 PM
> > To: Natale, Jonathan
> > Cc: [e-mail]
> > Subject: Re: admin dist/gp spec proposal 
> > 
> > 
> > Natale,
> > 
> > > 
> > > 
> > > -----Original Message-----
> > > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > > Sent: Friday, September 06, 2002 1:49 PM
> > > To: 'Natale, Jonathan'
> > > Subject: RE: admin dist/gp spec proposal
> > > 
> > > Jonathan:
> > > Forward this message to the IDR list. I think we dropped off.
> > > 
> > > Ben
> > > 
> > > > -----Original Message-----
> > > > From: Natale, Jonathan [mailto:[e-mail]]
> > > > Sent: Friday, September 06, 2002 1:46 PM
> > > > To: 'Abarbanel, Benjamin'
> > > > Subject: RE: admin dist/gp spec proposal
> > > > 
> > > > 
> > > > I agree.  The default values of the various protocols as they 
> > > > are currently
> > > > implemented make sense:
> > > > Connected
> > > > Static
> > > > Ebgp
> > > > Igp's
> > > > Ibgp
> > > > 
> > > > ...they should be documented in 1812 ideally, but putting it 
> > > > in 1771 would
> > > > not hurt.  Added a phrase to indicate that they may be user 
> > > > configurable is
> > > > good too.
> > 
> > Perhaps it is time to update 1812. But let's not use BGP
> > spec as a replacement for updating 1812 - it is not.
> > 
> > Yakov.
> > 
> > > > 
> > > > -----Original Message-----
> > > > From: Abarbanel, Benjamin 
[mailto:[e-mail]] 
> > > Sent: Friday, September 06, 2002 11:39 AM
> > > To: 'Mathew Richardson'; Natale, Jonathan
> > > Cc: [e-mail]
> > > Subject: RE: admin dist/gp spec proposal
> > > 
> > > 
> > > 
> > >  
> > > > 
> > > > > Natale, Jonathan <[e-mail]> [Fri, Sep 06, 
> > > > 2002 at 10:53:40AM -0400]:
> > > > >Add sect. in bgp draft stating that ebgp routes should be 
> > > > preferred over any
> > > > >igp routes and any igp routes should be preferred over ibgp 
> > > > routes.  The
> > > > >exception to this is igp summary routes may be preferred 
> > > > over ebgp routes.
> > > > 
> > > > The EBGP vs. IBGP is already covered in section 
> 9.1.2.2.  As to how
> > > > BGP and non-BGP routes interact, I suspect that that really 
> > > > should remain
> > > > largely a local policy matter.  A BCP is probably in 
> order (does one
> > > > on this topic already exist?)
> > > >
> > > Clearly the BGP and non-BGP route competition for dominance 
> > > in the routing
> > > table is firstly, defaulted and secondly policy over-written 
> > > by a local
> > > router administrator.  Just some mention of operational 
> > > impact by turning 
> > > some policy knobs and changing certain route selection 
> > > decisions and their 
> > > control plane impacts will be nice. Maybe this belongs in a 
> > > different spec.
> > > 
> > > I find spreading the knowledge across many specs a bit 
> inconvenient.
> > > 
> > > IMHO,
> > > Ben
> > > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA06167 for <[e-mail]>; Fri, 6 Sep 2002 15:05:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BDBE091321; Fri,  6 Sep 2002 15:01:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CAD6A9131E; Fri,  6 Sep 2002 15:01:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 99A3C91320 for <[e-mail]>; Fri,  6 Sep 2002 15:01:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 859A05DE69; Fri,  6 Sep 2002 15:01:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 065E65DE6A for <[e-mail]>; Fri,  6 Sep 2002 15:01:15 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA02829; Fri, 6 Sep 2002 15:01:12 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA16822; Fri, 6 Sep 2002 15:01:14 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68Q3MVG>; Fri, 6 Sep 2002 15:01:13 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Fri, 6 Sep 2002 15:01:12 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov:
  There is no reference to RFC1812 in the reference section nor references 
to this spec where appropriate in the BGP relevant discussions. As was 
earlier mentioned. At least we need to tie the thread between the two
specs so people know what the assumptions are.  

BTW. BGP Identifier is a very misleading way of naming what we know as the
Router ID in all other protocols. I would like to suggest we enhance its 
description as follows:

Current statement:
==================
"BGP Identifier:

         This 4-octet unsigned integer indicates the BGP Identifier of
         the sender. A given BGP speaker sets the value of its BGP
         Identifier to an IP address assigned to that BGP speaker.  The
         value of the BGP Identifier is determined on startup and is the
         same for every local interface and every BGP peer. "

New Statement:
==============
"BGP Identifier:

         This 4-octet unsigned integer indicates the BGP Identifier of
         the sender. A given BGP speaker sets the value of its BGP
         Identifier also known as the Router-ID, to an IP address assigned 
         to that BGP speaker. The value of the BGP Identifier is 
         determined on startup and is the same for every local interface 
         and every BGP peer and other IP related protocols. See [x],[y] for 
         more details on Router-ID useage between BGP and other protocols."

Where x = RFC1403,
      y = RFC1745

Ben
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Friday, September 06, 2002 2:31 PM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: admin dist/gp spec proposal 
> 
> 
> Natale,
> 
> > 
> > 
> > -----Original Message-----
> > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > Sent: Friday, September 06, 2002 1:49 PM
> > To: 'Natale, Jonathan'
> > Subject: RE: admin dist/gp spec proposal
> > 
> > Jonathan:
> > Forward this message to the IDR list. I think we dropped off.
> > 
> > Ben
> > 
> > > -----Original Message-----
> > > From: Natale, Jonathan [mailto:[e-mail]]
> > > Sent: Friday, September 06, 2002 1:46 PM
> > > To: 'Abarbanel, Benjamin'
> > > Subject: RE: admin dist/gp spec proposal
> > > 
> > > 
> > > I agree.  The default values of the various protocols as they 
> > > are currently
> > > implemented make sense:
> > > Connected
> > > Static
> > > Ebgp
> > > Igp's
> > > Ibgp
> > > 
> > > ...they should be documented in 1812 ideally, but putting it 
> > > in 1771 would
> > > not hurt.  Added a phrase to indicate that they may be user 
> > > configurable is
> > > good too.
> 
> Perhaps it is time to update 1812. But let's not use BGP
> spec as a replacement for updating 1812 - it is not.
> 
> Yakov.
> 
> > > 
> > > -----Original Message-----
> > > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > > Sent: Friday, September 06, 2002 11:39 AM
> > > To: 'Mathew Richardson'; Natale, Jonathan
> > > Cc: [e-mail]
> > > Subject: RE: admin dist/gp spec proposal
> > > 
> > > 
> > > 
> > >  
> > > > 
> > > > > Natale, Jonathan <[e-mail]> [Fri, Sep 06, 
> > > > 2002 at 10:53:40AM -0400]:
> > > > >Add sect. in bgp draft stating that ebgp routes should be 
> > > > preferred over any
> > > > >igp routes and any igp routes should be preferred over ibgp 
> > > > routes.  The
> > > > >exception to this is igp summary routes may be preferred 
> > > > over ebgp routes.
> > > > 
> > > > The EBGP vs. IBGP is already covered in section 
> 9.1.2.2.  As to how
> > > > BGP and non-BGP routes interact, I suspect that that really 
> > > > should remain
> > > > largely a local policy matter.  A BCP is probably in 
> order (does one
> > > > on this topic already exist?)
> > > >
> > > Clearly the BGP and non-BGP route competition for dominance 
> > > in the routing
> > > table is firstly, defaulted and secondly policy over-written 
> > > by a local
> > > router administrator.  Just some mention of operational 
> > > impact by turning 
> > > some policy knobs and changing certain route selection 
> > > decisions and their 
> > > control plane impacts will be nice. Maybe this belongs in a 
> > > different spec.
> > > 
> > > I find spreading the knowledge across many specs a bit 
> inconvenient.
> > > 
> > > IMHO,
> > > Ben
> > > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA05117 for <[e-mail]>; Fri, 6 Sep 2002 14:35:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5D0209131C; Fri,  6 Sep 2002 14:33:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04CA191320; Fri,  6 Sep 2002 14:33:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 167AD9131F for <[e-mail]>; Fri,  6 Sep 2002 14:32:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E7BE05DE3F; Fri,  6 Sep 2002 14:32:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 9B74A5DDE1 for <[e-mail]>; Fri,  6 Sep 2002 14:32:56 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BWKM>; Fri, 6 Sep 2002 14:32:52 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: admin dist/gp spec proposal 
Date: Fri, 6 Sep 2002 14:32:42 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Ok, I agree with you, but I figured I'd throw it out there anyway...

What year is 1812 going to be updated?

:-)

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Friday, September 06, 2002 2:31 PM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: admin dist/gp spec proposal 

Natale,

> 
> 
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Friday, September 06, 2002 1:49 PM
> To: 'Natale, Jonathan'
> Subject: RE: admin dist/gp spec proposal
> 
> Jonathan:
> Forward this message to the IDR list. I think we dropped off.
> 
> Ben
> 
> > -----Original Message-----
> > From: Natale, Jonathan [mailto:[e-mail]]
> > Sent: Friday, September 06, 2002 1:46 PM
> > To: 'Abarbanel, Benjamin'
> > Subject: RE: admin dist/gp spec proposal
> > 
> > 
> > I agree.  The default values of the various protocols as they 
> > are currently
> > implemented make sense:
> > Connected
> > Static
> > Ebgp
> > Igp's
> > Ibgp
> > 
> > ...they should be documented in 1812 ideally, but putting it 
> > in 1771 would
> > not hurt.  Added a phrase to indicate that they may be user 
> > configurable is
> > good too.

Perhaps it is time to update 1812. But let's not use BGP
spec as a replacement for updating 1812 - it is not.

Yakov.

> > 
> > -----Original Message-----
> > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > Sent: Friday, September 06, 2002 11:39 AM
> > To: 'Mathew Richardson'; Natale, Jonathan
> > Cc: [e-mail]
> > Subject: RE: admin dist/gp spec proposal
> > 
> > 
> > 
> >  
> > > 
> > > > Natale, Jonathan <[e-mail]> [Fri, Sep 06, 
> > > 2002 at 10:53:40AM -0400]:
> > > >Add sect. in bgp draft stating that ebgp routes should be 
> > > preferred over any
> > > >igp routes and any igp routes should be preferred over ibgp 
> > > routes.  The
> > > >exception to this is igp summary routes may be preferred 
> > > over ebgp routes.
> > > 
> > > The EBGP vs. IBGP is already covered in section 9.1.2.2.  As to how
> > > BGP and non-BGP routes interact, I suspect that that really 
> > > should remain
> > > largely a local policy matter.  A BCP is probably in order (does one
> > > on this topic already exist?)
> > >
> > Clearly the BGP and non-BGP route competition for dominance 
> > in the routing
> > table is firstly, defaulted and secondly policy over-written 
> > by a local
> > router administrator.  Just some mention of operational 
> > impact by turning 
> > some policy knobs and changing certain route selection 
> > decisions and their 
> > control plane impacts will be nice. Maybe this belongs in a 
> > different spec.
> > 
> > I find spreading the knowledge across many specs a bit inconvenient.
> > 
> > IMHO,
> > Ben
> > 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA05091 for <[e-mail]>; Fri, 6 Sep 2002 14:34:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A3DB19131A; Fri,  6 Sep 2002 14:33:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 549CF9131C; Fri,  6 Sep 2002 14:33:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E23BB9131A for <[e-mail]>; Fri,  6 Sep 2002 14:31:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C92C75DE3F; Fri,  6 Sep 2002 14:31:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 2CC4E5DDE1 for <[e-mail]>; Fri,  6 Sep 2002 14:31:09 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g86IV8m18650; Fri, 6 Sep 2002 11:31:08 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: admin dist/gp spec proposal 
In-Reply-To: Your message of "Fri, 06 Sep 2002 14:21:21 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 06 Sep 2002 11:31:08 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Natale,

> 
> 
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Friday, September 06, 2002 1:49 PM
> To: 'Natale, Jonathan'
> Subject: RE: admin dist/gp spec proposal
> 
> Jonathan:
> Forward this message to the IDR list. I think we dropped off.
> 
> Ben
> 
> > -----Original Message-----
> > From: Natale, Jonathan [mailto:[e-mail]]
> > Sent: Friday, September 06, 2002 1:46 PM
> > To: 'Abarbanel, Benjamin'
> > Subject: RE: admin dist/gp spec proposal
> > 
> > 
> > I agree.  The default values of the various protocols as they 
> > are currently
> > implemented make sense:
> > Connected
> > Static
> > Ebgp
> > Igp's
> > Ibgp
> > 
> > ...they should be documented in 1812 ideally, but putting it 
> > in 1771 would
> > not hurt.  Added a phrase to indicate that they may be user 
> > configurable is
> > good too.

Perhaps it is time to update 1812. But let's not use BGP
spec as a replacement for updating 1812 - it is not.

Yakov.

> > 
> > -----Original Message-----
> > From: Abarbanel, Benjamin [mailto:[e-mail]] 
> > Sent: Friday, September 06, 2002 11:39 AM
> > To: 'Mathew Richardson'; Natale, Jonathan
> > Cc: [e-mail]
> > Subject: RE: admin dist/gp spec proposal
> > 
> > 
> > 
> >  
> > > 
> > > > Natale, Jonathan <[e-mail]> [Fri, Sep 06, 
> > > 2002 at 10:53:40AM -0400]:
> > > >Add sect. in bgp draft stating that ebgp routes should be 
> > > preferred over any
> > > >igp routes and any igp routes should be preferred over ibgp 
> > > routes.  The
> > > >exception to this is igp summary routes may be preferred 
> > > over ebgp routes.
> > > 
> > > The EBGP vs. IBGP is already covered in section 9.1.2.2.  As to how
> > > BGP and non-BGP routes interact, I suspect that that really 
> > > should remain
> > > largely a local policy matter.  A BCP is probably in order (does one
> > > on this topic already exist?)
> > >
> > Clearly the BGP and non-BGP route competition for dominance 
> > in the routing
> > table is firstly, defaulted and secondly policy over-written 
> > by a local
> > router administrator.  Just some mention of operational 
> > impact by turning 
> > some policy knobs and changing certain route selection 
> > decisions and their 
> > control plane impacts will be nice. Maybe this belongs in a 
> > different spec.
> > 
> > I find spreading the knowledge across many specs a bit inconvenient.
> > 
> > IMHO,
> > Ben
> > 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA04855 for <[e-mail]>; Fri, 6 Sep 2002 14:26:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0ECBB91318; Fri,  6 Sep 2002 14:26:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC0B791319; Fri,  6 Sep 2002 14:26:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 672DC91318 for <[e-mail]>; Fri,  6 Sep 2002 14:26:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 552D15DF6F; Fri,  6 Sep 2002 14:26:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id ED6965DEFA for <[e-mail]>; Fri,  6 Sep 2002 14:26:05 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g86IQ3m18140; Fri, 6 Sep 2002 11:26:03 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: Mathew Richardson <[e-mail]>, [e-mail]
Subject: Re: bgp spec proposal 
In-Reply-To: Your message of "Fri, 06 Sep 2002 13:41:48 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 06 Sep 2002 11:26:03 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Which brings up another point:  What about the obscure rule that OSPF/BGP
> router IDs should match?  Should this be added? 

No, as this belongs to OSPF/BGP interaction, and interaction
between BGP and OSPF (as well as interaction between BGP and
any other protocols) is outside the scope of this document.

Yakov.

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Friday, September 06, 2002 11:32 AM
> To: Mathew Richardson
> Cc: Natale, Jonathan; [e-mail]
> Subject: Re: admin dist/gp spec proposal 
> 
> Mathew,
> 
> > > Natale, Jonathan <[e-mail]> [Fri, Sep 06, 2002 at
> 10:53:40
> AM -0400]:
> > >Add sect. in bgp draft stating that ebgp routes should be preferred over
> any
> > >igp routes and any igp routes should be preferred over ibgp routes.  The
> > >exception to this is igp summary routes may be preferred over ebgp
> routes.
> > 
> > The EBGP vs. IBGP is already covered in section 9.1.2.2.  As to how
> > BGP and non-BGP routes interact, I suspect that that really should remain
> > largely a local policy matter.  A BCP is probably in order (does one
> > on this topic already exist?)
> 
> The only document that was trying to address the issue of how BGP and 
> non-BGP routes interact (BGP/OSPF interaction) was moved to Historic
> some time ago.
> 
> 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 OAA04713 for <[e-mail]>; Fri, 6 Sep 2002 14:22:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EE15891314; Fri,  6 Sep 2002 14:21:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB42291315; Fri,  6 Sep 2002 14:21:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 78E5791314 for <[e-mail]>; Fri,  6 Sep 2002 14:21:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 63A755DF56; Fri,  6 Sep 2002 14:21:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 82F415DEFA for <[e-mail]>; Fri,  6 Sep 2002 14:21:22 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BW29>; Fri, 6 Sep 2002 14:21:22 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: admin dist/gp spec proposal
Date: Fri, 6 Sep 2002 14:21:21 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Friday, September 06, 2002 1:49 PM
To: 'Natale, Jonathan'
Subject: RE: admin dist/gp spec proposal

Jonathan:
Forward this message to the IDR list. I think we dropped off.

Ben

> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Friday, September 06, 2002 1:46 PM
> To: 'Abarbanel, Benjamin'
> Subject: RE: admin dist/gp spec proposal
> 
> 
> I agree.  The default values of the various protocols as they 
> are currently
> implemented make sense:
> Connected
> Static
> Ebgp
> Igp's
> Ibgp
> 
> ...they should be documented in 1812 ideally, but putting it 
> in 1771 would
> not hurt.  Added a phrase to indicate that they may be user 
> configurable is
> good too.
> 
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Friday, September 06, 2002 11:39 AM
> To: 'Mathew Richardson'; Natale, Jonathan
> Cc: [e-mail]
> Subject: RE: admin dist/gp spec proposal
> 
> 
> 
>  
> > 
> > > Natale, Jonathan <[e-mail]> [Fri, Sep 06, 
> > 2002 at 10:53:40AM -0400]:
> > >Add sect. in bgp draft stating that ebgp routes should be 
> > preferred over any
> > >igp routes and any igp routes should be preferred over ibgp 
> > routes.  The
> > >exception to this is igp summary routes may be preferred 
> > over ebgp routes.
> > 
> > The EBGP vs. IBGP is already covered in section 9.1.2.2.  As to how
> > BGP and non-BGP routes interact, I suspect that that really 
> > should remain
> > largely a local policy matter.  A BCP is probably in order (does one
> > on this topic already exist?)
> >
> Clearly the BGP and non-BGP route competition for dominance 
> in the routing
> table is firstly, defaulted and secondly policy over-written 
> by a local
> router administrator.  Just some mention of operational 
> impact by turning 
> some policy knobs and changing certain route selection 
> decisions and their 
> control plane impacts will be nice. Maybe this belongs in a 
> different spec.
> 
> I find spreading the knowledge across many specs a bit inconvenient.
> 
> IMHO,
> Ben
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA04497 for <[e-mail]>; Fri, 6 Sep 2002 14:16:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3C7FE91313; Fri,  6 Sep 2002 14:15:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B77391314; Fri,  6 Sep 2002 14:15:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E21191313 for <[e-mail]>; Fri,  6 Sep 2002 14:15:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C5A3B5DED9; Fri,  6 Sep 2002 14:15:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 0E1B95DE8B for <[e-mail]>; Fri,  6 Sep 2002 14:15:08 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BW2F>; Fri, 6 Sep 2002 14:15:04 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Mathew Richardson'" <[e-mail]>, "Cambria, Mike" <[e-mail]>
Cc: "'Abarbanel, Benjamin'" <[e-mail]>, [e-mail]
Subject: RE: Proxy: comments on section 9.1.3
Date: Fri, 6 Sep 2002 14:14:53 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I don't think that is necessary.  Somewhere (not sure where) it already says
there can only be 1 best route, right?

-----Original Message-----
From: 'Mathew Richardson' [mailto:[e-mail]] 
Sent: Friday, September 06, 2002 12:18 PM
To: Cambria, Mike
Cc: 'Abarbanel, Benjamin'; [e-mail]
Subject: Re: Proxy: comments on section 9.1.3

> Cambria, Mike <[e-mail]> [Fri, Sep 06, 2002 at 11:53:53AM
-0400]:
>
>(Pretending that I'm) reading the draft for the first time...
>
>Your comment:
>
>Somewhere in section 9.1.x, Do we want to mention the fact that the best 
>Loc-RIB BGP route for a given destination is still advertised to outgoing 
>peers via the Adj-RIB-out after it passes the outbound policy filtering,
>even though it is not really used for forwarding?
>
>and the text in 9.1.3 can be read as a contraction of section 2 (when only
>considering the base document, no route reflectors, route servers etc.):
>
>"... one must focus on the rule that a BGP speaker advertises to its peers
>(other BGP speakers which it communicates with) in neighboring ASs only
>those routes that it itself uses."

I thought that that was in there somewhere :)  I guess I've just gotten
in to the bad habit of skipping the intro and going straight to the
"good stuff" :)

>If, in the scope of an implementation of only what is specified in this
>draft, one can advertise to a peer what is in Loc-RIB but not the Route
>Table, the text in section 2 should be clarified.  Otherwise, the text in
>9.1.3 (and your comment) should be clarified, as it doesn't mention
anything
>about the route table.

How about changing the paragraph after c) in 9.1.2 to:

  The local speaker SHALL then install that route in the Loc-RIB,
  replacing any route to the same destination that is currently being
  held in the Loc-RIB.  This route SHALL then also be installed in
  the BGP speakers forwarding table.

<snip>

I personally much prefer this.  It helps keep the base spec focused
on describing the base protocol.

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 NAA03387 for <[e-mail]>; Fri, 6 Sep 2002 13:43:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 14CE591317; Fri,  6 Sep 2002 13:42:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D047F91316; Fri,  6 Sep 2002 13:42:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A0D6091313 for <[e-mail]>; Fri,  6 Sep 2002 13:41:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 817185DE64; Fri,  6 Sep 2002 13:41:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 360B25DE5E for <[e-mail]>; Fri,  6 Sep 2002 13:41:55 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BWDK>; Fri, 6 Sep 2002 13:41:50 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, Mathew Richardson <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: bgp spec proposal 
Date: Fri, 6 Sep 2002 13:41:48 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Which brings up another point:  What about the obscure rule that OSPF/BGP
router IDs should match?  Should this be added? 

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Friday, September 06, 2002 11:32 AM
To: Mathew Richardson
Cc: Natale, Jonathan; [e-mail]
Subject: Re: admin dist/gp spec proposal 

Mathew,

> > Natale, Jonathan <[e-mail]> [Fri, Sep 06, 2002 at
10:53:40
AM -0400]:
> >Add sect. in bgp draft stating that ebgp routes should be preferred over
any
> >igp routes and any igp routes should be preferred over ibgp routes.  The
> >exception to this is igp summary routes may be preferred over ebgp
routes.
> 
> The EBGP vs. IBGP is already covered in section 9.1.2.2.  As to how
> BGP and non-BGP routes interact, I suspect that that really should remain
> largely a local policy matter.  A BCP is probably in order (does one
> on this topic already exist?)

The only document that was trying to address the issue of how BGP and 
non-BGP routes interact (BGP/OSPF interaction) was moved to Historic
some time ago.

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 MAA00383 for <[e-mail]>; Fri, 6 Sep 2002 12:22:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 79DE791307; Fri,  6 Sep 2002 12:22:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3AD6191308; Fri,  6 Sep 2002 12:22:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4DC1391307 for <[e-mail]>; Fri,  6 Sep 2002 12:22:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3A7145DE4E; Fri,  6 Sep 2002 12:22:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id B67A55DE4C for <[e-mail]>; Fri,  6 Sep 2002 12:22:31 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA22300; Fri, 6 Sep 2002 12:22:29 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA13107; Fri, 6 Sep 2002 12:22:30 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68Q31LH>; Fri, 6 Sep 2002 12:22:30 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, "'Mathew Richardson'" <[e-mail]>, [e-mail]
Subject: RE: Proxy: comments on section 9.1.3 
Date: Fri, 6 Sep 2002 12:22:29 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Natale:

I think NRLI has no meaning in this sentence, change it to: 

> OK, thanks.
> 
> Then maybe:
> 
> "one must focus on the rule that a BGP speaker advertises
>    to its peers (other BGP speakers which it communicates with) in
>    neighboring ASs only those routes that it itself uses."
> 
> Should be changed to
> 
> "one must focus on the rule that a BGP speaker advertises
>    to its peers (other BGP speakers which it communicates with) in
>    neighboring ASs only routes whose NLRIs are locally reachable."
> 

Third version:

 "one must focus on the rule that a BGP speaker advertises
  to its peers (other BGP speakers which it communicates with) in
  neighboring ASs only routes which are locally reachable. Local
  reachability can be achieved by having any protocol route to 
  the given destination in the routing table."
 
Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA00221 for <[e-mail]>; Fri, 6 Sep 2002 12:19:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id AFA4591306; Fri,  6 Sep 2002 12:19:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 82F7D91307; Fri,  6 Sep 2002 12:19:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 461BD91306 for <[e-mail]>; Fri,  6 Sep 2002 12:18:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 29E895DE4E; Fri,  6 Sep 2002 12:18:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 749485DE4C for <[e-mail]>; Fri,  6 Sep 2002 12:18:19 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g86GIGS32730; Fri, 6 Sep 2002 12:18:16 -0400 (EDT) (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 g86GIDG32722; Fri, 6 Sep 2002 12:18:13 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g86GIDF25436; Fri, 6 Sep 2002 12:18:13 -0400 (EDT)
Date: Fri, 6 Sep 2002 12:18:13 -0400
From: "'Mathew Richardson'" <[e-mail]>
To: "Cambria, Mike" <[e-mail]>
Cc: "'Abarbanel, Benjamin'" <[e-mail]>, [e-mail]
Subject: Re: Proxy: comments on section 9.1.3
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

> Cambria, Mike <[e-mail]> [Fri, Sep 06, 2002 at 11:53:53AM -0400]:
>
>(Pretending that I'm) reading the draft for the first time...
>
>Your comment:
>
>Somewhere in section 9.1.x, Do we want to mention the fact that the best 
>Loc-RIB BGP route for a given destination is still advertised to outgoing 
>peers via the Adj-RIB-out after it passes the outbound policy filtering,
>even though it is not really used for forwarding?
>
>and the text in 9.1.3 can be read as a contraction of section 2 (when only
>considering the base document, no route reflectors, route servers etc.):
>
>"... one must focus on the rule that a BGP speaker advertises to its peers
>(other BGP speakers which it communicates with) in neighboring ASs only
>those routes that it itself uses."

I thought that that was in there somewhere :)  I guess I've just gotten
in to the bad habit of skipping the intro and going straight to the
"good stuff" :)

>If, in the scope of an implementation of only what is specified in this
>draft, one can advertise to a peer what is in Loc-RIB but not the Route
>Table, the text in section 2 should be clarified.  Otherwise, the text in
>9.1.3 (and your comment) should be clarified, as it doesn't mention anything
>about the route table.

How about changing the paragraph after c) in 9.1.2 to:

  The local speaker SHALL then install that route in the Loc-RIB,
  replacing any route to the same destination that is currently being
  held in the Loc-RIB.  This route SHALL then also be installed in
  the BGP speakers forwarding table.

<snip>

I personally much prefer this.  It helps keep the base spec focused
on describing the base protocol.

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 MAA29948 for <[e-mail]>; Fri, 6 Sep 2002 12:13:21 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DF2CD91305; Fri,  6 Sep 2002 12:13:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B068291306; Fri,  6 Sep 2002 12:13:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B8C791305 for <[e-mail]>; Fri,  6 Sep 2002 12:13:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3500E5DE4C; Fri,  6 Sep 2002 12:13:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id E01515DDCA for <[e-mail]>; Fri,  6 Sep 2002 12:12:59 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BVZD>; Fri, 6 Sep 2002 12:12:59 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'Abarbanel, Benjamin'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, "'Mathew Richardson'" <[e-mail]>, [e-mail]
Subject: RE: Proxy: comments on section 9.1.3 
Date: Fri, 6 Sep 2002 12:12:49 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

OK, thanks.

Then maybe:

"one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with) in
   neighboring ASs only those routes that it itself uses."

Should be changed to

"one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with) in
   neighboring ASs only routes whose NLRIs are locally reachable."

Since currently a bgp router will advertise bgp routes that are not in the
local routing table via bgp (as long as the NLRI of the route is in the
routing table via some routing protocol, the route will/may be advertised).

Maybe some reference to [Juniper] "active route" should be added? 

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Friday, September 06, 2002 11:29 AM
To: Natale, Jonathan
Cc: 'Abarbanel, Benjamin'; 'Jeffrey Haas'; 'Mathew Richardson';
[e-mail]
Subject: Re: Proxy: comments on section 9.1.3 

Natale,

> The confusion here is "routes".  Is it:
> Prefix + prefix length (this is what it is in my mind)
> OR
> Prefix + prefix length + protocol
> OR
> Prefix + prefix length + next hop
> OR
> Prefix + prefix length + next hop + protocol
> OR
> ???

>From section 3.1:

  For the purpose of this protocol, a route is defined as a unit of
  information that pairs a set of destinations with the attributes
  of a path to those destinations.  The set of destinations are the   
  systems whose IP addresses are reported in the Network Layer
  Reachability Information (NLRI) field and the path is the information
  reported in the path attributes field of the same UPDATE message.

Yakov.

> 
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Friday, September 06, 2002 10:55 AM
> To: 'Jeffrey Haas'; 'Mathew Richardson'
> Cc: Abarbanel, Benjamin; [e-mail]
> Subject: RE: Proxy: comments on section 9.1.3
> 
> Jeff:
>   I did not imply we forbid these non-FIB routes from being added to the
> Loc-RIB,
> just that we cover this case by saying we still knowingly advertise these
> non-FIB
> routes to our outbound BGP peers. Anyone with any doubt will know exactly
> what we
> mean. Perhaps a statement as to the impact on the topological graph in
this 
> scenario will be helpfull.
> 
> Ben
> 
> > -----Original Message-----
> > From: Jeffrey Haas [mailto:[e-mail]]
> > Sent: Friday, September 06, 2002 10:50 AM
> > To: 'Mathew Richardson'
> > Cc: Abarbanel, Benjamin; [e-mail]
> > Subject: Re: Proxy: comments on section 9.1.3
> > 
> > 
> > On Fri, Sep 06, 2002 at 10:41:38AM -0400, 'Mathew Richardson' wrote:
> > > And what do either of these have to do with the base BGP spec?
> > 
> > Adding language that specifically forbidding adding routes to Loc-Rib
> > when they wouldn't be added to the FIB would preclude some forms
> > of route concentrators.  I don't think we really want to do that.
> > 
> > > mrr
> > 
> > -- 
> > 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 MAA29692 for <[e-mail]>; Fri, 6 Sep 2002 12:05:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BB18791304; Fri,  6 Sep 2002 12:05:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A4E391305; Fri,  6 Sep 2002 12:05:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9923191304 for <[e-mail]>; Fri,  6 Sep 2002 12:05:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7D5925DE4E; Fri,  6 Sep 2002 12:05:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 038485DE4C for <[e-mail]>; Fri,  6 Sep 2002 12:05:13 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA21338; Fri, 6 Sep 2002 12:05:10 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA09099; Fri, 6 Sep 2002 12:05:12 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68Q3D22>; Fri, 6 Sep 2002 12:05:11 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Mathew Richardson'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal
Date: Fri, 6 Sep 2002 12:05:10 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Friday, September 06, 2002 11:48 AM
> To: Abarbanel, Benjamin
> Cc: 'Mathew Richardson'; Natale, Jonathan; [e-mail]
> Subject: Re: admin dist/gp spec proposal
> 
> 
> On Fri, Sep 06, 2002 at 11:39:02AM -0400, Abarbanel, Benjamin wrote:
> > Clearly the BGP and non-BGP route competition for dominance 
> in the routing
> > table is firstly, defaulted and secondly policy 
> over-written by a local
> > router administrator.  Just some mention of operational 
> impact by turning 
> > some policy knobs and changing certain route selection 
> decisions and their 
> > control plane impacts will be nice. Maybe this belongs in a 
> different spec.
> > 
> > I find spreading the knowledge across many specs a bit inconvenient.
> 
> : 9.4 Originating BGP routes
> : 
> :    A BGP speaker may originate BGP routes by injecting routing
> :    information acquired by some other means (e.g. via an 
> IGP) into BGP.
> :    A BGP speaker that originates BGP routes shall assign 
> the degree of
> :    preference to these routes by passing them through the Decision
> :    Process (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 Section 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.
>
 
What I meant is, by changing the routing table policy for priority
preference of each route type (IBGP, EBGP, Static, Direct, OSPF, ISIS, etc.)
in the routing table can lead to unstable and unpredictable control plane
behavior.  Although, if all the routers in the AS are changed accordingly,
it will minimize the instability. Again, maybe this belongs somewhere else,
RFC1812, etc. Maybe some mention of this fact would be nice.

P.S. If its already covered somewhere, ignore the suggestion.

Ben

 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA29349 for <[e-mail]>; Fri, 6 Sep 2002 11:56:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A8C5B91300; Fri,  6 Sep 2002 11:54:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67D6791303; Fri,  6 Sep 2002 11:54:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 042DB91300 for <[e-mail]>; Fri,  6 Sep 2002 11:54:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DD24B5DE4E; Fri,  6 Sep 2002 11:54:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from rerun.avayactc.com (rerun.avayactc.com [199.93.237.2]) by segue.merit.edu (Postfix) with ESMTP id 829725DE4C for <[e-mail]>; Fri,  6 Sep 2002 11:54:04 -0400 (EDT)
Received: by rerun.avayactc.com with Internet Mail Service (5.5.2653.19) id <30ZWHQYS>; Fri, 6 Sep 2002 11:54:01 -0400
Message-ID: <[e-mail]>
From: "Cambria, Mike" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>, "'Mathew Richardson'" <[e-mail]>, [e-mail]
Subject: RE: Proxy: comments on section 9.1.3
Date: Fri, 6 Sep 2002 11:53:53 -0400 
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

(Pretending that I'm) reading the draft for the first time...

Your comment:

Somewhere in section 9.1.x, Do we want to mention the fact that the best 
Loc-RIB BGP route for a given destination is still advertised to outgoing 
peers via the Adj-RIB-out after it passes the outbound policy filtering,
even though it is not really used for forwarding?

and the text in 9.1.3 can be read as a contraction of section 2 (when only
considering the base document, no route reflectors, route servers etc.):

"... one must focus on the rule that a BGP speaker advertises to its peers
(other BGP speakers which it communicates with) in neighboring ASs only
those routes that it itself uses."


If, in the scope of an implementation of only what is specified in this
draft, one can advertise to a peer what is in Loc-RIB but not the Route
Table, the text in section 2 should be clarified.  Otherwise, the text in
9.1.3 (and your comment) should be clarified, as it doesn't mention anything
about the route table.

All this assumes that Loc-RIB <> Routing Table, which is how I read the
draft.

MikeC


-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]]
Sent: Friday, September 06, 2002 10:27 AM
To: 'Mathew Richardson'; [e-mail]
Subject: RE: Proxy: comments on section 9.1.3


Mathew:

 
> >
> >I'm looking for clarification to wording in section 9.1.3 
> Phase 3: Route
> >Dessemination of draft-ietf-idr-bgp4-17.txt.
> >
> >My understanding is that a BGP route should not be 
> advertised to a peer if
> >that route is not also in the Routing Table (e.g. FIB).  I 
> was looking for
> >wording to support this, but am now starting to second guess myself.
> >

What about the case where the best BGP route for a given destination is
rejected/
preempted from the routing table by a higher preferenced IGP, Static, etc.,
route which is really used for forwarding?

Somewhere in section 9.1.x, Do we want to mention the fact that the best 
Loc-RIB BGP route for a given destination is still advertised to outgoing 
peers via the Adj-RIB-out after it passes the outbound policy filtering,
even though it is not really used for forwarding?

Ben


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 LAA29149 for <[e-mail]>; Fri, 6 Sep 2002 11:49:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 60531912FE; Fri,  6 Sep 2002 11:48:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2430091303; Fri,  6 Sep 2002 11:48:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3168E912FE for <[e-mail]>; Fri,  6 Sep 2002 11:48:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F152B5DE4E; Fri,  6 Sep 2002 11:48:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 6F7A95DE4C for <[e-mail]>; Fri,  6 Sep 2002 11:48:07 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g86Fm5O31211; Fri, 6 Sep 2002 11:48:05 -0400 (EDT) (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 g86Fm2G31204; Fri, 6 Sep 2002 11:48:02 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g86Fm2s03507; Fri, 6 Sep 2002 11:48:02 -0400 (EDT)
Date: Fri, 6 Sep 2002 11:48:02 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Mathew Richardson'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: Re: admin dist/gp spec proposal
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 Fri, Sep 06, 2002 at 11:39:02AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Sep 06, 2002 at 11:39:02AM -0400, Abarbanel, Benjamin wrote:
> Clearly the BGP and non-BGP route competition for dominance in the routing
> table is firstly, defaulted and secondly policy over-written by a local
> router administrator.  Just some mention of operational impact by turning 
> some policy knobs and changing certain route selection decisions and their 
> control plane impacts will be nice. Maybe this belongs in a different spec.
> 
> I find spreading the knowledge across many specs a bit inconvenient.

: 9.4 Originating BGP routes
: 
:    A BGP speaker may originate BGP routes by injecting routing
:    information acquired by some other means (e.g. via an IGP) into BGP.
:    A BGP speaker that originates BGP routes shall assign the degree of
:    preference to these routes by passing them through the Decision
:    Process (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 Section 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.

> Ben

-- 
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 LAA28803 for <[e-mail]>; Fri, 6 Sep 2002 11:40:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E061E91302; Fri,  6 Sep 2002 11:39:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD9DE91301; Fri,  6 Sep 2002 11:39:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F9A1912FE for <[e-mail]>; Fri,  6 Sep 2002 11:39:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 578455DE55; Fri,  6 Sep 2002 11:39:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id D37475DE4E for <[e-mail]>; Fri,  6 Sep 2002 11:39:05 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA19722; Fri, 6 Sep 2002 11:39:03 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03932; Fri, 6 Sep 2002 11:39:04 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68Q3B8W>; Fri, 6 Sep 2002 11:39:04 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Mathew Richardson'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: admin dist/gp spec proposal
Date: Fri, 6 Sep 2002 11:39:02 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

 
> 
> > Natale, Jonathan <[e-mail]> [Fri, Sep 06, 
> 2002 at 10:53:40AM -0400]:
> >Add sect. in bgp draft stating that ebgp routes should be 
> preferred over any
> >igp routes and any igp routes should be preferred over ibgp 
> routes.  The
> >exception to this is igp summary routes may be preferred 
> over ebgp routes.
> 
> The EBGP vs. IBGP is already covered in section 9.1.2.2.  As to how
> BGP and non-BGP routes interact, I suspect that that really 
> should remain
> largely a local policy matter.  A BCP is probably in order (does one
> on this topic already exist?)
>
Clearly the BGP and non-BGP route competition for dominance in the routing
table is firstly, defaulted and secondly policy over-written by a local
router administrator.  Just some mention of operational impact by turning 
some policy knobs and changing certain route selection decisions and their 
control plane impacts will be nice. Maybe this belongs in a different spec.

I find spreading the knowledge across many specs a bit inconvenient.

IMHO,
Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA28622 for <[e-mail]>; Fri, 6 Sep 2002 11:35:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7497F912FC; Fri,  6 Sep 2002 11:34:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 41F5D912FB; Fri,  6 Sep 2002 11:34:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 23A93912FF for <[e-mail]>; Fri,  6 Sep 2002 11:34:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 052A35DE5B; Fri,  6 Sep 2002 11:34:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 46E865DE4E for <[e-mail]>; Fri,  6 Sep 2002 11:34:08 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g86FY6V30593; Fri, 6 Sep 2002 11:34:06 -0400 (EDT) (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 g86FY3G30586; Fri, 6 Sep 2002 11:34:03 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g86FY3903355; Fri, 6 Sep 2002 11:34:03 -0400 (EDT)
Date: Fri, 6 Sep 2002 11:34:03 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Natale, Jonathan'" <[e-mail]>, "'Mathew Richardson'" <[e-mail]>, [e-mail]
Subject: Re: Proxy: comments on section 9.1.3
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 Fri, Sep 06, 2002 at 11:26:15AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

IMHO:
A prefix implies a prefix and its associated prefix length.
A destination implies an associated nexthop.
A route is a destination for a particular protocol.  A route
may have additional properties that are protocol specific.

The base bgp document (sec 3.1) has always had the unfortunate wording
implying that a route is a path attribute set and multiple NLRI.

On Fri, Sep 06, 2002 at 11:26:15AM -0400, Abarbanel, Benjamin wrote:
> A route is not a route, unless you have a Next Hop address. How can 
> you get from point A to point B without a (Next Hop) delivary router?
> 
> IMHO, 
> Ben

-- 
Jeff Haas 
NextHop Technologies


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 LAA28613 for <[e-mail]>; Fri, 6 Sep 2002 11:34:58 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A617D912F9; Fri,  6 Sep 2002 11:31:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 694CE912FB; Fri,  6 Sep 2002 11:31:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE3CD912F9 for <[e-mail]>; Fri,  6 Sep 2002 11:31:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D9C155DE55; Fri,  6 Sep 2002 11:31:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 767D15DE4E for <[e-mail]>; Fri,  6 Sep 2002 11:31:44 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g86FVgm04183; Fri, 6 Sep 2002 08:31:42 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Mathew Richardson <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: Re: admin dist/gp spec proposal 
In-Reply-To: Your message of "Fri, 06 Sep 2002 11:28:03 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 06 Sep 2002 08:31:42 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Mathew,

> > Natale, Jonathan <[e-mail]> [Fri, Sep 06, 2002 at 10:53:40
AM -0400]:
> >Add sect. in bgp draft stating that ebgp routes should be preferred over any
> >igp routes and any igp routes should be preferred over ibgp routes.  The
> >exception to this is igp summary routes may be preferred over ebgp routes.
> 
> The EBGP vs. IBGP is already covered in section 9.1.2.2.  As to how
> BGP and non-BGP routes interact, I suspect that that really should remain
> largely a local policy matter.  A BCP is probably in order (does one
> on this topic already exist?)

The only document that was trying to address the issue of how BGP and 
non-BGP routes interact (BGP/OSPF interaction) was moved to Historic
some time ago.

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 LAA28417 for <[e-mail]>; Fri, 6 Sep 2002 11:30:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C7D17912F8; Fri,  6 Sep 2002 11:29:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96F23912F9; Fri,  6 Sep 2002 11:29:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4A861912F8 for <[e-mail]>; Fri,  6 Sep 2002 11:29:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 331CF5DE5C; Fri,  6 Sep 2002 11:29:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 94D775DE55 for <[e-mail]>; Fri,  6 Sep 2002 11:29:33 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g86FTSm03949; Fri, 6 Sep 2002 08:29:28 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Abarbanel, Benjamin'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, "'Mathew Richardson'" <[e-mail]>, [e-mail]
Subject: Re: Proxy: comments on section 9.1.3 
In-Reply-To: Your message of "Fri, 06 Sep 2002 11:14:24 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 06 Sep 2002 08:29:28 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Natale,

> The confusion here is "routes".  Is it:
> Prefix + prefix length (this is what it is in my mind)
> OR
> Prefix + prefix length + protocol
> OR
> Prefix + prefix length + next hop
> OR
> Prefix + prefix length + next hop + protocol
> OR
> ???

>From section 3.1:

  For the purpose of this protocol, a route is defined as a unit of
  information that pairs a set of destinations with the attributes
  of a path to those destinations.  The set of destinations are the   
  systems whose IP addresses are reported in the Network Layer
  Reachability Information (NLRI) field and the path is the information
  reported in the path attributes field of the same UPDATE message.

Yakov.

> 
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Friday, September 06, 2002 10:55 AM
> To: 'Jeffrey Haas'; 'Mathew Richardson'
> Cc: Abarbanel, Benjamin; [e-mail]
> Subject: RE: Proxy: comments on section 9.1.3
> 
> Jeff:
>   I did not imply we forbid these non-FIB routes from being added to the
> Loc-RIB,
> just that we cover this case by saying we still knowingly advertise these
> non-FIB
> routes to our outbound BGP peers. Anyone with any doubt will know exactly
> what we
> mean. Perhaps a statement as to the impact on the topological graph in this 
> scenario will be helpfull.
> 
> Ben
> 
> > -----Original Message-----
> > From: Jeffrey Haas [mailto:[e-mail]]
> > Sent: Friday, September 06, 2002 10:50 AM
> > To: 'Mathew Richardson'
> > Cc: Abarbanel, Benjamin; [e-mail]
> > Subject: Re: Proxy: comments on section 9.1.3
> > 
> > 
> > On Fri, Sep 06, 2002 at 10:41:38AM -0400, 'Mathew Richardson' wrote:
> > > And what do either of these have to do with the base BGP spec?
> > 
> > Adding language that specifically forbidding adding routes to Loc-Rib
> > when they wouldn't be added to the FIB would preclude some forms
> > of route concentrators.  I don't think we really want to do that.
> > 
> > > mrr
> > 
> > -- 
> > 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 LAA28369 for <[e-mail]>; Fri, 6 Sep 2002 11:28:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 95562912F7; Fri,  6 Sep 2002 11:28:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 68CF3912F8; Fri,  6 Sep 2002 11:28:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 54ED5912F7 for <[e-mail]>; Fri,  6 Sep 2002 11:28:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 32B3B5DE5B; Fri,  6 Sep 2002 11:28:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 7AC5A5DE55 for <[e-mail]>; Fri,  6 Sep 2002 11:28:07 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g86FS6030340; Fri, 6 Sep 2002 11:28:06 -0400 (EDT) (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 g86FS3G30333; Fri, 6 Sep 2002 11:28:03 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g86FS3q25029; Fri, 6 Sep 2002 11:28:03 -0400 (EDT)
Date: Fri, 6 Sep 2002 11:28:03 -0400
From: Mathew Richardson <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: admin dist/gp spec proposal
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

> Natale, Jonathan <[e-mail]> [Fri, Sep 06, 2002 at 10:53:40AM -0400]:
>Add sect. in bgp draft stating that ebgp routes should be preferred over any
>igp routes and any igp routes should be preferred over ibgp routes.  The
>exception to this is igp summary routes may be preferred over ebgp routes.

The EBGP vs. IBGP is already covered in section 9.1.2.2.  As to how
BGP and non-BGP routes interact, I suspect that that really should remain
largely a local policy matter.  A BCP is probably in order (does one
on this topic already exist?)

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 LAA28311 for <[e-mail]>; Fri, 6 Sep 2002 11:26:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2EB44912F6; Fri,  6 Sep 2002 11:26:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA1C7912F7; Fri,  6 Sep 2002 11:26:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 00942912F6 for <[e-mail]>; Fri,  6 Sep 2002 11:26:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E0CE95DE59; Fri,  6 Sep 2002 11:26:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 6A8D05DE55 for <[e-mail]>; Fri,  6 Sep 2002 11:26:18 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18926; Fri, 6 Sep 2002 11:26:15 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA00633; Fri, 6 Sep 2002 11:26:17 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68Q3BA1>; Fri, 6 Sep 2002 11:26:16 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, "'Mathew Richardson'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Proxy: comments on section 9.1.3
Date: Fri, 6 Sep 2002 11:26:15 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

A route is not a route, unless you have a Next Hop address. How can 
you get from point A to point B without a (Next Hop) delivary router?

IMHO, 
Ben

> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Friday, September 06, 2002 11:14 AM
> To: 'Abarbanel, Benjamin'; 'Jeffrey Haas'; 'Mathew Richardson'
> Cc: [e-mail]
> Subject: RE: Proxy: comments on section 9.1.3
> 
> 
> The confusion here is "routes".  Is it:
> Prefix + prefix length (this is what it is in my mind)
> OR
> Prefix + prefix length + protocol
> OR
> Prefix + prefix length + next hop
> OR
> Prefix + prefix length + next hop + protocol
> OR
> ???
> 
> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]] 
> Sent: Friday, September 06, 2002 10:55 AM
> To: 'Jeffrey Haas'; 'Mathew Richardson'
> Cc: Abarbanel, Benjamin; [e-mail]
> Subject: RE: Proxy: comments on section 9.1.3
> 
> Jeff:
>   I did not imply we forbid these non-FIB routes from being 
> added to the
> Loc-RIB,
> just that we cover this case by saying we still knowingly 
> advertise these
> non-FIB
> routes to our outbound BGP peers. Anyone with any doubt will 
> know exactly
> what we
> mean. Perhaps a statement as to the impact on the topological 
> graph in this 
> scenario will be helpfull.
> 
> Ben
> 
> > -----Original Message-----
> > From: Jeffrey Haas [mailto:[e-mail]]
> > Sent: Friday, September 06, 2002 10:50 AM
> > To: 'Mathew Richardson'
> > Cc: Abarbanel, Benjamin; [e-mail]
> > Subject: Re: Proxy: comments on section 9.1.3
> > 
> > 
> > On Fri, Sep 06, 2002 at 10:41:38AM -0400, 'Mathew Richardson' wrote:
> > > And what do either of these have to do with the base BGP spec?
> > 
> > Adding language that specifically forbidding adding routes 
> to Loc-Rib
> > when they wouldn't be added to the FIB would preclude some forms
> > of route concentrators.  I don't think we really want to do that.
> > 
> > > mrr
> > 
> > -- 
> > 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 LAA28220 for <[e-mail]>; Fri, 6 Sep 2002 11:23:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 32AD7912F5; Fri,  6 Sep 2002 11:23:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE1D0912F6; Fri,  6 Sep 2002 11:23:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D62AD912F5 for <[e-mail]>; Fri,  6 Sep 2002 11:23:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C33AB5DE5A; Fri,  6 Sep 2002 11:23:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id D68C45DE4E for <[e-mail]>; Fri,  6 Sep 2002 11:23:34 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g86FNY230172 for [e-mail]; Fri, 6 Sep 2002 11:23:34 -0400 (EDT) (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 g86FNVG30165 for <[e-mail]>; Fri, 6 Sep 2002 11:23:31 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g86FNVu25004 for [e-mail]; Fri, 6 Sep 2002 11:23:31 -0400 (EDT)
Date: Fri, 6 Sep 2002 11:23:30 -0400
From: "'Mathew Richardson'" <[e-mail]>
To: [e-mail]
Subject: Re: Proxy: comments on section 9.1.3
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4i
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

> 'Mathew Richardson' <[e-mail]> [Fri, Sep 06, 2002 at 11:16:06AM -0400]:

<snip>

Replying to myself to correct some poor grammar:

>I think that case must either be disallowed, or placed outside the
>scope of the base document.  How about adding to section 9.1.3,
>at the end:
>
>  Any local-policy which results in reachability being added to an
>  Adj-RIB-Out without also being added to the local BGP speaker's
>  forwarding table, are beyond the scope of this document.

<snip>

The last line should read:

  forwarding table is beyond the scope of this document.

,rr


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA28098 for <[e-mail]>; Fri, 6 Sep 2002 11:19:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7D924912F3; Fri,  6 Sep 2002 11:19:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 42CD2912F5; Fri,  6 Sep 2002 11:19:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D2B47912F3 for <[e-mail]>; Fri,  6 Sep 2002 11:19:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 852FA5DE5E; Fri,  6 Sep 2002 11:19:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id C16CB5DE5B for <[e-mail]>; Fri,  6 Sep 2002 11:19:10 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA18503; Fri, 6 Sep 2002 11:19:03 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA29444; Fri, 6 Sep 2002 11:19:02 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68Q3AXL>; Fri, 6 Sep 2002 11:19:02 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Mathew Richardson'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Proxy: comments on section 9.1.3
Date: Fri, 6 Sep 2002 11:19:00 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Mathew:
 
> >Wrong, there is an IGP or static route to destination D in 
> the routing
> >table as the best forwarding route, the BGP route to 
> destination D that is
> >installed in the Loc-RIB with a different Next Hop router is 
> not used for
> >forwarding. That is the inconsistency I am talking about.
> 
> <snip>
> 
> I think that case must either be disallowed, or placed outside the
> scope of the base document.  How about adding to section 9.1.3,
> at the end:
> 
>   Any local-policy which results in reachability being added to an
>   Adj-RIB-Out without also being added to the local BGP speaker's
>   forwarding table, are beyond the scope of this document.
> 
>  
This is a good start. I will be happy with this, unless people want 
more definitive answer on this point.

Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA28016 for <[e-mail]>; Fri, 6 Sep 2002 11:18:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BE268912FA; Fri,  6 Sep 2002 11:17:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85634912FB; Fri,  6 Sep 2002 11:17:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 24F98912FA for <[e-mail]>; Fri,  6 Sep 2002 11:17:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0F5835DE51; Fri,  6 Sep 2002 11:17:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id BC6215DE4E for <[e-mail]>; Fri,  6 Sep 2002 11:17:28 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BVRB>; Fri, 6 Sep 2002 11:17:28 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal
Date: Fri, 6 Sep 2002 11:17:19 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

More terms that need to be defined--is static/direct an IGP? I think they
are, so I need to add other exceptions to my statement below--static is
preferred over all other protocols except direct.  Again, this should be in
1812, but it is not...(another discusson...)

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Friday, September 06, 2002 10:57 AM
To: 'Natale, Jonathan'; [e-mail]
Subject: RE: admin dist/gp spec proposal

Natale:
  Sorry, I should have been more precise on whether it was EBGP or IBGP .vs.
IGP or Static. But you get my point, right?

Ben

> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Friday, September 06, 2002 10:54 AM
> To: [e-mail]
> Subject: admin dist/gp spec proposal
> 
> 
> Add sect. in bgp draft stating that ebgp routes should be 
> preferred over any
> igp routes and any igp routes should be preferred over ibgp 
> routes.  The
> exception to this is igp summary routes may be preferred over 
> ebgp routes.
> 
> PS
> RFC1812 needs to be updated and brought to a STANDARD level 
> (it discusses
> admin. Dist. concept, but does not say the obvious-- 
> connected preferred
> over static preferred over dynamic, etc.)  
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA27984 for <[e-mail]>; Fri, 6 Sep 2002 11:17:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7516C912F4; Fri,  6 Sep 2002 11:16:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 119FF912F6; Fri,  6 Sep 2002 11:16:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B75C2912F4 for <[e-mail]>; Fri,  6 Sep 2002 11:16:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A0B4F5DE55; Fri,  6 Sep 2002 11:16:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 205035DE53 for <[e-mail]>; Fri,  6 Sep 2002 11:16:11 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g86FG9x29866; Fri, 6 Sep 2002 11:16:09 -0400 (EDT) (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 g86FG6G29859; Fri, 6 Sep 2002 11:16:06 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g86FG6824958; Fri, 6 Sep 2002 11:16:06 -0400 (EDT)
Date: Fri, 6 Sep 2002 11:16:06 -0400
From: "'Mathew Richardson'" <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: Proxy: comments on section 9.1.3
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

> Abarbanel, Benjamin <[e-mail]> [Fri, Sep 06, 2002 at 10:43:25AM -0400]:
>Mathew:
>
>> -----Original Message-----
>> From: 'Mathew Richardson' [mailto:[e-mail]]
>> Sent: Friday, September 06, 2002 10:34 AM
>> To: Abarbanel, Benjamin
>> Cc: [e-mail]
>> Subject: Re: Proxy: comments on section 9.1.3
>> 
>> 
>> > Abarbanel, Benjamin <[e-mail]> [Fri, 
>> Sep 06, 2002 at 10:26:59AM -0400]:
>> >Mathew:

<snip something that Mr. Abarbanel and I seem to agree on>

>> >Somewhere in section 9.1.x, Do we want to mention the fact 
>> that the best 
>> >Loc-RIB BGP route for a given destination is still 
>> advertised to outgoing 
>> >peers via the Adj-RIB-out after it passes the outbound 
>> policy filtering,
>> >even though it is not really used for forwarding?
>> 
>> <snip>
>> 
>> You're talking about the case where a BGP route to some destination D
>> has been installed in the Loc-RIB, but no route to 
>> destination D has been
>> added to the forwarding table?  I'm not sure we want to 
>> elaborate on that
>> case, except, perhaps, to disallow it.
>
>Wrong, there is an IGP or static route to destination D in the routing
>table as the best forwarding route, the BGP route to destination D that is
>installed in the Loc-RIB with a different Next Hop router is not used for
>forwarding. That is the inconsistency I am talking about.

<snip>

I think that case must either be disallowed, or placed outside the
scope of the base document.  How about adding to section 9.1.3,
at the end:

  Any local-policy which results in reachability being added to an
  Adj-RIB-Out without also being added to the local BGP speaker's
  forwarding table, are beyond the scope of this document.

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 LAA27960 for <[e-mail]>; Fri, 6 Sep 2002 11:17:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 21A2E912F2; Fri,  6 Sep 2002 11:14:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DCEE0912F4; Fri,  6 Sep 2002 11:14:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3B154912F2 for <[e-mail]>; Fri,  6 Sep 2002 11:14:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 286AD5DE58; Fri,  6 Sep 2002 11:14:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id D751B5DE55 for <[e-mail]>; Fri,  6 Sep 2002 11:14:28 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BVQ4>; Fri, 6 Sep 2002 11:14:28 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>, "'Jeffrey Haas'" <[e-mail]>, "'Mathew Richardson'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Proxy: comments on section 9.1.3
Date: Fri, 6 Sep 2002 11:14:24 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

The confusion here is "routes".  Is it:
Prefix + prefix length (this is what it is in my mind)
OR
Prefix + prefix length + protocol
OR
Prefix + prefix length + next hop
OR
Prefix + prefix length + next hop + protocol
OR
???

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Friday, September 06, 2002 10:55 AM
To: 'Jeffrey Haas'; 'Mathew Richardson'
Cc: Abarbanel, Benjamin; [e-mail]
Subject: RE: Proxy: comments on section 9.1.3

Jeff:
  I did not imply we forbid these non-FIB routes from being added to the
Loc-RIB,
just that we cover this case by saying we still knowingly advertise these
non-FIB
routes to our outbound BGP peers. Anyone with any doubt will know exactly
what we
mean. Perhaps a statement as to the impact on the topological graph in this 
scenario will be helpfull.

Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Friday, September 06, 2002 10:50 AM
> To: 'Mathew Richardson'
> Cc: Abarbanel, Benjamin; [e-mail]
> Subject: Re: Proxy: comments on section 9.1.3
> 
> 
> On Fri, Sep 06, 2002 at 10:41:38AM -0400, 'Mathew Richardson' wrote:
> > And what do either of these have to do with the base BGP spec?
> 
> Adding language that specifically forbidding adding routes to Loc-Rib
> when they wouldn't be added to the FIB would preclude some forms
> of route concentrators.  I don't think we really want to do that.
> 
> > mrr
> 
> -- 
> 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 LAA27689 for <[e-mail]>; Fri, 6 Sep 2002 11:08:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B25A0912EF; Fri,  6 Sep 2002 11:08:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 798E3912F0; Fri,  6 Sep 2002 11:08:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2EF13912EF for <[e-mail]>; Fri,  6 Sep 2002 11:08:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 20F785DE56; Fri,  6 Sep 2002 11:08:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id CFAD65DE55 for <[e-mail]>; Fri,  6 Sep 2002 11:08:18 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BVP3>; Fri, 6 Sep 2002 11:08:18 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: bgp draft review
Date: Fri, 6 Sep 2002 11:08:08 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C255B7.3540F1E0"
Sender: [e-mail]
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C255B7.3540F1E0
Content-Type: text/plain

Somewhere it says ebgp peers must be direct, right?  So then ttl should be
1, right?  Maybe that should be added.

 

Also, a option to allow non-direct ebgp should be added.


------_=_NextPart_001_01C255B7.3540F1E0
Content-Type: text/html

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">


<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Somewhere it says ebgp peers must be direct, right?&nbsp; So then
ttl should be 1, right?&nbsp; Maybe that should be added.</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Also, a option to allow non-direct ebgp should be added.</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C255B7.3540F1E0--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA27249 for <[e-mail]>; Fri, 6 Sep 2002 10:56:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 59B66912EA; Fri,  6 Sep 2002 10:56:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22ECC912ED; Fri,  6 Sep 2002 10:56:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3DD8A912EA for <[e-mail]>; Fri,  6 Sep 2002 10:56:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 282EB5DE4F; Fri,  6 Sep 2002 10:56:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id A5D1D5DE4E for <[e-mail]>; Fri,  6 Sep 2002 10:56:37 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16665; Fri, 6 Sep 2002 10:56:35 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA24202; Fri, 6 Sep 2002 10:56:36 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QN0NX>; Fri, 6 Sep 2002 10:56:36 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, [e-mail]
Subject: RE: admin dist/gp spec proposal
Date: Fri, 6 Sep 2002 10:56:35 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Natale:
  Sorry, I should have been more precise on whether it was EBGP or IBGP .vs.
IGP or Static. But you get my point, right?

Ben

> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Friday, September 06, 2002 10:54 AM
> To: [e-mail]
> Subject: admin dist/gp spec proposal
> 
> 
> Add sect. in bgp draft stating that ebgp routes should be 
> preferred over any
> igp routes and any igp routes should be preferred over ibgp 
> routes.  The
> exception to this is igp summary routes may be preferred over 
> ebgp routes.
> 
> PS
> RFC1812 needs to be updated and brought to a STANDARD level 
> (it discusses
> admin. Dist. concept, but does not say the obvious-- 
> connected preferred
> over static preferred over dynamic, etc.)  
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA27200 for <[e-mail]>; Fri, 6 Sep 2002 10:55:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5CA06912E8; Fri,  6 Sep 2002 10:55:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 23E13912EA; Fri,  6 Sep 2002 10:55:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B95AE912E8 for <[e-mail]>; Fri,  6 Sep 2002 10:55:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9F2445DE4F; Fri,  6 Sep 2002 10:55:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 2A95E5DE4E for <[e-mail]>; Fri,  6 Sep 2002 10:55:01 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16521; Fri, 6 Sep 2002 10:54:59 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA23794; Fri, 6 Sep 2002 10:55:00 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QN0KX>; Fri, 6 Sep 2002 10:54:59 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "'Mathew Richardson'" <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: RE: Proxy: comments on section 9.1.3
Date: Fri, 6 Sep 2002 10:54:58 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Jeff:
  I did not imply we forbid these non-FIB routes from being added to the
Loc-RIB,
just that we cover this case by saying we still knowingly advertise these
non-FIB
routes to our outbound BGP peers. Anyone with any doubt will know exactly
what we
mean. Perhaps a statement as to the impact on the topological graph in this 
scenario will be helpfull.

Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Friday, September 06, 2002 10:50 AM
> To: 'Mathew Richardson'
> Cc: Abarbanel, Benjamin; [e-mail]
> Subject: Re: Proxy: comments on section 9.1.3
> 
> 
> On Fri, Sep 06, 2002 at 10:41:38AM -0400, 'Mathew Richardson' wrote:
> > And what do either of these have to do with the base BGP spec?
> 
> Adding language that specifically forbidding adding routes to Loc-Rib
> when they wouldn't be added to the FIB would preclude some forms
> of route concentrators.  I don't think we really want to do that.
> 
> > mrr
> 
> -- 
> 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 KAA27159 for <[e-mail]>; Fri, 6 Sep 2002 10:54:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D93FB912EC; Fri,  6 Sep 2002 10:53:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9222B912EA; Fri,  6 Sep 2002 10:53:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 51E27912EE for <[e-mail]>; Fri,  6 Sep 2002 10:53:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 352BA5DE53; Fri,  6 Sep 2002 10:53:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id D8F945DE4F for <[e-mail]>; Fri,  6 Sep 2002 10:53:47 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BVNA>; Fri, 6 Sep 2002 10:53:47 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: admin dist/gp spec proposal
Date: Fri, 6 Sep 2002 10:53:40 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Add sect. in bgp draft stating that ebgp routes should be preferred over any
igp routes and any igp routes should be preferred over ibgp routes.  The
exception to this is igp summary routes may be preferred over ebgp routes.

PS
RFC1812 needs to be updated and brought to a STANDARD level (it discusses
admin. Dist. concept, but does not say the obvious-- connected preferred
over static preferred over dynamic, etc.)  


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA27034 for <[e-mail]>; Fri, 6 Sep 2002 10:50:01 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 43EFB912EB; Fri,  6 Sep 2002 10:49:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B1BF912EC; Fri,  6 Sep 2002 10:49:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 03C66912EB for <[e-mail]>; Fri,  6 Sep 2002 10:49:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E462E5DE4F; Fri,  6 Sep 2002 10:49:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 366A85DDCA for <[e-mail]>; Fri,  6 Sep 2002 10:49:41 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g86EndI28784; Fri, 6 Sep 2002 10:49:39 -0400 (EDT) (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 g86EnaG28777; Fri, 6 Sep 2002 10:49:36 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g86EnaB02008; Fri, 6 Sep 2002 10:49:36 -0400 (EDT)
Date: Fri, 6 Sep 2002 10:49:36 -0400
From: Jeffrey Haas <[e-mail]>
To: "'Mathew Richardson'" <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: Re: Proxy: comments on section 9.1.3
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 Fri, Sep 06, 2002 at 10:41:38AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Sep 06, 2002 at 10:41:38AM -0400, 'Mathew Richardson' wrote:
> And what do either of these have to do with the base BGP spec?

Adding language that specifically forbidding adding routes to Loc-Rib
when they wouldn't be added to the FIB would preclude some forms
of route concentrators.  I don't think we really want to do that.

> mrr

-- 
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 KAA26884 for <[e-mail]>; Fri, 6 Sep 2002 10:46:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 04925912E9; Fri,  6 Sep 2002 10:43:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 953E0912ED; Fri,  6 Sep 2002 10:43:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 484A6912E9 for <[e-mail]>; Fri,  6 Sep 2002 10:43:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2F3F75DE4E; Fri,  6 Sep 2002 10:43:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id AFB755DDCA for <[e-mail]>; Fri,  6 Sep 2002 10:43:28 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA15687; Fri, 6 Sep 2002 10:43:26 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18994; Fri, 6 Sep 2002 10:43:27 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QN849>; Fri, 6 Sep 2002 10:43:26 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Mathew Richardson'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Proxy: comments on section 9.1.3
Date: Fri, 6 Sep 2002 10:43:25 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Mathew:

> -----Original Message-----
> From: 'Mathew Richardson' [mailto:[e-mail]]
> Sent: Friday, September 06, 2002 10:34 AM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: Proxy: comments on section 9.1.3
> 
> 
> > Abarbanel, Benjamin <[e-mail]> [Fri, 
> Sep 06, 2002 at 10:26:59AM -0400]:
> >Mathew:
> >
> > 
> >> >
> >> >I'm looking for clarification to wording in section 9.1.3 
> >> Phase 3: Route
> >> >Dessemination of draft-ietf-idr-bgp4-17.txt.
> >> >
> >> >My understanding is that a BGP route should not be 
> >> advertised to a peer if
> >> >that route is not also in the Routing Table (e.g. FIB).  I 
> >> was looking for
> >> >wording to support this, but am now starting to second 
> guess myself.
> >> >
> >
> >What about the case where the best BGP route for a given 
> destination is
> >rejected/
> >preempted from the routing table by a higher preferenced 
> IGP, Static, etc.,
> >route which is really used for forwarding?
> 
> This route would have to be in the Loc-RIB, and would replace 
> all other
> routes in the Loc-RIB.  Whether this actually happens or not 
> is a matter
> of local-policy.
> 
Agree, the Loc-RIB routes are only BGP ones, therefore this 
route will pass all policy filters and be added. But, ---->

> >Somewhere in section 9.1.x, Do we want to mention the fact 
> that the best 
> >Loc-RIB BGP route for a given destination is still 
> advertised to outgoing 
> >peers via the Adj-RIB-out after it passes the outbound 
> policy filtering,
> >even though it is not really used for forwarding?
> 
> <snip>
> 
> You're talking about the case where a BGP route to some destination D
> has been installed in the Loc-RIB, but no route to 
> destination D has been
> added to the forwarding table?  I'm not sure we want to 
> elaborate on that
> case, except, perhaps, to disallow it.

Wrong, there is an IGP or static route to destination D in the routing
table as the best forwarding route, the BGP route to destination D that is
installed in the Loc-RIB with a different Next Hop router is not used for
forwarding. That is the inconsistency I am talking about.

Ben



> 
> 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 KAA26788 for <[e-mail]>; Fri, 6 Sep 2002 10:43:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C4B00912E4; Fri,  6 Sep 2002 10:41:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95FF7912E3; Fri,  6 Sep 2002 10:41:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 87F15912E0 for <[e-mail]>; Fri,  6 Sep 2002 10:41:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 721AC5DE4E; Fri,  6 Sep 2002 10:41:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id BB5DD5DDCA for <[e-mail]>; Fri,  6 Sep 2002 10:41:43 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g86EffV28465; Fri, 6 Sep 2002 10:41:41 -0400 (EDT) (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 g86EfdG28458; Fri, 6 Sep 2002 10:41:39 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g86Efdh24793; Fri, 6 Sep 2002 10:41:39 -0400 (EDT)
Date: Fri, 6 Sep 2002 10:41:38 -0400
From: "'Mathew Richardson'" <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: Re: Proxy: comments on section 9.1.3
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

> Jeffrey Haas <[e-mail]> [Fri, Sep 06, 2002 at 10:39:52AM -0400]:
>On Fri, Sep 06, 2002 at 10:34:22AM -0400, 'Mathew Richardson' wrote:
>> You're talking about the case where a BGP route to some destination D
>> has been installed in the Loc-RIB, but no route to destination D has been
>> added to the forwarding table?  I'm not sure we want to elaborate on that
>> case, except, perhaps, to disallow it.
>
>Route servers.
>Also, route reflectors do not necessarily need to be in the forwarding
>path of the routes they are reflecting and thus don't necessarily
>need any routes installed in the FIB.

<snip>

And what do either of these have to do with the base BGP spec?

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 KAA26701 for <[e-mail]>; Fri, 6 Sep 2002 10:41:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 05DA6912E1; Fri,  6 Sep 2002 10:40:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2EE6912E3; Fri,  6 Sep 2002 10:40:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D0110912E1 for <[e-mail]>; Fri,  6 Sep 2002 10:39:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B3AFB5DE4E; Fri,  6 Sep 2002 10:39:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 07ED85DDCA for <[e-mail]>; Fri,  6 Sep 2002 10:39:59 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g86EdvH28415; Fri, 6 Sep 2002 10:39:57 -0400 (EDT) (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 g86EdrG28404; Fri, 6 Sep 2002 10:39:53 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g86EdrL01648; Fri, 6 Sep 2002 10:39:53 -0400 (EDT)
Date: Fri, 6 Sep 2002 10:39:52 -0400
From: Jeffrey Haas <[e-mail]>
To: "'Mathew Richardson'" <[e-mail]>
Cc: "Abarbanel, Benjamin" <[e-mail]>, [e-mail]
Subject: Re: Proxy: comments on section 9.1.3
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, Sep 06, 2002 at 10:34:22AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Sep 06, 2002 at 10:34:22AM -0400, 'Mathew Richardson' wrote:
> You're talking about the case where a BGP route to some destination D
> has been installed in the Loc-RIB, but no route to destination D has been
> added to the forwarding table?  I'm not sure we want to elaborate on that
> case, except, perhaps, to disallow it.

Route servers.
Also, route reflectors do not necessarily need to be in the forwarding
path of the routes they are reflecting and thus don't necessarily
need any routes installed in the FIB.

> mrr

-- 
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 KAA26605 for <[e-mail]>; Fri, 6 Sep 2002 10:37:54 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DA67F912DE; Fri,  6 Sep 2002 10:36:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D540912E9; Fri,  6 Sep 2002 10:36:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5AD4F912DE for <[e-mail]>; Fri,  6 Sep 2002 10:36:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4B7AA5DE4E; Fri,  6 Sep 2002 10:36:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 07A2A5DDCA for <[e-mail]>; Fri,  6 Sep 2002 10:36:48 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1BVL1>; Fri, 6 Sep 2002 10:36:47 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: 
Date: Fri, 6 Sep 2002 10:36:45 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

What is the purpose of:

Routes that have the following attributes shall not be aggregated
   unless the corresponding attributes of each route are identical:
   MULTI_EXIT_DISC, NEXT_HOP.

The major vendor has a bug/request to add a knob to do the MULTI_EXIT_DISC
part (CSCds88309).  The only reason for the second part I have heard has to
do with RPF (can't recall details).  But basically I see no reason for doing
either part and I don't think any implementations do either anyway.

I propose that the reason for these limits be added to the text or remove
the text altogether.

Also, is shall not == MUST???


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA26560 for <[e-mail]>; Fri, 6 Sep 2002 10:36:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BC7A0912E7; Fri,  6 Sep 2002 10:34:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7577D912F3; Fri,  6 Sep 2002 10:34:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 31A9D912E7 for <[e-mail]>; Fri,  6 Sep 2002 10:34:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 167815DE4E; Fri,  6 Sep 2002 10:34:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 891E65DDCA for <[e-mail]>; Fri,  6 Sep 2002 10:34:27 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g86EYPS28196; Fri, 6 Sep 2002 10:34:25 -0400 (EDT) (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 g86EYMG28189; Fri, 6 Sep 2002 10:34:22 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g86EYMj24755; Fri, 6 Sep 2002 10:34:22 -0400 (EDT)
Date: Fri, 6 Sep 2002 10:34:22 -0400
From: "'Mathew Richardson'" <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: Proxy: comments on section 9.1.3
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

> Abarbanel, Benjamin <[e-mail]> [Fri, Sep 06, 2002 at 10:26:59AM -0400]:
>Mathew:
>
> 
>> >
>> >I'm looking for clarification to wording in section 9.1.3 
>> Phase 3: Route
>> >Dessemination of draft-ietf-idr-bgp4-17.txt.
>> >
>> >My understanding is that a BGP route should not be 
>> advertised to a peer if
>> >that route is not also in the Routing Table (e.g. FIB).  I 
>> was looking for
>> >wording to support this, but am now starting to second guess myself.
>> >
>
>What about the case where the best BGP route for a given destination is
>rejected/
>preempted from the routing table by a higher preferenced IGP, Static, etc.,
>route which is really used for forwarding?

This route would have to be in the Loc-RIB, and would replace all other
routes in the Loc-RIB.  Whether this actually happens or not is a matter
of local-policy.

>Somewhere in section 9.1.x, Do we want to mention the fact that the best 
>Loc-RIB BGP route for a given destination is still advertised to outgoing 
>peers via the Adj-RIB-out after it passes the outbound policy filtering,
>even though it is not really used for forwarding?

<snip>

You're talking about the case where a BGP route to some destination D
has been installed in the Loc-RIB, but no route to destination D has been
added to the forwarding table?  I'm not sure we want to elaborate on that
case, except, perhaps, to disallow it.

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 KAA26240 for <[e-mail]>; Fri, 6 Sep 2002 10:27:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F00EA91203; Fri,  6 Sep 2002 10:27:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B78C7912D9; Fri,  6 Sep 2002 10:27:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CBCDE91203 for <[e-mail]>; Fri,  6 Sep 2002 10:27:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B2A365DE4E; Fri,  6 Sep 2002 10:27:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 3D5015DDCA for <[e-mail]>; Fri,  6 Sep 2002 10:27:05 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14384; Fri, 6 Sep 2002 10:26:59 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA14975; Fri, 6 Sep 2002 10:27:00 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QN7S3>; Fri, 6 Sep 2002 10:26:59 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Mathew Richardson'" <[e-mail]>, [e-mail]
Subject: RE: Proxy: comments on section 9.1.3
Date: Fri, 6 Sep 2002 10:26:59 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Mathew:

 
> >
> >I'm looking for clarification to wording in section 9.1.3 
> Phase 3: Route
> >Dessemination of draft-ietf-idr-bgp4-17.txt.
> >
> >My understanding is that a BGP route should not be 
> advertised to a peer if
> >that route is not also in the Routing Table (e.g. FIB).  I 
> was looking for
> >wording to support this, but am now starting to second guess myself.
> >

What about the case where the best BGP route for a given destination is
rejected/
preempted from the routing table by a higher preferenced IGP, Static, etc.,
route which is really used for forwarding?

Somewhere in section 9.1.x, Do we want to mention the fact that the best 
Loc-RIB BGP route for a given destination is still advertised to outgoing 
peers via the Adj-RIB-out after it passes the outbound policy filtering,
even though it is not really used for forwarding?

Ben


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 JAA24560 for <[e-mail]>; Fri, 6 Sep 2002 09:43:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 98515912DC; Fri,  6 Sep 2002 09:42:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65912912DB; Fri,  6 Sep 2002 09:42:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0BDA9912D9 for <[e-mail]>; Fri,  6 Sep 2002 09:42:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EAD905DE4D; Fri,  6 Sep 2002 09:42:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 35D9E5DDCA for <[e-mail]>; Fri,  6 Sep 2002 09:42:18 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g86DgHM26447 for [e-mail]; Fri, 6 Sep 2002 09:42:17 -0400 (EDT) (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 g86DgEG26440 for <[e-mail]>; Fri, 6 Sep 2002 09:42:14 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g86DgEI24244 for [e-mail]; Fri, 6 Sep 2002 09:42:14 -0400 (EDT)
Date: Fri, 6 Sep 2002 09:42:14 -0400
From: Mathew Richardson <[e-mail]>
To: [e-mail]
Subject: Re: Proxy: comments on section 9.1.3
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

> Alex Zinin <[e-mail]> [Fri, Sep 06, 2002 at 03:07:40PM +0200]:
>Proxy-fwd below.
>
>--
>Alex
>
>I'm looking for clarification to wording in section 9.1.3 Phase 3: Route
>Dessemination of draft-ietf-idr-bgp4-17.txt.
>
>My understanding is that a BGP route should not be advertised to a peer if
>that route is not also in the Routing Table (e.g. FIB).  I was looking for
>wording to support this, but am now starting to second guess myself.
>
>"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."
>
>This seems clear.  I'm interpreting "configured policy" as routes can be
>filtered prior to being sent (and thus not sent) to a peer.
>
>"A route shall not be installed in the Adj-Rib-Out unless the destination
>and NEXT_HOP described by this route may be forwarded appropriately by the
>Routing Table."
>
>This covers the case when local policy keeps a route in Loc-RIB from being
>placed into the Routing Table and there is no other way for the route to get
>in the Routing Table.  Even though the route is in Loc-RIB, it will not be
>sent to the peer.
>
>What if the route in Loc-RIB would have been placed in the Routing Table,
>except local policy (e.g. lower Administrative Distance) placed an IGP route
>there instead?   

>From section 3.1:

   Routes that will be used by the local BGP speaker must be
   present in the Loc-RIB ...

>From section 9.1.2:

  The local speaker SHALL then install that route in the Loc-RIB,
  replacing any route to the same destination that is currently being
  held in the Loc-RIB. 

So, the Loc-RIB contains only one route per-destination, and routes
that will be used by the local BGP speaker must be present in the
Loc-RIB.

>Durring Phase 3, both the destination and NEXT_HOP
>described by the route in Loc-RIB could be "forwarded appropriately" (but
>perhaps to the wrong place.)   In this case, should the Loc-RIB be placed in
>Adj-RIB-Out?
>
>The text doesn't say that both Loc-RIB and the Routing Table (the route the
>local speaker itself uses) must have the same route.  It reads as if only
>route in Loc-RIB need be considered.  In the description of earlier phases,
>"local policy" is mentioned in the text describing what to do.  In this
>phase, the impact of any "local policy" should be called out.

I agree that this could use some clarification.  How about adding
to b) in section 9.1:

  The Loc-RIB must contain only one route per destination; further, it
  must include all routes that the BGP speaker is using.

changing c) in section 9.1.2 to:

  c) is selected as a result of the Phase 2 tie breaking rules specified
  in 9.1.2.2, or

and adding

  d) when routing protocols other than BGP are in use, is determined by
  some other local means to be the route that will actually be used to
  reach a particular destination.

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 JAA23970 for <[e-mail]>; Fri, 6 Sep 2002 09:24:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9BFE4912D2; Fri,  6 Sep 2002 09:23:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3AEC912D6; Fri,  6 Sep 2002 09:23:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 02C33912D2 for <[e-mail]>; Fri,  6 Sep 2002 09:23:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D648D5DF7A; Fri,  6 Sep 2002 09:23:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 10B725DE4E for <[e-mail]>; Fri,  6 Sep 2002 09:23:26 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g86DNO826031 for [e-mail]; Fri, 6 Sep 2002 09:23:24 -0400 (EDT) (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 g86DNLG26024 for <[e-mail]>; Fri, 6 Sep 2002 09:23:21 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g86DNLQ24099 for [e-mail]; Fri, 6 Sep 2002 09:23:21 -0400 (EDT)
Date: Fri, 6 Sep 2002 09:23:21 -0400
From: Mathew Richardson <[e-mail]>
To: [e-mail]
Subject: Re: Proxy: comments on section 3
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

> Alex Zinin <[e-mail]> [Fri, Sep 06, 2002 at 03:02:40PM +0200]:
>Proxy-fwd'ing a set of comments on the spec.
>Please discuss.
>Alex
>
>
>
>Reading draft-ietf-idr-bgp4-17.txt from a "first time implementer" point of
>view ...
>
>Something at the beginning of Section 3 of  is not clear.  
>
>> The initial data flow is the portion of the BGP routing table that is
>> allowed by the export policy, called the Adj-Ribs-Out (see 3.2).
>> Incremental updates are sent as the routing tables change. BGP does
>> not require periodic refresh of the routing table. Therefore, a BGP
>> speaker __must__ retain the current version of the routes advertised by
>> all of its peers for the duration of the connection. 
>
>Shouldn't "must retain" be "SHOULD retain"?  The text that comes next
>(below) contradicts "must".
> 
>> If the
>> implementation decides to not store the routes that have been
>> received from a peer, but have been filtered out according to
>> configured local policy, the BGP Route Refresh extension [12] may be
>> used to request the full set of routes from a peer without resetting
>> the BGP session when the local policy configuration changes.
>
>Regarding Route Refresh, this is clear.  When I change local policy, I would
>need to trigger a "Route Refresh" (e.g. clear ip bgp).
>
>However, what about if route refresh isn't supported (locally or by the
>remote peer, or both)?

This is why you must retain them.  I, personally, was against adding
the Route Refresh text to the base spec, and would still like to see
it removed.  Given that I'm in the minority on this, how about something
like:

  ... Therefore, a BGP speaker must either retain the current version of
  the routes advertised by all of its peers for the duration of the
  connection, or make use of the Route Refresh extension [12].  This
  is necessary to allow local policy changes to have the correct effect
  without requiring the reset of any peering sessions.

  If the implementation decides not to retain the current version of
  the routes that have been received from a peer, then Route Refresh
  messages should be sent whenever there is a change to local policy.

>I'm aware of the current practice of "soft reset".
>Should it be mentioned?  If not "soft reset" because its IOS specific,
>perhaps text pointing out that the routes retained from a peer should/could
>be used (via manual intervention) when local policy changes.   For
>completness, call out that routes filtered and not retained can never be
>used after local policy changes without a real reset (or route refresh).

Is the above text sufficient?

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 JAA23440 for <[e-mail]>; Fri, 6 Sep 2002 09:09:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 32880912CE; Fri,  6 Sep 2002 09:09:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1FFA912CF; Fri,  6 Sep 2002 09:09:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B383B912CE for <[e-mail]>; Fri,  6 Sep 2002 09:09:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 92C0D5DE4D; Fri,  6 Sep 2002 09:09:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 674AC5DE4A for <[e-mail]>; Fri,  6 Sep 2002 09:09:17 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17nIrM-000DTl-00 for [e-mail]; Fri, 06 Sep 2002 06:09:17 -0700
Date: Fri, 6 Sep 2002 15:07:40 +0200
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: Proxy: comments on section 9.1.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Proxy-fwd below.

--
Alex

I'm looking for clarification to wording in section 9.1.3 Phase 3: Route
Dessemination of draft-ietf-idr-bgp4-17.txt.

My understanding is that a BGP route should not be advertised to a peer if
that route is not also in the Routing Table (e.g. FIB).  I was looking for
wording to support this, but am now starting to second guess myself.

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

This seems clear.  I'm interpreting "configured policy" as routes can be
filtered prior to being sent (and thus not sent) to a peer.

"A route shall not be installed in the Adj-Rib-Out unless the destination
and NEXT_HOP described by this route may be forwarded appropriately by the
Routing Table."

This covers the case when local policy keeps a route in Loc-RIB from being
placed into the Routing Table and there is no other way for the route to get
in the Routing Table.  Even though the route is in Loc-RIB, it will not be
sent to the peer.

What if the route in Loc-RIB would have been placed in the Routing Table,
except local policy (e.g. lower Administrative Distance) placed an IGP route
there instead?   Durring Phase 3, both the destination and NEXT_HOP
described by the route in Loc-RIB could be "forwarded appropriately" (but
perhaps to the wrong place.)   In this case, should the Loc-RIB be placed in
Adj-RIB-Out?

The text doesn't say that both Loc-RIB and the Routing Table (the route the
local speaker itself uses) must have the same route.  It reads as if only
route in Loc-RIB need be considered.  In the description of earlier phases,
"local policy" is mentioned in the text describing what to do.  In this
phase, the impact of any "local policy" should be called out.




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA23290 for <[e-mail]>; Fri, 6 Sep 2002 09:04:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CECC6912CD; Fri,  6 Sep 2002 09:04:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96211912CE; Fri,  6 Sep 2002 09:04:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7469E912CD for <[e-mail]>; Fri,  6 Sep 2002 09:04:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E95295DE4D; Fri,  6 Sep 2002 09:04:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id BEC745DE38 for <[e-mail]>; Fri,  6 Sep 2002 09:04:17 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17nImX-000DE6-00 for [e-mail]; Fri, 06 Sep 2002 06:04:17 -0700
Date: Fri, 6 Sep 2002 15:02:40 +0200
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: Proxy: comments on section 3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Proxy-fwd'ing a set of comments on the spec.
Please discuss.
Alex



Reading draft-ietf-idr-bgp4-17.txt from a "first time implementer" point of
view ...

Something at the beginning of Section 3 of  is not clear.  

> The initial data flow is the portion of the BGP routing table that is
> allowed by the export policy, called the Adj-Ribs-Out (see 3.2).
> Incremental updates are sent as the routing tables change. BGP does
> not require periodic refresh of the routing table. Therefore, a BGP
> speaker __must__ retain the current version of the routes advertised by
> all of its peers for the duration of the connection. 

Shouldn't "must retain" be "SHOULD retain"?  The text that comes next
(below) contradicts "must".
 
> If the
> implementation decides to not store the routes that have been
> received from a peer, but have been filtered out according to
> configured local policy, the BGP Route Refresh extension [12] may be
> used to request the full set of routes from a peer without resetting
> the BGP session when the local policy configuration changes.

Regarding Route Refresh, this is clear.  When I change local policy, I would
need to trigger a "Route Refresh" (e.g. clear ip bgp).

However, what about if route refresh isn't supported (locally or by the
remote peer, or both)?  I'm aware of the current practice of "soft reset".
Should it be mentioned?  If not "soft reset" because its IOS specific,
perhaps text pointing out that the routes retained from a peer should/could
be used (via manual intervention) when local policy changes.   For
completness, call out that routes filtered and not retained can never be
used after local policy changes without a real reset (or route refresh).




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA23083 for <[e-mail]>; Fri, 6 Sep 2002 08:59:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D748A912CC; Fri,  6 Sep 2002 08:59:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A253A912CD; Fri,  6 Sep 2002 08:59:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7218E912CC for <[e-mail]>; Fri,  6 Sep 2002 08:59:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 57C765DE4A; Fri,  6 Sep 2002 08:59:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 2F77D5DDCA for <[e-mail]>; Fri,  6 Sep 2002 08:59:07 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17nIhW-000CwZ-00; Fri, 06 Sep 2002 05:59:06 -0700
Date: Fri, 6 Sep 2002 14:57:29 +0200
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP spec and IDR WG charter
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Yakov,

> Did you get from these folks timeline for when they'll be able to
> finish the review ?

Yes. Some of them promised to start the review within several
days and I'm already receiving some comments I'm going to proxy-fwd
to the list for consideration. There was also a request to extend
the review period to 4 weeks, as some folks are in deadlines.

Alex




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA01745 for <[e-mail]>; Thu, 5 Sep 2002 09:42:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EFB5C9123C; Thu,  5 Sep 2002 09:41:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B983D91294; Thu,  5 Sep 2002 09:41:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BD7F69123C for <[e-mail]>; Thu,  5 Sep 2002 09:41:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9F51F5DF34; Thu,  5 Sep 2002 09:41:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 2C3ED5DE0D for <[e-mail]>; Thu,  5 Sep 2002 09:41:30 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA16749; Thu, 5 Sep 2002 09:41:27 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06942; Thu, 5 Sep 2002 09:41:27 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QMHND>; Thu, 5 Sep 2002 09:41:26 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Alex Zinin'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Russ White'" <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail], [e-mail]
Subject: RE: IDR WG charter
Date: Thu, 5 Sep 2002 09:41:23 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Alex:
  Fair enough.

Ben

> -----Original Message-----
> From: Alex Zinin [mailto:[e-mail]]
> Sent: Wednesday, September 04, 2002 7:16 PM
> To: Abarbanel, Benjamin
> Cc: 'Russ White'; Yakov Rekhter; [e-mail]; [e-mail]
> Subject: Re: IDR WG charter
> 
> 
> Ben-
> 
> > I agree, the protocol should be made stable and accurate 
> according to
> > the majority of its users, ASAP. That should have no 
> significant impact
> > on any new ideas that may or may not be dependent on the 
> existing protocol
> > description. My guess is most of the time these ideas do not require
> > the base protocol to change for them to be feasable.
> 
> I don't want us to keep arguing here, I guess we just disagree.
> I believe that for two parties to come up with the same result
> of (A + b), it is not enough to define b, the exact value of A
> has to be known as well.
> 
> Alex
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA29965 for <[e-mail]>; Thu, 5 Sep 2002 09:02:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 53D8391293; Thu,  5 Sep 2002 09:01:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D5C691294; Thu,  5 Sep 2002 09:01:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B251591293 for <[e-mail]>; Thu,  5 Sep 2002 09:01:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 977275DE0B; Thu,  5 Sep 2002 09:01:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 0C6B55DDC2 for <[e-mail]>; Thu,  5 Sep 2002 09:01:45 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g85D1im15577; Thu, 5 Sep 2002 06:01:44 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Bill Fenner <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP spec and IDR WG charter 
In-Reply-To: Your message of "Thu, 22 Aug 2002 16:11:10 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 05 Sep 2002 06:01:43 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Bill,

Few questions on the charter proposed by you and Alex:

1. Any reason the charter doesn't include BGP Graceful Restart ?

2. Any reason the charter doesn't mention draft-ietf-idr-md5-keys-00.txt ?
   (The WG sent it to the IESG beginning of June 2002)

3. The WG completed the work on the extended communities and submitted 
   the draft to the IESG 3 weeks before you informed the WG
   about the Routing Area Directors' decision not to forward any 
   IDR documents for IESG considerations until the base BGP spec update 
   is finished. With this in mind we need to change

     MAR 03  Submit Extended Communities draft to IESG.

   to

     DONE Submit Extended Communities draft to IESG.

Yakov.

> Dear IDR WG,
> 
>   After some consideration, the Routing Area Directors have decided
> not to forward any IDR documents for IESG consideration until the
> base BGP spec update is finished.[*]  Despite the best efforts of all
> involved, the spec update has been taking an incredible amount of
> time.  We take this step in order to focus all possible resources
> of the WG community on the BGP spec update.
> 
>   This may seem like a negative action.  On the contrary, it is
> meant to support the accomplishment of the working group's goals.[**]
> The milestone for the submission of the BGP4 draft to the IESG
> was scheduled for January 2002.
> 
>   Attached is a proposed update for the IDR working group charter.
> Note that we just made up the dates in the goals and milestones,
> and the WG should come up with realistic ones.
> 
>   Bill and Alex
> 
> [*] "finished" means, in this case, WG consensus, WG Last Call,
> AD Review, IETF Last Call, and IESG approval for publication.
> 
> [**] In further support of the goal of having a quality specification
> that reflects current reality, the ADs have been working on assembling
> a team of reviewers that consists primarily of protocol implementors,
> who have committed their time to examine the spec.  We will be
> sending another message to this list explaining the details of how
> this team will do its work.
> 
> - - -
> 
> The Inter-Domain Routing Working Group is chartered to standardize
> and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
> 1771] capable of supporting policy based routing for TCP/IP internets.
> The objective is to promote the use of BGP-4 to support IP version
> 4 and IP version 6. The working group will continue to work on
> improving the scalability of BGP.
> 
> The current tasks of the WG are limited to:
> 
> - Revise and clarify the base BGP4 document (RFC 1771). Note that
> RFC 1771 no longer documents existing practice and one goal of the
> update is document existing practice. Determine whether the document
> can be advanced as full Standard or needs to recycle at Proposed
> or Draft Standard.
> 
> - Submit updated MIBs to accompany the revised base BGP4 document.
> 
> Once these tasks are completed, work will progress on the following:
> 
> - Review and Evaluate Existing RFCs on AS Confederations and Route
> Reflection. If changes are needed, create and advance revisions.
> 
> - Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
> if any changes need to be made based on current Internet practice
> or based on the changes to the current bgp draft. If changes are
> needed, create an revision. Issue the WG Last Call on advancing
> the document to Draft Standard.
> 
> - Produce an updated MIB for AS Confederations, Route Reflection,
> Communities, Multi-Protocol BGP, etc..
> 
> - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
> as Draft Standard.
> 
> - Complete work on an Extended Community Attribute. Develop MIB
> for BGP Extended Communities.
> 
> - Extend BGP to support a 4-byte AS number, develop plan for
> transitioning to usage of 4-byte AS numbers
> 
> - Progress along the IETF standards track 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. Currently defined in
> draft-ietf-idr-route-filter-03.txt.
> 
> - Progress along standards track an Outbound Router Filter (ORF)
> type for BGP, that can be used to perform aspath based route
> filtering. The ORF-type will support aspath based route filtering
> as well as regular expression based matching for address groups.
> Currently defined in draft-ietf-idr-aspath-orf-00.txt.
> 
> Tasks for this working group are limited to those listed above;
> new items to be added to the charter must be approved by the IESG.
> 
> Goals and Milestones
> 
> DONE    Submit BGP Capability Advertisement to the IESG
> NOV 02  Submit BGP4 document to IESG.
> DEC 02  Submit updated base BGP4 MIB to IESG.
> MAR 03  Submit extensible BGP MIB to IESG.
> MAR 03  Submit Extended Communities draft to IESG.
> MAR 03  Submit 4-byte AS ID to IESG.
> MAR 03  Initial Draft for RFC2858 (if needed)
> MAR 03  BGP TCP MD5 signatures document to IESG.
> MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA29420 for <[e-mail]>; Thu, 5 Sep 2002 08:45:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CFB1891237; Thu,  5 Sep 2002 08:44:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9178C91293; Thu,  5 Sep 2002 08:44:48 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4AD5691237 for <[e-mail]>; Thu,  5 Sep 2002 08:44:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2E94F5DE0B; Thu,  5 Sep 2002 08:44:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id C7B0A5DDC2 for <[e-mail]>; Thu,  5 Sep 2002 08:44:45 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g85Ciim14561; Thu, 5 Sep 2002 05:44:44 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: [e-mail]
Subject: Re: BGP spec and IDR WG charter 
In-Reply-To: Your message of "Thu, 05 Sep 2002 00:40:23 +0200." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 05 Sep 2002 05:44:44 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Alex,

> Folks-
> 
> Regarding the review team mentioned below--
> 
> Friday, August 23, 2002, 1:11:10 AM, Bill Fenner wrote:
> ...
> > [**] In further support of the goal of having a quality specification
> > that reflects current reality, the ADs have been working on assembling
> > a team of reviewers that consists primarily of protocol implementors,
> > who have committed their time to examine the spec.  We will be
> > sending another message to this list explaining the details of how
> > this team will do its work.
> 
> --today I have pinged about a dozen people who promised to commit
> some time to review the spec, and asked them to help with the FSM
> text review posted by Sue. Hopefully we will see more activity
> on the list in the following two weeks and later when the complete
> spec goes for the LC.

Did you get from these folks timeline for when they'll be able to
finish the review ?

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 TAA29821 for <[e-mail]>; Wed, 4 Sep 2002 19:18:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DAF0B9128A; Wed,  4 Sep 2002 19:18:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 200F19127B; Wed,  4 Sep 2002 19:18:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 23F239128A for <[e-mail]>; Wed,  4 Sep 2002 19:18:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F00A85DF23; Wed,  4 Sep 2002 19:17:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id C4A365DF0D for <[e-mail]>; Wed,  4 Sep 2002 19:17:59 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17mjPC-0006Qu-00; Wed, 04 Sep 2002 16:17:51 -0700
Date: Thu, 5 Sep 2002 01:16:03 +0200
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Russ White'" <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail], <[e-mail]>
Subject: Re: IDR WG charter
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Ben-

> I agree, the protocol should be made stable and accurate according to
> the majority of its users, ASAP. That should have no significant impact
> on any new ideas that may or may not be dependent on the existing protocol
> description. My guess is most of the time these ideas do not require
> the base protocol to change for them to be feasable.

I don't want us to keep arguing here, I guess we just disagree.
I believe that for two parties to come up with the same result
of (A + b), it is not enough to define b, the exact value of A
has to be known as well.

Alex




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA28564 for <[e-mail]>; Wed, 4 Sep 2002 18:42:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9A5F59128E; Wed,  4 Sep 2002 18:42:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BFB39128F; Wed,  4 Sep 2002 18:42:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2B4A59128E for <[e-mail]>; Wed,  4 Sep 2002 18:42:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F0F8C5DF0D; Wed,  4 Sep 2002 18:42:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id C8B9A5DD8E for <[e-mail]>; Wed,  4 Sep 2002 18:42:07 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17miqc-0004rE-00 for [e-mail]; Wed, 04 Sep 2002 15:42:06 -0700
Date: Thu, 5 Sep 2002 00:40:23 +0200
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: [e-mail]
Subject: Re: BGP spec and IDR WG charter
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Folks-

Regarding the review team mentioned below--

Friday, August 23, 2002, 1:11:10 AM, Bill Fenner wrote:
...
> [**] In further support of the goal of having a quality specification
> that reflects current reality, the ADs have been working on assembling
> a team of reviewers that consists primarily of protocol implementors,
> who have committed their time to examine the spec.  We will be
> sending another message to this list explaining the details of how
> this team will do its work.

--today I have pinged about a dozen people who promised to commit
some time to review the spec, and asked them to help with the FSM
text review posted by Sue. Hopefully we will see more activity
on the list in the following two weeks and later when the complete
spec goes for the LC.

For people who have not been explicitly pinged and who feel capable of
contributing to the protocol specification--please consider this
message as the invitation from the ADs to review the spec and provide
your comments. Please send your comments to the list, or (if you do
not feel comfortable speaking up on the list for some reason), send
them to the chairs and/or the ADs instead, we'll be able to function
as proxy if valid issues are raised.

A small request to the reviewers--when looking at the spec, please
evaluate it from the perspective of being sufficient to implement the
protocol if the reader is not familiar with the protocol, whether it
really reflects what your code is doing or what you know other
implementations do, whether one would need to reverse engineer things
to write an implementation, etc.

Cheers,
Alex




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA16518 for <[e-mail]>; Wed, 4 Sep 2002 12:50:30 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A033191275; Wed,  4 Sep 2002 12:49:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65C2C91277; Wed,  4 Sep 2002 12:49:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 57ADC91275 for <[e-mail]>; Wed,  4 Sep 2002 12:49:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 40E915DDCB; Wed,  4 Sep 2002 12:49:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id B68AA5DDB8 for <[e-mail]>; Wed,  4 Sep 2002 12:49:49 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g84Gngq53715; Wed, 4 Sep 2002 12:49:42 -0400 (EDT) (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 g84GndG53708; Wed, 4 Sep 2002 12:49:39 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g84Gndl04437; Wed, 4 Sep 2002 12:49:39 -0400 (EDT)
Date: Wed, 4 Sep 2002 12:49:39 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: IDR WG charter
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 Wed, Sep 04, 2002 at 11:46:59AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 04, 2002 at 11:46:59AM -0400, Abarbanel, Benjamin wrote:
>   I see no discussion on this list of the work to complete the base spec
> other than
> the review and update of Sue's FSM spec.

Sounds like a problem, eh?

Have you done a line by line review of the spec to make sure that it
lines up with what you perceive to be reality?

Have you compared how the features are actually implemented by various
vendors in your testbed?  Your own product?  Products you use?

Have you read the draft to determine if each section is clear and
understandable?

Anyone who is contributing to this list on a regular basis should have
the skills to do the above.  Its our dog food - we should be sure
we're ready to eat it.  The Internet will for some time after we say
we're done with it.

As for the FSM, there have been some random comments about word consistancy,
but thats all I've seen.  FSM's are tricky to write, especially with
the large number of states and events present in them.  Do the review
of the FSM yourself.  Encourage others to do so with you.  Even if
you don't agree 100% with the need for a FSM, make sure the document
that is produced is sane and complete.

> So unless, all this effort is done
> in a
> private list or behind the scenes, I dont see how it is detracted by new
> work topics
> discussed here?

Because there seems to be this implicit assumption, not necessarily by
you, that there is this secret cabal that will review the spec and
bless it.

Guess what folks - you are the secret cabal.  
Get cracking. :-)

> Ben

-- 
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 LAA14494 for <[e-mail]>; Wed, 4 Sep 2002 11:48:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2419F91276; Wed,  4 Sep 2002 11:48:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F301A91277; Wed,  4 Sep 2002 11:48:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 182FC91276 for <[e-mail]>; Wed,  4 Sep 2002 11:47:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E94325DDC6; Wed,  4 Sep 2002 11:47:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: from roam.psg.com (h116.p072.iij4u.or.jp [210.130.72.116]) by segue.merit.edu (Postfix) with ESMTP id 1F3EC5DDB8 for <[e-mail]>; Wed,  4 Sep 2002 11:47:34 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17mcNN-0005le-00 for [e-mail]; Wed, 04 Sep 2002 08:47:29 -0700
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: [e-mail]
Subject: RE: IDR WG charter
References: <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 04 Sep 2002 08:47:29 -0700
Sender: [e-mail]
Precedence: bulk

Benjamin Abarbanel <[e-mail]>
> Maybe we are making too much out of this thing. I dont know why
> we have to vote on this.

this is the ietf's voting group.  don't you know the famous quote
from dave clark, "we vote instead of completing work, it's easier?"
sorry.  but i get frustrated when a wg spends more time at layer
nine than at chartered work.  and i had a bad day.  but i feel
better now.  :-)

how goes the bgp draft?  especially, how goes the fsm?  the ads
have offerend to go find fresh 'outside' doc reviewers to help
get this stuff done.  as iesg load has increased expectations of
high quality when you ship this stuff to the ads, i would take
them up on the offer.

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 LAA14486 for <[e-mail]>; Wed, 4 Sep 2002 11:48:30 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1AF2F9125C; Wed,  4 Sep 2002 11:47:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D97C191275; Wed,  4 Sep 2002 11:47:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE7229125C for <[e-mail]>; Wed,  4 Sep 2002 11:47:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A6B835DDC6; Wed,  4 Sep 2002 11:47:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 243BA5DDB8 for <[e-mail]>; Wed,  4 Sep 2002 11:47:02 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA03252; Wed, 4 Sep 2002 11:46:59 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA20499; Wed, 4 Sep 2002 11:47:00 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QLDVK>; Wed, 4 Sep 2002 11:46:59 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: IDR WG charter
Date: Wed, 4 Sep 2002 11:46:59 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Jeff:
  I see no discussion on this list of the work to complete the base spec
other than
the review and update of Sue's FSM spec. So unless, all this effort is done
in a
private list or behind the scenes, I dont see how it is detracted by new
work topics
discussed here?

Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Wednesday, September 04, 2002 9:56 AM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: IDR WG charter
> 
> 
> Ben,
> 
> On Tue, Sep 03, 2002 at 01:39:52PM -0400, Abarbanel, Benjamin wrote:
> > At the rate things get done it will be 1-2 years before the 
> old work is
> > completed
> > (makes it to RFC status), where does that put us with new 
> fresh ideas?
> 
> It shouldn't take that long.  The amount of effort the working group
> has expended on debating new drafts would probably have pushed us
> to a final draft on bgp if we had used the same effort.
> 
> > Ben
> 
> -- 
> 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 LAA13831 for <[e-mail]>; Wed, 4 Sep 2002 11:27:21 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6809091288; Wed,  4 Sep 2002 11:26:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39A4D91289; Wed,  4 Sep 2002 11:26:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1F83091288 for <[e-mail]>; Wed,  4 Sep 2002 11:26:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 00A115DD90; Wed,  4 Sep 2002 11:26:51 -0400 (EDT)
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 7178A5DDC9 for <[e-mail]>; Wed,  4 Sep 2002 11:26:51 -0400 (EDT)
Received: from mira-sjcm-3.cisco.com (IDENT:[e-mail] [171.69.24.15]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g84FQnW4015581; Wed, 4 Sep 2002 08:26:49 -0700 (PDT)
Received: from cisco.com (ams-rraszuk2-vpn5.cisco.com [10.61.160.14]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AGB35795; Wed, 4 Sep 2002 08:26:52 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 04 Sep 2002 17:26:44 +0200
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: "Abarbanel, Benjamin" <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail], [e-mail]
Subject: Re: IDR WG charter
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Ben,

Search for "Message-Id:
<[e-mail]>" in:
ftp://ftp.merit.edu/mail.archives/idr/idr.102.08

R.

> "Abarbanel, Benjamin" wrote:
> 
> R:
> 
> I no longer have a copy of that message, could you please quote it in
> another
> message?
> 
> Thanks,
> Ben
> 
> > -----Original Message-----
> > From: Robert Raszuk [mailto:[e-mail]]
> > Sent: Wednesday, September 04, 2002 10:55 AM
> > To: Yakov Rekhter
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: IDR WG charter
> >
> > Reject new IDR WG charter proposal.
> >
> > As a motivation I could only quote recent Pedro's mail listing very
> > valid points on Wed, 21 Aug 2002 in the mail to this list.
> >
> > R.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA13556 for <[e-mail]>; Wed, 4 Sep 2002 11:18:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8C6C491287; Wed,  4 Sep 2002 11:18:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F07CE91288; Wed,  4 Sep 2002 11:18:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2357E91287 for <[e-mail]>; Wed,  4 Sep 2002 11:17:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E3FB55DDB5; Wed,  4 Sep 2002 11:17:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 687065DD90 for <[e-mail]>; Wed,  4 Sep 2002 11:17:53 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA00856; Wed, 4 Sep 2002 11:17:48 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA13452; Wed, 4 Sep 2002 11:17:49 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QLB07>; Wed, 4 Sep 2002 11:17:47 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Alex Zinin'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, Bill Fenner <[e-mail]>, [e-mail], [e-mail]
Subject: RE: IDR WG charter
Date: Wed, 4 Sep 2002 11:17:46 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Alex:

> 
> I think you're misinterpreting. Please read on.
> 
> >  Not advancement to RFC status. E.G. INFORM spec.
> > That is what the issue at hand is.
> 
>  There's two pieces here:
>  
>   1) Sorting out the existing work load. Here we would like to see the
>      base spec finished by the WG and approved by the IESG (i.e., all
>      review cycles completed) before other items are progressed.
> 
>   2) Taking on new work. This is more long term. Here, acceptance
>      of an ID as a WG item requires a related work item in 
> the charter.
>      If no such item exists, the charter needs to be updated. This
>      normally triggers negotiation with the ADs and the IESG 
> and review
>      of the WG progress. Given point 1) above, a work item 
> would really
>      have to be urgent and of high priority for us to be able 
> to explain
>      why we're adding more stuff when we're not yet finished with the
>      main objective. [*]
>
Maybe we are making too much out of this thing. I dont know why we have 
to vote on this. Its clearly an ADs right to decide this. 
 
Ben
 
  


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA13218 for <[e-mail]>; Wed, 4 Sep 2002 11:09:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2D9D191286; Wed,  4 Sep 2002 11:08:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0670791287; Wed,  4 Sep 2002 11:08:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9980F91286 for <[e-mail]>; Wed,  4 Sep 2002 11:08:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7BCE25DDB5; Wed,  4 Sep 2002 11:08:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 3E9855DD90 for <[e-mail]>; Wed,  4 Sep 2002 11:08:22 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17mbkF-0008iS-00; Wed, 04 Sep 2002 08:07:03 -0700
Date: Wed, 4 Sep 2002 17:05:08 +0200
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, Bill Fenner <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: IDR WG charter
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Ben, Andrew

Wednesday, September 04, 2002, 4:39:53 PM, Abarbanel, Benjamin wrote:
> Andrew:
>  According to my understanding the ADs are proposing rejecting any new
> drafts that have significance acceptance by list members from becoming
> a working group item.

I think you're misinterpreting. Please read on.

>  Not advancement to RFC status. E.G. INFORM spec.
> That is what the issue at hand is.

 There's two pieces here:
 
  1) Sorting out the existing work load. Here we would like to see the
     base spec finished by the WG and approved by the IESG (i.e., all
     review cycles completed) before other items are progressed.

  2) Taking on new work. This is more long term. Here, acceptance
     of an ID as a WG item requires a related work item in the charter.
     If no such item exists, the charter needs to be updated. This
     normally triggers negotiation with the ADs and the IESG and review
     of the WG progress. Given point 1) above, a work item would really
     have to be urgent and of high priority for us to be able to explain
     why we're adding more stuff when we're not yet finished with the
     main objective. [*]

 So, I think Andrew is closer to the truth in his assessment.
     
-- 
Alex

[*] I often have to explain people what "it is outside of the charter"
    means. The first thing you should do when you hear this is think
    or ask whether the charter can be extended. If they answer is no,
    then it generally does not mean that you're not welcome to the WG
    with this topic (in fact, the IESG will most probably force a doc
    to go to a proto-specific WG to avoid an end-run), but it is just
    not yet time for the WG to spend cycles on this. Now, it does not
    mean that you should go away and do something proprietary or drop
    the idea. My suggestion is despite the fact that it is not yet time
    in the WG, still follow the IETF process--talk to the WG chairs and
    active folks about who would be interested in the topic, work towards
    the consensus and work on the document, so that when the WG is
    ready to take on this work, part of the way is gone already.


>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Tuesday, September 03, 2002 9:12 PM
>> To: Bill Fenner
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: IDR WG charter
>> 
>> 
>> Bill,
>> 
>> Forgive me if I'm being dense, but for my clarification:  The proposed
>> changes to the charter do not put a stop on all new work, or even
>> new work items being adopted by the wg.  The new charter instead:
>> 
>>  - Prohibits advancement of a wg work item to RFC status before
>>    the base spec is advanced to at least Draft Standard.
>>  - Has the requirement that new wg items must have a spot on the
>>    agenda, and must be approved by the routing area AD's.
>> 
>> So new internet drafts could be adopted as wg items, with wg consensus
>> and AD approval, but could not advance to RFC status before the base
>> bgp spec.
>> 
>> That would make sense to me, especially for standards-track 
>> extentions,
>> since extentions require a stable, well-defined base to extend.
>> 
>> Andrew
>> 
>> On Tue, Sep 03, 2002 at 05:34:21PM -0700, Bill Fenner wrote:
>> > Delivered-To: [e-mail]
>> > Delivered-To: [e-mail]
>> > Delivered-To: [e-mail]
>> > From: Bill Fenner <[e-mail]>
>> > To: [e-mail]
>> > Subject: RE: IDR WG charter
>> > Cc: [e-mail]
>> > Date: Tue, 3 Sep 2002 17:34:21 -0700
>> > Versions: dmail (solaris) 2.5a/makemail 2.9d
>> > Precedence: bulk
>> > X-OriginalArrivalTime: 04 Sep 2002 00:36:26.0062 (UTC) 
>> FILETIME=[1A0196E0:01C253AB]
>> > 
>> > 
>> > > In those terms, I'd reject until we can understand better about
>> > > what we are trying to do with the charter, and how to handle it.
>> > 
>> > The current charter, with the specific tasks listed and the 
>> statement
>> > that no other work can be taken on without a charter 
>> update, was agreed
>> > upon between the WG and the previous ADs.  I suppose the discussion
>> > thinking that this stuff is new shows how much attention most people
>> > normally pay to the charter?...
>> > 
>> >   Bill
>> 




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA13091 for <[e-mail]>; Wed, 4 Sep 2002 11:04:58 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D73B991285; Wed,  4 Sep 2002 11:00:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5244E91284; Wed,  4 Sep 2002 11:00:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F22591285 for <[e-mail]>; Wed,  4 Sep 2002 11:00:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5ED6D5DEF9; Wed,  4 Sep 2002 11:00:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id DC85A5DD90 for <[e-mail]>; Wed,  4 Sep 2002 10:59:59 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA29315; Wed, 4 Sep 2002 10:59:57 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA08755; Wed, 4 Sep 2002 10:59:58 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QLAZM>; Wed, 4 Sep 2002 10:59:57 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Yakov Rekhter <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: IDR WG charter
Date: Wed, 4 Sep 2002 10:59:55 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

R:

I no longer have a copy of that message, could you please quote it in
another
message?

Thanks,
Ben

> -----Original Message-----
> From: Robert Raszuk [mailto:[e-mail]]
> Sent: Wednesday, September 04, 2002 10:55 AM
> To: Yakov Rekhter
> Cc: [e-mail]; [e-mail]
> Subject: Re: IDR WG charter
> 
> 
> 
> Reject new IDR WG charter proposal.
> 
> As a motivation I could only quote recent Pedro's mail listing very
> valid points on Wed, 21 Aug 2002 in the mail to this list.
> 
> R.
> 
> > Yakov Rekhter wrote:
> > 
> > Folks,
> > 
> > So far we received just two e-mail on the subject of the IDR WG
> > charter proposed by Bill and Alex. The WG chairs would like to get
> > opinion of the WG members on whether the WG should accept the new
> > charter, or stay with the existing one.  With this in mind, please
> > send me an e-mail with either "accept" (means accept the new
> > charter), or "reject" (means stay with the existing charter). The
> > deadline is Sep 17.
> > 
> > Sue & Yakov.
> > ------- Forwarded Message
> > 
> > Date:    Mon, 26 Aug 2002 07:18:00 -0700
> > From:    Yakov Rekhter <[e-mail]>
> > To:      [e-mail]
> > cc:      [e-mail]
> > Subject: IDR WG charter
> > 
> > Folks,
> > 
> > Please comment on the revised charter proposed by Bill and Alex
> > (see below). The deadline for comments is Sep 10, 2002.
> > 
> > Sue & Yakov
> > - ------- Forwarded Message
> > 
> > Date:    Thu, 22 Aug 2002 16:11:10 -0700
> > From:    Bill Fenner <[e-mail]>
> > To:      [e-mail]
> > Subject: BGP spec and IDR WG charter
> > 
> > Dear IDR WG,
> > 
> >   After some consideration, the Routing Area Directors have decided
> > not to forward any IDR documents for IESG consideration until the
> > base BGP spec update is finished.[*]  Despite the best 
> efforts of all
> > involved, the spec update has been taking an incredible amount of
> > time.  We take this step in order to focus all possible resources
> > of the WG community on the BGP spec update.
> > 
> >   This may seem like a negative action.  On the contrary, it is
> > meant to support the accomplishment of the working group's 
> goals.[**]
> > The milestone for the submission of the BGP4 draft to the IESG
> > was scheduled for January 2002.
> > 
> >   Attached is a proposed update for the IDR working group charter.
> > Note that we just made up the dates in the goals and milestones,
> > and the WG should come up with realistic ones.
> > 
> >   Bill and Alex
> > 
> > [*] "finished" means, in this case, WG consensus, WG Last Call,
> > AD Review, IETF Last Call, and IESG approval for publication.
> > 
> > [**] In further support of the goal of having a quality 
> specification
> > that reflects current reality, the ADs have been working on 
> assembling
> > a team of reviewers that consists primarily of protocol 
> implementors,
> > who have committed their time to examine the spec.  We will be
> > sending another message to this list explaining the details of how
> > this team will do its work.
> > 
> > - - - - -
> > 
> > The Inter-Domain Routing Working Group is chartered to standardize
> > and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
> > 1771] capable of supporting policy based routing for TCP/IP 
> internets.
> > The objective is to promote the use of BGP-4 to support IP version
> > 4 and IP version 6. The working group will continue to work on
> > improving the scalability of BGP.
> > 
> > The current tasks of the WG are limited to:
> > 
> > - - - Revise and clarify the base BGP4 document (RFC 1771). 
> Note that
> > RFC 1771 no longer documents existing practice and one goal of the
> > update is document existing practice. Determine whether the document
> > can be advanced as full Standard or needs to recycle at Proposed
> > or Draft Standard.
> > 
> > - - - Submit updated MIBs to accompany the revised base 
> BGP4 document.
> > 
> > Once these tasks are completed, work will progress on the following:
> > 
> > - - - Review and Evaluate Existing RFCs on AS 
> Confederations and Route
> > Reflection. If changes are needed, create and advance revisions.
> > 
> > - - - Review RFC 2385 (Protection of BGP via TCP MD5 
> signature) to see
> > if any changes need to be made based on current Internet practice
> > or based on the changes to the current bgp draft. If changes are
> > needed, create an revision. Issue the WG Last Call on advancing
> > the document to Draft Standard.
> > 
> > - - - Produce an updated MIB for AS Confederations, Route 
> Reflection,
> > Communities, Multi-Protocol BGP, etc..
> > 
> > - - - Review and evaluate Multiprotocol BGP (RFC 2858) for 
> advancement
> > as Draft Standard.
> > 
> > - - - Complete work on an Extended Community Attribute. Develop MIB
> > for BGP Extended Communities.
> > 
> > - - - Extend BGP to support a 4-byte AS number, develop plan for
> > transitioning to usage of 4-byte AS numbers
> > 
> > - - - Progress along the IETF standards track 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. Currently defined in
> > draft-ietf-idr-route-filter-03.txt.
> > 
> > - - - Progress along standards track an Outbound Router Filter (ORF)
> > type for BGP, that can be used to perform aspath based route
> > filtering. The ORF-type will support aspath based route filtering
> > as well as regular expression based matching for address groups.
> > Currently defined in draft-ietf-idr-aspath-orf-00.txt.
> > 
> > Tasks for this working group are limited to those listed above;
> > new items to be added to the charter must be approved by the IESG.
> > 
> > Goals and Milestones
> > 
> > DONE    Submit BGP Capability Advertisement to the IESG
> > NOV 02  Submit BGP4 document to IESG.
> > DEC 02  Submit updated base BGP4 MIB to IESG.
> > MAR 03  Submit extensible BGP MIB to IESG.
> > MAR 03  Submit Extended Communities draft to IESG.
> > MAR 03  Submit 4-byte AS ID to IESG.
> > MAR 03  Initial Draft for RFC2858 (if needed)
> > MAR 03  BGP TCP MD5 signatures document to IESG.
> > MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.
> > 
> > - ------- End of Forwarded Message
> > 
> > ------- End of Forwarded Message
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA12740 for <[e-mail]>; Wed, 4 Sep 2002 10:55:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1CB3791282; Wed,  4 Sep 2002 10:55:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE5C491283; Wed,  4 Sep 2002 10:55:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9DF3E91282 for <[e-mail]>; Wed,  4 Sep 2002 10:55:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 875015DDB8; Wed,  4 Sep 2002 10:55:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id EC1015DD90 for <[e-mail]>; Wed,  4 Sep 2002 10:55:26 -0400 (EDT)
Received: from mira-sjcm-3.cisco.com (IDENT:[e-mail] [171.69.24.15]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g84EtQKB007686; Wed, 4 Sep 2002 07:55:26 -0700 (PDT)
Received: from cisco.com (ams-rraszuk2-vpn5.cisco.com [10.61.160.14]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id AGB35080; Wed, 4 Sep 2002 07:55:24 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Wed, 04 Sep 2002 16:55:16 +0200
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: Yakov Rekhter <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: IDR WG charter
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Reject new IDR WG charter proposal.

As a motivation I could only quote recent Pedro's mail listing very
valid points on Wed, 21 Aug 2002 in the mail to this list.

R.

> Yakov Rekhter wrote:
> 
> Folks,
> 
> So far we received just two e-mail on the subject of the IDR WG
> charter proposed by Bill and Alex. The WG chairs would like to get
> opinion of the WG members on whether the WG should accept the new
> charter, or stay with the existing one.  With this in mind, please
> send me an e-mail with either "accept" (means accept the new
> charter), or "reject" (means stay with the existing charter). The
> deadline is Sep 17.
> 
> Sue & Yakov.
> ------- Forwarded Message
> 
> Date:    Mon, 26 Aug 2002 07:18:00 -0700
> From:    Yakov Rekhter <[e-mail]>
> To:      [e-mail]
> cc:      [e-mail]
> Subject: IDR WG charter
> 
> Folks,
> 
> Please comment on the revised charter proposed by Bill and Alex
> (see below). The deadline for comments is Sep 10, 2002.
> 
> Sue & Yakov
> - ------- Forwarded Message
> 
> Date:    Thu, 22 Aug 2002 16:11:10 -0700
> From:    Bill Fenner <[e-mail]>
> To:      [e-mail]
> Subject: BGP spec and IDR WG charter
> 
> Dear IDR WG,
> 
>   After some consideration, the Routing Area Directors have decided
> not to forward any IDR documents for IESG consideration until the
> base BGP spec update is finished.[*]  Despite the best efforts of all
> involved, the spec update has been taking an incredible amount of
> time.  We take this step in order to focus all possible resources
> of the WG community on the BGP spec update.
> 
>   This may seem like a negative action.  On the contrary, it is
> meant to support the accomplishment of the working group's goals.[**]
> The milestone for the submission of the BGP4 draft to the IESG
> was scheduled for January 2002.
> 
>   Attached is a proposed update for the IDR working group charter.
> Note that we just made up the dates in the goals and milestones,
> and the WG should come up with realistic ones.
> 
>   Bill and Alex
> 
> [*] "finished" means, in this case, WG consensus, WG Last Call,
> AD Review, IETF Last Call, and IESG approval for publication.
> 
> [**] In further support of the goal of having a quality specification
> that reflects current reality, the ADs have been working on assembling
> a team of reviewers that consists primarily of protocol implementors,
> who have committed their time to examine the spec.  We will be
> sending another message to this list explaining the details of how
> this team will do its work.
> 
> - - - - -
> 
> The Inter-Domain Routing Working Group is chartered to standardize
> and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
> 1771] capable of supporting policy based routing for TCP/IP internets.
> The objective is to promote the use of BGP-4 to support IP version
> 4 and IP version 6. The working group will continue to work on
> improving the scalability of BGP.
> 
> The current tasks of the WG are limited to:
> 
> - - - Revise and clarify the base BGP4 document (RFC 1771). Note that
> RFC 1771 no longer documents existing practice and one goal of the
> update is document existing practice. Determine whether the document
> can be advanced as full Standard or needs to recycle at Proposed
> or Draft Standard.
> 
> - - - Submit updated MIBs to accompany the revised base BGP4 document.
> 
> Once these tasks are completed, work will progress on the following:
> 
> - - - Review and Evaluate Existing RFCs on AS Confederations and Route
> Reflection. If changes are needed, create and advance revisions.
> 
> - - - Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
> if any changes need to be made based on current Internet practice
> or based on the changes to the current bgp draft. If changes are
> needed, create an revision. Issue the WG Last Call on advancing
> the document to Draft Standard.
> 
> - - - Produce an updated MIB for AS Confederations, Route Reflection,
> Communities, Multi-Protocol BGP, etc..
> 
> - - - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
> as Draft Standard.
> 
> - - - Complete work on an Extended Community Attribute. Develop MIB
> for BGP Extended Communities.
> 
> - - - Extend BGP to support a 4-byte AS number, develop plan for
> transitioning to usage of 4-byte AS numbers
> 
> - - - Progress along the IETF standards track 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. Currently defined in
> draft-ietf-idr-route-filter-03.txt.
> 
> - - - Progress along standards track an Outbound Router Filter (ORF)
> type for BGP, that can be used to perform aspath based route
> filtering. The ORF-type will support aspath based route filtering
> as well as regular expression based matching for address groups.
> Currently defined in draft-ietf-idr-aspath-orf-00.txt.
> 
> Tasks for this working group are limited to those listed above;
> new items to be added to the charter must be approved by the IESG.
> 
> Goals and Milestones
> 
> DONE    Submit BGP Capability Advertisement to the IESG
> NOV 02  Submit BGP4 document to IESG.
> DEC 02  Submit updated base BGP4 MIB to IESG.
> MAR 03  Submit extensible BGP MIB to IESG.
> MAR 03  Submit Extended Communities draft to IESG.
> MAR 03  Submit 4-byte AS ID to IESG.
> MAR 03  Initial Draft for RFC2858 (if needed)
> MAR 03  BGP TCP MD5 signatures document to IESG.
> MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.
> 
> - ------- End of Forwarded Message
> 
> ------- End of Forwarded Message


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA12624 for <[e-mail]>; Wed, 4 Sep 2002 10:51:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B7A3A91281; Wed,  4 Sep 2002 10:51:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8328F91282; Wed,  4 Sep 2002 10:51:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 532DD91281 for <[e-mail]>; Wed,  4 Sep 2002 10:51:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 525835DDB8; Wed,  4 Sep 2002 10:51:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by segue.merit.edu (Postfix) with ESMTP id 2BA635DD90 for <[e-mail]>; Wed,  4 Sep 2002 10:51:07 -0400 (EDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 86E1A4CE62; Wed,  4 Sep 2002 10:51:06 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id KAA23392; Wed, 4 Sep 2002 10:51:06 -0400 (EDT)
From: Bill Fenner <[e-mail]>
Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id HAA02726; Wed, 4 Sep 2002 07:51:05 -0700 (PDT)
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: [e-mail]
Subject: RE: IDR WG charter
Cc: [e-mail]
Date: Wed, 4 Sep 2002 07:51:05 -0700
Versions: dmail (solaris) 2.5a/makemail 2.9d
Sender: [e-mail]
Precedence: bulk

> According to my understanding the ADs are proposing rejecting any new
>drafts that have significance acceptance by list members from becoming
>a working group item. Not advancement to RFC status. E.G. INFORM spec.

The current charter already says that new work needs an updated
charter.  The modification we're proposing is to not progress any
documents to the IESG (the first step for publishing as an RFC)
until the base BGP spec update is.

>That is what the issue at hand is.

That's what the issue was the last time the charter got updated (in
2001, before my term as AD).

  Bill


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA12540 for <[e-mail]>; Wed, 4 Sep 2002 10:48:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id AC8AF91280; Wed,  4 Sep 2002 10:48:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8236791281; Wed,  4 Sep 2002 10:48:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8278C91280 for <[e-mail]>; Wed,  4 Sep 2002 10:48:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5CCCF5DDB8; Wed,  4 Sep 2002 10:48:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id D83AA5DD90 for <[e-mail]>; Wed,  4 Sep 2002 10:48:37 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA28191; Wed, 4 Sep 2002 10:48:34 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA06092; Wed, 4 Sep 2002 10:48:35 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QLAHJ>; Wed, 4 Sep 2002 10:48:34 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Alex Zinin'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Russ White'" <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail], [e-mail]
Subject: RE: IDR WG charter
Date: Wed, 4 Sep 2002 10:48:34 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Hi Alex:
 
> 
> > Russ:
> >   I totally agree. The working group charter should be to 
> review all new
> > technical draft proposals with equal merit based on what it 
> offers not based
> > on whether the working group has time to take on more work.
> 
> Let's not confuse technical evaluation with not biting more than
> we can chew and prioritizing work.
> 
> > At the rate things get done it will be 1-2 years before the 
> old work is
> > completed
> > (makes it to RFC status), where does that put us with new 
> fresh ideas?
> 
> Sometimes we just have to chew and swallow what we've already
> bitten to bite a new piece. In the particular case of the base
> BGP spec, it is essential to have an accurate protocol
> description, otherwise even describing 'fresh ideas' becomes
> a problem, not even talking about interoperability.
> 

I agree, the protocol should be made stable and accurate according to
the majority of its users, ASAP. That should have no significant impact
on any new ideas that may or may not be dependent on the existing protocol
description. My guess is most of the time these ideas do not require
the base protocol to change for them to be feasable.

> As far as the delay is concerned--it is totally up to the WG
> how fast the work is complete, as the ADs we can promise a fast
> turnaround with reviews, so there will not be a unreasonable
> delay from our side. We will also make sure the spec goes to
> the IESG review as fast as possible. Also note that as soon
> as the IESG approves the spec, we'll be happy to take other
> documents for review, no need to wait until the RFC editor
> is finished with their piece (takes several months now.)
> 

Thats sounds like a reasonable proposal, thanks.

Regards,
Ben 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA12262 for <[e-mail]>; Wed, 4 Sep 2002 10:40:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B11439127E; Wed,  4 Sep 2002 10:39:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7EC359127F; Wed,  4 Sep 2002 10:39:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8906C9127E for <[e-mail]>; Wed,  4 Sep 2002 10:39:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6E87D5DDC3; Wed,  4 Sep 2002 10:39:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id E23BE5DD90 for <[e-mail]>; Wed,  4 Sep 2002 10:39:55 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27438; Wed, 4 Sep 2002 10:39:53 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03985; Wed, 4 Sep 2002 10:39:55 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QK0YT>; Wed, 4 Sep 2002 10:39:54 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Bill Fenner <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: IDR WG charter
Date: Wed, 4 Sep 2002 10:39:53 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Andrew:
 According to my understanding the ADs are proposing rejecting any new
drafts that have significance acceptance by list members from becoming
a working group item. Not advancement to RFC status. E.G. INFORM spec.
That is what the issue at hand is.

Ben

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, September 03, 2002 9:12 PM
> To: Bill Fenner
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: IDR WG charter
> 
> 
> Bill,
> 
> Forgive me if I'm being dense, but for my clarification:  The proposed
> changes to the charter do not put a stop on all new work, or even
> new work items being adopted by the wg.  The new charter instead:
> 
>  - Prohibits advancement of a wg work item to RFC status before
>    the base spec is advanced to at least Draft Standard.
>  - Has the requirement that new wg items must have a spot on the
>    agenda, and must be approved by the routing area AD's.
> 
> So new internet drafts could be adopted as wg items, with wg consensus
> and AD approval, but could not advance to RFC status before the base
> bgp spec.
> 
> That would make sense to me, especially for standards-track 
> extentions,
> since extentions require a stable, well-defined base to extend.
> 
> Andrew
> 
> On Tue, Sep 03, 2002 at 05:34:21PM -0700, Bill Fenner wrote:
> > Delivered-To: [e-mail]
> > Delivered-To: [e-mail]
> > Delivered-To: [e-mail]
> > From: Bill Fenner <[e-mail]>
> > To: [e-mail]
> > Subject: RE: IDR WG charter
> > Cc: [e-mail]
> > Date: Tue, 3 Sep 2002 17:34:21 -0700
> > Versions: dmail (solaris) 2.5a/makemail 2.9d
> > Precedence: bulk
> > X-OriginalArrivalTime: 04 Sep 2002 00:36:26.0062 (UTC) 
> FILETIME=[1A0196E0:01C253AB]
> > 
> > 
> > > In those terms, I'd reject until we can understand better about
> > > what we are trying to do with the charter, and how to handle it.
> > 
> > The current charter, with the specific tasks listed and the 
> statement
> > that no other work can be taken on without a charter 
> update, was agreed
> > upon between the WG and the previous ADs.  I suppose the discussion
> > thinking that this stuff is new shows how much attention most people
> > normally pay to the charter?...
> > 
> >   Bill
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA12161 for <[e-mail]>; Wed, 4 Sep 2002 10:37:24 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 91AB49127D; Wed,  4 Sep 2002 10:37:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D52E9127E; Wed,  4 Sep 2002 10:37:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6389C9127D for <[e-mail]>; Wed,  4 Sep 2002 10:37:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3D6815DDC3; Wed,  4 Sep 2002 10:37:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id B92E35DD90 for <[e-mail]>; Wed,  4 Sep 2002 10:36:59 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA27193; Wed, 4 Sep 2002 10:36:56 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA03607; Wed, 4 Sep 2002 10:36:57 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QK0WK>; Wed, 4 Sep 2002 10:36:57 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: IDR WG charter 
Date: Wed, 4 Sep 2002 10:36:56 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Curtis:

 
> >   Is it possible to have two groups active at the same 
> time? 1. The current
> > group 
> > which needs to complete active IDR charter tasks as 
> highlighted by Bill
> > Fenner. 
> 
> My initial response would be "no" since the IESG wants to focus the
> effort of the BGP WG and forming a second WG would dilute the effort.
> 
> OTOH if some of the noise could be diverted, maybe forming a new WG
> and not accepting any of their documents would be a good idea.  :-)
> 

The only reason I would suggest having another "Advance IDR Work" working
group is to keep the new drafts/ideas on the burner while the "primary"
working group keep complete its ongoing tasks. This way, the enthusiasm
of contributors is keep alive and the work evolves and progresses nicely.
Also, it could act as a filter for the new work that might be
a bit controversial. 

E.G. Several drafts/ideas proposed to handle route oscillations.

Ben


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA10662 for <[e-mail]>; Wed, 4 Sep 2002 09:56:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 02BF091277; Wed,  4 Sep 2002 09:56:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C07BA91278; Wed,  4 Sep 2002 09:56:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE98B91277 for <[e-mail]>; Wed,  4 Sep 2002 09:55:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id ACEE35DDC5; Wed,  4 Sep 2002 09:55:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id F23D75DF15 for <[e-mail]>; Wed,  4 Sep 2002 09:55:58 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g84Dtur44975; Wed, 4 Sep 2002 09:55:56 -0400 (EDT) (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 g84DtrG44968; Wed, 4 Sep 2002 09:55:53 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g84Dtro03911; Wed, 4 Sep 2002 09:55:53 -0400 (EDT)
Date: Wed, 4 Sep 2002 09:55:53 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: IDR WG charter
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, Sep 03, 2002 at 01:39:52PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Ben,

On Tue, Sep 03, 2002 at 01:39:52PM -0400, Abarbanel, Benjamin wrote:
> At the rate things get done it will be 1-2 years before the old work is
> completed
> (makes it to RFC status), where does that put us with new fresh ideas?

It shouldn't take that long.  The amount of effort the working group
has expended on debating new drafts would probably have pushed us
to a final draft on bgp if we had used the same effort.

> Ben

-- 
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 JAA10567 for <[e-mail]>; Wed, 4 Sep 2002 09:54:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EA48E91276; Wed,  4 Sep 2002 09:54:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5E1691277; Wed,  4 Sep 2002 09:54:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A7D8A91276 for <[e-mail]>; Wed,  4 Sep 2002 09:54:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 87D545DEED; Wed,  4 Sep 2002 09:54:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id D0CD95DDC5 for <[e-mail]>; Wed,  4 Sep 2002 09:54:04 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g84Ds2G44882; Wed, 4 Sep 2002 09:54:02 -0400 (EDT) (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 g84DrrG44850; Wed, 4 Sep 2002 09:53:53 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g84DrrG03900; Wed, 4 Sep 2002 09:53:53 -0400 (EDT)
Date: Wed, 4 Sep 2002 09:53:53 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: IDR WG charter
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, Sep 03, 2002 at 09:43:42AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Sep 03, 2002 at 09:43:42AM -0700, Yakov Rekhter wrote:
> With this in mind, please
> send me an e-mail with either "accept" (means accept the new
> charter), or "reject" (means stay with the existing charter). The
> deadline is Sep 17.

I say accept.

Lets knuckle down and get this thing (base draft) clarified,
completed and RFCed.

> Sue & 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 JAA10457 for <[e-mail]>; Wed, 4 Sep 2002 09:50:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1AAF191275; Wed,  4 Sep 2002 09:50:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D864091276; Wed,  4 Sep 2002 09:50:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BA1D191275 for <[e-mail]>; Wed,  4 Sep 2002 09:50:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 905A85DEED; Wed,  4 Sep 2002 09:50:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id D32165DDC5 for <[e-mail]>; Wed,  4 Sep 2002 09:50:03 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g84Do1T44568; Wed, 4 Sep 2002 09:50:01 -0400 (EDT) (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 g84DnwG44558; Wed, 4 Sep 2002 09:49:58 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g84DnwK03882; Wed, 4 Sep 2002 09:49:58 -0400 (EDT)
Date: Wed, 4 Sep 2002 09:49:58 -0400
From: Jeffrey Haas <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: [e-mail]
Subject: Re: IDR WG charter
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 Wed, Sep 04, 2002 at 02:59:05PM +0200
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Sep 04, 2002 at 02:59:05PM +0200, Alex Zinin wrote:
> Sometimes we just have to chew and swallow what we've already
> bitten to bite a new piece. In the particular case of the base
> BGP spec, it is essential to have an accurate protocol
> description, otherwise even describing 'fresh ideas' becomes
> a problem, not even talking about interoperability.

And sometimes getting the parties who have diverged from what has
been published to talk about why they did it can be somewhat
difficult.

Consider, for example (not to pick on them particularly), Cisco's
alteration of the route selection algorithm in their implementation
to account for cluster-list length.  If a particular problem is
being solved, then it probably belongs in the base spec.
One way or the other, it potentially introduces compatability issues.

Then there are things that are in the spec that should be dealt
with, but will generate resistance in doing so.  My favorite example
is atomic aggregate.  No one, to my knowledge, implements it as documented.
Additionally, the reasoning for its existance, seems to be largely
irrelevant in today's Internet. 

(In this particular case, no one seems to have knobs to explicitly
de-aggregate routes where there are overlaps.  We know this breaks
things due to the more specifics generated by deaggregation 
clobbering the covering aggregates.)

While the feature of telling that a given route would have components
that may not follow the as path in the route (especially for policy
purposes), its likely that most of the routes in the Net would have
this property - so thats useless.

The only useful thing it signals in current implementations is that
an aggregate has been synthesized and the as path has been truncated.

Apologies for the AA rant - this is what has occupied my attention
in trying to resolve some last minute MIB isssues. :-|

-- 
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 JAA08849 for <[e-mail]>; Wed, 4 Sep 2002 09:01:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8B46A9125C; Wed,  4 Sep 2002 09:01:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 311CA91273; Wed,  4 Sep 2002 09:01:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8C2599125C for <[e-mail]>; Wed,  4 Sep 2002 09:01:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 78D115DEED; Wed,  4 Sep 2002 09:01:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 4E84E5DDB6 for <[e-mail]>; Wed,  4 Sep 2002 09:01:07 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17mZmC-0002KD-00; Wed, 04 Sep 2002 06:00:56 -0700
Date: Wed, 4 Sep 2002 14:59:05 +0200
From: Alex Zinin <[e-mail]>
X-Mailer: The Bat! (v1.51) Personal
Reply-To: Alex Zinin <[e-mail]>
X-Priority: 3 (Normal)
Message-ID: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Russ White'" <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail], <[e-mail]>
Subject: Re: IDR WG charter
In-Reply-To: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Ben-

> Russ:
>   I totally agree. The working group charter should be to review all new
> technical draft proposals with equal merit based on what it offers not based
> on whether the working group has time to take on more work.

Let's not confuse technical evaluation with not biting more than
we can chew and prioritizing work.

> At the rate things get done it will be 1-2 years before the old work is
> completed
> (makes it to RFC status), where does that put us with new fresh ideas?

Sometimes we just have to chew and swallow what we've already
bitten to bite a new piece. In the particular case of the base
BGP spec, it is essential to have an accurate protocol
description, otherwise even describing 'fresh ideas' becomes
a problem, not even talking about interoperability.

As far as the delay is concerned--it is totally up to the WG
how fast the work is complete, as the ADs we can promise a fast
turnaround with reviews, so there will not be a unreasonable
delay from our side. We will also make sure the spec goes to
the IESG review as fast as possible. Also note that as soon
as the IESG approves the spec, we'll be happy to take other
documents for review, no need to wait until the RFC editor
is finished with their piece (takes several months now.)

Alex




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA16093 for <[e-mail]>; Tue, 3 Sep 2002 21:16:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7B0D391252; Tue,  3 Sep 2002 21:15:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46C3791263; Tue,  3 Sep 2002 21:15:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4CE8D91252 for <[e-mail]>; Tue,  3 Sep 2002 21:15:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8CA8D5DEDB; Tue,  3 Sep 2002 21:15:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (unknown [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id B706B5DEA4 for <[e-mail]>; Tue,  3 Sep 2002 21:15:13 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id SAA00737; Tue, 3 Sep 2002 18:12:07 -0700 (PDT)
Date: Tue, 3 Sep 2002 18:12:07 -0700
From: [e-mail]
To: Bill Fenner <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: Re: IDR WG charter
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, Sep 03, 2002 at 05:34:21PM -0700
Sender: [e-mail]
Precedence: bulk

Bill,

Forgive me if I'm being dense, but for my clarification:  The proposed
changes to the charter do not put a stop on all new work, or even
new work items being adopted by the wg.  The new charter instead:

 - Prohibits advancement of a wg work item to RFC status before
   the base spec is advanced to at least Draft Standard.
 - Has the requirement that new wg items must have a spot on the
   agenda, and must be approved by the routing area AD's.

So new internet drafts could be adopted as wg items, with wg consensus
and AD approval, but could not advance to RFC status before the base
bgp spec.

That would make sense to me, especially for standards-track extentions,
since extentions require a stable, well-defined base to extend.

Andrew

On Tue, Sep 03, 2002 at 05:34:21PM -0700, Bill Fenner wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> From: Bill Fenner <[e-mail]>
> To: [e-mail]
> Subject: RE: IDR WG charter
> Cc: [e-mail]
> Date: Tue, 3 Sep 2002 17:34:21 -0700
> Versions: dmail (solaris) 2.5a/makemail 2.9d
> Precedence: bulk
> X-OriginalArrivalTime: 04 Sep 2002 00:36:26.0062 (UTC) FILETIME=[1A0196E0:01C253AB]
> 
> 
> > In those terms, I'd reject until we can understand better about
> > what we are trying to do with the charter, and how to handle it.
> 
> The current charter, with the specific tasks listed and the statement
> that no other work can be taken on without a charter update, was agreed
> upon between the WG and the previous ADs.  I suppose the discussion
> thinking that this stuff is new shows how much attention most people
> normally pay to the charter?...
> 
>   Bill


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA14678 for <[e-mail]>; Tue, 3 Sep 2002 20:34:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8AEBE91252; Tue,  3 Sep 2002 20:34:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 508CF9125C; Tue,  3 Sep 2002 20:34:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 17C8191252 for <[e-mail]>; Tue,  3 Sep 2002 20:34:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E86D15DEBB; Tue,  3 Sep 2002 20:34:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by segue.merit.edu (Postfix) with ESMTP id C65D35DE41 for <[e-mail]>; Tue,  3 Sep 2002 20:34:23 -0400 (EDT)
Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 23D371E00E; Tue,  3 Sep 2002 20:34:23 -0400 (EDT)
Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id UAA06890; Tue, 3 Sep 2002 20:34:22 -0400 (EDT)
From: Bill Fenner <[e-mail]>
Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id RAA24247; Tue, 3 Sep 2002 17:34:22 -0700 (PDT)
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
To: [e-mail]
Subject: RE: IDR WG charter
Cc: [e-mail]
Date: Tue, 3 Sep 2002 17:34:21 -0700
Versions: dmail (solaris) 2.5a/makemail 2.9d
Sender: [e-mail]
Precedence: bulk

> In those terms, I'd reject until we can understand better about
> what we are trying to do with the charter, and how to handle it.

The current charter, with the specific tasks listed and the statement
that no other work can be taken on without a charter update, was agreed
upon between the WG and the previous ADs.  I suppose the discussion
thinking that this stuff is new shows how much attention most people
normally pay to the charter?...

  Bill


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA08603 for <[e-mail]>; Tue, 3 Sep 2002 17:19:21 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0CCB391252; Tue,  3 Sep 2002 17:19:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C687491264; Tue,  3 Sep 2002 17:18:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE82F91252 for <[e-mail]>; Tue,  3 Sep 2002 17:18:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A88ED5DEBC; Tue,  3 Sep 2002 17:18:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from newdev.harvard.edu (unknown [140.247.60.212]) by segue.merit.edu (Postfix) with ESMTP id 48A3B5DEAD for <[e-mail]>; Tue,  3 Sep 2002 17:18:58 -0400 (EDT)
Received: (from sob@localhost) by newdev.harvard.edu (8.12.2/8.12.2) id g83LIlhK017307; Tue, 3 Sep 2002 17:18:47 -0400 (EDT)
Date: Tue, 3 Sep 2002 17:18:47 -0400 (EDT)
From: Scott Bradner <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: IDR WG charte
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

accept


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA04871 for <[e-mail]>; Tue, 3 Sep 2002 15:22:58 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 360179125C; Tue,  3 Sep 2002 15:22:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1CD091260; Tue,  3 Sep 2002 15:22:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 906EB9125C for <[e-mail]>; Tue,  3 Sep 2002 15:22:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 69FB05DEAC; Tue,  3 Sep 2002 15:22:29 -0400 (EDT)
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 053715DEA6 for <[e-mail]>; Tue,  3 Sep 2002 15:22:29 -0400 (EDT)
Received: from tom3 (userar02.uk.uudial.com [62.188.136.161]) by colossus.systems.pipex.net (Postfix) with SMTP id 1F06A1600039E; Tue,  3 Sep 2002 20:22:25 +0100 (BST)
Message-ID: <000401c2537e$d4f1db40$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: <[e-mail]>, "Yakov Rekhter" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: IDR WG charter
Date: Tue, 3 Sep 2002 20:03:09 +0100
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

Accept; I think the ADs have a point

Tom Petch, Network Consultant
[e-mail]

-----Original Message-----
From: Yakov Rekhter <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail]
<[e-mail]>
Date: 03 September 2002 17:43
Subject: IDR WG charter


>Folks,
>
>So far we received just two e-mail on the subject of the IDR WG
>charter proposed by Bill and Alex. The WG chairs would like to get
>opinion of the WG members on whether the WG should accept the new
>charter, or stay with the existing one.  With this in mind, please
>send me an e-mail with either "accept" (means accept the new
>charter), or "reject" (means stay with the existing charter). The
>deadline is Sep 17.
>
>Sue & Yakov.
>------- Forwarded Message
>
>Date:    Mon, 26 Aug 2002 07:18:00 -0700
>From:    Yakov Rekhter <[e-mail]>
>To:      [e-mail]
>cc:      [e-mail]
>Subject: IDR WG charter
>
>Folks,
>
>Please comment on the revised charter proposed by Bill and Alex
>(see below). The deadline for comments is Sep 10, 2002.
>
>Sue & Yakov
>- ------- Forwarded Message
>
>Date:    Thu, 22 Aug 2002 16:11:10 -0700
>From:    Bill Fenner <[e-mail]>
>To:      [e-mail]
>Subject: BGP spec and IDR WG charter
>
>Dear IDR WG,
>
>  After some consideration, the Routing Area Directors have decided
>not to forward any IDR documents for IESG consideration until the
>base BGP spec update is finished.[*]  Despite the best efforts of all
>involved, the spec update has been taking an incredible amount of
>time.  We take this step in order to focus all possible resources
>of the WG community on the BGP spec update.
>
>  This may seem like a negative action.  On the contrary, it is
>meant to support the accomplishment of the working group's goals.[**]
>The milestone for the submission of the BGP4 draft to the IESG
>was scheduled for January 2002.
>
>  Attached is a proposed update for the IDR working group charter.
>Note that we just made up the dates in the goals and milestones,
>and the WG should come up with realistic ones.
>
>  Bill and Alex
>
>[*] "finished" means, in this case, WG consensus, WG Last Call,
>AD Review, IETF Last Call, and IESG approval for publication.
>
>[**] In further support of the goal of having a quality specification
>that reflects current reality, the ADs have been working on
assembling
>a team of reviewers that consists primarily of protocol implementors,
>who have committed their time to examine the spec.  We will be
>sending another message to this list explaining the details of how
>this team will do its work.
>
>- - - - -
>
>The Inter-Domain Routing Working Group is chartered to standardize
>and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
>1771] capable of supporting policy based routing for TCP/IP
internets.
>The objective is to promote the use of BGP-4 to support IP version
>4 and IP version 6. The working group will continue to work on
>improving the scalability of BGP.
>
>The current tasks of the WG are limited to:
>
>- - - Revise and clarify the base BGP4 document (RFC 1771). Note that
>RFC 1771 no longer documents existing practice and one goal of the
>update is document existing practice. Determine whether the document
>can be advanced as full Standard or needs to recycle at Proposed
>or Draft Standard.
>
>- - - Submit updated MIBs to accompany the revised base BGP4
document.
>
>Once these tasks are completed, work will progress on the following:
>
>- - - Review and Evaluate Existing RFCs on AS Confederations and
Route
>Reflection. If changes are needed, create and advance revisions.
>
>- - - Review RFC 2385 (Protection of BGP via TCP MD5 signature) to
see
>if any changes need to be made based on current Internet practice
>or based on the changes to the current bgp draft. If changes are
>needed, create an revision. Issue the WG Last Call on advancing
>the document to Draft Standard.
>
>- - - Produce an updated MIB for AS Confederations, Route Reflection,
>Communities, Multi-Protocol BGP, etc..
>
>- - - Review and evaluate Multiprotocol BGP (RFC 2858) for
advancement
>as Draft Standard.
>
>- - - Complete work on an Extended Community Attribute. Develop MIB
>for BGP Extended Communities.
>
>- - - Extend BGP to support a 4-byte AS number, develop plan for
>transitioning to usage of 4-byte AS numbers
>
>- - - Progress along the IETF standards track 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. Currently defined in
>draft-ietf-idr-route-filter-03.txt.
>
>- - - Progress along standards track an Outbound Router Filter (ORF)
>type for BGP, that can be used to perform aspath based route
>filtering. The ORF-type will support aspath based route filtering
>as well as regular expression based matching for address groups.
>Currently defined in draft-ietf-idr-aspath-orf-00.txt.
>
>Tasks for this working group are limited to those listed above;
>new items to be added to the charter must be approved by the IESG.
>
>Goals and Milestones
>
>DONE    Submit BGP Capability Advertisement to the IESG
>NOV 02  Submit BGP4 document to IESG.
>DEC 02  Submit updated base BGP4 MIB to IESG.
>MAR 03  Submit extensible BGP MIB to IESG.
>MAR 03  Submit Extended Communities draft to IESG.
>MAR 03  Submit 4-byte AS ID to IESG.
>MAR 03  Initial Draft for RFC2858 (if needed)
>MAR 03  BGP TCP MD5 signatures document to IESG.
>MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.
>
>- ------- End of Forwarded Message
>
>
>------- End of Forwarded Message
>



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA04573 for <[e-mail]>; Tue, 3 Sep 2002 15:12:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B35B991252; Tue,  3 Sep 2002 15:11:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7AF339125C; Tue,  3 Sep 2002 15:11:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A1A2F91252 for <[e-mail]>; Tue,  3 Sep 2002 15:11:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8FAAF5DEB3; Tue,  3 Sep 2002 15:11:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from roam.psg.com (h213.p072.iij4u.or.jp [210.130.72.213]) by segue.merit.edu (Postfix) with ESMTP id 0E5CE5DEAE for <[e-mail]>; Tue,  3 Sep 2002 15:11:56 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 17mJ5d-0002nj-00; Tue, 03 Sep 2002 12:11:53 -0700
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: accept
References: <[e-mail]>
Message-Id: <[e-mail]>
Date: Tue, 03 Sep 2002 12:11:53 -0700
Sender: [e-mail]
Precedence: bulk


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA01487 for <[e-mail]>; Tue, 3 Sep 2002 13:40:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A6C739125B; Tue,  3 Sep 2002 13:40:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 767E69125C; Tue,  3 Sep 2002 13:40:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3FCE99125B for <[e-mail]>; Tue,  3 Sep 2002 13:40:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2C3CC5DEAC; Tue,  3 Sep 2002 13:40:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id A573D5DEA4 for <[e-mail]>; Tue,  3 Sep 2002 13:40:04 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA11452; Tue, 3 Sep 2002 13:40:01 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA02574; Tue, 3 Sep 2002 13:40:02 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QJ9M2>; Tue, 3 Sep 2002 13:40:02 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Russ White'" <[e-mail]>, Yakov Rekhter <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: IDR WG charter
Date: Tue, 3 Sep 2002 13:39:52 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Russ:
  I totally agree. The working group charter should be to review all new
technical draft proposals with equal merit based on what it offers not based

on whether the working group has time to take on more work. 

At the rate things get done it will be 1-2 years before the old work is
completed
(makes it to RFC status), where does that put us with new fresh ideas?

Ben

> -----Original Message-----
> From: Russ White [mailto:[e-mail]]
> Sent: Tuesday, September 03, 2002 1:27 PM
> To: Yakov Rekhter
> Cc: [e-mail]; [e-mail]
> Subject: Re: IDR WG charter
> 
> 
> 
> Actually, I'd like to modify this response some. I don't really
> understand why the IDR charter has specific drafts listed in this
> way, or if it's necessary. It seems to move the discussion of
> certain drafts from their technical merits, and deployment, to
> one of who can get the most votes on the charter, or cleverness
> in wording the charter a particular way.
> 
> It seems to me that it would be best to avoid making the charter
> a battelground for accepting or not accepting certain work, and
> instead, let that part happen traditionally, by acceptance of the
> draft, and the name change on the draft, as the indicator.
> 
> Or am I completely lost here?
> 
> In those terms, I'd reject until we can understand better about
> what we are trying to do with the charter, and how to handle it.
> 
> :-)
> 
> Russ
> 
> 
> On Tue, 3 Sep 2002, Russ White wrote:
> 
> > 
> > Accept.
> > 
> > :-)
> > 
> > Russ
> > 
> > On Tue, 3 Sep 2002, Yakov Rekhter wrote:
> > 
> > > Folks,
> > > 
> > > So far we received just two e-mail on the subject of the IDR WG
> > > charter proposed by Bill and Alex. The WG chairs would like to get
> > > opinion of the WG members on whether the WG should accept the new
> > > charter, or stay with the existing one.  With this in mind, please
> > > send me an e-mail with either "accept" (means accept the new
> > > charter), or "reject" (means stay with the existing charter). The
> > > deadline is Sep 17.
> > > 
> > > Sue & Yakov.
> > > ------- Forwarded Message
> > > 
> > > Date:    Mon, 26 Aug 2002 07:18:00 -0700
> > > From:    Yakov Rekhter <[e-mail]>
> > > To:      [e-mail]
> > > cc:      [e-mail]
> > > Subject: IDR WG charter
> > > 
> > > Folks,
> > > 
> > > Please comment on the revised charter proposed by Bill and Alex
> > > (see below). The deadline for comments is Sep 10, 2002.
> > > 
> > > Sue & Yakov
> > > - ------- Forwarded Message
> > > 
> > > Date:    Thu, 22 Aug 2002 16:11:10 -0700
> > > From:    Bill Fenner <[e-mail]>
> > > To:      [e-mail]
> > > Subject: BGP spec and IDR WG charter
> > > 
> > > Dear IDR WG,
> > > 
> > >   After some consideration, the Routing Area Directors 
> have decided
> > > not to forward any IDR documents for IESG consideration until the
> > > base BGP spec update is finished.[*]  Despite the best 
> efforts of all
> > > involved, the spec update has been taking an incredible amount of
> > > time.  We take this step in order to focus all possible resources
> > > of the WG community on the BGP spec update.
> > > 
> > >   This may seem like a negative action.  On the contrary, it is
> > > meant to support the accomplishment of the working 
> group's goals.[**]
> > > The milestone for the submission of the BGP4 draft to the IESG
> > > was scheduled for January 2002.
> > > 
> > >   Attached is a proposed update for the IDR working group charter.
> > > Note that we just made up the dates in the goals and milestones,
> > > and the WG should come up with realistic ones.
> > > 
> > >   Bill and Alex
> > > 
> > > [*] "finished" means, in this case, WG consensus, WG Last Call,
> > > AD Review, IETF Last Call, and IESG approval for publication.
> > > 
> > > [**] In further support of the goal of having a quality 
> specification
> > > that reflects current reality, the ADs have been working 
> on assembling
> > > a team of reviewers that consists primarily of protocol 
> implementors,
> > > who have committed their time to examine the spec.  We will be
> > > sending another message to this list explaining the details of how
> > > this team will do its work.
> > > 
> > > - - - - -
> > > 
> > > The Inter-Domain Routing Working Group is chartered to standardize
> > > and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
> > > 1771] capable of supporting policy based routing for 
> TCP/IP internets.
> > > The objective is to promote the use of BGP-4 to support IP version
> > > 4 and IP version 6. The working group will continue to work on
> > > improving the scalability of BGP.
> > > 
> > > The current tasks of the WG are limited to:
> > > 
> > > - - - Revise and clarify the base BGP4 document (RFC 
> 1771). Note that
> > > RFC 1771 no longer documents existing practice and one goal of the
> > > update is document existing practice. Determine whether 
> the document
> > > can be advanced as full Standard or needs to recycle at Proposed
> > > or Draft Standard.
> > > 
> > > - - - Submit updated MIBs to accompany the revised base 
> BGP4 document.
> > > 
> > > Once these tasks are completed, work will progress on the 
> following:
> > > 
> > > - - - Review and Evaluate Existing RFCs on AS 
> Confederations and Route
> > > Reflection. If changes are needed, create and advance revisions.
> > > 
> > > - - - Review RFC 2385 (Protection of BGP via TCP MD5 
> signature) to see
> > > if any changes need to be made based on current Internet practice
> > > or based on the changes to the current bgp draft. If changes are
> > > needed, create an revision. Issue the WG Last Call on advancing
> > > the document to Draft Standard.
> > > 
> > > - - - Produce an updated MIB for AS Confederations, Route 
> Reflection,
> > > Communities, Multi-Protocol BGP, etc..
> > > 
> > > - - - Review and evaluate Multiprotocol BGP (RFC 2858) 
> for advancement
> > > as Draft Standard.
> > > 
> > > - - - Complete work on an Extended Community Attribute. 
> Develop MIB
> > > for BGP Extended Communities.
> > > 
> > > - - - Extend BGP to support a 4-byte AS number, develop plan for
> > > transitioning to usage of 4-byte AS numbers
> > > 
> > > - - - Progress along the IETF standards track 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. Currently defined in
> > > draft-ietf-idr-route-filter-03.txt.
> > > 
> > > - - - Progress along standards track an Outbound Router 
> Filter (ORF)
> > > type for BGP, that can be used to perform aspath based route
> > > filtering. The ORF-type will support aspath based route filtering
> > > as well as regular expression based matching for address groups.
> > > Currently defined in draft-ietf-idr-aspath-orf-00.txt.
> > > 
> > > Tasks for this working group are limited to those listed above;
> > > new items to be added to the charter must be approved by the IESG.
> > > 
> > > Goals and Milestones
> > > 
> > > DONE    Submit BGP Capability Advertisement to the IESG
> > > NOV 02  Submit BGP4 document to IESG.
> > > DEC 02  Submit updated base BGP4 MIB to IESG.
> > > MAR 03  Submit extensible BGP MIB to IESG.
> > > MAR 03  Submit Extended Communities draft to IESG.
> > > MAR 03  Submit 4-byte AS ID to IESG.
> > > MAR 03  Initial Draft for RFC2858 (if needed)
> > > MAR 03  BGP TCP MD5 signatures document to IESG.
> > > MAR 03  Outbound Route Filter, Prefix and ASpath ORF 
> draft to IESG.
> > > 
> > > - ------- End of Forwarded Message
> > > 
> > > 
> > > ------- End of Forwarded Message
> > > 
> > 
> > __________________________________
> > [e-mail] CCIE <>< Grace Alone
> > 
> > 
> > 
> 
> __________________________________
> [e-mail] CCIE <>< Grace Alone
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA01105 for <[e-mail]>; Tue, 3 Sep 2002 13:27:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5DF6A91257; Tue,  3 Sep 2002 13:27:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 258F49125A; Tue,  3 Sep 2002 13:27:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6323691257 for <[e-mail]>; Tue,  3 Sep 2002 13:27:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 36F6F5DE9E; Tue,  3 Sep 2002 13:27:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id E411C5DE0A for <[e-mail]>; Tue,  3 Sep 2002 13:27:00 -0400 (EDT)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA13254; Tue, 3 Sep 2002 13:26:59 -0400 (EDT)
Date: Tue, 3 Sep 2002 13:26:59 -0400 (EDT)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: IDR WG charter
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Actually, I'd like to modify this response some. I don't really
understand why the IDR charter has specific drafts listed in this
way, or if it's necessary. It seems to move the discussion of
certain drafts from their technical merits, and deployment, to
one of who can get the most votes on the charter, or cleverness
in wording the charter a particular way.

It seems to me that it would be best to avoid making the charter
a battelground for accepting or not accepting certain work, and
instead, let that part happen traditionally, by acceptance of the
draft, and the name change on the draft, as the indicator.

Or am I completely lost here?

In those terms, I'd reject until we can understand better about
what we are trying to do with the charter, and how to handle it.

:-)

Russ


On Tue, 3 Sep 2002, Russ White wrote:

> 
> Accept.
> 
> :-)
> 
> Russ
> 
> On Tue, 3 Sep 2002, Yakov Rekhter wrote:
> 
> > Folks,
> > 
> > So far we received just two e-mail on the subject of the IDR WG
> > charter proposed by Bill and Alex. The WG chairs would like to get
> > opinion of the WG members on whether the WG should accept the new
> > charter, or stay with the existing one.  With this in mind, please
> > send me an e-mail with either "accept" (means accept the new
> > charter), or "reject" (means stay with the existing charter). The
> > deadline is Sep 17.
> > 
> > Sue & Yakov.
> > ------- Forwarded Message
> > 
> > Date:    Mon, 26 Aug 2002 07:18:00 -0700
> > From:    Yakov Rekhter <[e-mail]>
> > To:      [e-mail]
> > cc:      [e-mail]
> > Subject: IDR WG charter
> > 
> > Folks,
> > 
> > Please comment on the revised charter proposed by Bill and Alex
> > (see below). The deadline for comments is Sep 10, 2002.
> > 
> > Sue & Yakov
> > - ------- Forwarded Message
> > 
> > Date:    Thu, 22 Aug 2002 16:11:10 -0700
> > From:    Bill Fenner <[e-mail]>
> > To:      [e-mail]
> > Subject: BGP spec and IDR WG charter
> > 
> > Dear IDR WG,
> > 
> >   After some consideration, the Routing Area Directors have decided
> > not to forward any IDR documents for IESG consideration until the
> > base BGP spec update is finished.[*]  Despite the best efforts of all
> > involved, the spec update has been taking an incredible amount of
> > time.  We take this step in order to focus all possible resources
> > of the WG community on the BGP spec update.
> > 
> >   This may seem like a negative action.  On the contrary, it is
> > meant to support the accomplishment of the working group's goals.[**]
> > The milestone for the submission of the BGP4 draft to the IESG
> > was scheduled for January 2002.
> > 
> >   Attached is a proposed update for the IDR working group charter.
> > Note that we just made up the dates in the goals and milestones,
> > and the WG should come up with realistic ones.
> > 
> >   Bill and Alex
> > 
> > [*] "finished" means, in this case, WG consensus, WG Last Call,
> > AD Review, IETF Last Call, and IESG approval for publication.
> > 
> > [**] In further support of the goal of having a quality specification
> > that reflects current reality, the ADs have been working on assembling
> > a team of reviewers that consists primarily of protocol implementors,
> > who have committed their time to examine the spec.  We will be
> > sending another message to this list explaining the details of how
> > this team will do its work.
> > 
> > - - - - -
> > 
> > The Inter-Domain Routing Working Group is chartered to standardize
> > and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
> > 1771] capable of supporting policy based routing for TCP/IP internets.
> > The objective is to promote the use of BGP-4 to support IP version
> > 4 and IP version 6. The working group will continue to work on
> > improving the scalability of BGP.
> > 
> > The current tasks of the WG are limited to:
> > 
> > - - - Revise and clarify the base BGP4 document (RFC 1771). Note that
> > RFC 1771 no longer documents existing practice and one goal of the
> > update is document existing practice. Determine whether the document
> > can be advanced as full Standard or needs to recycle at Proposed
> > or Draft Standard.
> > 
> > - - - Submit updated MIBs to accompany the revised base BGP4 document.
> > 
> > Once these tasks are completed, work will progress on the following:
> > 
> > - - - Review and Evaluate Existing RFCs on AS Confederations and Route
> > Reflection. If changes are needed, create and advance revisions.
> > 
> > - - - Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
> > if any changes need to be made based on current Internet practice
> > or based on the changes to the current bgp draft. If changes are
> > needed, create an revision. Issue the WG Last Call on advancing
> > the document to Draft Standard.
> > 
> > - - - Produce an updated MIB for AS Confederations, Route Reflection,
> > Communities, Multi-Protocol BGP, etc..
> > 
> > - - - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
> > as Draft Standard.
> > 
> > - - - Complete work on an Extended Community Attribute. Develop MIB
> > for BGP Extended Communities.
> > 
> > - - - Extend BGP to support a 4-byte AS number, develop plan for
> > transitioning to usage of 4-byte AS numbers
> > 
> > - - - Progress along the IETF standards track 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. Currently defined in
> > draft-ietf-idr-route-filter-03.txt.
> > 
> > - - - Progress along standards track an Outbound Router Filter (ORF)
> > type for BGP, that can be used to perform aspath based route
> > filtering. The ORF-type will support aspath based route filtering
> > as well as regular expression based matching for address groups.
> > Currently defined in draft-ietf-idr-aspath-orf-00.txt.
> > 
> > Tasks for this working group are limited to those listed above;
> > new items to be added to the charter must be approved by the IESG.
> > 
> > Goals and Milestones
> > 
> > DONE    Submit BGP Capability Advertisement to the IESG
> > NOV 02  Submit BGP4 document to IESG.
> > DEC 02  Submit updated base BGP4 MIB to IESG.
> > MAR 03  Submit extensible BGP MIB to IESG.
> > MAR 03  Submit Extended Communities draft to IESG.
> > MAR 03  Submit 4-byte AS ID to IESG.
> > MAR 03  Initial Draft for RFC2858 (if needed)
> > MAR 03  BGP TCP MD5 signatures document to IESG.
> > MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.
> > 
> > - ------- End of Forwarded Message
> > 
> > 
> > ------- End of Forwarded Message
> > 
> 
> __________________________________
> [e-mail] CCIE <>< Grace Alone
> 
> 
> 

__________________________________
[e-mail] CCIE <>< Grace Alone




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA00811 for <[e-mail]>; Tue, 3 Sep 2002 13:18:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F32E991216; Tue,  3 Sep 2002 13:18:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F32C59125A; Tue,  3 Sep 2002 13:17:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AA18791257 for <[e-mail]>; Tue,  3 Sep 2002 13:17:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 900C25DEA3; Tue,  3 Sep 2002 13:17:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 43FC35DE9E for <[e-mail]>; Tue,  3 Sep 2002 13:17:04 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC1B2LC>; Tue, 3 Sep 2002 13:17:03 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: IDR WG charter
Date: Tue, 3 Sep 2002 13:17:02 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Reject

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Tuesday, September 03, 2002 12:44 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: IDR WG charter

Folks,

So far we received just two e-mail on the subject of the IDR WG
charter proposed by Bill and Alex. The WG chairs would like to get
opinion of the WG members on whether the WG should accept the new
charter, or stay with the existing one.  With this in mind, please
send me an e-mail with either "accept" (means accept the new
charter), or "reject" (means stay with the existing charter). The
deadline is Sep 17.

Sue & Yakov.
------- Forwarded Message

Date:    Mon, 26 Aug 2002 07:18:00 -0700
From:    Yakov Rekhter <[e-mail]>
To:      [e-mail]
cc:      [e-mail]
Subject: IDR WG charter

Folks,

Please comment on the revised charter proposed by Bill and Alex
(see below). The deadline for comments is Sep 10, 2002.

Sue & Yakov
- ------- Forwarded Message

Date:    Thu, 22 Aug 2002 16:11:10 -0700
From:    Bill Fenner <[e-mail]>
To:      [e-mail]
Subject: BGP spec and IDR WG charter

Dear IDR WG,

  After some consideration, the Routing Area Directors have decided
not to forward any IDR documents for IESG consideration until the
base BGP spec update is finished.[*]  Despite the best efforts of all
involved, the spec update has been taking an incredible amount of
time.  We take this step in order to focus all possible resources
of the WG community on the BGP spec update.

  This may seem like a negative action.  On the contrary, it is
meant to support the accomplishment of the working group's goals.[**]
The milestone for the submission of the BGP4 draft to the IESG
was scheduled for January 2002.

  Attached is a proposed update for the IDR working group charter.
Note that we just made up the dates in the goals and milestones,
and the WG should come up with realistic ones.

  Bill and Alex

[*] "finished" means, in this case, WG consensus, WG Last Call,
AD Review, IETF Last Call, and IESG approval for publication.

[**] In further support of the goal of having a quality specification
that reflects current reality, the ADs have been working on assembling
a team of reviewers that consists primarily of protocol implementors,
who have committed their time to examine the spec.  We will be
sending another message to this list explaining the details of how
this team will do its work.

- - - - -

The Inter-Domain Routing Working Group is chartered to standardize
and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
1771] capable of supporting policy based routing for TCP/IP internets.
The objective is to promote the use of BGP-4 to support IP version
4 and IP version 6. The working group will continue to work on
improving the scalability of BGP.

The current tasks of the WG are limited to:

- - - Revise and clarify the base BGP4 document (RFC 1771). Note that
RFC 1771 no longer documents existing practice and one goal of the
update is document existing practice. Determine whether the document
can be advanced as full Standard or needs to recycle at Proposed
or Draft Standard.

- - - Submit updated MIBs to accompany the revised base BGP4 document.

Once these tasks are completed, work will progress on the following:

- - - Review and Evaluate Existing RFCs on AS Confederations and Route
Reflection. If changes are needed, create and advance revisions.

- - - Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
if any changes need to be made based on current Internet practice
or based on the changes to the current bgp draft. If changes are
needed, create an revision. Issue the WG Last Call on advancing
the document to Draft Standard.

- - - Produce an updated MIB for AS Confederations, Route Reflection,
Communities, Multi-Protocol BGP, etc..

- - - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
as Draft Standard.

- - - Complete work on an Extended Community Attribute. Develop MIB
for BGP Extended Communities.

- - - Extend BGP to support a 4-byte AS number, develop plan for
transitioning to usage of 4-byte AS numbers

- - - Progress along the IETF standards track 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. Currently defined in
draft-ietf-idr-route-filter-03.txt.

- - - Progress along standards track an Outbound Router Filter (ORF)
type for BGP, that can be used to perform aspath based route
filtering. The ORF-type will support aspath based route filtering
as well as regular expression based matching for address groups.
Currently defined in draft-ietf-idr-aspath-orf-00.txt.

Tasks for this working group are limited to those listed above;
new items to be added to the charter must be approved by the IESG.

Goals and Milestones

DONE    Submit BGP Capability Advertisement to the IESG
NOV 02  Submit BGP4 document to IESG.
DEC 02  Submit updated base BGP4 MIB to IESG.
MAR 03  Submit extensible BGP MIB to IESG.
MAR 03  Submit Extended Communities draft to IESG.
MAR 03  Submit 4-byte AS ID to IESG.
MAR 03  Initial Draft for RFC2858 (if needed)
MAR 03  BGP TCP MD5 signatures document to IESG.
MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.

- ------- End of Forwarded Message


------- End of Forwarded Message


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA00647 for <[e-mail]>; Tue, 3 Sep 2002 13:13:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 75BEF91256; Tue,  3 Sep 2002 13:13:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 478DB91257; Tue,  3 Sep 2002 13:13:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A385491256 for <[e-mail]>; Tue,  3 Sep 2002 13:12:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8C9205DE9D; Tue,  3 Sep 2002 13:12:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by segue.merit.edu (Postfix) with ESMTP id 19B9E5DE0A for <[e-mail]>; Tue,  3 Sep 2002 13:12:58 -0400 (EDT)
Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA10715; Tue, 3 Sep 2002 13:12:56 -0400 (EDT)
Date: Tue, 3 Sep 2002 13:12:56 -0400 (EDT)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: IDR WG charter
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Accept.

:-)

Russ

On Tue, 3 Sep 2002, Yakov Rekhter wrote:

> Folks,
> 
> So far we received just two e-mail on the subject of the IDR WG
> charter proposed by Bill and Alex. The WG chairs would like to get
> opinion of the WG members on whether the WG should accept the new
> charter, or stay with the existing one.  With this in mind, please
> send me an e-mail with either "accept" (means accept the new
> charter), or "reject" (means stay with the existing charter). The
> deadline is Sep 17.
> 
> Sue & Yakov.
> ------- Forwarded Message
> 
> Date:    Mon, 26 Aug 2002 07:18:00 -0700
> From:    Yakov Rekhter <[e-mail]>
> To:      [e-mail]
> cc:      [e-mail]
> Subject: IDR WG charter
> 
> Folks,
> 
> Please comment on the revised charter proposed by Bill and Alex
> (see below). The deadline for comments is Sep 10, 2002.
> 
> Sue & Yakov
> - ------- Forwarded Message
> 
> Date:    Thu, 22 Aug 2002 16:11:10 -0700
> From:    Bill Fenner <[e-mail]>
> To:      [e-mail]
> Subject: BGP spec and IDR WG charter
> 
> Dear IDR WG,
> 
>   After some consideration, the Routing Area Directors have decided
> not to forward any IDR documents for IESG consideration until the
> base BGP spec update is finished.[*]  Despite the best efforts of all
> involved, the spec update has been taking an incredible amount of
> time.  We take this step in order to focus all possible resources
> of the WG community on the BGP spec update.
> 
>   This may seem like a negative action.  On the contrary, it is
> meant to support the accomplishment of the working group's goals.[**]
> The milestone for the submission of the BGP4 draft to the IESG
> was scheduled for January 2002.
> 
>   Attached is a proposed update for the IDR working group charter.
> Note that we just made up the dates in the goals and milestones,
> and the WG should come up with realistic ones.
> 
>   Bill and Alex
> 
> [*] "finished" means, in this case, WG consensus, WG Last Call,
> AD Review, IETF Last Call, and IESG approval for publication.
> 
> [**] In further support of the goal of having a quality specification
> that reflects current reality, the ADs have been working on assembling
> a team of reviewers that consists primarily of protocol implementors,
> who have committed their time to examine the spec.  We will be
> sending another message to this list explaining the details of how
> this team will do its work.
> 
> - - - - -
> 
> The Inter-Domain Routing Working Group is chartered to standardize
> and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
> 1771] capable of supporting policy based routing for TCP/IP internets.
> The objective is to promote the use of BGP-4 to support IP version
> 4 and IP version 6. The working group will continue to work on
> improving the scalability of BGP.
> 
> The current tasks of the WG are limited to:
> 
> - - - Revise and clarify the base BGP4 document (RFC 1771). Note that
> RFC 1771 no longer documents existing practice and one goal of the
> update is document existing practice. Determine whether the document
> can be advanced as full Standard or needs to recycle at Proposed
> or Draft Standard.
> 
> - - - Submit updated MIBs to accompany the revised base BGP4 document.
> 
> Once these tasks are completed, work will progress on the following:
> 
> - - - Review and Evaluate Existing RFCs on AS Confederations and Route
> Reflection. If changes are needed, create and advance revisions.
> 
> - - - Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
> if any changes need to be made based on current Internet practice
> or based on the changes to the current bgp draft. If changes are
> needed, create an revision. Issue the WG Last Call on advancing
> the document to Draft Standard.
> 
> - - - Produce an updated MIB for AS Confederations, Route Reflection,
> Communities, Multi-Protocol BGP, etc..
> 
> - - - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
> as Draft Standard.
> 
> - - - Complete work on an Extended Community Attribute. Develop MIB
> for BGP Extended Communities.
> 
> - - - Extend BGP to support a 4-byte AS number, develop plan for
> transitioning to usage of 4-byte AS numbers
> 
> - - - Progress along the IETF standards track 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. Currently defined in
> draft-ietf-idr-route-filter-03.txt.
> 
> - - - Progress along standards track an Outbound Router Filter (ORF)
> type for BGP, that can be used to perform aspath based route
> filtering. The ORF-type will support aspath based route filtering
> as well as regular expression based matching for address groups.
> Currently defined in draft-ietf-idr-aspath-orf-00.txt.
> 
> Tasks for this working group are limited to those listed above;
> new items to be added to the charter must be approved by the IESG.
> 
> Goals and Milestones
> 
> DONE    Submit BGP Capability Advertisement to the IESG
> NOV 02  Submit BGP4 document to IESG.
> DEC 02  Submit updated base BGP4 MIB to IESG.
> MAR 03  Submit extensible BGP MIB to IESG.
> MAR 03  Submit Extended Communities draft to IESG.
> MAR 03  Submit 4-byte AS ID to IESG.
> MAR 03  Initial Draft for RFC2858 (if needed)
> MAR 03  BGP TCP MD5 signatures document to IESG.
> MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.
> 
> - ------- End of Forwarded Message
> 
> 
> ------- End of Forwarded Message
> 

__________________________________
[e-mail] CCIE <>< Grace Alone




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA00068 for <[e-mail]>; Tue, 3 Sep 2002 12:57:15 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5EC6791254; Tue,  3 Sep 2002 12:56:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E8BC91255; Tue,  3 Sep 2002 12:56:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2066091254 for <[e-mail]>; Tue,  3 Sep 2002 12:56:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0A2435DE9E; Tue,  3 Sep 2002 12:56:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by segue.merit.edu (Postfix) with ESMTP id 879565DE9D for <[e-mail]>; Tue,  3 Sep 2002 12:56:52 -0400 (EDT)
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA08661; Tue, 3 Sep 2002 12:56:48 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA23987; Tue, 3 Sep 2002 12:56:49 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <R68QJ7D3>; Tue, 3 Sep 2002 12:56:48 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: IDR WG charter
Date: Tue, 3 Sep 2002 12:56:38 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Yakov and Sue:
 The new charter and existing charter seem to be the same based on this
email
and the IDR working group charter description on the Web at:
http://www.ietf.org/html.charters/idr-charter.html

Am I missing something or are we voting for the same thing?

The only thing that is different in this mail is refusal to accept new draft
proposals. 

If that is the case, I vote "REJECT" the new plan.

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Tuesday, September 03, 2002 12:44 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: IDR WG charter
> 
> 
> Folks,
> 
> So far we received just two e-mail on the subject of the IDR WG
> charter proposed by Bill and Alex. The WG chairs would like to get
> opinion of the WG members on whether the WG should accept the new
> charter, or stay with the existing one.  With this in mind, please
> send me an e-mail with either "accept" (means accept the new
> charter), or "reject" (means stay with the existing charter). The
> deadline is Sep 17.
> 
> Sue & Yakov.
> ------- Forwarded Message
> 
> Date:    Mon, 26 Aug 2002 07:18:00 -0700
> From:    Yakov Rekhter <[e-mail]>
> To:      [e-mail]
> cc:      [e-mail]
> Subject: IDR WG charter
> 
> Folks,
> 
> Please comment on the revised charter proposed by Bill and Alex
> (see below). The deadline for comments is Sep 10, 2002.
> 
> Sue & Yakov
> - ------- Forwarded Message
> 
> Date:    Thu, 22 Aug 2002 16:11:10 -0700
> From:    Bill Fenner <[e-mail]>
> To:      [e-mail]
> Subject: BGP spec and IDR WG charter
> 
> Dear IDR WG,
> 
>   After some consideration, the Routing Area Directors have decided
> not to forward any IDR documents for IESG consideration until the
> base BGP spec update is finished.[*]  Despite the best efforts of all
> involved, the spec update has been taking an incredible amount of
> time.  We take this step in order to focus all possible resources
> of the WG community on the BGP spec update.
> 
>   This may seem like a negative action.  On the contrary, it is
> meant to support the accomplishment of the working group's goals.[**]
> The milestone for the submission of the BGP4 draft to the IESG
> was scheduled for January 2002.
> 
>   Attached is a proposed update for the IDR working group charter.
> Note that we just made up the dates in the goals and milestones,
> and the WG should come up with realistic ones.
> 
>   Bill and Alex
> 
> [*] "finished" means, in this case, WG consensus, WG Last Call,
> AD Review, IETF Last Call, and IESG approval for publication.
> 
> [**] In further support of the goal of having a quality specification
> that reflects current reality, the ADs have been working on assembling
> a team of reviewers that consists primarily of protocol implementors,
> who have committed their time to examine the spec.  We will be
> sending another message to this list explaining the details of how
> this team will do its work.
> 
> - - - - -
> 
> The Inter-Domain Routing Working Group is chartered to standardize
> and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
> 1771] capable of supporting policy based routing for TCP/IP internets.
> The objective is to promote the use of BGP-4 to support IP version
> 4 and IP version 6. The working group will continue to work on
> improving the scalability of BGP.
> The current tasks of the WG are limited to:
> 
> - - - Revise and clarify the base BGP4 document (RFC 1771). Note that
> RFC 1771 no longer documents existing practice and one goal of the
> update is document existing practice. Determine whether the document
> can be advanced as full Standard or needs to recycle at Proposed
> or Draft Standard.
> 
> - - - Submit updated MIBs to accompany the revised base BGP4 document.
> 
> Once these tasks are completed, work will progress on the following:
> 
> - - - Review and Evaluate Existing RFCs on AS Confederations and Route
> Reflection. If changes are needed, create and advance revisions.
> 
> - - - Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
> if any changes need to be made based on current Internet practice
> or based on the changes to the current bgp draft. If changes are
> needed, create an revision. Issue the WG Last Call on advancing
> the document to Draft Standard.
> 
> - - - Produce an updated MIB for AS Confederations, Route Reflection,
> Communities, Multi-Protocol BGP, etc..
> 
> - - - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
> as Draft Standard.
> 
> - - - Complete work on an Extended Community Attribute. Develop MIB
> for BGP Extended Communities.
> 
> - - - Extend BGP to support a 4-byte AS number, develop plan for
> transitioning to usage of 4-byte AS numbers
> 
> - - - Progress along the IETF standards track 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. Currently defined in
> draft-ietf-idr-route-filter-03.txt.
> 
> - - - Progress along standards track an Outbound Router Filter (ORF)
> type for BGP, that can be used to perform aspath based route
> filtering. The ORF-type will support aspath based route filtering
> as well as regular expression based matching for address groups.
> Currently defined in draft-ietf-idr-aspath-orf-00.txt.
> 
> Tasks for this working group are limited to those listed above;
> new items to be added to the charter must be approved by the IESG.
> 
> Goals and Milestones
> 
> DONE    Submit BGP Capability Advertisement to the IESG
> NOV 02  Submit BGP4 document to IESG.
> DEC 02  Submit updated base BGP4 MIB to IESG.
> MAR 03  Submit extensible BGP MIB to IESG.
> MAR 03  Submit Extended Communities draft to IESG.
> MAR 03  Submit 4-byte AS ID to IESG.
> MAR 03  Initial Draft for RFC2858 (if needed)
> MAR 03  BGP TCP MD5 signatures document to IESG.
> MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.
> 
> - ------- End of Forwarded Message
> 
> 
> ------- End of Forwarded Message
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA00009 for <[e-mail]>; Tue, 3 Sep 2002 12:55:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4B7B991253; Tue,  3 Sep 2002 12:54:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B42291254; Tue,  3 Sep 2002 12:54:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D292B91253 for <[e-mail]>; Tue,  3 Sep 2002 12:54:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B4C205DE9D; Tue,  3 Sep 2002 12:54:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 287C45DE0A for <[e-mail]>; Tue,  3 Sep 2002 12:54:52 -0400 (EDT)
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 g83Gspm37390; Tue, 3 Sep 2002 09:54:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id g83GspF05346; Tue, 3 Sep 2002 09:54:51 -0700 (PDT) (envelope-from roque)
Date: Tue, 3 Sep 2002 09:54:51 -0700 (PDT)
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: lidefeng <[e-mail]>
Cc: [e-mail]
Subject: about :draft-chunzhe-idr-protection-md5-00.txt
In-Reply-To: <004301c25254$bb453280$[e-mail]>
References: <005e01c24cc9$da653b00$[e-mail]> <[e-mail]> <004301c25254$bb453280$[e-mail]>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: [e-mail]
Precedence: bulk

lidefeng  writes:

> hi, Thanks for your opinion,however, I have interpretation as
> follows:

> 1. The BGP protection method provided by RFC 2385(called RFC 2385
> method later) should maintain one listen socket for every TCP
> connection,

That is not correct.
TCP MD5 only needs one listen socket for the application. That socket
however needs to have an access control list including the passwds of
the neighbors that are allowed to connect.

> 2. RFC 2385 method provided a protection for Transport Layer, while
> chunzhe method provide a protection for the security of Application
> Layer,they serve different function, it can work harmoniously with
> RFC 2385 to provide security for both Transport Layer and
> Application Layer. Then the protection will be robust.

A model, the OSI model for instance, may be helpful when it help us
understand a given problem. I believe that when we begin talking about
security at the 'application' layer vs 'transport layer' the model is
just obfuscating the issue. Let us put the OSI-speak asside for a
while...

There are two things that need to be authenticated... the BGP protocol
data and the session state. The aproach that you are proposing
autenticates the BGP data only, while the existing aproach does
authenticate both.

The aproaches are not complementary... the aproach you are proposing
is redundant if 2385 is in use. It can not replace 2385 since it does
not provide authentication for session state transitions (i.e. TCP
resets/closes).

> 4. In situation where BGP needs authentication,while LDP(which use
> TCP as transport layer protocol) don't support authentication, RFC
> 2385 method will be difficult,while chunzhe method can serve it.

You can use TCP MD5 over both BGP and LDP... LDP does not have any
authentication fields because it is assumed that it will use a lower
layer mechanism that authenticates TCP state transitions, for instance
TCP MD5.

  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 MAA29608 for <[e-mail]>; Tue, 3 Sep 2002 12:44:06 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 597AB91252; Tue,  3 Sep 2002 12:43:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F41391253; Tue,  3 Sep 2002 12:43:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC7DC91252 for <[e-mail]>; Tue,  3 Sep 2002 12:43:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CD1E15DE4B; Tue,  3 Sep 2002 12:43:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id 4612A5DE0A for <[e-mail]>; Tue,  3 Sep 2002 12:43:43 -0400 (EDT)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g83Ghgm36382; Tue, 3 Sep 2002 09:43:42 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: IDR WG charter
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 03 Sep 2002 09:43:42 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

So far we received just two e-mail on the subject of the IDR WG
charter proposed by Bill and Alex. The WG chairs would like to get
opinion of the WG members on whether the WG should accept the new
charter, or stay with the existing one.  With this in mind, please
send me an e-mail with either "accept" (means accept the new
charter), or "reject" (means stay with the existing charter). The
deadline is Sep 17.

Sue & Yakov.
------- Forwarded Message

Date:    Mon, 26 Aug 2002 07:18:00 -0700
From:    Yakov Rekhter <[e-mail]>
To:      [e-mail]
cc:      [e-mail]
Subject: IDR WG charter

Folks,

Please comment on the revised charter proposed by Bill and Alex
(see below). The deadline for comments is Sep 10, 2002.

Sue & Yakov
- ------- Forwarded Message

Date:    Thu, 22 Aug 2002 16:11:10 -0700
From:    Bill Fenner <[e-mail]>
To:      [e-mail]
Subject: BGP spec and IDR WG charter

Dear IDR WG,

  After some consideration, the Routing Area Directors have decided
not to forward any IDR documents for IESG consideration until the
base BGP spec update is finished.[*]  Despite the best efforts of all
involved, the spec update has been taking an incredible amount of
time.  We take this step in order to focus all possible resources
of the WG community on the BGP spec update.

  This may seem like a negative action.  On the contrary, it is
meant to support the accomplishment of the working group's goals.[**]
The milestone for the submission of the BGP4 draft to the IESG
was scheduled for January 2002.

  Attached is a proposed update for the IDR working group charter.
Note that we just made up the dates in the goals and milestones,
and the WG should come up with realistic ones.

  Bill and Alex

[*] "finished" means, in this case, WG consensus, WG Last Call,
AD Review, IETF Last Call, and IESG approval for publication.

[**] In further support of the goal of having a quality specification
that reflects current reality, the ADs have been working on assembling
a team of reviewers that consists primarily of protocol implementors,
who have committed their time to examine the spec.  We will be
sending another message to this list explaining the details of how
this team will do its work.

- - - - -

The Inter-Domain Routing Working Group is chartered to standardize
and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
1771] capable of supporting policy based routing for TCP/IP internets.
The objective is to promote the use of BGP-4 to support IP version
4 and IP version 6. The working group will continue to work on
improving the scalability of BGP.

The current tasks of the WG are limited to:

- - - Revise and clarify the base BGP4 document (RFC 1771). Note that
RFC 1771 no longer documents existing practice and one goal of the
update is document existing practice. Determine whether the document
can be advanced as full Standard or needs to recycle at Proposed
or Draft Standard.

- - - Submit updated MIBs to accompany the revised base BGP4 document.

Once these tasks are completed, work will progress on the following:

- - - Review and Evaluate Existing RFCs on AS Confederations and Route
Reflection. If changes are needed, create and advance revisions.

- - - Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
if any changes need to be made based on current Internet practice
or based on the changes to the current bgp draft. If changes are
needed, create an revision. Issue the WG Last Call on advancing
the document to Draft Standard.

- - - Produce an updated MIB for AS Confederations, Route Reflection,
Communities, Multi-Protocol BGP, etc..

- - - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
as Draft Standard.

- - - Complete work on an Extended Community Attribute. Develop MIB
for BGP Extended Communities.

- - - Extend BGP to support a 4-byte AS number, develop plan for
transitioning to usage of 4-byte AS numbers

- - - Progress along the IETF standards track 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. Currently defined in
draft-ietf-idr-route-filter-03.txt.

- - - Progress along standards track an Outbound Router Filter (ORF)
type for BGP, that can be used to perform aspath based route
filtering. The ORF-type will support aspath based route filtering
as well as regular expression based matching for address groups.
Currently defined in draft-ietf-idr-aspath-orf-00.txt.

Tasks for this working group are limited to those listed above;
new items to be added to the charter must be approved by the IESG.

Goals and Milestones

DONE    Submit BGP Capability Advertisement to the IESG
NOV 02  Submit BGP4 document to IESG.
DEC 02  Submit updated base BGP4 MIB to IESG.
MAR 03  Submit extensible BGP MIB to IESG.
MAR 03  Submit Extended Communities draft to IESG.
MAR 03  Submit 4-byte AS ID to IESG.
MAR 03  Initial Draft for RFC2858 (if needed)
MAR 03  BGP TCP MD5 signatures document to IESG.
MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.

- ------- End of Forwarded Message


------- End of Forwarded Message



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA25176 for <[e-mail]>; Mon, 2 Sep 2002 03:51:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 07BCE91222; Mon,  2 Sep 2002 03:51:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7BD991223; Mon,  2 Sep 2002 03:50:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6634B91222 for <[e-mail]>; Mon,  2 Sep 2002 03:50:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5797F5DE88; Mon,  2 Sep 2002 03:50:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mta0 (unknown [61.144.161.2]) by segue.merit.edu (Postfix) with ESMTP id AA5745DE0C for <[e-mail]>; Mon,  2 Sep 2002 03:50:57 -0400 (EDT)
Received: from ldf (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 02 Sep 2002 15:49:12 +0800 (CST)
Date: Mon, 02 Sep 2002 15:46:27 +0800
From: lidefeng <[e-mail]>
Subject: about:draft-chunzhe-idr-protection-md5-00.txt
To: "John G. Scudder" <[e-mail]>
Cc: [e-mail]
Message-id: <004801c25254$d870d940$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <005e01c24cc9$da653b00$[e-mail]> <p05111a53b98fd85f3503@[171.69.182.142]>
Sender: [e-mail]
Precedence: bulk

hi,

Thanks for your opinion,however, I have interpretation as follows

1. The BGP protection method provided by RFC 2385(called RFC 2385 method
later) should maintain one listen socket
for every TCP connection,so if there are many BGP neighbors,RFC 2385 method
should maintain
many listen sockets for these neighbors,while in this situation, the method
provided by draft-chunzhe-idr-protection-md5-00.txt
(called chunzhe method later) need maintain only one listen socket for all
the neighbors.

2. RFC 2385 method provided a protection for Transport Layer, while chunzhe
method provide
a protection for the security of Application Layer,they serve different
function, it can work harmoniously with RFC 2385 to provide
security for both Transport Layer and Application Layer. Then the protection
will be robust.

3. RFC 2385 method have no option for Authentication Algorithm,so we can't
select the authentication method,
while chunzhe method provide the authentication algorithm field,the
authentication algorithm
is not mandatory as MD5.

4. In situation where BGP needs authentication,while LDP(which use TCP as
transport layer protocol) don't support authentication,
RFC 2385 method will be difficult,while chunzhe method can serve it.


Best Regards

Li Defeng
----- Original Message -----
From: "John G. Scudder" <[e-mail]>
To: "lidefeng" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, August 27, 2002 1:47 AM
Subject: Re: A draft about BGP protection,Please review


> Since draft-huawei-bgp-protection-md5-00.txt does not protect the
> transport layer, some other form of transport layer protection would
> be required in order to protect against RST attacks and the like.  In
> fact, this is exactly why RFC 2385 style protection was developed as
> a TCP option instead of using the BGP authentication field.
>
> Considering that (a) transport layer protection is required anyway,
> (b) as a subset of its functionality it provides substantially the
> same benefits as application layer protection and (c) it's
> well-deployed already, I don't see the motivation for developing
> application layer protection as your draft describes.
>
> Regards,
>
> --John Scudder
>
> At 2:28 PM +0800 8/26/02, lidefeng wrote:
> >hi,
> >
> >     As to the protection of BGP route information, we propose an
> >efficient mechanism as described
> >in draft-huawei-bgp-protection-md5-00.txt.
> >    Please reviev it as soon as possible.Thanks
> >
> >Regards
> >
> >Li Defeng
> >
> >
> >Attachment converted: JGS TiBook:draft-huawei-bgp-protection-md5
> >(TEXT/R*ch) (000A84F0)
>



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA25151 for <[e-mail]>; Mon, 2 Sep 2002 03:50:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D96F19121E; Mon,  2 Sep 2002 03:50:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9CECA91222; Mon,  2 Sep 2002 03:50:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F6A69121E for <[e-mail]>; Mon,  2 Sep 2002 03:50:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2D4965DE88; Mon,  2 Sep 2002 03:50:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mta0 (unknown [61.144.161.2]) by segue.merit.edu (Postfix) with ESMTP id 8D6BF5DE0C for <[e-mail]>; Mon,  2 Sep 2002 03:50:09 -0400 (EDT)
Received: from ldf (mta0 [172.17.1.62]) by mta0.huawei.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTPA id <[e-mail]> for [e-mail]; Mon, 02 Sep 2002 15:48:23 +0800 (CST)
Date: Mon, 02 Sep 2002 15:45:38 +0800
From: lidefeng <[e-mail]>
Subject: about :draft-chunzhe-idr-protection-md5-00.txt
To: Pedro Roque Marques <[e-mail]>
Cc: [e-mail]
Message-id: <004301c25254$bb453280$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <005e01c24cc9$da653b00$[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk

hi,

Thanks for your opinion,however, I have interpretation as follows:

1. The BGP protection method provided by RFC 2385(called RFC 2385 method
later) should maintain one listen socket
for every TCP connection,so if there are many BGP neighbors,RFC 2385 method
should maintain
many listen sockets for these neighbors,while in this situation, the method
provided by draft-chunzhe-idr-protection-md5-00.txt
(called chunzhe method later) need maintain only one listen socket for all
the neighbors.

2. RFC 2385 method provided a protection for Transport Layer, while chunzhe
method provide
a protection for the security of Application Layer,they serve different
function, it can work harmoniously with RFC 2385 to provide
security for both Transport Layer and Application Layer. Then the protection
will be robust.

3. RFC 2385 method have no option for Authentication Algorithm,so we can't
select the authentication method,
while chunzhe method provide the authentication algorithm field,the
authentication algorithm
is not mandatory as MD5.

4. In situation where BGP needs authentication,while LDP(which use TCP as
transport layer protocol) don't support authentication,
RFC 2385 method will be difficult,while chunzhe method can serve it.


Best Regards

Li Defeng

----- Original Message -----
From: "Pedro Roque Marques" <[e-mail]>
To: "lidefeng" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, August 27, 2002 1:42 AM
Subject: A draft about BGP protection,Please review


> lidefeng  writes:
>
> > 3.0 Security Considerations
>
> >     This BGP extension mechanism provides an simple but efficient
> > method to protect the security of BGP route information,compared
> > with other methods which encrypt the whole BGP message,the impact to
> > the performance of route protocol will be sustainable,and in
> > contrast to the existing BGP security mechanism such as RFC2385,
> > which is from the perspective of the transport layer ,this mechanism
> > takes measure on the application layer and do nothing to the
> > transport layer.
>
> Li,
> RFC 2385 protects you against attacks on the TCP session in addition
> to autenticating the BGP data. Causing a valid BGP session to be reset
> via attacks at the TCP layer is a very effective DOS attack which is
> still possible under your proposal.
>
> Effectivly BGP relies on its transport layer to provide it w/ a
> session. Authentication needs to be a property of that session, since
> events on the session are so or more important than the data in the
> session itself.
>
> Protecting BGP data does not address some of the most important
> concerns.
>
>   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 AAA17773 for <[e-mail]>; Mon, 2 Sep 2002 00:12:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C1FE59122A; Mon,  2 Sep 2002 00:12:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93E3F91230; Mon,  2 Sep 2002 00:12:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 611D69122A for <[e-mail]>; Mon,  2 Sep 2002 00:12:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 417655DE7B; Mon,  2 Sep 2002 00:12:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: from webmail7.rediffmail.com (unknown [202.54.124.152]) by segue.merit.edu (Postfix) with SMTP id 749965DE79 for <[e-mail]>; Mon,  2 Sep 2002 00:12:17 -0400 (EDT)
Received: (qmail 5609 invoked by uid 510); 2 Sep 2002 04:11:02 -0000
Date: 2 Sep 2002 04:11:02 -0000
Message-ID: <[e-mail]>
Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 02 sep 2002 04:11:01 -0000
MIME-Version: 1.0
From: "naresh  paliwal" <[e-mail]>
Reply-To: "naresh  paliwal" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: AS Confed for BGP, rfc 3065
Content-type: text/plain; format=flowed
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

In RFC 3065, assignments of Member-AS no. is not discussed.
If it can have any valid value, it may result in wrong open 
message. This is when Member-AS number and neighbouring AS number 
is same.

Open message to a peer in neighouring AS(which is not part of 
confed but has the same AS number as one of the Member-AS) carries 
Member-AS number in place of Confederation ID.

Can anybody suggest something to avoid this.

regards
-naresh