draft-ietf-idr-bgp4-18.txt

["Parag Deshpande" <[e-mail]>]

Hi,

I am unable to locate the latest bgp draft on ietf site. Where can I get it?
I would appreciate if someone could just mail it to me.

Thanks,
Parag





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA06777 for <[e-mail]>; Thu, 31 Oct 2002 17:50:15 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E28CD912BA; Thu, 31 Oct 2002 17:49:48 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE122912BB; Thu, 31 Oct 2002 17:49:48 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 52FF8912BA for <[e-mail]>; Thu, 31 Oct 2002 17:49:47 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3EF185DF68; Thu, 31 Oct 2002 17:49:47 -0500 (EST)
Delivered-To: [e-mail]
Received: from mpls-qmqp-03.inet.qwest.net (mpls-qmqp-03.inet.qwest.net [63.231.195.114]) by segue.merit.edu (Postfix) with SMTP id B6EED5DF66 for <[e-mail]>; Thu, 31 Oct 2002 17:49:45 -0500 (EST)
Received: (qmail 45266 invoked by uid 0); 31 Oct 2002 22:45:17 -0000
Received: from unknown (63.231.195.3) by mpls-qmqp-03.inet.qwest.net with QMQP; 31 Oct 2002 22:45:17 -0000
Received: from mplsapanas03poolc206.mpls.uswest.net (HELO charita) (65.103.5.206) by mpls-pop-03.inet.qwest.net with SMTP; 31 Oct 2002 22:49:44 -0000
Date: Thu, 31 Oct 2002 16:57:18 -0600
Message-ID: <013d01c28130$e0b0ed60$[e-mail]>
From: "Parag Deshpande" <[e-mail]>
To: [e-mail]
Cc: "Susan Hares" <[e-mail]>
References: <[e-mail]>
Subject: draft-ietf-idr-bgp4-18.txt
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 5.00.2615.200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: [e-mail]
Precedence: bulk

Hi,

I am unable to locate the latest bgp draft on ietf site. Where can I get it?
I would appreciate if someone could just mail it to me.

Thanks,
Parag




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA29145 for <[e-mail]>; Thu, 31 Oct 2002 15:31:24 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BEEB19121B; Thu, 31 Oct 2002 15:30:13 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51E069121F; Thu, 31 Oct 2002 15:30:13 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DEDE79121B for <[e-mail]>; Thu, 31 Oct 2002 15:30:10 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 215455DF6A; Thu, 31 Oct 2002 15:30:10 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id E32B55DE1B for <[e-mail]>; Thu, 31 Oct 2002 15:30:08 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9VKTms52541; Thu, 31 Oct 2002 15:29:48 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g9VKTjC52534; Thu, 31 Oct 2002 15:29:45 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9VKTj408273; Thu, 31 Oct 2002 15:29:45 -0500 (EST)
Date: Thu, 31 Oct 2002 15:29:45 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: missing issue - implemented route selections not necessarily consistant with draft
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, Oct 29, 2002 at 10:44:47AM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Curtis,

On Tue, Oct 29, 2002 at 10:44:47AM -0500, Curtis Villamizar wrote:
> Doing this or not will not cause interoperability problems since it is
> after the IGP cost in the decision.  If router A forwards to router B
> because the cost to reach the route is shorter through router B, then
> router B won't forward back to router A (higher IGP cost).
> 
> This just prevents changing the decision if the route from the lower
> BGP Identifier flaps a lot.
> 
> Putting this in the spec as optional would be harmless and useful.

I hadn't actually thought about it those particular terms.

However, I'll pass along some comments from this last NANOG:
Some operators would *really* prefer deterministic route selection.

Of course, as you note, if we make it past the IGP cost steps, we
are simply choosing stuff based on arbitrary criteria to be deterministic
and that some of the implementation changes to introduce temporal
ordering are to introduce stability.

Potentially competing goals.

In response to a comment from a particular lady, I suggested that we
should make sure our implementations all show (during your show ip route
equivalent) what in the tie-breaking process was used to select
a given route.

If we actually decided to go with this, it'd be a cool thing to put
into the MIB.

> 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 XAA06972 for <[e-mail]>; Wed, 30 Oct 2002 23:45:14 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 8DB679129A; Wed, 30 Oct 2002 23:44:37 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 56E279129B; Wed, 30 Oct 2002 23:44:37 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 226999129A for <[e-mail]>; Wed, 30 Oct 2002 23:44:36 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0C30E5DE9F; Wed, 30 Oct 2002 23:44:36 -0500 (EST)
Delivered-To: [e-mail]
Received: from realname (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id B12AA5DE4E for <[e-mail]>; Wed, 30 Oct 2002 23:44:35 -0500 (EST)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) id <[e-mail]> for [e-mail]; Thu, 31 Oct 2002 13:51:04 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <[e-mail]> for [e-mail]; Thu, 31 Oct 2002 13:51:04 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTPA id <[e-mail]> for [e-mail]; Thu, 31 Oct 2002 13:51:46 +0900 (KST)
Date: Thu, 31 Oct 2002 10:12:36 +0530
From: Manav Bhatia <[e-mail]>
Subject: Re: inclusion of AS no in AS path
To: [e-mail], [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <027601c28097$f080dff0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Curtis,

> This is clearly a very special cases that does not have to be
> reflected in the base BGP spec.  If someone (Merit?) wants to write an
> internet-draft describing how a RS uses BGP, that would be fine as a
> separate document describing a special usage of BGP in which some of
> the base BGP rules are altered.

I am *not* at all advocating that you put this in the base spec. My reply
was in response to your statement "I can't think of any exceptions".

Manav



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 QAA13367 for <[e-mail]>; Wed, 30 Oct 2002 16:40:03 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6BF5D91297; Wed, 30 Oct 2002 16:36:15 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD77791294; Wed, 30 Oct 2002 16:36:14 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 543E291294 for <[e-mail]>; Wed, 30 Oct 2002 16:36:07 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 228345DDBB; Wed, 30 Oct 2002 16:36:07 -0500 (EST)
Delivered-To: [e-mail]
Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by segue.merit.edu (Postfix) with ESMTP id 91B115DE54 for <[e-mail]>; Wed, 30 Oct 2002 16:36:06 -0500 (EST)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9ULa5j21812 for [e-mail]; Wed, 30 Oct 2002 16:36:05 -0500 (EST) (envelope-from [e-mail])
Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g9ULZvC21782 for <[e-mail]>; Wed, 30 Oct 2002 16:35:57 -0500 (EST) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9ULZvL05157 for [e-mail]; Wed, 30 Oct 2002 16:35:57 -0500 (EST)
Date: Wed, 30 Oct 2002 16:35:57 -0500
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Re: inclusion of AS no in AS path
Message-ID: <[e-mail]>
References: <024401c28009$d16148f0$[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, Oct 30, 2002 at 11:47:42AM -0500
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Oct 30, 2002 at 11:47:42AM -0500, Curtis Villamizar wrote:
> This is clearly a very special cases that does not have to be
> reflected in the base BGP spec.  If someone (Merit?) wants to write an
> internet-draft describing how a RS uses BGP, that would be fine as a
> separate document describing a special usage of BGP in which some of
> the base BGP rules are altered.

I believe that the last of the deployed RS's at the public IX's 
will be decomissioned soon.  There are still some private IX's that
are utilizing route servers as a method of implementing controlled
policy.

Being probably one of the few advocates for use of route servers
(where appropriate), I think this definitely can slip to an external
draft.  Its also generally fine because most relevant implementations
of routers have a knob for "ignore first as" and so long as
people put this in as a "knob complete" feature, all is well.

> 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 LAA25420 for <[e-mail]>; Wed, 30 Oct 2002 11:48:57 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 5779291283; Wed, 30 Oct 2002 11:48:36 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B1A991284; Wed, 30 Oct 2002 11:48:36 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 54F9F91283 for <[e-mail]>; Wed, 30 Oct 2002 11:48:33 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 2B7F55DEC9; Wed, 30 Oct 2002 11:48:33 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 6B28B5DDE4 for <[e-mail]>; Wed, 30 Oct 2002 11:48:32 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA56058; Wed, 30 Oct 2002 11:47:42 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Manav Bhatia <[e-mail]>
Cc: [e-mail], naresh paliwal <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: inclusion of AS no in AS path 
In-reply-to: Your message of "Wed, 30 Oct 2002 17:15:15 +0530." <024401c28009$d16148f0$[e-mail]> 
Date: Wed, 30 Oct 2002 11:47:42 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <024401c28009$d16148f0$[e-mail]>, Manav Bhatia writes
:
> >
> > When advertising to an EBGP peer, a router MUST include its own AS in
> > the path.  I can't think of any exceptions.
> >
> 
> I have seen atleast two implementations which have a flag to bypass this
> wherein a router does not append its own AS number even if it is
> advertising routes to its EBGP peers. One more scenario when this might
> happen is when the remote peer is configured as a route server client. In
> that case too, the host speaker does not append its own AS number when
> advertising to an EBGP peer.
> 
> Manav


Route servers such as those that are available at some of the NAPs act
as a filter of BGP information which should be as transparent as
possible.  These are definitely special cases.

The RS, the peer that it learned a route from, and the peer it
advertises a route to must all exist on the same broadcast network or
the RS must have other assurance that it's two EBPG peers can directly
reach each other.  The RS passes a third party route, without its own
AS to have the same effect as if the RS peers had passed the route
directly between themselves.

This is clearly a very special cases that does not have to be
reflected in the base BGP spec.  If someone (Merit?) wants to write an
internet-draft describing how a RS uses BGP, that would be fine as a
separate document describing a special usage of BGP in which some of
the base BGP rules are altered.

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 IAA14400 for <[e-mail]>; Wed, 30 Oct 2002 08:48:41 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BBF3391278; Wed, 30 Oct 2002 08:47:27 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B7AE91279; Wed, 30 Oct 2002 08:47:27 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0607191278 for <[e-mail]>; Wed, 30 Oct 2002 08:47:05 -0500 (EST)
Received: by segue.merit.edu (Postfix) id DF54D5DED6; Wed, 30 Oct 2002 08:47:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 687C95DD94 for <[e-mail]>; Wed, 30 Oct 2002 08:47:05 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT0APP>; Wed, 30 Oct 2002 08:47:04 -0500
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: using default route to reach peer 
Date: Wed, 30 Oct 2002 08:47:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Alexei,

So are you saying it does work on pre-12, or are you just assuming it does
because the docs don't say it doesn't?

This is getting old, can we drop it or are we going to check all versions of
code?   The consensus seems to already be that it will not get added to the
draft.  I am OK with this, although I stand by my original assertion that it
should be added as a "MAY" since it represents working code and could affect
interoperability; we should at least wait to see if other
(non-Juniper/non-IOS) implementations have this limitation as I tried to do
initially (before I got stomped by Pedro).

:-)


> -----Original Message-----
> From: Alexei Roudnev [mailto:[e-mail]] 
> Sent: Wednesday, October 30, 2002 2:04 AM
> To: Natale, Jonathan; [e-mail]
> Cc: [e-mail]
> Subject: Re: using default route to reach peer 
> 
> 
> I found this limitation in IOS 12.x only; and I am not sure 
> if it have any meaning
> except protection from dummy admins. Before, they had such notice:
> 
> ===
> Usage Guidelines
> This feature should only be used under the guidance of 
> technical support staff.
> ===
> 
> 
> So, it's not in the CISCO IOS, it's in very last version of 
> Cisco IOS only. And I
> do not think it's a good idea - I can image a situation when 
> I NEED to use default
> routing for ebgp link.
> 
> Alex Roudnev
> 
> ----- Original Message -----
> From: "Natale, Jonathan" <[e-mail]>
> To: "'Alexei Roudnev'" <[e-mail]>; 
> <[e-mail]>; "Natale,
> Jonathan" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Tuesday, October 29, 2002 8:51 AM
> Subject: RE: using default route to reach peer
> 
> 
> > "The multihop session is not established if the only route 
> to the multi-hop
> > peer's address is the default route (0.0.0.0)."
> > 
> --http://www.cisco.com/univercd/cc/td/doc/product/software/ios
120/12cgcr/np1
> _c/1cprt1/1cbgp.htm
>
> -----Original Message-----
> From: Alexei Roudnev [mailto:[e-mail]]
> Sent: Tuesday, October 29, 2002 11:32 AM
> To: [e-mail]; Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: using default route to reach peer
>
>
>
> >
> > In message
> > <[e-mail]
> > ks.com>, "Natale, Jonathan" writes:
> > > Folks,
> > >
> > > IOS does not allow a BGP peer to be reached via the default route.
> > > This
> ?? Where did you found it? There is not such limuitation in IOS.
>
>


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA09763 for <[e-mail]>; Wed, 30 Oct 2002 06:48:33 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DCFC291276; Wed, 30 Oct 2002 06:47:26 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38A1991277; Wed, 30 Oct 2002 06:47:17 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5D44291276 for <[e-mail]>; Wed, 30 Oct 2002 06:47:12 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3F9365DDF7; Wed, 30 Oct 2002 06:47:12 -0500 (EST)
Delivered-To: [e-mail]
Received: from realname (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id E452D5DD9B for <[e-mail]>; Wed, 30 Oct 2002 06:47:11 -0500 (EST)
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) id <[e-mail]> for [e-mail]; Wed, 30 Oct 2002 20:53:40 +0900 (KST)
Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <[e-mail]> for [e-mail]; Wed, 30 Oct 2002 20:53:40 +0900 (KST)
Received: from Manav ([107.108.3.180]) by mmp2.samsung.com (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 30 Oct 2002 20:54:21 +0900 (KST)
Date: Wed, 30 Oct 2002 17:15:15 +0530
From: Manav Bhatia <[e-mail]>
Subject: Re: inclusion of AS no in AS path
To: [e-mail], naresh paliwal <[e-mail]>
Cc: [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <024401c28009$d16148f0$[e-mail]>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Mailer: Microsoft Outlook Express 6.00.2720.3000
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>
> When advertising to an EBGP peer, a router MUST include its own AS in
> the path.  I can't think of any exceptions.
>

I have seen atleast two implementations which have a flag to bypass this
wherein a router does not append its own AS number even if it is
advertising routes to its EBGP peers. One more scenario when this might
happen is when the remote peer is configured as a route server client. In
that case too, the host speaker does not append its own AS number when
advertising to an EBGP peer.

Manav




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 GAA08183 for <[e-mail]>; Wed, 30 Oct 2002 06:20:27 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id E088791274; Wed, 30 Oct 2002 06:19:47 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A284D91278; Wed, 30 Oct 2002 06:19:47 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 81C2F91274 for <[e-mail]>; Wed, 30 Oct 2002 06:19:42 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 6F3DA5DD94; Wed, 30 Oct 2002 06:19:42 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 9FFCE5DE5E for <[e-mail]>; Wed, 30 Oct 2002 06:19:41 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08613; Wed, 30 Oct 2002 06:17:17 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail], [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-white-sobgp-bgp-extensions-00.txt
Date: Wed, 30 Oct 2002 06:17:17 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Deployment Considerations for Secure Origin BGP 
                          (soBGP)
	Author(s)	: R. White
	Filename	: draft-white-sobgp-bgp-extensions-00.txt
	Pages		: 12
	Date		: 2002-10-29
	
There is a great deal of concern over the security of routing systems
within the Internet, particularly in relation to the Border Gateway
Protocol [BGP], which is used to provide routing information between
autonomous systems. This draft addresses various deployment scenarios
and options using the extensions to BGP outlined in [SOBGP-BGP] in
conjunction with [SOBGP-KEY] (which is not yet completed or
published) and [SOBGP-RADIUS]. Each section of this draft discusses a
different deployment situation or deployment option. The final
section discusses how private key rollovers can be accomplished with
no loss of routing information within soBGP deployments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-white-sobgp-bgp-extensions-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-white-sobgp-bgp-extensions-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-white-sobgp-bgp-extensions-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-white-sobgp-bgp-extensions-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-white-sobgp-bgp-extensions-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 GAA08174 for <[e-mail]>; Wed, 30 Oct 2002 06:20:21 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 9BED091275; Wed, 30 Oct 2002 06:20:09 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 32C0591276; Wed, 30 Oct 2002 06:20:09 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED54791275 for <[e-mail]>; Wed, 30 Oct 2002 06:20:01 -0500 (EST)
Received: by segue.merit.edu (Postfix) id D09605DE5E; Wed, 30 Oct 2002 06:20:01 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 4D42B5DD94 for <[e-mail]>; Wed, 30 Oct 2002 06:20:01 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08690; Wed, 30 Oct 2002 06:17:37 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail], [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ng-sobgp-bgp-extensions-00.txt
Date: Wed, 30 Oct 2002 06:17:37 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Extensions to BGP to Support Secure Origin BGP (soBGP)
	Author(s)	: J. Ng
	Filename	: draft-ng-sobgp-bgp-extensions-00.txt
	Pages		: 28
	Date		: 2002-10-29
	
There is a great deal of concern over the security of routing systems
within the Internet, particularly in relation to the Border Gateway
Protocol [BGP], which is used to provide routing information between
autonomous systems. This document proposes a system where the origin
of any advertisement within BGP can be verified and authenticated,
preventing the advertisement of prefix blocks by unauthorized
networks, and verifying that the final destination in the path is
actually within the autonomous system to which the packets are being
routed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ng-sobgp-bgp-extensions-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-ng-sobgp-bgp-extensions-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-ng-sobgp-bgp-extensions-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-ng-sobgp-bgp-extensions-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ng-sobgp-bgp-extensions-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 GAA08146 for <[e-mail]>; Wed, 30 Oct 2002 06:19:52 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id F33FE9126E; Wed, 30 Oct 2002 06:19:32 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BEE6091274; Wed, 30 Oct 2002 06:19:31 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E0DE9126E for <[e-mail]>; Wed, 30 Oct 2002 06:19:30 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 64A105DE5E; Wed, 30 Oct 2002 06:19:30 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id DD4C85DD94 for <[e-mail]>; Wed, 30 Oct 2002 06:19:29 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08580; Wed, 30 Oct 2002 06:17:06 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-hardie-bounded-longest-match-03.txt
Date: Wed, 30 Oct 2002 06:17:06 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Bounding Longest Match Considered
	Author(s)	: T. Hardie, R. White
	Filename	: draft-hardie-bounded-longest-match-03.txt
	Pages		: 7
	Date		: 2002-10-29
	
Some ASes currently use length-based filters to manage the size of
the routing table they use and propagate.  This draft explores an
alternative to length-based filters which allows for more automatic
configuration and which provides for better redundancy.
Rather than use a filter, this draft proposes a method of modifying
the BGP longest match algorithm by setting a bound on the prefix
lengths eligible for preference.  A bound would operate on long
prefixes when covering route announcements are available; in certain
circumstances it would cause a router to prefer an aggregate over a
more specific route announcement.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hardie-bounded-longest-match-03.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-hardie-bounded-longest-match-03.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-hardie-bounded-longest-match-03.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-hardie-bounded-longest-match-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-hardie-bounded-longest-match-03.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 GAA07504 for <[e-mail]>; Wed, 30 Oct 2002 06:08:41 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 3A7D791207; Wed, 30 Oct 2002 06:08:18 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E830B9126E; Wed, 30 Oct 2002 06:08:17 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A522891207 for <[e-mail]>; Wed, 30 Oct 2002 06:08:16 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 898505DEAE; Wed, 30 Oct 2002 06:08:16 -0500 (EST)
Delivered-To: [e-mail]
Received: from webmail7.rediffmail.com (unknown [202.54.124.152]) by segue.merit.edu (Postfix) with SMTP id 9CFBD5DD9B for <[e-mail]>; Wed, 30 Oct 2002 06:08:14 -0500 (EST)
Received: (qmail 31763 invoked by uid 510); 30 Oct 2002 11:10:16 -0000
Date: 30 Oct 2002 11:10:16 -0000
Message-ID: <[e-mail]>
Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 30 oct 2002 11:10:14 -0000
MIME-Version: 1.0
From: "naresh  paliwal" <[e-mail]>
Reply-To: "naresh  paliwal" <[e-mail]>
To: [e-mail]
Cc: "Curtis Villamizar" <[e-mail]>, [e-mail]
Subject: Re: Re: inclusion of AS no in AS path
Content-type: text/plain; format=flowed
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

Curtis,

agree!

Even rfc 2858 (MPE for BGP4) tells the following:
"If such a message is received from an external peer, the local 
system shall check whether the leftmost AS in the AS_PATH 
attribute is equal to the autonomous system number of the peer 
than sent the message. If that is not the case, the local system 
shall send the NOTIFICATION message with Error Code UPDATE Message 
Error, and the Error Subcode set to Malformed AS_PATH."

This is not specific to MPE feature, then should be included in 
basic BGP4.

-naresh

On Tue, 29 Oct 2002 Curtis Villamizar wrote :
>
>"naresh paliwal" writes:
> >
> > Is not it useful to check whether an update contains 
>external
> > peer's AS number in AS path attribute, avoiding this may 
>introduce
> > routing loop.
> >
> > In other words, Are there situations/policies which could 
>restrict
> > a BGP speaker from including his AS number in the route 
>advertised
> > to an external peer ?
> > If yes how will routing loop be pruned?
> >
> > regards
> > -naresh
>
>
>When advertising to an EBGP peer, a router MUST include its own 
>AS in
>the path.  I can't think of any exceptions.

>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 MAA11056 for <[e-mail]>; Tue, 29 Oct 2002 12:27:04 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id DF9B691260; Tue, 29 Oct 2002 12:26:45 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF50F91262; Tue, 29 Oct 2002 12:26:45 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A63391260 for <[e-mail]>; Tue, 29 Oct 2002 12:26:44 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 578FD5DDC0; Tue, 29 Oct 2002 12:26:44 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 4DE0B5DDB5 for <[e-mail]>; Tue, 29 Oct 2002 12:26:43 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT96XY>; Tue, 29 Oct 2002 12:26:42 -0500
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, naresh paliwal <[e-mail]>
Cc: [e-mail]
Subject: RE: inclusion of AS no in AS path 
Date: Tue, 29 Oct 2002 12:26:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I agree with curtis, a peer must put its AS in

maybe referring to outbound pruning that a major vendor does that is not
required and that we have reached a consensus on not adding to the draft as
a MAY even though the paper the Jeff sent indicates it is good and nobody
could answer me why it is bad. ugh

pruning is done inbound, always.


> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]] 
> Sent: Tuesday, October 29, 2002 12:13 PM
> To: naresh paliwal
> Cc: [e-mail]
> Subject: Re: inclusion of AS no in AS path 
> 
> 
> 
> In message 
> <[e-mail]>, "naresh paliwa
> l" writes:
> > 
> > Is not it useful to check whether an update contains external 
> > peer's AS number in AS path attribute, avoiding this may introduce 
> > routing loop.
> > 
> > In other words, Are there situations/policies which could restrict 
> > a BGP speaker from including his AS number in the route advertised 
> > to an external peer ?
> > If yes how will routing loop be pruned?
> > 
> > regards
> > -naresh
> 
> 
> When advertising to an EBGP peer, a router MUST include its own AS in
> the path.  I can't think of any exceptions.
> 
> 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 MAA10709 for <[e-mail]>; Tue, 29 Oct 2002 12:21:02 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id B375E9125F; Tue, 29 Oct 2002 12:20:35 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CFD891260; Tue, 29 Oct 2002 12:20:35 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E04C9125F for <[e-mail]>; Tue, 29 Oct 2002 12:20:34 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 13A5C5DDC0; Tue, 29 Oct 2002 12:20:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 29E3C5DDB5 for <[e-mail]>; Tue, 29 Oct 2002 12:20:33 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT96WN>; Tue, 29 Oct 2002 12:20:32 -0500
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Alexei Roudnev'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: using default route to reach peer 
Date: Tue, 29 Oct 2002 12:20:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Also applies to IBGP:

Cisco-2500-RtrA#bs
BGP router identifier 192.1.1.1, local AS number 4
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down
State/PfxRcd
11.10.2.12      4     4       4       3        0    0    0 00:04:56 Active
Cisco-2500-RtrA#ping 11.10.2.12

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.10.2.12, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms
Cisco-2500-RtrA#sho ip route 11.10.2.12
% Network not in table
Cisco-2500-RtrA#



> -----Original Message-----
> From: Natale, Jonathan 
> Sent: Tuesday, October 29, 2002 11:52 AM
> To: 'Alexei Roudnev'; [e-mail]; Natale, Jonathan
> Cc: [e-mail]
> Subject: RE: using default route to reach peer 
> 
> 
> "The multihop session is not established if the only route to 
> the multi-hop peer's address is the default route (0.0.0.0)." 
> --http://www.cisco.com/univercd/cc/td/doc/product/software/ios
120/12cgcr/np1_c/1cprt1/1cbgp.htm

-----Original Message-----
From: Alexei Roudnev [mailto:[e-mail]] 
Sent: Tuesday, October 29, 2002 11:32 AM
To: [e-mail]; Natale, Jonathan
Cc: [e-mail]
Subject: Re: using default route to reach peer 



> 
> In message
> <[e-mail]
> ks.com>, "Natale, Jonathan" writes:
> > Folks,
> > 
> > IOS does not allow a BGP peer to be reached via the default route.
> > This
?? Where did you found it? There is not such limuitation in IOS.
 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA10307 for <[e-mail]>; Tue, 29 Oct 2002 12:14:22 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BAD709123A; Tue, 29 Oct 2002 12:13:45 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88AC99125F; Tue, 29 Oct 2002 12:13:45 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4DC039123A for <[e-mail]>; Tue, 29 Oct 2002 12:13:44 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 3704F5DEB8; Tue, 29 Oct 2002 12:13:44 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 68D065DDB5 for <[e-mail]>; Tue, 29 Oct 2002 12:13:43 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id MAA42977; Tue, 29 Oct 2002 12:13:10 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "naresh paliwal" <[e-mail]>
Cc: [e-mail]
Reply-To: [e-mail]
Subject: Re: inclusion of AS no in AS path 
In-reply-to: Your message of "25 Oct 2002 12:18:21 -0000." <[e-mail]> 
Date: Tue, 29 Oct 2002 12:13:10 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, "naresh paliwa
l" writes:
> 
> Is not it useful to check whether an update contains external 
> peer's AS number in AS path attribute, avoiding this may introduce 
> routing loop.
> 
> In other words, Are there situations/policies which could restrict 
> a BGP speaker from including his AS number in the route advertised 
> to an external peer ?
> If yes how will routing loop be pruned?
> 
> regards
> -naresh


When advertising to an EBGP peer, a router MUST include its own AS in
the path.  I can't think of any exceptions.

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 LAA09123 for <[e-mail]>; Tue, 29 Oct 2002 11:52:16 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 9FABC91201; Tue, 29 Oct 2002 11:51:53 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 634BA9125C; Tue, 29 Oct 2002 11:51:53 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1E49791201 for <[e-mail]>; Tue, 29 Oct 2002 11:51:52 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0A90F5DDC0; Tue, 29 Oct 2002 11:51:52 -0500 (EST)
Delivered-To: [e-mail]
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id AACD45DDB5 for <[e-mail]>; Tue, 29 Oct 2002 11:51:51 -0500 (EST)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT96SN>; Tue, 29 Oct 2002 11:51:51 -0500
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Alexei Roudnev'" <[e-mail]>, [e-mail], "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: using default route to reach peer 
Date: Tue, 29 Oct 2002 11:51:50 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

"The multihop session is not established if the only route to the multi-hop
peer's address is the default route (0.0.0.0)."
--http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1
_c/1cprt1/1cbgp.htm

-----Original Message-----
From: Alexei Roudnev [mailto:[e-mail]] 
Sent: Tuesday, October 29, 2002 11:32 AM
To: [e-mail]; Natale, Jonathan
Cc: [e-mail]
Subject: Re: using default route to reach peer 



> 
> In message 
> <[e-mail]
> ks.com>, "Natale, Jonathan" writes:
> > Folks,
> > 
> > IOS does not allow a BGP peer to be reached via the default route.  
> > This
?? Where did you found it? There is not such limuitation in IOS.
 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA07293 for <[e-mail]>; Tue, 29 Oct 2002 11:16:49 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 6059B9125B; Tue, 29 Oct 2002 11:15:37 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2DE8C9125C; Tue, 29 Oct 2002 11:15:37 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AC8659125B for <[e-mail]>; Tue, 29 Oct 2002 11:15:35 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 0CFD45DE52; Tue, 29 Oct 2002 11:15:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id EA50F5DDED for <[e-mail]>; Tue, 29 Oct 2002 11:15:32 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id LAA42716; Tue, 29 Oct 2002 11:15:02 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Reply-To: [e-mail]
Subject: Re: Issue 48 - Explicitly Define Processing of Incomming Connections 
In-reply-to: Your message of "Wed, 23 Oct 2002 10:53:37 EDT." <[e-mail]> 
Date: Tue, 29 Oct 2002 11:15:02 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Jeffrey Haas writes:
> > Curtis later proposed this text:
> 
> Most of which I'm in violent agreement with. :-)
> 
> > 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.
> 
> Its important to note that BGP Identifier is only important if the
> rest of the Open is valid.  For example, we must first get past
> AS number, hold time values, capabilities, etc.
> 
> > The FSM stays around as long as "BGP Identifier" is not known.
> 
> Or may be immediately aborted if the rest of the OPEN is rejected.


To be strictly correct the sentence could be changed to read "The FSM
stays around as long as the BGP session and TCP connection are not
rejected for other reasons and the 'BGP Identifier' is not known."

I don't think this needs to be added since it would seem, at least to
me, clear that a FSM would not be retained for a closed TCP connection
regardless of the reason it was closed, on FIN/ACK completion,
reception of CEASE, OPEN message rejection, or any other reason.


> -- 
> Jeff Haas 
> NextHop Technologies


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 KAA05874 for <[e-mail]>; Tue, 29 Oct 2002 10:50:48 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 449C491259; Tue, 29 Oct 2002 10:50:30 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1247D9125C; Tue, 29 Oct 2002 10:50:29 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D9F629125A for <[e-mail]>; Tue, 29 Oct 2002 10:50:27 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C00E15DE67; Tue, 29 Oct 2002 10:50:27 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id F3F3B5DE99 for <[e-mail]>; Tue, 29 Oct 2002 10:50:26 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA42608; Tue, 29 Oct 2002 10:49:48 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Venu Kumar G - CTD, Chennai." <[e-mail]>, vrishab sikand <[e-mail]>, Jeffrey Haas <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: missing issue - implemented route selections not necessarily consistant with draft 
In-reply-to: Your message of "Thu, 24 Oct 2002 09:12:40 PDT." <[e-mail]> 
Date: Tue, 29 Oct 2002 10:49:48 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Yakov Rekhter writes
:
> Venu,
> 
> > Hi,
> >             It is quiet possible that, we may receive multiple routes for
> > same destination with  varying CLUSTER list length's, even though we are no
> t
> > enabled  ( or Implemented)   RR features on a router.  So i feel we can add
> > this in base spec with indication as  optional to implement. 
> 
> If you don't implement the RR spec, then *by definition* you can't
> recognize CLUSTER_LIST attribute (as this attribute is defined
> in the RR spec). And if you can't recognize the attribute, then you
> can't take it into account for your route selection. 
> 
> In other words, you either implement the RR spec (and in this case
> you also implement the route selection procedures specific to the
> RR spec), or you don't (and in this case you can't take into account
> various attributes defined in the RR spec).
> 
> Yakov.
> 
> > This is cisco's best path selection algorithm
> >  
> >          http://www.cisco.com/warp/public/459/25.shtml
> > <http://www.cisco.com/warp/public/459/25.shtml> 
> >  
> > Venu 



It is also worth pointing out that because RR attributes (CLUSTER_LIST
length) are considered after IGP cost, considering it or not does not
cause any interoperability problems between RR incapable routers and
RR capable routers.

Therefore it does not need to go into the BGP spec and the RR spec
does not need to be changed.  Statements about migration in the RR
spec remain accurate.

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 KAA05671 for <[e-mail]>; Tue, 29 Oct 2002 10:46:40 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 82B8091258; Tue, 29 Oct 2002 10:45:32 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E4DD91259; Tue, 29 Oct 2002 10:45:32 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F160691258 for <[e-mail]>; Tue, 29 Oct 2002 10:45:30 -0500 (EST)
Received: by segue.merit.edu (Postfix) id C8C575DE67; Tue, 29 Oct 2002 10:45:25 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 97BFC5DDED for <[e-mail]>; Tue, 29 Oct 2002 10:45:24 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA42588; Tue, 29 Oct 2002 10:44:47 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: vrishab sikand <[e-mail]>
Cc: Pedro Roque Marques <[e-mail]>, Jeffrey Haas <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: missing issue - implemented route selections not necessarily consistant with draft 
In-reply-to: Your message of "Thu, 24 Oct 2002 11:37:39 PDT." <[e-mail]> 
Date: Tue, 29 Oct 2002 10:44:47 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, vrishab sikand
 writes:
> --0-386623435-1035484659=:38642
> Content-Type: text/plain; charset=us-ascii
> 
> 
> - What about arrival time of a route as decision factor... ?
> I believe there are implementations that choose the 'older' route
> (whatever that is) before router-id in certain circunstances.


Doing this or not will not cause interoperability problems since it is
after the IGP cost in the decision.  If router A forwards to router B
because the cost to reach the route is shorter through router B, then
router B won't forward back to router A (higher IGP cost).

This just prevents changing the decision if the route from the lower
BGP Identifier flaps a lot.

Putting this in the spec as optional would be harmless and useful.

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 KAA04728 for <[e-mail]>; Tue, 29 Oct 2002 10:28:52 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 215929125D; Tue, 29 Oct 2002 10:28:06 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D48689125F; Tue, 29 Oct 2002 10:28:05 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 729489125D for <[e-mail]>; Tue, 29 Oct 2002 10:27:58 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 5A19E5DE87; Tue, 29 Oct 2002 10:27:58 -0500 (EST)
Delivered-To: [e-mail]
Received: from workhorse.fictitious.org (workhorse.fictitious.org [209.150.1.230]) by segue.merit.edu (Postfix) with ESMTP id 86D8E5DE6D for <[e-mail]>; Tue, 29 Oct 2002 10:27:57 -0500 (EST)
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id KAA42536; Tue, 29 Oct 2002 10:27:22 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Reply-To: [e-mail]
Subject: Re: using default route to reach peer 
In-reply-to: Your message of "Thu, 24 Oct 2002 11:37:00 EDT." <[e-mail]> 
Date: Tue, 29 Oct 2002 10:27:22 -0500
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> Folks,
> 
> IOS does not allow a BGP peer to be reached via the default route.  This
> seems like a good rule to me.  Is this specified in the/a RFC/Draft
> somewhere?  Should it be added as a "MAY"?
> 
> Thank You,
> -Jonathan


I disagree.

[ ..cranky stuff omitted per your request.. ]

We've already clarified the line in the charter that you keep quoting.
We are modifying the draft to reflect current practice only where it
affects interoperability.  We are documenting current practices that
in some way significantly differ from the spec, not ever little Cisco
qwirk.

Nothing should be added or changed for this.

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 GAA23357 for <[e-mail]>; Tue, 29 Oct 2002 06:22:02 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 298A29124C; Tue, 29 Oct 2002 06:21:25 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E94689124D; Tue, 29 Oct 2002 06:21:24 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A06319124C for <[e-mail]>; Tue, 29 Oct 2002 06:21:23 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 8196E5DE7E; Tue, 29 Oct 2002 06:21:23 -0500 (EST)
Delivered-To: [e-mail]
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 038A55DE7C for <[e-mail]>; Tue, 29 Oct 2002 06:21:23 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28040; Tue, 29 Oct 2002 06:19:00 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-To: [e-mail]
Subject: I-D ACTION:draft-ietf-ipr-wg-guidelines-00.txt
Date: Tue, 29 Oct 2002 06:18:59 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

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

	Title		: Guidelines for Working Groups on Intellectual Property
                          Issues
	Author(s)	: S. Brim
	Filename	: draft-ietf-ipr-wg-guidelines-00.txt
	Pages		: 15
	Date		: 2002-10-28
	
This memo lays out a conceptual framework and rules of thumb useful
for working groups dealing with IPR issues.  It documents specific
examples of how IPR issues have been dealt with in the IETF.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipr-wg-guidelines-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipr-wg-guidelines-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipr-wg-guidelines-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-ipr-wg-guidelines-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipr-wg-guidelines-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 TAA27781 for <[e-mail]>; Mon, 28 Oct 2002 19:04:24 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 1E16091241; Mon, 28 Oct 2002 19:03:48 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B54EB9123F; Mon, 28 Oct 2002 19:03:47 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5DC6E91241 for <[e-mail]>; Mon, 28 Oct 2002 19:02:34 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 178C45DE28; Mon, 28 Oct 2002 19:02:34 -0500 (EST)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (demiurge.exodus.net [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id C6D675DDAF for <[e-mail]>; Mon, 28 Oct 2002 19:02:30 -0500 (EST)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id PAA17312 for [e-mail]; Mon, 28 Oct 2002 15:59:34 -0800 (PST)
Date: Mon, 28 Oct 2002 15:59:34 -0800
From: [e-mail]
To: [e-mail]
Subject: BGP Base Draft - Issue List v1.5
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="qDbXVdCdHGoSgWSk"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: [e-mail]
Precedence: bulk

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

Greetings,

Good news! With this iteration of the issues list we have NO outstanding
issues.  Over the course of the last week we have resolved the eight
issues we had not reached consensus on. 

Kudos to all, this brings us a big step closer to advancing a draft
to the IESG.

Andrew

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

2002-10-28
v1.5

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 "Unfeasible 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
61) Next Hop for Redistributed Routes
62) Deprecate BGP Authentication Optional Parameter from RFC1771
63) Clarify MED Removal Text
64) MED for Originated Routes
65) Rules for Aggregating with MED and NEXT_HOP
66) Complex AS Path Aggregating
67) Counting AS_SET/AS_CONFED_*
68) Outbound Loop Detection

============================================================================
Issues with Consensus
============================================================================
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
11.3) Documenting IBGP Multipath
12) TCP Behavior Wording
13) Next Hop for Originated Route
14) NEXT_HOP to Internal Peer (closed in favor of issue 61)
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 "Unfeasible 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
61) Next Hop for Redistributed Routes
62) Deprecate BGP Authentication Optional Parameter from RFC1771
63) Clarify MED Removal Text
64) MED for Originated Routes
65) Rules for Aggregating with MED and NEXT_HOP
66) Complex AS Path Aggregating
67) Counting AS_SET/AS_CONFED_*
68) Outbound Loop Detection

============================================================================
Issues WITHOUT Consensus
============================================================================

* NO ISSUES *

----------------------------------------------------------------------------
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 opinions expressed on this were 7 in favor, 4 against.

----------------------------------------------------------------------------
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: 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: Consensus
Change: Yes
Summary:
Get rid of section 9.2.1.3 ("Jitter").
Move the text to an Appendix: "BGP Timers"
Expand text to indicate that jitter applies to all timers, including 
ConnectRetry.

The text for the appendix is listed at the end of the discussion.

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"

Yakov agreed with making some changes and suggested that we make sure
that jitter is applied to all timers.  Specifically, he proposes we
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.

Jonathan, the original commentor, agreed with Yakov's suggestion.

In a follow-up to this issue, there was a question raised about the values
we have specified for timers in the document. Specifically:

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 ?

Curtis responded to this with:

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.

And Jonathan replied with this information about current practice:

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.

So the question that arises from this followup, is how does this question 
affect the text of the appendix on jitter?

Curtis replied that we need to only state that jitter should be applied
to all timers.  Whether a vendor does so or not is a minor deficiency and
does not bear on interoperability.  Therefore, specifying exact details
are not necessary.

After Jonathan's response Curtis and Jonathan agreed that jitter should
be added to all timers and that we should state so in the text.

Yakov proposed the following text for the appendix to discuss jitter:

I'd like to propose the following text for "BGP Timers" section:

BGP employs five timers: ConnectRetry (see Section 8), Hold Time
(see Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval
(see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
Section 9.2.1.1).

The suggested value for the ConnectRetry timer is 120 seconds.

The suggested value for the Hold Time is 90 seconds.

The suggested value for the KeepAlive timer is 1/3 of the Hold
Time.

The suggested value for the MinASOriginationInterval is 15
seconds.

The suggested value for the MinRouteAdvertisementInterval is 30
seconds.

An implementation of BGP MUST allow the Hold Time timer to be
configurable, and MAY allow the other timers to be configurable.

To minimize the likelihood that the distribution of BGP messages
by a given BGP speaker will contain peaks, jitter should be
applied to the timers associated with MinASOriginationInterval,
Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
given BGP speaker shall apply the same jitter to each of these
quantities regardless of the destinations to which the updates
are being sent; that is, jitter will not be applied on a "per
peer" basis.

The amount of jitter to be introduced shall be determined by
multiplying the base value of the appropriate timer by a random
factor which is uniformly distributed in the range from 0.75 to
1.0.

Jeff  & Ben agreed with this.  

Justin suggested that we move the range from 0.75 to 1.25 to ensure that the 
average is around the configured value.  Yakov agreed with Justin's changes. 
Jonathan disagreed, arguing that it was out-of-scope for the task of 
clarifying the text only.  Justin agreed and withdrew his comment.

Curtis liked the general text, but suggested these modifications:

minor improvement (not really an objection) --
s/suggested value/suggested default value/g

Also

s/shall apply the same jitter/may apply the same jitter/
(to each of these quantities regardless of ...).

s/jitter will not be applied/jitter need not be configured/
(on a "per peer" basis).

He stated that in Avici's implementation they allow a lot of granularity
in timer settings, so this reflects current practice.

Curtis also suggested changing the last paragraph:

The suggested default amount of jitter shall be determined by   
multiplying the base value of the appropriate timer by a random
factor which is uniformly distributed in the range from 0.75 to
1.0.  A new random value should be picked each time the timer is
set.  The range of the jitter random value MAY be configurable.

This would make it clear that it is possible to have this timer as 
configurable and still be within spec.

Other comments on Yakov's text pointed out that IOS uses 5 seconds as
the default IBGP MinRouteAdvertisementInterval.

Tom pointed out that there seems to be a discrepency between this text
and the FSM:  The FSM has an OpenDelay timer.  And the FSM suggests a 
HoldTimer of 4 minutes.

In following up on this issue, Yakov stated:

Here is the final text for the BGP Timers section:

BGP employs five timers: ConnectRetry (see Section 8), Hold Time
(see Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval
(see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
Section 9.2.1.1).

The suggested default value for the ConnectRetry timer is 120
seconds.

The suggested default value for the Hold Time is 90 seconds.

The suggested default value for the KeepAlive timer is 1/3 of
the Hold Time.

The suggested default value for the MinASOriginationInterval is
15 seconds.

The suggested default value for the MinRouteAdvertisementInterval
is 30 seconds.

An implementation of BGP MUST allow the Hold Time timer to be
configurable, and MAY allow the other timers to be configurable.

To minimize the likelihood that the distribution of BGP messages
by a given BGP speaker will contain peaks, jitter should be
applied to the timers associated with MinASOriginationInterval,
Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
given BGP speaker may apply the same jitter to each of these
quantities regardless of the destinations to which the updates
are being sent; that is, jitter need not be configured on a "per
peer" basis.

The suggested default amount of jitter shall be determined by
multiplying the base value of the appropriate timer by a random
factor which is uniformly distributed in the range from 0.75 to 
1.0. A new random value should be picked each time the timer
is set. The range of the jitter random value MAY be configurable.

With this in mind, I would suggest we mark this issue as closed.

Jonathan suggested adding "per peer" to the text, Yakov responded with
this text:

An implementation of BGP MUST allow the Hold Time timer to be configurable
on a per peer basis, and MAY allow the other timers to be configurable.

This proposal met with general agreement.  This issue is at consensus.

----------------------------------------------------------------------------
9) Reference to RFC904 - EGP Protocol
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
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.

Yakov agreed to this, and Jonathan seconded it.

----------------------------------------------------------------------------
10) Extending AS_PATH Attribute
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: 
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 MUST not advertise the route to its peers and
may choose to log an error locally.


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. 

Yakov stated that:

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:

After some discussion, Yakov's proposed text's last sentance was dropped
and we arrived at:

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. 

In response to Andrew's clarification question to the list, Curtis
responded:

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.

After some additional discussion, it was decided that we add "and may
choose to log an error locally." to the end of Yakov's text.

Also, we agreed to change "may choose not to advertize..." to 
"MUST NOT advertise...".

So the text 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.

This met with one agreement and no disagreements.  We have a consensus.

----------------------------------------------------------------------------
11) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1
----------------------------------------------------------------------------
Status: Consensus
Change: Yes 
Summary: Add this text:

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

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.

Yakov replied to this that:

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.

The "issue 11" thread this was being discussed in then digressed to the
topic, now covered in issue 11.3.

Ben readdressed the original issue with this input:

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

Jeff replied:

With the exception that Routing Table should be capitalized throughout,
I'd suggest we take this as consensus.

Yakov agreed.  We are at consensus.

----------------------------------------------------------------------------
11.1) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: The text below will be added to the -18 version.

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.

This text will be added to the -18 version, and since there were no
objections, this issue has been moved to consensus.

----------------------------------------------------------------------------
11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add this text:

In the context of this document we assume that a BGP speaker
advertises to its peers only those routes that it
itself uses (in this context a BGP speaker is said to "use" a BGP
route if it is the most preferred BGP route and is used in
forwarding). All other cases are outside the scope of this document.

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 were a lot of emails exchanged on this topic with a variety of 
texts proposed (see early in the "Active Route" thread).  This issue
reopend with Jonathan, who brought up the issue originally, stating that:

The issue I raised, and would like to be [re-]considered is with:

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

Curtis replied that:

That is called route orgination and it is allowed by:

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

Advice on what to put in the AS_PATH and NEXT_HOP is in the document.

He continued with:

I don't think there was ever consensus on what to do with the
statement "a BGP speaker advertises to its peers (other BGP speakers
which it communicates with) in neighboring ASs only those routes that
it itself uses".  Some reasonable choices are:

1.  Omit it (the implied consensus of the rewrite of the paragraph
in 32.2).

2.  Leave it as is and put it in another paragraph to separate it
from the destination based routing statement.

3.  Clean up the wording and put it in another paragraph to separate
it from the destination based routing statement.

The separate paragraph for 2 would be the exact sentence we now have.

A BGP speaker advertises to its peers (other BGP speakers which it
communicates with) in neighboring ASs only those routes that it
itself uses.

In possibility 3 we (try to) clear up the ambiguity about the meaning
of the word "use" in this sentence.

A BGP speaker advertises to its peers (other BGP speakers which it
communicates with) in neighboring ASs only those routes that it
itself uses.  In this context a BGP speaker is said to "use" a BGP
route if it is the most preferred BGP route and is either directly
used in forwarding or in a specifically configured case where the
BGP route would be forwarded internally but IGP forwarding
information is used.  The latter case reflects a usage in which the
IGP is used for forwarding but BGP is originated to IBGP to carry
attributes that cannot be carried by the IGP (for example, BGP
communities [N]).  Other special cases such as virtual routers and
multiple instances of BGP on a single router are beyond the scope
of this document but for each of these the statement "a BGP speaker
advertises to its peers (other BGP speakers which it communicates 
with) in neighboring ASs only those routes that it itself uses" can
(and should in the definition of the extension) be made true with
an appropriate definition of the word "use".

Unless someone volunteers better wording this may be a good starting
point.  I thing the last sentence borders on ridiculous in a protocol
spec but may be necessary to address specific objections raised on
this mailing list.  If we want to elaborate on the meaning of the word
"use" and address the objections this is what we end up with.

Of course looking at what we ended up with, I'd also go along with the
other two options (leave it out or put the one sentence in a separate
paragraph as is).

After some additional discussion (in the "issue 11.2" thread), we have
come to a consensus on this text:

In the context of this document we assume that a BGP speaker
advertises to its peers only those routes that it
itself uses (in this context a BGP speaker is said to "use" a BGP
route if it is the most preferred BGP route and is used in
forwarding). All other cases are outside the scope of this document.

This issue is at consensus.

----------------------------------------------------------------------------
11.3) Documenting IBGP Multipath
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: The documenting of IBGP Multipath is left to another Internet 
Draft.  The consensus is that it should not be in the base spec.

Discussion:

This thread began in the "issue 11" discussion.  In it it was proposed
that:

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.

After much discussion back and forth, it was agreed that documenting
IBGP Multipath behavior is a good thing.  However, it is something that
belongs in another draft.

Alex opened this issue up again.  There were a flury of responses, most
all of them agreeing with the original consensus that we should document
this feature in a different draft, since it doesn't affect the core
interoperatbilty requirements, and we want to advance the spec in a 
timely manner.

Alex persisted in his assertion that this belongs in the base specification.
Right now, the issue is still open.

This discussion later expanded in scope to include all BGP multipath.

Curtis laid out a good description of the various flavors of multipath:

In addition to IGP multihop, there are two cases of BGP multipath.

In IGP multihop there is one BGP advertisement but to ways to reach th
BGP NEXT_HOP via the IGP.

In one case of BGP multihop, two (or more) IBGP routers peering with
the same external AS have equal routes to a destination and are an
equal cost away from a third router.  BGP multihop is applicable to
that third router.  Without BGP multihop, BGP would normally pick the
BGP NEXT_HOP of the advertisement from only one of those IBGP peers
(using BGP Identifier) and use that.  The IGP lookup would yield one
next hop.  With BGP multihop, BGP uses the BGP NEXT_HOP of both
advertisements.  Each BGP NEXT_HOP has a different IGP next hop (one
or more IGP next hop).

The second case is where all of the candidates routes for BGP
multipath are external.  Seldom does IGP multipath come into play for
EBGP (odd tunneled EBGP mutlihop cases maybe).  Typically the load is
split among two (or more) routers in the same AS.

If in EBGP multipath you split among routers in difference AS, an
aggregate should be formed.  This is still prior to the IGP cost rule
in the route selection.

Normally one would not combine IBGP and EBGP in multihop given that
the decsion point for multihop is after "d" in 9.1.2.2.  If the
multihop decision was prior to "d", then two routers each with an
external peering would forward some of the traffic to each other and
for some src/dst pairs, they'd form a loop.  [So don't do that!]

This is getting to be a lot to add to the base spec.  I hope we've
convinced you that we should put it in another document.

Curtis later added specific text, that could serve as a start for the
new document (or added to the base spec if the consensus ended up
going the other way):

BGP specifies how to select the single best route.  OSPF
specifically defines procedures for handling equal cost multipath
(ECMP) [cite OSPF].  The same technique has been applied to ISIS.
A similar technique has been used with BGP.  Variations exist but
the decision to support BGP multipath, the specific variation of
BGP multipath, or not to support it, does not affect  
interoperability.

A naive implementations of ECMP can cause severe performance
degradation for TCP flows.  To avoid this, implementations of BGP
multipath SHOULD maintain packet ordering within microflows as
described in [cite rfc2991, rfc2992].

BGP multipath, if implemented, SHOULD be disabled by default.

In addition to IGP multipath (OSPF ECMP and ISIS equivalent), there
are two variations of BGP multipath described here.  A BGP
implementation may offer both, either one, or neither variation of
BGP multipath.  Other variations of BGP multipath may exist, but no
guarantees can be made in this protocol specification of their
properties or impact on interoperability.

Where IGP multipath is used, there is an interaction with BGP
learned routes.  The lookup of a BGP NEXT_HOP in the IGP can
result in the selection of an IGP multipath entry.  This is not a  
variation of BGP multipath.  When this occurs, one BGP route is
slected as the best but there is more than one way to reach the BGP
NEXT_HOP via the IGP.

In one variation of BGP multipath, a set of more than one IBGP
routers peering with the same external AS have equal routes to a
destination and are an equal IGP cost away from a second set of one
or more routers.  BGP multipath is applicable to the latter set of
routers.  Without BGP multipath, BGP would pick the BGP NEXT_HOP of
the advertisement from only one of those IBGP peers (using BGP   
Identifier) and use only that BGP route.  With BGP multipath, BGP
uses the BGP NEXT_HOP of more than one of these equal cost
advertisements, yielding more than one BGP NEXT_HOP.  Each BGP  
NEXT_HOP has a different IGP next hop (one or more IGP next hop if
IGP multipath is in use).

The second case is where all of the candidates routes for BGP
multipath are external and learned by a single BGP peer.  Without
BGP multipath this peer would select only one of the BGP routes and
obtain only one BGP NEXT_HOP.  With BGP multipath, more than one
equal cost route is selected yielding more than one BGP NEXT_HOP.
Seldom does IGP multipath come into play when looking up an EBGP
NEXT_HOP but could in principle be applicable.

If in EBGP multipath traffic is split among routers in difference
AS, an aggregate SHOULD be formed so as to propogate a route with 
an accurate AS_PATH.  If the resulting aggregate is not more
specific than the components, the AS_SET SHOULD NOT be dropped.

The decsion point for multipath is after step "d" in Section
9.1.2.2 (prefer externally learned routes).  IBGP learned and EBGP
learned routes MUST NOT be combined in multipath.  If the multipath
decision is prior to "d", then two routers each with an external   
peering would form a routing loop.

The decision point for multipath is generally after step "e" in
Section 9.1.2.2.  Some relaxation of the "equal cost" rule (also
applicable to IGP multipath) is possible.  In addition to the equal
cost BGP NEXT_HOPS available at BGP route selection, if the IGP 
next hop for other BGP NEXT_HOPs are of lower cost, then those may 
be used as well.  This relaxation of the step "e" is possible but 
is not widely implemented (and may not be implemented at all).

The consensus of the majority of the IDR WG is to keep this in a 
seperate draft and out of the base spec.

----------------------------------------------------------------------------
12) TCP Behavior Wording
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: In issue 19 we decided to remove this section entirely.  As a 
result the previous consensus on this issue (no change) is renderd
moot.

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.

In issue 19 we decided to remove this section entirely.

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

For related discussion see issue 61.

----------------------------------------------------------------------------
14) NEXT_HOP to Internal Peer
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Closed in favor of issue 61.

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.

Since this issue and issue 61 are basically the same, except 61 proposes
text, we'll close this issue in favor of 61.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
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.

Yakov responded that this will be added to the -18 review.

Jonathan agreed.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
Summary: Remove the section entirely, as this is something that does not
  belong in the base spec.

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.

There seems to be general agreement that this section should be removed.

N.B.  This also affects issue 12.

----------------------------------------------------------------------------
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: Consensus
Change: No
Summary: The consensus is that additional references to RFC2385 are not
necessary.

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.

Yakov replied to this:

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.

Ishi agreed with Yakov.  Jonathan disagreed since he thought no one uses
BGP auth.  Ishi replied that there are lots of people who do use it.
Jonathan replied with a clarification question: "Who uses *BGP's own* 
authentication mechanisms???"  Ron Bonica replied that they use BGP auth.
There was some additional discussion over who implements simple password
authentication vs. MD5.

After further discussion, the consensus seems to be that we should leave
the text as it is for the reasons Yakov pointed out.  There was some
discussion over opening a new issue to discuss deprecating the BGP
auth mechanism discussed in RFC1771 in favor of the mechanism in RFC2385.

The issue of Depricating BGP AUTH is discussed in issue 62.

----------------------------------------------------------------------------
22) Scope of Path Attribute Field
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: This is already being covered by text that has been added to
  the -18 draft.

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

Yakov replied to this that:

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.

There were no objections to this statement, so this issue has been moved
into consensus.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
Summary: 
Add the following to section 3.1:

Changing the attributes 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.

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.

Picking this thread up again, Yakov argued:

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.

Jonathan agreed with this statement, but Ben argued that the text in 
section 3 is insufficent the way it is currently written.   After
two iterations, Ben and Yakov agreed on this formulation for an
update to section 3.1:

Changing the attributes 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.

Jeff objected somewhat to the wording, since, because of a bgp route
is defined as a <path attribute, NLRI> pair, changing either part of
that pair, by definition, changes the route.  He acknowledged that
this might fall under the category of implementation detail.

Yakov presented the view that he thought we were at consensus with the
text he proposed above.  Jonathan agreed.  There were no objections, so
this is moved to Consnesus.

----------------------------------------------------------------------------
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: Consensus
Change: No
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. 

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.

Yakov replied to this that he would suggest we keep things as is, since
the purpose is to document current implementations.

This did not meet with any objections, so this issue has been moved into
consensus.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
Summary:  
Add:

"in case they become resolvable" after the last sentence on p. 46.

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"

Yakov responded that:

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.

Yakov also responded that:

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.

Jonathan, who was the original commentor, agreed with both the changed
text and the clarity of section 3.

----------------------------------------------------------------------------
30) Mention Other Message Types
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add a reference to RFC2918 at the end of the type code list.

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.

Yakov replied that:

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.

Jonathan agreed with this change.  This issue has been moved to consensus.

----------------------------------------------------------------------------
31) Add References to Additional Options
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Consensus to add:

[RFC2842] defines another Optional Parameter.

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.

Yakov replied that:

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.

The original poster agreed with this modification.  This issue is at 
consensus.

----------------------------------------------------------------------------
32) Clarify EGP Reference
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: The consensus is that this was addressed in 32.1, so we can close
this.

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

Yakov replied that an EGP reference will be added (see issue 9).

Yakov also stated that he doesn't see what is wrong with the current text,
and suggsted we keep it.  This includes leaving out any reference to the
status of the EGP spec.  He sees that it is clear from context that we
are talking about "the EGP" [RFC904].

Jeff noted that this issue has been sufficently addressed in the solution
to 32.1.  This met with agreement.  We are at consensus.

----------------------------------------------------------------------------
32.1) EGP ORIGIN Clarification
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: 
Change section 5.1.1 to 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."

Consensus 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]


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.

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.

After some further discussion, we have this text on the table:

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.

Jonathan suggested that we change "propagate this information" to
"forward this route".  He also mentioned that he would prefer something
more explicit instead of/in addition to "The attribute shall be included
in the UPDATE messages of all BGP speakers that choose to propagate this
information to other BGP speakers." such as "other speakers do not
change the ORIGIN value."

On the issue of making the EGP ORIGIN type more clear Andrew proposed:

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.

This met with a number of agreements.

On the second text section we are working on, Jonathan objected to the
current working text below and suggested an alternate:

CHANGE:

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

TO:

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

-or-

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

Jonathan cited a recent example of someone who was still confused by this
section of the text in -17 (not specifically the working text).

Yakov proposed this as final text:

In 4.3:

a)   ORIGIN (Type Code 1):

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 [RFC904]

2         INCOMPLETE - Network Layer Reachability
	Information learned by some other means

Usage of this attribute is defined in 5.1.1.

In 5.1.1:

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

This met with agreement.  This issue is at consensus.

----------------------------------------------------------------------------
32.2) BGP Desitnation-based Forwarding Paradigm
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: After much discussion, this is the consensus:
This text in the current draft:

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.

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: Consensus
Change: Yes
Summary: Add "Optional Non-Transitive" to MED Section
 Add "well-known mandatory" to the NEXT_HOP Section

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.

Yakov agreed to make this change in -18.

Jonathan replied that:

5.1.3 NEXT_HOP also, it is missing " well-known mandatory".

Yakov also agreed to make this change.

----------------------------------------------------------------------------
34) Timer & Counter Definition
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: No discussion, no text proposed, defaults to consensus for
  no change.

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.

There has been no further discussion on this issue.  Unless it is
brought up again, this issue is in consensus, with no change.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
Summary: This change requires a glossary. Yakov has committed to having
a section where commonly used terms are defined in draft 18, so this
issue is at consensus.

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.

Yakov replied:

will be added to the section "Definition of commonly used terms" in -18
version.

----------------------------------------------------------------------------
37) Combine "Unfeasible Routes" and "Withdrawn Routes"
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add the following terms to the "commonly used terms section":

Feasible route
A route that is available for use.

Unfeasible route
A previously advertised feasible route that is no longer available
for use.

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.

Ishi replied to this that he thought that we could combine the two terms,
since there is limited difference from an implementation standpoint.

Yakov replied:

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.

Ishi replied that he was convinved, and that the terms should stay
seperate.

Andrew asked the list if we should define these terms in the "commonly
used terms" section in draft -18.

Ben replied that if we use them alot, we should define them, and if not
local definitions will suffice.

There was some back and forth about the necessity of defining terms which
should be obvious. 

mrr actually checked the doc to see if we were consistantly using the 
terms, and found:

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:

After some further off-list discussion, mrr agreed that this inconsistancy
is extremely minor, and withdrew his comment.  feasible and unfeasible
route will be defined in the "commonly used terms" section to clear
up any confusion.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
Summary: Fix typo & parentheses.

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.

Yakov agreed to drop the third and fourth parentheses in the -18 version.

Jonathan replied to this:

Disagree, the text if fine the way it is, except you need to change
"shorted" to "shorter".

After minimal further discussion, it was decided we are at a consensus
on this issue to fix the typo and drop the third and fourth parentheses.

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

There was some additonal discussion on this point.  Most of it was along
the lines of extracting what was really implemented and supported among
various vendors.  The conclusion was the same.

----------------------------------------------------------------------------
41) Mention FSM Internal Timers
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: No discussion on this issue.  No text proposed.  Perhaps this is
in the FSM section of the draft?  Either way, it defaults to consensus
with no change.

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.

There has been no discussion on this, it now defaults to consensus with
no change.

----------------------------------------------------------------------------
42) Delete the FSM Section
----------------------------------------------------------------------------
Status: Consensus
Change: No
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: Consensus
Change: No
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.  They were later reminded that the base
behavior is acceptable, and agreed.

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.

Yakov replied to this with:

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.

The original poster, Jonathan, agreed with this.  This issue moves to
consensus.

----------------------------------------------------------------------------
45) Consistant References to BGP Peers/Connections/Sessions
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary:  Stick with "BGP Connection" as the consistant term.

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.

After some further discussion, it was decided that, due to existing
implementations, we should go with "BGP connection" as the consistant
term.  We are at consensus.

----------------------------------------------------------------------------
46) FSM Connection Collision Detection
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add this to section 8:

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.

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.

Sue responded that she would be happy to add Curits' text to section 8
and solicited any additional comments.  There was only one on 
capitilization, so this issue is at consensus.

----------------------------------------------------------------------------
47) FSM - Add Explicit State Change Wording
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: A desire for explicit state change wording was expressed.  No
text was proposed.  The assumption is that this issue has reached a
happy conclusion.

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.

There has been no further discussion on this.  The assumption is that
is has reached a happy conclusion privately.

----------------------------------------------------------------------------
48) Explicitly Define Processing of Incomming Connections
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary:  Add text that is at the end of the discussion to section 8.

Discussion:

Alex suggsted we explicity define:

- processing of incoming TCP connections (peer lookup, acceptance,
FSM creation, collision control,)

Curtis later proposed this text:

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.

Jonathan pointed out that there was an inaccuracy in the proposed text.
Curtis replied with this:

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.

Tom replied that:

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

And Curtis suggested that:

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.

Tom agreed with Curtis, that he liked the "will attempt to connect unless 
configured otherwise" verbiage.

This was discussed in the "Generial Editorial Comment" thread.

Sue proposed we add the text above in section 8.2.  It is summarized here
for clarity:

8.2) Description of FSM

8.2.1) FSM connections

(text below)


8.2.2) FSM Definition

(text now in 8.2)

"BGP must maintain a separate FSM for each configured peer plus
Each BGP peer paired in a potential connection unless configured
to remain in the idle state, or configured to remain passive,
will attempt to  to connect to the other.  For the purpose of  
 this discussion, the active or connect side of the TCP
 connection (the side of a TCP connection (the side sending
 the first TCP SYN packet) is called outgoing.  The passive or
 listening side (the sender of the first SYN ACK) is called
 an incoming connection. [See section on the terms active and
passive below.]

A BGP implementation must connect to and listen on TCP port 179
for incoming connections in addition to trying to connect to peers.
Fro 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 an outgoing
connection for the same configured peering 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 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.

There may be more than one connections 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.

8.2.1.1) Terms "active" and "passive"

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 per the   
definition above [and the state machine below.] When 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.

For additional text, see issue 46.

Sue solicited additonal comments, the only one was on capitiziation, so it 
would appear we are at consensus with this issue.

----------------------------------------------------------------------------
49) Explicity Define Event Generation
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Suggested that we explictiy define BGP message processing. No text
proposed.  There has been no further discussion on this issue, it
is assumed that the consensus is that things are ok the way they are.

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 discussion has received no further comment.  Unless someone wants
to reopen it, it is assumed it has reached a happy ending.

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: Consensus
Change: No
Summary: The text that has reached consensus in issue 54 also addresses
  this issue.

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.

This was discussed in the "Review Comments: Section 4.3: "routes" vs.
destinations - advertise" thread.

The text that has reached consensus in issue 54 also addresses this issue.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
Summary: 
Replace:

Path segment length is a 1-octet long field containing
the number of ASs in the path segment value field.

With:

Path segment length is a 1-octet long field containing
the number of ASs (not the number of octets) in the path
segment value field.

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.

Yakov proposed this change:

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.

Jonathan offered this text:

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

Jeff replied that he prefered Yakov's text, but without the "but".  Yakov
agreed to that.  Andrew also agreed, and asked if there were any objections
to moving this issue into consensus.  There were no objections.

----------------------------------------------------------------------------
56) Section 6 - BGP Error Handling
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: There are a variety of updates to the text that are best described
in the discussion section.

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

There have been no objections to the updates listed above.  This issue
seems to have reached a happy ending, so it has been moved into 
consensus.

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: Consensus
Change: Yes
Summary:  For new text, please see the end of the discussion.

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.

Yakov responded to this, saying that he thought these changes were 
reasonable, and unless there were objections, they would be adopted.

Ishi strongly agreed with the changes.

Curtis stated that:

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.

And suggested that we remove the MUSTs and indicated that this is only
informational.

Jeff replied that:

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.

Jonathan agreed with Curtis' idea that we should just move ATOMIC_AGGREGATE
to informational.

Curtis proposed this text:

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

Yakov was fine with this text.

Yakov posted the text that represents the WG consensus:

Replace:

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.

with:

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.

In 9.1.4 replace:

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.

with:

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 MUST 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 met with agreement.  This issue is at consensus.

----------------------------------------------------------------------------
59) Section 4.3 - Move text 
----------------------------------------------------------------------------
Status: Consensus
Change: Yes (minimal)
Summary: Update indentation to allow a new "subsection" heading. Otherwise
no change.

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.

Yakov agreed to update the indentation.

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. 

After Yakov's response and a posting to the list asking that this be moved
to consensus, there were no objections, so this is moved to consensus.

This is discussed in the "Review: Comments: Section 4.3: UPDATE min length"
thread.

----------------------------------------------------------------------------
60) Section 4.3 - Path Attributes
----------------------------------------------------------------------------
Status: Consensus
Change: Yes 
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: Consensus
Change: Yes
Summary:  More cleary specify the behavior of NEXT_HOP modification, for
the text see the end of the 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.

Issue 14 closed in favor of this issue.

In response to Yakov's call for input, Michael responded that:

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 (text is above.)

Yakov replied with this:

Replace:

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.

with:

1) When sending a message to an internal peer, if the route is
not locally originated the BGP speaker should not modify the
NEXT_HOP attribute, unless it has been explicitly configured to   
announce its own IP address as the NEXT_HOP. When announcing a   
locally originated route to an internal peer, the BGP speaker
should use 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).

And stated the change would be made if there were no objections.  There
have been no objections, so this is at consensus.

----------------------------------------------------------------------------
62) Deprecate BGP Authentication Optional Parameter from RFC1771
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: We are at consensus, in that we agree that we should deprecate
  the BGP Authentication Optional Parameter as described in RFC1771 in
  favor of the mechanism described in RFC2385.  The textual changes are 
  listed at the end of the discussion section of this issue.

Discussion:

This discussion started in issue 21: Authentication Text Update.

This topic has come up before (July timeframe), but was recently refreshed
in the context of issue 21.  It began with some questions to the list
as to who used what sort of authentication mechanisms.  From the
responses it was clear that MD5 (RFC2385) was the prefered method.

Eric Gray's message helps to flesh this out:

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

To this Yakov responded:

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.

There have been no responses to Yakov's question.

There seems to be a consensus that, since it is little used, and since
there are better mechanisms, namely MD5 authentication, we should 
deprecate the BGP Authentication Optional Parameter from RFC1771.

Ok, after some disucssion, this is a list of the text that we are
adding, changing or removing:

1) Remove the reference to the authentication optional parameter:

I would suggest to remove the following text from the draft:

 This document defines the following Optional Parameters:

 a) Authentication Information (Parameter Type 1):


    This optional parameter may be used to authenticate a BGP
    peer. The Parameter Value field contains a 1-octet
    Authentication Code followed by a variable length
    Authentication Data.

	0 1 2 3 4 5 6 7 8   
	+-+-+-+-+-+-+-+-+
	|  Auth. Code   |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|                                                     |
	|              Authentication Data                    |
	|                                                     |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


       Authentication Code:

	  This 1-octet unsigned integer indicates the
	  authentication mechanism being used. Whenever an
	  authentication mechanism is specified for use within
	  BGP, three things must be included in the
	  specification:

	  - the value of the Authentication Code which indicates
	  use of the mechanism,
	  - the form and meaning of the Authentication Data, and
	  - the algorithm for computing values of Marker fields.

	  Note that a separate authentication mechanism may be
	  used in establishing the transport level connection.

       Authentication Data:

	  Authentication Data is a variable length field that is
	  interpreted according to the value of the   
	  Authentication Code field.

2) Update the introduction:

In section 2 (Introduction), sixth paragraph

From:

BGP runs over a reliable transport protocol. This eliminates the
need to implement explicit update fragmentation, retransmission,
acknowledgment, and sequencing. Any authentication scheme used by the
transport protocol (e.g., RFC2385 [10]) may be used in addition to
BGP's own authentication mechanisms. The error notification mechanism
used in BGP assumes that the transport protocol supports a "graceful"
close, i.e., that all outstanding data will be delivered before the
connection is closed.

To:

BGP uses TCP [RFC793] as its transport protocol. This eliminates
the need to implement explicit update fragmentation, retransmission,
acknowledgment, and sequencing. BGP listens on TCP port 179. Any
authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may be
used. The error notification mechanism used in BGP assumes that TCP
supports a "graceful" close, i.e., that all outstanding data will
be delivered before the connection is closed.   

3) Update the message header format section:

From:

Marker:

 This 16-octet field contains a value that the receiver of the
 message can predict.  If the Type of the message is OPEN, or if
 the OPEN message carries no Authentication Information (as an
 Optional Parameter), then the Marker must be all ones.
 Otherwise, the value of the marker can be predicted by some a
 computation specified as part of the authentication mechanism
 (which is specified as part of the Authentication Information)
 used.  The Marker can be used to detect loss of synchronization
 between a pair of BGP peers, and to authenticate incoming BGP
 messages.

To:

Marker:

 This 16-octet field is included for compatibility; it must be  
 set to all ones.

4) Update the Message Header error handling section:

In section 6.1 (Message Header error handling), second paragraph

From:

The expected value of the Marker field of the message header is all
ones if the message type is OPEN.  The expected value of the Marker
field for all other types of BGP messages determined based on the
presence of the Authentication Information Optional Parameter in the
BGP OPEN message and the actual authentication mechanism (if the  
Authentication Information in the BGP OPEN message is present). If
the Marker field of the message header is not the expected one, then
a synchronization error has occurred and the Error Subcode is set to
Connection Not Synchronized.

To:

The expected value of the Marker field of the message header is all
ones. If the Marker field of the message header is not as expected,
then a synchronization error has occurred and the Error Subcode is   
set to Connection Not Synchronized.

5) Remove a paragraph from the OPEN mesage error handling section
(section 6.2):

If the OPEN message carries Authentication Information (as an
Optional Parameter), then the corresponding authentication procedure 
is invoked.  If the authentication procedure (based on Authentication
Code and Authentication Data) fails, then the Error Subcode is set to
Authentication Failure.

6) Update the "Differences from RFC1771 Appendix" 

Text not listed here

7) Fix the hole in the numbering by updating:

From: 

This document defines the following Optional Parameters:

a) Authentication Information (Parameter Type 1):

To:

This document defines the following Optional Parameters:

a) Optional parameter type 1, Authentication Information, 
has been deprecated.

We are at consensus with these changes.

----------------------------------------------------------------------------
63) Clarify MED Removal Text
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Modify text to clear up MED removal behavior.  Text is at the
end of the discussion.

Discussion:

This discussion began when Jonathan posted a question to the list:

In reference to:

"A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
which allows the MULTI_EXIT_DISC attribute to be removed from a
route"

Does anybody know how this can be done in IOS???  Looks like it cannot.

Juniper???

Other code???

Change to "SHOULD"???

Enke responded that:

As the MED value is treated as zero when the MED attribute is missing,
removing the MED attribute is really equivalent to setting the value to
zero. Based on this logic, one can argue that "MED removal" is supported
by multiple vendors.

However, I do see that the current text can be consolidated and cleaned up:

------------------------
5.1.4 MULTI_EXIT_DISC

...

A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
which allows the MULTI_EXIT_DISC attribute to be removed from a
route. This MAY be done prior to determining the degree of preference
of the route and performing route selection (decision process phases
1 and 2).

An implementation MAY also (based on local configuration) alter the
value of the MULTI_EXIT_DISC attribute received over an external
link.  If it does so, it shall do so prior to determining the degree
of preference of the route and performing route selection (decision
process phases 1 and 2).

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

How about this:

A BGP speaker MUST implement a mechanism based on local configuration
which allows the value of MULTI_EXIT_DISC attribute of a received route  
to be altered. This shall be done prior to determining the degree of
preference of the route and performing route selection (decision process
phases 1 and 2).

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

In responding to a question, Enke also added:

> Humm. I thought with a missing MED it was prefereable to be treated as
> worst not as 0.

It was changed a long time ago. Please see the following text in
Sect. 9.1.2.2 of the draft:

In the pseudo-code above, MED(n) is a function which returns the
value of route n's MULTI_EXIT_DISC attribute. If route n has no
MULTI_EXIT_DISC attribute, the function returns the lowest
possible MULTI_EXIT_DISC value, i.e. 0.

Curtis replied to Enke:

If Juniper treats missing MULTI_EXIT_DISC as worst and Cisco has a
knob to treat missing MULTI_EXIT_DISC as worst, then IMHO we should
change the spec to say that MED(n) returns the largest value possible
is MULTI_EXIT_DISC is missing since this has better loop suppression
bahaviour if the placement of MULTI_EXIT_DISC removal is moved in its
position in the flow from Adj-In-RIB to Loc-RIB to Adj-Rib-Out.  In
other words, no matter where the removal takes place, we are loop free
without special rules about comparing EBGP before MED removal and then
IBGP after MED removal.  The only argument for MED(n) going to zero
for missing MULTI_EXIT_DISC was that Cisco routers did that (and
change would pose an operational issue if there wasn't a knob to
facilitate the change).

Note that when explicitly jamming a MULTI_EXIT_DISC value, such as
zero, the issue of where in the decision process the MULTI_EXIT_DISC
learned from the EBGP peers could still be used becomes a concern
again.  Unfortunately these implementation hints are necessary to 
remain loop free and so its hard to declare them out of scope, unless
we forbid changing MULTI_EXIT_DISC and just allow it to be removed
(which does not reflect current practice).

Curtis also added:

The other issue was MED handling.  In "5.1.4 MULTI_EXIT_DISC":

A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
which allows the MULTI_EXIT_DISC attribute to be removed from a
route. This MAY be done prior to determining the degree of preference
of the route and performing route selection (decision process phases
1 and 2).

An implementation MAY also (based on local configuration) alter the  
value of the MULTI_EXIT_DISC attribute received over an external  
link.  If it does so, it shall do so prior to determining the degree 
of preference of the route and performing route selection (decision 
process phases 1 and 2).

This doesn't sufficiently address the issue.

The MED step in the decision process is (in 9.1.2.2):

c) Remove from consideration routes with less-preferred
MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
between routes learned from the same neighboring AS. Routes which
do not have the MULTI_EXIT_DISC attribute are considered to have
the lowest possible MULTI_EXIT_DISC value.

This is also described in the following procedure:

    for m = all routes still under consideration
	for n = all routes still under consideration
	    if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
		remove route m from consideration

In the pseudo-code above, MED(n) is a function which returns the
value of route n's MULTI_EXIT_DISC attribute. If route n has no
MULTI_EXIT_DISC attribute, the function returns the lowest
possible MULTI_EXIT_DISC value, i.e. 0.

Similarly, neighborAS(n) is a function which returns the neighbor
AS from which the route was received.

The problem is that a route loop can be formed.

To avoid the route loop, two suggestions were made (2-3 years ago and   
nothing was done).  One was to make MED(n) return infinity if there  
was no MULTI_EXIT_DISC.  The other was to consider MULTI_EXIT_DISC in   
the decision process only for the purpose of selecting among the EBGP  
peers, then remove MULTI_EXIT_DISC, then use that best route in
comparisons to IBGP learned routes.

The statement in 5.1.4 "This MAY be done prior to determining the
degree of preference of the route and performing route selection
(decision process phases 1 and 2)" does not sufficiently address this.
This implies that you MAY also remove after route selection, in which
case field experience indicates you WILL get burned (unless you know
about the caveat above).  Initially this came up as an
interoperability issue but later it was proven (in the field) that a  
Cisco and another Cisco could form a route loop until Cisco made this
change.

Additional wording is needed either in 5.1.4 or in 9.1.2.2.  I suggest
we put a forward reference in 5.1.4:

[...]. This MAY be done prior to determining the degree of preference
of the route and performing route selection (decision process phases
1 and 2).  See section 9.1.2.2 for necessary restricts on this.

Then in 9.1.2.2 add a clarificatio to the neighborAS(n) function and 
add to the existing text.

Similarly, neighborAS(n) is a function which returns the
neighbor AS from which the route was received.  If the route is  
learned via IBGP, it is the neighbor AS from which the other
IBGP speaker learned the route, not the internal AS.

If a MULTI_EXIT_DISC attribute is removed before redistributing
a route into IBGP, the MULTI_EXIT_DISC attribute may only be      
considered in the comparison of EBGP learned routes, them
removed, then the remaining EBGP learned route may be compared    
to the remaining IBGP learned routes, without considering the    
MULTI_EXIT_DISC attribute for those EBGP learned routes whose
MULTI_EXIT_DISC will be dropped before advertising to IBGP.
Including the MULTI_EXIT_DISC of an EBGP learned route in the
comparison with an IBGP learned route, then dropping the
MULTI_EXIT_DISC and advertising the route has been proven to
cause route loops.

The loop is the classic I prefer your and you prefer mine problem.  It
occurs when the router is configured to remove MULTI_EXIT_DISC and
advertise out a route so other routers can use IGP cost to select the 
best route.  If two routers do this, as soon as they hear the route  
with no MULTI_EXIT_DISC from the other peer they start forwarding
toward that peer but they continue to advertise to it since others
IBPG peers are expected to select among the MULTI_EXIT_DISC free IBGP 
learned routes using the next step in the decision process, IGP cost.

In this case, what you want is each router to prefer its own EBGP
route, even though it has a MULTI_EXIT_DISC and the IBGP learned route 
from the same neighbor AS has had its MULTI_EXIT_DISC stripped off (or
didn't have one, you can't tell which it is).  You then want all of
the IBGP peers with a MULTI_EXIT_DISC free route from that AS, or that
have stripped the MULTI_EXIT_DISC to form one, to advertise them.
Others in the AS will then use IGP cost to further resolve which exit
point to use.  It make a difference when the route is the aggregate
route of another major provider.  IGP cost yields what ISPs call "hot  
potatoe routing" and MED selects among multiple heavily loaded
provider interconnects.

[Aside: Having a missing MULTI_EXIT_DISC default to infinity would do
exactly what the ISPs want it to do in the first place and be a lot     
easier to explain but we didn't fix that 2-3 years ago when the issue
came up even though we had WG consensus that it was the right thing to  
do.  The authors didn't act on it at the time (because Cisco didn't do 
it that way and the authors preferred to sit on the draft).  At this
point we might as well adequately document what we ended up with....
End of soapbox.  I don't take myself all that seriously so others  
shouldn't either.  :-)]

After some more discussion on this, we have this text:

In 5.1.4 replace:

An implementation MAY also (based on local configuration) alter the
value of the MULTI_EXIT_DISC attribute received over EBGP.
If it does so, it shall do so prior to determining the degree of
preference of the route and performing route selection (decision
process phases 1 and 2).

with:

An implementation MAY also (based on local configuration) alter the
value of the MULTI_EXIT_DISC attribute received over EBGP.
This MAY be done prior to determining the degree of preference
of the route and performing route selection (decision process phases
1 and 2). See section 9.1.2.2 for necessary restricts on this.

In 9.1.2.2 replace:

Similarly, neighborAS(n) is a function which returns the neighbor
AS from which the route was received.

with:

Similarly, neighborAS(n) is a function which returns the neighbor
AS from which the route was received.  If the route is learned
via IBGP, and the other IBGP speaker didn't originate the route,
it is the neighbor AS from which the other IBGP speaker learned
the route. If the route is learned via IBGP, and the other IBGP
speaker originated the route, it is the local AS.

If a MULTI_EXIT_DISC attribute is removed before re-advertising  
a route into IBGP, the MULTI_EXIT_DISC attribute may only be
considered in the comparison of EBGP learned routes, then
removed, then the remaining EBGP learned route may be compared
to the remaining IBGP learned routes, without considering the
MULTI_EXIT_DISC attribute for those EBGP learned routes whose
MULTI_EXIT_DISC will be dropped before advertising to IBGP.
Including the MULTI_EXIT_DISC of an EBGP learned route in the   
comparison with an IBGP learned route, then dropping the
MULTI_EXIT_DISC and advertising the route has been proven to
cause route loops.

There have been no objections to this, so we are at consensus.

----------------------------------------------------------------------------
64) MED for Originated Routes
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: The consensus is that there is not need to specify default
values for MED in the base draft.

Discussion:

This issue began when it was pointed out that we do not specify the
default values for MED in the base draft.

There were a variety of responses, but the consensus is that since 
this is not relevant for interoperability, this does not need to be
in the base spec.

----------------------------------------------------------------------------
65) Rules for Aggregating with MED and NEXT_HOP
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Clear up the text on aggregating with a MED.  See the discussion
for the text.

Discussion:

There is a proposal to relax this statement:

"Routes that have the following attributes shall not be aggregated
unless the corresponding attributes of each route are identical:
MULTI_EXIT_DISC, NEXT_HOP."

In his reply to the original mail, Curtis asserted that we should leave
the MED rules alone, but perhaps we could relax the NEXT_HOP statement.

This was revisited in the "aggregating with MED and NEXT_HOP" thread.

Yakov suggested we replace:

Routes that have the following attributes shall not be aggregated
unless the corresponding attributes of each route are identical:
MULTI_EXIT_DISC, NEXT_HOP.

If the aggregation occurs as part of the update process, routes with
different NEXT_HOP values can be aggregated when announced through an
external BGP session.

Path attributes that have different type codes can not be aggregated
together. Path attributes of the same type code may be aggregated,
according to the following rules:

with:

Routes that have different MULTI_EXIT_DISC attribute SHALL NOT
be aggregated.

Path attributes that have different type codes can not be aggregated
together. Path attributes of the same type code may be aggregated,
according to the following rules:

NEXT_HOP: When aggregating routes that have different NEXT_HOP
attribute, the NEXT_HOP attribute of the aggregated route SHALL
identify an interface on the router that performs the aggregation.

This met with agreement.

Dimitry asked if the "Routes that have different MULTI_EXIT_DESC attribute
SHALL NOT be aggregated." sentance was unnecessary since it should be a
matter of local policy.  Jeff replied that it has been mentioned that
removing this stipulation can cause routing loops.

We are at consensus with this issue.

----------------------------------------------------------------------------
66) Complex AS Path Aggregating
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Since we have two implementations of this method, secion 6.8 stays
in the specification.

Discussion:

Jonathan opened this discussion with:

The part in the draft about complex AS path aggregation could/should be
deleted.  The current draft implies that when aggregating, for example
(1st):

1 2 4 3

w/

3 4 6 5

and

5 6 7 8

then

1 2 {3 4 5 6} 7 8

...would be OK

AFAIK, all implementations aggregate by either: (2nd)putting ONLY the local
AS in the path (and setting the atomic) OR (3rd)by creating 1 giant set and
adding the local AS as a seq.

So he proposed we remove this to reflect current code.

Jeff replied that there is absolutely nothing wrong with doing complex
aggregation, and there is no reason to remove this from the specification.

Yakov responded that:

Jonathan is certainly correct that the spec has to reflect current
code.  Therefore, unless there are at least two (interoperable)
implementations that implement the algorithm described in "6.8
Complex AS_PATH aggregation", this section has to be removed (this
is irrespective of whether there is something wrong, or nothing
wrong with complex aggregation). With this in mind, if you implement
this algorithm please speak up within a week.  If within a week we
wouldn't know that there are at least two implementations the
section will be removed. And likewise, if we hear that there are
at least two implementations, the section will stay.

Jeff replied:

I am also fine with removing it.  I just don't think its necessary,
especially if One Of These Days someone decides that running policy
based on as-adjacencies would be a Nice Thing and fixes their
implementation to support "complex" aggregation of paths.

That said, I am aware of no one who implements this.

As an aside, in the thread "last thought on complex aggregation" Jeff
supplied:

I finally remembered what was bothering me about removing complex
aggregation from the spec.

If it is removed, people who do conformance tests and some implementations
may take this to mean "it shall be illegal to have an AS_PATH that
contains a SEQUENCE of a particular type after a SET".

This would make a perfectly ok AS_PATH into one that isn't legal, even
if no implementation currently generates it.

Jonathan replied that he thought the issue was moot since no one has 
implemented this.

John replied that, although he is a bit uncomfortable in removing this
from the spec, he doesn't see any harm in doing so.

With this in mind, Yakov suggested we consider the issue closed. 

So we will wait a week from 10/17 to see if anyone chimes in.

Siva responded that they have implemented this functionality.  So we
need one more...Ben responded that they support this at Marconi as well.

So we have two implementations, the section stays in the spec.  We are
at consensus with this issue.

----------------------------------------------------------------------------
67) Counting AS_SET/AS_CONFED_*
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Move how AS_CONFED_SET & SEQUENCE affect route selection to the
BGP Confederations document.   Update the base draft to reflect this
by changing section 9.1.2.2.  Specific text is at the end of the
discussion.

Discussion:

Jonathan brought up some questions on how current implementations count
AS_SET and AS_CONFED_*

There were a variety of resposnes to this, answering his questions.
Curtis pointed out that this behavior is covered in:

That's in 9.1.2.2:

a) Remove from consideration all routes which are not tied for
having the smallest number of AS numbers present in their AS_PATH
attributes. Note, that when counting this number, an AS_SET counts
as 1, no matter how many ASs are in the set, and that, if the
implementation supports [13], then AS numbers present in segments
of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in
the count of AS numbers present in the AS_PATH.

Jonathan replied that this might be at odds with what Juniper does,
although he was unsure, and asked for clarification.

This was discussed in the "New Issue AS path" thread.

Yakov proposed that:

The issue of route selection in the present of confederations
belongs *not* to the base spec, but to the spec that describes
BGP Confeds. With this in mind I would suggest to change in 9.1.2.2 from

a) Remove from consideration all routes which are not tied for
having the smallest number of AS numbers present in their AS_PATH
attributes. Note, that when counting this number, an AS_SET counts
as 1, no matter how many ASs are in the set, and that, if the
implementation supports [13], then AS numbers present in segments
of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in
the count of AS numbers present in the AS_PATH.
to

a) Remove from consideration all routes which are not tied for
having the smallest number of AS numbers present in their AS_PATH
attributes. Note, that when counting this number, an AS_SET counts
as 1, no matter how many ASs are in the set.

and ask the authors of BGP Confeds to update their document to
cover how the presence of confeds impact route selection.

This met with agreement, this issue is at conensus.

----------------------------------------------------------------------------
68) Outbound Loop Detection
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: The consensus is, that while this may be a useful technique, it
  would break existing methods, and is otherwise out-of-scope for the
  base draft.  It was suggested that this could be addressed in the
  update to RFC1772.
 
Discussion:

Jonathan brought up that:

This paper (thanks Jeff)
http://www.research.microsoft.com/scripts/pubs/view.asp?TR_ID=MSR-TR-2000-08
indicates that it
is better to do the loop detection outbound as well inbound.  The current
draft indicates that
it only needs to be done inbound.  IOS does it inbound as well as outbound.
GateD/Juniper
does it (did it ???) only inbound.

So I propose we add:
"An implementation MAY choose to not advertise routes to EBGP peers if these
routes contain
the AS of that peer in the AS path."
after:
"If the autonomous system number appears in the AS path the route may be
stored in the
Adj-RIB In, but unless the router is configured to accept routes with its
own AS in the
AS path, the route shall not be passed to the BGP Decision Process."

*If there is at least one other implementation that does outbound
pruning/loop-detection.*

Yakov pointed out that this is ONLY applicable to the base draft if there
are multiple implementations doing this.  This issue will only be 
considered if these implementors come forward by 10/25/02.  Otherwise
the issue will be considered closed.

Jeff replied that there was more at stake with this than if people had
implemented it:

 My suggestion is that this can stay out of the base draft.  While it
 is true that this speeds up convergence (per the paper), it doesn't
 affect interoperability.

 Also, adding this specifically removes the ability from several
 implementations to be able to bridge a partitioned AS by permitting
 loops.  (I'm not going to argue whether this is a Good way to do this,
 just that its done.)

 Its also worth noting that one could produce the same resultant speed-up
 by detecting the loop on an outbound basis and *not* applying the
 min*timers to the UPDATE.  Thus, this would be a case of an advertisement
 of NLRI being treated the same, timer-wise, as the advertisement of
 WD_NLRI.

 I would suggest moving this suggestion for outbound loop detection
 in one form or another to the 1772 replacement.

Yakov agreed with this.

============================================================================
Appendix A - Other Documents
============================================================================

Over the course of this discussion, a number of issues have been raised
that the group though would be better dealt with in other documents.
These additional documents, and their concomitant issues will be more
fully addressed when the WG turns its focus to them.  These projects are:

1) Update RFC 1772: Application of the Border Gateway Protocol in the Internet.
   This will probably entail a complete rewrite.
2) Update Route Reflector (2796) and Confederation (3065) RFC's regarding their
   impact on route selection.
3) Write a new document covering BGP Multipath.

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

CHANGELOG

----------------------------------------------------------------------------
v1.4 to v1.5
2002-10-28
----------------------------------------------------------------------------

Updated:

11) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1
32) Clarify EGP Reference
39) Redundant Sentance Fragments
45) Consistant References to BGP Peers/Connections/Sessions
46) FSM Connection Collision Detection
48) Explicitly Define Processing of Incomming Connections
53) Section 4.3 - Routes v. Destinations - Advertise
68) Outbound Loop Detection

Moved to Consensus:

11) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1
32) Clarify EGP Reference
39) Redundant Sentance Fragments
45) Consistant References to BGP Peers/Connections/Sessions
46) FSM Connection Collision Detection
48) Explicitly Define Processing of Incomming Connections
53) Section 4.3 - Routes v. Destinations - Advertise
68) Outbound Loop Detection

Minor Editorial Fixes:

19) Appendix Section 6.2: Processing Messages on a Stream Protocol
22) Scope of Path Attribute Field
34) Timer & Counter Definition
42) Delete the FSM Section
60) Section 4.3 - Path Attributes

----------------------------------------------------------------------------
v1.3 to v1.4
2002-10-22
----------------------------------------------------------------------------

Added:

Appendix A - Other Documents
68) Outbound Loop Detection

Updated:

8) Jitter Text
11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
11.3) Documenting IBGP Multipath
32.1) EGP ORIGIN Clarification
58) Deprication of ATOMIC_AGGREGATE
61) Next Hop for Redistributed Routes
63) Clarify MED Removal Text
65) Rules for Aggregating with MED and NEXT_HOP 
66) Complex AS Path Aggregating
67) Counting AS_SET/AS_CONFED_*

Moved to Consensus:

8) Jitter Text
11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
11.3) Documenting IBGP Multipath
32.1) EGP ORIGIN Clarification
58) Deprication of ATOMIC_AGGREGATE
61) Next Hop for Redistributed Routes
63) Clarify MED Removal Text
65) Rules for Aggregating with MED and NEXT_HOP
66) Complex AS Path Aggregating
67) Counting AS_SET/AS_CONFED_*

----------------------------------------------------------------------------
v1.2 to v1.3
2002-10-16
----------------------------------------------------------------------------

Added:

64) MED for Originated Routes
65) Rules for Aggregating with MED and NEXT_HOP
66) Complex AS Path Aggregating
67) Counting AS_SET/AS_CONFED_*
List of issues that are NOT at consensus

Updated:

8) Jitter Text
10) Extending AS_PATH Attribute
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
19) Appendix Section 6.2: Processing Messages on a Stream Protocol
32.1) EGP ORIGIN Clarification
34) Timer & Counter Definition
37) Combine "Unfeasible Routes" and "Withdrawn Routes"
41) Mention FSM Internal Timers
47) FSM - Add Explicit State Change Wording
49) Explicity Define Event Generation
62) Deprecate BGP Authentication Optional Parameter from RFC1771

Moved FROM Consensus:

11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2

Moved to Consensus:

10) Extending AS_PATH Attribute
19) Appendix Section 6.2: Processing Messages on a Stream Protocol
34) Timer & Counter Definition
37) Combine "Unfeasible Routes" and "Withdrawn Routes"
41) Mention FSM Internal Timers
47) FSM - Add Explicit State Change Wording
49) Explicity Define Event Generation
62) Deprecate BGP Authentication Optional Parameter from RFC1771

----------------------------------------------------------------------------
v1.2 to v1.2.1
2002-10-01
----------------------------------------------------------------------------

Updated:

11.3) Documenting IBGP Multipath
24) Addition or Deletion of Path Attributes
63) Clarify MED Removal Text
TOC) Added issues 62 and 63 to the table of contents.

Moved to Consensus:
24) Addition or Deletion of Path Attributes

----------------------------------------------------------------------------
v1.1.1 to v1.2
2002-10-01
----------------------------------------------------------------------------

Added:
11.3) Documenting IBGP Multipath
62) Deprecate BGP Authentication Optional Parameter from RFC1771
63) Clarify MED Removal Text

Updated:

1) IDR WG Charter
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
13) Next Hop for Originated Route
14) NEXT_HOP to Internal Peer
17) Add References to other RFC-status BGP docs to base spec.
21) Authentication Text Update
22) Scope of Path Attribute Field
24) Addition or Deletion of Path Attributes
27) Allow All Non-Destructive Messages to Refresh Hold Timer
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
36) Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary
37) Combine "Unfeasable Routes" and "Withdrawn Routes"
39) Redundant Sentance Fragments
40) Section 9.2.1.1 - Per Peer vs. Per Router MinRouteAdvertisementInterval
44) Section 6.2: OPEN message error handling
48) Explicitly Define Processing of Incomming Connections
55) Section 4.3 - Description of AS_PATH length
56) Section 6 - BGP Error Handling
58) Deprication of ATOMIC_AGGREGATE
59) Section 4.3 - Move text
61) Next Hop for Redistributed Routes
62) Deprecate BGP Authentication Optional Parameter from RFC1771
63) Clarify MED Removal Text

Moved to Consensus:

9) Reference to RFC904 - EGP Protocol
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
14) NEXT_HOP to Internal Peer (closed in favor of issue 61)
17) Add References to other RFC-status BGP docs to base spec.
21) Authentication Text Update
22) Scope of Path Attribute Field
27) Allow All Non-Destructive Messages to Refresh Hold Timer
29) State Why Unresolveable Routes Should Be Kept in Adj-RIB-In
30) Mention Other Message Types
31) Add References to Additional Options
32.2) BGP Desitnation-based Forwarding Paradigm
33) Add "Optional Non-Transitive" to the MED Section
36) Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary
44) Section 6.2: OPEN message error handling
55) Section 4.3 - Description of AS_PATH length
56) Section 6 - BGP Error Handling
59) Section 4.3 - Move text

----------------------------------------------------------------------------
v1.1 to v1.1.1
2002-09-24
----------------------------------------------------------------------------

Updated:

5) Direct EBGP Peers
   Added the "consensus" line in the actual issue description.
TOC) Added issue 61 to the table-of-contents.

----------------------------------------------------------------------------
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 Sectioules for Aggregating with MED and NEXT_HOP


--qDbXVdCdHGoSgWSk--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA11923 for <[e-mail]>; Mon, 28 Oct 2002 11:34:34 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id BE22091242; Mon, 28 Oct 2002 11:34:03 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DD8491243; Mon, 28 Oct 2002 11:34:03 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7599E91242 for <[e-mail]>; Mon, 28 Oct 2002 11:34:02 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 513FE5DE11; Mon, 28 Oct 2002 11:34:02 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id CCD0D5DE0C for <[e-mail]>; Mon, 28 Oct 2002 11:34:01 -0500 (EST)
Received: by sentry.gw.tislabs.com; id LAA18607; Mon, 28 Oct 2002 11:34:02 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma018593; Mon, 28 Oct 02 11:33:17 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g9SGXFC13728; Mon, 28 Oct 2002 11:33:15 -0500 (EST)
Date: Mon, 28 Oct 2002 11:33:15 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: Re: draft-murphy-bgp-vuln-01.txt (was Re: draft-murphy-bgp-vuln-02.txt)
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

About the version numbers....

The internet-draft people contacted me to say that a resubmission of an
expired draft gets the next number after the expired draft, not the 
next number after the notice of the expired draft.  So instead of being
published as a -02, this will be published as a -01.  They asked me to
send them a revised version, which I did.

I can see this will cause confusion when (if) we get to a -02 version again
and people look in the archive.  But I exist only to obey the will of
the secretariat.

--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 LAA11486 for <[e-mail]>; Mon, 28 Oct 2002 11:25:36 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id 02BCD91241; Mon, 28 Oct 2002 11:24:59 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C071091242; Mon, 28 Oct 2002 11:24:58 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B46E591241 for <[e-mail]>; Mon, 28 Oct 2002 11:24:57 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 9B8725DE1C; Mon, 28 Oct 2002 11:24:57 -0500 (EST)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 266BB5DE11 for <[e-mail]>; Mon, 28 Oct 2002 11:24:57 -0500 (EST)
Received: by sentry.gw.tislabs.com; id LAA18371; Mon, 28 Oct 2002 11:24:57 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma018357; Mon, 28 Oct 02 11:24:51 -0500
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g9SGOnM13291; Mon, 28 Oct 2002 11:24:49 -0500 (EST)
Date: Mon, 28 Oct 2002 11:24:49 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: Re: draft-murphy-bgp-vuln-02.txt
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

>I have one issue with the current draft:

Gee, only ONE!!!!  I declare success.  :-)

>I recommend replacing what is below with what follows it:

This was a resubmission of the old version of the draft, which is almost
certainly seriously out of date, given the number of changes under
consideration for the -18 version of the base spec.  But (a) the -18 version
has not been published (and I pale at the prospect of trying to piece it
together from the various discussions that have reached consensus) and (b)
the intent was to get the document out real fast.

So there are bound to be lots of wording changes, based on the changes
in the base spec.

--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 KAA09811 for <[e-mail]>; Mon, 28 Oct 2002 10:54:43 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id AB73B9123F; Mon, 28 Oct 2002 10:54:23 -0500 (EST)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B49591240; Mon, 28 Oct 2002 10:54:23 -0500 (EST)
Delivered-To: [e-mail]
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 302C59123F for <[e-mail]>; Mon, 28 Oct 2002 10:54:22 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 1C9F65DDF5; Mon, 28 Oct 2002 10:54:22 -0500 (EST)
Delivered-To: [e-mail]
Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by segue.merit.edu (Postfix) with ESMTP id CCCC05DDCC for <[e-mail]>; Mon, 28 Oct 2002 10:54:21 -0500 (EST)
Received: from cmr2.ash.ops.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP  (peer crosschecked as: localhost [127.0.0.1]) id QQnmnv07283 for <[e-mail]>; Mon, 28 Oct 2002 15:54:21 GMT
Received: from csserve0.corp.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP  (peer crosschecked as: csserve0.corp.us.uu.net [153.39.88.140]) id QQnmnv07275; Mon, 28 Oct 2002 15:54:20 GMT
Received: from localhost by csserve0.corp.us.uu.net with ESMTP  (peer crosschecked as: dbarak@localhost) id QQnmnv01090; Mon, 28 Oct 2002 10:54:20 -0500 (EST)
Date: Mon, 28 Oct 2002 10:54:20 -0500 (EST)
From: David Barak <[e-mail]>
X-Sender: [e-mail]
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: draft-murphy-bgp-vuln-02.txt
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

I have one issue with the current draft:

I recommend replacing what is below with what follows it:

>ORIGIN

>This field indicates whether the information was learned from IGP or EGP
>information.  If the route is used in inter-AS multicast routing, a
>value of INCOMPLETE may be used.  This field is not used in making
>routing decisions, so there are no vulnerabilities arising from this
>field, either from BGP peers or outsiders.

ORIGIN

This field indicates whether the information was learned via the EGP
Protocol [6], by manual insertion into the BGP table, or learned by some
other means.  This field is used in routing decisions, although not
widely.  This field is subject to manipulation, but the net effect of said
manipulation would be subtle.

[6] RFC 904, EGP is now depricated.

David Barak
WorldCom
Voice: [phone]
Fax: [phone]

"Quis custodes ipsos custodiet?" - Juvenal
=====   Fully RFC 1925 compliant   =====




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA03587 for <[e-mail]>; Fri, 25 Oct 2002 17:39:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9E3199131A; Fri, 25 Oct 2002 17:38:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3093491325; Fri, 25 Oct 2002 17: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 C438B9131A for <[e-mail]>; Fri, 25 Oct 2002 17:38:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id AFCF95DF69; Fri, 25 Oct 2002 17:38:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (unknown [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 6C3315DF60 for <[e-mail]>; Fri, 25 Oct 2002 17:38:40 -0400 (EDT)
Received: by sentry.gw.tislabs.com; id RAA18083; Fri, 25 Oct 2002 17:38:40 -0400 (EDT)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma018072; Fri, 25 Oct 02 21:38:22 GMT
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g9PLcLJ26557; Fri, 25 Oct 2002 17:38:21 -0400 (EDT)
Date: Fri, 25 Oct 2002 17:38:21 -0400 (EDT)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: RE: draft-murphy-bgp-vuln-02.txt
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

> I thought this will become a rpsec submission..

No.  See the minutes from the last IETF idr meeting.  David Ward
sent the minutes to the list on July 18.  (Archived at 
http://www.merit.edu/mail.archives/idr/2002-07/msg00140.html)

>        10. Murphy's vulnerability draft to be IDR WG item
>
>        11. Murphy's protection mechanisms to be RPSec WG item


--Sandy

P.S.  Neither the vulnerabilities draft nor the protections draft
could become an rpsec submission, by how I understand the rpsec work.
See the rpsec charter at http://www.ietf.org/html.charters/rpsec-charter.html:
"It is also a non-goal at this point to produce new or change the current
security mechanisms in the existing routing protocols."  What Alex had
said (if I remember correctly) was that the protections draft would have
to wait until the rpsec group established the security requirements.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA24806 for <[e-mail]>; Fri, 25 Oct 2002 15:01:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CBE1A91319; Fri, 25 Oct 2002 14:59:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C3979131A; Fri, 25 Oct 2002 14:59: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 589CC91319 for <[e-mail]>; Fri, 25 Oct 2002 14:59:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 401975DDB0; Fri, 25 Oct 2002 14:59:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (unknown [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 989A95DF4F for <[e-mail]>; Fri, 25 Oct 2002 14:59:26 -0400 (EDT)
Received: by sentry.gw.tislabs.com; id OAA14533; Fri, 25 Oct 2002 14:59:26 -0400 (EDT)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma014523; Fri, 25 Oct 02 18:59:02 GMT
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g9PIx1j20343; Fri, 25 Oct 2002 14:59:01 -0400 (EDT)
Date: Fri, 25 Oct 2002 14:59:01 -0400 (EDT)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: draft-murphy-bgp-vuln-02.txt
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk

Network Working Group                                      Sandra Murphy
INTERNET DRAFT                                                  NAI Labs
draft-murphy-bgp-vuln-02.txt                                October 2002


                 BGP Security Vulnerabilities Analysis



Status of this Memo

This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC2026.

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

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

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

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

Abstract

BGP, along with a host of other infrastructure protocols designed before
the Internet environment became perilous, is designed with little
consideration for protection of the information it carries.  There are
no mechanisms in BGP to protect against attacks that modify, delete,
forge, or replay data, any of which has the potential to disrupt overall
network routing behavior.

This internet draft discusses some of the security issues with BGP
routing data dissemination.  A companion work, [5], discusses possible
security solutions and the costs of those solutions.  This internet
draft does not discuss security issues with forwarding of packets.








Murphy                     Expires: April 2003                  [Page 1]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis     October 2002


Table of Contents


 Status of this Memo ..............................................    1
 Abstract .........................................................    1
1 Introduction ....................................................    3
2 Vulnerabilities and Risks .......................................    5
2.1 OPEN ..........................................................    5
2.2 KEEPALIVE .....................................................    6
2.3 NOTIFICATION ..................................................    6
2.4 UPDATE ........................................................    6
2.4.1 Unfeasible Routes Length, Total Path Attribute Length .......    6
2.4.2 Withdrawn Routes ............................................    6
2.4.3 Path Attributes .............................................    7
 Attribute Flags, Attribute Type Codes, Attribute Length ..........    7
 ORIGIN ...........................................................    7
 AS_PATH ..........................................................    7
 Originating Routes ...............................................    8
 NEXT_HOP .........................................................    9
 MULTI_EXIT_DISC ..................................................    9
 LOCAL_PREF .......................................................    9
 ATOMIC_AGGREGATE .................................................    9
 AGGREGATOR .......................................................   10
2.4.4 NLRI ........................................................   10
2.5 BGP Extensions ................................................   10
2.5.1 Communities .................................................   10
2.5.2 Confederations ..............................................   11
3 Security Considerations .........................................   11
4 References ......................................................   11
5 Author's Address ................................................   12




















Murphy                     Expires: April 2003                  [Page 2]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis     October 2002


1.  Introduction

The inter-domain routing protocol BGP was created when the Internet
environment had not yet reached the present contentious state.
Consequently, the BGP protocol was not designed with protection against
deliberate or accidental errors causing disruptions of routing behavior.

We here discuss the vulnerabilities of BGP, based on the BGP RFC [1] and
on [2].  Readers are expected to be familiar with the BGP RFC and the
behavior of BGP.  A companion work, [5], proposes several different
security solutions to protect these vulnerabilities and discuss the
benefits derived from each solution and its cost.

It is clear that the Internet is vulnerable to attack through its
routing protocols and BGP is no exception.  Faulty, misconfigured or
deliberately malicious sources can disrupt overall Internet behavior by
injecting bogus routing information into the BGP distributed routing
database (by modifying, forging, or replaying BGP packets).  The same
methods can also be used to disrupt local and overall network behavior
by breaking the distributed communication of information between BGP
peers.  The sources of bogus information can be either outsiders or true
BGP peers.

Under the present BGP design, cryptographic authentication of the peer-
peer communication is not mandated.  As a TCP/IP protocol, BGP is
subject to all the TCP/IP attacks, like IP spoofing, session stealing,
etc.  Any outsider can inject believable BGP messages into the
communication between BGP peers and thereby inject bogus routing
information or break the peer to peer connection.  Any break in the peer
to peer communication has a ripple effect on routing that can be wide
spread.  Furthermore, outsider sources can also disrupt communications
between BGP peers by breaking their TCP connection with spoofed RST
packets.  Outsider sources of bogus BGP information can reside anywhere
in the world.

BGP speakers themselves can inject bogus routing information, either by
masquerading as information from any other legitimate BGP speaker, or by
distributing unauthentic routing information as themselves.
Historically, misconfigured and faulty routers have been responsible for
widespread disruptions in the Internet.

Bogus routing information can have many different effects on routing
behavior.  If the bogus information removes routing information for a
particular network, that network can become unreachable for the portion
of the Internet that accepts the bogus information.  If the bogus





Murphy                     Expires: April 2003                  [Page 3]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis     October 2002


information changes the route to a network, then packets destined for
that network may be forwarded by a sub-optimal path, or a path that does
not follow the expected policy, or a path that will not forward the
traffic.  As a consequence, traffic to that network could be delayed by
a longer than necessary path.  The network could become unreachable from
areas where the bogus information is accepted.  Traffic might also be
forwarded along a path that permits some adversary a view of the data.
If the bogus information makes it appear that an autonomous system
originates a network when it does not, then packets for that network may
not be deliverable for the portion of the Internet that accepts the
bogus information.  A false announcement that an autonomous systems
originates a network may also fragment aggregated address blocks in
other parts of the Internet and cause routing problems for other
networks.

The damage that might result from these attacks are:

     starvation: data traffic destined for a node is forwarded to a part
     of the network that cannot deliver it,

     network congestion: more data traffic is forwarded through some
     portion of the network than would otherwise need to carry the
     traffic,

     blackhole: large amounts of traffic are directed to be forwarded
     through one router that cannot handle the increased level of
     traffic and drops many/most/all packets,

     delay: data traffic destined for a node is forwarded along a path
     that is in some way inferior to the path it would otherwise take,

     looping: data traffic is forwarded along a path that loops, so that
     the data is never delivered,

     eavesdrop: data traffic is forwarded through some router or network
     that would otherwise not see the traffic, affording an opportunity
     to see the data,

     partition: some portion of the network believes that it is
     partitioned from the rest of the network when it is not,

     cut: some portion of the network believes that it has no route to
     some network that is in fact connected,







Murphy                     Expires: April 2003                  [Page 4]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis     October 2002


     churn: the forwarding in the network changes at a rapid pace,
     resulting in large variations in the data delivery patterns (and
     adversely affecting congestion control techniques),

     instability: BGP become unstable so that convergence on a global
     forwarding state is not achieved, and

     overload: the BGP messages themselves become a significant portion
     of the traffic the network carries.

2.  Vulnerabilities and Risks

The risks in BGP arise from three fundamental vulnerabilities:

     no mechanism has been mandated that provides strong protection of
     the integrity, freshness and source authenticity of the messages in
     peer-peer BGP communications.

     no mechanism has been specified to validate the authority of an AS
     to announce NLRI information.

     no mechanism has been specified to ensure the authenticity of the
     AS_PATH announced by an AS.

There are four different BGP message types - OPEN, KEEPALIVE,
NOTIFICATION, and UPDATE.  This section contains a discussion of the
vulnerabilities arising from each message and the ability of outsiders
or BGP peers to exploit the vulnerabilities.  To summarize, outsiders
can use bogus OPEN, KEEPALIVE, or NOTIFICATION messages to disrupt the
BGP peer-peer connections and can use bogus UPDATE messages to disrupt
routing.  Outsiders can also disrupt BGP peer-peer connections by
inserting bogus TCP RST packets.  BGP peers themselves are permitted to
break peer-peer connections at any time, and so they cannot be said to
be issuing "bogus" OPEN, KEEPALIVE or NOTIFICATION messages.  However,
BGP peers can disrupt routing by issuing bogus UPDATE messages.  In
particular, bogus ATOMIC_AGGREGATE and AS_PATH attributes and bogus NLRI
in UPDATE messages can disrupt routing.

Each message introduces certain different vulnerabilities and risks.

2.1.  OPEN

Because receipt of a new OPEN message in the Established state will
cause the close of the BGP peering session and thereby induce the
release of all resources and deletion of all associated routes, the





Murphy                     Expires: April 2003                  [Page 5]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis     October 2002


ability to spoof this message can lead to a severe disruption of
routing.

2.2.  KEEPALIVE

Receipt of a KEEPALIVE message when the peering connection is in the
OpenSent state can lead to a failure to establish a connection.  The
ability to spoof this message is a vulnerability.  To exploit this
vulnerability deliberately, the KEEPALIVE must be carefully timed in the
sequence of messages exchanged between the peers; otherwise, it causes
no damage.

2.3.  NOTIFICATION

Receipt of a NOTIFICATION message will cause the close of the BGP
peering session and thereby induce the release of all resources and
deletion of all associated routes.  Therefore, the ability to spoof this
message can lead to a severe disruption of routing.

2.4.  UPDATE

The Update message carries the routing information.  The ability to
spoof any part of this message can lead to a disruption of routing.

2.4.1.  Unfeasible Routes Length, Total Path Attribute Length

There is a vulnerability arising from the ability to modify these
fields.  If a length is modified, the message is not likely to parse
properly, resulting in an error, the transmission of a NOTIFICATION
message and the close of the connection.  As a true BGP speaker is
always able to close a connection at any time, this vulnerability
represents an additional risk only when the source is a non-BGP speaker,
i.e., it presents no additional risk from BGP sources.

2.4.2.  Withdrawn Routes

An outsider could cause the elimination of existing legitimate routes by
forging or modifying this field.  An outsider could also cause the
elimination of reestablished routes by replaying this withdrawal
information from earlier packets.

A BGP speaker could "falsely" withdraw feasible routes using this field.
However, as the BGP speaker is authoritative for the routes it will
announce, it is allowed to withdraw any previously announced routes that
it wants.  As the receiving BGP speaker will only withdraw routes





Murphy                     Expires: April 2003                  [Page 6]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis     October 2002


associated with the sending BGP speaker, there is no opportunity for a
BGP speaker to withdraw another BGP speaker's routes.  Therefore, there
is no additional risk from BGP peers via this field.

2.4.3.  Path Attributes

The path attributes present many different vulnerabilities and risks.

Attribute Flags, Attribute Type Codes, Attribute Length

A BGP peer or an outsider could modify the attribute length or attribute
type (flags and type codes) so they did not reflect the attribute values
that followed.  If the flags were modified, the flags and type code
could become incompatible (i.e., a mandatory attribute marked as
partial), or a optional attribute could be interpreted as a mandatory
attribute or vice versa.  If the type code were modified,  the attribute
value could be interpreted as if it were the data type and value of a
different attribute.

The most likely result from modifying the attribute length, flags, or
type code would be a parse error of the UPDATE message.  A parse error
would cause the transmission of a NOTIFICATION message and the close of
the connection.  As a true BGP speaker is always able to close a
connection at any time, this vulnerability represents an additional risk
only when the source is an outsider, i.e., it presents no additional
risk from a BGP peer.

ORIGIN

This field indicates whether the information was learned from IGP or EGP
information.  If the route is used in inter-AS multicast routing, a
value of INCOMPLETE may be used.  This field is not used in making
routing decisions, so there are no vulnerabilities arising from this
field, either from BGP peers or outsiders.

AS_PATH

A BGP peer or outsider could announce an AS_PATH that was not accurate
for the associated NLRI.  Forwarding for the NLRI associated with the
AS_PATH could potentially be induced to follow a sub-optimal path, a
path that did not follow some intended policy, or even a path that would
not forward the traffic.  If the path would not forward the traffic, the
NLRI would become unreachable for that portion of the Internet that
accepted the false path.  If much traffic is mis-directed, some routers
and transit networks along the announced route could become flooded with





Murphy                     Expires: April 2003                  [Page 7]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis     October 2002


the mis-directed traffic.

It is not clear how far an inaccurate AS_PATH could deviate from the
true AS_PATH.  It may be that the first AS in the AS_PATH, at least,
must be a legal hop.  The RFC states that a BGP speaker prepends its own
AS to an AS_PATH before announcing it to a neighbor.  If the BGP speaker
must prepend its own AS, then a BGP speaker that produced a bogus
AS_PATH could end up receiving the traffic for the associated NLRI.
This could be desirable if the error was deliberate and the intent was
to receive traffic that would not otherwise be received.  Receiving the
mis-routed traffic could be undesirable for the faulty BGP speaker if it
were not prepared to handle the extra (mis-routed) traffic.  So,
requiring a BGP peer to prepend its own AS to the AS_PATH, might
encourage or discourage it from inventing an arbitrary AS_PATH,
depending on its resources and intent.

If BGP peers need not prepend its own AS (or implementations do not
ensure that this is done), then a malicious BGP peer could announce a
path that begins with the AS of any BGP speaker with little impact on
itself.

Whether such an arbitrary AS_PATH is a vulnerability would depend on
whether BGP implementations check the AS_PATH (to see if the first AS is
the neighbor) and would catch the error.  If there are legitimate
situations in which a BGP speaker could pass an AS_PATH to a neighbor
without putting its own AS at the head of the AS_PATH, then there is no
way for implementations to detect totally bogus AS_PATHs.

Originating Routes

A special case of announcing a false AS_PATH occurs when the AS_PATH
advertises a direct connection to a specific network address.  An BGP
peer or outsider could disrupt routing to the network(s) listed in the
NLRI field by falsely advertising a direct connection to the network.
The NLRI would become unreachable to the portion of the network that
accepted this false route, unless the ultimate AS on the AS_PATH
undertook to tunnel the packets it was forwarded for this NLRI on toward
their true destination AS by a valid path.  But even when the packets
are tunneled to the correct destination AS, the route followed may not
be optimal or may not follow the intended policy.  Additionally, routing
for other networks in the Internet could be affected if the false
advertisement fragmented an aggregated address block, forcing the
routers to handle (issue UPDATES, store, manage) the multiple fragments
rather than the single aggregate.  False originations for multiple
addresses can result in routers and transit networks along the announced





Murphy                     Expires: April 2003                  [Page 8]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis     October 2002


route to become flooded with mis-directed traffic.

NEXT_HOP

The NEXT_HOP attribute defines the IP address of the border router that
should be used as the next hop when forwarding the NLRI listed in the
UPDATE message.  If the recipient is an external peer, then the
recipient and the NEXT_HOP address must share a subnet.  It is clear
that an outsider modifying this field could disrupt the forwarding of
traffic between the two AS's.

In the case that the recipient of the message is an external peer of an
AS and the route was learned from another peer AS (this is one of two
forms of "third party" NEXT_HOP), then the BGP speaker advertising the
route has the opportunity to direct the recipient to forward traffic to
a BGP speaker at the NEXT_HOP address.  This affords the opportunity to
direct traffic at a router that may not be able to continue forwarding
the traffic.  It is unclear whether this would also require the
advertising BGP speaker to construct an AS_PATH mentioning the NEXT_HOP
external peer's AS.

MULTI_EXIT_DISC

The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted
between inter-AS BGP peers.  While the MULTI_EXIT_DISC received from an
inter-AS peer may be propagated within an AS, it may not be propagated
to other AS's.  Consequently, this field is only used in making routing
decisions internal to one AS.  Modifying this field, whether by an
outsider or an BGP peer, could influence routing within an AS to be sub-
optimal, but the effect should be limited in scope.

LOCAL_PREF

The LOCAL_PREF attribute must be included in all messages with internal
peers and excluded from messages with external peers.  Consequently,
modification of the LOCAL_PREF could effect the routing process within
the AS only.  Note that there is no requirement in the BGP RFC that the
LOCAL_PREF be consistent among the internal BGP speakers of an AS.  As
BGP peers are free to choose the LOCAL_PREF as they wish, modification
of this field is a vulnerability with respect to outsiders only.

ATOMIC_AGGREGATE

The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way
has received a more specific and a less specific route to the NLRI and





Murphy                     Expires: April 2003                  [Page 9]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis     October 2002


installed the aggregated route.  This route cannot be de-aggregated
because it is not certain that the route to more specific prefixes will
follow the listed AS_PATH.  Consequently, BGP speakers receiving a route
with ATOMIC_AGGREGATE are restricted from making the NLRI any more
specific.  Removing the ATOMIC_AGGREGATE attribute would remove the
restriction, possibly causing traffic intended for the more specific
NLRI to be routed incorrectly.   Adding the ATOMIC_AGGREGATE attribute
when no aggregation was done would have little effect, beyond
restricting the un-aggregated NLRI from being made more specific.  This
vulnerability exists whether the source is a BGP peer or an outsider.

AGGREGATOR

This field may be included by a BGP speaker who has computed the routes
represented in the UPDATE message from aggregation of other routes.  The
field contains the AS number and IP address of the last aggregator of
the route.  It is not used in making any routing decisions, so it does
not represent a vulnerability.

2.4.4.  NLRI

By modifying or forging this field, either an outsider or BGP peer
source could cause disruption of routing to the announced network,
overwhelm a router along the announced route, cause data loss when the
announced route will not forward traffic to the announced network, route
traffic by a sub-optimal route, etc.

2.5.  BGP Extensions

Several standards track extensions have been defined for BGP, e.g., [3],
[4].  Some have present additional vulnerabilities.

2.5.1.  Communities

An optional transitive path attribute called COMMUNITIES, [3], provides
for more flexible and scalable configuration of routing policies and for
control of configuration by the service provider customer.  Routing
UPDATEs may now include a communities attribute that is used by the
receiver in deciding to accept, prefer, or distribute the UPDATE route.

An outsider could forge values in this field to affect the routing
behavior of the receiver.  In particular, the defined values for this
attribute of NO_EXPORT, NO_ADVERTISE, and NO_EXPORT_SUBCONFED offer the
opportunity to affect the distribution of those routes.






Murphy                     Expires: April 2003                 [Page 10]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis     October 2002


Depending on the use the receiver makes of the communities attribute, a
BGP peer who had knowledge of the routing decision process of the
receiver could misuse communities to which it was not authorized to its
own benefit or to the harm of others.

2.5.2.  Confederations

New types for AS_PATH segments called AS_CONFED_SEQUENCE and
AS_CONFED_SET, [4], offer an alternative to ful mesh IBGP sessions.  A
confederation is a collection of autonomous systems advertised to BGP
speaker outside the confederation as a single AS but within the
confederation as if they were distinct AS's.

An outsider who was able to forge this segment type could affect routing
within the confederation and consequently routing with peers as well.

The specification [4] makes no distinction between the values for
Member-AS numbers used within a confederation and AS numbers used
outside a confederation.  The possibility exists for a BGP speaker to
include a segment type of AS_CONFED_SEQUENCE or AS_CONFED_SET and use
the same Member-AS value as used in its peer's own confederation.  This
presents an opportunity to considerably affect routing between the two
confederations and inside the peer's confederation.

3.  Security Considerations

This entire memo is about security, describing an analysis of the
vulnerabilities that exist in the BGP protocol.  A companion work, [5],
describes possible security solutions and their costs.

4.  References

[1]  Y. Rekhter and T. Li,  "A Border Gateway Protocol 4 (BGP-4)",
     RFC1771, March 1995.

[2]  Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP-4)", work
     in progress, November 2001.  available as
     <<draft-ietf-idr-bgp4-17.txt>> at Internet-Draft shadow sites.

[3]  R. Chandra, P. Traina, and T. Li, "BGP Communities Attribute",
     RFC1997, August 1996.

[4]  P. Traina, D. McPherson, and J. Scudder, "Autonomous System
     Confederations for BGP", RFC3065, February 2001.






Murphy                     Expires: April 2003                 [Page 11]

INTERNET DRAFT    BGP Security Vulnerabilities Analysis     October 2002


[5]  S. Murphy, "BGP Security Protections", work in progress, October,
     2002.  available as
     <<draft-murphy-bgp-protect-02.txt>> at Internet-Draft shadow sites.

5.  Author's Address

Sandra Murphy
Network Associates, Inc.
NAI Labs
3060 Washington Road
Glenwood, MD  21738
EMail: [e-mail]






































Murphy                     Expires: April 2003                 [Page 12]


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 OAA24630 for <[e-mail]>; Fri, 25 Oct 2002 14:58:24 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 31B7291312; Fri, 25 Oct 2002 14:57:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0C1F91314; Fri, 25 Oct 2002 14:57: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 E804091312 for <[e-mail]>; Fri, 25 Oct 2002 14:57:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D12CC5DF55; Fri, 25 Oct 2002 14:57:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: from sentry.gw.tislabs.com (unknown [192.94.214.100]) by segue.merit.edu (Postfix) with ESMTP id 4C6B25DF6C for <[e-mail]>; Fri, 25 Oct 2002 14:57:29 -0400 (EDT)
Received: by sentry.gw.tislabs.com; id OAA14461; Fri, 25 Oct 2002 14:57:25 -0400 (EDT)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma014446; Fri, 25 Oct 02 18:56:59 GMT
Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g9PIuwi20222; Fri, 25 Oct 2002 14:56:58 -0400 (EDT)
Date: Fri, 25 Oct 2002 14:56:58 -0400 (EDT)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: security drafts
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

Since the vulnerability draft has expired from the internet-draft
sites, as noted, Yakov asked that I resubmit the draft, post-haste.
I'll send the draft to the internet-drafts address and cc the idr
list, so you should see draft-murphy-bgp-vuln-02.txt momentarily.

If you get the internet draft announcements, you might also see an
announcement of draft-murphy-bgp-protect-02.txt.  That's the dual to
the vulnerabilities draft and is the remaining half of what used to
be the "BGP Security Analysis" draft.  The vulnerabilities draft
refers to the protections draft, so I needed to resubmit both.
But only the vulnerabilities draft draft-murphy-bgp-vuln-02.txt is
under consideration as an idr working group draft.

--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 NAA19365 for <[e-mail]>; Fri, 25 Oct 2002 13:21:27 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7B7289130E; Fri, 25 Oct 2002 13:19:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 497879130F; Fri, 25 Oct 2002 13:19: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 E61729130E for <[e-mail]>; Fri, 25 Oct 2002 13:19:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CEE0B5DF20; Fri, 25 Oct 2002 13:19:04 -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 85AC15DDB0 for <[e-mail]>; Fri, 25 Oct 2002 13:19:04 -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 g9PHJ2C91878; Fri, 25 Oct 2002 13:19:02 -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 g9PHJ2175190; Fri, 25 Oct 2002 13:19:02 -0400 (EDT)
Received: (from kaarthik@localhost) by coors.torrentnet.com (8.11.2/8.11.2) id g9PHJ2k06295; Fri, 25 Oct 2002 13:19:02 -0400 (EDT)
X-Authentication-Warning: coors.torrentnet.com: kaarthik set sender to [e-mail] using -f
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-murphy-bgp-vuln-00.txt as a WG item
References: <[e-mail]>
From: Kaarthik Sivakumar <[e-mail]>
In-Reply-To: <[e-mail]>
Date: 25 Oct 2002 13:19:02 -0400
Message-ID: <[e-mail]>
Lines: 33
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

>>> "YR" == Yakov Rekhter <[e-mail]> writes:
YR> Folks,
YR> minor correction - it should be draft-murphy-bgp-vuln-01.txt
YR> in the attached.

This draft doesnt exist in the IETF directory.
http://www.ietf.org/internet-drafts/draft-murphy-bgp-vuln-01.txt says
that this draft has expired and is not available. Can the author
resend it? Thanks.

Kaarthik


YR> Sorry for the confusion.

YR> Yakov.
YR> From:    Yakov Rekhter <[e-mail]>
YR> Subject: draft-murphy-bgp-vuln-00.txt as a WG item
YR> To:      [e-mail]
YR> Date: Fri, 25 Oct 2002 09:46:14 -0700


YR> Folks,

YR> If there are any objections to accepting  draft-murphy-bgp-vuln-00.txt
YR> as a WG document, please send them to the list within the next
YR> week. In the absence of objections by 11/1  draft-murphy-bgp-vuln-00.txt
YR> will be accepted as an IDR WG document.

YR> Yakov.
YR> ----------




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA17732 for <[e-mail]>; Fri, 25 Oct 2002 12:52:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id AA8389130C; Fri, 25 Oct 2002 12:51:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75A7B9130D; Fri, 25 Oct 2002 12:51: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 53C2C9130C for <[e-mail]>; Fri, 25 Oct 2002 12:51:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 416EC5DF33; Fri, 25 Oct 2002 12:51: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 A75D55DE5F for <[e-mail]>; Fri, 25 Oct 2002 12:51: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 g9PGpYm08835 for <[e-mail]>; Fri, 25 Oct 2002 09:51:34 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: draft-murphy-bgp-vuln-00.txt as a WG item
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 25 Oct 2002 09:51:34 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

minor correction - it should be draft-murphy-bgp-vuln-01.txt
in the attached.

Sorry for the confusion.

Yakov.
------- Forwarded Message

Date:    Fri, 25 Oct 2002 09:46:14 -0700
From:    Yakov Rekhter <[e-mail]>
To:      [e-mail]
Subject: draft-murphy-bgp-vuln-00.txt as a WG item

Folks,

If there are any objections to accepting  draft-murphy-bgp-vuln-00.txt
as a WG document, please send them to the list within the next
week. In the absence of objections by 11/1  draft-murphy-bgp-vuln-00.txt
will be accepted as an IDR WG document.

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 MAA17473 for <[e-mail]>; Fri, 25 Oct 2002 12:46:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CFEFC9130B; Fri, 25 Oct 2002 12:46:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF7489130C; Fri, 25 Oct 2002 12: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 82F4C9130B for <[e-mail]>; Fri, 25 Oct 2002 12:46:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 61C095DF33; Fri, 25 Oct 2002 12:46:15 -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 C38105DDB0 for <[e-mail]>; Fri, 25 Oct 2002 12:46:14 -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 g9PGkEm08498 for <[e-mail]>; Fri, 25 Oct 2002 09:46:14 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: draft-murphy-bgp-vuln-00.txt as a WG item
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 25 Oct 2002 09:46:14 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

If there are any objections to accepting  draft-murphy-bgp-vuln-00.txt
as a WG document, please send them to the list within the next
week. In the absence of objections by 11/1  draft-murphy-bgp-vuln-00.txt
will be accepted as an IDR WG 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 KAA08726 for <[e-mail]>; Fri, 25 Oct 2002 10:09:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 69BE091304; Fri, 25 Oct 2002 10:09:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EBD491305; Fri, 25 Oct 2002 10:09: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 B7FB591304 for <[e-mail]>; Fri, 25 Oct 2002 10:09:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9E8BA5DF09; Fri, 25 Oct 2002 10:09: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 50ED45DDE4 for <[e-mail]>; Fri, 25 Oct 2002 10:09:22 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT9HTN>; Fri, 25 Oct 2002 10:09:21 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Susan Hares'" <[e-mail]>, "Gray, Eric" <[e-mail]>, [e-mail]
Cc: [e-mail], yakov Rekhter <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: RE: Issue 46 and 48
Date: Fri, 25 Oct 2002 10:09:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Sue,

	Sorry for the confusing usage.  I meant to ask
"should (the word) 'must' be capitalized (MUST)?" in 
reference to the text explicitly included "below" the 
question.

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


> -----Original Message-----
> From: Susan Hares [mailto:[e-mail]]
> Sent: Friday, October 25, 2002 8:22 AM
> To: Gray, Eric; [e-mail]
> Cc: [e-mail]; yakov Rekhter;
> [e-mail]; [e-mail]; [e-mail]
> Subject: RE: Issue 46 and 48
> 
> Eric:
> 
> Thank, it is issue 48 in the text below.
> 
> And Should be capitalized in the following
> three locations:
> 
> 
>  Event13: Transport Connection Indication & valid remote peer[changed]
> 
> 	   Definition: Event indicating that transport
>                        Requestvalid 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
> 
> 
> 
> 
>  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.
> 
> 
> 
> 8.2) Description of FSM
> 
> 
> 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 a
> 
> thanks for the comment.
> 
> Sue
> 
> 
> > -----Original Message-----
> > From: Susan Hares [mailto:[e-mail]]
> > Sent: Thursday, October 24, 2002 11:05 AM
> > To: [e-mail]
> > Cc: [e-mail]; yakov Rekhter;
> > [e-mail]; [e-mail]; [e-mail]
> > Subject: Issue 46 and 48
> >
> >
> > I propose putting the text suggested by issue 48 in section 8.2 after
> >
> > 8.2) Description of FSM
> >
> > 8.2.1) FSM connections
> >
> > 	(text below)
> >
> >
> > 8.2.2) FSM Definition
> >
> > (text now in 8.2)
> >
> >
> > issue 48 suggested the following text:
> 
> Also, in the text below, should must be capitalized?
> 
> >
> > 	"BGP must maintain a separate FSM for each configured peer plus
           MUST?
> > 	Each BGP peer paired in a potential connection unless configured
> > 	to remain in the idle state, or configured to remain passive,
> > 	will attempt to  to connect to the other.  For the purpose of
> >     this discussion, the active or connect side of the TCP
> >     connection (the side of a TCP connection (the side sending
> >     the first TCP SYN packet) is called outgoing.  The passive or
> >     listening side (the sender of the first SYN ACK) is called
> >     an incoming connection. [See section on the terms active and
> > 	passive below.]
> >
> > 	A BGP implementation must connect to and listen on TCP port 179
                           MUST?
> > 	for incoming connections in addition to trying to connect to peers.
> > 	Fro each incoming connection, a state machine must be instantiated.
      FOR
> > 	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 an outgoing
> > 	connection for the same configured peering 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 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.
> >
> > 	There may be more than one connections between a pair of peers if
            MAY?
> > 	the connections are configured to use a different pair of IP
> > 	addresses. This is referred to as multiple "configured peerings"
> > 	to the same peer.
> >
> > 	8.2.1.1) Terms "active" and "passive"
> >
> > 	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 per the
> > 	definition above [and the state machine below.] When 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.
> >
> >
> >
> >
> > ... [snip]
> >
> > 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 JAA05225 for <[e-mail]>; Fri, 25 Oct 2002 09:04:24 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5BDD391301; Fri, 25 Oct 2002 09:04:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2918C912FF; Fri, 25 Oct 2002 09:04: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 E9A6991301 for <[e-mail]>; Fri, 25 Oct 2002 09:02:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CD3CF5DF18; Fri, 25 Oct 2002 09:02:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from rtp-cse-319.cisco.com (unknown [64.102.253.5]) by segue.merit.edu (Postfix) with ESMTP id 537FB5DF00 for <[e-mail]>; Fri, 25 Oct 2002 09:02:19 -0400 (EDT)
Received: from localhost (dwalton@localhost) by rtp-cse-319.cisco.com (8.11.6+Sun/CA/950118) with ESMTP id g9PD2EJ03075; Fri, 25 Oct 2002 09:02:14 -0400 (EDT)
Date: Fri, 25 Oct 2002 09:02:14 -0400 (EDT)
From: Daniel Walton <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: missing issue - implemented route selections not necessarily  consistant with draft
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On Thu, 24 Oct 2002, Natale, Jonathan wrote:

> this is my unofficial understanding of this...
>
> first the router id's were used
>
> then there was a "bug" that said they should not be used,
> and this bug was fixed so the oldest route was used
>

The "prefer the oldest external" step was added to prevent a variation of the
MED churn.

> then they came up with "bgp bestpath compare-routerid"
> to restore the older behavior
>

Customers asked for a knob :)

> *i think* this applies to the peer ip (next step)
>
> not sure how the clust-list applies here
>

The oldest external check only makes a difference if you are comparing two
external routes and this happens right before the router-ID check.  Comparing
peer addresses is the last step, after the router-ID and cluster-list length
have tied.

Daniel

> -$0.02
>
>
> -----Original Message-----
> From: Pedro Roque Marques [mailto:[e-mail]]
> Sent: Thursday, October 24, 2002 2:26 PM
> To: Jeffrey Haas
> Cc: [e-mail]
> Subject: missing issue - implemented route selections not necessarily
> consistant with draft
>
>
> Jeffrey Haas writes:
>
> > Reviewing my inbox, I think we dropped an issue - or I've misplaced
> > the resolution of it.
>
> > Our route selection tie-breaking process in -17 doesn't match at least
> > two of the $LARGE_ROUTER_VENDORs.
>
> > Noted differences are (per vrishab sikand): 1) originator ID (to be
> > substituited for router id, when present in path attribute) 2) cluster
> > list length 3) peer id (configured ip address of peer in the neighbor
> > command)
>
> - What about arrival time of a route as decision factor... ?
> I believe there are implementations that choose the 'older' route (whatever
> that is) before router-id in certain circunstances.
>
> Which may seen as a behaviour in which the route selection does not depend
> on the route attributes entirely...
>
>   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 IAA02765 for <[e-mail]>; Fri, 25 Oct 2002 08:17:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 61EB8912FB; Fri, 25 Oct 2002 08:16:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 252EC912FC; Fri, 25 Oct 2002 08:16: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 64B10912FB for <[e-mail]>; Fri, 25 Oct 2002 08:16:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4AEE05DE40; Fri, 25 Oct 2002 08:16:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: from webmail3.rediffmail.com (unknown [202.54.124.148]) by segue.merit.edu (Postfix) with SMTP id F2E315DDE4 for <[e-mail]>; Fri, 25 Oct 2002 08:16:24 -0400 (EDT)
Received: (qmail 32617 invoked by uid 510); 25 Oct 2002 12:18:21 -0000
Date: 25 Oct 2002 12:18:21 -0000
Message-ID: <[e-mail]>
Received: from unknown (203.197.138.199) by rediffmail.com via HTTP; 25 oct 2002 12:18:21 -0000
MIME-Version: 1.0
From: "naresh  paliwal" <[e-mail]>
Reply-To: "naresh  paliwal" <[e-mail]>
To: [e-mail]
Subject: inclusion of AS no in AS path
Content-type: text/plain; format=flowed
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

Is not it useful to check whether an update contains external 
peer's AS number in AS path attribute, avoiding this may introduce 
routing loop.

In other words, Are there situations/policies which could restrict 
a BGP speaker from including his AS number in the route advertised 
to an external peer ?
If yes how will routing loop be pruned?

regards
-naresh




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA18137 for <[e-mail]>; Thu, 24 Oct 2002 18:27:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BB1A9912E2; Thu, 24 Oct 2002 18:26:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86762912F4; Thu, 24 Oct 2002 18:26: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 708A7912E2 for <[e-mail]>; Thu, 24 Oct 2002 18:26:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 528475DED6; Thu, 24 Oct 2002 18:26: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 F27D85DED4 for <[e-mail]>; Thu, 24 Oct 2002 18:26:40 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9OMQXP90310; Thu, 24 Oct 2002 18:26: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 g9OMQTC90303; Thu, 24 Oct 2002 18:26:29 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9OMQTw20356; Thu, 24 Oct 2002 18:26:29 -0400 (EDT)
Date: Thu, 24 Oct 2002 18:26:29 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: using default route to reach peer
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, Oct 24, 2002 at 05:17:29PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Oct 24, 2002 at 05:17:29PM -0400, Natale, Jonathan wrote:
> But I still don't know why you are so angry???  Sorry.

Although Pedro is a little cranky about this, I can somewhat sympathise.

Too often we are assuming that just because something is in a certain
$LARGE_ROUTER_VENDOR's implementation that it is a good thing,
and a necessary thing to implement for protocol completeness.

It is far more important that we think about "is this necessary for
things to work?" and "can we both interoperate if we disagree with
this detail?".

And sometimes, its worth thinking about whether or not a certain
$LARGE_ROUTER_VENDOR made the right choice in their implementation.
If they did, incorporate it into the spec.  If not... :-)

> -Jonathan

-- 
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 RAA14492 for <[e-mail]>; Thu, 24 Oct 2002 17:19:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 920E0912EE; Thu, 24 Oct 2002 17:19:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D700912F0; Thu, 24 Oct 2002 17: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 5C5D1912EE for <[e-mail]>; Thu, 24 Oct 2002 17:17:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 41AAF5DECF; Thu, 24 Oct 2002 17:17: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 F410B5DEC9 for <[e-mail]>; Thu, 24 Oct 2002 17:17:44 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT9D0Q>; Thu, 24 Oct 2002 17:17:44 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Pedro Roque Marques'" <[e-mail]>
Cc: [e-mail], "Natale, Jonathan" <[e-mail]>
Subject: RE: using default route to reach peer
Date: Thu, 24 Oct 2002 17:17:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Pedro,

	I believe if you think about the implications
of peering with a device for which you do not have a
route learned from some routing protocol, you will
see that doing so by default is not a good idea.  If
the administrator wants to force this behavior, they
could simply add a static route for the peer.

	That said, however, I see no reason to get too
acrimonious about this issue.  It is not possible to
engineer common sense into a specification, so it is
probably fine to leave this issue alone.

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


> -----Original Message-----
> From: Pedro Roque Marques [mailto:[e-mail]]
> Sent: Thursday, October 24, 2002 5:08 PM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: RE: using default route to reach peer
> 
> Natale, Jonathan writes:
> 
> > key word is "MAY" key concept is documenting existing behavior: "one
> > goal of the update is document existing practice"
> > --http://www.ietf.org/html.charters/idr-charter.html
> 
> Can i add to the spec 'an implementation MAY choose to calculate the
> first 100 prime numbers between generating 2 sets of update
> messages'... ?
> 
> > "The point specifically here is that an implementation must be able
> > to deal w/ potentially looping routes. i.e. a route which by being
> > installed in a routing table causes itself to be looping..."
> > ...WRONG, that is not the point.
> 
> Are you going to put forward any argument other than the capital
> letters ?
> 
> If that is not the point, do you mind giving us a rational for not
> peering over the default route. Why is it such a good idea ?
> 
> The fact of the matter is that it works just fine when the apropriate
> safe gurards against looping routes are in place, usually for
> applications other than strictly internet routing.
> 
>   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 RAA14493 for <[e-mail]>; Thu, 24 Oct 2002 17:19:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1C06F912ED; Thu, 24 Oct 2002 17:19:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF5B7912F1; Thu, 24 Oct 2002 17: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 9CA58912ED for <[e-mail]>; Thu, 24 Oct 2002 17:17:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6DC6A5DE35; Thu, 24 Oct 2002 17:17: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 264785DEC9 for <[e-mail]>; Thu, 24 Oct 2002 17:17:31 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT9D03>; Thu, 24 Oct 2002 17:17:30 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Pedro Roque Marques'" <[e-mail]>
Cc: [e-mail]
Subject: RE: using default route to reach peer
Date: Thu, 24 Oct 2002 17:17:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Pedro,

I don't like your tone.  Just stating "I disagree" would suffice.  Please.
Thank you.

No argument is needed, it was clearly not the point.

Anyway, I'll assume (until Of have a chance to try it) that Juniper does
peer based on the default route.

But I still don't know why you are so angry???  Sorry.

Peace,
-Jonathan


-----Original Message-----
From: Pedro Roque Marques [mailto:[e-mail]] 
Sent: Thursday, October 24, 2002 5:08 PM
To: Natale, Jonathan
Cc: [e-mail]
Subject: RE: using default route to reach peer


Natale, Jonathan writes:

> key word is "MAY" key concept is documenting existing behavior: "one 
> goal of the update is document existing practice" 
> --http://www.ietf.org/html.charters/idr-charter.html

Can i add to the spec 'an implementation MAY choose to calculate the first
100 prime numbers between generating 2 sets of update messages'... ?

> "The point specifically here is that an implementation must be able to 
> deal w/ potentially looping routes. i.e. a route which by being 
> installed in a routing table causes itself to be looping..." ...WRONG, 
> that is not the point.

Are you going to put forward any argument other than the capital letters ?

If that is not the point, do you mind giving us a rational for not peering
over the default route. Why is it such a good idea ?

The fact of the matter is that it works just fine when the apropriate safe
gurards against looping routes are in place, usually for applications other
than strictly internet routing.

  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 RAA13869 for <[e-mail]>; Thu, 24 Oct 2002 17:09:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 85509912EC; Thu, 24 Oct 2002 17:08:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E8C8912ED; Thu, 24 Oct 2002 17:08: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 0C0DD912EC for <[e-mail]>; Thu, 24 Oct 2002 17:08:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EDDC35DED8; Thu, 24 Oct 2002 17:08: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 8D0EF5DED6 for <[e-mail]>; Thu, 24 Oct 2002 17:08:24 -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 g9OL8Om47231; Thu, 24 Oct 2002 14:08:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id g9OL8OB30472; Thu, 24 Oct 2002 14:08:24 -0700 (PDT) (envelope-from roque)
Date: Thu, 24 Oct 2002 14:08:24 -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: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: using default route to reach peer
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: [e-mail]
Precedence: bulk

Natale, Jonathan writes:

> key word is "MAY" key concept is documenting existing behavior: "one
> goal of the update is document existing practice"
> --http://www.ietf.org/html.charters/idr-charter.html

Can i add to the spec 'an implementation MAY choose to calculate the
first 100 prime numbers between generating 2 sets of update
messages'... ?

> "The point specifically here is that an implementation must be able
> to deal w/ potentially looping routes. i.e. a route which by being
> installed in a routing table causes itself to be looping..."
> ...WRONG, that is not the point.

Are you going to put forward any argument other than the capital
letters ?

If that is not the point, do you mind giving us a rational for not
peering over the default route. Why is it such a good idea ?

The fact of the matter is that it works just fine when the apropriate
safe gurards against looping routes are in place, usually for
applications other than strictly internet routing.

  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 QAA13359 for <[e-mail]>; Thu, 24 Oct 2002 16:59:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D3D6C912EA; Thu, 24 Oct 2002 16:59:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94C39912EB; Thu, 24 Oct 2002 16:59: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 48104912EA for <[e-mail]>; Thu, 24 Oct 2002 16:59:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 305185DECA; Thu, 24 Oct 2002 16:59:03 -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 D96565DEC6 for <[e-mail]>; Thu, 24 Oct 2002 16:59:02 -0400 (EDT)
Received: from tom3 (usercr19.uk.uudial.com [62.188.156.246]) by nemesis.systems.pipex.net (Postfix) with SMTP id 54FD516007E32; Thu, 24 Oct 2002 21:58:56 +0100 (BST)
Message-ID: <002601c27b9f$b527dbe0$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: <[e-mail]>, "Susan Hares" <[e-mail]>
Subject: Re: FSM issues - first of many discussions
Date: Thu, 24 Oct 2002 21:53:39 +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

Sue

Two thoughts.

First, not all FSM issues made it to the issues list - some did not
make it to the IDR list in the first place eg a suggestion of mine to
simplify the Connect and Active states by removing the Open Delay
timer expired substate into a separate OpenDelay state which then
removes much duplication and also simplifies other issues including
some which do appear on the list eg issue 47.

Second, I continue to see draft-hares-bgp-statemt-01.txt in the IETF
repository; not ietf-draft-hares-statmt-02.txt, and I do think that so
much has been raised over the FSM, we are in need of a new text (and I
don't know if that is -02 or -03) incorporating some of the changes -
eg the wording consistency comments of Xia W Zhao and Jeff Haas - to
provide a fresh base to work from.

I think the fastest way forward is in a number of steps, via a number
of versions of the FSM, and that trying to make a giant step, in
changes or in elapsed time or whatever, ends up slower.


Tom Petch
-----Original Message-----
From: Susan Hares <[e-mail]>
To: [e-mail] <[e-mail]>
Date: 24 October 2002 16:47
Subject: FSM issues - first of many discussions


>My understanding from Andrews 10-01-2002 version of the
>IDR issues, is that the following issues did not reach consensus:
>
> 4,8,10,11,18,19,24,32,32.1, 34, 39, 41, 45, 46, 47, 48, 49, 53
>
>Of these issues, I believe the following are associated with the
>FSM portion of the specification:
>
> 41 - Mention the FSM Internal Timers
> 46 - FSM Connection Collision Detections
>  47 - FSM - Add Explicit State Changing wording
> 48 - Explicitly Defined Processing of Incomming Connections
> 49 - Explicitly Define Event Generation
>
>Please let know if any other "non-consensus" issues are related
>to the state machine.
>
>I would like to examine these issue to reach the consensus needed
>for me to re-edit the base draft wording.
>
>If you have comments associated with these issues
>on the BGP FSM draft (ietf-draft-hares-statmt-02.txt) or the
>BGP Peer Persistent Oscillation (ietf-draft-hares-backoff-01.txt).
>associated with these issues, please clearly state which draft you
>are commenting on.
>
>Sue Hares
>[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 QAA13212 for <[e-mail]>; Thu, 24 Oct 2002 16:56:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CE3AE912E9; Thu, 24 Oct 2002 16:56:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B8EB912EA; Thu, 24 Oct 2002 16:56: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 5B51F912E9 for <[e-mail]>; Thu, 24 Oct 2002 16:56:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 42D615DEC4; Thu, 24 Oct 2002 16:56: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 F3C275DEB9 for <[e-mail]>; Thu, 24 Oct 2002 16:56:28 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT9D7R>; Thu, 24 Oct 2002 16:56:28 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Pedro Roque Marques'" <[e-mail]>
Cc: [e-mail]
Subject: RE: using default route to reach peer
Date: Thu, 24 Oct 2002 16:56:28 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

key word is "MAY"
key concept is documenting existing behavior:
"one goal of the update is document existing practice"
--http://www.ietf.org/html.charters/idr-charter.html

"The point specifically here is that an implementation must be able to deal
w/ potentially looping routes. i.e. a route which by being installed in a
routing table causes itself to be looping..."
...WRONG, that is not the point.  But that IS already covered in the draft
(it was NOT in the RFC).

but I will concede that "they" do have a bug such that they will install bgp
routes that will become mutually recursive once installed. 'nough said.

I see the "not peer based on default route" as confronting the situation
when you are multihomed to 2 different AS's and get the default route from 1
and are doing multihop to the other, and then the route to the multihop peer
goes away.  Do you want to peer to the multihop peer THRU the first peer???
Probably not.

-----Original Message-----
From: Pedro Roque Marques [mailto:[e-mail]] 
Sent: Thursday, October 24, 2002 2:47 PM
To: Natale, Jonathan
Cc: [e-mail]
Subject: using default route to reach peer


Natale, Jonathan writes:

> Folks, IOS does not allow a BGP peer to be reached via the default 
> route.  This seems like a good rule to me.  Is this specified in the/a 
> RFC/Draft somewhere?  Should it be added as a "MAY"?

I'm wondering if the document when finished will be published w/ by Cisco
Press... it is starting to seem as if it comes closer to document and
semi-officially sanction the behaviour of a particular implementation than
actually address the underlying technical issues.

The point specifically here is that an implementation must be able to deal
w/ potentially looping routes. i.e. a route which by being installed in a
routing table causes itself to be looping...

A simple minded aproach to the problem above that some implementations take
is to simply deny peering on the default route w/ the logic that any route
installed via that peering session that would be more specific for the
peering session address or nexthop of the default route would cause all
received routes to become looping.

There are implementations however that have a much more complete aproach to
the root problem and have no use for the quick fast hack of denying peering
on default.

The later is imho an implementation specific quirk which is probably already
documented sufficiently on books published under the label of the equipment
vendor in question.

I've no problem w/ any particular vendor or its implementation but puting
down as a standard the solutions of a particular implementation, which may
or may not be the most apropriate, i don't think the spec is doing a
service...

  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 QAA12088 for <[e-mail]>; Thu, 24 Oct 2002 16:36:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 338D3912E5; Thu, 24 Oct 2002 16:36:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECEBE912E4; Thu, 24 Oct 2002 16:36: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 732ED912E5 for <[e-mail]>; Thu, 24 Oct 2002 16:36:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 573545DEC7; Thu, 24 Oct 2002 16:36: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 E31845DEC6 for <[e-mail]>; Thu, 24 Oct 2002 16:36:12 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT9DZW>; Thu, 24 Oct 2002 16:36:12 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'vrishab sikand'" <[e-mail]>
Cc: [e-mail]
Subject: RE: missing issue - implemented route selections not necessarily  consistant with draft 
Date: Thu, 24 Oct 2002 16:36:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27B9C.FDCB7800"
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_01C27B9C.FDCB7800
Content-Type: text/plain

makes sense
did you verify this?
so the steps on the web are wrong
 
does bgp bestpath router-id effect this?

-----Original Message-----
From: vrishab sikand [mailto:[e-mail]] 
Sent: Thursday, October 24, 2002 2:45 PM
To: Yakov Rekhter; Venu Kumar G - CTD, Chennai.
Cc: vrishab sikand; Jeffrey Haas; [e-mail]
Subject: Re: missing issue - implemented route selections not necessarily
consistant with draft 



If you don't implement the RR spec, then *by definition* you can't
recognize CLUSTER_LIST attribute (as this attribute is defined
in the RR spec). And if you can't recognize the attribute, then you
can't take it into account for your route selection. 

In other words, you either implement the RR spec (and in this case
you also implement the route selection procedures specific to the
RR spec), or you don't (and in this case you can't take into account
various attributes defined in the RR spec).

Yakov. 


I agree. Thanks for the explanation. 


It seems that every implementation must atleast be able to decode ORIGINATOR
ID and CLUSTER LIST attributes, even if they dont support rest of RR
features. If they dont do so, then they cannot be deployed in a network
which has route reflectors. 


 Yakov Rekhter <[e-mail]> wrote: 


Venu,

> Hi,
> It is quiet possible that, we may receive multiple routes for
> same destination with varying CLUSTER list length's, even though we are
not
> enabled ( or Implemented) RR features on a router. So i feel we can add
> this in base spec with indication as optional to implement. 

If you don't implement the RR spec, then *by definition* you can't
recognize CLUSTER_LIST attribute (as this attribute is defined
in the RR spec). And if you can't recognize the attribute, then you
can't take it into account for your route selection. 

In other words, you either implement the RR spec (and in this case
you also implement the route selection procedures specific to the
RR spec), or you don't (and in this case you can't take into account
various attributes defined in the RR spec).

Yakov.



> This is cisco's best path selection algorithm
> 
> http://www.cisco.com/warp/public/459/25.shtml
> 
> 
> Venu 
> 
> 
> 
> -----Original Message-----
> From: vrishab sikand [mailto:[e-mail]]
> Sent: Thursday, October 24, 2002 9:16 PM
> To: Yakov Rekhter; Jeffrey Haas
> Cc: [e-mail]
> Subject: Re: missing issue - implemented route selections not necessarily
> consistant with draft 
> 
> 
> 
> The original thought expressed in the route reflector RFC was that: those
> routers which are not configured as route reflectors do not need to have
> "any" knowledge route reflector attributes. This i think was done to ease
> the migration to RR's. 
> 
> 
> I understand that for the major vendors, even if you are not configured as
> a RR, they perform these additional steps. So I believe these belong in
the
> main bgp specification. 
> 
> 
> 
> Yakov Rekhter wrote: 
> 
> 
> Jeff,
> 
> > Reviewing my inbox, I think we dropped an issue - or I've misplaced
> > the resolution of it.
> > 
> > Our route selection tie-breaking process in -17 doesn't match at
> > least two of the $LARGE_ROUTER_VENDORs.
> > 
> > Noted differences are (per vrishab sikand):
> > 1) originator ID (to be substituited for router id, when present
> > in path attribute)
> > 2) cluster list length
> > 3) peer id (configured ip address of peer in the neighbor command) 
> 
> These are all have to do with route selection in the presence
> of Route Reflectors. So, these issues have to be covered in the
> Route Reflector spec (the Route Reflector spec has to have a section
> on how Route Reflectors impact BGP Route Selection process).
> 
> Yakov.
> 
> 
> 
> 
> _____ 
> 
> Do you Yahoo!?
> Y! Web Hosting - Let the expert host your
> web site
> 
> 
> ------_=_NextPart_001_01C27B77.329D9CF0
> Content-Type: text/html;
> charset="iso-8859-1"
> 
> 
> 
> 
> 
> 
> 


> 
> 


> class=985534615-24102002>Hi,

> 

> class=985534615-24102002>        &nbs
p;   It 
> is quiet possible that, we may receive multiple routes for same
destination 
> with  varying CLUSTER list length's, even though we are not 
> enabled  ( or Implemented)   RR features on a router.  So

> i feel we can add this in base spec with indication as  

> optional to implement. 

> 

> class=985534615-24102002> 

> 
Thi
s 
> is cisco's best path selection algorithm

> 

> class=985534615-24102002> 

> 

> class=985534615-24102002>         
>
href="http://www.cisco.com/warp/public/459/25.shtml">http://www.cisco.com/wa
r
p/public/459/25.shtml

> 

> class=985534615-24102002> 

> 
Ven
u 
> 

> 

> class=985534615-24102002> 

> 

> class=985534615-24102002> 

> 

> class=985534615-24102002> 

> 

> class=985534615-24102002>-----Original

> Message-----
From: vrishab sikand 
> [mailto:[e-mail]]
Sent: Thursday, October 24, 2002 9:16 
> PM
To: Yakov Rekhter; Jeffrey Haas
Cc: 
> [e-mail]
Subject: Re: missing issue - implemented route 
> selections not necessarily consistant with draft 



> 


> 

The original thought expressed in the route reflector RFC was that: thos
e 
> routers which are not configured as route reflectors do not need to have
"a
ny" 
> knowledge route reflector attributes. This i think was done to ease the 
> migration to RR's. 
> 


I understand that  for the major vendors, even if you are not 
> configured as a RR, they perform these additional steps. So I believe
these

> belong in the main bgp specification. 
> 



> 


 Yakov Rekhter <[e-mail]> wrote: 
> 



> style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT:
5px"
>Jeff,

> 
> Reviewing my inbox, I think we dropped an issue - or I've misplaced
&g
t; 
> the resolution of it.
> 
> Our route selection tie-breaking 
> process in -17 doesn't match at
> least two of the 
> $LARGE_ROUTER_VENDORs.
> 
> Noted differences are (per vrisha
b 
> sikand):
> 1) originator ID (to be substituited for router id, when

> present
> in path attribute)
> 2) cluster list length
>
3) 
> peer id (configured ip address of peer in the neighbor command) 
> 

These are all have to do with route selection in the presence

of 
> Route Reflectors. So, these issues have to be covered in the
Route 
> Reflector spec (the Route Reflector spec has to have a section
on how 
> Route Reflectors impact BGP Route Selection 
> process).

Yakov.


> 



> 

  _____  


> Do you Yahoo!?
Y! Web  <http://webhosting.yahoo.com/> Hosting
> - 
> Let the expert host your web site


> 
> ------_=_NextPart_001_01C27B77.329D9CF0--




  _____  

Do you Yahoo!?
Y! Web Hosting <http://webhosting.yahoo.com/>  - Let the expert host your
web site


------_=_NextPart_001_01C27B9C.FDCB7800
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">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2713.1100" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=896463320-24102002><FONT face=Arial color=#0000ff size=2>makes 
sense</FONT></SPAN></DIV>
<DIV><SPAN class=896463320-24102002><FONT face=Arial color=#0000ff size=2>did 
you verify this?</FONT></SPAN></DIV>
<DIV><SPAN class=896463320-24102002><FONT face=Arial color=#0000ff size=2>so the 
steps on the web are wrong</FONT></SPAN></DIV>
<DIV><SPAN class=896463320-24102002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=896463320-24102002><FONT face=Arial color=#0000ff size=2>does 
bgp bestpath router-id effect this?</FONT></SPAN></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> vrishab sikand 
  [mailto:[e-mail]] <BR><B>Sent:</B> Thursday, October 24, 2002 2:45 
  PM<BR><B>To:</B> Yakov Rekhter; Venu Kumar G - CTD, Chennai.<BR><B>Cc:</B> 
  vrishab sikand; Jeffrey Haas; [e-mail]<BR><B>Subject:</B> Re: missing 
  issue - implemented route selections not necessarily consistant with draft 
  <BR><BR></FONT></DIV>
  <P>If you don't implement the RR spec, then *by definition* you 
  can't<BR>recognize CLUSTER_LIST attribute (as this attribute is defined<BR>in 
  the RR spec). And if you can't recognize the attribute, then you<BR>can't take 
  it into account for your route selection. <BR><BR>In other words, you either 
  implement the RR spec (and in this case<BR>you also implement the route 
  selection procedures specific to the<BR>RR spec), or you don't (and in this 
  case you can't take into account<BR>various attributes defined in the RR 
  spec).<BR><BR>Yakov. 
  <P>I agree. Thanks for the explanation. 
  <P>It seems that every implementation must atleast be able to decode 
  ORIGINATOR ID and CLUSTER LIST attributes, even if they dont support rest of 
  RR features. If they dont do so, then they cannot be deployed in a network 
  which has route reflectors. 
  <P>&nbsp;<B><I>Yakov Rekhter &lt;[e-mail]&gt;</I></B> wrote: 
  <BLOCKQUOTE 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
    <P>Venu,<BR><BR>&gt; Hi,<BR>&gt; It is quiet possible that, we may receive 
    multiple routes for<BR>&gt; same destination with varying CLUSTER list 
    length's, even though we are not<BR>&gt; enabled ( or Implemented) RR 
    features on a router. So i feel we can add<BR>&gt; this in base spec with 
    indication as optional to implement. <BR><BR>If you don't implement the RR 
    spec, then *by definition* you can't<BR>recognize CLUSTER_LIST attribute (as 
    this attribute is defined<BR>in the RR spec). And if you can't recognize the 
    attribute, then you<BR>can't take it into account for your route selection. 
    <BR><BR>In other words, you either implement the RR spec (and in this 
    case<BR>you also implement the route selection procedures specific to 
    the<BR>RR spec), or you don't (and in this case you can't take into 
    account<BR>various attributes defined in the RR spec).<BR><BR>Yakov.</P>
    <P><BR><BR>&gt; This is cisco's best path selection algorithm<BR>&gt; 
    <BR>&gt; http://www.cisco.com/warp/public/459/25.shtml<BR>&gt; <HTTP: 
    www.cisco.com warp public 459 25.shtml><BR>&gt; <BR>&gt; Venu <BR>&gt; 
    <BR>&gt; <BR>&gt; <BR>&gt; -----Original Message-----<BR>&gt; From: vrishab 
    sikand [mailto:[e-mail]]<BR>&gt; Sent: Thursday, October 24, 2002 
    9:16 PM<BR>&gt; To: Yakov Rekhter; Jeffrey Haas<BR>&gt; Cc: 
    [e-mail]<BR>&gt; Subject: Re: missing issue - implemented route 
    selections not necessarily<BR>&gt; consistant with draft <BR>&gt; <BR>&gt; 
    <BR>&gt; <BR>&gt; The original thought expressed in the route reflector RFC 
    was that: those<BR>&gt; routers which are not configured as route reflectors 
    do not need to have<BR>&gt; "any" knowledge route reflector attributes. This 
    i think was done to ease<BR>&gt; the migration to RR's. <BR>&gt; <BR>&gt; 
    <BR>&gt; I understand that for the major vendors, even if you are not 
    configured as<BR>&gt; a RR, they perform these additional steps. So I 
    believe these belong in the<BR>&gt; main bgp specification. <BR>&gt; 
    <BR>&gt; <BR>&gt; <BR>&gt; Yakov Rekhter <[e-mail]>wrote: <BR>&gt; 
    <BR>&gt; <BR>&gt; Jeff,<BR>&gt; <BR>&gt; &gt; Reviewing my inbox, I think we 
    dropped an issue - or I've misplaced<BR>&gt; &gt; the resolution of 
    it.<BR>&gt; &gt; <BR>&gt; &gt; Our route selection tie-breaking process in 
    -17 doesn't match at<BR>&gt; &gt; least two of the 
    $LARGE_ROUTER_VENDORs.<BR>&gt; &gt; <BR>&gt; &gt; Noted differences are (per 
    vrishab sikand):<BR>&gt; &gt; 1) originator ID (to be substituited for 
    router id, when present<BR>&gt; &gt; in path attribute)<BR>&gt; &gt; 2) 
    cluster list length<BR>&gt; &gt; 3) peer id (configured ip address of peer 
    in the neighbor command) <BR>&gt; <BR>&gt; These are all have to do with 
    route selection in the presence<BR>&gt; of Route Reflectors. So, these 
    issues have to be covered in the<BR>&gt; Route Reflector spec (the Route 
    Reflector spec has to have a section<BR>&gt; on how Route Reflectors impact 
    BGP Route Selection process).<BR>&gt; <BR>&gt; Yakov.<BR>&gt; <BR>&gt; 
    <BR>&gt; <BR>&gt; <BR>&gt; _____ <BR>&gt; <BR>&gt; Do you Yahoo!?<BR>&gt; Y! 
    Web Hosting <HTTP: webhosting.yahoo.com />- Let the expert host your<BR>&gt; 
    web site<BR>&gt; <BR>&gt; <BR>&gt; 
    ------_=_NextPart_001_01C27B77.329D9CF0<BR>&gt; Content-Type: 
    text/html;<BR>&gt; charset="iso-8859-1"<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; 
    <BR>&gt; <BR>&gt; <BR>&gt; 
    <META content="MSHTML 5.00.2919.6307" name=GENERATOR><BR>&gt; <BR>&gt; </P>
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; 
    class=985534615-24102002&gt;Hi,</SPAN></FONT></DIV><BR>&gt; 
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; 
    class=985534615-24102002&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;nbs<BR>p;&nbsp;&nbsp;&nbsp;It 
    <BR>&gt; is quiet possible that, we may receive multiple routes for same 
    destination <BR>&gt; with&nbsp; varying CLUSTER&nbsp;list length's, even 
    though we are not <BR>&gt; enabled&nbsp; ( or Implemented)&nbsp;&nbsp; RR 
    features on a router.&nbsp; So<BR><BR>&gt; i&nbsp;feel we can add this in 
    base spec&nbsp;with indication as&nbsp;&nbsp;<BR><BR>&gt; optional to 
    implement. </SPAN></FONT></DIV><BR>&gt; 
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; 
    class=985534615-24102002&gt;</SPAN></FONT>&nbsp;</DIV><BR>&gt; 
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=985534615-24102002>Thi<BR>s <BR>&gt; is cisco's best path selection 
    algorithm</SPAN></FONT></DIV><BR>&gt; 
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; 
    class=985534615-24102002&gt;</SPAN></FONT>&nbsp;</DIV><BR>&gt; 
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; 
    class=985534615-24102002&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    <A <br>&gt; 
    href="http://www.cisco.com/warp/public/459/25.shtml"&gt;http://www.cisco.com/war<BR>p/public/459/25.shtml</A></SPAN></FONT></DIV><BR>&gt; 

    <DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; 
    class=985534615-24102002&gt;</SPAN></FONT>&nbsp;</DIV><BR>&gt; 
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
    class=985534615-24102002>Ven<BR>u <BR>&gt; </SPAN></FONT></DIV><BR>&gt; 
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; 
    class=985534615-24102002&gt;</SPAN></FONT>&nbsp;</DIV><BR>&gt; 
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; 
    class=985534615-24102002&gt;</SPAN></FONT>&nbsp;</DIV><BR>&gt; 
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; 
    class=985534615-24102002&gt;</SPAN></FONT>&nbsp;</DIV><BR>&gt; 
    <DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; 
    class=985534615-24102002&gt;</SPAN></FONT><FONT face=Tahoma 
    size=2>-----Original<BR><BR>&gt; Message-----<BR><B>From:</B> vrishab sikand 
    <BR>&gt; [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, October 24, 
    2002 9:16 <BR>&gt; PM<BR><B>To:</B> Yakov Rekhter; Jeffrey 
    Haas<BR><B>Cc:</B> <BR>&gt; [e-mail]<BR><B>Subject:</B> Re: missing 
    issue - implemented route <BR>&gt; selections not necessarily consistant 
    with draft <BR><BR></DIV><BR>&gt; 
    <BLOCKQUOTE></FONT><BR>&gt; 
      <P>The original thought expressed in the route reflector RFC was that: 
      thos<BR>e <BR>&gt; routers which are not configured as route reflectors do 
      not need to have "a<BR>ny" <BR>&gt; knowledge route reflector attributes. 
      This i think was done to ease the <BR>&gt; migration to RR's. <BR>&gt; 
      <P>I&nbsp;understand that &nbsp;for the major vendors, even if you are not 
      <BR>&gt; configured as a RR, they perform these additional steps. So I 
      believe these<BR><BR>&gt; belong in the main bgp specification. <BR>&gt; 
      <P><BR>&gt; 
      <P>&nbsp;<B><I>Yakov Rekhter &lt;[e-mail]&gt;</I></B> wrote: 
      <BR>&gt; 
      <BLOCKQUOTE <br>&gt; style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 
        5px; PADDING-LEFT: 5px"<BR>&gt;Jeff,<BR><BR>&gt; <BR>&gt; Reviewing my 
        inbox, I think we dropped an issue - or I've misplaced<BR>&amp;g<BR>t; 
        <BR>&gt; the resolution of it.<BR>&gt; <BR>&gt; Our route selection 
        tie-breaking <BR>&gt; process in -17 doesn't match at<BR>&gt; least two 
        of the <BR>&gt; $LARGE_ROUTER_VENDORs.<BR>&gt; <BR>&gt; Noted 
        differences are (per vrisha<BR>b <BR>&gt; sikand):<BR>&gt; 1) originator 
        ID (to be substituited for router id, when<BR><BR>&gt; present<BR>&gt; 
        in path attribute)<BR>&gt; 2) cluster list length<BR>&gt;<BR>3) <BR>&gt; 
        peer id (configured ip address of peer in the neighbor command) <BR>&gt; 
        <BR><BR>These are all have to do with route selection in the 
        presence<BR><BR>of <BR>&gt; Route Reflectors. So, these issues have to 
        be covered in the<BR>Route <BR>&gt; Reflector spec (the Route Reflector 
        spec has to have a section<BR>on how <BR>&gt; Route Reflectors impact 
        BGP Route Selection <BR>&gt; process).<BR><BR>Yakov.</BLOCKQUOTE><BR>&gt; 
      <P><BR><BR>&gt; 
      <HR SIZE=1>
      <BR>&gt; Do you Yahoo!?<BR><A href="http://webhosting.yahoo.com/">Y! Web 
      Hosting</A<BR>&gt; - <BR>&gt; Let the expert host your web 
    site</BLOCKQUOTE><BR>&gt; <BR>&gt; 
  ------_=_NextPart_001_01C27B77.329D9CF0--</BLOCKQUOTE></A>
  <P><BR>
  <HR SIZE=1>
  Do you Yahoo!?<BR><A href="http://webhosting.yahoo.com/ ">Y! Web Hosting</A> - 
  Let the expert host your web site</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C27B9C.FDCB7800--


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 QAA12079 for <[e-mail]>; Thu, 24 Oct 2002 16:36:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 72932912E3; Thu, 24 Oct 2002 16:33:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B8D5912E4; Thu, 24 Oct 2002 16:33: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 5A555912E3 for <[e-mail]>; Thu, 24 Oct 2002 16:32:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 41FDB5DEC7; Thu, 24 Oct 2002 16:32: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 E57345DEC6 for <[e-mail]>; Thu, 24 Oct 2002 16:32:58 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT9DZB>; Thu, 24 Oct 2002 16:32:58 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: missing issue - implemented route selections not necessarily  consistant with draft
Date: Thu, 24 Oct 2002 16:32:57 -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 my unofficial understanding of this...

first the router id's were used

then there was a "bug" that said they should not be used,
and this bug was fixed so the oldest route was used

then they came up with "bgp bestpath compare-routerid"
to restore the older behavior

*i think* this applies to the peer ip (next step)

not sure how the clust-list applies here

-$0.02


-----Original Message-----
From: Pedro Roque Marques [mailto:[e-mail]] 
Sent: Thursday, October 24, 2002 2:26 PM
To: Jeffrey Haas
Cc: [e-mail]
Subject: missing issue - implemented route selections not necessarily
consistant with draft


Jeffrey Haas writes:

> Reviewing my inbox, I think we dropped an issue - or I've misplaced 
> the resolution of it.

> Our route selection tie-breaking process in -17 doesn't match at least 
> two of the $LARGE_ROUTER_VENDORs.

> Noted differences are (per vrishab sikand): 1) originator ID (to be 
> substituited for router id, when present in path attribute) 2) cluster 
> list length 3) peer id (configured ip address of peer in the neighbor 
> command)

- What about arrival time of a route as decision factor... ?
I believe there are implementations that choose the 'older' route (whatever
that is) before router-id in certain circunstances.

Which may seen as a behaviour in which the route selection does not depend
on the route attributes entirely...

  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 OAA06146 for <[e-mail]>; Thu, 24 Oct 2002 14:49:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 30F2D912DA; Thu, 24 Oct 2002 14:47:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFE3D912DB; Thu, 24 Oct 2002 14:47: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 8D20F912DA for <[e-mail]>; Thu, 24 Oct 2002 14:47:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5DF1A5DE3E; Thu, 24 Oct 2002 14:47: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 061855DECF for <[e-mail]>; Thu, 24 Oct 2002 14:46:58 -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 g9OIkvm34855; Thu, 24 Oct 2002 11:46:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id g9OIkvG30296; Thu, 24 Oct 2002 11:46:57 -0700 (PDT) (envelope-from roque)
Date: Thu, 24 Oct 2002 11:46:57 -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: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: using default route to reach peer
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: [e-mail]
Precedence: bulk

Natale, Jonathan writes:

> Folks, IOS does not allow a BGP peer to be reached via the default
> route.  This seems like a good rule to me.  Is this specified in
> the/a RFC/Draft somewhere?  Should it be added as a "MAY"?

I'm wondering if the document when finished will be published w/ by
Cisco Press... it is starting to seem as if it comes closer to
document and semi-officially sanction the behaviour of a particular
implementation than actually address the underlying technical issues.

The point specifically here is that an implementation must be able to
deal w/ potentially looping routes. i.e. a route which by being
installed in a routing table causes itself to be looping...

A simple minded aproach to the problem above that some implementations
take is to simply deny peering on the default route w/ the logic that
any route installed via that peering session that would be more
specific for the peering session address or nexthop of the default
route would cause all received routes to become looping.

There are implementations however that have a much more complete
aproach to the root problem and have no use for the quick fast hack of
denying peering on default.

The later is imho an implementation specific quirk which is probably
already documented sufficiently on books published under the label of
the equipment vendor in question.

I've no problem w/ any particular vendor or its implementation but
puting down as a standard the solutions of a particular
implementation, which may or may not be the most apropriate, i don't
think the spec is doing a service...

  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 OAA06014 for <[e-mail]>; Thu, 24 Oct 2002 14:46:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 56F19912D9; Thu, 24 Oct 2002 14:45:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 20DC9912DA; Thu, 24 Oct 2002 14:45: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 75CAC912D9 for <[e-mail]>; Thu, 24 Oct 2002 14:45:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 108EF5DEC3; Thu, 24 Oct 2002 14:45:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web12804.mail.yahoo.com (web12804.mail.yahoo.com [216.136.174.39]) by segue.merit.edu (Postfix) with SMTP id 1739E5DEC1 for <[e-mail]>; Thu, 24 Oct 2002 14:45:27 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [208.246.215.128] by web12804.mail.yahoo.com via HTTP; Thu, 24 Oct 2002 11:45:26 PDT
Date: Thu, 24 Oct 2002 11:45:26 -0700 (PDT)
From: vrishab sikand <[e-mail]>
Subject: Re: missing issue - implemented route selections not necessarily consistant with draft 
To: Yakov Rekhter <[e-mail]>, "Venu Kumar G - CTD, Chennai." <[e-mail]>
Cc: vrishab sikand <[e-mail]>, Jeffrey Haas <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1005831156-1035485126=:28109"
Sender: [e-mail]
Precedence: bulk

--0-1005831156-1035485126=:28109
Content-Type: text/plain; charset=us-ascii


If you don't implement the RR spec, then *by definition* you can't
recognize CLUSTER_LIST attribute (as this attribute is defined
in the RR spec). And if you can't recognize the attribute, then you
can't take it into account for your route selection. 

In other words, you either implement the RR spec (and in this case
you also implement the route selection procedures specific to the
RR spec), or you don't (and in this case you can't take into account
various attributes defined in the RR spec).

Yakov.
I agree. Thanks for the explanation. 
It seems that every implementation must atleast be able to decode ORIGINATOR ID and CLUSTER LIST attributes, even if they dont support rest of RR features. If they dont do so, then they cannot be deployed in a network which has route reflectors.
 Yakov Rekhter <[e-mail]> wrote:
Venu,

> Hi,
> It is quiet possible that, we may receive multiple routes for
> same destination with varying CLUSTER list length's, even though we are not
> enabled ( or Implemented) RR features on a router. So i feel we can add
> this in base spec with indication as optional to implement. 

If you don't implement the RR spec, then *by definition* you can't
recognize CLUSTER_LIST attribute (as this attribute is defined
in the RR spec). And if you can't recognize the attribute, then you
can't take it into account for your route selection. 

In other words, you either implement the RR spec (and in this case
you also implement the route selection procedures specific to the
RR spec), or you don't (and in this case you can't take into account
various attributes defined in the RR spec).

Yakov.



> This is cisco's best path selection algorithm
> 
> http://www.cisco.com/warp/public/459/25.shtml
> 
> 
> Venu 
> 
> 
> 
> -----Original Message-----
> From: vrishab sikand [mailto:[e-mail]]
> Sent: Thursday, October 24, 2002 9:16 PM
> To: Yakov Rekhter; Jeffrey Haas
> Cc: [e-mail]
> Subject: Re: missing issue - implemented route selections not necessarily
> consistant with draft 
> 
> 
> 
> The original thought expressed in the route reflector RFC was that: those
> routers which are not configured as route reflectors do not need to have
> "any" knowledge route reflector attributes. This i think was done to ease
> the migration to RR's. 
> 
> 
> I understand that for the major vendors, even if you are not configured as
> a RR, they perform these additional steps. So I believe these belong in the
> main bgp specification. 
> 
> 
> 
> Yakov Rekhter wrote: 
> 
> 
> Jeff,
> 
> > Reviewing my inbox, I think we dropped an issue - or I've misplaced
> > the resolution of it.
> > 
> > Our route selection tie-breaking process in -17 doesn't match at
> > least two of the $LARGE_ROUTER_VENDORs.
> > 
> > Noted differences are (per vrishab sikand):
> > 1) originator ID (to be substituited for router id, when present
> > in path attribute)
> > 2) cluster list length
> > 3) peer id (configured ip address of peer in the neighbor command) 
> 
> These are all have to do with route selection in the presence
> of Route Reflectors. So, these issues have to be covered in the
> Route Reflector spec (the Route Reflector spec has to have a section
> on how Route Reflectors impact BGP Route Selection process).
> 
> Yakov.
> 
> 
> 
> 
> _____ 
> 
> Do you Yahoo!?
> Y! Web Hosting - Let the expert host your
> web site
> 
> 
> ------_=_NextPart_001_01C27B77.329D9CF0
> Content-Type: text/html;
> charset="iso-8859-1"
> 
> 
> 
> 
> 
> 
> 
> 
> 
> class=985534615-24102002>Hi,
> > class=985534615-24102002>        &nbs
p;   It 
> is quiet possible that, we may receive multiple routes for same destination 
> with  varying CLUSTER list length's, even though we are not 
> enabled  ( or Implemented)   RR features on a router.  So

> i feel we can add this in base spec with indication as  

> optional to implement. 
> > class=985534615-24102002> 
> Thi
s 
> is cisco's best path selection algorithm
> > class=985534615-24102002> 
> > class=985534615-24102002>         > href="http://www.cisco.com/warp/public/459/25.shtml">http://www.cisco.com/war
p/public/459/25.shtml
> > class=985534615-24102002> 
> Ven
u 
> 
> > class=985534615-24102002> 
> > class=985534615-24102002> 
> > class=985534615-24102002> 
> > class=985534615-24102002>-----Original

> Message-----
From: vrishab sikand 
> [mailto:[e-mail]]
Sent: Thursday, October 24, 2002 9:16 
> PM
To: Yakov Rekhter; Jeffrey Haas
Cc: 
> [e-mail]
Subject: Re: missing issue - implemented route 
> selections not necessarily consistant with draft 


> 
> 
The original thought expressed in the route reflector RFC was that: thos
e 
> routers which are not configured as route reflectors do not need to have "a
ny" 
> knowledge route reflector attributes. This i think was done to ease the 
> migration to RR's. 
> 
I understand that  for the major vendors, even if you are not 
> configured as a RR, they perform these additional steps. So I believe these

> belong in the main bgp specification. 
> 

> 
 Yakov Rekhter <[e-mail]> wrote: 
> > style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"
>Jeff,

> 
> Reviewing my inbox, I think we dropped an issue - or I've misplaced
&g
t; 
> the resolution of it.
> 
> Our route selection tie-breaking 
> process in -17 doesn't match at
> least two of the 
> $LARGE_ROUTER_VENDORs.
> 
> Noted differences are (per vrisha
b 
> sikand):
> 1) originator ID (to be substituited for router id, when

> present
> in path attribute)
> 2) cluster list length
>
3) 
> peer id (configured ip address of peer in the neighbor command) 
> 

These are all have to do with route selection in the presence

of 
> Route Reflectors. So, these issues have to be covered in the
Route 
> Reflector spec (the Route Reflector spec has to have a section
on how 
> Route Reflectors impact BGP Route Selection 
> process).

Yakov.
> 


> 
---------------------------------

> Do you Yahoo!?
Y! Web Hosting> - 
> Let the expert host your web site
> 
> ------_=_NextPart_001_01C27B77.329D9CF0--


---------------------------------
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
--0-1005831156-1035485126=:28109
Content-Type: text/html; charset=us-ascii

<P>If you don't implement the RR spec, then *by definition* you can't<BR>recognize CLUSTER_LIST attribute (as this attribute is defined<BR>in the RR spec). And if you can't recognize the attribute, then you<BR>can't take it into account for your route selection. <BR><BR>In other words, you either implement the RR spec (and in this case<BR>you also implement the route selection procedures specific to the<BR>RR spec), or you don't (and in this case you can't take into account<BR>various attributes defined in the RR spec).<BR><BR>Yakov.
<P>I agree. Thanks for the explanation. 
<P>It seems that every implementation must atleast be able to decode ORIGINATOR ID and CLUSTER LIST attributes, even if they dont support rest of RR features. If they dont do so, then they cannot be deployed in a network which has route reflectors.
<P>&nbsp;<B><I>Yakov Rekhter &lt;[e-mail]&gt;</I></B> wrote:
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<P>Venu,<BR><BR>&gt; Hi,<BR>&gt; It is quiet possible that, we may receive multiple routes for<BR>&gt; same destination with varying CLUSTER list length's, even though we are not<BR>&gt; enabled ( or Implemented) RR features on a router. So i feel we can add<BR>&gt; this in base spec with indication as optional to implement. <BR><BR>If you don't implement the RR spec, then *by definition* you can't<BR>recognize CLUSTER_LIST attribute (as this attribute is defined<BR>in the RR spec). And if you can't recognize the attribute, then you<BR>can't take it into account for your route selection. <BR><BR>In other words, you either implement the RR spec (and in this case<BR>you also implement the route selection procedures specific to the<BR>RR spec), or you don't (and in this case you can't take into account<BR>various attributes defined in the RR spec).<BR><BR>Yakov.</P>
<P><BR><BR>&gt; This is cisco's best path selection algorithm<BR>&gt; <BR>&gt; http://www.cisco.com/warp/public/459/25.shtml<BR>&gt; <HTTP: 25.shtml 459 public warp www.cisco.com><BR>&gt; <BR>&gt; Venu <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; -----Original Message-----<BR>&gt; From: vrishab sikand [mailto:[e-mail]]<BR>&gt; Sent: Thursday, October 24, 2002 9:16 PM<BR>&gt; To: Yakov Rekhter; Jeffrey Haas<BR>&gt; Cc: [e-mail]<BR>&gt; Subject: Re: missing issue - implemented route selections not necessarily<BR>&gt; consistant with draft <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; The original thought expressed in the route reflector RFC was that: those<BR>&gt; routers which are not configured as route reflectors do not need to have<BR>&gt; "any" knowledge route reflector attributes. This i think was done to ease<BR>&gt; the migration to RR's. <BR>&gt; <BR>&gt; <BR>&gt; I understand that for the major vendors, even if you are not configured as<BR>&gt; a RR, they perform these additional steps. So I believe these belong in the<BR>&gt; main bgp specification. <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; Yakov Rekhter <[e-mail]>wrote: <BR>&gt; <BR>&gt; <BR>&gt; Jeff,<BR>&gt; <BR>&gt; &gt; Reviewing my inbox, I think we dropped an issue - or I've misplaced<BR>&gt; &gt; the resolution of it.<BR>&gt; &gt; <BR>&gt; &gt; Our route selection tie-breaking process in -17 doesn't match at<BR>&gt; &gt; least two of the $LARGE_ROUTER_VENDORs.<BR>&gt; &gt; <BR>&gt; &gt; Noted differences are (per vrishab sikand):<BR>&gt; &gt; 1) originator ID (to be substituited for router id, when present<BR>&gt; &gt; in path attribute)<BR>&gt; &gt; 2) cluster list length<BR>&gt; &gt; 3) peer id (configured ip address of peer in the neighbor command) <BR>&gt; <BR>&gt; These are all have to do with route selection in the presence<BR>&gt; of Route Reflectors. So, these issues have to be covered in the<BR>&gt; Route Reflector spec (the Route Reflector spec has to have a section<BR>&gt; on how Route Reflectors impact BGP Route Selection process).<BR>&gt; <BR>&gt; Yakov.<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; _____ <BR>&gt; <BR>&gt; Do you Yahoo!?<BR>&gt; Y! Web Hosting <HTTP: webhosting.yahoo.com />- Let the expert host your<BR>&gt; web site<BR>&gt; <BR>&gt; <BR>&gt; ------_=_NextPart_001_01C27B77.329D9CF0<BR>&gt; Content-Type: text/html;<BR>&gt; charset="iso-8859-1"<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt; 
<META content="MSHTML 5.00.2919.6307" name=GENERATOR><BR>&gt; <BR>&gt; </P>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; class=985534615-24102002&gt;Hi,</SPAN></FONT></DIV><BR>&gt; 
<DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; class=985534615-24102002&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;nbs<BR>p;&nbsp;&nbsp;&nbsp;It <BR>&gt; is quiet possible that, we may receive multiple routes for same destination <BR>&gt; with&nbsp; varying CLUSTER&nbsp;list length's, even though we are not <BR>&gt; enabled&nbsp; ( or Implemented)&nbsp;&nbsp; RR features on a router.&nbsp; So<BR><BR>&gt; i&nbsp;feel we can add this in base spec&nbsp;with indication as&nbsp;&nbsp;<BR><BR>&gt; optional to implement. </SPAN></FONT></DIV><BR>&gt; 
<DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; class=985534615-24102002&gt;</SPAN></FONT>&nbsp;</DIV><BR>&gt; 
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=985534615-24102002>Thi<BR>s <BR>&gt; is cisco's best path selection algorithm</SPAN></FONT></DIV><BR>&gt; 
<DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; class=985534615-24102002&gt;</SPAN></FONT>&nbsp;</DIV><BR>&gt; 
<DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; class=985534615-24102002&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A <br>&gt; href="http://www.cisco.com/warp/public/459/25.shtml"&gt;http://www.cisco.com/war<BR>p/public/459/25.shtml</A></SPAN></FONT></DIV><BR>&gt; 
<DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; class=985534615-24102002&gt;</SPAN></FONT>&nbsp;</DIV><BR>&gt; 
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=985534615-24102002>Ven<BR>u <BR>&gt; </SPAN></FONT></DIV><BR>&gt; 
<DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; class=985534615-24102002&gt;</SPAN></FONT>&nbsp;</DIV><BR>&gt; 
<DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; class=985534615-24102002&gt;</SPAN></FONT>&nbsp;</DIV><BR>&gt; 
<DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; class=985534615-24102002&gt;</SPAN></FONT>&nbsp;</DIV><BR>&gt; 
<DIV><FONT face=Arial color=#0000ff size=2><SPAN <br>&gt; class=985534615-24102002&gt;</SPAN></FONT><FONT face=Tahoma size=2>-----Original<BR><BR>&gt; Message-----<BR><B>From:</B> vrishab sikand <BR>&gt; [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, October 24, 2002 9:16 <BR>&gt; PM<BR><B>To:</B> Yakov Rekhter; Jeffrey Haas<BR><B>Cc:</B> <BR>&gt; [e-mail]<BR><B>Subject:</B> Re: missing issue - implemented route <BR>&gt; selections not necessarily consistant with draft <BR><BR></DIV><BR>&gt; 
<BLOCKQUOTE></FONT><BR>&gt; 
<P>The original thought expressed in the route reflector RFC was that: thos<BR>e <BR>&gt; routers which are not configured as route reflectors do not need to have "a<BR>ny" <BR>&gt; knowledge route reflector attributes. This i think was done to ease the <BR>&gt; migration to RR's. <BR>&gt; 
<P>I&nbsp;understand that &nbsp;for the major vendors, even if you are not <BR>&gt; configured as a RR, they perform these additional steps. So I believe these<BR><BR>&gt; belong in the main bgp specification. <BR>&gt; 
<P><BR>&gt; 
<P>&nbsp;<B><I>Yakov Rekhter &lt;[e-mail]&gt;</I></B> wrote: <BR>&gt; 
<BLOCKQUOTE <br>&gt; style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"<BR>&gt;Jeff,<BR><BR>&gt; <BR>&gt; Reviewing my inbox, I think we dropped an issue - or I've misplaced<BR>&amp;g<BR>t; <BR>&gt; the resolution of it.<BR>&gt; <BR>&gt; Our route selection tie-breaking <BR>&gt; process in -17 doesn't match at<BR>&gt; least two of the <BR>&gt; $LARGE_ROUTER_VENDORs.<BR>&gt; <BR>&gt; Noted differences are (per vrisha<BR>b <BR>&gt; sikand):<BR>&gt; 1) originator ID (to be substituited for router id, when<BR><BR>&gt; present<BR>&gt; in path attribute)<BR>&gt; 2) cluster list length<BR>&gt;<BR>3) <BR>&gt; peer id (configured ip address of peer in the neighbor command) <BR>&gt; <BR><BR>These are all have to do with route selection in the presence<BR><BR>of <BR>&gt; Route Reflectors. So, these issues have to be covered in the<BR>Route <BR>&gt; Reflector spec (the Route Reflector spec has to have a section<BR>on how <BR>&gt; Route Reflectors impact BGP Route Selection <BR>&gt; process).<BR><BR>Yakov.</BLOCKQUOTE><BR>&gt; 
<P><BR><BR>&gt; 
<HR SIZE=1>
<BR>&gt; Do you Yahoo!?<BR><A href="http://webhosting.yahoo.com/">Y! Web Hosting</A<BR>&gt; - <BR>&gt; Let the expert host your web site</BLOCKQUOTE><BR>&gt; <BR>&gt; ------_=_NextPart_001_01C27B77.329D9CF0--</BLOCKQUOTE></A><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://webhosting.yahoo.com/ ">Y! Web Hosting</a> - Let the expert host your web site
--0-1005831156-1035485126=:28109--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA05668 for <[e-mail]>; Thu, 24 Oct 2002 14:39:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 44BCA912DE; Thu, 24 Oct 2002 14:37:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C1F8912DD; Thu, 24 Oct 2002 14:37: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 CE822912DB for <[e-mail]>; Thu, 24 Oct 2002 14:37:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B3D165DEC4; Thu, 24 Oct 2002 14:37:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web12802.mail.yahoo.com (web12802.mail.yahoo.com [216.136.174.37]) by segue.merit.edu (Postfix) with SMTP id 63EB35DEBC for <[e-mail]>; Thu, 24 Oct 2002 14:37:40 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [208.246.215.128] by web12802.mail.yahoo.com via HTTP; Thu, 24 Oct 2002 11:37:39 PDT
Date: Thu, 24 Oct 2002 11:37:39 -0700 (PDT)
From: vrishab sikand <[e-mail]>
Subject: Re: missing issue - implemented route selections not necessarily consistant with draft
To: Pedro Roque Marques <[e-mail]>, Jeffrey Haas <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-386623435-1035484659=:38642"
Sender: [e-mail]
Precedence: bulk

--0-386623435-1035484659=:38642
Content-Type: text/plain; charset=us-ascii


on "careful" reading you may observe that step is just before using configured peer id. i.e. All attributes which come with the route or session are used first. If they are equal only then use time. In order avoid a flap for no good reason.
Having said that, using time does not make for very deterministic route selection.
 Pedro Roque Marques <[e-mail]> wrote:
Jeffrey Haas writes:

> Reviewing my inbox, I think we dropped an issue - or I've misplaced
> the resolution of it.

> Our route selection tie-breaking process in -17 doesn't match at
> least two of the $LARGE_ROUTER_VENDORs.

> Noted differences are (per vrishab sikand): 1) originator ID (to be
> substituited for router id, when present in path attribute) 2)
> cluster list length 3) peer id (configured ip address of peer in the
> neighbor command)

- What about arrival time of a route as decision factor... ?
I believe there are implementations that choose the 'older' route
(whatever that is) before router-id in certain circunstances.

Which may seen as a behaviour in which the route selection does not
depend on the route attributes entirely...

Pedro



---------------------------------
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
--0-386623435-1035484659=:38642
Content-Type: text/html; charset=us-ascii

<P>on "careful" reading you may observe that step is just before using configured peer id. i.e. All attributes which come with the route or session are used first. If they are equal only then use time. In order avoid a flap for no good reason.
<P>Having said that, using time does not make for very deterministic route selection.
<P>&nbsp;<B><I>Pedro Roque Marques &lt;[e-mail]&gt;</I></B> wrote:
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<P>Jeffrey Haas writes:<BR><BR>&gt; Reviewing my inbox, I think we dropped an issue - or I've misplaced<BR>&gt; the resolution of it.<BR><BR>&gt; Our route selection tie-breaking process in -17 doesn't match at<BR>&gt; least two of the $LARGE_ROUTER_VENDORs.<BR><BR>&gt; Noted differences are (per vrishab sikand): 1) originator ID (to be<BR>&gt; substituited for router id, when present in path attribute) 2)<BR>&gt; cluster list length 3) peer id (configured ip address of peer in the<BR>&gt; neighbor command)<BR><BR>- What about arrival time of a route as decision factor... ?<BR>I believe there are implementations that choose the 'older' route<BR>(whatever that is) before router-id in certain circunstances.<BR><BR>Which may seen as a behaviour in which the route selection does not<BR>depend on the route attributes entirely...<BR><BR>Pedro</P></BLOCKQUOTE><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://webhosting.yahoo.com/ ">Y! Web Hosting</a> - Let the expert host your web site
--0-386623435-1035484659=:38642--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA04955 for <[e-mail]>; Thu, 24 Oct 2002 14:27:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E39E891203; Thu, 24 Oct 2002 14:26:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF652912D6; Thu, 24 Oct 2002 14: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 664D791203 for <[e-mail]>; Thu, 24 Oct 2002 14:26:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 51E415DEB0; Thu, 24 Oct 2002 14:26: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 E71425DE53 for <[e-mail]>; Thu, 24 Oct 2002 14:26:23 -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 g9OIQNm32699; Thu, 24 Oct 2002 11:26:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id g9OIQNM30271; Thu, 24 Oct 2002 11:26:23 -0700 (PDT) (envelope-from roque)
Date: Thu, 24 Oct 2002 11:26:23 -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: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: missing issue - implemented route selections not necessarily consistant with draft
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: [e-mail]
Precedence: bulk

Jeffrey Haas writes:

> Reviewing my inbox, I think we dropped an issue - or I've misplaced
> the resolution of it.

> Our route selection tie-breaking process in -17 doesn't match at
> least two of the $LARGE_ROUTER_VENDORs.

> Noted differences are (per vrishab sikand): 1) originator ID (to be
> substituited for router id, when present in path attribute) 2)
> cluster list length 3) peer id (configured ip address of peer in the
> neighbor command)

- What about arrival time of a route as decision factor... ?
I believe there are implementations that choose the 'older' route
(whatever that is) before router-id in certain circunstances.

Which may seen as a behaviour in which the route selection does not
depend on the route attributes entirely...

  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 NAA00938 for <[e-mail]>; Thu, 24 Oct 2002 13:14:36 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3D54D912D3; Thu, 24 Oct 2002 13:14:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08902912D4; Thu, 24 Oct 2002 13:14: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 8DD80912D3 for <[e-mail]>; Thu, 24 Oct 2002 13:14:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 677065DEC1; Thu, 24 Oct 2002 13:14: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 24AD35DEBC for <[e-mail]>; Thu, 24 Oct 2002 13:14:07 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT9CZV>; Thu, 24 Oct 2002 13:14:06 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Susan Hares'" <[e-mail]>, [e-mail]
Cc: [e-mail], yakov Rekhter <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: RE: Issue 46 and 48
Date: Thu, 24 Oct 2002 13:14:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Sue,

	Please see below...

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


> -----Original Message-----
> From: Susan Hares [mailto:[e-mail]]
> Sent: Thursday, October 24, 2002 11:05 AM
> To: [e-mail]
> Cc: [e-mail]; yakov Rekhter;
> [e-mail]; [e-mail]; [e-mail]
> Subject: Issue 46 and 48
> 
> 
> I propose putting the text suggested by issue 48 in section 8.2 after
> 
> 8.2) Description of FSM
> 
> 8.2.1) FSM connections
> 
> 	(text below)
> 
> 
> 8.2.2) FSM Definition
> 
> (text now in 8.2)
> 
> 
> issue 47 suggested the following text:

Issue 48?

Also, in the text below, should must be capitalized?

> 
> 	"BGP must maintain a separate FSM for each configured peer plus
> 	Each BGP peer paired in a potential connection unless configured
> 	to remain in the idle state, or configured to remain passive,
> 	will attempt to  to connect to the other.  For the purpose of
>          this discussion, the active or connect side of the TCP
>          connection (the side of a TCP connection (the side sending
>          the first TCP SYN packet) is called outgoing.  The passive or
>          listening side (the sender of the first SYN ACK) is called
>          an incoming connection. [See section on the terms active and
> 	passive below.]
> 
> 	A BGP implementation must connect to and listen on TCP port 179
> 	for incoming connections in addition to trying to connect to peers.
> 	Fro 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 an outgoing
> 	connection for the same configured peering 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 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.
> 
> 	There may be more than one connections 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.
> 
> 	8.2.1.1) Terms "active" and "passive"
> 
> 	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 per the
> 	definition above [and the state machine below.] When 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.
> 
> 
> 
> 
> ... [snip]
> 
> 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 MAA29926 for <[e-mail]>; Thu, 24 Oct 2002 12:57:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5DE8B912D2; Thu, 24 Oct 2002 12:56:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F4A3912D3; Thu, 24 Oct 2002 12:56: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 A1F6A912D2 for <[e-mail]>; Thu, 24 Oct 2002 12:56:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8E4A25DEB1; Thu, 24 Oct 2002 12:56: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 1A5965DE8A for <[e-mail]>; Thu, 24 Oct 2002 12:56: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 g9OGuZm22996; Thu, 24 Oct 2002 09:56:35 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Venu Kumar G - CTD, Chennai." <[e-mail]>
Cc: vrishab sikand <[e-mail]>, [e-mail]
Subject: Re: missing issue - implemented route selections not necessarily consistant with draft 
In-Reply-To: Your message of "Thu, 24 Oct 2002 22:20:29 +0530." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 24 Oct 2002 09:56:35 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Venu,

>      I agreeing with your point for time being, But It really looks valid
> point to me to add  in the base spec and I guess Cisco do consider the
> "Originator_ID" /"Cluster list" attributes for Best route selection process
> even if we won't enable RR features on the router. 

As I said before, don't confuse *enabling* RR feature on a router
with *implementing* RR spec on a router. The latter doesn't automatically
imply the former. To consider CLUSTER_LIST for route selection you need 
to implement RR spec on a router, irrespective of whether you configure 
the router as an RR or not.

> My request is, at least
> we should add this issue in  next BGP base spec version (..After updating RR
> spec with best route selection process), So that we can give the RR spec
> reference in the BGP base spec.

The base BGP spec will have a pointer to the RR spec. And I certainly
agree with you that the RR spec has to be updated to cover route
selection process. 

Yakov.

> 
> 
> Venu
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Thursday, October 24, 2002 9:43 PM
> To: Venu Kumar G - CTD, Chennai.
> Cc: vrishab sikand; Jeffrey Haas; [e-mail]
> Subject: Re: missing issue - implemented route selections not
> necessarily consistant with draft 
> 
> 
> Venu,
> 
> > Hi,
> >             It is quiet possible that, we may receive multiple routes for
> > same destination with  varying CLUSTER list length's, even though we are
> not
> > enabled  ( or Implemented)   RR features on a router.  So i feel we can
> add
> > this in base spec with indication as  optional to implement. 
> 
> If you don't implement the RR spec, then *by definition* you can't
> recognize CLUSTER_LIST attribute (as this attribute is defined
> in the RR spec). And if you can't recognize the attribute, then you
> can't take it into account for your route selection. 
> 
> In other words, you either implement the RR spec (and in this case
> you also implement the route selection procedures specific to the
> RR spec), or you don't (and in this case you can't take into account
> various attributes defined in the RR spec).
> 
> Yakov.
> 
> > This is cisco's best path selection algorithm
> >  
> >          http://www.cisco.com/warp/public/459/25.shtml
> > <http://www.cisco.com/warp/public/459/25.shtml> 
> >  
> > Venu 
> >  
> >  
> >  
> > -----Original Message-----
> > From: vrishab sikand [mailto:[e-mail]]
> > Sent: Thursday, October 24, 2002 9:16 PM
> > To: Yakov Rekhter; Jeffrey Haas
> > Cc: [e-mail]
> > Subject: Re: missing issue - implemented route selections not necessarily
> > consistant with draft 
> > 
> > 
> > 
> > The original thought expressed in the route reflector RFC was that: those
> > routers which are not configured as route reflectors do not need to have
> > "any" knowledge route reflector attributes. This i think was done to ease
> > the migration to RR's. 
> > 
> > 
> > I understand that  for the major vendors, even if you are not configured
> as
> > a RR, they perform these additional steps. So I believe these belong in
> the
> > main bgp specification. 
> > 
> > 
> > 
> >  Yakov Rekhter <[e-mail]> wrote: 
> > 
> > 
> > Jeff,
> > 
> > > Reviewing my inbox, I think we dropped an issue - or I've misplaced
> > > the resolution of it.
> > > 
> > > Our route selection tie-breaking process in -17 doesn't match at
> > > least two of the $LARGE_ROUTER_VENDORs.
> > > 
> > > Noted differences are (per vrishab sikand):
> > > 1) originator ID (to be substituited for router id, when present
> > > in path attribute)
> > > 2) cluster list length
> > > 3) peer id (configured ip address of peer in the neighbor command) 
> > 
> > These are all have to do with route selection in the presence
> > of Route Reflectors. So, these issues have to be covered in the
> > Route Reflector spec (the Route Reflector spec has to have a section
> > on how Route Reflectors impact BGP Route Selection process).
> > 
> > Yakov.
> > 
> > 
> > 
> > 
> >    _____  
> > 
> > Do you Yahoo!?
> > Y! Web Hosting <http://webhosting.yahoo.com/>  - Let the expert host your
> > web site
> > 
> > 
> > ------_=_NextPart_001_01C27B77.329D9CF0
> > 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">
> > 
> > 
> > <META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
> > <BODY>
> > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> > class=985534615-24102002>Hi,</SPAN></FONT></DIV>
> > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> >
> class=985534615-24102002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
> s
> p;&nbsp;&nbsp;&nbsp;It 
> > is quiet possible that, we may receive multiple routes for same
> destination 
> > with&nbsp; varying CLUSTER&nbsp;list length's, even though we are not 
> > enabled&nbsp; ( or Implemented)&nbsp;&nbsp; RR features on a router.&nbsp;
> So
>  
> > i&nbsp;feel  we can add this in base spec&nbsp;with indication
> as&nbsp;&nbsp;
>  
> > optional to implement. </SPAN></FONT></DIV>
> > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> > class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
> class=985534615-24102002>Thi
> s 
> > is cisco's best path selection algorithm</SPAN></FONT></DIV>
> > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> > class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> > class=985534615-24102002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> <A 
> >
> href="http://www.cisco.com/warp/public/459/25.shtml">http://www.cisco.com/wa
> r
> p/public/459/25.shtml</A></SPAN></FONT></DIV>
> > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> > class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
> class=985534615-24102002>Ven
> u 
> > </SPAN></FONT></DIV>
> > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> > class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> > class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> > class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> > <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> > class=985534615-24102002></SPAN></FONT><FONT face=Tahoma
> size=2>-----Original
>  
> > Message-----<BR><B>From:</B> vrishab sikand 
> > [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, October 24, 2002
> 9:16 
> > PM<BR><B>To:</B> Yakov Rekhter; Jeffrey Haas<BR><B>Cc:</B> 
> > [e-mail]<BR><B>Subject:</B> Re: missing issue - implemented route 
> > selections not necessarily consistant with draft <BR><BR></DIV>
> > <BLOCKQUOTE></FONT>
> >   <P>The original thought expressed in the route reflector RFC was that:
> thos
> e 
> >   routers which are not configured as route reflectors do not need to have
> "a
> ny" 
> >   knowledge route reflector attributes. This i think was done to ease the 
> >   migration to RR's. 
> >   <P>I&nbsp;understand that &nbsp;for the major vendors, even if you are
> not 
> >   configured as a RR, they perform these additional steps. So I believe
> these
>  
> >   belong in the main bgp specification. 
> >   <P> 
> >   <P>&nbsp;<B><I>Yakov Rekhter &lt;[e-mail]&gt;</I></B> wrote: 
> >   <BLOCKQUOTE 
> >   style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT:
> 5px"
> >Jeff,<BR><BR>&gt; 
> >     Reviewing my inbox, I think we dropped an issue - or I've
> misplaced<BR>&g
> t; 
> >     the resolution of it.<BR>&gt; <BR>&gt; Our route selection
> tie-breaking 
> >     process in -17 doesn't match at<BR>&gt; least two of the 
> >     $LARGE_ROUTER_VENDORs.<BR>&gt; <BR>&gt; Noted differences are (per
> vrisha
> b 
> >     sikand):<BR>&gt; 1) originator ID (to be substituited for router id,
> when
>  
> >     present<BR>&gt; in path attribute)<BR>&gt; 2) cluster list
> length<BR>&gt;
>  3) 
> >     peer id (configured ip address of peer in the neighbor command) 
> >     <BR><BR>These are all have to do with route selection in the
> presence<BR>
> of 
> >     Route Reflectors. So, these issues have to be covered in the<BR>Route 
> >     Reflector spec (the Route Reflector spec has to have a section<BR>on
> how 
> >     Route Reflectors impact BGP Route Selection 
> >   process).<BR><BR>Yakov.</BLOCKQUOTE>
> >   <P><BR>
> >   <HR SIZE=1>
> >   Do you Yahoo!?<BR><A href="http://webhosting.yahoo.com/ ">Y! Web
> Hosting</A
> > - 
> >   Let the expert host your web site</BLOCKQUOTE></BODY></HTML>
> > 
> > ------_=_NextPart_001_01C27B77.329D9CF0--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA29451 for <[e-mail]>; Thu, 24 Oct 2002 12:49:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BF9EB912D1; Thu, 24 Oct 2002 12:48:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 911309123A; Thu, 24 Oct 2002 12:48: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 90410912D2 for <[e-mail]>; Thu, 24 Oct 2002 12:48:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 649FF5DE8A; Thu, 24 Oct 2002 12:48:21 -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 4520B5DEB1 for <[e-mail]>; Thu, 24 Oct 2002 12:48:19 -0400 (EDT)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <48ZCD483>; Thu, 24 Oct 2002 22:19:35 +0530
Message-ID: <[e-mail]>
From: "Venu Kumar G - CTD, Chennai." <[e-mail]>
To: Yakov Rekhter <[e-mail]>, "Venu Kumar G - CTD, Chennai." <[e-mail]>
Cc: vrishab sikand <[e-mail]>, Jeffrey Haas <[e-mail]>, [e-mail]
Subject: RE: missing issue - implemented route selections not necessarily  consistant with draft 
Date: Thu, 24 Oct 2002 22:20:29 +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

Hi 

     I agreeing with your point for time being, But It really looks valid
point to me to add  in the base spec and I guess Cisco do consider the
"Originator_ID" /"Cluster list" attributes for Best route selection process
even if we won't enable RR features on the router. My request is, at least
we should add this issue in  next BGP base spec version (..After updating RR
spec with best route selection process), So that we can give the RR spec
reference in the BGP base spec.


Venu

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]]
Sent: Thursday, October 24, 2002 9:43 PM
To: Venu Kumar G - CTD, Chennai.
Cc: vrishab sikand; Jeffrey Haas; [e-mail]
Subject: Re: missing issue - implemented route selections not
necessarily consistant with draft 


Venu,

> Hi,
>             It is quiet possible that, we may receive multiple routes for
> same destination with  varying CLUSTER list length's, even though we are
not
> enabled  ( or Implemented)   RR features on a router.  So i feel we can
add
> this in base spec with indication as  optional to implement. 

If you don't implement the RR spec, then *by definition* you can't
recognize CLUSTER_LIST attribute (as this attribute is defined
in the RR spec). And if you can't recognize the attribute, then you
can't take it into account for your route selection. 

In other words, you either implement the RR spec (and in this case
you also implement the route selection procedures specific to the
RR spec), or you don't (and in this case you can't take into account
various attributes defined in the RR spec).

Yakov.

> This is cisco's best path selection algorithm
>  
>          http://www.cisco.com/warp/public/459/25.shtml
> <http://www.cisco.com/warp/public/459/25.shtml> 
>  
> Venu 
>  
>  
>  
> -----Original Message-----
> From: vrishab sikand [mailto:[e-mail]]
> Sent: Thursday, October 24, 2002 9:16 PM
> To: Yakov Rekhter; Jeffrey Haas
> Cc: [e-mail]
> Subject: Re: missing issue - implemented route selections not necessarily
> consistant with draft 
> 
> 
> 
> The original thought expressed in the route reflector RFC was that: those
> routers which are not configured as route reflectors do not need to have
> "any" knowledge route reflector attributes. This i think was done to ease
> the migration to RR's. 
> 
> 
> I understand that  for the major vendors, even if you are not configured
as
> a RR, they perform these additional steps. So I believe these belong in
the
> main bgp specification. 
> 
> 
> 
>  Yakov Rekhter <[e-mail]> wrote: 
> 
> 
> Jeff,
> 
> > Reviewing my inbox, I think we dropped an issue - or I've misplaced
> > the resolution of it.
> > 
> > Our route selection tie-breaking process in -17 doesn't match at
> > least two of the $LARGE_ROUTER_VENDORs.
> > 
> > Noted differences are (per vrishab sikand):
> > 1) originator ID (to be substituited for router id, when present
> > in path attribute)
> > 2) cluster list length
> > 3) peer id (configured ip address of peer in the neighbor command) 
> 
> These are all have to do with route selection in the presence
> of Route Reflectors. So, these issues have to be covered in the
> Route Reflector spec (the Route Reflector spec has to have a section
> on how Route Reflectors impact BGP Route Selection process).
> 
> Yakov.
> 
> 
> 
> 
>    _____  
> 
> Do you Yahoo!?
> Y! Web Hosting <http://webhosting.yahoo.com/>  - Let the expert host your
> web site
> 
> 
> ------_=_NextPart_001_01C27B77.329D9CF0
> 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">
> 
> 
> <META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
> <BODY>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002>Hi,</SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
>
class=985534615-24102002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb
s
p;&nbsp;&nbsp;&nbsp;It 
> is quiet possible that, we may receive multiple routes for same
destination 
> with&nbsp; varying CLUSTER&nbsp;list length's, even though we are not 
> enabled&nbsp; ( or Implemented)&nbsp;&nbsp; RR features on a router.&nbsp;
So
 
> i&nbsp;feel  we can add this in base spec&nbsp;with indication
as&nbsp;&nbsp;
 
> optional to implement. </SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=985534615-24102002>Thi
s 
> is cisco's best path selection algorithm</SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<A 
>
href="http://www.cisco.com/warp/public/459/25.shtml">http://www.cisco.com/wa
r
p/public/459/25.shtml</A></SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=985534615-24102002>Ven
u 
> </SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT><FONT face=Tahoma
size=2>-----Original
 
> Message-----<BR><B>From:</B> vrishab sikand 
> [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, October 24, 2002
9:16 
> PM<BR><B>To:</B> Yakov Rekhter; Jeffrey Haas<BR><B>Cc:</B> 
> [e-mail]<BR><B>Subject:</B> Re: missing issue - implemented route 
> selections not necessarily consistant with draft <BR><BR></DIV>
> <BLOCKQUOTE></FONT>
>   <P>The original thought expressed in the route reflector RFC was that:
thos
e 
>   routers which are not configured as route reflectors do not need to have
"a
ny" 
>   knowledge route reflector attributes. This i think was done to ease the 
>   migration to RR's. 
>   <P>I&nbsp;understand that &nbsp;for the major vendors, even if you are
not 
>   configured as a RR, they perform these additional steps. So I believe
these
 
>   belong in the main bgp specification. 
>   <P> 
>   <P>&nbsp;<B><I>Yakov Rekhter &lt;[e-mail]&gt;</I></B> wrote: 
>   <BLOCKQUOTE 
>   style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT:
5px"
>Jeff,<BR><BR>&gt; 
>     Reviewing my inbox, I think we dropped an issue - or I've
misplaced<BR>&g
t; 
>     the resolution of it.<BR>&gt; <BR>&gt; Our route selection
tie-breaking 
>     process in -17 doesn't match at<BR>&gt; least two of the 
>     $LARGE_ROUTER_VENDORs.<BR>&gt; <BR>&gt; Noted differences are (per
vrisha
b 
>     sikand):<BR>&gt; 1) originator ID (to be substituited for router id,
when
 
>     present<BR>&gt; in path attribute)<BR>&gt; 2) cluster list
length<BR>&gt;
 3) 
>     peer id (configured ip address of peer in the neighbor command) 
>     <BR><BR>These are all have to do with route selection in the
presence<BR>
of 
>     Route Reflectors. So, these issues have to be covered in the<BR>Route 
>     Reflector spec (the Route Reflector spec has to have a section<BR>on
how 
>     Route Reflectors impact BGP Route Selection 
>   process).<BR><BR>Yakov.</BLOCKQUOTE>
>   <P><BR>
>   <HR SIZE=1>
>   Do you Yahoo!?<BR><A href="http://webhosting.yahoo.com/ ">Y! Web
Hosting</A
> - 
>   Let the expert host your web site</BLOCKQUOTE></BODY></HTML>
> 
> ------_=_NextPart_001_01C27B77.329D9CF0--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA28282 for <[e-mail]>; Thu, 24 Oct 2002 12:27:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4146C912CC; Thu, 24 Oct 2002 12:27:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E877912CF; Thu, 24 Oct 2002 12: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 B611D912CC for <[e-mail]>; Thu, 24 Oct 2002 12:27:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A59E85DEBF; Thu, 24 Oct 2002 12:27: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 20FC05DEBD for <[e-mail]>; Thu, 24 Oct 2002 12:27:31 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9OGROi80167; Thu, 24 Oct 2002 12:27:24 -0400 (EDT) (envelope-from [e-mail])
Received: from SKHtemp.nexthop.com (216-40-174-179.livonia.tir.com [216.40.174.179]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g9OGR2C80153; Thu, 24 Oct 2002 12:27:02 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 24 Oct 2002 12:15:03 -0400
To: [e-mail]
From: Susan Hares <[e-mail]>
Subject: Fwd: Issue 47 - per Andrew's latest list
Cc: [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

This issue is closed per Andrew's latest list.
Please ignore the previous mail.

Sue

>Date: Thu, 24 Oct 2002 11:23:34 -0400
>To: [e-mail]
>From: Susan Hares <[e-mail]>
>Subject: Issue 47
>Cc: yakov Rekhter <[e-mail]>, [e-mail], 
>[e-mail], [e-mail]
>
>
>Issue 47 indicates
>
>  " in most places, the actions taken on receipt of
>    an event include what the new state will be or that it
>    remains unchanged.  But there are a significant number of places
>    where this is not done (Eg Connect state Events 14, 15, 16]"
>
>I believe the text below indicates the state and the events.
>Can I consider this item closed?
>
>Sue Hares
>
>
>
>
>=============
>The text for Connect State is below.  I find Event 13,14,15
>to be have this covered.
>
>
>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.
>
>




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA28191 for <[e-mail]>; Thu, 24 Oct 2002 12:26:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 21F5C912CA; Thu, 24 Oct 2002 12:25:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E56CF912CC; Thu, 24 Oct 2002 12:25: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 B93BE912CA for <[e-mail]>; Thu, 24 Oct 2002 12:25:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A1B805DEBD; Thu, 24 Oct 2002 12:25: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 D4C3E5DEB1 for <[e-mail]>; Thu, 24 Oct 2002 12:25:47 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9OGPj680101; Thu, 24 Oct 2002 12:25:45 -0400 (EDT) (envelope-from [e-mail])
Received: from SKHtemp.nexthop.com (216-40-174-179.livonia.tir.com [216.40.174.179]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g9OGPbC80086; Thu, 24 Oct 2002 12:25:38 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 24 Oct 2002 12:13:47 -0400
To: [e-mail]
From: Susan Hares <[e-mail]>
Subject: Fwd: issue 49 - this issue is closed per Andrew's latest list
Cc: yakov Rekhter <[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

This item is closed.

Sue

>Date: Thu, 24 Oct 2002 11:13:21 -0400
>To: [e-mail]
>From: Susan Hares <[e-mail]>
>Subject: issue 49
>Cc: [e-mail], [e-mail], yakov Rekhter <[e-mail]>
>
>
>Issue 48 indicates that we explictly define BGP message
>processing.  I cannot connect any specific action with
>section 8.0 on the FSM.
>
>Without further text, I cannot process issue 49.
>
>
>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 MAA28116 for <[e-mail]>; Thu, 24 Oct 2002 12:24:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 045C091234; Thu, 24 Oct 2002 12:24:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C43D1912CA; Thu, 24 Oct 2002 12:24: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 ADF0491234 for <[e-mail]>; Thu, 24 Oct 2002 12:24:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8F3AF5DEBD; Thu, 24 Oct 2002 12:24: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 D73005DEB0 for <[e-mail]>; Thu, 24 Oct 2002 12:24:11 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9OGOBv79991 for [e-mail]; Thu, 24 Oct 2002 12:24:11 -0400 (EDT) (envelope-from [e-mail])
Received: from SKHtemp.nexthop.com (216-40-174-179.livonia.tir.com [216.40.174.179]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g9OGO6C79984 for <[e-mail]>; Thu, 24 Oct 2002 12:24:06 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 24 Oct 2002 12:12:14 -0400
To: [e-mail]
From: Susan Hares <[e-mail]>
Subject: Fwd: Issue 41 - FSM Internal Timers
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

I've got Andrew's last list.  This issue is closed.

Sue


>Date: Thu, 24 Oct 2002 10:38:48 -0400
>To: [e-mail]
>From: Susan Hares <[e-mail]>
>Subject: Issue 41 - FSM Internal Timers
>Cc: yakov Rekhter <[e-mail]>, alex Zinin <[e-mail]>, 
>[e-mail]
>
>In section 8.0, 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
>============
>Indicates FSM timers.  Please indicate on whether these timers
>in section 8.0 close issue 41.
>
>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 MAA27394 for <[e-mail]>; Thu, 24 Oct 2002 12:13:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E521591218; Thu, 24 Oct 2002 12:12:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id ACE07912CA; Thu, 24 Oct 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 3104B91218 for <[e-mail]>; Thu, 24 Oct 2002 12:12:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 110355DEB8; Thu, 24 Oct 2002 12:12:50 -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 6FE7A5DEAD for <[e-mail]>; Thu, 24 Oct 2002 12:12: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 g9OGCem19369; Thu, 24 Oct 2002 09:12:40 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Venu Kumar G - CTD, Chennai." <[e-mail]>
Cc: vrishab sikand <[e-mail]>, Jeffrey Haas <[e-mail]>, [e-mail]
Subject: Re: missing issue - implemented route selections not necessarily consistant with draft 
In-Reply-To: Your message of "Thu, 24 Oct 2002 21:35:40 +0530." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 24 Oct 2002 09:12:40 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Venu,

> Hi,
>             It is quiet possible that, we may receive multiple routes for
> same destination with  varying CLUSTER list length's, even though we are not
> enabled  ( or Implemented)   RR features on a router.  So i feel we can add
> this in base spec with indication as  optional to implement. 

If you don't implement the RR spec, then *by definition* you can't
recognize CLUSTER_LIST attribute (as this attribute is defined
in the RR spec). And if you can't recognize the attribute, then you
can't take it into account for your route selection. 

In other words, you either implement the RR spec (and in this case
you also implement the route selection procedures specific to the
RR spec), or you don't (and in this case you can't take into account
various attributes defined in the RR spec).

Yakov.

> This is cisco's best path selection algorithm
>  
>          http://www.cisco.com/warp/public/459/25.shtml
> <http://www.cisco.com/warp/public/459/25.shtml> 
>  
> Venu 
>  
>  
>  
> -----Original Message-----
> From: vrishab sikand [mailto:[e-mail]]
> Sent: Thursday, October 24, 2002 9:16 PM
> To: Yakov Rekhter; Jeffrey Haas
> Cc: [e-mail]
> Subject: Re: missing issue - implemented route selections not necessarily
> consistant with draft 
> 
> 
> 
> The original thought expressed in the route reflector RFC was that: those
> routers which are not configured as route reflectors do not need to have
> "any" knowledge route reflector attributes. This i think was done to ease
> the migration to RR's. 
> 
> 
> I understand that  for the major vendors, even if you are not configured as
> a RR, they perform these additional steps. So I believe these belong in the
> main bgp specification. 
> 
> 
> 
>  Yakov Rekhter <[e-mail]> wrote: 
> 
> 
> Jeff,
> 
> > Reviewing my inbox, I think we dropped an issue - or I've misplaced
> > the resolution of it.
> > 
> > Our route selection tie-breaking process in -17 doesn't match at
> > least two of the $LARGE_ROUTER_VENDORs.
> > 
> > Noted differences are (per vrishab sikand):
> > 1) originator ID (to be substituited for router id, when present
> > in path attribute)
> > 2) cluster list length
> > 3) peer id (configured ip address of peer in the neighbor command) 
> 
> These are all have to do with route selection in the presence
> of Route Reflectors. So, these issues have to be covered in the
> Route Reflector spec (the Route Reflector spec has to have a section
> on how Route Reflectors impact BGP Route Selection process).
> 
> Yakov.
> 
> 
> 
> 
>    _____  
> 
> Do you Yahoo!?
> Y! Web Hosting <http://webhosting.yahoo.com/>  - Let the expert host your
> web site
> 
> 
> ------_=_NextPart_001_01C27B77.329D9CF0
> 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">
> 
> 
> <META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
> <BODY>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002>Hi,</SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
p;&nbsp;&nbsp;&nbsp;It 
> is quiet possible that, we may receive multiple routes for same destination 
> with&nbsp; varying CLUSTER&nbsp;list length's, even though we are not 
> enabled&nbsp; ( or Implemented)&nbsp;&nbsp; RR features on a router.&nbsp; So
 
> i&nbsp;feel  we can add this in base spec&nbsp;with indication as&nbsp;&nbsp;
 
> optional to implement. </SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=985534615-24102002>Thi
s 
> is cisco's best path selection algorithm</SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A 
> href="http://www.cisco.com/warp/public/459/25.shtml">http://www.cisco.com/war
p/public/459/25.shtml</A></SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=985534615-24102002>Ven
u 
> </SPAN></FONT></DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
> <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
> class=985534615-24102002></SPAN></FONT><FONT face=Tahoma size=2>-----Original
 
> Message-----<BR><B>From:</B> vrishab sikand 
> [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, October 24, 2002 9:16 
> PM<BR><B>To:</B> Yakov Rekhter; Jeffrey Haas<BR><B>Cc:</B> 
> [e-mail]<BR><B>Subject:</B> Re: missing issue - implemented route 
> selections not necessarily consistant with draft <BR><BR></DIV>
> <BLOCKQUOTE></FONT>
>   <P>The original thought expressed in the route reflector RFC was that: thos
e 
>   routers which are not configured as route reflectors do not need to have "a
ny" 
>   knowledge route reflector attributes. This i think was done to ease the 
>   migration to RR's. 
>   <P>I&nbsp;understand that &nbsp;for the major vendors, even if you are not 
>   configured as a RR, they perform these additional steps. So I believe these
 
>   belong in the main bgp specification. 
>   <P> 
>   <P>&nbsp;<B><I>Yakov Rekhter &lt;[e-mail]&gt;</I></B> wrote: 
>   <BLOCKQUOTE 
>   style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"
>Jeff,<BR><BR>&gt; 
>     Reviewing my inbox, I think we dropped an issue - or I've misplaced<BR>&g
t; 
>     the resolution of it.<BR>&gt; <BR>&gt; Our route selection tie-breaking 
>     process in -17 doesn't match at<BR>&gt; least two of the 
>     $LARGE_ROUTER_VENDORs.<BR>&gt; <BR>&gt; Noted differences are (per vrisha
b 
>     sikand):<BR>&gt; 1) originator ID (to be substituited for router id, when
 
>     present<BR>&gt; in path attribute)<BR>&gt; 2) cluster list length<BR>&gt;
 3) 
>     peer id (configured ip address of peer in the neighbor command) 
>     <BR><BR>These are all have to do with route selection in the presence<BR>
of 
>     Route Reflectors. So, these issues have to be covered in the<BR>Route 
>     Reflector spec (the Route Reflector spec has to have a section<BR>on how 
>     Route Reflectors impact BGP Route Selection 
>   process).<BR><BR>Yakov.</BLOCKQUOTE>
>   <P><BR>
>   <HR SIZE=1>
>   Do you Yahoo!?<BR><A href="http://webhosting.yahoo.com/ ">Y! Web Hosting</A
> - 
>   Let the expert host your web site</BLOCKQUOTE></BODY></HTML>
> 
> ------_=_NextPart_001_01C27B77.329D9CF0--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA26884 for <[e-mail]>; Thu, 24 Oct 2002 12:04:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1B780912CB; Thu, 24 Oct 2002 12:03:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E499E912D0; Thu, 24 Oct 2002 12: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 6C335912CB for <[e-mail]>; Thu, 24 Oct 2002 12:03:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 52D335DE8A; Thu, 24 Oct 2002 12:03:35 -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 0C06B5DE35 for <[e-mail]>; Thu, 24 Oct 2002 12:03:29 -0400 (EDT)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <48ZCD4A0>; Thu, 24 Oct 2002 21:34:46 +0530
Message-ID: <[e-mail]>
From: "Venu Kumar G - CTD, Chennai." <[e-mail]>
To: vrishab sikand <[e-mail]>, Yakov Rekhter <[e-mail]>, Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: RE: missing issue - implemented route selections not necessarily  consistant with draft 
Date: Thu, 24 Oct 2002 21:35:40 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27B77.329D9CF0"
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_01C27B77.329D9CF0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi,
            It is quiet possible that, we may receive multiple routes for
same destination with  varying CLUSTER list length's, even though we are not
enabled  ( or Implemented)   RR features on a router.  So i feel we can add
this in base spec with indication as   optional to implement. 
 
This is cisco's best path selection algorithm
 
         http://www.cisco.com/warp/public/459/25.shtml
<http://www.cisco.com/warp/public/459/25.shtml> 
 
Venu 
 
 
 
-----Original Message-----
From: vrishab sikand [mailto:[e-mail]]
Sent: Thursday, October 24, 2002 9:16 PM
To: Yakov Rekhter; Jeffrey Haas
Cc: [e-mail]
Subject: Re: missing issue - implemented route selections not necessarily
consistant with draft 



The original thought expressed in the route reflector RFC was that: those
routers which are not configured as route reflectors do not need to have
"any" knowledge route reflector attributes. This i think was done to ease
the migration to RR's. 


I understand that  for the major vendors, even if you are not configured as
a RR, they perform these additional steps. So I believe these belong in the
main bgp specification. 



 Yakov Rekhter <[e-mail]> wrote: 


Jeff,

> Reviewing my inbox, I think we dropped an issue - or I've misplaced
> the resolution of it.
> 
> Our route selection tie-breaking process in -17 doesn't match at
> least two of the $LARGE_ROUTER_VENDORs.
> 
> Noted differences are (per vrishab sikand):
> 1) originator ID (to be substituited for router id, when present
> in path attribute)
> 2) cluster list length
> 3) peer id (configured ip address of peer in the neighbor command) 

These are all have to do with route selection in the presence
of Route Reflectors. So, these issues have to be covered in the
Route Reflector spec (the Route Reflector spec has to have a section
on how Route Reflectors impact BGP Route Selection process).

Yakov.




   _____  

Do you Yahoo!?
Y! Web Hosting <http://webhosting.yahoo.com/>  - Let the expert host your
web site


------_=_NextPart_001_01C27B77.329D9CF0
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">


<META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=985534615-24102002>Hi,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=985534615-24102002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;It 
is quiet possible that, we may receive multiple routes for same destination 
with&nbsp; varying CLUSTER&nbsp;list length's, even though we are not 
enabled&nbsp; ( or Implemented)&nbsp;&nbsp; RR features on a router.&nbsp; So 
i&nbsp;feel  we can add this in base spec&nbsp;with indication as&nbsp;&nbsp; 
optional to implement. </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=985534615-24102002>This 
is cisco's best path selection algorithm</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=985534615-24102002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A 
href="http://www.cisco.com/warp/public/459/25.shtml">http://www.cisco.com/warp/public/459/25.shtml</A></SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=985534615-24102002>Venu 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=985534615-24102002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=985534615-24102002></SPAN></FONT><FONT face=Tahoma size=2>-----Original 
Message-----<BR><B>From:</B> vrishab sikand 
[mailto:[e-mail]]<BR><B>Sent:</B> Thursday, October 24, 2002 9:16 
PM<BR><B>To:</B> Yakov Rekhter; Jeffrey Haas<BR><B>Cc:</B> 
[e-mail]<BR><B>Subject:</B> Re: missing issue - implemented route 
selections not necessarily consistant with draft <BR><BR></DIV>
<BLOCKQUOTE></FONT>
  <P>The original thought expressed in the route reflector RFC was that: those 
  routers which are not configured as route reflectors do not need to have "any" 
  knowledge route reflector attributes. This i think was done to ease the 
  migration to RR's. 
  <P>I&nbsp;understand that &nbsp;for the major vendors, even if you are not 
  configured as a RR, they perform these additional steps. So I believe these 
  belong in the main bgp specification. 
  <P> 
  <P>&nbsp;<B><I>Yakov Rekhter &lt;[e-mail]&gt;</I></B> wrote: 
  <BLOCKQUOTE 
  style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">Jeff,<BR><BR>&gt; 
    Reviewing my inbox, I think we dropped an issue - or I've misplaced<BR>&gt; 
    the resolution of it.<BR>&gt; <BR>&gt; Our route selection tie-breaking 
    process in -17 doesn't match at<BR>&gt; least two of the 
    $LARGE_ROUTER_VENDORs.<BR>&gt; <BR>&gt; Noted differences are (per vrishab 
    sikand):<BR>&gt; 1) originator ID (to be substituited for router id, when 
    present<BR>&gt; in path attribute)<BR>&gt; 2) cluster list length<BR>&gt; 3) 
    peer id (configured ip address of peer in the neighbor command) 
    <BR><BR>These are all have to do with route selection in the presence<BR>of 
    Route Reflectors. So, these issues have to be covered in the<BR>Route 
    Reflector spec (the Route Reflector spec has to have a section<BR>on how 
    Route Reflectors impact BGP Route Selection 
  process).<BR><BR>Yakov.</BLOCKQUOTE>
  <P><BR>
  <HR SIZE=1>
  Do you Yahoo!?<BR><A href="http://webhosting.yahoo.com/ ">Y! Web Hosting</A> - 
  Let the expert host your web site</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C27B77.329D9CF0--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA26764 for <[e-mail]>; Thu, 24 Oct 2002 12:02:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E5E92912C9; Thu, 24 Oct 2002 12:01:12 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD2DA912CA; Thu, 24 Oct 2002 12:01: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 97BCF912C9 for <[e-mail]>; Thu, 24 Oct 2002 12:01:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 718205DE8A; Thu, 24 Oct 2002 12:01:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web12802.mail.yahoo.com (web12802.mail.yahoo.com [216.136.174.37]) by segue.merit.edu (Postfix) with SMTP id 67EDF5DE35 for <[e-mail]>; Thu, 24 Oct 2002 12:00:58 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [208.246.215.128] by web12802.mail.yahoo.com via HTTP; Thu, 24 Oct 2002 09:00:30 PDT
Date: Thu, 24 Oct 2002 09:00:30 -0700 (PDT)
From: vrishab sikand <[e-mail]>
Subject: Re: missing issue - implemented route selections not necessarily consistant with draft 
To: Yakov Rekhter <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-927603142-1035475230=:5044"
Sender: [e-mail]
Precedence: bulk

--0-927603142-1035475230=:5044
Content-Type: text/plain; charset=us-ascii


2.  Design Criteria

   Route Reflection was designed to satisfy the following criteria.

           o Simplicity

             Any alternative must be both simple to configure as well
             as understand.

           o Easy Migration

             It must be possible to migrate from a full mesh
             configuration without the need to change either topology
             or AS. This is an unfortunate management overhead of the
             technique proposed in [3].

           o Compatibility

             It must be possible for non compliant IBGP peers
             to continue be part of the original AS or domain
             without any loss of BGP routing information.

These criteria were motivated by operational experiences of a very
 large and topology rich network with many external connections.



*******************************************************************************************
The above is the design criteria quoted from RFC 2796. They explicitly state design goal is to interoperate with non compliant IBGP neighbors.
Image the case were a routers which dont support router reflector rfc (You may be tempted to say: junk it). If it is deployed in a network in which there are routers which support RR functionality. There will be inconsistent routing

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

 
 Yakov Rekhter <[e-mail]> wrote:Vrishab,

> The original thought expressed in the route reflector RFC was that:
> those rou ters which are not configured as route reflectors do not
> need to have "any" kno wledge route reflector attributes. This i
> think was done to ease the migration to RR's. I understand that
> for the major vendors, even if you are not configured as a RR, they
> perform these additional steps. So I believe these belong in the
> main bgp specification.

The point is not whether a route is *configured* to act as an RR or not.
The point is whether a router *implements* the stuff specified in the
RR spec or not.

Yakov.

> Yakov Rekhter wrote:Jeff,
> 
> > Reviewing my inbox, I think we dropped an issue - or I've misplaced
> > the resolution of it.
> > 
> > Our route selection tie-breaking process in -17 doesn't match at
> > least two of the $LARGE_ROUTER_VENDORs.
> > 
> > Noted differences are (per vrishab sikand):
> > 1) originator ID (to be substituited for router id, when present
> > in path attribute)
> > 2) cluster list length
> > 3) peer id (configured ip address of peer in the neighbor command) 
> 
> These are all have to do with route selection in the presence
> of Route Reflectors. So, these issues have to be covered in the
> Route Reflector spec (the Route Reflector spec has to have a section
> on how Route Reflectors impact BGP Route Selection process).
> 
> Yakov.
> 
> 
> ---------------------------------
> Do you Yahoo!?
> Y! Web Hosting - Let the expert host your web site
> --0-1274477441-1035474355=:88280
> Content-Type: text/html; charset=us-ascii
> 
> 
The original thought expressed in the route reflector RFC was that: those 
routers which are not configured as route reflectors do not need to have "any" 
knowledge route reflector attributes. This i think was done to ease the migrati
on to RR's.
> 
I understand that  for the major vendors, even if you are not co
nfigured as a RR, they perform these additional steps. So I believe these belon
g in the main bgp specification.
> 

> 
 Yakov Rekhter <[e-mail]> wrote:
> Jeff,

> Reviewing my inbox, I think we dropped an issue - 
or I've misplaced
> the resolution of it.
> 
> Our route sele
ction tie-breaking process in -17 doesn't match at
> least two of the $LA
RGE_ROUTER_VENDORs.
> 
> Noted differences are (per vrishab sikand)
:
> 1) originator ID (to be substituited for router id, when present
&
gt; in path attribute)
> 2) cluster list length
> 3) peer id (confi
gured ip address of peer in the neighbor command) 

These are all have to
do with route selection in the presence
of Route Reflectors. So, these issu
es have to be covered in the
Route Reflector spec (the Route Reflector spec 
has to have a section
on how Route Reflectors impact BGP Route Selection pro
cess).

Yakov.


---------------------------------
Do you Yahoo!?

> Y! Web Hosting - Let the expert h
ost your web site
> --0-1274477441-1035474355=:88280--


---------------------------------
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
--0-927603142-1035475230=:5044
Content-Type: text/html; charset=us-ascii

<P>2.&nbsp; Design Criteria<BR><BR>&nbsp;&nbsp; Route Reflection was designed to satisfy the following criteria.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; o Simplicity<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Any alternative must be both simple to configure as well<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as understand.<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; o Easy Migration<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It must be possible to migrate from a full mesh<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; configuration without the need to change either topology<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; or AS. This is an unfortunate management overhead of the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; technique proposed in [3].<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; o Compatibility<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It must be possible for non compliant IBGP peers<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to continue be part of the original AS or domain<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; without any loss of BGP routing information.<BR>
<P>These criteria were motivated by operational experiences of a very<BR>&nbsp;large and topology rich network with many external connections.<BR><BR></P>
<P>*******************************************************************************************
<P>The&nbsp;above is the design criteria quoted from RFC 2796. They explicitly state design goal is to interoperate with non compliant IBGP neighbors.
<P>Image the case were a routers&nbsp;which dont&nbsp;support router reflector rfc (You may be tempted to say: junk it). If it is deployed in a network in which there are routers which support RR functionality. There will be inconsistent routing</P>
<P>**************************************************************************************************</P>
<P>&nbsp;
<P>&nbsp;<B><I>Yakov Rekhter &lt;[e-mail]&gt;</I></B> wrote:
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Vrishab,<BR><BR>&gt; The original thought expressed in the route reflector RFC was that:<BR>&gt; those rou ters which are not configured as route reflectors do not<BR>&gt; need to have "any" kno wledge route reflector attributes. This i<BR>&gt; think was done to ease the migration to RR's. I understand that<BR>&gt; for the major vendors, even if you are not configured as a RR, they<BR>&gt; perform these additional steps. So I believe these belong in the<BR>&gt; main bgp specification.<BR><BR>The point is not whether a route is *configured* to act as an RR or not.<BR>The point is whether a router *implements* the stuff specified in the<BR>RR spec or not.<BR><BR>Yakov.<BR><BR>&gt; Yakov Rekhter <[e-mail]>wrote:Jeff,<BR>&gt; <BR>&gt; &gt; Reviewing my inbox, I think we dropped an issue - or I've misplaced<BR>&gt; &gt; the resolution of it.<BR>&gt; &gt; <BR>&gt; &gt; Our route selection tie-breaking process in -17 doesn't match at<BR>&gt; &gt; least two of the $LARGE_ROUTER_VENDORs.<BR>&gt; &gt; <BR>&gt; &gt; Noted differences are (per vrishab sikand):<BR>&gt; &gt; 1) originator ID (to be substituited for router id, when present<BR>&gt; &gt; in path attribute)<BR>&gt; &gt; 2) cluster list length<BR>&gt; &gt; 3) peer id (configured ip address of peer in the neighbor command) <BR>&gt; <BR>&gt; These are all have to do with route selection in the presence<BR>&gt; of Route Reflectors. So, these issues have to be covered in the<BR>&gt; Route Reflector spec (the Route Reflector spec has to have a section<BR>&gt; on how Route Reflectors impact BGP Route Selection process).<BR>&gt; <BR>&gt; Yakov.<BR>&gt; <BR>&gt; <BR>&gt; ---------------------------------<BR>&gt; Do you Yahoo!?<BR>&gt; Y! Web Hosting - Let the expert host your web site<BR>&gt; --0-1274477441-1035474355=:88280<BR>&gt; Content-Type: text/html; charset=us-ascii<BR>&gt; <BR>&gt; 
<P>The original thought expressed in the route reflector RFC was that: those <BR>routers which are not configured as route reflectors do not need to have "any" <BR>knowledge route reflector attributes. This i think was done to ease the migrati<BR>on to RR's.<BR>&gt; 
<P>I&nbsp;understand that &nbsp;for the major vendors, even if you are not co<BR>nfigured as a RR, they perform these additional steps. So I believe these belon<BR>g in the main bgp specification.<BR>&gt; 
<P><BR>&gt; 
<P>&nbsp;<B><I>Yakov Rekhter &lt;[e-mail]&gt;</I></B> wrote:<BR>&gt; 
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff">Jeff,<BR><BR>&gt; Reviewing my inbox, I think we dropped an issue - <BR>or I've misplaced<BR>&gt; the resolution of it.<BR>&gt; <BR>&gt; Our route sele<BR>ction tie-breaking process in -17 doesn't match at<BR>&gt; least two of the $LA<BR>RGE_ROUTER_VENDORs.<BR>&gt; <BR>&gt; Noted differences are (per vrishab sikand)<BR>:<BR>&gt; 1) originator ID (to be substituited for router id, when present<BR>&amp;<BR>gt; in path attribute)<BR>&gt; 2) cluster list length<BR>&gt; 3) peer id (confi<BR>gured ip address of peer in the neighbor command) <BR><BR>These are all have to<BR>do with route selection in the presence<BR>of Route Reflectors. So, these issu<BR>es have to be covered in the<BR>Route Reflector spec (the Route Reflector spec <BR>has to have a section<BR>on how Route Reflectors impact BGP Route Selection pro<BR>cess).<BR><BR>Yakov.</BLOCKQUOTE>
<P><BR>
<HR SIZE=1>
Do you Yahoo!?<BR><BR>&gt; <A href="http://webhosting.yahoo.com/">Y! Web Hosting</A> - Let the expert h<BR>ost your web site<BR>&gt; --0-1274477441-1035474355=:88280--</BLOCKQUOTE><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://webhosting.yahoo.com/ ">Y! Web Hosting</a> - Let the expert host your web site
--0-927603142-1035475230=:5044--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA26736 for <[e-mail]>; Thu, 24 Oct 2002 12:01:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3F052912C8; Thu, 24 Oct 2002 12:00:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E608912C9; Thu, 24 Oct 2002 12:00: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 E4899912C8 for <[e-mail]>; Thu, 24 Oct 2002 12:00:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3099E5DEB3; Thu, 24 Oct 2002 12:00: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 4E09B5DE35 for <[e-mail]>; Thu, 24 Oct 2002 12:00:38 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9OG0UJ79294; Thu, 24 Oct 2002 12:00:30 -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 g9OG0PC79280; Thu, 24 Oct 2002 12:00:25 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9OG0PS18902; Thu, 24 Oct 2002 12:00:25 -0400 (EDT)
Date: Thu, 24 Oct 2002 12:00:25 -0400
From: Jeffrey Haas <[e-mail]>
To: vrishab sikand <[e-mail]>
Cc: [e-mail]
Subject: Re: missing issue - implemented route selections not necessarily consistant with draft
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, Oct 24, 2002 at 08:45:55AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Oct 24, 2002 at 08:45:55AM -0700, vrishab sikand wrote:
> I understand that  for the major vendors, even if you are not
> configured as a RR, they perform these additional steps. So I
> believe these belong in the main bgp specification.

There is a difference from being a route reflector by configuration
and understanding the path attributes because you have code to support it.

However, this does argue that route reflectors using these
extensions may have inconsitant route-selection when some of the
clients don't understand the extensions.   This is hardly transparent.

-- 
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 LAA26414 for <[e-mail]>; Thu, 24 Oct 2002 11:55:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F05D5912C6; Thu, 24 Oct 2002 11:55:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9A82912C8; Thu, 24 Oct 2002 11:55: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 71086912C6 for <[e-mail]>; Thu, 24 Oct 2002 11:55:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 51F765DEB3; Thu, 24 Oct 2002 11:55: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 E7C045DE35 for <[e-mail]>; Thu, 24 Oct 2002 11:55: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 g9OFtTm17922; Thu, 24 Oct 2002 08:55:29 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Susan Hares <[e-mail]>
Cc: [e-mail]
Subject: Re: FSM issues - first of many discussions 
In-Reply-To: Your message of "Thu, 24 Oct 2002 10:28:59 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 24 Oct 2002 08:55:29 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Sue,

> My understanding from Andrews 10-01-2002 version of the
> IDR issues, is that the following issues did not reach consensus:
> 
> 	4,8,10,11,18,19,24,32,32.1, 34, 39, 41, 45, 46, 47, 48, 49, 53

Just one minor correction. The most recent version of Andrew's document 
lists just the following issues on which there is no consensus:

   11) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1
   32) Clarify EGP Reference
   39) Redundant Sentance Fragments
   45) Consistant References to BGP Peers/Connections/Sessions
   46) FSM Connection Collision Detection
   48) Explicitly Define Processing of Incomming Connections
   53) Section 4.3 - Routes v. Destinations - Advertise
   68) Outbound Loop Detection

Subsequently (after Andrew posted his list) the consensus was
reach on issues 11, 32, 39, 45, 53 and 68.

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 LAA26097 for <[e-mail]>; Thu, 24 Oct 2002 11:50:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5030F912C5; Thu, 24 Oct 2002 11:49:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 68455912CB; Thu, 24 Oct 2002 11:49: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 66F00912CA for <[e-mail]>; Thu, 24 Oct 2002 11:48:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4087A5DEB1; Thu, 24 Oct 2002 11:48: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 ABEBE5DE35 for <[e-mail]>; Thu, 24 Oct 2002 11:48:05 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9OFlRu78785; Thu, 24 Oct 2002 11:47:27 -0400 (EDT) (envelope-from [e-mail])
Received: from SKHtemp.nexthop.com (216-40-174-179.livonia.tir.com [216.40.174.179]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g9OFl7C78768; Thu, 24 Oct 2002 11:47:09 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 24 Oct 2002 11:23:34 -0400
To: [e-mail]
From: Susan Hares <[e-mail]>
Subject: Issue 47
Cc: yakov Rekhter <[e-mail]>, [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

Issue 47 indicates

  " in most places, the actions taken on receipt of
    an event include what the new state will be or that it
    remains unchanged.  But there are a significant number of places
    where this is not done (Eg Connect state Events 14, 15, 16]"

I believe the text below indicates the state and the events.
Can I consider this item closed?

Sue Hares




=============
The text for Connect State is below.  I find Event 13,14,15
to be have this covered.


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.





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA26050 for <[e-mail]>; Thu, 24 Oct 2002 11:50:15 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A1ABF912C4; Thu, 24 Oct 2002 11:49:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4419912C8; Thu, 24 Oct 2002 11:49: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 88672912C3 for <[e-mail]>; Thu, 24 Oct 2002 11:47:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6E9B35DE8F; Thu, 24 Oct 2002 11:47: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 AB2FB5DE35 for <[e-mail]>; Thu, 24 Oct 2002 11:47:57 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9OFl5q78758; Thu, 24 Oct 2002 11:47:05 -0400 (EDT) (envelope-from [e-mail])
Received: from SKHtemp.nexthop.com (216-40-174-179.livonia.tir.com [216.40.174.179]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g9OFkqC78723; Thu, 24 Oct 2002 11:46:53 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 24 Oct 2002 11:05:15 -0400
To: [e-mail]
From: Susan Hares <[e-mail]>
Subject: Issue 46 and 48
Cc: [e-mail], yakov Rekhter <[e-mail]>, [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

I propose putting the text suggested by issue 48 in section 8.2 after

8.2) Description of FSM

8.2.1) FSM connections
	
	(text below)


8.2.2) FSM Definition

(text now in 8.2)


issue 47 suggested the following text:

	"BGP must maintain a separate FSM for each configured peer plus
	Each BGP peer paired in a potential connection unless configured
	to remain in the idle state, or configured to remain passive,
	will attempt to  to connect to the other.  For the purpose of
         this discussion, the active or connect side of the TCP
         connection (the side of a TCP connection (the side sending
         the first TCP SYN packet) is called outgoing.  The passive or
         listening side (the sender of the first SYN ACK) is called
         an incoming connection. [See section on the terms active and
	passive below.]
	
	A BGP implementation must connect to and listen on TCP port 179
	for incoming connections in addition to trying to connect to peers.
	Fro 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 an outgoing
	connection for the same configured peering 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 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.

	There may be more than one connections 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.

	8.2.1.1) Terms "active" and "passive"

	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 per the
	definition above [and the state machine below.] When 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.




In issue 46, Curtis proposed text the following text:
	"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 guidances 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 glad to add this text to section 8. Does it need to be added to the
same section?

Are there any comments on this addition?

Sue Hares





Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA26044 for <[e-mail]>; Thu, 24 Oct 2002 11:50:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id ACE83912C3; Thu, 24 Oct 2002 11:49:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53416912C5; Thu, 24 Oct 2002 11:49: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 01F6B912CC for <[e-mail]>; Thu, 24 Oct 2002 11:48:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CB0745DECC; Thu, 24 Oct 2002 11:48: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 3368A5DEC3 for <[e-mail]>; Thu, 24 Oct 2002 11:48: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 g9OFmNm17574; Thu, 24 Oct 2002 08:48:23 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: vrishab sikand <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>, [e-mail]
Subject: Re: missing issue - implemented route selections not necessarily consistant with draft 
In-Reply-To: Your message of "Thu, 24 Oct 2002 08:45:55 PDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 24 Oct 2002 08:48:23 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Vrishab,

> The original thought expressed in the route reflector RFC was that:
> those rou ters which are not configured as route reflectors do not
> need to have "any" kno wledge route reflector attributes. This i
> think was done to ease the migration to RR's.  I understand that
> for the major vendors, even if you are not configured as a RR, they
> perform these additional steps. So I believe these belong in the
> main bgp specification.

The point is not whether a route is *configured* to act as an RR or not.
The point is whether a router *implements* the stuff specified in the
RR spec or not.

Yakov.

>  Yakov Rekhter <[e-mail]> wrote:Jeff,
> 
> > Reviewing my inbox, I think we dropped an issue - or I've misplaced
> > the resolution of it.
> > 
> > Our route selection tie-breaking process in -17 doesn't match at
> > least two of the $LARGE_ROUTER_VENDORs.
> > 
> > Noted differences are (per vrishab sikand):
> > 1) originator ID (to be substituited for router id, when present
> > in path attribute)
> > 2) cluster list length
> > 3) peer id (configured ip address of peer in the neighbor command) 
> 
> These are all have to do with route selection in the presence
> of Route Reflectors. So, these issues have to be covered in the
> Route Reflector spec (the Route Reflector spec has to have a section
> on how Route Reflectors impact BGP Route Selection process).
> 
> Yakov.
> 
> 
> ---------------------------------
> Do you Yahoo!?
> Y! Web Hosting - Let the expert host your web site
> --0-1274477441-1035474355=:88280
> Content-Type: text/html; charset=us-ascii
> 
> <P>The original thought expressed in the route reflector RFC was that: those 
routers which are not configured as route reflectors do not need to have "any" 
knowledge route reflector attributes. This i think was done to ease the migrati
on to RR's.
> <P>I&nbsp;understand that &nbsp;for the major vendors, even if you are not co
nfigured as a RR, they perform these additional steps. So I believe these belon
g in the main bgp specification.
> <P>&nbsp;
> <P>&nbsp;<B><I>Yakov Rekhter &lt;[e-mail]&gt;</I></B> wrote:
> <BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 
2px solid">Jeff,<BR><BR>&gt; Reviewing my inbox, I think we dropped an issue - 
or I've misplaced<BR>&gt; the resolution of it.<BR>&gt; <BR>&gt; Our route sele
ction tie-breaking process in -17 doesn't match at<BR>&gt; least two of the $LA
RGE_ROUTER_VENDORs.<BR>&gt; <BR>&gt; Noted differences are (per vrishab sikand)
:<BR>&gt; 1) originator ID (to be substituited for router id, when present<BR>&
gt; in path attribute)<BR>&gt; 2) cluster list length<BR>&gt; 3) peer id (confi
gured ip address of peer in the neighbor command) <BR><BR>These are all have to
 do with route selection in the presence<BR>of Route Reflectors. So, these issu
es have to be covered in the<BR>Route Reflector spec (the Route Reflector spec 
has to have a section<BR>on how Route Reflectors impact BGP Route Selection pro
cess).<BR><BR>Yakov.</BLOCKQUOTE><p><br><hr size=1>Do you Yahoo!?<br>
> <a href="http://webhosting.yahoo.com/ ">Y! Web Hosting</a> - Let the expert h
ost your web site
> --0-1274477441-1035474355=:88280--


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 LAA26018 for <[e-mail]>; Thu, 24 Oct 2002 11:49:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D1DDF912CD; Thu, 24 Oct 2002 11:48:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9FF1912C4; Thu, 24 Oct 2002 11:48: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 6D6E4912C6 for <[e-mail]>; Thu, 24 Oct 2002 11:47:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4EF955DE8F; Thu, 24 Oct 2002 11:47: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 8F0545DE35 for <[e-mail]>; Thu, 24 Oct 2002 11:47:33 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9OFkw978734; Thu, 24 Oct 2002 11:46:58 -0400 (EDT) (envelope-from [e-mail])
Received: from SKHtemp.nexthop.com (216-40-174-179.livonia.tir.com [216.40.174.179]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g9OFkdC78699; Thu, 24 Oct 2002 11:46:39 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 24 Oct 2002 10:38:48 -0400
To: [e-mail]
From: Susan Hares <[e-mail]>
Subject: Issue 41 - FSM Internal Timers
Cc: yakov Rekhter <[e-mail]>, alex Zinin <[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

In section 8.0, 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
============
Indicates FSM timers.  Please indicate on whether these timers
in section 8.0 close issue 41.

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 LAA26003 for <[e-mail]>; Thu, 24 Oct 2002 11:49:36 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E1396912CE; Thu, 24 Oct 2002 11:48:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04A98912C6; Thu, 24 Oct 2002 11:48: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 035DA912C8 for <[e-mail]>; Thu, 24 Oct 2002 11:47:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D4EAB5DE35; Thu, 24 Oct 2002 11:47: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 1AAFF5DE8F for <[e-mail]>; Thu, 24 Oct 2002 11:47:43 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9OFlA678772; Thu, 24 Oct 2002 11:47:10 -0400 (EDT) (envelope-from [e-mail])
Received: from SKHtemp.nexthop.com (216-40-174-179.livonia.tir.com [216.40.174.179]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g9OFl0C78750; Thu, 24 Oct 2002 11:47:01 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 24 Oct 2002 11:13:21 -0400
To: [e-mail]
From: Susan Hares <[e-mail]>
Subject: issue 49
Cc: [e-mail], [e-mail], yakov Rekhter <[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

Issue 48 indicates that we explictly define BGP message
processing.  I cannot connect any specific action with
section 8.0 on the FSM.

Without further text, I cannot process issue 49.


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 LAA25965 for <[e-mail]>; Thu, 24 Oct 2002 11:48:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2A520912C2; Thu, 24 Oct 2002 11:46:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF8D5912C3; Thu, 24 Oct 2002 11:46: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 CC731912C2 for <[e-mail]>; Thu, 24 Oct 2002 11:46:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A55B25DEB3; Thu, 24 Oct 2002 11: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 E97195DE8F for <[e-mail]>; Thu, 24 Oct 2002 11:46:39 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9OFkc778698 for [e-mail]; Thu, 24 Oct 2002 11:46:38 -0400 (EDT) (envelope-from [e-mail])
Received: from SKHtemp.nexthop.com (216-40-174-179.livonia.tir.com [216.40.174.179]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g9OFkWC78683 for <[e-mail]>; Thu, 24 Oct 2002 11:46:32 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 24 Oct 2002 10:28:59 -0400
To: [e-mail]
From: Susan Hares <[e-mail]>
Subject: FSM issues - first of many discussions
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

My understanding from Andrews 10-01-2002 version of the
IDR issues, is that the following issues did not reach consensus:

	4,8,10,11,18,19,24,32,32.1, 34, 39, 41, 45, 46, 47, 48, 49, 53

Of these issues, I believe the following are associated with the
FSM portion of the specification:

	41 - Mention the FSM Internal Timers
	46 - FSM Connection Collision Detections
  	47 - FSM - Add Explicit State Changing wording
	48 - Explicitly Defined Processing of Incomming Connections
	49 - Explicitly Define Event Generation

Please let know if any other "non-consensus" issues are related
to the state machine.

I would like to examine these issue to reach the consensus needed
for me to re-edit the base draft wording.

If you have comments associated with these issues
on the BGP FSM draft (ietf-draft-hares-statmt-02.txt) or the
BGP Peer Persistent Oscillation (ietf-draft-hares-backoff-01.txt).
associated with these issues, please clearly state which draft you
are commenting on.

Sue Hares
[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 LAA25847 for <[e-mail]>; Thu, 24 Oct 2002 11:46:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8C0B7912C1; Thu, 24 Oct 2002 11:45:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 534B0912C2; Thu, 24 Oct 2002 11:45: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 E67BD912C1 for <[e-mail]>; Thu, 24 Oct 2002 11:45:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BB4265DEB8; Thu, 24 Oct 2002 11:45:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web12803.mail.yahoo.com (web12803.mail.yahoo.com [216.136.174.38]) by segue.merit.edu (Postfix) with SMTP id 464845DEBF for <[e-mail]>; Thu, 24 Oct 2002 11:45:56 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [208.246.215.128] by web12803.mail.yahoo.com via HTTP; Thu, 24 Oct 2002 08:45:55 PDT
Date: Thu, 24 Oct 2002 08:45:55 -0700 (PDT)
From: vrishab sikand <[e-mail]>
Subject: Re: missing issue - implemented route selections not necessarily consistant with draft 
To: Yakov Rekhter <[e-mail]>, Jeffrey Haas <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1274477441-1035474355=:88280"
Sender: [e-mail]
Precedence: bulk

--0-1274477441-1035474355=:88280
Content-Type: text/plain; charset=us-ascii


The original thought expressed in the route reflector RFC was that: those routers which are not configured as route reflectors do not need to have "any" knowledge route reflector attributes. This i think was done to ease the migration to RR's.
I understand that  for the major vendors, even if you are not configured as a RR, they perform these additional steps. So I believe these belong in the main bgp specification.
 
 Yakov Rekhter <[e-mail]> wrote:Jeff,

> Reviewing my inbox, I think we dropped an issue - or I've misplaced
> the resolution of it.
> 
> Our route selection tie-breaking process in -17 doesn't match at
> least two of the $LARGE_ROUTER_VENDORs.
> 
> Noted differences are (per vrishab sikand):
> 1) originator ID (to be substituited for router id, when present
> in path attribute)
> 2) cluster list length
> 3) peer id (configured ip address of peer in the neighbor command) 

These are all have to do with route selection in the presence
of Route Reflectors. So, these issues have to be covered in the
Route Reflector spec (the Route Reflector spec has to have a section
on how Route Reflectors impact BGP Route Selection process).

Yakov.


---------------------------------
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
--0-1274477441-1035474355=:88280
Content-Type: text/html; charset=us-ascii

<P>The original thought expressed in the route reflector RFC was that: those routers which are not configured as route reflectors do not need to have "any" knowledge route reflector attributes. This i think was done to ease the migration to RR's.
<P>I&nbsp;understand that &nbsp;for the major vendors, even if you are not configured as a RR, they perform these additional steps. So I believe these belong in the main bgp specification.
<P>&nbsp;
<P>&nbsp;<B><I>Yakov Rekhter &lt;[e-mail]&gt;</I></B> wrote:
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">Jeff,<BR><BR>&gt; Reviewing my inbox, I think we dropped an issue - or I've misplaced<BR>&gt; the resolution of it.<BR>&gt; <BR>&gt; Our route selection tie-breaking process in -17 doesn't match at<BR>&gt; least two of the $LARGE_ROUTER_VENDORs.<BR>&gt; <BR>&gt; Noted differences are (per vrishab sikand):<BR>&gt; 1) originator ID (to be substituited for router id, when present<BR>&gt; in path attribute)<BR>&gt; 2) cluster list length<BR>&gt; 3) peer id (configured ip address of peer in the neighbor command) <BR><BR>These are all have to do with route selection in the presence<BR>of Route Reflectors. So, these issues have to be covered in the<BR>Route Reflector spec (the Route Reflector spec has to have a section<BR>on how Route Reflectors impact BGP Route Selection process).<BR><BR>Yakov.</BLOCKQUOTE><p><br><hr size=1>Do you Yahoo!?<br>
<a href="http://webhosting.yahoo.com/ ">Y! Web Hosting</a> - Let the expert host your web site
--0-1274477441-1035474355=:88280--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA25409 for <[e-mail]>; Thu, 24 Oct 2002 11:38:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A0B0C912C0; Thu, 24 Oct 2002 11:38:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70040912C1; Thu, 24 Oct 2002 11:38: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 1D495912C0 for <[e-mail]>; Thu, 24 Oct 2002 11:38:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0BFA35DEB3; Thu, 24 Oct 2002 11:38: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 BA5B35DEB1 for <[e-mail]>; Thu, 24 Oct 2002 11:38:13 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT9CLN>; Thu, 24 Oct 2002 11:38:13 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: using default route to reach peer
Date: Thu, 24 Oct 2002 11:38:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Also, are there other implementations that have this restriction?

-----Original Message-----
From: Natale, Jonathan 
Sent: Thursday, October 24, 2002 11:37 AM
To: [e-mail]
Subject: using default route to reach peer


Folks,

IOS does not allow a BGP peer to be reached via the default route.  This
seems like a good rule to me.  Is this specified in the/a RFC/Draft
somewhere?  Should it be added as a "MAY"?

Thank You,
-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 LAA25356 for <[e-mail]>; Thu, 24 Oct 2002 11:37:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3BF7A912BF; Thu, 24 Oct 2002 11:37:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9CB9912C0; Thu, 24 Oct 2002 11:37: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 323DF912BF for <[e-mail]>; Thu, 24 Oct 2002 11:37:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 17C935DEB1; Thu, 24 Oct 2002 11:37: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 C83105DEAD for <[e-mail]>; Thu, 24 Oct 2002 11:37:01 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT9CL1>; Thu, 24 Oct 2002 11:37:01 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: using default route to reach peer
Date: Thu, 24 Oct 2002 11:37:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Folks,

IOS does not allow a BGP peer to be reached via the default route.  This
seems like a good rule to me.  Is this specified in the/a RFC/Draft
somewhere?  Should it be added as a "MAY"?

Thank You,
-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 LAA25349 for <[e-mail]>; Thu, 24 Oct 2002 11:37:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DB28A912BC; Thu, 24 Oct 2002 11:36:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A28ED912BF; Thu, 24 Oct 2002 11:36: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 8A816912BC for <[e-mail]>; Thu, 24 Oct 2002 11:36:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6E2D35DEAF; Thu, 24 Oct 2002 11:36: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 B35235DEAD for <[e-mail]>; Thu, 24 Oct 2002 11:36:55 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9OFasF78223; Thu, 24 Oct 2002 11:36:54 -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 g9OFapC78215; Thu, 24 Oct 2002 11:36:51 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9OFaps18498; Thu, 24 Oct 2002 11:36:51 -0400 (EDT)
Date: Thu, 24 Oct 2002 11:36:51 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: missing issue - implemented route selections not necessarily consistant with draft
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, Oct 24, 2002 at 08:33:44AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Thu, Oct 24, 2002 at 08:33:44AM -0700, Yakov Rekhter wrote:
> These are all have to do with route selection in the presence
> of Route Reflectors. So, these issues have to be covered in the
> Route Reflector spec (the Route Reflector spec has to have a section
> on how Route Reflectors impact BGP Route Selection process).

Thanks.  That addresses my concern.

Hopefully Andrew will add this to his Codex Errata for route reflectors.

> 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 LAA25193 for <[e-mail]>; Thu, 24 Oct 2002 11:34:25 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DB1E2912BD; Thu, 24 Oct 2002 11:33:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0896912BE; Thu, 24 Oct 2002 11:33: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 5CA7C912BD for <[e-mail]>; Thu, 24 Oct 2002 11:33:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 33CEE5DEB3; Thu, 24 Oct 2002 11:33: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 C6A825DEAF for <[e-mail]>; Thu, 24 Oct 2002 11:33: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 g9OFXim16630; Thu, 24 Oct 2002 08:33:44 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: missing issue - implemented route selections not necessarily consistant with draft 
In-Reply-To: Your message of "Thu, 24 Oct 2002 10:57:54 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 24 Oct 2002 08:33:44 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> Reviewing my inbox, I think we dropped an issue - or I've misplaced
> the resolution of it.
> 
> Our route selection tie-breaking process in -17 doesn't match at
> least two of the $LARGE_ROUTER_VENDORs.
> 
> Noted differences are (per vrishab sikand):
> 1) originator ID (to be substituited for router id, when present
> in path attribute)
> 2) cluster list length
> 3) peer id (configured ip address of peer in the neighbor command)    

These are all have to do with route selection in the presence
of Route Reflectors. So, these issues have to be covered in the
Route Reflector spec (the Route Reflector spec has to have a section
on how Route Reflectors impact BGP Route Selection process).

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 KAA23964 for <[e-mail]>; Thu, 24 Oct 2002 10:58:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A50E6912B8; Thu, 24 Oct 2002 10:58:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E756912B9; Thu, 24 Oct 2002 10:58: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 5C85E912B8 for <[e-mail]>; Thu, 24 Oct 2002 10:57:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 42E545DEB6; Thu, 24 Oct 2002 10:57: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 8349F5DEB3 for <[e-mail]>; Thu, 24 Oct 2002 10:57:58 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9OEvv976936 for [e-mail]; Thu, 24 Oct 2002 10:57: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 g9OEvsC76929 for <[e-mail]>; Thu, 24 Oct 2002 10:57:54 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9OEvsq18350 for [e-mail]; Thu, 24 Oct 2002 10:57:54 -0400 (EDT)
Date: Thu, 24 Oct 2002 10:57:54 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: missing issue - implemented route selections not necessarily consistant with draft
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Reviewing my inbox, I think we dropped an issue - or I've misplaced
the resolution of it.

Our route selection tie-breaking process in -17 doesn't match at
least two of the $LARGE_ROUTER_VENDORs.

Noted differences are (per vrishab sikand):
1) originator ID (to be substituited for router id, when present
in path attribute)
2) cluster list length
3) peer id (configured ip address of peer in the neighbor command)    

-- 
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 PAA22437 for <[e-mail]>; Wed, 23 Oct 2002 15:33:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5DE8891294; Wed, 23 Oct 2002 15:33:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2763C91295; Wed, 23 Oct 2002 15: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 6DE2891294 for <[e-mail]>; Wed, 23 Oct 2002 15:33:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 512535DE28; Wed, 23 Oct 2002 15:33: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 B42835DE25 for <[e-mail]>; Wed, 23 Oct 2002 15:33: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 g9NJXMm52027; Wed, 23 Oct 2002 12:33:22 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 46 - FSM Connection Collision Detection
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 23 Oct 2002 12:33:22 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

[clipped...]

> With the additional FSM text contained in issue 48, I think we're
> mostly good here.  However, given the complexity of the issue
> (where is the current text - which is the canonical version, etc.)
> I would like to see the text in a complete form before suggesting
> we declare consensus on this.
> 
> Yakov - what is the hope of getting a -18 candidate posted including
> all consensus changes for review?

I am waiting for Sue to provide me with the FSM text (Section 8)
that reflects the comments we received. The rest of the comments
have been incorporated already.

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 MAA11030 for <[e-mail]>; Wed, 23 Oct 2002 12:14:25 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9E26C91281; Wed, 23 Oct 2002 12:12:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53A4991284; Wed, 23 Oct 2002 12: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 B4C5F91281 for <[e-mail]>; Wed, 23 Oct 2002 12:11:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A1D9C5DE0C; Wed, 23 Oct 2002 12:11: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 62A5B5DDA8 for <[e-mail]>; Wed, 23 Oct 2002 12:11:53 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT87RR>; Wed, 23 Oct 2002 12:11:52 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: RE: Issue 39 - Redundant Sentance Fragments 
Date: Wed, 23 Oct 2002 12:11:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

agreed (let's not belabor this trivial point)

:-)

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, October 23, 2002 11:21 AM
To: Jeffrey Haas
Cc: [e-mail]
Subject: Re: Issue 39 - Redundant Sentance Fragments 


Jeff,

> > 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.
> > 
> > Yakov agreed to drop the third and fourth parentheses in the -18 
> > version.
> > 
> > Jonathan replied to this:
> > 
> > Disagree, the text if fine the way it is, except you need to change 
> > "shorted" to "shorter".
> 
> This sounds like consensus to me - especially if we're quibbling about 
> a typo. :-)

Yes, indeed we have a consesus - fix the typo and drop the third and 
fourth parentheses.

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 LAA08312 for <[e-mail]>; Wed, 23 Oct 2002 11:27:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CE1999127E; Wed, 23 Oct 2002 11:26:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9FE6C9127F; Wed, 23 Oct 2002 11: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 5CF6C9127E for <[e-mail]>; Wed, 23 Oct 2002 11:26:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 468055DE20; Wed, 23 Oct 2002 11:26: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 74AE45DE1D for <[e-mail]>; Wed, 23 Oct 2002 11:26:23 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9NFQL947662; Wed, 23 Oct 2002 11:26: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 g9NFQIC47655; Wed, 23 Oct 2002 11:26:18 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9NFQIj13133; Wed, 23 Oct 2002 11:26:18 -0400 (EDT)
Date: Wed, 23 Oct 2002 11:26:18 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: Issue 45 - Consistant References to BGP Peers/Connections/Sessions
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, Oct 23, 2002 at 08:17:56AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Wed, Oct 23, 2002 at 08:17:56AM -0700, Yakov Rekhter wrote:
> If we are to use "BGP session" instead of "BGP connection", we
> would talk about "Session collision" not "connection collision".
> 
> I would prefer to use "BGP connection".

I can see that.

A stronger argument is perhaps the fact that our notification messages
have always said "connection not synchronized".  Given that implementors
have often used the words from this text in their CLI/GUI/SNMP
implementation, its probably best to stay with "connection".

I yield to your argument. :-)

> 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 LAA08019 for <[e-mail]>; Wed, 23 Oct 2002 11:21:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EC15B9127C; Wed, 23 Oct 2002 11:21:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBC5B9127D; Wed, 23 Oct 2002 11:21: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 975FB9127C for <[e-mail]>; Wed, 23 Oct 2002 11:20:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 823AC5DE1D; Wed, 23 Oct 2002 11:20: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 20EC35DE12 for <[e-mail]>; Wed, 23 Oct 2002 11:20: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 g9NFKvm30669; Wed, 23 Oct 2002 08:20:57 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 39 - Redundant Sentance Fragments 
In-Reply-To: Your message of "Wed, 23 Oct 2002 10:56:04 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 23 Oct 2002 08:20:57 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> > 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.
> > 
> > Yakov agreed to drop the third and fourth parentheses in the -18 version.
> > 
> > Jonathan replied to this:
> > 
> > Disagree, the text if fine the way it is, except you need to change
> > "shorted" to "shorter".
> 
> This sounds like consensus to me - especially if we're quibbling about
> a typo. :-)

Yes, indeed we have a consesus - fix the typo and drop the third and 
fourth parentheses.

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 LAA07880 for <[e-mail]>; Wed, 23 Oct 2002 11:18:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A6AA89127B; Wed, 23 Oct 2002 11:18:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 767689127C; Wed, 23 Oct 2002 11:18: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 4EBE89127B for <[e-mail]>; Wed, 23 Oct 2002 11:17:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 357475DE17; Wed, 23 Oct 2002 11:17: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 C94BC5DE12 for <[e-mail]>; Wed, 23 Oct 2002 11:17: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 g9NFHum30437; Wed, 23 Oct 2002 08:17:56 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 45 - Consistant References to BGP Peers/Connections/Sessions 
In-Reply-To: Your message of "Wed, 23 Oct 2002 11:06:29 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 23 Oct 2002 08:17:56 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> > 45) Consistant References to BGP Peers/Connections/Sessions
> 
> In general, the cleanup is appropriate.  The only change would
> be agreeing with Alex:
> 
> > "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") 
> 
> Thus, consistantly use "BGP session".
> 
> Aside from converging on this point, I think we have reached consensus.
> 
> Are there arguments to keep this "BGP connection"?

If we are to use "BGP session" instead of "BGP connection", we
would talk about "Session collision" not "connection collision".

I would prefer to use "BGP connection".

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 LAA07760 for <[e-mail]>; Wed, 23 Oct 2002 11:16:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5BC189127A; Wed, 23 Oct 2002 11:15:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B7819127B; Wed, 23 Oct 2002 11:15: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 D6A309127A for <[e-mail]>; Wed, 23 Oct 2002 11:15:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BEA3C5DE1D; Wed, 23 Oct 2002 11:15: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 93E975DE12 for <[e-mail]>; Wed, 23 Oct 2002 11:15:15 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9NFFEL47187 for [e-mail]; Wed, 23 Oct 2002 11:15: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 g9NFFBC47176 for <[e-mail]>; Wed, 23 Oct 2002 11:15:11 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9NFFBT13085 for [e-mail]; Wed, 23 Oct 2002 11:15:11 -0400 (EDT)
Date: Wed, 23 Oct 2002 11:15:11 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Issue 46 - FSM Connection Collision Detection
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, Oct 22, 2002 at 07:02:19PM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

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

With the additional FSM text contained in issue 48, I think we're
mostly good here.  However, given the complexity of the issue
(where is the current text - which is the canonical version, etc.)
I would like to see the text in a complete form before suggesting
we declare consensus on this.

Yakov - what is the hope of getting a -18 candidate posted including
all consensus changes for review?

-- Jeff


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA07525 for <[e-mail]>; Wed, 23 Oct 2002 11:13:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D9AB6912D8; Wed, 23 Oct 2002 11:07:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1605A912D2; Wed, 23 Oct 2002 11:07: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 1969E912D9 for <[e-mail]>; Wed, 23 Oct 2002 11:06:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 097885DE16; Wed, 23 Oct 2002 11:06: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 2BA055DE17 for <[e-mail]>; Wed, 23 Oct 2002 11:06:38 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9NF6b046879 for [e-mail]; Wed, 23 Oct 2002 11:06: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 g9NF6TC46861 for <[e-mail]>; Wed, 23 Oct 2002 11:06:29 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9NF6Tj13046 for [e-mail]; Wed, 23 Oct 2002 11:06:29 -0400 (EDT)
Date: Wed, 23 Oct 2002 11:06:29 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Issue 45 - Consistant References to BGP Peers/Connections/Sessions
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, Oct 22, 2002 at 07:02:19PM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

> 45) Consistant References to BGP Peers/Connections/Sessions

In general, the cleanup is appropriate.  The only change would
be agreeing with Alex:

> "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") 

Thus, consistantly use "BGP session".

Aside from converging on this point, I think we have reached consensus.

Are there arguments to keep this "BGP connection"?

-- 
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 LAA07254 for <[e-mail]>; Wed, 23 Oct 2002 11:08:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 86A10912A1; Wed, 23 Oct 2002 10:57:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A640B912A4; Wed, 23 Oct 2002 10: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 72B4A9129E for <[e-mail]>; Wed, 23 Oct 2002 10:56:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5DDBF5DE18; Wed, 23 Oct 2002 10:56: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 B21AD5DDDC for <[e-mail]>; Wed, 23 Oct 2002 10:56:11 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9NEuAu46431 for [e-mail]; Wed, 23 Oct 2002 10: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 g9NEu4C46417 for <[e-mail]>; Wed, 23 Oct 2002 10:56:04 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9NEu4a13005 for [e-mail]; Wed, 23 Oct 2002 10:56:04 -0400 (EDT)
Date: Wed, 23 Oct 2002 10:56:04 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Issue 39 - Redundant Sentance Fragments 
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, Oct 22, 2002 at 07:02:19PM -0700
X-Virus-Scanned: by AMaViS perl-11
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.
> 
> Yakov agreed to drop the third and fourth parentheses in the -18 version.
> 
> Jonathan replied to this:
> 
> Disagree, the text if fine the way it is, except you need to change
> "shorted" to "shorter".

This sounds like consensus to me - especially if we're quibbling about
a typo. :-)

-- Jeff


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA07109 for <[e-mail]>; Wed, 23 Oct 2002 11:05:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 03B8091299; Wed, 23 Oct 2002 10:56:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9CCB1912A1; Wed, 23 Oct 2002 10:56: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 4171391299 for <[e-mail]>; Wed, 23 Oct 2002 10:56:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 300C55DE1F; Wed, 23 Oct 2002 10: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 C2E5E5DE18 for <[e-mail]>; Wed, 23 Oct 2002 10:56: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 g9NEu4m28970; Wed, 23 Oct 2002 07:56:04 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 68 - outbound loop detection 
In-Reply-To: Your message of "Wed, 23 Oct 2002 10:34:43 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 23 Oct 2002 07:56:04 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> > Status: No Consensus
> > Change: Potentially
> > Summary: IFF we have two implementations, we'd consider including this in
> >   the base spec.
> >  
> > Discussion:
> > 
> > Jonathan brought up that:
> > 
> > This paper (thanks Jeff)
> 
> Since my name is brought up, I thought I'd offer an opinion. :-)
> 
> > http://www.research.microsoft.com/scripts/pubs/view.asp?TR_ID=MSR-TR-2000-0
> > indicates that it
> > is better to do the loop detection outbound as well inbound.  The current
> > draft indicates that
> > it only needs to be done inbound.  IOS does it inbound as well as outbound.
> > GateD/Juniper
> > does it (did it ???) only inbound.
> > 
> > So I propose we add:
> > "An implementation MAY choose to not advertise routes to EBGP peers if these
> > routes contain
> > the AS of that peer in the AS path."
> > after:
> > "If the autonomous system number appears in the AS path the route may be
> > stored in the
> > Adj-RIB In, but unless the router is configured to accept routes with its
> > own AS in the
> > AS path, the route shall not be passed to the BGP Decision Process."
> > 
> > *If there is at least one other implementation that does outbound
> > pruning/loop-detection.*
> 
> My suggestion is that this can stay out of the base draft.  While it
> is true that this speeds up convergence (per the paper), it doesn't
> affect interoperability.
> 
> Also, adding this specifically removes the ability from several 
> implementations to be able to bridge a partitioned AS by permitting
> loops.  (I'm not going to argue whether this is a Good way to do this,
> just that its done.)
> 
> Its also worth noting that one could produce the same resultant speed-up
> by detecting the loop on an outbound basis and *not* applying the
> min*timers to the UPDATE.  Thus, this would be a case of an advertisement
> of NLRI being treated the same, timer-wise, as the advertisement of
> WD_NLRI.
> 
> I would suggest moving this suggestion for outbound loop detection
> in one form or another to the 1772 replacement.

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 LAA06709 for <[e-mail]>; Wed, 23 Oct 2002 11:00:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2479A91291; Wed, 23 Oct 2002 10:55:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E00F791296; Wed, 23 Oct 2002 10:55: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 5C83991291 for <[e-mail]>; Wed, 23 Oct 2002 10:55:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 495335DE1C; Wed, 23 Oct 2002 10: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 A85355DE07 for <[e-mail]>; Wed, 23 Oct 2002 10:55: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 g9NEtAm28933; Wed, 23 Oct 2002 07:55:10 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 32 - Clarify EGP Reference 
In-Reply-To: Your message of "Wed, 23 Oct 2002 10:42:41 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 23 Oct 2002 07:55:10 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> > ---------------------------------------------------------------------------
> > 32) Clarify EGP Reference
> > ---------------------------------------------------------------------------
-
> 
> I'd like to propose that all of the issues here have been addressed
> by 32.1 and we close this one.
> 
> If others disagree, could you note what your perception of remaining
> issues are?

Agreed.

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 KAA06680 for <[e-mail]>; Wed, 23 Oct 2002 10:59:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4B0199128F; Wed, 23 Oct 2002 10:54:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15C9B91290; Wed, 23 Oct 2002 10:54: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 3C0229128F for <[e-mail]>; Wed, 23 Oct 2002 10:54:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2918F5DE18; Wed, 23 Oct 2002 10:54: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 BBC305DDDC for <[e-mail]>; Wed, 23 Oct 2002 10:54: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 g9NEsTm28894; Wed, 23 Oct 2002 07:54:29 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 11 - Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1 
In-Reply-To: Your message of "Wed, 23 Oct 2002 10:47:26 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 23 Oct 2002 07:54:29 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> > 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."
> 
> With the exception that Routing Table should be capitalized throughout,
> I'd suggest we take this as consensus.

Agreed.

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 KAA06543 for <[e-mail]>; Wed, 23 Oct 2002 10:57:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 34C7191285; Wed, 23 Oct 2002 10:53:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C36BD91283; Wed, 23 Oct 2002 10:53: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 6539B91287 for <[e-mail]>; Wed, 23 Oct 2002 10:53:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7BC495DE12; Wed, 23 Oct 2002 10:53: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 8B3FB5DDDC for <[e-mail]>; Wed, 23 Oct 2002 10:53:41 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9NEred46244 for [e-mail]; Wed, 23 Oct 2002 10:53: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 g9NErbC46237 for <[e-mail]>; Wed, 23 Oct 2002 10:53:37 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9NErbt12982 for [e-mail]; Wed, 23 Oct 2002 10:53:37 -0400 (EDT)
Date: Wed, 23 Oct 2002 10:53:37 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Issue 48 - Explicitly Define Processing of Incomming 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 Tue, Oct 22, 2002 at 07:02:19PM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

> Curtis later proposed this text:

Most of which I'm in violent agreement with. :-)

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

Its important to note that BGP Identifier is only important if the
rest of the Open is valid.  For example, we must first get past
AS number, hold time values, capabilities, etc.

> The FSM stays around as long as "BGP Identifier" is not known.

Or may be immediately aborted if the rest of the OPEN is rejected.


-- 
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 KAA06221 for <[e-mail]>; Wed, 23 Oct 2002 10:51:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1E20E91278; Wed, 23 Oct 2002 10:48:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 815BC9127A; Wed, 23 Oct 2002 10: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 BF2B891276 for <[e-mail]>; Wed, 23 Oct 2002 10:47:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9CAF45DE12; Wed, 23 Oct 2002 10:47: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 B28945DE0B for <[e-mail]>; Wed, 23 Oct 2002 10:47:30 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9NElTG46052 for [e-mail]; Wed, 23 Oct 2002 10:47:29 -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 g9NElQC46045 for <[e-mail]>; Wed, 23 Oct 2002 10:47:26 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9NElQs12964 for [e-mail]; Wed, 23 Oct 2002 10:47:26 -0400 (EDT)
Date: Wed, 23 Oct 2002 10:47:26 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Issue 11 - Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.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 Tue, Oct 22, 2002 at 07:02:19PM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

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

With the exception that Routing Table should be capitalized throughout,
I'd suggest we take this as consensus.

-- Jeff


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA06216 for <[e-mail]>; Wed, 23 Oct 2002 10:51:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DFF1891276; Wed, 23 Oct 2002 10:48:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79BB69127C; Wed, 23 Oct 2002 10: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 06B0291278 for <[e-mail]>; Wed, 23 Oct 2002 10:47:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B92085DE18; Wed, 23 Oct 2002 10:47:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by segue.merit.edu (Postfix) with ESMTP id 37F965DE12 for <[e-mail]>; Wed, 23 Oct 2002 10:47:45 -0400 (EDT)
Received: from cmr1.ash.ops.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP  (peer crosschecked as: localhost [127.0.0.1]) id QQnlvf18060 for <[e-mail]>; Wed, 23 Oct 2002 14:47:44 GMT
Received: from csserve0.corp.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP  (peer crosschecked as: csserve0.corp.us.uu.net [153.39.88.140]) id QQnlvf18049; Wed, 23 Oct 2002 14:47:44 GMT
Received: from localhost by csserve0.corp.us.uu.net with ESMTP  (peer crosschecked as: dbarak@localhost) id QQnlvf08774; Wed, 23 Oct 2002 10:47:43 -0400 (EDT)
Date: Wed, 23 Oct 2002 10:47:43 -0400 (EDT)
From: David Barak <[e-mail]>
X-Sender: [e-mail]
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: Issue 32 - Clarify EGP Reference
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

agreed.

David Barak
WorldCom
Voice: [phone]
Fax: [phone]

"Quis custodes ipsos custodiet?" - Juvenal
=====   Fully RFC 1925 compliant   =====

On Wed, 23 Oct 2002, Jeffrey Haas wrote:

> > ----------------------------------------------------------------------------
> > 32) Clarify EGP Reference
> > ----------------------------------------------------------------------------
> 
> I'd like to propose that all of the issues here have been addressed
> by 32.1 and we close this one.
> 
> If others disagree, could you note what your perception of remaining
> issues are?
> 
> -- Jeff
> 



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA05764 for <[e-mail]>; Wed, 23 Oct 2002 10:43:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id AAE4B91272; Wed, 23 Oct 2002 10:42:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 789BA91274; Wed, 23 Oct 2002 10:42: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 6C86691272 for <[e-mail]>; Wed, 23 Oct 2002 10:42:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 528C65DE0B; Wed, 23 Oct 2002 10:42: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 78C575DE0E for <[e-mail]>; Wed, 23 Oct 2002 10:42:45 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9NEgi145931 for [e-mail]; Wed, 23 Oct 2002 10:42: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 g9NEgfC45924 for <[e-mail]>; Wed, 23 Oct 2002 10:42:41 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9NEgfa12941 for [e-mail]; Wed, 23 Oct 2002 10:42:41 -0400 (EDT)
Date: Wed, 23 Oct 2002 10:42:41 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Issue 32 - Clarify EGP Reference
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, Oct 22, 2002 at 07:02:19PM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

> ----------------------------------------------------------------------------
> 32) Clarify EGP Reference
> ----------------------------------------------------------------------------

I'd like to propose that all of the issues here have been addressed
by 32.1 and we close this one.

If others disagree, could you note what your perception of remaining
issues are?

-- Jeff


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA05385 for <[e-mail]>; Wed, 23 Oct 2002 10:35:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id ECBF091271; Wed, 23 Oct 2002 10:34:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B241791285; Wed, 23 Oct 2002 10:34: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 24FE591271 for <[e-mail]>; Wed, 23 Oct 2002 10:34:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0ED8D5DDDC; Wed, 23 Oct 2002 10:34: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 41B275DE12 for <[e-mail]>; Wed, 23 Oct 2002 10:34:48 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9NEYlT45713 for [e-mail]; Wed, 23 Oct 2002 10:34: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 g9NEYiC45706 for <[e-mail]>; Wed, 23 Oct 2002 10:34:44 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9NEYhw12908 for [e-mail]; Wed, 23 Oct 2002 10:34:44 -0400 (EDT)
Date: Wed, 23 Oct 2002 10:34:43 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: Issue 68 - outbound loop detection
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, Oct 22, 2002 at 07:02:19PM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Oct 22, 2002 at 07:02:19PM -0700, [e-mail] wrote:
> Status: No Consensus
> Change: Potentially
> Summary: IFF we have two implementations, we'd consider including this in
>   the base spec.
>  
> Discussion:
> 
> Jonathan brought up that:
> 
> This paper (thanks Jeff)

Since my name is brought up, I thought I'd offer an opinion. :-)

> http://www.research.microsoft.com/scripts/pubs/view.asp?TR_ID=MSR-TR-2000-08
> indicates that it
> is better to do the loop detection outbound as well inbound.  The current
> draft indicates that
> it only needs to be done inbound.  IOS does it inbound as well as outbound.
> GateD/Juniper
> does it (did it ???) only inbound.
> 
> So I propose we add:
> "An implementation MAY choose to not advertise routes to EBGP peers if these
> routes contain
> the AS of that peer in the AS path."
> after:
> "If the autonomous system number appears in the AS path the route may be
> stored in the
> Adj-RIB In, but unless the router is configured to accept routes with its
> own AS in the
> AS path, the route shall not be passed to the BGP Decision Process."
> 
> *If there is at least one other implementation that does outbound
> pruning/loop-detection.*

My suggestion is that this can stay out of the base draft.  While it
is true that this speeds up convergence (per the paper), it doesn't
affect interoperability.

Also, adding this specifically removes the ability from several 
implementations to be able to bridge a partitioned AS by permitting
loops.  (I'm not going to argue whether this is a Good way to do this,
just that its done.)

Its also worth noting that one could produce the same resultant speed-up
by detecting the loop on an outbound basis and *not* applying the
min*timers to the UPDATE.  Thus, this would be a case of an advertisement
of NLRI being treated the same, timer-wise, as the advertisement of
WD_NLRI.

I would suggest moving this suggestion for outbound loop detection
in one form or another to the 1772 replacement.

-- 
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 WAA22709 for <[e-mail]>; Tue, 22 Oct 2002 22:06:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B38BB9125C; Tue, 22 Oct 2002 22:05:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 56A109125D; Tue, 22 Oct 2002 22:05: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 E69909125C for <[e-mail]>; Tue, 22 Oct 2002 22:05:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A973F5DD8D; Tue, 22 Oct 2002 22:05:17 -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 8D8DE5DD8C for <[e-mail]>; Tue, 22 Oct 2002 22:05:14 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id TAA05148 for [e-mail]; Tue, 22 Oct 2002 19:02:19 -0700 (PDT)
Date: Tue, 22 Oct 2002 19:02:19 -0700
From: [e-mail]
To: [e-mail]
Subject: BGP Base Draft - Issue List v1.4
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="z6Eq5LdranGa6ru8"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: [e-mail]
Precedence: bulk

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

Hello all,

This is the 1.4 edition of the issues document.  Since the 1.3 edition
we have:  

 Added 1 issue.
 Added a list of to-do documents (Appendix A)
 Updated 10 issues.
 Moved the same 10 issues to consensus.

We have only 8 issues outstanding, and we're close on some of them.  Time
to take a deep breath and plow on through, we're almost there!
 
Andrew

--z6Eq5LdranGa6ru8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="Issue_List-v1.4.txt"

2002-10-22
v1.4

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 "Unfeasible 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
61) Next Hop for Redistributed Routes
62) Deprecate BGP Authentication Optional Parameter from RFC1771
63) Clarify MED Removal Text
64) MED for Originated Routes
65) Rules for Aggregating with MED and NEXT_HOP
66) Complex AS Path Aggregating
67) Counting AS_SET/AS_CONFED_*
68) Outbound Loop Detection

============================================================================
Issues with Consensus
============================================================================
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.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
11.3) Documenting IBGP Multipath
12) TCP Behavior Wording
13) Next Hop for Originated Route
14) NEXT_HOP to Internal Peer (closed in favor of issue 61)
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.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 "Unfeasible Routes" and "Withdrawn Routes"
38) Clarify Outbound Route Text
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
47) FSM - Add Explicit State Change Wording
49) Explicity Define Event Generation
50) FSM Timers 
51) FSM ConnectRetryCnt
52) Section 3: Keeping routes in Adj-RIB-In
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
61) Next Hop for Redistributed Routes
62) Deprecate BGP Authentication Optional Parameter from RFC1771
63) Clarify MED Removal Text
64) MED for Originated Routes
65) Rules for Aggregating with MED and NEXT_HOP
66) Complex AS Path Aggregating
67) Counting AS_SET/AS_CONFED_*

============================================================================
Issues WITHOUT Consensus
============================================================================

11) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1
32) Clarify EGP Reference
39) Redundant Sentance Fragments
45) Consistant References to BGP Peers/Connections/Sessions
46) FSM Connection Collision Detection
48) Explicitly Define Processing of Incomming Connections
53) Section 4.3 - Routes v. Destinations - Advertise
68) Outbound Loop Detection

----------------------------------------------------------------------------
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 opinions expressed on this were 7 in favor, 4 against.

----------------------------------------------------------------------------
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: 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: Consensus
Change: Yes
Summary:
 Get rid of section 9.2.1.3 ("Jitter").
 Move the text to an Appendix: "BGP Timers"
 Expand text to indicate that jitter applies to all timers, including 
  ConnectRetry.
 
 The text for the appendix is listed at the end of the discussion.

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"

Yakov agreed with making some changes and suggested that we make sure
that jitter is applied to all timers.  Specifically, he proposes we
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.

Jonathan, the original commentor, agreed with Yakov's suggestion.

In a follow-up to this issue, there was a question raised about the values
we have specified for timers in the document. Specifically:

    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 ?

Curtis responded to this with:

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.

And Jonathan replied with this information about current practice:

 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.

So the question that arises from this followup, is how does this question 
affect the text of the appendix on jitter?

Curtis replied that we need to only state that jitter should be applied
to all timers.  Whether a vendor does so or not is a minor deficiency and
does not bear on interoperability.  Therefore, specifying exact details
are not necessary.

After Jonathan's response Curtis and Jonathan agreed that jitter should
be added to all timers and that we should state so in the text.

Yakov proposed the following text for the appendix to discuss jitter:

I'd like to propose the following text for "BGP Timers" section:

   BGP employs five timers: ConnectRetry (see Section 8), Hold Time
   (see Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval
   (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
   Section 9.2.1.1).

   The suggested value for the ConnectRetry timer is 120 seconds.

   The suggested value for the Hold Time is 90 seconds.

   The suggested value for the KeepAlive timer is 1/3 of the Hold
   Time.

   The suggested value for the MinASOriginationInterval is 15
   seconds.

   The suggested value for the MinRouteAdvertisementInterval is 30
   seconds.

   An implementation of BGP MUST allow the Hold Time timer to be
   configurable, and MAY allow the other timers to be configurable.

   To minimize the likelihood that the distribution of BGP messages
   by a given BGP speaker will contain peaks, jitter should be
   applied to the timers associated with MinASOriginationInterval,
   Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
   given BGP speaker shall apply the same jitter to each of these
   quantities regardless of the destinations to which the updates
   are being sent; that is, jitter will not be applied on a "per
   peer" basis.

   The amount of jitter to be introduced shall be determined by
   multiplying the base value of the appropriate timer by a random
   factor which is uniformly distributed in the range from 0.75 to
   1.0.

Jeff  & Ben agreed with this.  

Justin suggested that we move the range from 0.75 to 1.25 to ensure that the 
average is around the configured value.  Yakov agreed with Justin's changes. 
Jonathan disagreed, arguing that it was out-of-scope for the task of 
clarifying the text only.  Justin agreed and withdrew his comment.

Curtis liked the general text, but suggested these modifications:

minor improvement (not really an objection) --
   s/suggested value/suggested default value/g

Also

  s/shall apply the same jitter/may apply the same jitter/
   (to each of these quantities regardless of ...).
 
  s/jitter will not be applied/jitter need not be configured/
    (on a "per peer" basis).

He stated that in Avici's implementation they allow a lot of granularity
in timer settings, so this reflects current practice.

Curtis also suggested changing the last paragraph:

   The suggested default amount of jitter shall be determined by   
   multiplying the base value of the appropriate timer by a random
   factor which is uniformly distributed in the range from 0.75 to
   1.0.  A new random value should be picked each time the timer is
   set.  The range of the jitter random value MAY be configurable.

This would make it clear that it is possible to have this timer as 
configurable and still be within spec.

Other comments on Yakov's text pointed out that IOS uses 5 seconds as
the default IBGP MinRouteAdvertisementInterval.

Tom pointed out that there seems to be a discrepency between this text
and the FSM:  The FSM has an OpenDelay timer.  And the FSM suggests a 
HoldTimer of 4 minutes.

In following up on this issue, Yakov stated:

Here is the final text for the BGP Timers section:
   
   BGP employs five timers: ConnectRetry (see Section 8), Hold Time
   (see Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval
   (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
   Section 9.2.1.1).

   The suggested default value for the ConnectRetry timer is 120
   seconds.

   The suggested default value for the Hold Time is 90 seconds.
     
   The suggested default value for the KeepAlive timer is 1/3 of
   the Hold Time.
  
   The suggested default value for the MinASOriginationInterval is
   15 seconds.

   The suggested default value for the MinRouteAdvertisementInterval
   is 30 seconds.

   An implementation of BGP MUST allow the Hold Time timer to be
   configurable, and MAY allow the other timers to be configurable.

   To minimize the likelihood that the distribution of BGP messages
   by a given BGP speaker will contain peaks, jitter should be
   applied to the timers associated with MinASOriginationInterval,
   Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
   given BGP speaker may apply the same jitter to each of these
   quantities regardless of the destinations to which the updates
   are being sent; that is, jitter need not be configured on a "per
   peer" basis.

   The suggested default amount of jitter shall be determined by
   multiplying the base value of the appropriate timer by a random
   factor which is uniformly distributed in the range from 0.75 to 
   1.0. A new random value should be picked each time the timer
   is set. The range of the jitter random value MAY be configurable.

With this in mind, I would suggest we mark this issue as closed.

Jonathan suggested adding "per peer" to the text, Yakov responded with
this text:

  An implementation of BGP MUST allow the Hold Time timer to be configurable
  on a per peer basis, and MAY allow the other timers to be configurable.

This proposal met with general agreement.  This issue is at consensus.

----------------------------------------------------------------------------
9) Reference to RFC904 - EGP Protocol
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
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.

Yakov agreed to this, and Jonathan seconded it.

----------------------------------------------------------------------------
10) Extending AS_PATH Attribute
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: 
  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 MUST not advertise the route to its peers and
    may choose to log an error locally.


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. 

Yakov stated that:

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:

After some discussion, Yakov's proposed text's last sentance was dropped
and we arrived at:

    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. 

In response to Andrew's clarification question to the list, Curtis
responded:

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.
     
After some additional discussion, it was decided that we add "and may
choose to log an error locally." to the end of Yakov's text.

Also, we agreed to change "may choose not to advertize..." to 
"MUST NOT advertise...".

So the text 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.

This met with one agreement and no disagreements.  We have a consensus.

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

Yakov replied to this that:

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.

The "issue 11" thread this was being discussed in then digressed to the
topic, now covered in issue 11.3.

Ben readdressed the original issue with this input:

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

Ben's comment has not yet received a reponse.

We are still working on consensus on this. 

----------------------------------------------------------------------------
11.1) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: The text below will be added to the -18 version.

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.

This text will be added to the -18 version, and since there were no
objections, this issue has been moved to consensus.

----------------------------------------------------------------------------
11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add this text:

     In the context of this document we assume that a BGP speaker
     advertises to its peers only those routes that it
     itself uses (in this context a BGP speaker is said to "use" a BGP
     route if it is the most preferred BGP route and is used in
     forwarding). All other cases are outside the scope of this document.

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 were a lot of emails exchanged on this topic with a variety of 
texts proposed (see early in the "Active Route" thread).  This issue
reopend with Jonathan, who brought up the issue originally, stating that:

 The issue I raised, and would like to be [re-]considered is with:
 
 "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."

Curtis replied that:

That is called route orgination and it is allowed by:

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

Advice on what to put in the AS_PATH and NEXT_HOP is in the document.

He continued with:

I don't think there was ever consensus on what to do with the
statement "a BGP speaker advertises to its peers (other BGP speakers
which it communicates with) in neighboring ASs only those routes that
it itself uses".  Some reasonable choices are:

  1.  Omit it (the implied consensus of the rewrite of the paragraph
      in 32.2).
  
  2.  Leave it as is and put it in another paragraph to separate it
      from the destination based routing statement.

  3.  Clean up the wording and put it in another paragraph to separate
      it from the destination based routing statement.

The separate paragraph for 2 would be the exact sentence we now have.
   
   A BGP speaker advertises to its peers (other BGP speakers which it
   communicates with) in neighboring ASs only those routes that it
   itself uses.

In possibility 3 we (try to) clear up the ambiguity about the meaning
of the word "use" in this sentence.

   A BGP speaker advertises to its peers (other BGP speakers which it
   communicates with) in neighboring ASs only those routes that it
   itself uses.  In this context a BGP speaker is said to "use" a BGP
   route if it is the most preferred BGP route and is either directly
   used in forwarding or in a specifically configured case where the
   BGP route would be forwarded internally but IGP forwarding
   information is used.  The latter case reflects a usage in which the
   IGP is used for forwarding but BGP is originated to IBGP to carry
   attributes that cannot be carried by the IGP (for example, BGP
   communities [N]).  Other special cases such as virtual routers and
   multiple instances of BGP on a single router are beyond the scope
   of this document but for each of these the statement "a BGP speaker
   advertises to its peers (other BGP speakers which it communicates 
   with) in neighboring ASs only those routes that it itself uses" can
   (and should in the definition of the extension) be made true with
   an appropriate definition of the word "use".
      
Unless someone volunteers better wording this may be a good starting
point.  I thing the last sentence borders on ridiculous in a protocol
spec but may be necessary to address specific objections raised on
this mailing list.  If we want to elaborate on the meaning of the word
"use" and address the objections this is what we end up with.
      
Of course looking at what we ended up with, I'd also go along with the
other two options (leave it out or put the one sentence in a separate
paragraph as is).

After some additional discussion (in the "issue 11.2" thread), we have
come to a consensus on this text:

     In the context of this document we assume that a BGP speaker
     advertises to its peers only those routes that it
     itself uses (in this context a BGP speaker is said to "use" a BGP
     route if it is the most preferred BGP route and is used in
     forwarding). All other cases are outside the scope of this document.

This issue is at consensus.

----------------------------------------------------------------------------
11.3) Documenting IBGP Multipath
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: The documenting of IBGP Multipath is left to another Internet 
 Draft.  The consensus is that it should not be in the base spec.

Discussion:

This thread began in the "issue 11" discussion.  In it it was proposed
that:

    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.

After much discussion back and forth, it was agreed that documenting
IBGP Multipath behavior is a good thing.  However, it is something that
belongs in another draft.

Alex opened this issue up again.  There were a flury of responses, most
all of them agreeing with the original consensus that we should document
this feature in a different draft, since it doesn't affect the core
interoperatbilty requirements, and we want to advance the spec in a 
timely manner.

Alex persisted in his assertion that this belongs in the base specification.
Right now, the issue is still open.

This discussion later expanded in scope to include all BGP multipath.

Curtis laid out a good description of the various flavors of multipath:

 In addition to IGP multihop, there are two cases of BGP multipath.

 In IGP multihop there is one BGP advertisement but to ways to reach th
 BGP NEXT_HOP via the IGP.

 In one case of BGP multihop, two (or more) IBGP routers peering with
 the same external AS have equal routes to a destination and are an
 equal cost away from a third router.  BGP multihop is applicable to
 that third router.  Without BGP multihop, BGP would normally pick the
 BGP NEXT_HOP of the advertisement from only one of those IBGP peers
 (using BGP Identifier) and use that.  The IGP lookup would yield one
 next hop.  With BGP multihop, BGP uses the BGP NEXT_HOP of both
 advertisements.  Each BGP NEXT_HOP has a different IGP next hop (one
 or more IGP next hop).

 The second case is where all of the candidates routes for BGP
 multipath are external.  Seldom does IGP multipath come into play for
 EBGP (odd tunneled EBGP mutlihop cases maybe).  Typically the load is
 split among two (or more) routers in the same AS.
 
 If in EBGP multipath you split among routers in difference AS, an
 aggregate should be formed.  This is still prior to the IGP cost rule
 in the route selection.

 Normally one would not combine IBGP and EBGP in multihop given that
 the decsion point for multihop is after "d" in 9.1.2.2.  If the
 multihop decision was prior to "d", then two routers each with an
 external peering would forward some of the traffic to each other and
 for some src/dst pairs, they'd form a loop.  [So don't do that!]

 This is getting to be a lot to add to the base spec.  I hope we've
 convinced you that we should put it in another document.

Curtis later added specific text, that could serve as a start for the
new document (or added to the base spec if the consensus ended up
going the other way):

   BGP specifies how to select the single best route.  OSPF
   specifically defines procedures for handling equal cost multipath
   (ECMP) [cite OSPF].  The same technique has been applied to ISIS.
   A similar technique has been used with BGP.  Variations exist but
   the decision to support BGP multipath, the specific variation of
   BGP multipath, or not to support it, does not affect  
   interoperability.
 
   A naive implementations of ECMP can cause severe performance
   degradation for TCP flows.  To avoid this, implementations of BGP
   multipath SHOULD maintain packet ordering within microflows as
   described in [cite rfc2991, rfc2992].

   BGP multipath, if implemented, SHOULD be disabled by default.

   In addition to IGP multipath (OSPF ECMP and ISIS equivalent), there
   are two variations of BGP multipath described here.  A BGP
   implementation may offer both, either one, or neither variation of
   BGP multipath.  Other variations of BGP multipath may exist, but no
   guarantees can be made in this protocol specification of their
   properties or impact on interoperability.

   Where IGP multipath is used, there is an interaction with BGP
   learned routes.  The lookup of a BGP NEXT_HOP in the IGP can
   result in the selection of an IGP multipath entry.  This is not a  
   variation of BGP multipath.  When this occurs, one BGP route is
   slected as the best but there is more than one way to reach the BGP
   NEXT_HOP via the IGP.

   In one variation of BGP multipath, a set of more than one IBGP
   routers peering with the same external AS have equal routes to a
   destination and are an equal IGP cost away from a second set of one
   or more routers.  BGP multipath is applicable to the latter set of
   routers.  Without BGP multipath, BGP would pick the BGP NEXT_HOP of
   the advertisement from only one of those IBGP peers (using BGP   
   Identifier) and use only that BGP route.  With BGP multipath, BGP
   uses the BGP NEXT_HOP of more than one of these equal cost
   advertisements, yielding more than one BGP NEXT_HOP.  Each BGP  
   NEXT_HOP has a different IGP next hop (one or more IGP next hop if
   IGP multipath is in use).

   The second case is where all of the candidates routes for BGP
   multipath are external and learned by a single BGP peer.  Without
   BGP multipath this peer would select only one of the BGP routes and
   obtain only one BGP NEXT_HOP.  With BGP multipath, more than one
   equal cost route is selected yielding more than one BGP NEXT_HOP.
   Seldom does IGP multipath come into play when looking up an EBGP
   NEXT_HOP but could in principle be applicable.
   
   If in EBGP multipath traffic is split among routers in difference
   AS, an aggregate SHOULD be formed so as to propogate a route with 
   an accurate AS_PATH.  If the resulting aggregate is not more
   specific than the components, the AS_SET SHOULD NOT be dropped.
   
   The decsion point for multipath is after step "d" in Section
   9.1.2.2 (prefer externally learned routes).  IBGP learned and EBGP
   learned routes MUST NOT be combined in multipath.  If the multipath
   decision is prior to "d", then two routers each with an external   
   peering would form a routing loop.
   
   The decision point for multipath is generally after step "e" in
   Section 9.1.2.2.  Some relaxation of the "equal cost" rule (also
   applicable to IGP multipath) is possible.  In addition to the equal
   cost BGP NEXT_HOPS available at BGP route selection, if the IGP 
   next hop for other BGP NEXT_HOPs are of lower cost, then those may 
   be used as well.  This relaxation of the step "e" is possible but 
   is not widely implemented (and may not be implemented at all).

The consensus of the majority of the IDR WG is to keep this in a 
seperate draft and out of the base spec.

----------------------------------------------------------------------------
12) TCP Behavior Wording
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: In issue 19 we decided to remove this section entirely.  As a 
  result the previous consensus on this issue (no change) is renderd
  moot.

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.

In issue 19 we decided to remove this section entirely.

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

For related discussion see issue 61.

----------------------------------------------------------------------------
14) NEXT_HOP to Internal Peer
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Closed in favor of issue 61.

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.

Since this issue and issue 61 are basically the same, except 61 proposes
text, we'll close this issue in favor of 61.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
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.

Yakov responded that this will be added to the -18 review.

Jonathan agreed.

----------------------------------------------------------------------------
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: Consensus
Change: No
Summary: Remove the section entirely, as this is something that does not
  belong in the base spec.

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.

There seems to be general agreement that this section should be removed.

N.B.  This also affects issue 12.

----------------------------------------------------------------------------
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: Consensus
Change: No
Summary: The consensus is that additional references to RFC2385 are not
  necessary.

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.

Yakov replied to this:

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.

Ishi agreed with Yakov.  Jonathan disagreed since he thought no one uses
BGP auth.  Ishi replied that there are lots of people who do use it.
Jonathan replied with a clarification question: "Who uses *BGP's own* 
authentication mechanisms???"  Ron Bonica replied that they use BGP auth.
There was some additional discussion over who implements simple password
authentication vs. MD5.

After further discussion, the consensus seems to be that we should leave
the text as it is for the reasons Yakov pointed out.  There was some
discussion over opening a new issue to discuss deprecating the BGP
auth mechanism discussed in RFC1771 in favor of the mechanism in RFC2385.

The issue of Depricating BGP AUTH is discussed in issue 62.

----------------------------------------------------------------------------
22) Scope of Path Attribute Field
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: This is already being covered by text that has been added to
 the -18 draft.

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

Yakov replied to this that:

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.

There were no objections to this statement, so this issue has been moved
into consensus.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
Summary: 
 Add the following to section 3.1:

   Changing the attributes 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.

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.

Picking this thread up again, Yakov argued:

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.

Jonathan agreed with this statement, but Ben argued that the text in 
section 3 is insufficent the way it is currently written.   After
two iterations, Ben and Yakov agreed on this formulation for an
update to section 3.1:

   Changing the attributes 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.

Jeff objected somewhat to the wording, since, because of a bgp route
is defined as a <path attribute, NLRI> pair, changing either part of
that pair, by definition, changes the route.  He acknowledged that
this might fall under the category of implementation detail.

Yakov presented the view that he thought we were at consensus with the
text he proposed above.  Jonathan agreed.  There were no objections, so
this is moved to Consnesus.

----------------------------------------------------------------------------
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: Consensus
Change: No
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. 

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.

Yakov replied to this that he would suggest we keep things as is, since
the purpose is to document current implementations.

This did not meet with any objections, so this issue has been moved into
consensus.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
Summary:  
  Add:

  "in case they become resolvable" after the last sentence on p. 46.

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"

Yakov responded that:

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.

Yakov also responded that:

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.

Jonathan, who was the original commentor, agreed with both the changed
text and the clarity of section 3.

----------------------------------------------------------------------------
30) Mention Other Message Types
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add a reference to RFC2918 at the end of the type code list.

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.

Yakov replied that:

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.

Jonathan agreed with this change.  This issue has been moved to consensus.

----------------------------------------------------------------------------
31) Add References to Additional Options
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Consensus to add:

   [RFC2842] defines another Optional Parameter.

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.

Yakov replied that:

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.

The original poster agreed with this modification.  This issue is at 
consensus.

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

  This is partly addressed in the 32.1 text with the addition of a RFC904
  reference to EGP ORIGIN type.

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

Yakov replied that an EGP reference will be added (see issue 9).

Yakov also stated that he doesn't see what is wrong with the current text,
and suggsted we keep it.  This includes leaving out any reference to the
status of the EGP spec.  He sees that it is clear from context that we
are talking about "the EGP" [RFC904].

----------------------------------------------------------------------------
32.1) EGP ORIGIN Clarification
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: 
 Change section 5.1.1 to 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."

 Consensus 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]


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.

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.

After some further discussion, we have this text on the table:

   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.

Jonathan suggested that we change "propagate this information" to
"forward this route".  He also mentioned that he would prefer something
more explicit instead of/in addition to "The attribute shall be included
in the UPDATE messages of all BGP speakers that choose to propagate this
information to other BGP speakers." such as "other speakers do not
change the ORIGIN value."

On the issue of making the EGP ORIGIN type more clear Andrew proposed:

 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.

This met with a number of agreements.

On the second text section we are working on, Jonathan objected to the
current working text below and suggested an alternate:

CHANGE:

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

TO:

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

-or-

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

Jonathan cited a recent example of someone who was still confused by this
section of the text in -17 (not specifically the working text).

Yakov proposed this as final text:

In 4.3:
    
   a)   ORIGIN (Type Code 1):
    
   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 [RFC904]
   
   2         INCOMPLETE - Network Layer Reachability
                Information learned by some other means

   Usage of this attribute is defined in 5.1.1.

In 5.1.1:

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

This met with agreement.  This issue is at consensus.

----------------------------------------------------------------------------
32.2) BGP Desitnation-based Forwarding Paradigm
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: After much discussion, this is the consensus:
 This text in the current draft:

     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.

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: Consensus
Change: Yes
Summary: Add "Optional Non-Transitive" to MED Section
         Add "well-known mandatory" to the NEXT_HOP Section

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.

Yakov agreed to make this change in -18.

Jonathan replied that:

5.1.3 NEXT_HOP also, it is missing " well-known mandatory".

Yakov also agreed to make this change.

----------------------------------------------------------------------------
34) Timer & Counter Definition
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: No discussion, no text proposed, defaults to consensus for
  no change.

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.

There has been no further discussion on this issue.  Unless it is
brought up again, this issue is in consensus, with no change.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
Summary: This change requires a glossary. Yakov has committed to having
 a section where commonly used terms are defined in draft 18, so this
 issue is at consensus.

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.

Yakov replied:

will be added to the section "Definition of commonly used terms" in -18
version.

----------------------------------------------------------------------------
37) Combine "Unfeasible Routes" and "Withdrawn Routes"
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add the following terms to the "commonly used terms section":

   Feasible route
    A route that is available for use.

   Unfeasible route
    A previously advertised feasible route that is no longer available
    for use.

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.
 
Ishi replied to this that he thought that we could combine the two terms,
since there is limited difference from an implementation standpoint.

Yakov replied:

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.

Ishi replied that he was convinved, and that the terms should stay
seperate.

Andrew asked the list if we should define these terms in the "commonly
used terms" section in draft -18.

Ben replied that if we use them alot, we should define them, and if not
local definitions will suffice.

There was some back and forth about the necessity of defining terms which
should be obvious. 

mrr actually checked the doc to see if we were consistantly using the 
terms, and found:

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:

After some further off-list discussion, mrr agreed that this inconsistancy
is extremely minor, and withdrew his comment.  feasible and unfeasible
route will be defined in the "commonly used terms" section to clear
up any confusion.

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

Yakov agreed to drop the third and fourth parentheses in the -18 version.

Jonathan replied to this:

Disagree, the text if fine the way it is, except you need to change
"shorted" to "shorter".

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

There was some additonal discussion on this point.  Most of it was along
the lines of extracting what was really implemented and supported among
various vendors.  The conclusion was the same.

----------------------------------------------------------------------------
41) Mention FSM Internal Timers
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: No discussion on this issue.  No text proposed.  Perhaps this is
  in the FSM section of the draft?  Either way, it defaults to consensus
  with no change.

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.

There has been no discussion on this, it now defaults to consensus with
no change.

----------------------------------------------------------------------------
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: Consensus
Change: No
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.  They were later reminded that the base
  behavior is acceptable, and agreed.

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.

Yakov replied to this with:

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.

The original poster, Jonathan, agreed with this.  This issue moves to
consensus.

----------------------------------------------------------------------------
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: Consensus
Change: No
Summary: A desire for explicit state change wording was expressed.  No
  text was proposed.  The assumption is that this issue has reached a
  happy conclusion.

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.

There has been no further discussion on this.  The assumption is that
is has reached a happy conclusion privately.

----------------------------------------------------------------------------
48) Explicitly Define Processing of Incomming Connections
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Text has been proposed to describe the general process of 
 a BGP connection comming up.

Discussion:

Alex suggsted we explicity define:

   - processing of incoming TCP connections (peer lookup, acceptance,
     FSM creation, collision control,)

Curtis later proposed this text:

  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.

Jonathan pointed out that there was an inaccuracy in the proposed text.
Curtis replied with this:

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.

Tom replied that:

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

And Curtis suggested that:

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.

Tom agreed with Curtis, that he liked the "will attempt to connect unless 
configured otherwise" verbiage.

This was discussed in the "Generial Editorial Comment" thread.

----------------------------------------------------------------------------
49) Explicity Define Event Generation
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Suggested that we explictiy define BGP message processing. No text
  proposed.  There has been no further discussion on this issue, it
  is assumed that the consensus is that things are ok the way they are.

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 discussion has received no further comment.  Unless someone wants
to reopen it, it is assumed it has reached a happy ending.

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: Consensus
Change: Yes
Summary: 
 Replace:

   Path segment length is a 1-octet long field containing
   the number of ASs in the path segment value field.

 With:
 
   Path segment length is a 1-octet long field containing
   the number of ASs (not the number of octets) in the path
   segment value field.

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.

Yakov proposed this change:

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.

Jonathan offered this text:

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

Jeff replied that he prefered Yakov's text, but without the "but".  Yakov
agreed to that.  Andrew also agreed, and asked if there were any objections
to moving this issue into consensus.  There were no objections.

----------------------------------------------------------------------------
56) Section 6 - BGP Error Handling
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: There are a variety of updates to the text that are best described
 in the discussion section.

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

There have been no objections to the updates listed above.  This issue
seems to have reached a happy ending, so it has been moved into 
consensus.

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: Consensus
Change: Yes
Summary:  For new text, please see the end of the discussion.

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.

Yakov responded to this, saying that he thought these changes were 
reasonable, and unless there were objections, they would be adopted.

Ishi strongly agreed with the changes.

Curtis stated that:

 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.

 And suggested that we remove the MUSTs and indicated that this is only
 informational.

Jeff replied that:

 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.

Jonathan agreed with Curtis' idea that we should just move ATOMIC_AGGREGATE
to informational.

Curtis proposed this text:

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

Yakov was fine with this text.

Yakov posted the text that represents the WG consensus:

Replace:

  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.

with:

  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.

In 9.1.4 replace:

   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.

with:

   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 MUST 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 met with agreement.  This issue is at consensus.

----------------------------------------------------------------------------
59) Section 4.3 - Move text 
----------------------------------------------------------------------------
Status: Consensus
Change: Yes (minimal)
Summary: Update indentation to allow a new "subsection" heading. Otherwise
 no change.

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.

Yakov agreed to update the indentation.

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. 

After Yakov's response and a posting to the list asking that this be moved
to consensus, there were no objections, so this is moved to 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: Consensus
Change: Yes
Summary:  More cleary specify the behavior of NEXT_HOP modification, for
  the text see the end of the 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.

Issue 14 closed in favor of this issue.

In response to Yakov's call for input, Michael responded that:

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 (text is above.)

Yakov replied with this:

Replace:
  
  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.
  
with:
  
  1) When sending a message to an internal peer, if the route is
  not locally originated the BGP speaker should not modify the
  NEXT_HOP attribute, unless it has been explicitly configured to   
  announce its own IP address as the NEXT_HOP. When announcing a   
  locally originated route to an internal peer, the BGP speaker
  should use 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).

And stated the change would be made if there were no objections.  There
have been no objections, so this is at consensus.

----------------------------------------------------------------------------
62) Deprecate BGP Authentication Optional Parameter from RFC1771
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: We are at consensus, in that we agree that we should deprecate
 the BGP Authentication Optional Parameter as described in RFC1771 in
 favor of the mechanism described in RFC2385.  The textual changes are 
 listed at the end of the discussion section of this issue.

Discussion:

This discussion started in issue 21: Authentication Text Update.

This topic has come up before (July timeframe), but was recently refreshed
in the context of issue 21.  It began with some questions to the list
as to who used what sort of authentication mechanisms.  From the
responses it was clear that MD5 (RFC2385) was the prefered method.

Eric Gray's message helps to flesh this out:

        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

To this Yakov responded:

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.

There have been no responses to Yakov's question.

There seems to be a consensus that, since it is little used, and since
there are better mechanisms, namely MD5 authentication, we should 
deprecate the BGP Authentication Optional Parameter from RFC1771.

Ok, after some disucssion, this is a list of the text that we are
adding, changing or removing:

1) Remove the reference to the authentication optional parameter:

I would suggest to remove the following text from the draft:

         This document defines the following Optional Parameters:
  
         a) Authentication Information (Parameter Type 1):


            This optional parameter may be used to authenticate a BGP
            peer. The Parameter Value field contains a 1-octet
            Authentication Code followed by a variable length
            Authentication Data.

                0 1 2 3 4 5 6 7 8   
                +-+-+-+-+-+-+-+-+
                |  Auth. Code   |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |                                                     |
                |              Authentication Data                    |
                |                                                     |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Authentication Code:
   
                  This 1-octet unsigned integer indicates the
                  authentication mechanism being used. Whenever an
                  authentication mechanism is specified for use within
                  BGP, three things must be included in the
                  specification:
   
                  - the value of the Authentication Code which indicates
                  use of the mechanism,
                  - the form and meaning of the Authentication Data, and
                  - the algorithm for computing values of Marker fields.

                  Note that a separate authentication mechanism may be
                  used in establishing the transport level connection.

               Authentication Data:

                  Authentication Data is a variable length field that is
                  interpreted according to the value of the   
                  Authentication Code field.

2) Update the introduction:

In section 2 (Introduction), sixth paragraph

 From:

   BGP runs over a reliable transport protocol. This eliminates the
   need to implement explicit update fragmentation, retransmission,
   acknowledgment, and sequencing. Any authentication scheme used by the
   transport protocol (e.g., RFC2385 [10]) may be used in addition to
   BGP's own authentication mechanisms. The error notification mechanism
   used in BGP assumes that the transport protocol supports a "graceful"
   close, i.e., that all outstanding data will be delivered before the
   connection is closed.

 To:

   BGP uses TCP [RFC793] as its transport protocol. This eliminates
   the need to implement explicit update fragmentation, retransmission,
   acknowledgment, and sequencing. BGP listens on TCP port 179. Any
   authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may be
   used. The error notification mechanism used in BGP assumes that TCP
   supports a "graceful" close, i.e., that all outstanding data will
   be delivered before the connection is closed.   

3) Update the message header format section:

 From:

     Marker:

         This 16-octet field contains a value that the receiver of the
         message can predict.  If the Type of the message is OPEN, or if
         the OPEN message carries no Authentication Information (as an
         Optional Parameter), then the Marker must be all ones.
         Otherwise, the value of the marker can be predicted by some a
         computation specified as part of the authentication mechanism
         (which is specified as part of the Authentication Information)
         used.  The Marker can be used to detect loss of synchronization
         between a pair of BGP peers, and to authenticate incoming BGP
         messages.
   
  To:
   
     Marker:
   
         This 16-octet field is included for compatibility; it must be  
         set to all ones.

4) Update the Message Header error handling section:

In section 6.1 (Message Header error handling), second paragraph

 From:

   The expected value of the Marker field of the message header is all
   ones if the message type is OPEN.  The expected value of the Marker
   field for all other types of BGP messages determined based on the
   presence of the Authentication Information Optional Parameter in the
   BGP OPEN message and the actual authentication mechanism (if the  
   Authentication Information in the BGP OPEN message is present). If
   the Marker field of the message header is not the expected one, then
   a synchronization error has occurred and the Error Subcode is set to
   Connection Not Synchronized.

 To:
     
   The expected value of the Marker field of the message header is all
   ones. If the Marker field of the message header is not as expected,
   then a synchronization error has occurred and the Error Subcode is   
   set to Connection Not Synchronized.

5) Remove a paragraph from the OPEN mesage error handling section
   (section 6.2):

   If the OPEN message carries Authentication Information (as an
   Optional Parameter), then the corresponding authentication procedure 
   is invoked.  If the authentication procedure (based on Authentication
   Code and Authentication Data) fails, then the Error Subcode is set to
   Authentication Failure.

6) Update the "Differences from RFC1771 Appendix" 

   Text not listed here

7) Fix the hole in the numbering by updating:

 From: 

   This document defines the following Optional Parameters:

   a) Authentication Information (Parameter Type 1):

 To:

   This document defines the following Optional Parameters:

   a) Optional parameter type 1, Authentication Information, 
      has been deprecated.

We are at consensus with these changes.

----------------------------------------------------------------------------
63) Clarify MED Removal Text
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Modify text to clear up MED removal behavior.  Text is at the
  end of the discussion.

Discussion:

This discussion began when Jonathan posted a question to the list:

In reference to:

"A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
 which allows the MULTI_EXIT_DISC attribute to be removed from a
 route"

 Does anybody know how this can be done in IOS???  Looks like it cannot.

 Juniper???

 Other code???

 Change to "SHOULD"???

Enke responded that:

As the MED value is treated as zero when the MED attribute is missing,
removing the MED attribute is really equivalent to setting the value to
zero. Based on this logic, one can argue that "MED removal" is supported
by multiple vendors.
 
However, I do see that the current text can be consolidated and cleaned up:
 
------------------------
5.1.4 MULTI_EXIT_DISC

   ...
      
   A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
   which allows the MULTI_EXIT_DISC attribute to be removed from a
   route. This MAY be done prior to determining the degree of preference
   of the route and performing route selection (decision process phases
   1 and 2).
 
   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over an external
   link.  If it does so, it shall do so prior to determining the degree
   of preference of the route and performing route selection (decision
   process phases 1 and 2).

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

How about this:

   A BGP speaker MUST implement a mechanism based on local configuration
   which allows the value of MULTI_EXIT_DISC attribute of a received route  
   to be altered. This shall be done prior to determining the degree of
   preference of the route and performing route selection (decision process
   phases 1 and 2).

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

In responding to a question, Enke also added:

> Humm. I thought with a missing MED it was prefereable to be treated as
> worst not as 0.

It was changed a long time ago. Please see the following text in
Sect. 9.1.2.2 of the draft:
 
      In the pseudo-code above, MED(n) is a function which returns the
      value of route n's MULTI_EXIT_DISC attribute. If route n has no
      MULTI_EXIT_DISC attribute, the function returns the lowest
      possible MULTI_EXIT_DISC value, i.e. 0.

Curtis replied to Enke:

If Juniper treats missing MULTI_EXIT_DISC as worst and Cisco has a
knob to treat missing MULTI_EXIT_DISC as worst, then IMHO we should
change the spec to say that MED(n) returns the largest value possible
is MULTI_EXIT_DISC is missing since this has better loop suppression
bahaviour if the placement of MULTI_EXIT_DISC removal is moved in its
position in the flow from Adj-In-RIB to Loc-RIB to Adj-Rib-Out.  In
other words, no matter where the removal takes place, we are loop free
without special rules about comparing EBGP before MED removal and then
IBGP after MED removal.  The only argument for MED(n) going to zero
for missing MULTI_EXIT_DISC was that Cisco routers did that (and
change would pose an operational issue if there wasn't a knob to
facilitate the change).
   
Note that when explicitly jamming a MULTI_EXIT_DISC value, such as
zero, the issue of where in the decision process the MULTI_EXIT_DISC
learned from the EBGP peers could still be used becomes a concern
again.  Unfortunately these implementation hints are necessary to 
remain loop free and so its hard to declare them out of scope, unless
we forbid changing MULTI_EXIT_DISC and just allow it to be removed
(which does not reflect current practice).

Curtis also added:

The other issue was MED handling.  In "5.1.4 MULTI_EXIT_DISC":

   A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
   which allows the MULTI_EXIT_DISC attribute to be removed from a
   route. This MAY be done prior to determining the degree of preference
   of the route and performing route selection (decision process phases
   1 and 2).

   An implementation MAY also (based on local configuration) alter the  
   value of the MULTI_EXIT_DISC attribute received over an external  
   link.  If it does so, it shall do so prior to determining the degree 
   of preference of the route and performing route selection (decision 
   process phases 1 and 2).

This doesn't sufficiently address the issue.

The MED step in the decision process is (in 9.1.2.2):

      c) Remove from consideration routes with less-preferred
      MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
      between routes learned from the same neighboring AS. Routes which
      do not have the MULTI_EXIT_DISC attribute are considered to have
      the lowest possible MULTI_EXIT_DISC value.

      This is also described in the following procedure:

            for m = all routes still under consideration
                for n = all routes still under consideration
                    if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
                        remove route m from consideration

      In the pseudo-code above, MED(n) is a function which returns the
      value of route n's MULTI_EXIT_DISC attribute. If route n has no
      MULTI_EXIT_DISC attribute, the function returns the lowest
      possible MULTI_EXIT_DISC value, i.e. 0.
   
      Similarly, neighborAS(n) is a function which returns the neighbor
      AS from which the route was received.
   
The problem is that a route loop can be formed.

To avoid the route loop, two suggestions were made (2-3 years ago and   
nothing was done).  One was to make MED(n) return infinity if there  
was no MULTI_EXIT_DISC.  The other was to consider MULTI_EXIT_DISC in   
the decision process only for the purpose of selecting among the EBGP  
peers, then remove MULTI_EXIT_DISC, then use that best route in
comparisons to IBGP learned routes.

The statement in 5.1.4 "This MAY be done prior to determining the
degree of preference of the route and performing route selection
(decision process phases 1 and 2)" does not sufficiently address this.
This implies that you MAY also remove after route selection, in which
case field experience indicates you WILL get burned (unless you know
about the caveat above).  Initially this came up as an
interoperability issue but later it was proven (in the field) that a  
Cisco and another Cisco could form a route loop until Cisco made this
change.
      
Additional wording is needed either in 5.1.4 or in 9.1.2.2.  I suggest
we put a forward reference in 5.1.4:

   [...]. This MAY be done prior to determining the degree of preference
   of the route and performing route selection (decision process phases
   1 and 2).  See section 9.1.2.2 for necessary restricts on this.
      
Then in 9.1.2.2 add a clarificatio to the neighborAS(n) function and 
add to the existing text.

      Similarly, neighborAS(n) is a function which returns the
      neighbor AS from which the route was received.  If the route is  
      learned via IBGP, it is the neighbor AS from which the other
      IBGP speaker learned the route, not the internal AS.

      If a MULTI_EXIT_DISC attribute is removed before redistributing
      a route into IBGP, the MULTI_EXIT_DISC attribute may only be      
      considered in the comparison of EBGP learned routes, them
      removed, then the remaining EBGP learned route may be compared    
      to the remaining IBGP learned routes, without considering the    
      MULTI_EXIT_DISC attribute for those EBGP learned routes whose
      MULTI_EXIT_DISC will be dropped before advertising to IBGP.
      Including the MULTI_EXIT_DISC of an EBGP learned route in the
      comparison with an IBGP learned route, then dropping the
      MULTI_EXIT_DISC and advertising the route has been proven to
      cause route loops.

The loop is the classic I prefer your and you prefer mine problem.  It
occurs when the router is configured to remove MULTI_EXIT_DISC and
advertise out a route so other routers can use IGP cost to select the 
best route.  If two routers do this, as soon as they hear the route  
with no MULTI_EXIT_DISC from the other peer they start forwarding
toward that peer but they continue to advertise to it since others
IBPG peers are expected to select among the MULTI_EXIT_DISC free IBGP 
learned routes using the next step in the decision process, IGP cost.

In this case, what you want is each router to prefer its own EBGP
route, even though it has a MULTI_EXIT_DISC and the IBGP learned route 
from the same neighbor AS has had its MULTI_EXIT_DISC stripped off (or
didn't have one, you can't tell which it is).  You then want all of
the IBGP peers with a MULTI_EXIT_DISC free route from that AS, or that
have stripped the MULTI_EXIT_DISC to form one, to advertise them.
Others in the AS will then use IGP cost to further resolve which exit
point to use.  It make a difference when the route is the aggregate
route of another major provider.  IGP cost yields what ISPs call "hot  
potatoe routing" and MED selects among multiple heavily loaded
provider interconnects.

[Aside: Having a missing MULTI_EXIT_DISC default to infinity would do
exactly what the ISPs want it to do in the first place and be a lot     
easier to explain but we didn't fix that 2-3 years ago when the issue
came up even though we had WG consensus that it was the right thing to  
do.  The authors didn't act on it at the time (because Cisco didn't do 
it that way and the authors preferred to sit on the draft).  At this
point we might as well adequately document what we ended up with....
End of soapbox.  I don't take myself all that seriously so others  
shouldn't either.  :-)]

After some more discussion on this, we have this text:

In 5.1.4 replace:

   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over EBGP.
   If it does so, it shall do so prior to determining the degree of
   preference of the route and performing route selection (decision
   process phases 1 and 2).

with:

   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over EBGP.
   This MAY be done prior to determining the degree of preference
   of the route and performing route selection (decision process phases
   1 and 2). See section 9.1.2.2 for necessary restricts on this.

In 9.1.2.2 replace:

   Similarly, neighborAS(n) is a function which returns the neighbor
   AS from which the route was received.

with:
   
   Similarly, neighborAS(n) is a function which returns the neighbor
   AS from which the route was received.  If the route is learned
   via IBGP, and the other IBGP speaker didn't originate the route,
   it is the neighbor AS from which the other IBGP speaker learned
   the route. If the route is learned via IBGP, and the other IBGP
   speaker originated the route, it is the local AS.

   If a MULTI_EXIT_DISC attribute is removed before re-advertising  
   a route into IBGP, the MULTI_EXIT_DISC attribute may only be
   considered in the comparison of EBGP learned routes, then
   removed, then the remaining EBGP learned route may be compared
   to the remaining IBGP learned routes, without considering the
   MULTI_EXIT_DISC attribute for those EBGP learned routes whose
   MULTI_EXIT_DISC will be dropped before advertising to IBGP.
   Including the MULTI_EXIT_DISC of an EBGP learned route in the   
   comparison with an IBGP learned route, then dropping the
   MULTI_EXIT_DISC and advertising the route has been proven to
   cause route loops.

There have been no objections to this, so we are at consensus.

----------------------------------------------------------------------------
64) MED for Originated Routes
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: The consensus is that there is not need to specify default
  values for MED in the base draft.

Discussion:

This issue began when it was pointed out that we do not specify the
default values for MED in the base draft.

There were a variety of responses, but the consensus is that since 
this is not relevant for interoperability, this does not need to be
in the base spec.

----------------------------------------------------------------------------
65) Rules for Aggregating with MED and NEXT_HOP
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Clear up the text on aggregating with a MED.  See the discussion
  for the text.

Discussion:

There is a proposal to relax this statement:

"Routes that have the following attributes shall not be aggregated
   unless the corresponding attributes of each route are identical:
   MULTI_EXIT_DISC, NEXT_HOP."

In his reply to the original mail, Curtis asserted that we should leave
the MED rules alone, but perhaps we could relax the NEXT_HOP statement.

This was revisited in the "aggregating with MED and NEXT_HOP" thread.

Yakov suggested we replace:

   Routes that have the following attributes shall not be aggregated
   unless the corresponding attributes of each route are identical:
   MULTI_EXIT_DISC, NEXT_HOP.

   If the aggregation occurs as part of the update process, routes with
   different NEXT_HOP values can be aggregated when announced through an
   external BGP session.
   
   Path attributes that have different type codes can not be aggregated
   together. Path attributes of the same type code may be aggregated,
   according to the following rules:
      
with:

   Routes that have different MULTI_EXIT_DISC attribute SHALL NOT
   be aggregated.

   Path attributes that have different type codes can not be aggregated
   together. Path attributes of the same type code may be aggregated,
   according to the following rules:

     NEXT_HOP: When aggregating routes that have different NEXT_HOP
     attribute, the NEXT_HOP attribute of the aggregated route SHALL
     identify an interface on the router that performs the aggregation.

This met with agreement.

Dimitry asked if the "Routes that have different MULTI_EXIT_DESC attribute
SHALL NOT be aggregated." sentance was unnecessary since it should be a
matter of local policy.  Jeff replied that it has been mentioned that
removing this stipulation can cause routing loops.

We are at consensus with this issue.

----------------------------------------------------------------------------
66) Complex AS Path Aggregating
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Since we have two implementations of this method, secion 6.8 stays
 in the specification.

Discussion:

Jonathan opened this discussion with:

The part in the draft about complex AS path aggregation could/should be
deleted.  The current draft implies that when aggregating, for example
(1st):

1 2 4 3

w/

3 4 6 5

and

5 6 7 8

then

1 2 {3 4 5 6} 7 8

...would be OK

AFAIK, all implementations aggregate by either: (2nd)putting ONLY the local
AS in the path (and setting the atomic) OR (3rd)by creating 1 giant set and
adding the local AS as a seq.

So he proposed we remove this to reflect current code.

Jeff replied that there is absolutely nothing wrong with doing complex
aggregation, and there is no reason to remove this from the specification.

Yakov responded that:

Jonathan is certainly correct that the spec has to reflect current
code.  Therefore, unless there are at least two (interoperable)
implementations that implement the algorithm described in "6.8
Complex AS_PATH aggregation", this section has to be removed (this
is irrespective of whether there is something wrong, or nothing
wrong with complex aggregation). With this in mind, if you implement
this algorithm please speak up within a week.  If within a week we
wouldn't know that there are at least two implementations the
section will be removed. And likewise, if we hear that there are
at least two implementations, the section will stay.

Jeff replied:

I am also fine with removing it.  I just don't think its necessary,
especially if One Of These Days someone decides that running policy
based on as-adjacencies would be a Nice Thing and fixes their
implementation to support "complex" aggregation of paths.

That said, I am aware of no one who implements this.

As an aside, in the thread "last thought on complex aggregation" Jeff
supplied:

 I finally remembered what was bothering me about removing complex
 aggregation from the spec.

 If it is removed, people who do conformance tests and some implementations
 may take this to mean "it shall be illegal to have an AS_PATH that
 contains a SEQUENCE of a particular type after a SET".

 This would make a perfectly ok AS_PATH into one that isn't legal, even
 if no implementation currently generates it.

Jonathan replied that he thought the issue was moot since no one has 
implemented this.

John replied that, although he is a bit uncomfortable in removing this
from the spec, he doesn't see any harm in doing so.

With this in mind, Yakov suggested we consider the issue closed. 

So we will wait a week from 10/17 to see if anyone chimes in.

Siva responded that they have implemented this functionality.  So we
need one more...Ben responded that they support this at Marconi as well.

So we have two implementations, the section stays in the spec.  We are
at consensus with this issue.

----------------------------------------------------------------------------
67) Counting AS_SET/AS_CONFED_*
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Move how AS_CONFED_SET & SEQUENCE affect route selection to the
  BGP Confederations document.   Update the base draft to reflect this
  by changing section 9.1.2.2.  Specific text is at the end of the
  discussion.

Discussion:

Jonathan brought up some questions on how current implementations count
AS_SET and AS_CONFED_*

There were a variety of resposnes to this, answering his questions.
Curtis pointed out that this behavior is covered in:

That's in 9.1.2.2:

      a) Remove from consideration all routes which are not tied for
      having the smallest number of AS numbers present in their AS_PATH
      attributes. Note, that when counting this number, an AS_SET counts
      as 1, no matter how many ASs are in the set, and that, if the
      implementation supports [13], then AS numbers present in segments
      of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in
      the count of AS numbers present in the AS_PATH.

Jonathan replied that this might be at odds with what Juniper does,
although he was unsure, and asked for clarification.

This was discussed in the "New Issue AS path" thread.

Yakov proposed that:

The issue of route selection in the present of confederations
belongs *not* to the base spec, but to the spec that describes
BGP Confeds. With this in mind I would suggest to change in 9.1.2.2 from

        a) Remove from consideration all routes which are not tied for
        having the smallest number of AS numbers present in their AS_PATH
        attributes. Note, that when counting this number, an AS_SET counts
        as 1, no matter how many ASs are in the set, and that, if the
        implementation supports [13], then AS numbers present in segments
        of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in
        the count of AS numbers present in the AS_PATH.
to

        a) Remove from consideration all routes which are not tied for
        having the smallest number of AS numbers present in their AS_PATH
        attributes. Note, that when counting this number, an AS_SET counts
        as 1, no matter how many ASs are in the set.

and ask the authors of BGP Confeds to update their document to
cover how the presence of confeds impact route selection.

This met with agreement, this issue is at conensus.

----------------------------------------------------------------------------
68) Outbound Loop Detection
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: IFF we have two implementations, we'd consider including this in
  the base spec.
 
Discussion:

Jonathan brought up that:

This paper (thanks Jeff)
http://www.research.microsoft.com/scripts/pubs/view.asp?TR_ID=MSR-TR-2000-08
indicates that it
is better to do the loop detection outbound as well inbound.  The current
draft indicates that
it only needs to be done inbound.  IOS does it inbound as well as outbound.
GateD/Juniper
does it (did it ???) only inbound.

So I propose we add:
"An implementation MAY choose to not advertise routes to EBGP peers if these
routes contain
the AS of that peer in the AS path."
after:
"If the autonomous system number appears in the AS path the route may be
stored in the
Adj-RIB In, but unless the router is configured to accept routes with its
own AS in the
AS path, the route shall not be passed to the BGP Decision Process."

*If there is at least one other implementation that does outbound
pruning/loop-detection.*

Yakov pointed out that this is ONLY applicable to the base draft if there
are multiple implementations doing this.  This issue will only be 
considered if these implementors come forward by 10/25/02.  Otherwise
the issue will be considered closed.

============================================================================
Appendix A - Other Documents
============================================================================

Over the course of this discussion, a number of issues have been raised
that the group though would be better dealt with in other documents.
These additional documents, and their concomitant issues will be more
fully addressed when the WG turns its focus to them.  These projects are:

1) Update RFC 1772: Application of the Border Gateway Protocol in the Internet.
   This will probably entail a complete rewrite.
2) Update Route Reflector (2796) and Confederation (3065) RFC's regarding their
   impact on route selection.
3) Write a new document covering BGP Multipath.

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

CHANGELOG

----------------------------------------------------------------------------
v1.3 to v1.4
2002-10-22
----------------------------------------------------------------------------

Added:

Appendix A - Other Documents
68) Outbound Loop Detection

Updated:

8) Jitter Text
11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
11.3) Documenting IBGP Multipath
32.1) EGP ORIGIN Clarification
58) Deprication of ATOMIC_AGGREGATE
61) Next Hop for Redistributed Routes
63) Clarify MED Removal Text
65) Rules for Aggregating with MED and NEXT_HOP 
66) Complex AS Path Aggregating
67) Counting AS_SET/AS_CONFED_*

Moved to Consensus:

8) Jitter Text
11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
11.3) Documenting IBGP Multipath
32.1) EGP ORIGIN Clarification
58) Deprication of ATOMIC_AGGREGATE
61) Next Hop for Redistributed Routes
63) Clarify MED Removal Text
65) Rules for Aggregating with MED and NEXT_HOP
66) Complex AS Path Aggregating
67) Counting AS_SET/AS_CONFED_*

----------------------------------------------------------------------------
v1.2 to v1.3
2002-10-16
----------------------------------------------------------------------------

Added:

64) MED for Originated Routes
65) Rules for Aggregating with MED and NEXT_HOP
66) Complex AS Path Aggregating
67) Counting AS_SET/AS_CONFED_*
List of issues that are NOT at consensus

Updated:

8) Jitter Text
10) Extending AS_PATH Attribute
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
19) Appendix Section 6.2: Processing Messages on a Stream Protocol
32.1) EGP ORIGIN Clarification
34) Timer & Counter Definition
37) Combine "Unfeasible Routes" and "Withdrawn Routes"
41) Mention FSM Internal Timers
47) FSM - Add Explicit State Change Wording
49) Explicity Define Event Generation
62) Deprecate BGP Authentication Optional Parameter from RFC1771

Moved FROM Consensus:

11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2

Moved to Consensus:

10) Extending AS_PATH Attribute
19) Appendix Section 6.2: Processing Messages on a Stream Protocol
34) Timer & Counter Definition
37) Combine "Unfeasible Routes" and "Withdrawn Routes"
41) Mention FSM Internal Timers
47) FSM - Add Explicit State Change Wording
49) Explicity Define Event Generation
62) Deprecate BGP Authentication Optional Parameter from RFC1771

----------------------------------------------------------------------------
v1.2 to v1.2.1
2002-10-01
----------------------------------------------------------------------------

Updated:

11.3) Documenting IBGP Multipath
24) Addition or Deletion of Path Attributes
63) Clarify MED Removal Text
TOC) Added issues 62 and 63 to the table of contents.

Moved to Consensus:
24) Addition or Deletion of Path Attributes

----------------------------------------------------------------------------
v1.1.1 to v1.2
2002-10-01
----------------------------------------------------------------------------

Added:
11.3) Documenting IBGP Multipath
62) Deprecate BGP Authentication Optional Parameter from RFC1771
63) Clarify MED Removal Text

Updated:

1) IDR WG Charter
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
13) Next Hop for Originated Route
14) NEXT_HOP to Internal Peer
17) Add References to other RFC-status BGP docs to base spec.
21) Authentication Text Update
22) Scope of Path Attribute Field
24) Addition or Deletion of Path Attributes
27) Allow All Non-Destructive Messages to Refresh Hold Timer
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
36) Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary
37) Combine "Unfeasable Routes" and "Withdrawn Routes"
39) Redundant Sentance Fragments
40) Section 9.2.1.1 - Per Peer vs. Per Router MinRouteAdvertisementInterval
44) Section 6.2: OPEN message error handling
48) Explicitly Define Processing of Incomming Connections
55) Section 4.3 - Description of AS_PATH length
56) Section 6 - BGP Error Handling
58) Deprication of ATOMIC_AGGREGATE
59) Section 4.3 - Move text
61) Next Hop for Redistributed Routes
62) Deprecate BGP Authentication Optional Parameter from RFC1771
63) Clarify MED Removal Text

Moved to Consensus:

9) Reference to RFC904 - EGP Protocol
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
14) NEXT_HOP to Internal Peer (closed in favor of issue 61)
17) Add References to other RFC-status BGP docs to base spec.
21) Authentication Text Update
22) Scope of Path Attribute Field
27) Allow All Non-Destructive Messages to Refresh Hold Timer
29) State Why Unresolveable Routes Should Be Kept in Adj-RIB-In
30) Mention Other Message Types
31) Add References to Additional Options
32.2) BGP Desitnation-based Forwarding Paradigm
33) Add "Optional Non-Transitive" to the MED Section
36) Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary
44) Section 6.2: OPEN message error handling
55) Section 4.3 - Description of AS_PATH length
56) Section 6 - BGP Error Handling
59) Section 4.3 - Move text

----------------------------------------------------------------------------
v1.1 to v1.1.1
2002-09-24
----------------------------------------------------------------------------

Updated:

5) Direct EBGP Peers
   Added the "consensus" line in the actual issue description.
TOC) Added issue 61 to the table-of-contents.

----------------------------------------------------------------------------
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 Sectioules for Aggregating with MED and NEXT_HOP


--z6Eq5LdranGa6ru8--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA22233 for <[e-mail]>; Tue, 22 Oct 2002 21:54:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F30BD9122D; Tue, 22 Oct 2002 21:54:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2E8D9125C; Tue, 22 Oct 2002 21:54: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 C6F139122D for <[e-mail]>; Tue, 22 Oct 2002 21:54:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A9E695DD8D; Tue, 22 Oct 2002 21:54:32 -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 4BEB25DD8C for <[e-mail]>; Tue, 22 Oct 2002 21:54:32 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id SAA04998; Tue, 22 Oct 2002 18:51:10 -0700 (PDT)
Date: Tue, 22 Oct 2002 18:51:10 -0700
From: [e-mail]
To: Alex Zinin <[e-mail]>
Cc: Curtis Villamizar <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: issue 11.2
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, Oct 22, 2002 at 05:44:25PM -0700
Sender: [e-mail]
Precedence: bulk

> >> BTW, is there anyone maintaining the list of documents
> >> that the WG should work on?
> 
> > Were we supposed to do that?  :-)
> 
> > I remember 1) update 1772, 2) update RR and Confed re impact on route
> > decision rules, 3) new BGP multipath document.  The 1772 update would
> > probably need to be a complete rewrite.
> 
> > Did I miss any.
> 
> > Its much easier to just say "put it in another document" and forget
> > about it.  :-)
> 
> This WG would never do this, would it? ;)
> 
> I guess we have to ask Andrew another favor :)
> Andrew, would it be possible to have such a list in
> your document?

Done.  Added in Appendix A of the forthcomming v1.4 edition.

Andrew

> Also, I'd like to suggest that the contents of this list
> is reflected in the proposed WG charter.
> 
> Thanks!
> 
> 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 UAA19253 for <[e-mail]>; Tue, 22 Oct 2002 20:47:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E6A7D9125A; Tue, 22 Oct 2002 20:47:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A83819125B; Tue, 22 Oct 2002 20:47: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 645839125A for <[e-mail]>; Tue, 22 Oct 2002 20:47:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 494D25DDB7; Tue, 22 Oct 2002 20:47: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 202445DD95 for <[e-mail]>; Tue, 22 Oct 2002 20:47:11 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 1849fv-000OHu-00; Tue, 22 Oct 2002 17:47:07 -0700
Date: Tue, 22 Oct 2002 17:44:25 -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.2
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

>> BTW, is there anyone maintaining the list of documents
>> that the WG should work on?

> Were we supposed to do that?  :-)

> I remember 1) update 1772, 2) update RR and Confed re impact on route
> decision rules, 3) new BGP multipath document.  The 1772 update would
> probably need to be a complete rewrite.

> Did I miss any.

> Its much easier to just say "put it in another document" and forget
> about it.  :-)

This WG would never do this, would it? ;)

I guess we have to ask Andrew another favor :)
Andrew, would it be possible to have such a list in
your document?

Also, I'd like to suggest that the contents of this list
is reflected in the proposed WG charter.

Thanks!

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 JAA11737 for <[e-mail]>; Tue, 22 Oct 2002 09:49:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 396A89124F; Tue, 22 Oct 2002 09:49:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0104191250; Tue, 22 Oct 2002 09: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 EB1DE9124F for <[e-mail]>; Tue, 22 Oct 2002 09:49:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C876A5DECE; Tue, 22 Oct 2002 09:49: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 1A3905DD99 for <[e-mail]>; Tue, 22 Oct 2002 09:49:20 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9MDnIi16525; Tue, 22 Oct 2002 09:49: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 g9MDnDC16514; Tue, 22 Oct 2002 09:49:13 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9MDnD409074; Tue, 22 Oct 2002 09:49:13 -0400 (EDT)
Date: Tue, 22 Oct 2002 09:49:13 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 58: final
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, Oct 17, 2002 at 09:09:10AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Thu, Oct 17, 2002 at 09:09:10AM -0700, Yakov Rekhter wrote:
> 58) Deprication of ATOMIC_AGGREGATE
> ----------------------------------------------------------------------------
> The following changes reflect the consensus of the WG:

This looks good.


-- 
Jeff Haas 
NextHop Technologies


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA20462 for <[e-mail]>; Mon, 21 Oct 2002 18:43:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CB9A491248; Mon, 21 Oct 2002 18:43:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 953A291249; Mon, 21 Oct 2002 18: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 6CBD291248 for <[e-mail]>; Mon, 21 Oct 2002 18:43:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 599245DFD7; Mon, 21 Oct 2002 18:43: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 BD03C5DFBD for <[e-mail]>; Mon, 21 Oct 2002 18:43: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 g9LMhGm89427 for <[e-mail]>; Mon, 21 Oct 2002 15:43:16 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: 11.3 BGP Multipath: final
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 21 Oct 2002 15:43:16 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

It seems that we have a pretty clear consensus not to specify
handling BGP multipath in the BGP base spec, but rather have a
separate document that specifies how to handle BGP Multipath (all
the postings on the list, except from Alex, agree to have it as a
separate document). So, to reflect the consensus (and given that
we don't need a "perfect" consensus), we close 11.3 (no BGP Multipath
text in the base spec) and will have a separate document that will
cover BGP Multipath.

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 SAA18241 for <[e-mail]>; Mon, 21 Oct 2002 18:03:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9386E91243; Mon, 21 Oct 2002 18:02:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F27591244; Mon, 21 Oct 2002 18:02: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 7F91091243 for <[e-mail]>; Mon, 21 Oct 2002 18:02:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 56FBC5DFBC; Mon, 21 Oct 2002 18:02:26 -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 D09325DF26 for <[e-mail]>; Mon, 21 Oct 2002 18:02:25 -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 SAA20457; Mon, 21 Oct 2002 18:02:08 -0400 (EDT)
Date: Mon, 21 Oct 2002 18:02:08 -0400 (EDT)
From: Russ White <[e-mail]>
Reply-To: Russ White <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Separate document for multipath - or part of BGP spec 
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

Agreed--let's leave this out of scope, and see about a seperate
draft.

Russ

On Fri, 18 Oct 2002, Natale, Jonathan wrote:

> I think you had proposed adding some type of blurb that basically said that
> this is out of
> scope. I think it is out of scope.  I also think it is sufficiently complex
> to warrant a
> separate draft (doesn't one already exist?).
> 
> Also, in Bgp multipath it is important that there is still only one route
> selected for
> re-advertisement.  The text below does not indicate this.
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Thursday, October 17, 2002 7:58 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Separate document for multipath - or part of BGP spec 
> 
> 
> Curtis,
> 
> > After some discussion initiated by Alex we ended up with the following 
> > text on BGP multipath.  If we can get consensus on text to be added to 
> > the BGP base spec then we'll add text.  If not, we'll omit any mention 
> > of BGP multipath.  We seem to have rough consensus among a small 
> > number of people.
> 
> In addition to getting consensus we also need (at least) two implementations
> of the text. Otherwise, we wouldn't be able to include it in the BGP base
> spec. With this in mind I would appreciate if folks who implement something
> along the lines of the text below drop me an e-mail.
> 
> Yakov.
> 
> > 
> > Curtis
> > 
> > 
> >   [new subesection]
> > 
> >    BGP specifies how to select the single best route.  OSPF
> >    specifically defines procedures for handling equal cost multipath
> >    (ECMP) [cite OSPF].  The same technique has been applied to ISIS.
> >    A similar technique has been used with BGP.  Variations exist but
> >    the decision to support BGP multipath, the specific variation of
> >    BGP multipath, or not to support it, does not affect
> >    interoperability.
> > 
> >    A naive implementations of ECMP can cause severe performance
> >    degradation for TCP flows.  To avoid this, implementations of BGP
> >    multipath SHOULD maintain packet ordering within microflows as
> >    described in [cite rfc2991, rfc2992].
> > 
> >    BGP multipath, if implemented, SHOULD be disabled by default.
> > 
> >    In addition to IGP multipath (OSPF ECMP and ISIS equivalent), there
> >    are two variations of BGP multipath described here.  A BGP
> >    implementation may offer both, either one, or neither variation of
> >    BGP multipath.  Other variations of BGP multipath may exist, but no
> >    guarantees can be made in this protocol specification of their
> >    properties or impact on interoperability.
> > 
> >    Where IGP multipath is used, there is an interaction with BGP
> >    learned routes.  The lookup of a BGP NEXT_HOP in the IGP can
> >    result in the selection of an IGP multipath entry.  This is not a
> >    variation of BGP multipath.  When this occurs, one BGP route is
> >    slected as the best but there is more than one way to reach the BGP
> >    NEXT_HOP via the IGP.
> > 
> >    In one variation of BGP multipath, a set of more than one IBGP
> >    routers peering with the same external AS have equal routes to a
> >    destination and are an equal IGP cost away from a second set of one
> >    or more routers.  BGP multipath is applicable to the latter set of
> >    routers.  Without BGP multipath, BGP would pick the BGP NEXT_HOP of
> >    the advertisement from only one of those IBGP peers (using BGP
> >    Identifier) and use only that BGP route.  With BGP multipath, BGP
> >    uses the BGP NEXT_HOP of more than one of these equal cost
> >    advertisements, yielding more than one BGP NEXT_HOP.  Each BGP
> >    NEXT_HOP has a different IGP next hop (one or more IGP next hop if
> >    IGP multipath is in use).
> > 
> >    The second case is where all of the candidates routes for BGP
> >    multipath are external and learned by a single BGP peer.  Without
> >    BGP multipath this peer would select only one of the BGP routes and
> >    obtain only one BGP NEXT_HOP.  With BGP multipath, more than one
> >    equal cost route is selected yielding more than one BGP NEXT_HOP.
> >    Seldom does IGP multipath come into play when looking up an EBGP
> >    NEXT_HOP but could in principle be applicable.
> > 
> >    If in EBGP multipath traffic is split among routers in difference
> >    AS, an aggregate SHOULD be formed so as to propogate a route with
> >    an accurate AS_PATH.  If the resulting aggregate is not more
> >    specific than the components, the AS_SET SHOULD NOT be dropped.
> > 
> >    The decsion point for multipath is after step "d" in Section
> >    9.1.2.2 (prefer externally learned routes).  IBGP learned and EBGP
> >    learned routes MUST NOT be combined in multipath.  If the multipath
> >    decision is prior to "d", then two routers each with an external
> >    peering would form a routing loop.
> > 
> >    The decision point for multipath is generally after step "e" in
> >    Section 9.1.2.2.  Some relaxation of the "equal cost" rule (also
> >    applicable to IGP multipath) is possible.  In addition to the equal
> >    cost BGP NEXT_HOPS available at BGP route selection, if the IGP
> >    next hop for other BGP NEXT_HOPs are of lower cost, then those may
> >    be used as well.  This relaxation of the step "e" is possible but
> >    is not widely implemented (and may not be implemented at all).
> 

__________________________________
[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 NAA03764 for <[e-mail]>; Mon, 21 Oct 2002 13:42:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 181A29121B; Mon, 21 Oct 2002 13:42:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D603D9123B; Mon, 21 Oct 2002 13:42: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 CBD919121B for <[e-mail]>; Mon, 21 Oct 2002 13:42:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B8EF25DFCC; Mon, 21 Oct 2002 13:42: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 E5A415DFCA for <[e-mail]>; Mon, 21 Oct 2002 13:42:04 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9LHfxw91759; Mon, 21 Oct 2002 13:41: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 g9LHftC91752; Mon, 21 Oct 2002 13:41:55 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9LHftK05424; Mon, 21 Oct 2002 13:41:55 -0400 (EDT)
Date: Mon, 21 Oct 2002 13:41:55 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: Re: issue 11.2
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Sat, Oct 19, 2002 at 05:32:44PM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Sat, Oct 19, 2002 at 05:32:44PM -0700, Yakov Rekhter wrote:
>      In the context of this document we assume that a BGP speaker
>      advertises to its peers only those routes that it
>      itself uses (in this context a BGP speaker is said to "use" a BGP
>      route if it is the most preferred BGP route and is used in
>      forwarding). All other cases are outside the scope of this document.

I can live with 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 MAA28035 for <[e-mail]>; Mon, 21 Oct 2002 12:01:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B8B9791238; Mon, 21 Oct 2002 12:00:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 494549123B; Mon, 21 Oct 2002 12:00: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 B9C3591238 for <[e-mail]>; Mon, 21 Oct 2002 12:00:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E53D25DFC3; Mon, 21 Oct 2002 12:00: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 28D955DFC2 for <[e-mail]>; Mon, 21 Oct 2002 12: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 g9LG0Am54270; Mon, 21 Oct 2002 09:00:10 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 66 (Complex AS Path Aggregating) 
In-Reply-To: Your message of "Mon, 21 Oct 2002 11:56:39 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 21 Oct 2002 09:00:10 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> Yakov:
>   We do support "Complex AS Path Aggregation" at Marconi.

Thanks !!! With this in mind, issue 66 is closed (as we do have
at least two implementations). The section 6.8 stays in the spec.

Yakov.

> 
> Ben
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Monday, October 21, 2002 10:35 AM
> > To: [e-mail]
> > Subject: issue 66 (Complex AS Path Aggregating)
> > 
> > 
> > Folks,
> > 
> > So far we heard of just one implementation. Unless we hear about
> > one more implementation by this Thursday, section 6.8 ("Complex
> > AS Path Aggregation") will be removed from the spec. Likewise,
> > if we hear of least one more implementation by this Thursday,
> > section 6.8 will stay. 
> > 
> > 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 LAA27792 for <[e-mail]>; Mon, 21 Oct 2002 11:57:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A91EC91235; Mon, 21 Oct 2002 11:56:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76F4991238; Mon, 21 Oct 2002 11:56: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 892E991235 for <[e-mail]>; Mon, 21 Oct 2002 11:56:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5C90A5DFC5; Mon, 21 Oct 2002 11:56: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 D53DA5DFC3 for <[e-mail]>; Mon, 21 Oct 2002 11:56: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 LAA12194; Mon, 21 Oct 2002 11:56: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 LAA17351; Mon, 21 Oct 2002 11:56:42 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4W8J7G28>; Mon, 21 Oct 2002 11:56:41 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 66  (Complex AS Path Aggregating)
Date: Mon, 21 Oct 2002 11:56: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

Yakov:
  We do support "Complex AS Path Aggregation" at Marconi.

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Monday, October 21, 2002 10:35 AM
> To: [e-mail]
> Subject: issue 66 (Complex AS Path Aggregating)
> 
> 
> Folks,
> 
> So far we heard of just one implementation. Unless we hear about
> one more implementation by this Thursday, section 6.8 ("Complex
> AS Path Aggregation") will be removed from the spec. Likewise,
> if we hear of least one more implementation by this Thursday,
> section 6.8 will stay. 
> 
> 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 KAA23161 for <[e-mail]>; Mon, 21 Oct 2002 10:35:01 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 435E791229; Mon, 21 Oct 2002 10:34:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 153AA9122C; Mon, 21 Oct 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 942BD91229 for <[e-mail]>; Mon, 21 Oct 2002 10:34:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7FA8A5DF81; Mon, 21 Oct 2002 10:34: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 E557E5DEF7 for <[e-mail]>; Mon, 21 Oct 2002 10:34: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 g9LEYUm48542 for <[e-mail]>; Mon, 21 Oct 2002 07:34:30 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 66  (Complex AS Path Aggregating)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 21 Oct 2002 07:34:30 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

So far we heard of just one implementation. Unless we hear about
one more implementation by this Thursday, section 6.8 ("Complex
AS Path Aggregation") will be removed from the spec. Likewise,
if we hear of least one more implementation by this Thursday,
section 6.8 will stay. 

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 IAA16912 for <[e-mail]>; Mon, 21 Oct 2002 08:46:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E724B9120A; Mon, 21 Oct 2002 08:46:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2CC991224; Mon, 21 Oct 2002 08:46: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 E43009120A for <[e-mail]>; Mon, 21 Oct 2002 08:46:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0767D5DFB0; Mon, 21 Oct 2002 08:45: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 B443F5DFAE for <[e-mail]>; Mon, 21 Oct 2002 08:45:46 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT8P4S>; Mon, 21 Oct 2002 08:45:46 -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 11.2 
Date: Mon, 21 Oct 2002 08:45:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

ok

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Saturday, October 19, 2002 8:33 PM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: issue 11.2 


Jonathan,

> ...except for what Jeff raised--I think we should remove
> "(other BGP speakers which it communicates with) in neighboring ASs"
> 
> :-)

ok, so how about the following:

     In the context of this document we assume that a BGP speaker
     advertises to its peers only those routes that it
     itself uses (in this context a BGP speaker is said to "use" a BGP
     route if it is the most preferred BGP route and is used in
     forwarding). All other cases are outside the scope of this document.

Yakov.

> 
> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Friday, October 18, 2002 5:05 PM
> To: 'Yakov Rekhter'; [e-mail]
> Subject: RE: issue 11.2
> 
> 
> that would be fine
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Friday, October 18, 2002 4:44 PM
> To: [e-mail]
> Subject: issue 11.2
> 
> 
>   11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
>   
> ----------------------------------------------------------------------
>       
> Folks I wonder whether the following text would be enough to close 
> this
> issue:
> 
>    In the context of this document we assume 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 (in this context a BGP speaker is said to "use" a BGP
>    route if it is the most preferred BGP route and is used in 
>    forwarding). All other cases 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 UAA19784 for <[e-mail]>; Sat, 19 Oct 2002 20:41:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A7A3791217; Sat, 19 Oct 2002 20:40:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7369691222; Sat, 19 Oct 2002 20:40: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 4EDC191217 for <[e-mail]>; Sat, 19 Oct 2002 20:40:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 319DA5DF0C; Sat, 19 Oct 2002 20:40: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 915F15DF0A for <[e-mail]>; Sat, 19 Oct 2002 20:40: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 g9K0eQm74458; Sat, 19 Oct 2002 17:40:26 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: "Michael C. Cambria" <[e-mail]>, [e-mail]
Subject: Re: issue 11.2 
In-Reply-To: Your message of "Fri, 18 Oct 2002 17:33:35 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sat, 19 Oct 2002 17:40:26 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> Michael,
> 
> On Fri, Oct 18, 2002 at 05:02:58PM -0400, Michael C. Cambria wrote:
> > Doesn't injecting a route into BGP make that route a BGP route?
> 
> If it does, then there's no issue and I'm overly hung up about the
> words.  I typically think of a bgp route as one that has come from
> BGP.  When you inject a route, you're taking a non-bgp route and
> redistributing it.

and thus it becomes a BGP 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 UAA19517 for <[e-mail]>; Sat, 19 Oct 2002 20:36:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 985EF91205; Sat, 19 Oct 2002 20:36:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E4C591217; Sat, 19 Oct 2002 20:36: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 51DF391205 for <[e-mail]>; Sat, 19 Oct 2002 20:36:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3EBE95DF03; Sat, 19 Oct 2002 20:36: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 CFE515DEFE for <[e-mail]>; Sat, 19 Oct 2002 20:36: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 g9K0aKm74390; Sat, 19 Oct 2002 17:36:20 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 11.2 
In-Reply-To: Your message of "Fri, 18 Oct 2002 16:52:54 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sat, 19 Oct 2002 17:36:20 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> Yakov,
> 
> On Fri, Oct 18, 2002 at 01:43:40PM -0700, Yakov Rekhter wrote:
> > Folks I wonder whether the following text would be enough to
> > close this issue:
> > 
> >    In the context of this document we assume that a BGP speaker 
> >    advertises to its peers (other BGP speakers which it
> >    communicates with) in neighboring ASs only those routes that it
> 
> Why only neighboring as's?
> 
> >    itself uses (in this context a BGP speaker is said to "use" a BGP
> >    route if it is the most preferred BGP route and is used in 
> >    forwarding). All other cases are outside the scope of this document.
> 
> Are we specifically trying to say that the process of injecting
> a route into bgp is outside the scope of the bgp protocol document?

There is some text in 9.4 on the subject of originating BGP routes.
In general redistribution of non-BGP routes (e.g., IGP routes)
into BGP is clearly outside the scope of the base spec (we've been
through this more than once).

> If not, the parenthesized text needs to be tweaked.

With the above in mind, do you still see the need for the
parenthesized text needs to be tweaked ? If yes, please
proposed the replacement.

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 UAA19365 for <[e-mail]>; Sat, 19 Oct 2002 20:33:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8B8ED9120C; Sat, 19 Oct 2002 20:33:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5971F91205; Sat, 19 Oct 2002 20:33: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 D64A59120C for <[e-mail]>; Sat, 19 Oct 2002 20:32:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id AD0E35DF06; Sat, 19 Oct 2002 20:32: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 4E00E5DEEE for <[e-mail]>; Sat, 19 Oct 2002 20:32: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 g9K0Wim74328; Sat, 19 Oct 2002 17:32:44 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 11.2 
In-Reply-To: Your message of "Fri, 18 Oct 2002 17:08:43 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Sat, 19 Oct 2002 17:32:44 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> ...except for what Jeff raised--I think we should remove 
> "(other BGP speakers which it communicates with) in neighboring ASs"
> 
> :-)

ok, so how about the following:

     In the context of this document we assume that a BGP speaker
     advertises to its peers only those routes that it
     itself uses (in this context a BGP speaker is said to "use" a BGP
     route if it is the most preferred BGP route and is used in
     forwarding). All other cases are outside the scope of this document.

Yakov.

> 
> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]] 
> Sent: Friday, October 18, 2002 5:05 PM
> To: 'Yakov Rekhter'; [e-mail]
> Subject: RE: issue 11.2
> 
> 
> that would be fine
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Friday, October 18, 2002 4:44 PM
> To: [e-mail]
> Subject: issue 11.2
> 
> 
>   11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
>   ----------------------------------------------------------------------
>       
> Folks I wonder whether the following text would be enough to close this
> issue:
> 
>    In the context of this document we assume 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 (in this context a BGP speaker is said to "use" a BGP
>    route if it is the most preferred BGP route and is used in 
>    forwarding). All other cases 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 LAA20538 for <[e-mail]>; Sat, 19 Oct 2002 11:48:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3E6F591218; Sat, 19 Oct 2002 11:48:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E54491234; Sat, 19 Oct 2002 11:48: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 89D6191218 for <[e-mail]>; Sat, 19 Oct 2002 11:47:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4C5305DEC2; Sat, 19 Oct 2002 11:47:46 -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 6DD225DE1A for <[e-mail]>; Sat, 19 Oct 2002 11:47:45 -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 LAA06043; Sat, 19 Oct 2002 11:46:40 -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.2 
In-reply-to: Your message of "Fri, 18 Oct 2002 14:48:31 PDT." <[e-mail]> 
Date: Sat, 19 Oct 2002 11:46:40 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Alex Zinin writes:
> Friday, October 18, 2002, 2:17:44 PM, Jeffrey Haas wrote:
> [...]
> > Its been pointed out to me that this may be a case of having the
> > "route redistribution question" discussed again.  If route origination
> > is clearly covered in the yet-to-be-released draft, this is probably cool.
> 
> BTW, is there anyone maintaining the list of documents
> that the WG should work on?
> 
> Alex


Were we supposed to do that?  :-)

I remember 1) update 1772, 2) update RR and Confed re impact on route
decision rules, 3) new BGP multipath document.  The 1772 update would
probably need to be a complete rewrite.

Did I miss any.

Its much easier to just say "put it in another document" and forget
about 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 VAA00167 for <[e-mail]>; Fri, 18 Oct 2002 21:21:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 835E991324; Fri, 18 Oct 2002 21:21:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 548C091325; Fri, 18 Oct 2002 21:21: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 8E9BF91324 for <[e-mail]>; Fri, 18 Oct 2002 21:21:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 73C395DE93; Fri, 18 Oct 2002 21:21:22 -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 F0B385DE81 for <[e-mail]>; Fri, 18 Oct 2002 21:21:21 -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 g9J1Hhtq038929; Fri, 18 Oct 2002 21:17:44 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 18 Oct 2002 21:17:43 -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]
Cc: Jeffrey Haas <[e-mail]>
Subject: Re: issue 11.2
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

Jeffrey Haas wrote:
 >
 > On Fri, Oct 18, 2002 at 05:02:58PM -0400, Michael C. Cambria wrote:

[deleted]

 >
 >>The
 >>route now lives in Loc-RIB, and other peers will see it as a BGP route,
 >>with attributes (e.g. Origin=IGP or Origin=Incomplete, depending on how
 >>the route was "injected" into BGP.)
 >
 >
 > Its the interaction between Loc-Rib and our documented process in 9.4
 > that bothers me.  9.4 says that we put a route through the decision
 > process - logically as if we had a "routing table peer".


I read 9.4 as implying an Adj_Rib_in for locally originated routes (e.g.
via network or redistribute commands).  This is how I read what you
refer to above as a logical "routing table peer".

What to set the attributes to are covered in -17 (plus the resolved
issues list being kept.)  At this point, don't we have an 'Adj-Rib-In' 
on which section 9.1 can be invoked?

  > However,
  > this route may depend on what BGP would chose as its best route.
  > Potentially a circular dependency.

I don't see this.  What am I missing?  How I understand things is 
described below:


Using a (logical) Adj-Rib-In for locally originated routes, you should 
be able to invoke the decision process as if an UPDATE was received.  I 
conceed that I am doing some handwaving.  Reading 9.1.1 literally, one 
wouldn't calculate a degress of preference at all (i.e. invoke phase 1) 
since no UPDATE was received.  The text in this section also doesn't 
mention anything about locally originated routes, while explicitly 
describing what to do for both internal and external peers.

That said, even though no mention in 9.1.1 of locally originated routes 
is made, the entire section allows for "local policy" to determine the 
degree of preference.  For example, locally injected routes are set to 
degree of preference of 'x'.  The value for 'x' can be hardcoded or user 
configured, or whatever.

Phase 2 starts from there.  The "best" BGP route, locally originated or 
from a real peer (internal or external) is chosen.  This makes it to 
Loc-Rib.

Yakov's proposed text takes care of phase 3.  As far as the scope of the 
draft is concerned, if the Loc-Rib route is used for forwarding, the 
route can be advertised to a peer.


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 RAA18235 for <[e-mail]>; Fri, 18 Oct 2002 17:50:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3542B9131D; Fri, 18 Oct 2002 17:50:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC3E19131E; Fri, 18 Oct 2002 17:50: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 40D919131D for <[e-mail]>; Fri, 18 Oct 2002 17:50:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 251845DE37; Fri, 18 Oct 2002 17:50:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id F070C5DDFF for <[e-mail]>; Fri, 18 Oct 2002 17:50:39 -0400 (EDT)
Received: from psg.com ([147.28.0.62] helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 3.36 #2) id 182f0u-000NWf-00; Fri, 18 Oct 2002 14:50:37 -0700
Date: Fri, 18 Oct 2002 14:48:31 -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: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: issue 11.2
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Friday, October 18, 2002, 2:17:44 PM, Jeffrey Haas wrote:
[...]
> Its been pointed out to me that this may be a case of having the
> "route redistribution question" discussed again.  If route origination
> is clearly covered in the yet-to-be-released draft, this is probably cool.

BTW, is there anyone maintaining the list of documents
that the WG should work on?

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 RAA17198 for <[e-mail]>; Fri, 18 Oct 2002 17:34:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 304AE9131B; Fri, 18 Oct 2002 17:33:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F18D19131C; Fri, 18 Oct 2002 17:33: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 ED39B9131B for <[e-mail]>; Fri, 18 Oct 2002 17:33:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C85C15DDFF; Fri, 18 Oct 2002 17:33: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 49DB65DDEE for <[e-mail]>; Fri, 18 Oct 2002 17:33:46 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9ILXdf37950; Fri, 18 Oct 2002 17:33: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 g9ILXZC37939; Fri, 18 Oct 2002 17:33:35 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9ILXZ928340; Fri, 18 Oct 2002 17:33:35 -0400 (EDT)
Date: Fri, 18 Oct 2002 17:33:35 -0400
From: Jeffrey Haas <[e-mail]>
To: "Michael C. Cambria" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 11.2
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, Oct 18, 2002 at 05:02:58PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Michael,

On Fri, Oct 18, 2002 at 05:02:58PM -0400, Michael C. Cambria wrote:
> Doesn't injecting a route into BGP make that route a BGP route?

If it does, then there's no issue and I'm overly hung up about the
words.  I typically think of a bgp route as one that has come from
BGP.  When you inject a route, you're taking a non-bgp route and
redistributing it.

> The 
> route now lives in Loc-RIB, and other peers will see it as a BGP route, 
> with attributes (e.g. Origin=IGP or Origin=Incomplete, depending on how 
> the route was "injected" into BGP.)

Its the interaction between Loc-Rib and our documented process in 9.4
that bothers me.  9.4 says that we put a route through the decision
process - logically as if we had a "routing table peer".  However,
this route may depend on what BGP would chose as its best route.
Potentially a circular dependency.

> 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 RAA16587 for <[e-mail]>; Fri, 18 Oct 2002 17:22:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EBCA39131A; Fri, 18 Oct 2002 17:22:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BCF6F9131B; Fri, 18 Oct 2002 17:22: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 2155D9131A for <[e-mail]>; Fri, 18 Oct 2002 17:22:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 101525DE14; Fri, 18 Oct 2002 17:22:00 -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 921025DDFF for <[e-mail]>; Fri, 18 Oct 2002 17:21: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 g9ILIJtq038659 for <[e-mail]>; Fri, 18 Oct 2002 17:18:22 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 18 Oct 2002 17:02:58 -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 11.2
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:
> Yakov,
> 
> On Fri, Oct 18, 2002 at 01:43:40PM -0700, Yakov Rekhter wrote:
> 
>>Folks I wonder whether the following text would be enough to
>>close this issue:
>>
>>   In the context of this document we assume that a BGP speaker 
>>   advertises to its peers (other BGP speakers which it
>>   communicates with) in neighboring ASs only those routes that it
> 
> 
> Why only neighboring as's?
> 
> 
>>   itself uses (in this context a BGP speaker is said to "use" a BGP
>>   route if it is the most preferred BGP route and is used in 
>>   forwarding). All other cases are outside the scope of this document.
> 
> 
> Are we specifically trying to say that the process of injecting
> a route into bgp is outside the scope of the bgp protocol document?

Doesn't injecting a route into BGP make that route a BGP route?  The 
route now lives in Loc-RIB, and other peers will see it as a BGP route, 
with attributes (e.g. Origin=IGP or Origin=Incomplete, depending on how 
the route was "injected" into BGP.)

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 RAA16325 for <[e-mail]>; Fri, 18 Oct 2002 17:18:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2E86D91319; Fri, 18 Oct 2002 17:18:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 051639131B; Fri, 18 Oct 2002 17:18: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 1570B91319 for <[e-mail]>; Fri, 18 Oct 2002 17:17:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E2ECE5DDEE; Fri, 18 Oct 2002 17:17: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 287795DD9A for <[e-mail]>; Fri, 18 Oct 2002 17:17:50 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9ILHmP37478; Fri, 18 Oct 2002 17:17: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 g9ILHiC37471; Fri, 18 Oct 2002 17:17:44 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9ILHi128175; Fri, 18 Oct 2002 17:17:44 -0400 (EDT)
Date: Fri, 18 Oct 2002 17:17:44 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 11.2
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, Oct 18, 2002 at 04:52:54PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Fri, Oct 18, 2002 at 04:52:54PM -0400, Jeffrey Haas wrote:
> Are we specifically trying to say that the process of injecting
> a route into bgp is outside the scope of the bgp protocol document?

Its been pointed out to me that this may be a case of having the
"route redistribution question" discussed again.  If route origination
is clearly covered in the yet-to-be-released draft, this is probably cool.

-- 
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 RAA15795 for <[e-mail]>; Fri, 18 Oct 2002 17:09:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4EF4A91317; Fri, 18 Oct 2002 17:08:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C0B391318; Fri, 18 Oct 2002 17:08: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 82CF891317 for <[e-mail]>; Fri, 18 Oct 2002 17:08:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6F9DE5DD9A; Fri, 18 Oct 2002 17:08: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 105ED5DE37 for <[e-mail]>; Fri, 18 Oct 2002 17:08:44 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT8GLT>; Fri, 18 Oct 2002 17:08:43 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 11.2
Date: Fri, 18 Oct 2002 17:08:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

...except for what Jeff raised--I think we should remove 
"(other BGP speakers which it communicates with) in neighboring ASs"

:-)

-----Original Message-----
From: Natale, Jonathan [mailto:[e-mail]] 
Sent: Friday, October 18, 2002 5:05 PM
To: 'Yakov Rekhter'; [e-mail]
Subject: RE: issue 11.2


that would be fine

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Friday, October 18, 2002 4:44 PM
To: [e-mail]
Subject: issue 11.2


  11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
  ----------------------------------------------------------------------
      
Folks I wonder whether the following text would be enough to close this
issue:

   In the context of this document we assume 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 (in this context a BGP speaker is said to "use" a BGP
   route if it is the most preferred BGP route and is used in 
   forwarding). All other cases 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 RAA15624 for <[e-mail]>; Fri, 18 Oct 2002 17:05:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 429ED91316; Fri, 18 Oct 2002 17:05:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DB5391317; Fri, 18 Oct 2002 17:05: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 8ED1C91316 for <[e-mail]>; Fri, 18 Oct 2002 17:05:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7541E5DDFF; Fri, 18 Oct 2002 17:05: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 2B2255DD9A for <[e-mail]>; Fri, 18 Oct 2002 17:05:27 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT8GLM>; Fri, 18 Oct 2002 17:05:26 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 11.2
Date: Fri, 18 Oct 2002 17:05:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

that would be fine

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Friday, October 18, 2002 4:44 PM
To: [e-mail]
Subject: issue 11.2


  11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
  ----------------------------------------------------------------------
      
Folks I wonder whether the following text would be enough to close this
issue:

   In the context of this document we assume 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 (in this context a BGP speaker is said to "use" a BGP
   route if it is the most preferred BGP route and is used in 
   forwarding). All other cases 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 QAA14889 for <[e-mail]>; Fri, 18 Oct 2002 16:53:30 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A6BA991314; Fri, 18 Oct 2002 16:53:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DC1891316; Fri, 18 Oct 2002 16:53: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 255E191314 for <[e-mail]>; Fri, 18 Oct 2002 16:53:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 08D715DE14; Fri, 18 Oct 2002 16:53: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 332C75DD9A for <[e-mail]>; Fri, 18 Oct 2002 16:53:01 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9IKqw336678; Fri, 18 Oct 2002 16:52: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 g9IKqsC36671; Fri, 18 Oct 2002 16:52:54 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9IKqsG27975; Fri, 18 Oct 2002 16:52:54 -0400 (EDT)
Date: Fri, 18 Oct 2002 16:52:54 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 11.2
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, Oct 18, 2002 at 01:43:40PM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Fri, Oct 18, 2002 at 01:43:40PM -0700, Yakov Rekhter wrote:
> Folks I wonder whether the following text would be enough to
> close this issue:
> 
>    In the context of this document we assume that a BGP speaker 
>    advertises to its peers (other BGP speakers which it
>    communicates with) in neighboring ASs only those routes that it

Why only neighboring as's?

>    itself uses (in this context a BGP speaker is said to "use" a BGP
>    route if it is the most preferred BGP route and is used in 
>    forwarding). All other cases are outside the scope of this document.

Are we specifically trying to say that the process of injecting
a route into bgp is outside the scope of the bgp protocol document?

If not, the parenthesized text needs to be tweaked.

> 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 QAA14334 for <[e-mail]>; Fri, 18 Oct 2002 16:44:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A74C291313; Fri, 18 Oct 2002 16:43:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 725A791314; Fri, 18 Oct 2002 16: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 ED69E91313 for <[e-mail]>; Fri, 18 Oct 2002 16:43:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CA71E5DE14; Fri, 18 Oct 2002 16:43: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 3BD455DD9A for <[e-mail]>; Fri, 18 Oct 2002 16:43: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 g9IKhem19665 for <[e-mail]>; Fri, 18 Oct 2002 13:43:40 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 11.2
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 18 Oct 2002 13:43:40 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
  ----------------------------------------------------------------------
      
Folks I wonder whether the following text would be enough to
close this issue:

   In the context of this document we assume 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 (in this context a BGP speaker is said to "use" a BGP
   route if it is the most preferred BGP route and is used in 
   forwarding). All other cases 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 OAA06617 for <[e-mail]>; Fri, 18 Oct 2002 14:26:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6CCB791214; Fri, 18 Oct 2002 14:26:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CA2291312; Fri, 18 Oct 2002 14:26: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 B2E6191214 for <[e-mail]>; Fri, 18 Oct 2002 14:25:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9A26A5DE44; Fri, 18 Oct 2002 14:25: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 3A67C5DE01 for <[e-mail]>; Fri, 18 Oct 2002 14:25: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 g9IIPvm07439; Fri, 18 Oct 2002 11:25:57 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 63 
In-Reply-To: Your message of "Fri, 18 Oct 2002 13:20:52 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 18 Oct 2002 11:25:57 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> What will neighborAS(n) return the if the route is learned via IBGP and the
> other IBGP speaker originated the route? (0 ???)

the local AS.

with this in mind, (and taking into account your editorial comments)
here is proposed text:

In 5.1.4 replace:

   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over EBGP.
   If it does so, it shall do so prior to determining the degree of
   preference of the route and performing route selection (decision
   process phases 1 and 2).

with:

   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over EBGP.
   This MAY be done prior to determining the degree of preference
   of the route and performing route selection (decision process phases
   1 and 2). See section 9.1.2.2 for necessary restricts on this.
      
In 9.1.2.2 replace:

   Similarly, neighborAS(n) is a function which returns the neighbor
   AS from which the route was received.
      
with:

   Similarly, neighborAS(n) is a function which returns the neighbor
   AS from which the route was received.  If the route is learned
   via IBGP, and the other IBGP speaker didn't originate the route,
   it is the neighbor AS from which the other IBGP speaker learned
   the route. If the route is learned via IBGP, and the other IBGP
   speaker originated the route, it is the local AS.

   If a MULTI_EXIT_DISC attribute is removed before re-advertising
   a route into IBGP, the MULTI_EXIT_DISC attribute may only be      
   considered in the comparison of EBGP learned routes, then
   removed, then the remaining EBGP learned route may be compared    
   to the remaining IBGP learned routes, without considering the    
   MULTI_EXIT_DISC attribute for those EBGP learned routes whose
   MULTI_EXIT_DISC will be dropped before advertising to IBGP.
   Including the MULTI_EXIT_DISC of an EBGP learned route in the
   comparison with an IBGP learned route, then dropping the
   MULTI_EXIT_DISC and advertising the route has been proven to
   cause route loops.

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 NAA03841 for <[e-mail]>; Fri, 18 Oct 2002 13:37:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 201629130E; Fri, 18 Oct 2002 13:37:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CEC4191311; Fri, 18 Oct 2002 13:37: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 497199130E for <[e-mail]>; Fri, 18 Oct 2002 13:37:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 309F65DE61; Fri, 18 Oct 2002 13:37: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 E1B625DE44 for <[e-mail]>; Fri, 18 Oct 2002 13:37:29 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT8FKF>; Fri, 18 Oct 2002 13:37:29 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: RE: New Issue - Outbound Loop Detection 
Date: Fri, 18 Oct 2002 13:37: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,

OK, you are correct on both counts.

-Jonathan


-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Friday, October 18, 2002 1:32 PM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: New Issue - Outbound Loop Detection 


Jonathan,

> This paper (thanks Jeff) 
> http://www.research.microsoft.com/scripts/pubs/view.asp?TR_ID=MSR-TR-2
> 000-08
> indicates that it is better to do the loop detection outbound as well 
> inbound. The current draft indicates that it only needs to be done
inbound. 
> IOS does it inbound as well as outbound. GateD/Juniper does it (did it
???) 
> only inbound.
> 
> So I propose we add:
> "An implementation MAY choose to not advertise routes to EBGP peers if 
> these routes contain the AS of that peer in the AS path."
> after:
> "If the autonomous system number appears in the AS path the route may 
> be stored in the Adj-RIB In, but unless the router is configured to 
> accept routes with its own AS in the AS path, the route shall not be 
> passed to the BGP Decision Process."

First of all, if we add the text you proposed it should go into 9.1.3, and
not in 9 (as Section 9 deals with processing UPDATE messages, while Seciton
9.1.3 deals with advertising routes to peers. 

Second, we could add this sentence only if there are at least two
implementations that support it. So, folks who implement the outbound loop
detection please drop an e-mail within a week.

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 NAA03623 for <[e-mail]>; Fri, 18 Oct 2002 13:33:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 801F491310; Fri, 18 Oct 2002 13:33:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 537719130E; Fri, 18 Oct 2002 13:33: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 DA79D91311 for <[e-mail]>; Fri, 18 Oct 2002 13:32:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B429B5DE61; Fri, 18 Oct 2002 13:32: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 20ACF5DE44 for <[e-mail]>; Fri, 18 Oct 2002 13:32: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 g9IHWmm02494; Fri, 18 Oct 2002 10:32:48 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 63 
In-Reply-To: Your message of "Fri, 18 Oct 2002 13:29:33 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 18 Oct 2002 10:32:48 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I suggest replacing "redistributing" with "re-advertising" to reflect more
> recent common usage.
> 
> also change:
> "BGP learned routes, them"
> to:
> "BGP learned routes, then"

accepted.

yakov.

> 
> 
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Friday, October 18, 2002 1:06 PM
> To: [e-mail]
> Subject: issue 63
> 
> 
> 63) Clarify MED Removal Text
> ----------------------------------------------------------------------------
> Following suggestion from Curtis, here are the changes:
> 
> In 5.1.4 replace:
> 
>    An implementation MAY also (based on local configuration) alter the
>    value of the MULTI_EXIT_DISC attribute received over EBGP.
>    If it does so, it shall do so prior to determining the degree of
>    preference of the route and performing route selection (decision
>    process phases 1 and 2).
> 
> with:
> 
>    An implementation MAY also (based on local configuration) alter the
>    value of the MULTI_EXIT_DISC attribute received over EBGP.
>    This MAY be done prior to determining the degree of preference
>    of the route and performing route selection (decision process phases
>    1 and 2). See section 9.1.2.2 for necessary restricts on this.
>       
> In 9.1.2.2 replace:
> 
>    Similarly, neighborAS(n) is a function which returns the neighbor
>    AS from which the route was received.
>       
> with:
> 
>    Similarly, neighborAS(n) is a function which returns the
>    neighbor AS from which the route was received.  If the route is  
>    learned via IBGP, it is the neighbor AS from which the other
>    IBGP speaker learned the route, not the local AS.
> 
>    If a MULTI_EXIT_DISC attribute is removed before redistributing
>    a route into IBGP, the MULTI_EXIT_DISC attribute may only be      
>    considered in the comparison of EBGP learned routes, them
>    removed, then the remaining EBGP learned route may be compared    
>    to the remaining IBGP learned routes, without considering the    
>    MULTI_EXIT_DISC attribute for those EBGP learned routes whose
>    MULTI_EXIT_DISC will be dropped before advertising to IBGP.
>    Including the MULTI_EXIT_DISC of an EBGP learned route in the
>    comparison with an IBGP learned route, then dropping the
>    MULTI_EXIT_DISC and advertising the route has been proven to
>    cause route loops.
> 
> In the absence of objections I'll make the above changes.
> 
> 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 NAA03544 for <[e-mail]>; Fri, 18 Oct 2002 13:32:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6FE9F9130F; Fri, 18 Oct 2002 13:32:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A85191310; Fri, 18 Oct 2002 13: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 93CED9130F for <[e-mail]>; Fri, 18 Oct 2002 13:31:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 77A725DE61; Fri, 18 Oct 2002 13:31: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 109985DE6C for <[e-mail]>; Fri, 18 Oct 2002 13:31: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 g9IHVtm02428; Fri, 18 Oct 2002 10:31:55 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: New Issue - Outbound Loop Detection 
In-Reply-To: Your message of "Fri, 18 Oct 2002 13:17:22 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 18 Oct 2002 10:31:55 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> This paper (thanks Jeff)
> http://www.research.microsoft.com/scripts/pubs/view.asp?TR_ID=MSR-TR-2000-08
> indicates that it is better to do the loop detection outbound as well 
> inbound. The current draft indicates that it only needs to be done inbound. 
> IOS does it inbound as well as outbound. GateD/Juniper does it (did it ???) 
> only inbound.
> 
> So I propose we add:
> "An implementation MAY choose to not advertise routes to EBGP peers if these
> routes contain the AS of that peer in the AS path."
> after:
> "If the autonomous system number appears in the AS path the route may be
> stored in the Adj-RIB In, but unless the router is configured to accept 
> routes with its own AS in the AS path, the route shall not be passed to 
> the BGP Decision Process."

First of all, if we add the text you proposed it should go into 9.1.3,
and not in 9 (as Section 9 deals with processing UPDATE messages, while
Seciton 9.1.3 deals with advertising routes to peers. 

Second, we could add this sentence only if there are at least two
implementations that support it. So, folks who implement the outbound
loop detection please drop an e-mail within a week.

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 NAA03373 for <[e-mail]>; Fri, 18 Oct 2002 13:30:15 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2AD509130D; Fri, 18 Oct 2002 13:29:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1F069130E; Fri, 18 Oct 2002 13:29: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 5282A9130D for <[e-mail]>; Fri, 18 Oct 2002 13:29:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 350A45DE61; Fri, 18 Oct 2002 13:29: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 E98735DE44 for <[e-mail]>; Fri, 18 Oct 2002 13:29:34 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT8FJD>; Fri, 18 Oct 2002 13:29:34 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 63
Date: Fri, 18 Oct 2002 13:29:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I suggest replacing "redistributing" with "re-advertising" to reflect more
recent common usage.

also change:
"BGP learned routes, them"
to:
"BGP learned routes, then"



-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Friday, October 18, 2002 1:06 PM
To: [e-mail]
Subject: issue 63


63) Clarify MED Removal Text
----------------------------------------------------------------------------
Following suggestion from Curtis, here are the changes:

In 5.1.4 replace:

   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over EBGP.
   If it does so, it shall do so prior to determining the degree of
   preference of the route and performing route selection (decision
   process phases 1 and 2).

with:

   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over EBGP.
   This MAY be done prior to determining the degree of preference
   of the route and performing route selection (decision process phases
   1 and 2). See section 9.1.2.2 for necessary restricts on this.
      
In 9.1.2.2 replace:

   Similarly, neighborAS(n) is a function which returns the neighbor
   AS from which the route was received.
      
with:

   Similarly, neighborAS(n) is a function which returns the
   neighbor AS from which the route was received.  If the route is  
   learned via IBGP, it is the neighbor AS from which the other
   IBGP speaker learned the route, not the local AS.

   If a MULTI_EXIT_DISC attribute is removed before redistributing
   a route into IBGP, the MULTI_EXIT_DISC attribute may only be      
   considered in the comparison of EBGP learned routes, them
   removed, then the remaining EBGP learned route may be compared    
   to the remaining IBGP learned routes, without considering the    
   MULTI_EXIT_DISC attribute for those EBGP learned routes whose
   MULTI_EXIT_DISC will be dropped before advertising to IBGP.
   Including the MULTI_EXIT_DISC of an EBGP learned route in the
   comparison with an IBGP learned route, then dropping the
   MULTI_EXIT_DISC and advertising the route has been proven to
   cause route loops.

In the absence of objections I'll make the above changes.

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 NAA02947 for <[e-mail]>; Fri, 18 Oct 2002 13:22:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id ABC879130C; Fri, 18 Oct 2002 13:21:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CA1091312; Fri, 18 Oct 2002 13:21: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 819D59130C for <[e-mail]>; Fri, 18 Oct 2002 13:20:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 35C075DE67; Fri, 18 Oct 2002 13:20: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 BB9B65DE45 for <[e-mail]>; Fri, 18 Oct 2002 13:20:52 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT8F2F>; Fri, 18 Oct 2002 13:20:52 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 63
Date: Fri, 18 Oct 2002 13:20:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

What will neighborAS(n) return the if the route is learned via IBGP and the
other IBGP speaker originated the route? (0 ???)

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Friday, October 18, 2002 1:06 PM
To: [e-mail]
Subject: issue 63


63) Clarify MED Removal Text
----------------------------------------------------------------------------
Following suggestion from Curtis, here are the changes:

In 5.1.4 replace:

   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over EBGP.
   If it does so, it shall do so prior to determining the degree of
   preference of the route and performing route selection (decision
   process phases 1 and 2).

with:

   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over EBGP.
   This MAY be done prior to determining the degree of preference
   of the route and performing route selection (decision process phases
   1 and 2). See section 9.1.2.2 for necessary restricts on this.
      
In 9.1.2.2 replace:

   Similarly, neighborAS(n) is a function which returns the neighbor
   AS from which the route was received.
      
with:

   Similarly, neighborAS(n) is a function which returns the
   neighbor AS from which the route was received.  If the route is  
   learned via IBGP, it is the neighbor AS from which the other
   IBGP speaker learned the route, not the local AS.

   If a MULTI_EXIT_DISC attribute is removed before redistributing
   a route into IBGP, the MULTI_EXIT_DISC attribute may only be      
   considered in the comparison of EBGP learned routes, them
   removed, then the remaining EBGP learned route may be compared    
   to the remaining IBGP learned routes, without considering the    
   MULTI_EXIT_DISC attribute for those EBGP learned routes whose
   MULTI_EXIT_DISC will be dropped before advertising to IBGP.
   Including the MULTI_EXIT_DISC of an EBGP learned route in the
   comparison with an IBGP learned route, then dropping the
   MULTI_EXIT_DISC and advertising the route has been proven to
   cause route loops.

In the absence of objections I'll make the above changes.

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 NAA02737 for <[e-mail]>; Fri, 18 Oct 2002 13:18:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 18C8F9130A; Fri, 18 Oct 2002 13:18:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F2729130B; Fri, 18 Oct 2002 13:17: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 3819B9130A for <[e-mail]>; Fri, 18 Oct 2002 13:17:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 145385DE45; Fri, 18 Oct 2002 13:17: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 CACB15DE44 for <[e-mail]>; Fri, 18 Oct 2002 13:17:23 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT8FHY>; Fri, 18 Oct 2002 13:17:23 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: New Issue - Outbound Loop Detection
Date: Fri, 18 Oct 2002 13:17:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

This paper (thanks Jeff)
http://www.research.microsoft.com/scripts/pubs/view.asp?TR_ID=MSR-TR-2000-08
indicates that it
is better to do the loop detection outbound as well inbound.  The current
draft indicates that
it only needs to be done inbound.  IOS does it inbound as well as outbound.
GateD/Juniper
does it (did it ???) only inbound.

So I propose we add:
"An implementation MAY choose to not advertise routes to EBGP peers if these
routes contain
the AS of that peer in the AS path."
after:
"If the autonomous system number appears in the AS path the route may be
stored in the
Adj-RIB In, but unless the router is configured to accept routes with its
own AS in the
AS path, the route shall not be passed to the BGP Decision Process."

*If there is at least one other implementation that does outbound
pruning/loop-detection.*


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA02149 for <[e-mail]>; Fri, 18 Oct 2002 13:08:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EEBD191309; Fri, 18 Oct 2002 13:06:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBFF19130B; Fri, 18 Oct 2002 13:06: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 0EA6791309 for <[e-mail]>; Fri, 18 Oct 2002 13:06:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F0EA95DE44; Fri, 18 Oct 2002 13:06:15 -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 90BF95DE01 for <[e-mail]>; Fri, 18 Oct 2002 13:06: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 g9IH6Fm00248 for <[e-mail]>; Fri, 18 Oct 2002 10:06:15 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 63
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 18 Oct 2002 10:06:15 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

63) Clarify MED Removal Text
----------------------------------------------------------------------------
Following suggestion from Curtis, here are the changes:

In 5.1.4 replace:

   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over EBGP.
   If it does so, it shall do so prior to determining the degree of
   preference of the route and performing route selection (decision
   process phases 1 and 2).

with:

   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over EBGP.
   This MAY be done prior to determining the degree of preference
   of the route and performing route selection (decision process phases
   1 and 2). See section 9.1.2.2 for necessary restricts on this.
      
In 9.1.2.2 replace:

   Similarly, neighborAS(n) is a function which returns the neighbor
   AS from which the route was received.
      
with:

   Similarly, neighborAS(n) is a function which returns the
   neighbor AS from which the route was received.  If the route is  
   learned via IBGP, it is the neighbor AS from which the other
   IBGP speaker learned the route, not the local AS.

   If a MULTI_EXIT_DISC attribute is removed before redistributing
   a route into IBGP, the MULTI_EXIT_DISC attribute may only be      
   considered in the comparison of EBGP learned routes, them
   removed, then the remaining EBGP learned route may be compared    
   to the remaining IBGP learned routes, without considering the    
   MULTI_EXIT_DISC attribute for those EBGP learned routes whose
   MULTI_EXIT_DISC will be dropped before advertising to IBGP.
   Including the MULTI_EXIT_DISC of an EBGP learned route in the
   comparison with an IBGP learned route, then dropping the
   MULTI_EXIT_DISC and advertising the route has been proven to
   cause route loops.

In the absence of objections I'll make the above changes.

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 MAA01275 for <[e-mail]>; Fri, 18 Oct 2002 12:54:21 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7A1A091306; Fri, 18 Oct 2002 12:53:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4738291307; Fri, 18 Oct 2002 12:53: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 8149191306 for <[e-mail]>; Fri, 18 Oct 2002 12:53:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 62F995DE44; Fri, 18 Oct 2002 12:53: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 C310B5DE01 for <[e-mail]>; Fri, 18 Oct 2002 12:53: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 g9IGrsm98888; Fri, 18 Oct 2002 09:53:54 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 8: final text 
In-Reply-To: Your message of "Fri, 18 Oct 2002 09:38:32 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 18 Oct 2002 09:53:54 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> The IOS defaults are 5 seconds for MinRouteAdvertisementInterval for IBGP
> and 30 seconds for
> EBGP(not sure what these are for Juniper, my guess is 30 for both).  This
> makes sense to me
> since for IBGP you are more concerned with convergence, whereas for EBGP you
> are more
> concerned with stability.  But I'm not sure if this could effect
> interoperability, but if it
> is and the involved implementations' timers were not configurable then there
> might be a
> problem.
> 
> I propose we change:
> "An implementation of BGP MUST allow the Hold Time timer to be configurable,
> and MAY allow
> the other timers to be configurable."
> to:
> "An implementation of BGP MUST allow the Hold Time timer to be configurable
> on a per peer
> basis, and SHOULD allow the other timers to be configurable on a per peer
> basis.

How about the following:

  An implementation of BGP MUST allow the Hold Time timer to be configurable
  on a per peer basis, and MAY allow the other timers to be configurable.

Yakov.


> 
> (RFC1771 has "An implementation of BGP MUST allow these timers to be
> configurable.")
> 
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Thursday, October 17, 2002 9:23 AM
> To: [e-mail]
> Subject: issue 8: final text
> 
> 
> Folks,
> 
> Here is the final text for the BGP Timers section:
> 
>    BGP employs five timers: ConnectRetry (see Section 8), Hold Time
>    (see Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval
>    (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
>    Section 9.2.1.1).
> 
>    The suggested default value for the ConnectRetry timer is 120
>    seconds.
> 
>    The suggested default value for the Hold Time is 90 seconds.
> 
>    The suggested default value for the KeepAlive timer is 1/3 of
>    the Hold Time.
> 
>    The suggested default value for the MinASOriginationInterval is
>    15 seconds.
> 
>    The suggested default value for the MinRouteAdvertisementInterval
>    is 30 seconds.
> 
>    An implementation of BGP MUST allow the Hold Time timer to be
>    configurable, and MAY allow the other timers to be configurable.
> 
>    To minimize the likelihood that the distribution of BGP messages
>    by a given BGP speaker will contain peaks, jitter should be
>    applied to the timers associated with MinASOriginationInterval,
>    Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
>    given BGP speaker may apply the same jitter to each of these
>    quantities regardless of the destinations to which the updates
>    are being sent; that is, jitter need not be configured on a "per
>    peer" basis.
> 
>    The suggested default amount of jitter shall be determined by
>    multiplying the base value of the appropriate timer by a random
>    factor which is uniformly distributed in the range from 0.75 to
>    1.0. A new random value should be picked each time the timer
>    is set. The range of the jitter random value MAY be configurable.
> 
> With this in mind, I would suggest we mark this issue as closed.
> 
> 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 MAA00646 for <[e-mail]>; Fri, 18 Oct 2002 12:43:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E6D7691305; Fri, 18 Oct 2002 12:43:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7D6C91306; Fri, 18 Oct 2002 12: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 34C1091305 for <[e-mail]>; Fri, 18 Oct 2002 12:43:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 14D4E5DE44; Fri, 18 Oct 2002 12: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 7420C5DE01 for <[e-mail]>; Fri, 18 Oct 2002 12: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 g9IGhHm98080; Fri, 18 Oct 2002 09:43:17 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 66 
In-Reply-To: Your message of "Fri, 18 Oct 2002 18:39:20 +0530." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Fri, 18 Oct 2002 09:43:17 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Siva,

> Hello,
> 
>     We have implemented this.

Ok. So far we have one implementation of complex AS path aggregation.
We need (at least) one more to keep it in the base spec.

Yakov.

> 
> Siva
> ([e-mail])
> 
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Thursday, October 17, 2002 7:15 PM
> > To: [e-mail]
> > Subject: issue 66
> > 
> > 
> >   66) Complex AS Path Aggregating
> >   
> > --------------------------------------------------------------
> > --------------
> >   Status: No Consensus
> >   Change: Potentially
> >   Summary: Do we remove a section of the spec that has to do 
> > with an aggregation
> >     scheme that is rarely used?
> >   
> >   Discussion:
> >   
> >   Jonathan opened this discussion with:
> >   
> >   The part in the draft about complex AS path aggregation 
> > could/should be
> >   deleted.  The current draft implies that when aggregating, 
> > for example
> >   (1st):
> >   
> >   1 2 4 3
> >   
> >   w/
> >   
> >   3 4 6 5
> >    
> >   and
> >   
> >   5 6 7 8
> >   
> >   then
> >   
> >   1 2 {3 4 5 6} 7 8
> >   
> >   ...would be OK
> >   
> >   AFAIK, all implementations aggregate by either: 
> > (2nd)putting ONLY the local
> >   AS in the path (and setting the atomic) OR (3rd)by creating 
> > 1 giant set and
> >   adding the local AS as a seq.
> >   
> >   So he proposed we remove this to reflect current code.
> >   
> >   Jeff replied that there is absolutely nothing wrong with 
> > doing complex
> >   aggregation, and there is no reason to remove this from the 
> > specification.
> > 
> > Jonathan is certainly correct that the spec has to reflect current
> > code.  Therefore, unless there are at least two (interoperable)
> > implementations that implement the algorithm described in "6.8
> > Complex AS_PATH aggregation", this section has to be removed (this
> > is irrespective of whether there is something wrong, or nothing
> > wrong with complex aggregation). With this in mind, if you implement
> > this algorithm please speak up within a week.  If within a week we
> > wouldn't know that there are at least two implementations the
> > section will be removed. And likewise, if we hear that there are
> > at least two implementations, the section will stay. 
> > 
> > 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 KAA22270 for <[e-mail]>; Fri, 18 Oct 2002 10:16:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A9CA4912FA; Fri, 18 Oct 2002 10:15:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74CBC912FB; Fri, 18 Oct 2002 10:15: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 28204912FA for <[e-mail]>; Fri, 18 Oct 2002 10:15:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DFF235DE3F; Fri, 18 Oct 2002 10:15: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 06A095DDD4 for <[e-mail]>; Fri, 18 Oct 2002 10:15:31 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9IEEwV26059; Fri, 18 Oct 2002 10:14: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 g9IEEsC26052; Fri, 18 Oct 2002 10:14:54 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9IEEs024942; Fri, 18 Oct 2002 10:14:54 -0400 (EDT)
Date: Fri, 18 Oct 2002 10:14:54 -0400
From: Jeffrey Haas <[e-mail]>
To: Dimitry Haskin <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 65
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, Oct 18, 2002 at 10:10:18AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Oct 18, 2002 at 10:10:18AM -0400, Dimitry Haskin wrote:
> I propose to remove the above sentence from the text. Whether to aggregate
> routes that were received with different MEDs or not is a local policy
> decision that has no interoperability implication or breaks routing in any
> way.

It has been claimed by those who have more experience than me that
you can end up with loops in some cases if you do this.  No, I
never got an example.

> P.S. I am aware of implementations (I believe GateD one of them) that ignore
> the above rule.

That is also by knob.  The "bgp" keyword on the aggregate clause
forces aggregation to not aggregate routes with differing nexthops and
med'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 KAA22156 for <[e-mail]>; Fri, 18 Oct 2002 10:14:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 87E39912F8; Fri, 18 Oct 2002 10:14:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 551F8912FA; Fri, 18 Oct 2002 10:14: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 D8243912F8 for <[e-mail]>; Fri, 18 Oct 2002 10:14:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C727A5DE48; Fri, 18 Oct 2002 10:14:28 -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 204715DE47 for <[e-mail]>; Fri, 18 Oct 2002 10:14:28 -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 g9IE6iE30603; Fri, 18 Oct 2002 16:06:44 +0200
Received: from alcatel.be ([138.203.142.14]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002101816133931:7766 ; Fri, 18 Oct 2002 16:13:39 +0200 
Message-ID: <[e-mail]>
Date: Fri, 18 Oct 2002 16:13:15 +0200
From: [e-mail]
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Natale, Jonathan" <[e-mail]>
Cc: BGP mailing list <[e-mail]>
Subject: Re: issue 61
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 10/18/2002 16:13:39, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 10/18/2002 16:13:40, Serialize complete at 10/18/2002 16:13:40
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Thanks Jonathan

this fully anwers the question.

Hans.

"Natale, Jonathan" wrote:

> No, it would not be a loop (assuming the second router had an IGP route to
> the same
> destination) because the admin distance of IBGP is lower than the admin
> distance of IGPs.
> (I tried to get this added to the draft, but it was voted down).  You'd have
> to check with a
> real Juniper guy, but I am pretty sure you can do this on Juniper too.  Of
> course you
> could always create a routing loop by bad network design, particularly with
> static
> routes.
>
> The other issue in the scenario is that the received BGP route would not be
> the active route,
> so as the draft reads now it should not be re-advertised.  (I also tried to
> get this added to
> the draft, and I think it was finally accepted).
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Friday, October 18, 2002 5:10 AM
> To: BGP mailing list
> Subject: Re: issue 61
>
> I have some trouble in understanding part of the proposed text.  " if 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)."
>
> The way i understand this is:
> We have a route in the routing database, whose next-hop happens  to be equal
> to the address of one of the iBGP peers. (who in this case must be an
> internal BGP peer which is exactly one hop away).
>
> In this case we can avertise this route to this iBGP peer as long as we put
> the next-hop field to the Ip-address which is assigned to our router on the
> interface connecting us to the internal peer.
>
> But, if my way of understanding the text is correct, then i get the
> impression we have created a routing loop, as we have announced a route to a
> peer that actually is routed through that peer. Therefore I guess my
> understanding of the text is wrong, and i hope that somebody can put me
> straight here.
>
> thanks,
> hans.
>
> Yakov Rekhter wrote:
>
> >   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.
> >
> >   Issue 14 closed in favor of this issue.
> >
> >   In response to Yakov's call for input, Michael responded that:
> >
> >   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 (text is above.)
> >
> > Replace:
> >
> >   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.
> >
> > with:
> >
> >   1) When sending a message to an internal peer, if the route is
> >   not locally originated the BGP speaker should not modify the
> >   NEXT_HOP attribute, unless it has been explicitly configured to
> >   announce its own IP address as the NEXT_HOP. When announcing a
> >   locally originated route to an internal peer, the BGP speaker
> >   should use 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).
> >
> > In the absence of objections I'll make the above change.
> >
> > 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 KAA21702 for <[e-mail]>; Fri, 18 Oct 2002 10:10:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 386C9912F9; Fri, 18 Oct 2002 10:10:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB5B6912F8; Fri, 18 Oct 2002 10:10: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 A33FF912F9 for <[e-mail]>; Fri, 18 Oct 2002 10:10:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8D1265DE3F; Fri, 18 Oct 2002 10:10:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: from bridge.axiowave.com (unknown [64.115.125.242]) by segue.merit.edu (Postfix) with ESMTP id E71F15DDD4 for <[e-mail]>; Fri, 18 Oct 2002 10:10:25 -0400 (EDT)
Message-ID: <[e-mail]>
From: Dimitry Haskin <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 65
Date: Fri, 18 Oct 2002 10:10:18 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> 
>   65) Rules for Aggregating with MED and NEXT_HOP
>   
> --------------------------------------------------------------
> --------------
> 
> I would suggest to replace:
> 
>    [snip]
> 
> with:
> 
>    Routes that have different MULTI_EXIT_DISC attribute SHALL NOT
>    be aggregated. 
> 
I propose to remove the above sentence from the text. Whether to aggregate
routes that were received with different MEDs or not is a local policy
decision that has no interoperability implication or breaks routing in any
way. It also is a local policy choice whether to advertise MED and what MED
value to use with a newly generated aggregate route.

Dimitry

P.S. I am aware of implementations (I believe GateD one of them) that ignore
the above rule. Which is fine.. except that those implementations don't pass
some well known conformance tests.

>    Path attributes that have different type codes can not be 
> aggregated
>    together. Path attributes of the same type code may be aggregated,
>    according to the following rules:
> 
>      NEXT_HOP: When aggregating routes that have different NEXT_HOP
>      attribute, the NEXT_HOP attribute of the aggregated route SHALL
>      identify an interface on the router that performs the 
> aggregation.
> 
> In the absence of objections I am going to make the above change.
> 
> 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 KAA21696 for <[e-mail]>; Fri, 18 Oct 2002 10:10:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0F1E5912F7; Fri, 18 Oct 2002 10:08:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0843912F9; Fri, 18 Oct 2002 10:08: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 6A9E0912F7 for <[e-mail]>; Fri, 18 Oct 2002 10:08:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C900B5DE4C; Fri, 18 Oct 2002 10:08: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 581575DE28 for <[e-mail]>; Fri, 18 Oct 2002 10:08:07 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT81JK>; Fri, 18 Oct 2002 10:08:05 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, BGP mailing list <[e-mail]>
Subject: RE: issue 61
Date: Fri, 18 Oct 2002 10:08:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

No, it would not be a loop (assuming the second router had an IGP route to
the same
destination) because the admin distance of IBGP is lower than the admin
distance of IGPs.
(I tried to get this added to the draft, but it was voted down).  You'd have
to check with a
real Juniper guy, but I am pretty sure you can do this on Juniper too.  Of
course you
could always create a routing loop by bad network design, particularly with
static
routes.

The other issue in the scenario is that the received BGP route would not be
the active route,
so as the draft reads now it should not be re-advertised.  (I also tried to
get this added to
the draft, and I think it was finally accepted).


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] 
Sent: Friday, October 18, 2002 5:10 AM
To: BGP mailing list
Subject: Re: issue 61



I have some trouble in understanding part of the proposed text.  " if 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)."

The way i understand this is:
We have a route in the routing database, whose next-hop happens  to be equal
to the address of one of the iBGP peers. (who in this case must be an
internal BGP peer which is exactly one hop away).

In this case we can avertise this route to this iBGP peer as long as we put
the next-hop field to the Ip-address which is assigned to our router on the
interface connecting us to the internal peer.

But, if my way of understanding the text is correct, then i get the
impression we have created a routing loop, as we have announced a route to a
peer that actually is routed through that peer. Therefore I guess my
understanding of the text is wrong, and i hope that somebody can put me
straight here.

thanks,
hans.


Yakov Rekhter wrote:

>   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.
>
>   Issue 14 closed in favor of this issue.
>
>   In response to Yakov's call for input, Michael responded that:
>
>   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 (text is above.)
>
> Replace:
>
>   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.
>
> with:
>
>   1) When sending a message to an internal peer, if the route is
>   not locally originated the BGP speaker should not modify the
>   NEXT_HOP attribute, unless it has been explicitly configured to
>   announce its own IP address as the NEXT_HOP. When announcing a
>   locally originated route to an internal peer, the BGP speaker
>   should use 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).
>
> In the absence of objections I'll make the above change.
>
> 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 JAA20453 for <[e-mail]>; Fri, 18 Oct 2002 09:48:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 39221912F4; Fri, 18 Oct 2002 09:48:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04341912F5; Fri, 18 Oct 2002 09:48: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 404FB912F4 for <[e-mail]>; Fri, 18 Oct 2002 09:48:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2041F5DE34; Fri, 18 Oct 2002 09:48: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 CED2D5DDD4 for <[e-mail]>; Fri, 18 Oct 2002 09:48:38 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT811B>; Fri, 18 Oct 2002 09:48:38 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Separate document for multipath - or part of BGP spec 
Date: Fri, 18 Oct 2002 09:48: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 think you had proposed adding some type of blurb that basically said that
this is out of
scope. I think it is out of scope.  I also think it is sufficiently complex
to warrant a
separate draft (doesn't one already exist?).

Also, in Bgp multipath it is important that there is still only one route
selected for
re-advertisement.  The text below does not indicate this.

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Thursday, October 17, 2002 7:58 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: Separate document for multipath - or part of BGP spec 


Curtis,

> After some discussion initiated by Alex we ended up with the following 
> text on BGP multipath.  If we can get consensus on text to be added to 
> the BGP base spec then we'll add text.  If not, we'll omit any mention 
> of BGP multipath.  We seem to have rough consensus among a small 
> number of people.

In addition to getting consensus we also need (at least) two implementations
of the text. Otherwise, we wouldn't be able to include it in the BGP base
spec. With this in mind I would appreciate if folks who implement something
along the lines of the text below drop me an e-mail.

Yakov.

> 
> Curtis
> 
> 
>   [new subesection]
> 
>    BGP specifies how to select the single best route.  OSPF
>    specifically defines procedures for handling equal cost multipath
>    (ECMP) [cite OSPF].  The same technique has been applied to ISIS.
>    A similar technique has been used with BGP.  Variations exist but
>    the decision to support BGP multipath, the specific variation of
>    BGP multipath, or not to support it, does not affect
>    interoperability.
> 
>    A naive implementations of ECMP can cause severe performance
>    degradation for TCP flows.  To avoid this, implementations of BGP
>    multipath SHOULD maintain packet ordering within microflows as
>    described in [cite rfc2991, rfc2992].
> 
>    BGP multipath, if implemented, SHOULD be disabled by default.
> 
>    In addition to IGP multipath (OSPF ECMP and ISIS equivalent), there
>    are two variations of BGP multipath described here.  A BGP
>    implementation may offer both, either one, or neither variation of
>    BGP multipath.  Other variations of BGP multipath may exist, but no
>    guarantees can be made in this protocol specification of their
>    properties or impact on interoperability.
> 
>    Where IGP multipath is used, there is an interaction with BGP
>    learned routes.  The lookup of a BGP NEXT_HOP in the IGP can
>    result in the selection of an IGP multipath entry.  This is not a
>    variation of BGP multipath.  When this occurs, one BGP route is
>    slected as the best but there is more than one way to reach the BGP
>    NEXT_HOP via the IGP.
> 
>    In one variation of BGP multipath, a set of more than one IBGP
>    routers peering with the same external AS have equal routes to a
>    destination and are an equal IGP cost away from a second set of one
>    or more routers.  BGP multipath is applicable to the latter set of
>    routers.  Without BGP multipath, BGP would pick the BGP NEXT_HOP of
>    the advertisement from only one of those IBGP peers (using BGP
>    Identifier) and use only that BGP route.  With BGP multipath, BGP
>    uses the BGP NEXT_HOP of more than one of these equal cost
>    advertisements, yielding more than one BGP NEXT_HOP.  Each BGP
>    NEXT_HOP has a different IGP next hop (one or more IGP next hop if
>    IGP multipath is in use).
> 
>    The second case is where all of the candidates routes for BGP
>    multipath are external and learned by a single BGP peer.  Without
>    BGP multipath this peer would select only one of the BGP routes and
>    obtain only one BGP NEXT_HOP.  With BGP multipath, more than one
>    equal cost route is selected yielding more than one BGP NEXT_HOP.
>    Seldom does IGP multipath come into play when looking up an EBGP
>    NEXT_HOP but could in principle be applicable.
> 
>    If in EBGP multipath traffic is split among routers in difference
>    AS, an aggregate SHOULD be formed so as to propogate a route with
>    an accurate AS_PATH.  If the resulting aggregate is not more
>    specific than the components, the AS_SET SHOULD NOT be dropped.
> 
>    The decsion point for multipath is after step "d" in Section
>    9.1.2.2 (prefer externally learned routes).  IBGP learned and EBGP
>    learned routes MUST NOT be combined in multipath.  If the multipath
>    decision is prior to "d", then two routers each with an external
>    peering would form a routing loop.
> 
>    The decision point for multipath is generally after step "e" in
>    Section 9.1.2.2.  Some relaxation of the "equal cost" rule (also
>    applicable to IGP multipath) is possible.  In addition to the equal
>    cost BGP NEXT_HOPS available at BGP route selection, if the IGP
>    next hop for other BGP NEXT_HOPs are of lower cost, then those may
>    be used as well.  This relaxation of the step "e" is possible but
>    is not widely implemented (and may not be implemented at all).


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA19879 for <[e-mail]>; Fri, 18 Oct 2002 09:39:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2CCD7912F3; Fri, 18 Oct 2002 09:38:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA2E6912F4; Fri, 18 Oct 2002 09: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 4029A912F3 for <[e-mail]>; Fri, 18 Oct 2002 09:38:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 174465DE28; Fri, 18 Oct 2002 09:38: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 C92F35DDDC for <[e-mail]>; Fri, 18 Oct 2002 09:38:33 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT81CJ>; Fri, 18 Oct 2002 09:38:33 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 8: final text
Date: Fri, 18 Oct 2002 09:38:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Folks,

The IOS defaults are 5 seconds for MinRouteAdvertisementInterval for IBGP
and 30 seconds for
EBGP(not sure what these are for Juniper, my guess is 30 for both).  This
makes sense to me
since for IBGP you are more concerned with convergence, whereas for EBGP you
are more
concerned with stability.  But I'm not sure if this could effect
interoperability, but if it
is and the involved implementations' timers were not configurable then there
might be a
problem.

I propose we change:
"An implementation of BGP MUST allow the Hold Time timer to be configurable,
and MAY allow
the other timers to be configurable."
to:
"An implementation of BGP MUST allow the Hold Time timer to be configurable
on a per peer
basis, and SHOULD allow the other timers to be configurable on a per peer
basis.

(RFC1771 has "An implementation of BGP MUST allow these timers to be
configurable.")


-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Thursday, October 17, 2002 9:23 AM
To: [e-mail]
Subject: issue 8: final text


Folks,

Here is the final text for the BGP Timers section:

   BGP employs five timers: ConnectRetry (see Section 8), Hold Time
   (see Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval
   (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
   Section 9.2.1.1).

   The suggested default value for the ConnectRetry timer is 120
   seconds.

   The suggested default value for the Hold Time is 90 seconds.

   The suggested default value for the KeepAlive timer is 1/3 of
   the Hold Time.

   The suggested default value for the MinASOriginationInterval is
   15 seconds.

   The suggested default value for the MinRouteAdvertisementInterval
   is 30 seconds.

   An implementation of BGP MUST allow the Hold Time timer to be
   configurable, and MAY allow the other timers to be configurable.

   To minimize the likelihood that the distribution of BGP messages
   by a given BGP speaker will contain peaks, jitter should be
   applied to the timers associated with MinASOriginationInterval,
   Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
   given BGP speaker may apply the same jitter to each of these
   quantities regardless of the destinations to which the updates
   are being sent; that is, jitter need not be configured on a "per
   peer" basis.

   The suggested default amount of jitter shall be determined by
   multiplying the base value of the appropriate timer by a random
   factor which is uniformly distributed in the range from 0.75 to
   1.0. A new random value should be picked each time the timer
   is set. The range of the jitter random value MAY be configurable.

With this in mind, I would suggest we mark this issue as closed.

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 JAA19563 for <[e-mail]>; Fri, 18 Oct 2002 09:33:16 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B87C8912F2; Fri, 18 Oct 2002 09:32:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BED4912F3; Fri, 18 Oct 2002 09:32: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 B0898912F2 for <[e-mail]>; Fri, 18 Oct 2002 09:32:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 878B55DE34; Fri, 18 Oct 2002 09:32: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 02CA35DE28 for <[e-mail]>; Fri, 18 Oct 2002 09:32:06 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9IDVx725133; Fri, 18 Oct 2002 09:31: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 g9IDVuC25126; Fri, 18 Oct 2002 09:31:56 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9IDVum24757; Fri, 18 Oct 2002 09:31:56 -0400 (EDT)
Date: Fri, 18 Oct 2002 09:31:56 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 8: final text
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, Oct 18, 2002 at 09:09:45AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Oct 18, 2002 at 09:09:45AM -0400, Natale, Jonathan wrote:
> Are you referring to the MinASOriginationInterval?

I'm speaking of the two BGP timers, MinASOriginationInternal, 
MinRouteAdverInterval.

One deals with the propagation of the routes from outside of an AS,
the other deals with origination of routes in the AS.

> I also don't think
> anybody uses it.  As far as the outdelay--that is not really mentioned in
> the draft, right?

outdelay is GateD's implementation of a delay timer for
reachability announcements.  As previously noted, one could consider
it a replacement for *both* timers as one timer.

> But I don't think either effects interoperability
> though, so I'd say let's not change the spec based on these.

These timers greatly affect convergence.  See Craig and Abha's paper
on the topic.
http://www.research.microsoft.com/scripts/pubs/view.asp?TR_ID=MSR-TR-2000-08

-- 
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 JAA19114 for <[e-mail]>; Fri, 18 Oct 2002 09:25:54 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F309D912F1; Fri, 18 Oct 2002 09:25:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE5CD912F2; Fri, 18 Oct 2002 09: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 77C16912F1 for <[e-mail]>; Fri, 18 Oct 2002 09:25:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5FE2E5DDF5; Fri, 18 Oct 2002 09:25: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 9B9435DDDC for <[e-mail]>; Fri, 18 Oct 2002 09:25:24 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9IDPKY24896; Fri, 18 Oct 2002 09:25:20 -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 g9IDPHC24889; Fri, 18 Oct 2002 09:25:17 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9IDPEB24726; Fri, 18 Oct 2002 09:25:14 -0400 (EDT)
Date: Fri, 18 Oct 2002 09:25:14 -0400
From: Jeffrey Haas <[e-mail]>
To: christophe preguica <[e-mail]>
Cc: [e-mail]
Subject: Re: MP-BGP for IPv4 and IPv6
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, Oct 18, 2002 at 10:23:34AM +0200
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Oct 18, 2002 at 10:23:34AM +0200, christophe preguica wrote:
> I saw nothing about this issue.
> Is it a good solution to configure an IPv6 address of peer 2 when
> configuring a TCPv4 connection on peer 1 towards peer 2 ?
> Is there another way ?

Currently, configuration is the only way to solve this particular
problem.  (At least that I know of.)

Cisco bypasses this particular problem and causes you to configure
your v6 routing across a v6 peering session.

> Christophe.

-- 
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 JAA18186 for <[e-mail]>; Fri, 18 Oct 2002 09:10:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 44EAE912F0; Fri, 18 Oct 2002 09:09:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1441A912F1; Fri, 18 Oct 2002 09: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 52348912F0 for <[e-mail]>; Fri, 18 Oct 2002 09:09:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3EC0E5DDDC; Fri, 18 Oct 2002 09: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 BFD0E5DDD4 for <[e-mail]>; Fri, 18 Oct 2002 09:09:46 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT8D9N>; Fri, 18 Oct 2002 09:09:46 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 8: final text
Date: Fri, 18 Oct 2002 09:09:45 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Are you referring to the MinASOriginationInterval?  I also don't think
anybody uses it.  As far as the outdelay--that is not really mentioned in
the draft, right?  So maybe the former should be deprecated, and maybe the
latter should be added?  But I don't think either effects interoperability
though, so I'd say let's not change the spec based on these.

-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Thursday, October 17, 2002 10:18 AM
To: Yakov Rekhter
Cc: [e-mail]
Subject: Re: issue 8: final text


On Thu, Oct 17, 2002 at 06:22:31AM -0700, Yakov Rekhter wrote:
> With this in mind, I would suggest we mark this issue as closed.

Generally agreed.

But does anyone actually implement both timers?
GateD and Juniper have outdelay.
Cisco has neighbor advertisement-interval.

In all cases, this is a general delay, not one that depends on whether the
route is being propagated or originated.

> 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 JAA18119 for <[e-mail]>; Fri, 18 Oct 2002 09:09:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A6ADB912EF; Fri, 18 Oct 2002 09:08:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71F58912F0; Fri, 18 Oct 2002 09:08: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 B3F87912EF for <[e-mail]>; Fri, 18 Oct 2002 09:08:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 929265DDE6; Fri, 18 Oct 2002 09:08: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 CF0325DDDC for <[e-mail]>; Fri, 18 Oct 2002 09:08:26 -0400 (EDT)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <48ZB94NR>; Fri, 18 Oct 2002 18:36:54 +0530
Message-ID: <[e-mail]>
From: "Sivananda Ramnath - CTD, Chennai." <[e-mail]>
To: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: RE: issue 66
Date: Fri, 18 Oct 2002 18:39:20 +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,

    We have implemented this.

Siva
([e-mail])


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Thursday, October 17, 2002 7:15 PM
> To: [e-mail]
> Subject: issue 66
> 
> 
>   66) Complex AS Path Aggregating
>   
> --------------------------------------------------------------
> --------------
>   Status: No Consensus
>   Change: Potentially
>   Summary: Do we remove a section of the spec that has to do 
> with an aggregation
>     scheme that is rarely used?
>   
>   Discussion:
>   
>   Jonathan opened this discussion with:
>   
>   The part in the draft about complex AS path aggregation 
> could/should be
>   deleted.  The current draft implies that when aggregating, 
> for example
>   (1st):
>   
>   1 2 4 3
>   
>   w/
>   
>   3 4 6 5
>    
>   and
>   
>   5 6 7 8
>   
>   then
>   
>   1 2 {3 4 5 6} 7 8
>   
>   ...would be OK
>   
>   AFAIK, all implementations aggregate by either: 
> (2nd)putting ONLY the local
>   AS in the path (and setting the atomic) OR (3rd)by creating 
> 1 giant set and
>   adding the local AS as a seq.
>   
>   So he proposed we remove this to reflect current code.
>   
>   Jeff replied that there is absolutely nothing wrong with 
> doing complex
>   aggregation, and there is no reason to remove this from the 
> specification.
> 
> Jonathan is certainly correct that the spec has to reflect current
> code.  Therefore, unless there are at least two (interoperable)
> implementations that implement the algorithm described in "6.8
> Complex AS_PATH aggregation", this section has to be removed (this
> is irrespective of whether there is something wrong, or nothing
> wrong with complex aggregation). With this in mind, if you implement
> this algorithm please speak up within a week.  If within a week we
> wouldn't know that there are at least two implementations the
> section will be removed. And likewise, if we hear that there are
> at least two implementations, the section will stay. 
> 
> 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 FAA02475 for <[e-mail]>; Fri, 18 Oct 2002 05:11:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 86281912E7; Fri, 18 Oct 2002 05:10:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F5C9912E9; Fri, 18 Oct 2002 05:10: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 DC811912E7 for <[e-mail]>; Fri, 18 Oct 2002 05:10:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C4FE15DE03; Fri, 18 Oct 2002 05:10:56 -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 3FF065DDB2 for <[e-mail]>; Fri, 18 Oct 2002 05:10:56 -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 g9I93pQ21619 for <[e-mail]>; Fri, 18 Oct 2002 11:03:51 +0200
Received: from alcatel.be ([138.203.142.14]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002101811104552:4480 ; Fri, 18 Oct 2002 11:10:45 +0200 
Message-ID: <[e-mail]>
Date: Fri, 18 Oct 2002 11:10:22 +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: issue 61
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 10/18/2002 11:10:45, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 10/18/2002 11:10:46, Serialize complete at 10/18/2002 11:10:46
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

I have some trouble in understanding part of the proposed text.
 " if 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)."

The way i understand this is:
We have a route in the routing database, whose next-hop happens  to be equal to
the address of one of the iBGP peers. (who in this case must be an internal BGP
peer which is exactly one hop away).

In this case we can avertise this route to this iBGP peer as long as we put the
next-hop field to the Ip-address which is assigned to our router on the interface
connecting us to the internal peer.

But, if my way of understanding the text is correct, then i get the impression we
have created a routing loop, as we have announced a route to a peer that actually
is routed through that peer. Therefore I guess my understanding of the text is
wrong, and i hope that somebody can put me straight here.

thanks,
hans.


Yakov Rekhter wrote:

>   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.
>
>   Issue 14 closed in favor of this issue.
>
>   In response to Yakov's call for input, Michael responded that:
>
>   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 (text is above.)
>
> Replace:
>
>   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.
>
> with:
>
>   1) When sending a message to an internal peer, if the route is
>   not locally originated the BGP speaker should not modify the
>   NEXT_HOP attribute, unless it has been explicitly configured to
>   announce its own IP address as the NEXT_HOP. When announcing a
>   locally originated route to an internal peer, the BGP speaker
>   should use 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).
>
> In the absence of objections I'll make the above change.
>
> 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 EAA00305 for <[e-mail]>; Fri, 18 Oct 2002 04:34:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F2DFD912E6; Fri, 18 Oct 2002 04:32:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7FC52912E8; Fri, 18 Oct 2002 04:32: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 970C4912E6 for <[e-mail]>; Fri, 18 Oct 2002 04:31:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 54BBB5DDC8; Fri, 18 Oct 2002 04:30:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from smail2.alcatel.fr (colt-na6.alcatel.fr [62.23.212.6]) by segue.merit.edu (Postfix) with ESMTP id AC5085DDB2 for <[e-mail]>; Fri, 18 Oct 2002 04:30:46 -0400 (EDT)
Received: from nmu.alcatel.fr (tcmh80.nmu.alcatel.fr [139.54.143.3]) by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id g9I8UjWJ017192 for <[e-mail]>; Fri, 18 Oct 2002 10:30:45 +0200
Received: from nmu.alcatel.fr (houat [192.200.245.153]) by nmu.alcatel.fr (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA25885 for <[e-mail]>; Fri, 18 Oct 2002 10:29:24 +0200 (METDST)
Message-ID: <[e-mail]>
Date: Fri, 18 Oct 2002 10:25:30 +0200
From: christophe preguica <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: MP-BGP for IPv4 and IPv6
Content-Type: multipart/alternative; boundary="------------2B0943E13A9C759F4AF3B39C"
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: [e-mail]
Precedence: bulk

--------------2B0943E13A9C759F4AF3B39C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

it is specified on MP-BGP that any kind of route (both IPv4 and IPv6)
can be advertised through a TCPv4 connection and ditto through a TCPv6
connection.
But in case we have the following topology:

________________                                      ________________
|peer 1                     |
|peer2                     |
|144.20.20.1
|-------------------------|144.20.20.2            |
|3ffe:400:100::1        |   TCPv4
|3ffe:400:100::2        |
|dual stack               |                                       |dual
stack               |
|_______________|
|_______________|

An open message will be sent with both IPv4 and IPv6 capabilities.
But when peer 1 receives an IPv6 route from peer 2 and has to advertise
this route to other peers,
it does not have the IPv6 address of peer 2 since the connection was
made in IPv4: so no way to fill up the NH field
of the MP_reach_NLRI in the update message.

The BGP tunnel draft specifies the use of mapped addresses in this case
(::ffff:144.20.20.2) which is a good solution for some scenarios but
IPv6 packets will
always be encapsulated in IPv4 to reach peer 2 even if there is an IPv6
path. Moreover, the BGP tunnel solution do not handle
the case of sending IPv4 routes over a TCPv6 connection.

I saw nothing about this issue.
Is it a good solution to configure an IPv6 address of peer 2 when
configuring a TCPv4 connection on peer 1 towards peer 2 ?
Is there another way ?

The best solution would be to only allow advertising IPv4 routes on
TCPv4 connections but that is not what is specified...

Kind Regards,

Christophe.



--------------2B0943E13A9C759F4AF3B39C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>it is specified on MP-BGP that any kind of route (both IPv4 and IPv6)
<br>can be advertised through a TCPv4 connection and ditto through a TCPv6
<br>connection.
<br>But in case we have the following topology:
<p>________________&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
________________
<br>|peer 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|peer2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>|144.20.20.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|-------------------------|144.20.20.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>|3ffe:400:100::1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;
TCPv4&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|3ffe:400:100::2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |
<br>|dual stack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|dual stack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|
<br>|_______________|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&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></tt>|_______________|
<p>An open message will be sent with both IPv4 and IPv6 capabilities.
<br>But when peer 1 receives an IPv6 route from peer 2 and has to advertise
<br>this route to other peers,
<br>it does not have the IPv6 address of peer 2 since the connection was
<br>made in IPv4: so no way to fill up the NH field
<br>of the MP_reach_NLRI in the update message.
<p>The BGP tunnel draft specifies the use of mapped addresses in this case
<br>(::ffff:144.20.20.2) which is a good solution for some scenarios but
<br>IPv6 packets will
<br>always be encapsulated in IPv4 to reach peer 2 even if there is an
IPv6
<br>path. Moreover, the BGP tunnel solution do not handle
<br>the case of sending IPv4 routes over a TCPv6 connection.
<p>I saw nothing about this issue.
<br>Is it a good solution to configure an IPv6 address of peer 2 when
<br>configuring a TCPv4 connection on peer 1 towards peer 2 ?
<br>Is there another way ?
<p>The best solution would be to only allow advertising IPv4 routes on
<br>TCPv4 connections but that is not what is specified...
<p>Kind Regards,
<p>Christophe.
<br>&nbsp;
<br>&nbsp;</html>

--------------2B0943E13A9C759F4AF3B39C--



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id EAA29975 for <[e-mail]>; Fri, 18 Oct 2002 04:29:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 57BD9912E4; Fri, 18 Oct 2002 04:28:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1AED9912E5; Fri, 18 Oct 2002 04:28: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 67109912E4 for <[e-mail]>; Fri, 18 Oct 2002 04:28:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4E3395DDC0; Fri, 18 Oct 2002 04:28:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: from smail2.alcatel.fr (colt-na6.alcatel.fr [62.23.212.6]) by segue.merit.edu (Postfix) with ESMTP id 951AA5DDB2 for <[e-mail]>; Fri, 18 Oct 2002 04:28:50 -0400 (EDT)
Received: from nmu.alcatel.fr (tcmh80.nmu.alcatel.fr [139.54.143.3]) by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id g9I8SnWJ015721 for <[e-mail]>; Fri, 18 Oct 2002 10:28:49 +0200
Received: from nmu.alcatel.fr (houat [192.200.245.153]) by nmu.alcatel.fr (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA25794 for <[e-mail]>; Fri, 18 Oct 2002 10:27:28 +0200 (METDST)
Message-ID: <[e-mail]>
Date: Fri, 18 Oct 2002 10:23:34 +0200
From: christophe preguica <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: MP-BGP for IPv4 and IPv6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: [e-mail]
Precedence: bulk

Hi,

it is specified on MP-BGP that any kind of route (both IPv4 and IPv6)
can be advertised through a TCPv4 connection and ditto through a TCPv6
connection.
But in case we have the following topology:

________________                                      ________________
|peer 1                     |
|peer2                     |
|144.20.20.1
|-------------------------|144.20.20.2            |
|3ffe:400:100::1        |   TCPv4
|3ffe:400:100::2        |
|dual stack               |                                       |dual
stack               |
|_______________|
|_______________|

An open message will be sent with both IPv4 and IPv6 capabilities.
But when peer 1 receives an IPv6 route from peer 2 and has to advertise
this route to other peers,
it does not have the IPv6 address of peer 2 since the connection was
made in IPv4: so no way to fill up the NH field
of the MP_reach_NLRI in the update message.

The BGP tunnel draft specifies the use of mapped addresses in this case
(::ffff:144.20.20.2) which is a good solution for some scenarios but
IPv6 packets will
always be encapsulated in IPv4 to reach peer 2 even if there is an IPv6
path. Moreover, the BGP tunnel solution do not handle
the case of sending IPv4 routes over a TCPv6 connection.

I saw nothing about this issue.
Is it a good solution to configure an IPv6 address of peer 2 when
configuring a TCPv4 connection on peer 1 towards peer 2 ?
Is there another way ?

The best solution would be to only allow advertising IPv4 routes on
TCPv4 connections but that is not what is specified...

Kind Regards,

Christophe.



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA00008 for <[e-mail]>; Thu, 17 Oct 2002 19:59:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0A6BB912DE; Thu, 17 Oct 2002 19:58:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CBD38912DF; Thu, 17 Oct 2002 19:58: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 8348B912DE for <[e-mail]>; Thu, 17 Oct 2002 19:58:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 580895DED9; Thu, 17 Oct 2002 19:58: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 EF88B5DDE1 for <[e-mail]>; Thu, 17 Oct 2002 19:58: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 g9HNwFm52783; Thu, 17 Oct 2002 16:58:15 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Separate document for multipath - or part of BGP spec 
In-Reply-To: Your message of "Thu, 17 Oct 2002 11:59:48 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 17 Oct 2002 16:58:15 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Curtis,

> After some discussion initiated by Alex we ended up with the following
> text on BGP multipath.  If we can get consensus on text to be added to
> the BGP base spec then we'll add text.  If not, we'll omit any mention
> of BGP multipath.  We seem to have rough consensus among a small
> number of people.

In addition to getting consensus we also need (at least) two
implementations of the text. Otherwise, we wouldn't be able to
include it in the BGP base spec. With this in mind I would appreciate
if folks who implement something along the lines of the text below
drop me an e-mail.

Yakov.

> 
> Curtis
> 
> 
>   [new subesection]
> 
>    BGP specifies how to select the single best route.  OSPF
>    specifically defines procedures for handling equal cost multipath
>    (ECMP) [cite OSPF].  The same technique has been applied to ISIS.
>    A similar technique has been used with BGP.  Variations exist but
>    the decision to support BGP multipath, the specific variation of
>    BGP multipath, or not to support it, does not affect
>    interoperability.
> 
>    A naive implementations of ECMP can cause severe performance
>    degradation for TCP flows.  To avoid this, implementations of BGP
>    multipath SHOULD maintain packet ordering within microflows as
>    described in [cite rfc2991, rfc2992].
> 
>    BGP multipath, if implemented, SHOULD be disabled by default.
> 
>    In addition to IGP multipath (OSPF ECMP and ISIS equivalent), there
>    are two variations of BGP multipath described here.  A BGP
>    implementation may offer both, either one, or neither variation of
>    BGP multipath.  Other variations of BGP multipath may exist, but no
>    guarantees can be made in this protocol specification of their
>    properties or impact on interoperability.
> 
>    Where IGP multipath is used, there is an interaction with BGP
>    learned routes.  The lookup of a BGP NEXT_HOP in the IGP can
>    result in the selection of an IGP multipath entry.  This is not a
>    variation of BGP multipath.  When this occurs, one BGP route is
>    slected as the best but there is more than one way to reach the BGP
>    NEXT_HOP via the IGP.
> 
>    In one variation of BGP multipath, a set of more than one IBGP
>    routers peering with the same external AS have equal routes to a
>    destination and are an equal IGP cost away from a second set of one
>    or more routers.  BGP multipath is applicable to the latter set of
>    routers.  Without BGP multipath, BGP would pick the BGP NEXT_HOP of
>    the advertisement from only one of those IBGP peers (using BGP
>    Identifier) and use only that BGP route.  With BGP multipath, BGP
>    uses the BGP NEXT_HOP of more than one of these equal cost
>    advertisements, yielding more than one BGP NEXT_HOP.  Each BGP
>    NEXT_HOP has a different IGP next hop (one or more IGP next hop if
>    IGP multipath is in use).
> 
>    The second case is where all of the candidates routes for BGP
>    multipath are external and learned by a single BGP peer.  Without
>    BGP multipath this peer would select only one of the BGP routes and
>    obtain only one BGP NEXT_HOP.  With BGP multipath, more than one
>    equal cost route is selected yielding more than one BGP NEXT_HOP.
>    Seldom does IGP multipath come into play when looking up an EBGP
>    NEXT_HOP but could in principle be applicable.
> 
>    If in EBGP multipath traffic is split among routers in difference
>    AS, an aggregate SHOULD be formed so as to propogate a route with
>    an accurate AS_PATH.  If the resulting aggregate is not more
>    specific than the components, the AS_SET SHOULD NOT be dropped.
> 
>    The decsion point for multipath is after step "d" in Section
>    9.1.2.2 (prefer externally learned routes).  IBGP learned and EBGP
>    learned routes MUST NOT be combined in multipath.  If the multipath
>    decision is prior to "d", then two routers each with an external
>    peering would form a routing loop.
> 
>    The decision point for multipath is generally after step "e" in
>    Section 9.1.2.2.  Some relaxation of the "equal cost" rule (also
>    applicable to IGP multipath) is possible.  In addition to the equal
>    cost BGP NEXT_HOPS available at BGP route selection, if the IGP
>    next hop for other BGP NEXT_HOPs are of lower cost, then those may
>    be used as well.  This relaxation of the step "e" is possible but
>    is not widely implemented (and may not be implemented at all).


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA29009 for <[e-mail]>; Thu, 17 Oct 2002 19:40:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 75036912DD; Thu, 17 Oct 2002 19:40:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4456C912DE; Thu, 17 Oct 2002 19:40: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 22568912DD for <[e-mail]>; Thu, 17 Oct 2002 19:40:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 069E05DED1; Thu, 17 Oct 2002 19:40: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 6CCEB5DDE1 for <[e-mail]>; Thu, 17 Oct 2002 19:40: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 g9HNe2m51526; Thu, 17 Oct 2002 16:40:02 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: "John G. Scudder" <[e-mail]>, [e-mail]
Subject: Re: last thought on complex aggregation 
In-Reply-To: Your message of "Thu, 17 Oct 2002 15:03:52 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 17 Oct 2002 16:40:02 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> On Thu, Oct 17, 2002 at 02:59:10PM -0400, John G. Scudder wrote:
> > In other words, as long as the spec doesn't explicitly make such AS 
> > paths illegal, I don't think any permanent harm will have been done.
> 
> Amen.

With this in mind let's consider this issue closed (section on
complex path aggregation will be removed).

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 TAA28674 for <[e-mail]>; Thu, 17 Oct 2002 19:34:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 157A69121C; Thu, 17 Oct 2002 19:34:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D773A912DD; Thu, 17 Oct 2002 19: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 B12129121C for <[e-mail]>; Thu, 17 Oct 2002 19:34:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 941855DDE1; Thu, 17 Oct 2002 19:34: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 360445DDC8 for <[e-mail]>; Thu, 17 Oct 2002 19:34: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 g9HNXtm51033; Thu, 17 Oct 2002 16:33:55 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail], Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: issue 8: final text 
In-Reply-To: Your message of "Thu, 17 Oct 2002 17:43:15 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 17 Oct 2002 16:33:55 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> On Thu, Oct 17, 2002 at 02:35:19PM -0700, [e-mail] wrot
e:
> > Wouldn't this be the same as implementing the timers seperately with the
> > same values?  I would argue that it a vendor wishes to do so they may,
> > but it doesn't affect interoperabilty or the text Yakov posted.  The
> > different values in the text are only "suggested defaults" so there is
> > room of implementations to choose different default values.
> 
> The main reason I mentioned this was the fact that the lack of
> implemented complex path aggregation was reason enough to call for
> its removal from the spec.  If we're going to have this requirement,
> this is another spot where its at issue.
> 
> In any case, I don't disagree with your assessment. :-)

So, with this in mind, let's assume that we have a consensus
and close the issue.

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 RAA22383 for <[e-mail]>; Thu, 17 Oct 2002 17:43:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0BFA5912D7; Thu, 17 Oct 2002 17:43:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C542E912D8; Thu, 17 Oct 2002 17:43: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 B591B912D7 for <[e-mail]>; Thu, 17 Oct 2002 17:43:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 985C55DDC9; Thu, 17 Oct 2002 17:43: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 D02B55DD95 for <[e-mail]>; Thu, 17 Oct 2002 17:43:26 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9HLhJm10960; Thu, 17 Oct 2002 17:43: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 g9HLhFC10953; Thu, 17 Oct 2002 17:43:15 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9HLhFP22519; Thu, 17 Oct 2002 17:43:15 -0400 (EDT)
Date: Thu, 17 Oct 2002 17:43:15 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: issue 8: final text
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, Oct 17, 2002 at 02:35:19PM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Oct 17, 2002 at 02:35:19PM -0700, [e-mail] wrote:
> Wouldn't this be the same as implementing the timers seperately with the
> same values?  I would argue that it a vendor wishes to do so they may,
> but it doesn't affect interoperabilty or the text Yakov posted.  The
> different values in the text are only "suggested defaults" so there is
> room of implementations to choose different default values.

The main reason I mentioned this was the fact that the lack of
implemented complex path aggregation was reason enough to call for
its removal from the spec.  If we're going to have this requirement,
this is another spot where its at issue.

In any case, I don't disagree with your assessment. :-)

> 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 RAA22091 for <[e-mail]>; Thu, 17 Oct 2002 17:38:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2CB5D912D6; Thu, 17 Oct 2002 17:38:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA167912D7; Thu, 17 Oct 2002 17: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 029FB912D6 for <[e-mail]>; Thu, 17 Oct 2002 17:38:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DE7775DDC9; Thu, 17 Oct 2002 17:38:17 -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 8184C5DD9D for <[e-mail]>; Thu, 17 Oct 2002 17:38:17 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id OAA05647; Thu, 17 Oct 2002 14:35:19 -0700 (PDT)
Date: Thu, 17 Oct 2002 14:35:19 -0700
From: [e-mail]
To: Jeffrey Haas <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Subject: Re: issue 8: final text
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, Oct 17, 2002 at 10:18:21AM -0400
Sender: [e-mail]
Precedence: bulk

Jeff,

Wouldn't this be the same as implementing the timers seperately with the
same values?  I would argue that it a vendor wishes to do so they may,
but it doesn't affect interoperabilty or the text Yakov posted.  The
different values in the text are only "suggested defaults" so there is
room of implementations to choose different default values.

Andrew

> On Thu, Oct 17, 2002 at 06:22:31AM -0700, Yakov Rekhter wrote:
> > With this in mind, I would suggest we mark this issue as closed.
> 
> Generally agreed.
> 
> But does anyone actually implement both timers?
> GateD and Juniper have outdelay.
> Cisco has neighbor advertisement-interval.
> 
> In all cases, this is a general delay, not one that depends on
> whether the route is being propagated or originated.
> 
> > 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 PAA13576 for <[e-mail]>; Thu, 17 Oct 2002 15:04:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9E7C2912D3; Thu, 17 Oct 2002 15:04:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 69C0A912D4; Thu, 17 Oct 2002 15:04: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 647BE912D3 for <[e-mail]>; Thu, 17 Oct 2002 15:04:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C59BC5DE04; Thu, 17 Oct 2002 15:04: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 B8FA25DDA0 for <[e-mail]>; Thu, 17 Oct 2002 15:04:10 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9HJ3uc05673; Thu, 17 Oct 2002 15:03: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 g9HJ3qC05666; Thu, 17 Oct 2002 15:03:52 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9HJ3qU20549; Thu, 17 Oct 2002 15:03:52 -0400 (EDT)
Date: Thu, 17 Oct 2002 15:03:52 -0400
From: Jeffrey Haas <[e-mail]>
To: "John G. Scudder" <[e-mail]>
Cc: [e-mail]
Subject: Re: last thought on complex aggregation
Message-ID: <[e-mail]>
References: <[e-mail] <[e-mail]> <p05111a0fb9d4b8150c95@[192.168.42.10]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <p05111a0fb9d4b8150c95@[192.168.42.10]>; from [e-mail] on Thu, Oct 17, 2002 at 02:59:10PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Oct 17, 2002 at 02:59:10PM -0400, John G. Scudder wrote:
> In other words, as long as the spec doesn't explicitly make such AS 
> paths illegal, I don't think any permanent harm will have been done.

Amen.

> --John

-- 
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 PAA13335 for <[e-mail]>; Thu, 17 Oct 2002 15:00:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C3A36912D1; Thu, 17 Oct 2002 14:59:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92EF5912D2; Thu, 17 Oct 2002 14:59: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 81339912D1 for <[e-mail]>; Thu, 17 Oct 2002 14:59:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5B4FD5DD8C; Thu, 17 Oct 2002 14:59:46 -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 81E8E5DDBE for <[e-mail]>; Thu, 17 Oct 2002 14:59:45 -0400 (EDT)
Received: from [192.168.42.10] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA25094; Thu, 17 Oct 2002 14:59:19 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a0fb9d4b8150c95@[192.168.42.10]>
In-Reply-To: <[e-mail]>
References:  <[e-mail] > <[e-mail]>
Date: Thu, 17 Oct 2002 14:59:10 -0400
To: Jeffrey Haas <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: last thought on complex aggregation
Cc: "Natale, Jonathan" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

I have the same opinion about removing "complex aggregation" as Jeff 
-- I'm not thrilled but on the other hand I see no serious harm that 
will be caused by doing so.

I am assuming that people will follow the "be liberal in what you 
accept" dictum and accept any reasonable AS path.  IMO an 
implementation that rejects an AS path of the form 
(sequence)(set)(sequence) simply because the RFC doesn't spell out 
how to form one, is an implementation which is trying to be too 
clever by half.

In other words, as long as the spec doesn't explicitly make such AS 
paths illegal, I don't think any permanent harm will have been done.

--John

At 2:49 PM -0400 10/17/02, Jeffrey Haas wrote:
>On Thu, Oct 17, 2002 at 02:43:56PM -0400, Natale, Jonathan wrote:
>>  Nobody "fixed" their code based on this test, or we would not be
>>  having this conversation.
>
>IMO, that particular test should have been "can a router accept
>a packet of this form (complexly aggregated) and still work"?
>
>>  Also, what would happen in a real network with this type of aggregation???
>>  --We don't know.  I think that is the main point.
>
>IMO, things would work fine so long as people could accept packets of
>that form.
>
>--
>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 OAA12743 for <[e-mail]>; Thu, 17 Oct 2002 14:50:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 695C1912D0; Thu, 17 Oct 2002 14:49:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 366E3912D1; Thu, 17 Oct 2002 14:49: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 209B2912D0 for <[e-mail]>; Thu, 17 Oct 2002 14:49:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 01DF95DD8D; Thu, 17 Oct 2002 14:49: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 436AF5DD8C for <[e-mail]>; Thu, 17 Oct 2002 14:49:44 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9HInMO05105; Thu, 17 Oct 2002 14:49:22 -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 g9HInJC05098; Thu, 17 Oct 2002 14:49:19 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9HInJU20486; Thu, 17 Oct 2002 14:49:19 -0400 (EDT)
Date: Thu, 17 Oct 2002 14:49:19 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: last thought on complex aggregation
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, Oct 17, 2002 at 02:43:56PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Oct 17, 2002 at 02:43:56PM -0400, Natale, Jonathan wrote:
> Nobody "fixed" their code based on this test, or we would not be
> having this conversation.

IMO, that particular test should have been "can a router accept
a packet of this form (complexly aggregated) and still work"?

> Also, what would happen in a real network with this type of aggregation???
> --We don't know.  I think that is the main point.

IMO, things would work fine so long as people could accept packets of 
that form.

-- 
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 OAA12429 for <[e-mail]>; Thu, 17 Oct 2002 14:44:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 46B29912CF; Thu, 17 Oct 2002 14:44:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FEE9912D0; Thu, 17 Oct 2002 14:44: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 C5A51912CF for <[e-mail]>; Thu, 17 Oct 2002 14:43:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id AE4585DE04; Thu, 17 Oct 2002 14:43: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 70FE35DDBE for <[e-mail]>; Thu, 17 Oct 2002 14:43:59 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT8AD0>; Thu, 17 Oct 2002 14:43:59 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: RE: last thought on complex aggregation
Date: Thu, 17 Oct 2002 14:43:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Jeff,

Since there are no implementations that do complex aggregation, then your
scenario will probably never happen.  Removing complex aggregation from the
spec is so that nobody takes the trouble of coding it.  So far, the lone
implementer (that I am aware of) was QoSnetics/Qbot/Router tester; they
wrote a test (expecting the complex type of aggregation) which failed for
all known (by me at least) "real" implementations (note that they mis-read
RFC1771/Draft-10, which indicated that simple aggregation is sufficient
also).  Nobody "fixed" their code based on this test, or we would not be
having this conversation.

Also, what would happen in a real network with this type of aggregation???
--We don't know.  I think that is the main point.

:-)


-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Thursday, October 17, 2002 1:45 PM
To: [e-mail]
Subject: last thought on complex aggregation


I finally remembered what was bothering me about removing complex
aggregation from the spec.

If it is removed, people who do conformance tests and some implementations
may take this to mean "it shall be illegal to have an AS_PATH that contains
a SEQUENCE of a particular type after a SET".

This would make a perfectly ok AS_PATH into one that isn't legal, even if no
implementation currently generates it.

-- 
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 NAA09116 for <[e-mail]>; Thu, 17 Oct 2002 13:46:36 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DC53E912CC; Thu, 17 Oct 2002 13:45:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F282912CD; Thu, 17 Oct 2002 13:45: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 31EAA912CC for <[e-mail]>; Thu, 17 Oct 2002 13:45:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 121585DDB4; Thu, 17 Oct 2002 13:45: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 14A8F5DDB2 for <[e-mail]>; Thu, 17 Oct 2002 13:45:13 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9HHjAb02101 for [e-mail]; Thu, 17 Oct 2002 13:45: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 g9HHj7C02094 for <[e-mail]>; Thu, 17 Oct 2002 13:45:07 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9HHj7720240 for [e-mail]; Thu, 17 Oct 2002 13:45:07 -0400 (EDT)
Date: Thu, 17 Oct 2002 13:45:07 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Subject: last thought on complex aggregation
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

I finally remembered what was bothering me about removing complex
aggregation from the spec.

If it is removed, people who do conformance tests and some implementations
may take this to mean "it shall be illegal to have an AS_PATH that
contains a SEQUENCE of a particular type after a SET".

This would make a perfectly ok AS_PATH into one that isn't legal, even
if no implementation currently generates it.

-- 
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 MAA05638 for <[e-mail]>; Thu, 17 Oct 2002 12:45:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6B03A912C8; Thu, 17 Oct 2002 12:45:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04403912C9; Thu, 17 Oct 2002 12:45: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 1ACC1912C8 for <[e-mail]>; Thu, 17 Oct 2002 12:45:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8BD535DE04; Thu, 17 Oct 2002 12:45:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id B0F305DDDA for <[e-mail]>; Thu, 17 Oct 2002 12:45:03 -0400 (EDT)
Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g9HGehp11696 for <[e-mail]>; Thu, 17 Oct 2002 10:40:43 -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: MED is evil? (was: Re: I-D ACTION:draft-mcpherson-rfc3065bis-00.txt)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 17 Oct 2002 10:40:43 -0600
Sender: [e-mail]
Precedence: bulk

> Whether to strip MED depends on what you are trying to accomplish with
> MED.

Of course.  It's just that in my experience the harm caused by MEDs 
considerably outweighs the good.

> Consider the case where ISP A and ISP B peer at multiple places and A
> is directly connected to destination X and B is directly connected to
> destination Y.
> 
> Some ISPs consider it "fair" if both ISPs take the shortest path out
> of their own netork to the other.  In this case both will strip MED
> before advertising to the IGP.  They will usually accept MED for the
> purpose of determining which of multiple routers to select at a
> peering point.

Right, and ALWAYS pick the peer that uses the IGP metric/MED allocation 
mechanism that results in the "lowest value", regardless of any real 
"metric".

> If ISP A has a much faster or less congested network than ISP B, ISP A
> may accept MED from ISP B and route based on MED.  If ISP B sets MED
> according to IGP cost, then a longer path might be taken through the
> ISP A network but the shortest path will be taken in ISP B's network
> in both directions.  This is often the case if B is a customer of A.

Likewise, if ISP A has congestion at a peering point or backbone link
they may muck with the MEDs such that "accepting peers" carry the traffic 
across their network and hand it off where ISP A considers the optimal 
local entry point, potentially changing network and bw/util 
characteristics of the peers networks without any notice or other 
indications, etc..

I think MEDs have their uses, but again, see my first comment above.
As always, YMMV.

-danny



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA04989 for <[e-mail]>; Thu, 17 Oct 2002 12:34:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CEF05912C7; Thu, 17 Oct 2002 12:34:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A04B2912C8; Thu, 17 Oct 2002 12:34: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 5E0E9912C7 for <[e-mail]>; Thu, 17 Oct 2002 12:34:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4B0A45DDA9; Thu, 17 Oct 2002 12:34:05 -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 6AEBB5DD9A for <[e-mail]>; Thu, 17 Oct 2002 12:34: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 MAA88148; Thu, 17 Oct 2002 12:33:26 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Reply-To: [e-mail]
Subject: MED is evil? (was: Re: I-D ACTION:draft-mcpherson-rfc3065bis-00.txt)
In-reply-to: Your message of "Thu, 17 Oct 2002 09:52:15 MDT." <[e-mail]> 
Date: Thu, 17 Oct 2002 12:33:26 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Danny McPherson writes:
> 
> > Just the fact that so many knobs are available sheds light on the
> > fact that many ISPs think MEDs are just evil and should be stripped.
> 
> And I tend to agree...
> 
> -danny


Whether to strip MED depends on what you are trying to accomplish with
MED.

Consider the case where ISP A and ISP B peer at multiple places and A
is directly connected to destination X and B is directly connected to
destination Y.

Some ISPs consider it "fair" if both ISPs take the shortest path out
of their own netork to the other.  In this case both will strip MED
before advertising to the IGP.  They will usually accept MED for the
purpose of determining which of multiple routers to select at a
peering point.

If ISP A has a much faster or less congested network than ISP B, ISP A
may accept MED from ISP B and route based on MED.  If ISP B sets MED
according to IGP cost, then a longer path might be taken through the
ISP A network but the shortest path will be taken in ISP B's network
in both directions.  This is often the case if B is a customer of A.

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 MAA04842 for <[e-mail]>; Thu, 17 Oct 2002 12:31:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 511EE912C5; Thu, 17 Oct 2002 12:30:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C71D912C9; Thu, 17 Oct 2002 12:30: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 3336A912C5 for <[e-mail]>; Thu, 17 Oct 2002 12:30:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 303A35DDA2; Thu, 17 Oct 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 854265DD9A for <[e-mail]>; Thu, 17 Oct 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 MAA17635; Thu, 17 Oct 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 MAA15055; Thu, 17 Oct 2002 12:30:31 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4W8JY918>; Thu, 17 Oct 2002 12:30:30 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 65
Date: Thu, 17 Oct 2002 12:30: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

Agree. Perfect, it also addresses the MULTI-PATH issues.

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Thursday, October 17, 2002 12:27 PM
> To: [e-mail]
> Subject: issue 65
> 
> 
>   65) Rules for Aggregating with MED and NEXT_HOP
>   
> --------------------------------------------------------------
> --------------
> 
> I would suggest to replace:
> 
>    Routes that have the following attributes shall not be aggregated  
>    unless the corresponding attributes of each route are identical:
>    MULTI_EXIT_DISC, NEXT_HOP.
> 
>    If the aggregation occurs as part of the update process, 
> routes with 
>    different NEXT_HOP values can be aggregated when announced 
> through an
>    external BGP session.
> 
>    Path attributes that have different type codes can not be 
> aggregated
>    together. Path attributes of the same type code may be aggregated,
>    according to the following rules:
> 
> with:
> 
>    Routes that have different MULTI_EXIT_DISC attribute SHALL NOT
>    be aggregated. 
> 
>    Path attributes that have different type codes can not be 
> aggregated
>    together. Path attributes of the same type code may be aggregated,
>    according to the following rules:
> 
>      NEXT_HOP: When aggregating routes that have different NEXT_HOP
>      attribute, the NEXT_HOP attribute of the aggregated route SHALL
>      identify an interface on the router that performs the 
> aggregation.
> 
> In the absence of objections I am going to make the above change.
> 
> 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 MAA04612 for <[e-mail]>; Thu, 17 Oct 2002 12:27:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CBA41912C4; Thu, 17 Oct 2002 12:27:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94E02912C5; Thu, 17 Oct 2002 12:27: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 64A91912C4 for <[e-mail]>; Thu, 17 Oct 2002 12:27:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 48E0A5DDA2; Thu, 17 Oct 2002 12:27: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 AECA85DD9A for <[e-mail]>; Thu, 17 Oct 2002 12:27: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 g9HGR5m11307 for <[e-mail]>; Thu, 17 Oct 2002 09:27:05 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 65
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 17 Oct 2002 09:27:05 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  65) Rules for Aggregating with MED and NEXT_HOP
  ----------------------------------------------------------------------------

I would suggest to replace:

   Routes that have the following attributes shall not be aggregated  
   unless the corresponding attributes of each route are identical:
   MULTI_EXIT_DISC, NEXT_HOP.

   If the aggregation occurs as part of the update process, routes with 
   different NEXT_HOP values can be aggregated when announced through an
   external BGP session.

   Path attributes that have different type codes can not be aggregated
   together. Path attributes of the same type code may be aggregated,
   according to the following rules:

with:

   Routes that have different MULTI_EXIT_DISC attribute SHALL NOT
   be aggregated. 

   Path attributes that have different type codes can not be aggregated
   together. Path attributes of the same type code may be aggregated,
   according to the following rules:

     NEXT_HOP: When aggregating routes that have different NEXT_HOP
     attribute, the NEXT_HOP attribute of the aggregated route SHALL
     identify an interface on the router that performs the aggregation.

In the absence of objections I am going to make the above change.

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 MAA03876 for <[e-mail]>; Thu, 17 Oct 2002 12:14:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5784F912C3; Thu, 17 Oct 2002 12:14:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24D8D912C4; Thu, 17 Oct 2002 12:14: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 1D351912C3 for <[e-mail]>; Thu, 17 Oct 2002 12:14:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 01B925DDFD; Thu, 17 Oct 2002 12:14:29 -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 AC9B45DDA6 for <[e-mail]>; Thu, 17 Oct 2002 12:14:28 -0400 (EDT)
Received: from riga ([10.0.0.25]) by earthquake.proficient.net with Microsoft SMTPSVC(5.0.2195.4905); Thu, 17 Oct 2002 09:14:27 -0700
Subject: Re: issue 8: final text
From: Justin Fletcher <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [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: 17 Oct 2002 09:14:25 -0700
Message-Id: <1034871266.2449.43.camel@riga>
Mime-Version: 1.0
X-OriginalArrivalTime: 17 Oct 2002 16:14:27.0253 (UTC) FILETIME=[43F90E50:01C275F8]
Sender: [e-mail]
Precedence: bulk

Agreed

Justin Fletcher

--

On Thu, 2002-10-17 at 06:22, Yakov Rekhter wrote:
> Folks,
> 
> Here is the final text for the BGP Timers section:
> 
>    BGP employs five timers: ConnectRetry (see Section 8), Hold Time
>    (see Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval
>    (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
>    Section 9.2.1.1).
> 
>    The suggested default value for the ConnectRetry timer is 120
>    seconds.
> 
>    The suggested default value for the Hold Time is 90 seconds.
> 
>    The suggested default value for the KeepAlive timer is 1/3 of
>    the Hold Time.
> 
>    The suggested default value for the MinASOriginationInterval is
>    15 seconds.
> 
>    The suggested default value for the MinRouteAdvertisementInterval
>    is 30 seconds.
> 
>    An implementation of BGP MUST allow the Hold Time timer to be
>    configurable, and MAY allow the other timers to be configurable.
> 
>    To minimize the likelihood that the distribution of BGP messages
>    by a given BGP speaker will contain peaks, jitter should be
>    applied to the timers associated with MinASOriginationInterval,
>    Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
>    given BGP speaker may apply the same jitter to each of these
>    quantities regardless of the destinations to which the updates
>    are being sent; that is, jitter need not be configured on a "per
>    peer" basis.
> 
>    The suggested default amount of jitter shall be determined by
>    multiplying the base value of the appropriate timer by a random
>    factor which is uniformly distributed in the range from 0.75 to
>    1.0. A new random value should be picked each time the timer
>    is set. The range of the jitter random value MAY be configurable.
> 
> With this in mind, I would suggest we mark this issue as closed.
> 
> 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 MAA03547 for <[e-mail]>; Thu, 17 Oct 2002 12:09:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5D2CB912C2; Thu, 17 Oct 2002 12:09:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2827E912C3; Thu, 17 Oct 2002 12:09: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 CC2AE912C2 for <[e-mail]>; Thu, 17 Oct 2002 12:09:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B73A25DDFD; Thu, 17 Oct 2002 12:09: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 3FB085DDA6 for <[e-mail]>; Thu, 17 Oct 2002 12:09: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 g9HG9Am10149 for <[e-mail]>; Thu, 17 Oct 2002 09:09:10 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 58: final
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 17 Oct 2002 09:09:10 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

58) Deprication of ATOMIC_AGGREGATE
----------------------------------------------------------------------------
The following changes reflect the consensus of the WG:

Replace:
    
  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.
 
with:

  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.
 
In 9.1.4 replace:
   
   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.

with:

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

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 MAA03150 for <[e-mail]>; Thu, 17 Oct 2002 12:02:25 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DCC40912C0; Thu, 17 Oct 2002 12:01:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C5B2912C1; Thu, 17 Oct 2002 12:01: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 B9DDE912C0 for <[e-mail]>; Thu, 17 Oct 2002 12:01:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 959BB5DDAC; Thu, 17 Oct 2002 12:01: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 024F85DDA6 for <[e-mail]>; Thu, 17 Oct 2002 12:01: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 g9HG1qm09515 for <[e-mail]>; Thu, 17 Oct 2002 09:01:52 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 61
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 17 Oct 2002 09:01:52 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  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.
  
  Issue 14 closed in favor of this issue.
  
  In response to Yakov's call for input, Michael responded that:
  
  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 (text is above.)

Replace:

  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.

with:

  1) When sending a message to an internal peer, if the route is
  not locally originated the BGP speaker should not modify the
  NEXT_HOP attribute, unless it has been explicitly configured to
  announce its own IP address as the NEXT_HOP. When announcing a
  locally originated route to an internal peer, the BGP speaker
  should use 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).

In the absence of objections I'll make the above change.

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 MAA03100 for <[e-mail]>; Thu, 17 Oct 2002 12:01:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6DF05912BF; Thu, 17 Oct 2002 12:00:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3514A912C0; Thu, 17 Oct 2002 12: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 8F3FE912BF for <[e-mail]>; Thu, 17 Oct 2002 12:00:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DAC815DDB3; Thu, 17 Oct 2002 12:00:26 -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 52B505DDAC for <[e-mail]>; Thu, 17 Oct 2002 12:00:25 -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 LAA87883; Thu, 17 Oct 2002 11:59:48 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Reply-To: [e-mail]
Subject: Separate document for multipath - or part of BGP spec
Date: Thu, 17 Oct 2002 11:59:48 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

After some discussion initiated by Alex we ended up with the following
text on BGP multipath.  If we can get consensus on text to be added to
the BGP base spec then we'll add text.  If not, we'll omit any mention
of BGP multipath.  We seem to have rough consensus among a small
number of people.

Curtis


  [new subesection]

   BGP specifies how to select the single best route.  OSPF
   specifically defines procedures for handling equal cost multipath
   (ECMP) [cite OSPF].  The same technique has been applied to ISIS.
   A similar technique has been used with BGP.  Variations exist but
   the decision to support BGP multipath, the specific variation of
   BGP multipath, or not to support it, does not affect
   interoperability.

   A naive implementations of ECMP can cause severe performance
   degradation for TCP flows.  To avoid this, implementations of BGP
   multipath SHOULD maintain packet ordering within microflows as
   described in [cite rfc2991, rfc2992].

   BGP multipath, if implemented, SHOULD be disabled by default.

   In addition to IGP multipath (OSPF ECMP and ISIS equivalent), there
   are two variations of BGP multipath described here.  A BGP
   implementation may offer both, either one, or neither variation of
   BGP multipath.  Other variations of BGP multipath may exist, but no
   guarantees can be made in this protocol specification of their
   properties or impact on interoperability.

   Where IGP multipath is used, there is an interaction with BGP
   learned routes.  The lookup of a BGP NEXT_HOP in the IGP can
   result in the selection of an IGP multipath entry.  This is not a
   variation of BGP multipath.  When this occurs, one BGP route is
   slected as the best but there is more than one way to reach the BGP
   NEXT_HOP via the IGP.

   In one variation of BGP multipath, a set of more than one IBGP
   routers peering with the same external AS have equal routes to a
   destination and are an equal IGP cost away from a second set of one
   or more routers.  BGP multipath is applicable to the latter set of
   routers.  Without BGP multipath, BGP would pick the BGP NEXT_HOP of
   the advertisement from only one of those IBGP peers (using BGP
   Identifier) and use only that BGP route.  With BGP multipath, BGP
   uses the BGP NEXT_HOP of more than one of these equal cost
   advertisements, yielding more than one BGP NEXT_HOP.  Each BGP
   NEXT_HOP has a different IGP next hop (one or more IGP next hop if
   IGP multipath is in use).

   The second case is where all of the candidates routes for BGP
   multipath are external and learned by a single BGP peer.  Without
   BGP multipath this peer would select only one of the BGP routes and
   obtain only one BGP NEXT_HOP.  With BGP multipath, more than one
   equal cost route is selected yielding more than one BGP NEXT_HOP.
   Seldom does IGP multipath come into play when looking up an EBGP
   NEXT_HOP but could in principle be applicable.

   If in EBGP multipath traffic is split among routers in difference
   AS, an aggregate SHOULD be formed so as to propogate a route with
   an accurate AS_PATH.  If the resulting aggregate is not more
   specific than the components, the AS_SET SHOULD NOT be dropped.

   The decsion point for multipath is after step "d" in Section
   9.1.2.2 (prefer externally learned routes).  IBGP learned and EBGP
   learned routes MUST NOT be combined in multipath.  If the multipath
   decision is prior to "d", then two routers each with an external
   peering would form a routing loop.

   The decision point for multipath is generally after step "e" in
   Section 9.1.2.2.  Some relaxation of the "equal cost" rule (also
   applicable to IGP multipath) is possible.  In addition to the equal
   cost BGP NEXT_HOPS available at BGP route selection, if the IGP
   next hop for other BGP NEXT_HOPs are of lower cost, then those may
   be used as well.  This relaxation of the step "e" is possible but
   is not widely implemented (and may not be implemented at all).


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA02842 for <[e-mail]>; Thu, 17 Oct 2002 11:57:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7A0F0912BE; Thu, 17 Oct 2002 11:56:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47945912BF; Thu, 17 Oct 2002 11:56: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 5A203912BE for <[e-mail]>; Thu, 17 Oct 2002 11:56:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 489D05DDD8; Thu, 17 Oct 2002 11:56:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: from tcb.net (tcb.net [205.168.100.1]) by segue.merit.edu (Postfix) with ESMTP id BED165DDB3 for <[e-mail]>; Thu, 17 Oct 2002 11:56:36 -0400 (EDT)
Received: from dog.tcb.net (danny@localhost) by tcb.net (8.11.6/8.11.4) with ESMTP id g9HFqFk11109 for <[e-mail]>; Thu, 17 Oct 2002 09:52:16 -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, 17 Oct 2002 09:52:15 -0600
Sender: [e-mail]
Precedence: bulk

> The document should be clarified.
> GateD currently pays attention to the neighboring AS regardless of
> whether its a confederation or not.
> The *DEFAULT* behavior of Cisco and Juniper is to not pay attention,
> but that depends which of way too many knobs are set.  

I'll attempt to clarify in the next rev.
 
> http://www.cisco.com/en/US/tech/tk648/tk365/technologies_tech_note09186a0080094431.shtml
> http://www.juniper.net/techpubs/software/junos54/swconfig54-routing/html/protocols-overview4.html#1014020
> 
> Just the fact that so many knobs are available sheds light on the
> fact that many ISPs think MEDs are just evil and should be stripped.

And I tend to agree...

-danny





Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA02507 for <[e-mail]>; Thu, 17 Oct 2002 11:51:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 49736912BC; Thu, 17 Oct 2002 11:51:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F1C7912BD; Thu, 17 Oct 2002 11:51: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 7EBE6912BC for <[e-mail]>; Thu, 17 Oct 2002 11:51:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5B82C5DDAA; Thu, 17 Oct 2002 11:51: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 CCD0C5DD9A for <[e-mail]>; Thu, 17 Oct 2002 11:51:23 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9HFoiC98618; Thu, 17 Oct 2002 11:50: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 g9HFoeC98606; Thu, 17 Oct 2002 11:50:40 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9HFodv19727; Thu, 17 Oct 2002 11:50:39 -0400 (EDT)
Date: Thu, 17 Oct 2002 11:50:39 -0400
From: Jeffrey Haas <[e-mail]>
To: Tian Fang <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-mcpherson-rfc3065bis-00.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Sep 19, 2002 at 10:58:29AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Sep 19, 2002 at 10:58:29AM -0400, Tian Fang wrote:
> 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?

The document should be clarified.
GateD currently pays attention to the neighboring AS regardless of
whether its a confederation or not.
The *DEFAULT* behavior of Cisco and Juniper is to not pay attention,
but that depends which of way too many knobs are set.  

http://www.cisco.com/en/US/tech/tk648/tk365/technologies_tech_note09186a0080094431.shtml
http://www.juniper.net/techpubs/software/junos54/swconfig54-routing/html/protocols-overview4.html#1014020

Just the fact that so many knobs are available sheds light on the
fact that many ISPs think MEDs are just evil and should be stripped.

> Tian Fang

-- 
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 KAA27130 for <[e-mail]>; Thu, 17 Oct 2002 10:18:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3E47F912B4; Thu, 17 Oct 2002 10:18:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09B98912B5; Thu, 17 Oct 2002 10:18: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 04AAE912B4 for <[e-mail]>; Thu, 17 Oct 2002 10:18:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E011A5DDD0; Thu, 17 Oct 2002 10:18: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 2D2E35DDA0 for <[e-mail]>; Thu, 17 Oct 2002 10:18:26 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9HEIOi95703; Thu, 17 Oct 2002 10:18:24 -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 g9HEILC95696; Thu, 17 Oct 2002 10:18:21 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9HEILk19262; Thu, 17 Oct 2002 10:18:21 -0400 (EDT)
Date: Thu, 17 Oct 2002 10:18:21 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 8: final text
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, Oct 17, 2002 at 06:22:31AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Oct 17, 2002 at 06:22:31AM -0700, Yakov Rekhter wrote:
> With this in mind, I would suggest we mark this issue as closed.

Generally agreed.

But does anyone actually implement both timers?
GateD and Juniper have outdelay.
Cisco has neighbor advertisement-interval.

In all cases, this is a general delay, not one that depends on
whether the route is being propagated or originated.

> 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 KAA26546 for <[e-mail]>; Thu, 17 Oct 2002 10:11:16 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B0E99912B3; Thu, 17 Oct 2002 10:10:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 827DD912B4; Thu, 17 Oct 2002 10:10: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 7EF9D912B3 for <[e-mail]>; Thu, 17 Oct 2002 10:10:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 67B535DD9D; Thu, 17 Oct 2002 10:10: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 B08335DD98 for <[e-mail]>; Thu, 17 Oct 2002 10:10:47 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9HEAk195367; Thu, 17 Oct 2002 10:10:46 -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 g9HEAhC95360; Thu, 17 Oct 2002 10:10:43 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g9HEAhW19245; Thu, 17 Oct 2002 10:10:43 -0400 (EDT)
Date: Thu, 17 Oct 2002 10:10:42 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 66
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, Oct 17, 2002 at 06:45:29AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Oct 17, 2002 at 06:45:29AM -0700, Yakov Rekhter wrote:
>   Jeff replied that there is absolutely nothing wrong with doing complex
>   aggregation, and there is no reason to remove this from the specification.

I am also fine with removing it.  I just don't think its necessary,
especially if One Of These Days someone decides that running policy
based on as-adjacencies would be a Nice Thing and fixes their
implementation to support "complex" aggregation of paths.

That said, I am aware of no one who implements 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 KAA26202 for <[e-mail]>; Thu, 17 Oct 2002 10:05:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D9E17912B2; Thu, 17 Oct 2002 10:05:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A556F912B3; Thu, 17 Oct 2002 10:05: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 6ED64912B2 for <[e-mail]>; Thu, 17 Oct 2002 10:05:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5B41F5DD9D; Thu, 17 Oct 2002 10:05: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 14BD15DDA1 for <[e-mail]>; Thu, 17 Oct 2002 10:05:42 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <4LBT79VZ>; Thu, 17 Oct 2002 10:05:41 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 32.1: final
Date: Thu, 17 Oct 2002 10:05:38 -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: Thursday, October 17, 2002 9:53 AM
To: [e-mail]
Subject: issue 32.1: final


Here is the final text:

In 4.3:

   a)   ORIGIN (Type Code 1):
   
   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 [RFC904]
   
   2         INCOMPLETE - Network Layer Reachability
                Information learned by some other means
   
   Usage of this attribute is defined in 5.1.1.

In 5.1.1:

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

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 KAA26132 for <[e-mail]>; Thu, 17 Oct 2002 10:04:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 95D0F912B1; Thu, 17 Oct 2002 10:04:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05412912B2; Thu, 17 Oct 2002 10:04: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 E28E1912B1 for <[e-mail]>; Thu, 17 Oct 2002 10:04:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D07245DD9E; Thu, 17 Oct 2002 10:04: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 4D4775DD9D for <[e-mail]>; Thu, 17 Oct 2002 10:04:20 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g9HE4J695190 for [e-mail]; Thu, 17 Oct 2002 10:04:19 -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 g9HE4GC95183 for <[e-mail]>; Thu, 17 Oct 2002 10:04:16 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g9HE4F810195 for [e-mail]; Thu, 17 Oct 2002 10:04:16 -0400 (EDT)
Date: Thu, 17 Oct 2002 10:04:15 -0400
From: Mathew Richardson <[e-mail]>
To: [e-mail]
Subject: Re: issue 67
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4i
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

> Yakov Rekhter <[e-mail]> [Thu, Oct 17, 2002 at 06:34:02AM -0700]:

<snip>

>The issue of route selection in the present of confederations
>belongs *not* to the base spec, but to the spec that describes
>BGP Confeds. With this in mind I would suggest to change in 9.1.2.2 from
>
>        a) Remove from consideration all routes which are not tied for
>        having the smallest number of AS numbers present in their AS_PATH
>        attributes. Note, that when counting this number, an AS_SET counts
>        as 1, no matter how many ASs are in the set, and that, if the
>        implementation supports [13], then AS numbers present in segments
>        of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in
>        the count of AS numbers present in the AS_PATH.
>to
>
>        a) Remove from consideration all routes which are not tied for
>        having the smallest number of AS numbers present in their AS_PATH
>        attributes. Note, that when counting this number, an AS_SET counts
>        as 1, no matter how many ASs are in the set. 

<snip>

I agree both with this change, and with the logic behind 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 JAA25475 for <[e-mail]>; Thu, 17 Oct 2002 09:53:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 96396912AF; Thu, 17 Oct 2002 09:53:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61A75912B0; Thu, 17 Oct 2002 09:53: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 5DEF9912AF for <[e-mail]>; Thu, 17 Oct 2002 09:53:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 280725DDA0; Thu, 17 Oct 2002 09:53: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 8F6E95DD9A for <[e-mail]>; Thu, 17 Oct 2002 09:53: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 g9HDrGm00666 for <[e-mail]>; Thu, 17 Oct 2002 06:53:16 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 32.1: final
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 17 Oct 2002 06:53:16 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Here is the final text:

In 4.3:

   a)   ORIGIN (Type Code 1):
   
   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 [RFC904]
   
   2         INCOMPLETE - Network Layer Reachability
                Information learned by some other means
   
   Usage of this attribute is defined in 5.1.1.

In 5.1.1:

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

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 JAA25099 for <[e-mail]>; Thu, 17 Oct 2002 09:46:36 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D4906912AD; Thu, 17 Oct 2002 09:45:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DC60912AF; Thu, 17 Oct 2002 09:45: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 69445912AD for <[e-mail]>; Thu, 17 Oct 2002 09:45:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BF38C5DDA1; Thu, 17 Oct 2002 09:45: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 314605DDA0 for <[e-mail]>; Thu, 17 Oct 2002 09:45: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 g9HDjTm00415 for <[e-mail]>; Thu, 17 Oct 2002 06:45:29 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 66
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 17 Oct 2002 06:45:29 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  66) Complex AS Path Aggregating
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Do we remove a section of the spec that has to do with an aggregation
    scheme that is rarely used?
  
  Discussion:
  
  Jonathan opened this discussion with:
  
  The part in the draft about complex AS path aggregation could/should be
  deleted.  The current draft implies that when aggregating, for example
  (1st):
  
  1 2 4 3
  
  w/
  
  3 4 6 5
   
  and
  
  5 6 7 8
  
  then
  
  1 2 {3 4 5 6} 7 8
  
  ...would be OK
  
  AFAIK, all implementations aggregate by either: (2nd)putting ONLY the local
  AS in the path (and setting the atomic) OR (3rd)by creating 1 giant set and
  adding the local AS as a seq.
  
  So he proposed we remove this to reflect current code.
  
  Jeff replied that there is absolutely nothing wrong with doing complex
  aggregation, and there is no reason to remove this from the specification.

Jonathan is certainly correct that the spec has to reflect current
code.  Therefore, unless there are at least two (interoperable)
implementations that implement the algorithm described in "6.8
Complex AS_PATH aggregation", this section has to be removed (this
is irrespective of whether there is something wrong, or nothing
wrong with complex aggregation). With this in mind, if you implement
this algorithm please speak up within a week.  If within a week we
wouldn't know that there are at least two implementations the
section will be removed. And likewise, if we hear that there are
at least two implementations, the section will stay. 

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 JAA24382 for <[e-mail]>; Thu, 17 Oct 2002 09:34:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8850D912AC; Thu, 17 Oct 2002 09:34:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57ED7912AD; Thu, 17 Oct 2002 09:34: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 3879F912AC for <[e-mail]>; Thu, 17 Oct 2002 09:34:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 054525DDA0; Thu, 17 Oct 2002 09:34: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 906225DD9F for <[e-mail]>; Thu, 17 Oct 2002 09:34: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 g9HDY2m99767 for <[e-mail]>; Thu, 17 Oct 2002 06:34:02 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 67
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 17 Oct 2002 06:34:02 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

  67) Counting AS_SET/AS_CONFED_*
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: Is how we count AS_SET/AS_CONFED_* covered suffiecently in the
    current draft? 
  
  Discussion:
  
  Jonathan brought up some questions on how current implementations count
  AS_SET and AS_CONFED_*
  
  There were a variety of resposnes to this, answering his questions.
  Curtis pointed out that this behavior is covered in:
  
  That's in 9.1.2.2:
  
        a) Remove from consideration all routes which are not tied for
        having the smallest number of AS numbers present in their AS_PATH
        attributes. Note, that when counting this number, an AS_SET counts
        as 1, no matter how many ASs are in the set, and that, if the
        implementation supports [13], then AS numbers present in segments
        of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in
        the count of AS numbers present in the AS_PATH.
  
  Jonathan replied that this might be at odds with what Juniper does,
  although he was unsure, and asked for clarification.
  
  This was discussed in the "New Issue AS path" thread.

The issue of route selection in the present of confederations
belongs *not* to the base spec, but to the spec that describes
BGP Confeds. With this in mind I would suggest to change in 9.1.2.2 from

        a) Remove from consideration all routes which are not tied for
        having the smallest number of AS numbers present in their AS_PATH
        attributes. Note, that when counting this number, an AS_SET counts
        as 1, no matter how many ASs are in the set, and that, if the
        implementation supports [13], then AS numbers present in segments
        of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in
        the count of AS numbers present in the AS_PATH.
to

        a) Remove from consideration all routes which are not tied for
        having the smallest number of AS numbers present in their AS_PATH
        attributes. Note, that when counting this number, an AS_SET counts
        as 1, no matter how many ASs are in the set. 

and ask the authors of BGP Confeds to update their document to
cover how the presence of confeds impact route selection.

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 JAA23727 for <[e-mail]>; Thu, 17 Oct 2002 09:22:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 05748912A9; Thu, 17 Oct 2002 09:22:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB2DB912AA; Thu, 17 Oct 2002 09: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 AAF94912A9 for <[e-mail]>; Thu, 17 Oct 2002 09:22:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9B7115DD9A; Thu, 17 Oct 2002 09:22: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 3DB6A5DD99 for <[e-mail]>; Thu, 17 Oct 2002 09:22:32 -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 g9HDMVm99249 for <[e-mail]>; Thu, 17 Oct 2002 06:22:31 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 8: final text
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Thu, 17 Oct 2002 06:22:31 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

Here is the final text for the BGP Timers section:

   BGP employs five timers: ConnectRetry (see Section 8), Hold Time
   (see Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval
   (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
   Section 9.2.1.1).

   The suggested default value for the ConnectRetry timer is 120
   seconds.

   The suggested default value for the Hold Time is 90 seconds.

   The suggested default value for the KeepAlive timer is 1/3 of
   the Hold Time.

   The suggested default value for the MinASOriginationInterval is
   15 seconds.

   The suggested default value for the MinRouteAdvertisementInterval
   is 30 seconds.

   An implementation of BGP MUST allow the Hold Time timer to be
   configurable, and MAY allow the other timers to be configurable.

   To minimize the likelihood that the distribution of BGP messages
   by a given BGP speaker will contain peaks, jitter should be
   applied to the timers associated with MinASOriginationInterval,
   Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
   given BGP speaker may apply the same jitter to each of these
   quantities regardless of the destinations to which the updates
   are being sent; that is, jitter need not be configured on a "per
   peer" basis.

   The suggested default amount of jitter shall be determined by
   multiplying the base value of the appropriate timer by a random
   factor which is uniformly distributed in the range from 0.75 to
   1.0. A new random value should be picked each time the timer
   is set. The range of the jitter random value MAY be configurable.

With this in mind, I would suggest we mark this issue as closed.

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 EAA11981 for <[e-mail]>; Thu, 17 Oct 2002 04:38:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9E997912A3; Thu, 17 Oct 2002 04:38:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F761912A4; Thu, 17 Oct 2002 04:38: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 AA8B3912A3 for <[e-mail]>; Thu, 17 Oct 2002 04:38:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 83FB55E078; Thu, 17 Oct 2002 04:38:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: from demiurge.exodus.net (unknown [216.32.171.82]) by segue.merit.edu (Postfix) with ESMTP id 5FE675DECE for <[e-mail]>; Thu, 17 Oct 2002 04:38:07 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id BAA26238 for [e-mail]; Thu, 17 Oct 2002 01:35:08 -0700 (PDT)
Date: Thu, 17 Oct 2002 01:35:08 -0700
From: [e-mail]
To: [e-mail]
Subject: BGP Base Draft - Issue List v1.3
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="RASg3xLB4tUQ4RcS"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: [e-mail]
Precedence: bulk

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

Attached is the latest update to the issues list.  I've added a section 
at the beginning listing all the issues that are NOT at consensus, so 
we can more easily see what we still need to work on.  As of this revision
we have 16 outstanding issue.  Since the last revision, we had added
4 issues, updated 13, move 1 FROM consensus, and moved 8 to consensus.

Andrew


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

2002-10-16
v1.3

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 "Unfeasible 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
61) Next Hop for Redistributed Routes
62) Deprecate BGP Authentication Optional Parameter from RFC1771
63) Clarify MED Removal Text
64) MED for Originated Routes
65) Rules for Aggregating with MED and NEXT_HOP
66) Complex AS Path Aggregating
67) Counting AS_SET/AS_CONFED_*

============================================================================
Issues with Consensus
============================================================================
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
9) Reference to RFC904 - EGP Protocol
10) Extending AS_PATH Attribute
11.1) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3
12) TCP Behavior Wording
13) Next Hop for Originated Route
14) NEXT_HOP to Internal Peer (closed in favor of issue 61)
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.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 "Unfeasible Routes" and "Withdrawn Routes"
38) Clarify Outbound Route Text
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
47) FSM - Add Explicit State Change Wording
49) Explicity Define Event Generation
50) FSM Timers 
51) FSM ConnectRetryCnt
52) Section 3: Keeping routes in Adj-RIB-In
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
59) Section 4.3 - Move text
60) Section 4.3 - Path Attributes
62) Deprecate BGP Authentication Optional Parameter from RFC1771
64) MED for Originated Routes

============================================================================
Issues WITHOUT Consensus
============================================================================

8) Jitter Text
11) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1
11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
32) Clarify EGP Reference
32.1) EGP ORIGIN Clarification
39) Redundant Sentance Fragments
45) Consistant References to BGP Peers/Connections/Sessions
46) FSM Connection Collision Detection
48) Explicitly Define Processing of Incomming Connections
53) Section 4.3 - Routes v. Destinations - Advertise
58) Deprication of ATOMIC_AGGREGATE
61) Next Hop for Redistributed Routes
63) Clarify MED Removal Text
65) Rules for Aggregating with MED and NEXT_HOP
66) Complex AS Path Aggregating
67) Counting AS_SET/AS_CONFED_*

----------------------------------------------------------------------------
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 opinions expressed on this were 7 in favor, 4 against.

----------------------------------------------------------------------------
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: 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: Consensus on the change, but we still need the text
Change: Potentially
Summary:
 Get rid of section 9.2.1.3 ("Jitter").
 Move the text to an Appendix: "BGP Timers"
 Expand text to indicate that jitter applies to all timers, including 
  ConnectRetry.
 
 We still need specific text for the Appendix we have some good text on
 the table, and we're debating tweaks to it.

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"

Yakov agreed with making some changes and suggested that we make sure
that jitter is applied to all timers.  Specifically, he proposes we
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.

Jonathan, the original commentor, agreed with Yakov's suggestion.

In a follow-up to this issue, there was a question raised about the values
we have specified for timers in the document. Specifically:

    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 ?

Curtis responded to this with:

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.

And Jonathan replied with this information about current practice:

 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.

So the question that arises from this followup, is how does this question 
affect the text of the appendix on jitter?

Curtis replied that we need to only state that jitter should be applied
to all timers.  Whether a vendor does so or not is a minor deficiency and
does not bear on interoperability.  Therefore, specifying exact details
are not necessary.

After Jonathan's response Curtis and Jonathan agreed that jitter should
be added to all timers and that we should state so in the text.

Yakov proposed the following text for the appendix to discuss jitter:

I'd like to propose the following text for "BGP Timers" section:

   BGP employs five timers: ConnectRetry (see Section 8), Hold Time
   (see Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval
   (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
   Section 9.2.1.1).

   The suggested value for the ConnectRetry timer is 120 seconds.

   The suggested value for the Hold Time is 90 seconds.

   The suggested value for the KeepAlive timer is 1/3 of the Hold
   Time.

   The suggested value for the MinASOriginationInterval is 15
   seconds.

   The suggested value for the MinRouteAdvertisementInterval is 30
   seconds.

   An implementation of BGP MUST allow the Hold Time timer to be
   configurable, and MAY allow the other timers to be configurable.

   To minimize the likelihood that the distribution of BGP messages
   by a given BGP speaker will contain peaks, jitter should be
   applied to the timers associated with MinASOriginationInterval,
   Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
   given BGP speaker shall apply the same jitter to each of these
   quantities regardless of the destinations to which the updates
   are being sent; that is, jitter will not be applied on a "per
   peer" basis.

   The amount of jitter to be introduced shall be determined by
   multiplying the base value of the appropriate timer by a random
   factor which is uniformly distributed in the range from 0.75 to
   1.0.

Jeff  & Ben agreed with this.  

Justin suggested that we move the range from 0.75 to 1.25 to ensure that the 
average is around the configured value.  Yakov agreed with Justin's changes. 
Jonathan disagreed, arguing that it was out-of-scope for the task of 
clarifying the text only.  Justin agreed and withdrew his comment.

Curtis liked the general text, but suggested these modifications:

minor improvement (not really an objection) --
   s/suggested value/suggested default value/g

Also

  s/shall apply the same jitter/may apply the same jitter/
   (to each of these quantities regardless of ...).
 
  s/jitter will not be applied/jitter need not be configured/
    (on a "per peer" basis).

He stated that in Avici's implementation they allow a lot of granularity
in timer settings, so this reflects current practice.

Curtis also suggested changing the last paragraph:

   The suggested default amount of jitter shall be determined by   
   multiplying the base value of the appropriate timer by a random
   factor which is uniformly distributed in the range from 0.75 to
   1.0.  A new random value should be picked each time the timer is
   set.  The range of the jitter random value MAY be configurable.

This would make it clear that it is possible to have this timer as 
configurable and still be within spec.

Other comments on Yakov's text pointed out that IOS uses 5 seconds as
the default IBGP MinRouteAdvertisementInterval.

Tom pointed out that there seems to be a discrepency between this text
and the FSM:  The FSM has an OpenDelay timer.  And the FSM suggests a 
HoldTimer of 4 minutes.

----------------------------------------------------------------------------
9) Reference to RFC904 - EGP Protocol
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
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.

Yakov agreed to this, and Jonathan seconded it.

----------------------------------------------------------------------------
10) Extending AS_PATH Attribute
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: 
  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 MUST not advertise the route to its peers and
    may choose to log an error locally.


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. 

Yakov stated that:

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:

After some discussion, Yakov's proposed text's last sentance was dropped
and we arrived at:

    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. 

In response to Andrew's clarification question to the list, Curtis
responded:

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.
     
After some additional discussion, it was decided that we add "and may
choose to log an error locally." to the end of Yakov's text.

Also, we agreed to change "may choose not to advertize..." to 
"MUST NOT advertise...".

So the text 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.

This met with one agreement and no disagreements.  We have a consensus.

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

Yakov replied to this that:

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.

The "issue 11" thread this was being discussed in then digressed to the
topic, now covered in issue 11.3.

Ben readdressed the original issue with this input:

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

Ben's comment has not yet received a reponse.

We are still working on consensus on this. 

----------------------------------------------------------------------------
11.1) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: The text below will be added to the -18 version.

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.

This text will be added to the -18 version, and since there were no
objections, this issue has been moved to consensus.

----------------------------------------------------------------------------
11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: It was pointed out that this issue had gotten prematurely moved
  to consensus since it was incorrectly subsumed into issue 32.2.  Discussion
  on this issue as resumed.

  We are currently trying to decide if we should:

  1.  Omit it (the implied consensus of the rewrite of the paragraph
      in 32.2).

  2.  Leave it as is and put it in another paragraph to separate it
      from the destination based routing statement.

  3.  Clean up the wording and put it in another paragraph to separate
      it from the destination based routing statement.

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 were a lot of emails exchanged on this topic with a variety of 
texts proposed (see early in the "Active Route" thread).  This issue
reopend with Jonathan, who brought up the issue originally, stating that:

 The issue I raised, and would like to be [re-]considered is with:
 
 "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."

Curtis replied that:

That is called route orgination and it is allowed by:

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

Advice on what to put in the AS_PATH and NEXT_HOP is in the document.

He continued with:

I don't think there was ever consensus on what to do with the
statement "a BGP speaker advertises to its peers (other BGP speakers
which it communicates with) in neighboring ASs only those routes that
it itself uses".  Some reasonable choices are:

  1.  Omit it (the implied consensus of the rewrite of the paragraph
      in 32.2).
  
  2.  Leave it as is and put it in another paragraph to separate it
      from the destination based routing statement.

  3.  Clean up the wording and put it in another paragraph to separate
      it from the destination based routing statement.

The separate paragraph for 2 would be the exact sentence we now have.
   
   A BGP speaker advertises to its peers (other BGP speakers which it
   communicates with) in neighboring ASs only those routes that it
   itself uses.

In possibility 3 we (try to) clear up the ambiguity about the meaning
of the word "use" in this sentence.

   A BGP speaker advertises to its peers (other BGP speakers which it
   communicates with) in neighboring ASs only those routes that it
   itself uses.  In this context a BGP speaker is said to "use" a BGP
   route if it is the most preferred BGP route and is either directly
   used in forwarding or in a specifically configured case where the
   BGP route would be forwarded internally but IGP forwarding
   information is used.  The latter case reflects a usage in which the
   IGP is used for forwarding but BGP is originated to IBGP to carry
   attributes that cannot be carried by the IGP (for example, BGP
   communities [N]).  Other special cases such as virtual routers and
   multiple instances of BGP on a single router are beyond the scope
   of this document but for each of these the statement "a BGP speaker
   advertises to its peers (other BGP speakers which it communicates 
   with) in neighboring ASs only those routes that it itself uses" can
   (and should in the definition of the extension) be made true with
   an appropriate definition of the word "use".
      
Unless someone volunteers better wording this may be a good starting
point.  I thing the last sentence borders on ridiculous in a protocol
spec but may be necessary to address specific objections raised on
this mailing list.  If we want to elaborate on the meaning of the word
"use" and address the objections this is what we end up with.
      
Of course looking at what we ended up with, I'd also go along with the
other two options (leave it out or put the one sentence in a separate
paragraph as is).

This issue is still undergoing debate.

----------------------------------------------------------------------------
11.3) Documenting IBGP Multipath
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: The documenting of IBGP Multipath is left to another Internet 
 Draft.  The consensus is that it should not be in the base spec.

 However, we are reconsiderting this at the moment.

Discussion:

This thread began in the "issue 11" discussion.  In it it was proposed
that:

    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.

After much discussion back and forth, it was agreed that documenting
IBGP Multipath behavior is a good thing.  However, it is something that
belongs in another draft.

Alex opened this issue up again.  There were a flury of responses, most
all of them agreeing with the original consensus that we should document
this feature in a different draft, since it doesn't affect the core
interoperatbilty requirements, and we want to advance the spec in a 
timely manner.

Alex persisted in his assertion that this belongs in the base specification.
Right now, the issue is still open.

This discussion later expanded in scope to include all BGP multipath.

Curtis laid out a good description of the various flavors of multipath:

 In addition to IGP multihop, there are two cases of BGP multipath.

 In IGP multihop there is one BGP advertisement but to ways to reach th
 BGP NEXT_HOP via the IGP.

 In one case of BGP multihop, two (or more) IBGP routers peering with
 the same external AS have equal routes to a destination and are an
 equal cost away from a third router.  BGP multihop is applicable to
 that third router.  Without BGP multihop, BGP would normally pick the
 BGP NEXT_HOP of the advertisement from only one of those IBGP peers
 (using BGP Identifier) and use that.  The IGP lookup would yield one
 next hop.  With BGP multihop, BGP uses the BGP NEXT_HOP of both
 advertisements.  Each BGP NEXT_HOP has a different IGP next hop (one
 or more IGP next hop).

 The second case is where all of the candidates routes for BGP
 multipath are external.  Seldom does IGP multipath come into play for
 EBGP (odd tunneled EBGP mutlihop cases maybe).  Typically the load is
 split among two (or more) routers in the same AS.
 
 If in EBGP multipath you split among routers in difference AS, an
 aggregate should be formed.  This is still prior to the IGP cost rule
 in the route selection.

 Normally one would not combine IBGP and EBGP in multihop given that
 the decsion point for multihop is after "d" in 9.1.2.2.  If the
 multihop decision was prior to "d", then two routers each with an
 external peering would forward some of the traffic to each other and
 for some src/dst pairs, they'd form a loop.  [So don't do that!]

 This is getting to be a lot to add to the base spec.  I hope we've
 convinced you that we should put it in another document.

----------------------------------------------------------------------------
12) TCP Behavior Wording
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: In issue 19 we decided to remove this section entirely.  As a 
  result the previous consensus on this issue (no change) is renderd
  moot.

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.

In issue 19 we decided to remove this section entirely.

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

For related discussion see issue 61.

----------------------------------------------------------------------------
14) NEXT_HOP to Internal Peer
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Closed in favor of issue 61.

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.

Since this issue and issue 61 are basically the same, except 61 proposes
text, we'll close this issue in favor of 61.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
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.

Yakov responded that this will be added to the -18 review.

Jonathan agreed.

----------------------------------------------------------------------------
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: Consensus
Change: No
Summary: Remove the section entirely, as this is something that does not
  belong in the base spec.

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.

There seems to be general agreement that this section should be removed.

N.B.  This also affects issue 12.

----------------------------------------------------------------------------
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: Consensus
Change: No
Summary: The consensus is that additional references to RFC2385 are not
  necessary.

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.

Yakov replied to this:

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.

Ishi agreed with Yakov.  Jonathan disagreed since he thought no one uses
BGP auth.  Ishi replied that there are lots of people who do use it.
Jonathan replied with a clarification question: "Who uses *BGP's own* 
authentication mechanisms???"  Ron Bonica replied that they use BGP auth.
There was some additional discussion over who implements simple password
authentication vs. MD5.

After further discussion, the consensus seems to be that we should leave
the text as it is for the reasons Yakov pointed out.  There was some
discussion over opening a new issue to discuss deprecating the BGP
auth mechanism discussed in RFC1771 in favor of the mechanism in RFC2385.

The issue of Depricating BGP AUTH is discussed in issue 62.

----------------------------------------------------------------------------
22) Scope of Path Attribute Field
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: This is already being covered by text that has been added to
 the -18 draft.

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

Yakov replied to this that:

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.

There were no objections to this statement, so this issue has been moved
into consensus.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
Summary: 
 Add the following to section 3.1:

   Changing the attributes 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.

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.

Picking this thread up again, Yakov argued:

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.

Jonathan agreed with this statement, but Ben argued that the text in 
section 3 is insufficent the way it is currently written.   After
two iterations, Ben and Yakov agreed on this formulation for an
update to section 3.1:

   Changing the attributes 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.

Jeff objected somewhat to the wording, since, because of a bgp route
is defined as a <path attribute, NLRI> pair, changing either part of
that pair, by definition, changes the route.  He acknowledged that
this might fall under the category of implementation detail.

Yakov presented the view that he thought we were at consensus with the
text he proposed above.  Jonathan agreed.  There were no objections, so
this is moved to Consnesus.

----------------------------------------------------------------------------
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: Consensus
Change: No
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. 

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.

Yakov replied to this that he would suggest we keep things as is, since
the purpose is to document current implementations.

This did not meet with any objections, so this issue has been moved into
consensus.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
Summary:  
  Add:

  "in case they become resolvable" after the last sentence on p. 46.

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"

Yakov responded that:

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.

Yakov also responded that:

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.

Jonathan, who was the original commentor, agreed with both the changed
text and the clarity of section 3.

----------------------------------------------------------------------------
30) Mention Other Message Types
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add a reference to RFC2918 at the end of the type code list.

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.

Yakov replied that:

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.

Jonathan agreed with this change.  This issue has been moved to consensus.

----------------------------------------------------------------------------
31) Add References to Additional Options
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Consensus to add:

   [RFC2842] defines another Optional Parameter.

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.

Yakov replied that:

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.

The original poster agreed with this modification.  This issue is at 
consensus.

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

  This is partly addressed in the 32.1 text with the addition of a RFC904
  reference to EGP ORIGIN type.

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

Yakov replied that an EGP reference will be added (see issue 9).

Yakov also stated that he doesn't see what is wrong with the current text,
and suggsted we keep it.  This includes leaving out any reference to the
status of the EGP spec.  He sees that it is clear from context that we
are talking about "the EGP" [RFC904].

----------------------------------------------------------------------------
32.1) EGP ORIGIN Clarification
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: 
 Change section 5.1.1.  Text is still being worked out.

   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.

 Consensus 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]


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.

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.

After some further discussion, we have this text on the table:

   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.

Jonathan suggested that we change "propagate this information" to
"forward this route".  He also mentioned that he would prefer something
more explicit instead of/in addition to "The attribute shall be included
in the UPDATE messages of all BGP speakers that choose to propagate this
information to other BGP speakers." such as "other speakers do not
change the ORIGIN value."

On the issue of making the EGP ORIGIN type more clear Andrew proposed:

 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.

This met with a number of agreements.

On the second text section we are working on, Jonathan objected to the
current working text below and suggested an alternate:

CHANGE:

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

TO:

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

-or-

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

Jonathan cited a recent example of someone who was still confused by this
section of the text in -17 (not specifically the working text).


----------------------------------------------------------------------------
32.2) BGP Desitnation-based Forwarding Paradigm
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: After much discussion, this is the consensus:
 This text in the current draft:

     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.

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: Consensus
Change: Yes
Summary: Add "Optional Non-Transitive" to MED Section
         Add "well-known mandatory" to the NEXT_HOP Section

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.

Yakov agreed to make this change in -18.

Jonathan replied that:

5.1.3 NEXT_HOP also, it is missing " well-known mandatory".

Yakov also agreed to make this change.

----------------------------------------------------------------------------
34) Timer & Counter Definition
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: No discussion, no text proposed, defaults to consensus for
  no change.

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.

There has been no further discussion on this issue.  Unless it is
brought up again, this issue is in consensus, with no change.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
Summary: This change requires a glossary. Yakov has committed to having
 a section where commonly used terms are defined in draft 18, so this
 issue is at consensus.

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.

Yakov replied:

will be added to the section "Definition of commonly used terms" in -18
version.

----------------------------------------------------------------------------
37) Combine "Unfeasible Routes" and "Withdrawn Routes"
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add the following terms to the "commonly used terms section":

   Feasible route
    A route that is available for use.

   Unfeasible route
    A previously advertised feasible route that is no longer available
    for use.

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.
 
Ishi replied to this that he thought that we could combine the two terms,
since there is limited difference from an implementation standpoint.

Yakov replied:

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.

Ishi replied that he was convinved, and that the terms should stay
seperate.

Andrew asked the list if we should define these terms in the "commonly
used terms" section in draft -18.

Ben replied that if we use them alot, we should define them, and if not
local definitions will suffice.

There was some back and forth about the necessity of defining terms which
should be obvious. 

mrr actually checked the doc to see if we were consistantly using the 
terms, and found:

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:

After some further off-list discussion, mrr agreed that this inconsistancy
is extremely minor, and withdrew his comment.  feasible and unfeasible
route will be defined in the "commonly used terms" section to clear
up any confusion.

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

Yakov agreed to drop the third and fourth parentheses in the -18 version.

Jonathan replied to this:

Disagree, the text if fine the way it is, except you need to change
"shorted" to "shorter".

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

There was some additonal discussion on this point.  Most of it was along
the lines of extracting what was really implemented and supported among
various vendors.  The conclusion was the same.

----------------------------------------------------------------------------
41) Mention FSM Internal Timers
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: No discussion on this issue.  No text proposed.  Perhaps this is
  in the FSM section of the draft?  Either way, it defaults to consensus
  with no change.

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.

There has been no discussion on this, it now defaults to consensus with
no change.

----------------------------------------------------------------------------
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: Consensus
Change: No
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.  They were later reminded that the base
  behavior is acceptable, and agreed.

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.

Yakov replied to this with:

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.

The original poster, Jonathan, agreed with this.  This issue moves to
consensus.

----------------------------------------------------------------------------
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: Consensus
Change: No
Summary: A desire for explicit state change wording was expressed.  No
  text was proposed.  The assumption is that this issue has reached a
  happy conclusion.

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.

There has been no further discussion on this.  The assumption is that
is has reached a happy conclusion privately.

----------------------------------------------------------------------------
48) Explicitly Define Processing of Incomming Connections
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Text has been proposed to describe the general process of 
 a BGP connection comming up.

Discussion:

Alex suggsted we explicity define:

   - processing of incoming TCP connections (peer lookup, acceptance,
     FSM creation, collision control,)

Curtis later proposed this text:

  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.

Jonathan pointed out that there was an inaccuracy in the proposed text.
Curtis replied with this:

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.

Tom replied that:

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

And Curtis suggested that:

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.

Tom agreed with Curtis, that he liked the "will attempt to connect unless 
configured otherwise" verbiage.

This was discussed in the "Generial Editorial Comment" thread.

----------------------------------------------------------------------------
49) Explicity Define Event Generation
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Suggested that we explictiy define BGP message processing. No text
  proposed.  There has been no further discussion on this issue, it
  is assumed that the consensus is that things are ok the way they are.

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 discussion has received no further comment.  Unless someone wants
to reopen it, it is assumed it has reached a happy ending.

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: Consensus
Change: Yes
Summary: 
 Replace:

   Path segment length is a 1-octet long field containing
   the number of ASs in the path segment value field.

 With:
 
   Path segment length is a 1-octet long field containing
   the number of ASs (not the number of octets) in the path
   segment value field.

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.

Yakov proposed this change:

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.

Jonathan offered this text:

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

Jeff replied that he prefered Yakov's text, but without the "but".  Yakov
agreed to that.  Andrew also agreed, and asked if there were any objections
to moving this issue into consensus.  There were no objections.

----------------------------------------------------------------------------
56) Section 6 - BGP Error Handling
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: There are a variety of updates to the text that are best described
 in the discussion section.

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

There have been no objections to the updates listed above.  This issue
seems to have reached a happy ending, so it has been moved into 
consensus.

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: After some discussion, it would seem that the group is converging
 on an opinion that ATOMIC_AGGREGATE should be moved to an informational
 status.

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.

Yakov responded to this, saying that he thought these changes were 
reasonable, and unless there were objections, they would be adopted.

Ishi strongly agreed with the changes.

Curtis stated that:

 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.

 And suggested that we remove the MUSTs and indicated that this is only
 informational.

Jeff replied that:

 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.

Jonathan agreed with Curtis' idea that we should just move ATOMIC_AGGREGATE
to informational.

Curtis proposed this text:

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

Yakov was fine with this text.

So at this point we're trying to achieve consensus with the text Curtis
has proposed.

----------------------------------------------------------------------------
59) Section 4.3 - Move text 
----------------------------------------------------------------------------
Status: Consensus
Change: Yes (minimal)
Summary: Update indentation to allow a new "subsection" heading. Otherwise
 no change.

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.

Yakov agreed to update the indentation.

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. 

After Yakov's response and a posting to the list asking that this be moved
to consensus, there were no objections, so this is moved to 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.

Issue 14 closed in favor of this issue.

In response to Yakov's call for input, Michael responded that:

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 (text is above.)

----------------------------------------------------------------------------
62) Deprecate BGP Authentication Optional Parameter from RFC1771
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: We are at consensus, in that we agree that we should deprecate
 the BGP Authentication Optional Parameter as described in RFC1771 in
 favor of the mechanism described in RFC2385.  The textual changes are 
 listed at the end of the discussion section of this issue.

Discussion:

This discussion started in issue 21: Authentication Text Update.

This topic has come up before (July timeframe), but was recently refreshed
in the context of issue 21.  It began with some questions to the list
as to who used what sort of authentication mechanisms.  From the
responses it was clear that MD5 (RFC2385) was the prefered method.

Eric Gray's message helps to flesh this out:

        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

To this Yakov responded:

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.

There have been no responses to Yakov's question.

There seems to be a consensus that, since it is little used, and since
there are better mechanisms, namely MD5 authentication, we should 
deprecate the BGP Authentication Optional Parameter from RFC1771.

Ok, after some disucssion, this is a list of the text that we are
adding, changing or removing:

1) Remove the reference to the authentication optional parameter:

I would suggest to remove the following text from the draft:

         This document defines the following Optional Parameters:
  
         a) Authentication Information (Parameter Type 1):


            This optional parameter may be used to authenticate a BGP
            peer. The Parameter Value field contains a 1-octet
            Authentication Code followed by a variable length
            Authentication Data.

                0 1 2 3 4 5 6 7 8   
                +-+-+-+-+-+-+-+-+
                |  Auth. Code   |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |                                                     |
                |              Authentication Data                    |
                |                                                     |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Authentication Code:
   
                  This 1-octet unsigned integer indicates the
                  authentication mechanism being used. Whenever an
                  authentication mechanism is specified for use within
                  BGP, three things must be included in the
                  specification:
   
                  - the value of the Authentication Code which indicates
                  use of the mechanism,
                  - the form and meaning of the Authentication Data, and
                  - the algorithm for computing values of Marker fields.

                  Note that a separate authentication mechanism may be
                  used in establishing the transport level connection.

               Authentication Data:

                  Authentication Data is a variable length field that is
                  interpreted according to the value of the   
                  Authentication Code field.

2) Update the introduction:

In section 2 (Introduction), sixth paragraph

 From:

   BGP runs over a reliable transport protocol. This eliminates the
   need to implement explicit update fragmentation, retransmission,
   acknowledgment, and sequencing. Any authentication scheme used by the
   transport protocol (e.g., RFC2385 [10]) may be used in addition to
   BGP's own authentication mechanisms. The error notification mechanism
   used in BGP assumes that the transport protocol supports a "graceful"
   close, i.e., that all outstanding data will be delivered before the
   connection is closed.

 To:

   BGP uses TCP [RFC793] as its transport protocol. This eliminates
   the need to implement explicit update fragmentation, retransmission,
   acknowledgment, and sequencing. BGP listens on TCP port 179. Any
   authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may be
   used. The error notification mechanism used in BGP assumes that TCP
   supports a "graceful" close, i.e., that all outstanding data will
   be delivered before the connection is closed.   

3) Update the message header format section:

 From:

     Marker:

         This 16-octet field contains a value that the receiver of the
         message can predict.  If the Type of the message is OPEN, or if
         the OPEN message carries no Authentication Information (as an
         Optional Parameter), then the Marker must be all ones.
         Otherwise, the value of the marker can be predicted by some a
         computation specified as part of the authentication mechanism
         (which is specified as part of the Authentication Information)
         used.  The Marker can be used to detect loss of synchronization
         between a pair of BGP peers, and to authenticate incoming BGP
         messages.
   
  To:
   
     Marker:
   
         This 16-octet field is included for compatibility; it must be  
         set to all ones.

4) Update the Message Header error handling section:

In section 6.1 (Message Header error handling), second paragraph

 From:

   The expected value of the Marker field of the message header is all
   ones if the message type is OPEN.  The expected value of the Marker
   field for all other types of BGP messages determined based on the
   presence of the Authentication Information Optional Parameter in the
   BGP OPEN message and the actual authentication mechanism (if the  
   Authentication Information in the BGP OPEN message is present). If
   the Marker field of the message header is not the expected one, then
   a synchronization error has occurred and the Error Subcode is set to
   Connection Not Synchronized.

 To:
     
   The expected value of the Marker field of the message header is all
   ones. If the Marker field of the message header is not as expected,
   then a synchronization error has occurred and the Error Subcode is   
   set to Connection Not Synchronized.

5) Remove a paragraph from the OPEN mesage error handling section
   (section 6.2):

   If the OPEN message carries Authentication Information (as an
   Optional Parameter), then the corresponding authentication procedure 
   is invoked.  If the authentication procedure (based on Authentication
   Code and Authentication Data) fails, then the Error Subcode is set to
   Authentication Failure.

6) Update the "Differences from RFC1771 Appendix" 

   Text not listed here

7) Fix the hole in the numbering by updating:

 From: 

   This document defines the following Optional Parameters:

   a) Authentication Information (Parameter Type 1):

 To:

   This document defines the following Optional Parameters:

   a) Optional parameter type 1, Authentication Information, 
      has been deprecated.

We are at consensus with these changes.

----------------------------------------------------------------------------
63) Clarify MED Removal Text
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: What behavior should we specify for an absent MED?

Discussion:

This discussion began when Jonathan posted a question to the list:

In reference to:

"A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
 which allows the MULTI_EXIT_DISC attribute to be removed from a
 route"

 Does anybody know how this can be done in IOS???  Looks like it cannot.

 Juniper???

 Other code???

 Change to "SHOULD"???

Enke responded that:

As the MED value is treated as zero when the MED attribute is missing,
removing the MED attribute is really equivalent to setting the value to
zero. Based on this logic, one can argue that "MED removal" is supported
by multiple vendors.
 
However, I do see that the current text can be consolidated and cleaned up:
 
------------------------
5.1.4 MULTI_EXIT_DISC

   ...
      
   A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
   which allows the MULTI_EXIT_DISC attribute to be removed from a
   route. This MAY be done prior to determining the degree of preference
   of the route and performing route selection (decision process phases
   1 and 2).
 
   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over an external
   link.  If it does so, it shall do so prior to determining the degree
   of preference of the route and performing route selection (decision
   process phases 1 and 2).

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

How about this:

   A BGP speaker MUST implement a mechanism based on local configuration
   which allows the value of MULTI_EXIT_DISC attribute of a received route  
   to be altered. This shall be done prior to determining the degree of
   preference of the route and performing route selection (decision process
   phases 1 and 2).

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

In responding to a question, Enke also added:

> Humm. I thought with a missing MED it was prefereable to be treated as
> worst not as 0.

It was changed a long time ago. Please see the following text in
Sect. 9.1.2.2 of the draft:
 
      In the pseudo-code above, MED(n) is a function which returns the
      value of route n's MULTI_EXIT_DISC attribute. If route n has no
      MULTI_EXIT_DISC attribute, the function returns the lowest
      possible MULTI_EXIT_DISC value, i.e. 0.

Curtis replied to Enke:

If Juniper treats missing MULTI_EXIT_DISC as worst and Cisco has a
knob to treat missing MULTI_EXIT_DISC as worst, then IMHO we should
change the spec to say that MED(n) returns the largest value possible
is MULTI_EXIT_DISC is missing since this has better loop suppression
bahaviour if the placement of MULTI_EXIT_DISC removal is moved in its
position in the flow from Adj-In-RIB to Loc-RIB to Adj-Rib-Out.  In
other words, no matter where the removal takes place, we are loop free
without special rules about comparing EBGP before MED removal and then
IBGP after MED removal.  The only argument for MED(n) going to zero
for missing MULTI_EXIT_DISC was that Cisco routers did that (and
change would pose an operational issue if there wasn't a knob to
facilitate the change).
   
Note that when explicitly jamming a MULTI_EXIT_DISC value, such as
zero, the issue of where in the decision process the MULTI_EXIT_DISC
learned from the EBGP peers could still be used becomes a concern
again.  Unfortunately these implementation hints are necessary to 
remain loop free and so its hard to declare them out of scope, unless
we forbid changing MULTI_EXIT_DISC and just allow it to be removed
(which does not reflect current practice).

Curtis also added:

The other issue was MED handling.  In "5.1.4 MULTI_EXIT_DISC":

   A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
   which allows the MULTI_EXIT_DISC attribute to be removed from a
   route. This MAY be done prior to determining the degree of preference
   of the route and performing route selection (decision process phases
   1 and 2).

   An implementation MAY also (based on local configuration) alter the  
   value of the MULTI_EXIT_DISC attribute received over an external  
   link.  If it does so, it shall do so prior to determining the degree 
   of preference of the route and performing route selection (decision 
   process phases 1 and 2).

This doesn't sufficiently address the issue.

The MED step in the decision process is (in 9.1.2.2):

      c) Remove from consideration routes with less-preferred
      MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
      between routes learned from the same neighboring AS. Routes which
      do not have the MULTI_EXIT_DISC attribute are considered to have
      the lowest possible MULTI_EXIT_DISC value.

      This is also described in the following procedure:

            for m = all routes still under consideration
                for n = all routes still under consideration
                    if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
                        remove route m from consideration

      In the pseudo-code above, MED(n) is a function which returns the
      value of route n's MULTI_EXIT_DISC attribute. If route n has no
      MULTI_EXIT_DISC attribute, the function returns the lowest
      possible MULTI_EXIT_DISC value, i.e. 0.
   
      Similarly, neighborAS(n) is a function which returns the neighbor
      AS from which the route was received.
   
The problem is that a route loop can be formed.

To avoid the route loop, two suggestions were made (2-3 years ago and   
nothing was done).  One was to make MED(n) return infinity if there  
was no MULTI_EXIT_DISC.  The other was to consider MULTI_EXIT_DISC in   
the decision process only for the purpose of selecting among the EBGP  
peers, then remove MULTI_EXIT_DISC, then use that best route in
comparisons to IBGP learned routes.

The statement in 5.1.4 "This MAY be done prior to determining the
degree of preference of the route and performing route selection
(decision process phases 1 and 2)" does not sufficiently address this.
This implies that you MAY also remove after route selection, in which
case field experience indicates you WILL get burned (unless you know
about the caveat above).  Initially this came up as an
interoperability issue but later it was proven (in the field) that a  
Cisco and another Cisco could form a route loop until Cisco made this
change.
      
Additional wording is needed either in 5.1.4 or in 9.1.2.2.  I suggest
we put a forward reference in 5.1.4:

   [...]. This MAY be done prior to determining the degree of preference
   of the route and performing route selection (decision process phases
   1 and 2).  See section 9.1.2.2 for necessary restricts on this.
      
Then in 9.1.2.2 add a clarificatio to the neighborAS(n) function and 
add to the existing text.

      Similarly, neighborAS(n) is a function which returns the
      neighbor AS from which the route was received.  If the route is  
      learned via IBGP, it is the neighbor AS from which the other
      IBGP speaker learned the route, not the internal AS.

      If a MULTI_EXIT_DISC attribute is removed before redistributing
      a route into IBGP, the MULTI_EXIT_DISC attribute may only be      
      considered in the comparison of EBGP learned routes, them
      removed, then the remaining EBGP learned route may be compared    
      to the remaining IBGP learned routes, without considering the    
      MULTI_EXIT_DISC attribute for those EBGP learned routes whose
      MULTI_EXIT_DISC will be dropped before advertising to IBGP.
      Including the MULTI_EXIT_DISC of an EBGP learned route in the
      comparison with an IBGP learned route, then dropping the
      MULTI_EXIT_DISC and advertising the route has been proven to
      cause route loops.

The loop is the classic I prefer your and you prefer mine problem.  It
occurs when the router is configured to remove MULTI_EXIT_DISC and
advertise out a route so other routers can use IGP cost to select the 
best route.  If two routers do this, as soon as they hear the route  
with no MULTI_EXIT_DISC from the other peer they start forwarding
toward that peer but they continue to advertise to it since others
IBPG peers are expected to select among the MULTI_EXIT_DISC free IBGP 
learned routes using the next step in the decision process, IGP cost.

In this case, what you want is each router to prefer its own EBGP
route, even though it has a MULTI_EXIT_DISC and the IBGP learned route 
from the same neighbor AS has had its MULTI_EXIT_DISC stripped off (or
didn't have one, you can't tell which it is).  You then want all of
the IBGP peers with a MULTI_EXIT_DISC free route from that AS, or that
have stripped the MULTI_EXIT_DISC to form one, to advertise them.
Others in the AS will then use IGP cost to further resolve which exit
point to use.  It make a difference when the route is the aggregate
route of another major provider.  IGP cost yields what ISPs call "hot  
potatoe routing" and MED selects among multiple heavily loaded
provider interconnects.

[Aside: Having a missing MULTI_EXIT_DISC default to infinity would do
exactly what the ISPs want it to do in the first place and be a lot     
easier to explain but we didn't fix that 2-3 years ago when the issue
came up even though we had WG consensus that it was the right thing to  
do.  The authors didn't act on it at the time (because Cisco didn't do 
it that way and the authors preferred to sit on the draft).  At this
point we might as well adequately document what we ended up with....
End of soapbox.  I don't take myself all that seriously so others  
shouldn't either.  :-)]

----------------------------------------------------------------------------
64) MED for Originated Routes
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: The consensus is that there is not need to specify default
  values for MED in the base draft.

Discussion:

This issue began when it was pointed out that we do not specify the
default values for MED in the base draft.

There were a variety of responses, but the consensus is that since 
this is not relevant for interoperability, this does not need to be
in the base spec.

----------------------------------------------------------------------------
65) Rules for Aggregating with MED and NEXT_HOP
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Do we change the rules for aggregating routes with different
  MED's and NEXT_HOPs?

Discussion:

There is a proposal to relax this statement:

"Routes that have the following attributes shall not be aggregated
   unless the corresponding attributes of each route are identical:
   MULTI_EXIT_DISC, NEXT_HOP."

In his reply to the original mail, Curtis asserted that we should leave
the MED rules alone, but perhaps we could relax the NEXT_HOP statement.

This was revisited in the "aggregating with MED and NEXT_HOP" thread.

There is no consensus.

----------------------------------------------------------------------------
66) Complex AS Path Aggregating
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Do we remove a section of the spec that has to do with an aggregation
  scheme that is rarely used?

Discussion:

Jonathan opened this discussion with:

The part in the draft about complex AS path aggregation could/should be
deleted.  The current draft implies that when aggregating, for example
(1st):

1 2 4 3

w/

3 4 6 5

and

5 6 7 8

then

1 2 {3 4 5 6} 7 8

...would be OK

AFAIK, all implementations aggregate by either: (2nd)putting ONLY the local
AS in the path (and setting the atomic) OR (3rd)by creating 1 giant set and
adding the local AS as a seq.

So he proposed we remove this to reflect current code.

Jeff replied that there is absolutely nothing wrong with doing complex
aggregation, and there is no reason to remove this from the specification.

----------------------------------------------------------------------------
67) Counting AS_SET/AS_CONFED_*
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: Is how we count AS_SET/AS_CONFED_* covered suffiecently in the
  current draft?

Discussion:

Jonathan brought up some questions on how current implementations count
AS_SET and AS_CONFED_*

There were a variety of resposnes to this, answering his questions.
Curtis pointed out that this behavior is covered in:

That's in 9.1.2.2:

      a) Remove from consideration all routes which are not tied for
      having the smallest number of AS numbers present in their AS_PATH
      attributes. Note, that when counting this number, an AS_SET counts
      as 1, no matter how many ASs are in the set, and that, if the
      implementation supports [13], then AS numbers present in segments
      of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in
      the count of AS numbers present in the AS_PATH.

Jonathan replied that this might be at odds with what Juniper does,
although he was unsure, and asked for clarification.

This was discussed in the "New Issue AS path" thread.

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

CHANGELOG

----------------------------------------------------------------------------
v1.2 to v1.3
2002-10-16
----------------------------------------------------------------------------

Added:

64) MED for Originated Routes
65) Rules for Aggregating with MED and NEXT_HOP
66) Complex AS Path Aggregating
67) Counting AS_SET/AS_CONFED_*
List of issues that are NOT at consensus

Updated:

8) Jitter Text
10) Extending AS_PATH Attribute
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
19) Appendix Section 6.2: Processing Messages on a Stream Protocol
32.1) EGP ORIGIN Clarification
34) Timer & Counter Definition
37) Combine "Unfeasible Routes" and "Withdrawn Routes"
41) Mention FSM Internal Timers
47) FSM - Add Explicit State Change Wording
49) Explicity Define Event Generation
62) Deprecate BGP Authentication Optional Parameter from RFC1771

Moved FROM Consensus:

11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2

Moved to Consensus:

10) Extending AS_PATH Attribute
19) Appendix Section 6.2: Processing Messages on a Stream Protocol
34) Timer & Counter Definition
37) Combine "Unfeasible Routes" and "Withdrawn Routes"
41) Mention FSM Internal Timers
47) FSM - Add Explicit State Change Wording
49) Explicity Define Event Generation
62) Deprecate BGP Authentication Optional Parameter from RFC1771

----------------------------------------------------------------------------
v1.2 to v1.2.1
2002-10-01
----------------------------------------------------------------------------

Updated:

11.3) Documenting IBGP Multipath
24) Addition or Deletion of Path Attributes
63) Clarify MED Removal Text
TOC) Added issues 62 and 63 to the table of contents.

Moved to Consensus:
24) Addition or Deletion of Path Attributes

----------------------------------------------------------------------------
v1.1.1 to v1.2
2002-10-01
----------------------------------------------------------------------------

Added:
11.3) Documenting IBGP Multipath
62) Deprecate BGP Authentication Optional Parameter from RFC1771
63) Clarify MED Removal Text

Updated:

1) IDR WG Charter
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
13) Next Hop for Originated Route
14) NEXT_HOP to Internal Peer
17) Add References to other RFC-status BGP docs to base spec.
21) Authentication Text Update
22) Scope of Path Attribute Field
24) Addition or Deletion of Path Attributes
27) Allow All Non-Destructive Messages to Refresh Hold Timer
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
36) Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary
37) Combine "Unfeasable Routes" and "Withdrawn Routes"
39) Redundant Sentance Fragments
40) Section 9.2.1.1 - Per Peer vs. Per Router MinRouteAdvertisementInterval
44) Section 6.2: OPEN message error handling
48) Explicitly Define Processing of Incomming Connections
55) Section 4.3 - Description of AS_PATH length
56) Section 6 - BGP Error Handling
58) Deprication of ATOMIC_AGGREGATE
59) Section 4.3 - Move text
61) Next Hop for Redistributed Routes
62) Deprecate BGP Authentication Optional Parameter from RFC1771
63) Clarify MED Removal Text

Moved to Consensus:

9) Reference to RFC904 - EGP Protocol
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
14) NEXT_HOP to Internal Peer (closed in favor of issue 61)
17) Add References to other RFC-status BGP docs to base spec.
21) Authentication Text Update
22) Scope of Path Attribute Field
27) Allow All Non-Destructive Messages to Refresh Hold Timer
29) State Why Unresolveable Routes Should Be Kept in Adj-RIB-In
30) Mention Other Message Types
31) Add References to Additional Options
32.2) BGP Desitnation-based Forwarding Paradigm
33) Add "Optional Non-Transitive" to the MED Section
36) Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary
44) Section 6.2: OPEN message error handling
55) Section 4.3 - Description of AS_PATH length
56) Section 6 - BGP Error Handling
59) Section 4.3 - Move text

----------------------------------------------------------------------------
v1.1 to v1.1.1
2002-09-24
----------------------------------------------------------------------------

Updated:

5) Direct EBGP Peers
   Added the "consensus" line in the actual issue description.
TOC) Added issue 61 to the table-of-contents.

----------------------------------------------------------------------------
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 Sectioules for Aggregating with MED and NEXT_HOP


--RASg3xLB4tUQ4RcS--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA08414 for <[e-mail]>; Wed, 16 Oct 2002 13:16:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 87F0D91286; Wed, 16 Oct 2002 13:16:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4940391287; Wed, 16 Oct 2002 13:16: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 DC71991286 for <[e-mail]>; Wed, 16 Oct 2002 13:16:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A1EE35DDCB; Wed, 16 Oct 2002 13:16: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 0DFEC5DDBF for <[e-mail]>; Wed, 16 Oct 2002 13:16:20 -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 g9GHGJm25275; Wed, 16 Oct 2002 10:16:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id g9GHGJK09161; Wed, 16 Oct 2002 10:16:19 -0700 (PDT) (envelope-from roque)
Date: Wed, 16 Oct 2002 10:16:19 -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: Nicolas REBIERRE <[e-mail]>
Cc: [e-mail], christophe preguica <[e-mail]>
Subject: IPv6 link-local address added as NH
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: [e-mail]
Precedence: bulk

Nicolas REBIERRE writes:

> Hi all, I do not understand why is it necessary to add a link-local
> address on the NH in some cases as specified in the RFC 2545 "MP-BGP
> for IPv6".  What is the difference between adding a route with a ll@
> as next hop in the Routing database and adding one with a global
> address as NH ?

If you have a multi-access interface, ipv6 implicitly requires you to
install routes with a link-local address nexthop. This because, if
hosts are present on the same link, you might need to send an icmp
redirect message, which may only be sent in terms of a link local
address.

Since in BGP you don't want to know what are the characteristics of the
link, the link-local address is exchanged between directly connected
peers regardless of the link type.

regards,
  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 JAA24534 for <[e-mail]>; Wed, 16 Oct 2002 09:01:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0070791279; Wed, 16 Oct 2002 09:01:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C85989127A; Wed, 16 Oct 2002 09:01: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 7F63791279 for <[e-mail]>; Wed, 16 Oct 2002 09:01:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 239B75DFFE; Wed, 16 Oct 2002 09:00:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: from smail2.alcatel.fr (colt-na6.alcatel.fr [62.23.212.6]) by segue.merit.edu (Postfix) with ESMTP id 41C2E5DFF7 for <[e-mail]>; Wed, 16 Oct 2002 09:00:52 -0400 (EDT)
Received: from nmu.alcatel.fr (tcmh80.nmu.alcatel.fr [139.54.143.3]) by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id g9GD0oWJ014997 for <[e-mail]>; Wed, 16 Oct 2002 15:00:50 +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 OAA10918; Wed, 16 Oct 2002 14:59:30 +0200 (METDST)
Message-ID: <[e-mail]>
Date: Wed, 16 Oct 2002 14:55:39 +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], christophe preguica <[e-mail]>
Subject: IPv6 link-local address added as NH
Content-Type: multipart/mixed; boundary="------------3E41AD91B7B34532097C3DA4"
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.
--------------3E41AD91B7B34532097C3DA4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

I do not understand why is it necessary to add a link-local address on
the NH in some cases as specified in the RFC 2545 "MP-BGP for IPv6".
What is the difference between adding a route with a ll@ as next hop in
the Routing database and adding one with a global address as NH ?

Thanks,

Christophe.

[Please note I'm posting this mail on behalf of Christophe, whose posts
seem not to appear on the mailing list.]

--------------3E41AD91B7B34532097C3DA4
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

--------------3E41AD91B7B34532097C3DA4--



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA13657 for <[e-mail]>; Wed, 16 Oct 2002 03:32:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C89F491270; Wed, 16 Oct 2002 03:31:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F66B91271; Wed, 16 Oct 2002 03:31: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 202A991270 for <[e-mail]>; Wed, 16 Oct 2002 03:31:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0AF825DF50; Wed, 16 Oct 2002 03:31:22 -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 9B9215DE30 for <[e-mail]>; Wed, 16 Oct 2002 03:31:21 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id AAA08061; Wed, 16 Oct 2002 00:28:17 -0700 (PDT)
Date: Wed, 16 Oct 2002 00:28:17 -0700
From: [e-mail]
To: [e-mail]
Cc: "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: issue 11.2
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, Oct 02, 2002 at 11:56:36AM -0400
Sender: [e-mail]
Precedence: bulk

Jonathan,

Thank you for pointing out that this issue did not get resolved.

Curtis,

It sounds like you hit the nail on the head here.  To reiterate, we have
3 options:

  1.  Omit it (the implied consensus of the rewrite of the paragraph
      in 32.2).

  2.  Leave it as is and put it in another paragraph to separate it
      from the destination based routing statement.

  3.  Clean up the wording and put it in another paragraph to separate
      it from the destination based routing statement.

We now need to decide on which one we want to do.

I've updated the issue list, and reopened this issue.  A slew of possible
texts have flown about, and I have left them out of the issue list since
they complicate the discussion, until we decide which option we are going
to pursue.

Andrew


On Wed, Oct 02, 2002 at 11:56:36AM -0400, Curtis Villamizar wrote:
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> Delivered-To: [e-mail]
> To: "Natale, Jonathan" <[e-mail]>
> Cc: [e-mail]
> Reply-To: [e-mail]
> Subject: issue 11.2 (was Re: Active Route)
> In-reply-to: Your message of "Wed, 02 Oct 2002 10:19:49 EDT."
>              <[e-mail]> 
> Date: Wed, 02 Oct 2002 11:56:36 -0400
> From: Curtis Villamizar <[e-mail]>
> Precedence: bulk
> X-OriginalArrivalTime: 02 Oct 2002 15:59:36.0421 (UTC) FILETIME=[B4CCA150:01C26A2C]
> 
> 
> In message <[e-mail]
> ks.com>, "Natale, Jonathan" writes:
> > Folks,
> > 
> > This issue seems to have been convoluted into issue 32.2.  I am in agreement
> > with 32.2 (other than style/conciseness--I think it is a little long winded,
> > but I can live with it), but it is not what I raised.  
> > 
> > The issue I raised, and would like to be [re-]considered is with:
> > 
> > "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."
> 
> 
> That is called route orgination and it is allowed by:
> 
>   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.
>    [...]  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.
> 
> Advice on what to put in the AS_PATH and NEXT_HOP is in the document.
> 
> > This means that if the speaker's routing table has a non-bgp route to a
> > destination but does not have bgp route to the same destination (for
> > example, based on administrative distance), then the speaker may not
> > advertise that route to it's peers. This is true on Juniper by default for
> > EBGP, but is NOT TRUE [ever?] on Juniper for IBGP, and is NOT TRUE on
> > Juniper if ~= "advertise inactive" is enabled.  This is NOT TRUE ever on
> > Cisco.
> 
>    [...]  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.
> 
> > Now we are proposing that the quoted clause above be completely removed.
> > This means that it will be allowable to advertise a route to a destination
> > that is not locally reachable.  This is obviously (to me, but not to all--
> > which is why it should not be removed) bad. 
> > 
> > Thank you.
> 
> In the summary, one of the entries is incorrect:
> 
>   11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
> 
>   ...
> 
>   Since this issue and issue 32.2 are very similar, and 32.2 is at consensus,
>   this issue has also been moved to consensus in favor of 32.2.
> 
> These are not the same so the entry in Andrews summary is wrong.
> 
> We never reached full consensus on 11.2 but seemed to have more
> support for either 1) leaving it as, 2) take it out.  There were some
> semantic arguments about what it meant to "use" a route with a few
> people offering an interpretation of "use" that would make the
> statement false under some conditions.
> 
> I suggest that we change 11.2 and return it to "no consensus".
> 
> The edit to change the same paragraph in 32.2 was to reflect the
> intent of the paragraph to indicate that BGP supports destination
> based routing and not some form of source specified routing.
> 
> I don't think there was ever consensus on what to do with the
> statement "a BGP speaker advertises to its peers (other BGP speakers
> which it communicates with) in neighboring ASs only those routes that
> it itself uses".  Some reasonable choices are:
> 
>   1.  Omit it (the implied consensus of the rewrite of the paragraph
>       in 32.2).
> 
>   2.  Leave it as is and put it in another paragraph to separate it
>       from the destination based routing statement.
> 
>   3.  Clean up the wording and put it in another paragraph to separate
>       it from the destination based routing statement.
> 
> The separate paragraph for 2 would be the exact sentence we now have.
> 
>    A BGP speaker advertises to its peers (other BGP speakers which it
>    communicates with) in neighboring ASs only those routes that it
>    itself uses.
> 
> In possibility 3 we (try to) clear up the ambiguity about the meaning
> of the word "use" in this sentence.
> 
>    A BGP speaker advertises to its peers (other BGP speakers which it
>    communicates with) in neighboring ASs only those routes that it
>    itself uses.  In this context a BGP speaker is said to "use" a BGP
>    route if it is the most preferred BGP route and is either directly
>    used in forwarding or in a specifically configured case where the
>    BGP route would be forwarded internally but IGP forwarding
>    information is used.  The latter case reflects a usage in which the
>    IGP is used for forwarding but BGP is originated to IBGP to carry
>    attributes that cannot be carried by the IGP (for example, BGP
>    communities [N]).  Other special cases such as virtual routers and
>    multiple instances of BGP on a single router are beyond the scope
>    of this document but for each of these the statement "a BGP speaker
>    advertises to its peers (other BGP speakers which it communicates
>    with) in neighboring ASs only those routes that it itself uses" can
>    (and should in the definition of the extension) be made true with
>    an appropriate definition of the word "use".
> 
> Unless someone volunteers better wording this may be a good starting
> point.  I thing the last sentence borders on ridiculous in a protocol
> spec but may be necessary to address specific objections raised on
> this mailing list.  If we want to elaborate on the meaning of the word
> "use" and address the objections this is what we end up with.
> 
> Of course looking at what we ended up with, I'd also go along with the
> other two options (leave it out or put the one sentence in a separate
> paragraph as is).
> 
> 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 FAA29022 for <[e-mail]>; Tue, 15 Oct 2002 05:47:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0A79391247; Tue, 15 Oct 2002 05:47:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C42CA91249; Tue, 15 Oct 2002 05:47: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 4058A91247 for <[e-mail]>; Tue, 15 Oct 2002 05:47:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1A5225DF59; Tue, 15 Oct 2002 05:47:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from mta0 (unknown [61.144.161.10]) by segue.merit.edu (Postfix) with ESMTP id 397BA5DF52 for <[e-mail]>; Tue, 15 Oct 2002 05:47:15 -0400 (EDT)
Received: from l04955 (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]; Tue, 15 Oct 2002 17:41:17 +0800 (CST)
Date: Tue, 15 Oct 2002 17:43:15 +0800
From: lidefeng <[e-mail]>
Subject: Re: agenda for the IDR WG meeting
To: Yakov Rekhter <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], "Fu Y. Miao" <[e-mail]>, [e-mail]
Message-id: <000c01c2742f$4942e180$[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

Hi,all,

In draft-chunzhe-idr-protection-md5-00.txt, a better mechanism to protect
BGP session is presented, and in September mail-list discussion, Pedro Roque
Marques(Juniper Networks) and John G.Scudder(Cisco System) presented some
arguements respectively,and we gave the interpretations corresponding to
their arguements and with no results arrived. IMH,this draft is worthwhile
to discuss at the Atlanta meeting. We hope you can highlight on this draft
and the relevant problem.

Thanks and Regards

Defeng Li



----- Original Message -----
From: "Yakov Rekhter" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Tuesday, October 15, 2002 2:52 AM
Subject: agenda for the IDR WG meeting


> Folks,
>
> It is time to start setting the agenda for the Atlanta meeting.
> If you want to discuss issues with drafts at the Atlanta meeting
> please request a slot to do so, by sending mail to the wg chairs.
>
> 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 OAA28933 for <[e-mail]>; Mon, 14 Oct 2002 14:52:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id AA50D9120C; Mon, 14 Oct 2002 14:52:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A1E591241; Mon, 14 Oct 2002 14:52: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 455AB9120C for <[e-mail]>; Mon, 14 Oct 2002 14:52:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 290F45DF0E; Mon, 14 Oct 2002 14:52: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 8D5DD5DF0B for <[e-mail]>; Mon, 14 Oct 2002 14:52: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 g9EIqSm56653; Mon, 14 Oct 2002 11:52:28 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: agenda for the IDR WG meeting
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 14 Oct 2002 11:52:28 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

It is time to start setting the agenda for the Atlanta meeting.
If you want to discuss issues with drafts at the Atlanta meeting
please request a slot to do so, by sending mail to the wg chairs.

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 FAA21305 for <[e-mail]>; Wed, 9 Oct 2002 05:21:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BF493912CF; Wed,  9 Oct 2002 05:21:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88A39912D0; Wed,  9 Oct 2002 05:21: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 4600C912CF for <[e-mail]>; Wed,  9 Oct 2002 05:21:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2A83B5E0B9; Wed,  9 Oct 2002 05:21:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by segue.merit.edu (Postfix) with ESMTP id C7BE85DDCE for <[e-mail]>; Wed,  9 Oct 2002 05:21:13 -0400 (EDT)
Received: from m2vwall2 (m2vwall2.wipro.com [164.164.29.236]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g999L1209679 for <[e-mail]>; Wed, 9 Oct 2002 14:51:01 +0530 (IST)
Received: from blr-m1-bh1.wipro.com ([10.115.50.91]) by ace.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id H3PJAU01.HHR; Wed, 9 Oct 2002 14:50:55 +0530 
Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 9 Oct 2002 14:50:54 +0530
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-a264d77e-dfc0-4a04-af00-5b68f030c23a"
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Subject: RE: draft-ietf-idr-restart-05.txt
Date: Wed, 9 Oct 2002 14:50:54 +0530
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-idr-restart-05.txt
Thread-Index: AcJvYbaSFNrlRZ88QZOkLvGX6fpvzwAEvNhQ
From: "Shankar" <[e-mail]>
To: "Manav Bhatia" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 09 Oct 2002 09:20:54.0882 (UTC) FILETIME=[2B57B420:01C26F75]
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPartTM-000-a264d77e-dfc0-4a04-af00-5b68f030c23a
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
  IMHO, this is to address the route-flapping issues in BGP. The =
forwarding
Plane is not disturbed, i.e.. the data traffic is not disturbed when BGP =
restarts.=20
Hence the restart is only in the control plane and not in the data =
plane.

Regds
Shankar K A


Hi,
I have a question regarding the graceful restart capability in BGP. In =
the
draft-ietf-idr-restart-05.txt it doesn't talk anything about the =
forwarding
plane.

The draft just talks about what is applicable when the BGP restarts. Why
doesn't it explicitly say anything about forwarding plane and control =
plane
as in OSPF draft? Does it mean that even if forwarding plane goes down =
also
this is applicable? Can somebody please throw some light on this issue.

Is it a mandatory requirement to have your forwarding plane up, when =
your
BGP restarts?

Am I missing something?

Regards,
Manav


------=_NextPartTM-000-a264d77e-dfc0-4a04-af00-5b68f030c23a
Content-Type: text/plain;
	name="Wipro_Disclaimer.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="Wipro_Disclaimer.txt"

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

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

------=_NextPartTM-000-a264d77e-dfc0-4a04-af00-5b68f030c23a--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA16603 for <[e-mail]>; Wed, 9 Oct 2002 03:01:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DFC87912CB; Wed,  9 Oct 2002 02:58:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3497912CC; Wed,  9 Oct 2002 02:58: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 9FE86912CB for <[e-mail]>; Wed,  9 Oct 2002 02:58:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 917275DE8C; Wed,  9 Oct 2002 02:58:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from realname (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 435F65DE8A for <[e-mail]>; Wed,  9 Oct 2002 02:58:19 -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, 09 Oct 2002 16:03:54 +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, 09 Oct 2002 16:03:51 +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, 09 Oct 2002 16:04:25 +0900 (KST)
Date: Wed, 09 Oct 2002 12:27:07 +0530
From: Manav Bhatia <[e-mail]>
Subject: draft-ietf-idr-restart-05.txt
To: [e-mail]
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <02ad01c26f61$15cef230$[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
Sender: [e-mail]
Precedence: bulk

Hi,
I have a question regarding the graceful restart capability in BGP. In the
draft-ietf-idr-restart-05.txt it doesn't talk anything about the forwarding
plane.

The draft just talks about what is applicable when the BGP restarts. Why
doesn't it explicitly say anything about forwarding plane and control plane
as in OSPF draft? Does it mean that even if forwarding plane goes down also
this is applicable? Can somebody please throw some light on this issue.

Is it a mandatory requirement to have your forwarding plane up, when your
BGP restarts?

Am I missing something?

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 LAA28645 for <[e-mail]>; Mon, 7 Oct 2002 11:37:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DD7339124E; Mon,  7 Oct 2002 11:37:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A70B991251; Mon,  7 Oct 2002 11:37: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 337B89124E for <[e-mail]>; Mon,  7 Oct 2002 11:37:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 156405E00B; Mon,  7 Oct 2002 11:37:12 -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 69C655DD94 for <[e-mail]>; Mon,  7 Oct 2002 11:37:11 -0400 (EDT)
Received: from tom3 (usermg27.uk.uudial.com [62.188.122.13]) by nemesis.systems.pipex.net (Postfix) with SMTP id 680FB16008B9D; Mon,  7 Oct 2002 16:37:03 +0100 (BST)
Message-ID: <014601c26e16$f65fbb00$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Yakov Rekhter" <[e-mail]>, "idr" <[e-mail]>
Subject: Re: Generial Editorial Comment 
Date: Mon, 7 Oct 2002 16:33: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

Yes, I like the change from
"will attempt to connect" with

 "will attempt to connect unless configured otherwise".

I don't like the active/passive; we have active already defined as
part of the FSM (Aug02 version)
" In this state BGP is trying to acquire a peer by listening
 for and accepting a transport protocol connection"
and I think this goes far enough.


Tom Petch
-----Original Message-----
From: Curtis Villamizar <[e-mail]>
To: Tom Petch <[e-mail]>
Cc: [e-mail] <[e-mail]>; Yakov Rekhter
<[e-mail]>;  idr <[e-mail]>
Date: 30 September 2002 15:31
Subject: Re: Generial Editorial Comment


>
>I 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 LAA27546 for <[e-mail]>; Mon, 7 Oct 2002 11:05:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D2AA69124F; Mon,  7 Oct 2002 11:04:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A27059124E; Mon,  7 Oct 2002 11:04: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 41B2691251 for <[e-mail]>; Mon,  7 Oct 2002 11:04:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0D7D95DD9D; Mon,  7 Oct 2002 11:04: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 1E3225DD94 for <[e-mail]>; Mon,  7 Oct 2002 11:04:12 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g97F3ok41661; Mon, 7 Oct 2002 11:03:50 -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 g97F3kC41654; Mon, 7 Oct 2002 11:03:46 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g97F3kQ01071; Mon, 7 Oct 2002 11:03:46 -0400 (EDT)
Date: Mon, 7 Oct 2002 11:03:46 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Active Route - OT
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 Mon, Oct 07, 2002 at 04:40:33PM +0200
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Hans,

On Mon, Oct 07, 2002 at 04:40:33PM +0200, [e-mail] wrote:
>    A well-kown and documented exception is when route aggregation is used.
>    A new TLV "atomic aggregate" was defined to indicate this.

And its important to note that this is not only explicitly configured
aggregation, this is implicit aggregation any time a less specific and
a more specific route are being aggregated by a less specific one.

>    Other execptions are also known to happen (the example of the IGP route
>    in the FIB for a route route also learned by IBGP). Those cases will make
>    that the AS-path  send along with a route may not be correct without
>    notice of this fact. Those exceptions not not nessesarily cause problems,
>    however they should be considered as 'bad practice'

Any re-origination of a route that loses path information may potentially
lead to loops.

>    The main purpose for sending round the AS-Path attributes is to avoid loops.
>    Any other use of the attribute (e.g. for applying policies) is not guaranteed
>    to work in all cases.
> 
> 
> Hope this is correct?

Pretty much.

> Hans.

-- 
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 KAA26749 for <[e-mail]>; Mon, 7 Oct 2002 10:41:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BF50D9124D; Mon,  7 Oct 2002 10:40:46 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88E8B9124E; Mon,  7 Oct 2002 10:40: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 523DE9124D for <[e-mail]>; Mon,  7 Oct 2002 10:40:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3783D5E001; Mon,  7 Oct 2002 10:40:45 -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 33DDC5DDA5 for <[e-mail]>; Mon,  7 Oct 2002 10:40:44 -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 g97EY0x18386 for <[e-mail]>; Mon, 7 Oct 2002 16:34:00 +0200
Received: from alcatel.be ([138.203.191.116]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002100716403377:6198 ; Mon, 7 Oct 2002 16:40:33 +0200 
Message-ID: <[e-mail]>
Date: Mon, 07 Oct 2002 16:40:33 +0200
From: [e-mail]
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Cc: [e-mail]
Subject: Re: Active Route - OT
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 10/07/2002 16:40:33, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 10/07/2002 16:40:35, Serialize complete at 10/07/2002 16:40:35
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Jeffrey et al,

from the reactions on this topic, my understanding of the validity of the AS-path
attribute assigned to a route becomes something like:

   The AS-path associated with a route is meant to be correct.

   A well-kown and documented exception is when route aggregation is used.
   A new TLV "atomic aggregate" was defined to indicate this.

   Other execptions are also known to happen (the example of the IGP route
   in the FIB for a route route also learned by IBGP). Those cases will make
   that the AS-path  send along with a route may not be correct without
   notice of this fact. Those exceptions not not nessesarily cause problems,
   however they should be considered as 'bad practice'

   The main purpose for sending round the AS-Path attributes is to avoid loops.
   Any other use of the attribute (e.g. for applying policies) is not guaranteed
   to work in all cases.


Hope this is correct?

---
Hans.





Jeffrey Haas wrote:

> On Fri, Oct 04, 2002 at 10:54:12AM +0200, [e-mail] wrote:
> > Well, I tend to be picky on the attributes. Why do we forward them, or have long
> > discussions about then (as the ones I see ongoing for e.g. the AS-PATH) if in
> > the end the attribute is not trustworthy?
>
> That was what ATOMIC_AGGREGATE was intended to signal.
>
> One of the problems with creating aggregates without full path information
> is that you can't tell if there are contributors that you might loop to.
> You essentially must count on the more specifics being present
> or being far enough away from things to not be affected by a potential
> looping situation.
>
> Thankfully, this seems to often be the case.
>
> Dennis points out that people largely form aggregates along their
> assigned address boundaries anyway.  So long as proxy aggregation
> doesn't happen all over the place, we're fine with incomplete path
> information.
>
> > What is e.g. the value of a routing policy saying that "I do not want to use
> > routes that to pass via this particular AS".
>
> The fact that it lets you shape your packet flows.  Even a coarse
> control is better than none.  And when none is available, people
> will sometimes internally de-aggregate in order to get that control.
>
> > Unless  of course, my whole appreciation of the atributes is wrong. But in this
> > case it would be good to indicate what can and cannot be expected from an
> > attribute.
>
> Honestly, its best to *not* expect anything beyond guaranteeing loop
> free routing.  The fact that you can *try* is an operational decision.
> It might even work.
>
> > So we would probaby end up with an indicator in the route saying " attributes
> > not guaranteed", but then again i think i prefer the restriction in the RFC.
>
> We could also say that everyone must propagate every route that enters
> the routing system.  I rather suspect network operators and other
> implementators would tell us where to put that suggestion.
>
> --
> 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 SAA21785 for <[e-mail]>; Sun, 6 Oct 2002 18:00:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 232D591242; Sun,  6 Oct 2002 17:59:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2E9C91244; Sun,  6 Oct 2002 17:59: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 7D95C91242 for <[e-mail]>; Sun,  6 Oct 2002 17:59:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5861F5DE70; Sun,  6 Oct 2002 17:59:41 -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 279455DD9E for <[e-mail]>; Sun,  6 Oct 2002 17:59:41 -0400 (EDT)
Received: from tom3 (userbl60.uk.uudial.com [62.188.144.167]) by shockwave.systems.pipex.net (Postfix) with SMTP id A2E8C16001145; Sun,  6 Oct 2002 22:59:38 +0100 (BST)
Message-ID: <049601c26d83$3cdf3680$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: <[e-mail]>, "Yakov Rekhter" <[e-mail]>
Subject: Re: issue 8
Date: Sun, 6 Oct 2002 22:51: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

The FSM also introduces an OpenDelay timer which then should be
included.  I don't have any experience of a suitable setting; I
imagine it would be commensurate with, perhaps a multiple of, the
ConnectRetryTimer.

FSM also in places suggests a Hold Timer of 4 minutes.  Likewise, I
cannot suggest a resolution ( but can point out a potential
discrepancy:-(

Tom Petch

-----Original Message-----
From: Yakov Rekhter <[e-mail]>
To: [e-mail] <[e-mail]>
Date: 02 October 2002 16:49
Subject: issue 8


>Folks,
>
>I'd like to propose the following text for "BGP Timers" section:
>
>   BGP employs five timers: ConnectRetry (see Section 8), Hold Time
>   (see Section 4.2), KeepAlive (see Section 8),
MinASOriginationInterval
>   (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
>   Section 9.2.1.1).
>
>   The suggested value for the ConnectRetry timer is 120 seconds.
>
>   The suggested value for the Hold Time is 90 seconds.
>
>   The suggested value for the KeepAlive timer is 1/3 of the Hold
>   Time.
>
>   The suggested value for the MinASOriginationInterval is 15
>   seconds.
>
>   The suggested value for the MinRouteAdvertisementInterval is 30
>   seconds.
>
>   An implementation of BGP MUST allow the Hold Time timer to be
>   configurable, and MAY allow the other timers to be configurable.
>
>   To minimize the likelihood that the distribution of BGP messages
>   by a given BGP speaker will contain peaks, jitter should be
>   applied to the timers associated with MinASOriginationInterval,
>   Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
>   given BGP speaker shall apply the same jitter to each of these
>   quantities regardless of the destinations to which the updates
>   are being sent; that is, jitter will not be applied on a "per
>   peer" basis.
>
>Any objections ?
>
>Yakov.
>
>   The amount of jitter to be introduced shall be determined by
>   multiplying the base value of the appropriate timer by a random
>   factor which is uniformly distributed in the range from 0.75 to
>   1.0.
>
>



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA06411 for <[e-mail]>; Fri, 4 Oct 2002 13:22:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4176491386; Fri,  4 Oct 2002 13:21:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E4E091384; Fri,  4 Oct 2002 13:21: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 AEAB491387 for <[e-mail]>; Fri,  4 Oct 2002 13:21:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 9BB6D5DDEE; Fri,  4 Oct 2002 13:21:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: from bridge.axiowave.com (unknown [64.115.125.242]) by segue.merit.edu (Postfix) with ESMTP id 060015DEEB for <[e-mail]>; Fri,  4 Oct 2002 13:21:34 -0400 (EDT)
Message-ID: <[e-mail]>
From: Dimitry Haskin <[e-mail]>
To: "'Dennis Ferguson'" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 11 
Date: Fri, 4 Oct 2002 13:21:26 -0400 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Dennis,


> 
> What you describe is a reasonable way to do this function, but I think
> the fact that it actually depends on the combination of component route
> AS paths into the aggregate route's AS path for the purpose of ensuring
> correct, loop-free routing, and that it can't be safely simulated by
simple
> redistribution policy, makes it unique enough to require more explanation
> than just a conceptual statement.

It can be approached at a slightly different angle. It is true that what
I've described requires more strict adherence to the aggregation rules
specified in the draft-17 document than in the most other aggregation cases.
However it may be better, if deemed necessary, to specify in the aggregation
section when and how the currently specified rules can be relaxed. 

> 
> Dennis Ferguson

Regards,
 Dimitry


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA03571 for <[e-mail]>; Fri, 4 Oct 2002 11:56:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0A33E91205; Fri,  4 Oct 2002 11:55:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D03BF91384; Fri,  4 Oct 2002 11:55: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 DA5B791205 for <[e-mail]>; Fri,  4 Oct 2002 11:55:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B4D935DEEC; Fri,  4 Oct 2002 11:55: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 3A7F05DEE4 for <[e-mail]>; Fri,  4 Oct 2002 11:55: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 LAA26035; Fri, 4 Oct 2002 11:55: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 LAA09735; Fri, 4 Oct 2002 11:55:39 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7R86C>; Fri, 4 Oct 2002 11:55:05 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'John G. Scudder'" <[e-mail]>, Jeffrey Haas <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Active Route - OT
Date: Fri, 4 Oct 2002 11:55: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

According to the definition of ATOMIC_AGGREGATE. It discusses loss of
information due to aggregation, not due to other means
like choosing an IGP route over IBGP. If that were mentioned I would agree
the ATOMIC_AGGREGATE covers it all. 

Plus, the ATOMIC_AGGREGATE says receiving peers cannot deaggregate the route
to a more specific components, mainly because all the AS_Paths of the
component routes are not present in the aggregated route. This is completely
different than choosing an IGP route over an IBGP route. In my case, most
likely none of the AS_PATHS are in the IBGP route. 

I think you guys are trying to merge everything into existing stuff that
does not cover it in all cases.


Ben

> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]]
> Sent: Friday, October 04, 2002 11:27 AM
> To: Jeffrey Haas
> Cc: [e-mail]; [e-mail]
> Subject: Re: Active Route - OT
> 
> 
> At 10:59 AM -0400 10/4/02, Jeffrey Haas wrote:
> >  > Unless  of course, my whole appreciation of the atributes is 
> >wrong. But in this
> >>  case it would be good to indicate what can and cannot be 
> expected from an
> >>  attribute.
> >
> >Honestly, its best to *not* expect anything beyond guaranteeing loop
> >free routing.  The fact that you can *try* is an operational 
> decision.
> >It might even work.
> 
> Indeed, and this has been called out in the spec for a very long time 
> now, in the case of ATOMIC_AGGREGATE.  From 5.1.6:
> 
>     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.
> 
> Consider this statement in combination with your earlier observation 
> that in effect, everything is an atomic aggregate (or at least, must 
> be treated as if it were).
> 
> --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 LAA02930 for <[e-mail]>; Fri, 4 Oct 2002 11:37:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1F6E791381; Fri,  4 Oct 2002 11:34:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6B6C91386; Fri,  4 Oct 2002 11:34: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 B1B5891381 for <[e-mail]>; Fri,  4 Oct 2002 11:34:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A08AC5DEDC; Fri,  4 Oct 2002 11:34: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 2EB1A5DE3C for <[e-mail]>; Fri,  4 Oct 2002 11:34: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 LAA23028; Fri, 4 Oct 2002 11:34: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 LAA02564; Fri, 4 Oct 2002 11:34:49 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7R7LD>; Fri, 4 Oct 2002 11:34:44 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: RE: Active Route - OT
Date: Fri, 4 Oct 2002 11:34: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

Jeff:

> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Friday, October 04, 2002 11:02 AM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: Active Route - OT
> 
> 
> Ben,
> 
> [is there any need to quote the entirety of messages?]
> 
> On Fri, Oct 04, 2002 at 10:26:02AM -0400, Abarbanel, Benjamin wrote:
> > Agreed, but as your example shows its possible to violate 
> the AS path
> > traversel
> > and not really forward packets along the path that the peer 
> thinks is
> > happening. Therefore, one solution would be not to 
> advertise the route if
> > the Routing Table and the BGP Loc-Rib/Adj-Rib-out(peer) do 
> not agree 100% on
> > the useage of that route. 
> 
> Please see my long original post on deprecating atomic_aggregate.
> Then please read Dennis Ferguson's posts on how the lack of
> full path information in aggregates isn't too much of a concern.
> 
> These reflect deployed reality.  You're talking about a spec change.
> 

Denying a route is not a spec change, but a policy decision.

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 LAA02832 for <[e-mail]>; Fri, 4 Oct 2002 11:34:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C172491212; Fri,  4 Oct 2002 11:33:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7088191384; Fri,  4 Oct 2002 11:33: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 3CF4B91212 for <[e-mail]>; Fri,  4 Oct 2002 11:31:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 084475DEE4; Fri,  4 Oct 2002 11:31:44 -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 4B82C5DEDC for <[e-mail]>; Fri,  4 Oct 2002 11:31:43 -0400 (EDT)
Received: from [171.69.182.140] (dhcp-171-69-182-140.cisco.com [171.69.182.140]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA06050; Fri, 4 Oct 2002 11:31:21 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a02b9c36307fdc7@[192.168.42.10]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 4 Oct 2002 11:27:19 -0400
To: Jeffrey Haas <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: Re: Active Route - OT
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 10:59 AM -0400 10/4/02, Jeffrey Haas wrote:
>  > Unless  of course, my whole appreciation of the atributes is 
>wrong. But in this
>>  case it would be good to indicate what can and cannot be expected from an
>>  attribute.
>
>Honestly, its best to *not* expect anything beyond guaranteeing loop
>free routing.  The fact that you can *try* is an operational decision.
>It might even work.

Indeed, and this has been called out in the spec for a very long time 
now, in the case of ATOMIC_AGGREGATE.  From 5.1.6:

    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.

Consider this statement in combination with your earlier observation 
that in effect, everything is an atomic aggregate (or at least, must 
be treated as if it were).

--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 LAA01805 for <[e-mail]>; Fri, 4 Oct 2002 11:03:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 33D2991383; Fri,  4 Oct 2002 11:03:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A46BE91387; Fri,  4 Oct 2002 11:03: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 234B391383 for <[e-mail]>; Fri,  4 Oct 2002 11:02:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0C54F5DEE4; Fri,  4 Oct 2002 11:02: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 1DB485DEB0 for <[e-mail]>; Fri,  4 Oct 2002 11:02:25 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g94F2JR77343; Fri, 4 Oct 2002 11:02: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 g94F2FC77336; Fri, 4 Oct 2002 11:02:15 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g94F2Fn11375; Fri, 4 Oct 2002 11:02:15 -0400 (EDT)
Date: Fri, 4 Oct 2002 11:02:15 -0400
From: Jeffrey Haas <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: Active Route - OT
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, Oct 04, 2002 at 10:26:02AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Ben,

[is there any need to quote the entirety of messages?]

On Fri, Oct 04, 2002 at 10:26:02AM -0400, Abarbanel, Benjamin wrote:
> Agreed, but as your example shows its possible to violate the AS path
> traversel
> and not really forward packets along the path that the peer thinks is
> happening. Therefore, one solution would be not to advertise the route if
> the Routing Table and the BGP Loc-Rib/Adj-Rib-out(peer) do not agree 100% on
> the useage of that route. 

Please see my long original post on deprecating atomic_aggregate.
Then please read Dennis Ferguson's posts on how the lack of
full path information in aggregates isn't too much of a concern.

These reflect deployed reality.  You're talking about a spec change.


-- 
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 LAA01738 for <[e-mail]>; Fri, 4 Oct 2002 11:01:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 408CA91380; Fri,  4 Oct 2002 11:00:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B90D791381; Fri,  4 Oct 2002 11:00: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 931F991380 for <[e-mail]>; Fri,  4 Oct 2002 11:00:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B56185DEEC; Fri,  4 Oct 2002 11:00: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 3082A5DEE9 for <[e-mail]>; Fri,  4 Oct 2002 11:00:09 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g94ExuG77251; Fri, 4 Oct 2002 10:59: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 g94ExpC77240; Fri, 4 Oct 2002 10:59:51 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g94ExpA11354; Fri, 4 Oct 2002 10:59:51 -0400 (EDT)
Date: Fri, 4 Oct 2002 10:59:51 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Active Route - OT
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, Oct 04, 2002 at 10:54:12AM +0200
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Oct 04, 2002 at 10:54:12AM +0200, [e-mail] wrote:
> Well, I tend to be picky on the attributes. Why do we forward them, or have long
> discussions about then (as the ones I see ongoing for e.g. the AS-PATH) if in
> the end the attribute is not trustworthy?

That was what ATOMIC_AGGREGATE was intended to signal.

One of the problems with creating aggregates without full path information
is that you can't tell if there are contributors that you might loop to.
You essentially must count on the more specifics being present
or being far enough away from things to not be affected by a potential
looping situation.

Thankfully, this seems to often be the case.

Dennis points out that people largely form aggregates along their
assigned address boundaries anyway.  So long as proxy aggregation
doesn't happen all over the place, we're fine with incomplete path
information.

> What is e.g. the value of a routing policy saying that "I do not want to use
> routes that to pass via this particular AS".

The fact that it lets you shape your packet flows.  Even a coarse
control is better than none.  And when none is available, people
will sometimes internally de-aggregate in order to get that control.

> Unless  of course, my whole appreciation of the atributes is wrong. But in this
> case it would be good to indicate what can and cannot be expected from an
> attribute.

Honestly, its best to *not* expect anything beyond guaranteeing loop
free routing.  The fact that you can *try* is an operational decision.
It might even work.

> So we would probaby end up with an indicator in the route saying " attributes
> not guaranteed", but then again i think i prefer the restriction in the RFC.

We could also say that everyone must propagate every route that enters
the routing system.  I rather suspect network operators and other
implementators would tell us where to put that suggestion.

-- 
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 KAA01391 for <[e-mail]>; Fri, 4 Oct 2002 10:52:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 272869137F; Fri,  4 Oct 2002 10:52:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC5EB91380; Fri,  4 Oct 2002 10:52: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 CEBB29137F for <[e-mail]>; Fri,  4 Oct 2002 10:52:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B781B5DEB0; Fri,  4 Oct 2002 10:52: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 C430A5DEEC for <[e-mail]>; Fri,  4 Oct 2002 10:52:18 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g94EqGc77081; Fri, 4 Oct 2002 10:52: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 g94EqDC77074; Fri, 4 Oct 2002 10:52:13 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g94EqDX11339; Fri, 4 Oct 2002 10:52:13 -0400 (EDT)
Date: Fri, 4 Oct 2002 10:52:12 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: MED for Originated Routes
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, Oct 04, 2002 at 09:36:53AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Fri, Oct 04, 2002 at 09:36:53AM -0400, Natale, Jonathan wrote:
> The point is:
> "the base spec does not say what to set the MED to for originated routes"

This is called an implementation decision.

You could put a MED in of 2^32-1 if you wanted to and it would still
be legal.  You would still interoperate.

And your customers would get cranky.

> ...the fact that Juniper and Cisco chose sensible things to do
> is not an argument for the spec to be silent, is it?

And why do most routers tend to send a localpref of 100 by default?
Do you think that should be in the spec as well?  I sincerely hope not.

> Also, didn't the old spec say to treat a missing MED as all 1's?

In -14, it says the lowest possible value, which until it was
clarified, could be considered to be smaller than a value of zero.

-- 
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 KAA00479 for <[e-mail]>; Fri, 4 Oct 2002 10:26:36 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A15F89137E; Fri,  4 Oct 2002 10:26:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 665259137F; Fri,  4 Oct 2002 10: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 4CA799137E for <[e-mail]>; Fri,  4 Oct 2002 10:26:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 308ED5DEE6; Fri,  4 Oct 2002 10:26: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 DCB4B5DEE3 for <[e-mail]>; Fri,  4 Oct 2002 10:26: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 KAA18266; Fri, 4 Oct 2002 10:26: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 KAA18002; Fri, 4 Oct 2002 10:26:10 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7RY1V>; Fri, 4 Oct 2002 10:26:04 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: BGP mailing list <[e-mail]>
Subject: RE: Active Route - OT
Date: Fri, 4 Oct 2002 10:26: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

Hans:

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Friday, October 04, 2002 4:54 AM
> To: Abarbanel, Benjamin
> Cc: BGP mailing list
> Subject: Re: Active Route - OT
> 
> 
> Ben,
> 
> "Abarbanel, Benjamin" wrote:
> 
> > Hans:
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]
> > > Sent: Thursday, October 03, 2002 9:09 AM
> > > To: BGP mailing list
> > > Subject: Re: Active Route - OT
> > >
> > >
> > > All,
> > >
> > > thanks for your feedback on this.  Now I tend to be  more in
> > > favor of  leaving
> > > the text  and the restriction in the RFC.  The reasons i see
> > > for this are:
> > >
> > > 1. The effective use of policy is endangered. Supose a bgp
> > > speaker announces to
> > > its external peer reachability for a route, and indicates
> > > that this route
> > > passes through AS 1,2 and 3, while at the same time the FIB
> > > of the same router
> > > would actually send the traffic so that in the end it follows
> > > another path
> > > passing through a different set of ASses.  If this is allowed
> > > why would we even
> > > bother to pass along attributes? (Also I learned of some
> > > people trying to make
> > > tools that use the BGP RIB to figure out how traffic is 
> flowing in the
> > > internet).
> > >
> >
> > According to Dennis you are gauranteed that the mix of BGP 
> and IGP routing
> > will prevent any possible loops and get the packet to its 
> destination. It
> > does not gaurantee that the packet will travel the AS_PATH 
> defined in the
> > (i/e)BGP route. Thus, in a way it works and it doesn't, if 
> you are picky
> > about the attributes.
> 
> Well, I tend to be picky on the attributes. Why do we forward 
> them, or have long
> discussions about then (as the ones I see ongoing for e.g. 
> the AS-PATH) if in
> the end the attribute is not trustworthy?
> 
> What is e.g. the value of a routing policy saying that "I do 
> not want to use
> routes that to pass via this particular AS".
> 
Agreed, but as your example shows its possible to violate the AS path
traversel
and not really forward packets along the path that the peer thinks is
happening. Therefore, one solution would be not to advertise the route if
the Routing Table and the BGP Loc-Rib/Adj-Rib-out(peer) do not agree 100% on
the useage of that route. 

One other way is to guarantee that a BGP route and IGP route never
match on a destination in the routing table, thus you never have this
problem.
That might require additional policies or such. Somehow I think there will
always be a case where they match and thus the problem occurs.


> Unless  of course, my whole appreciation of the atributes is 
> wrong. But in this
> case it would be good to indicate what can and cannot be 
> expected from an
> attribute.
> 
> 
> > IMHO, there should be a way to flag that suboptimal
> > routing is
> > taking place with this route so that any external peers can 
> make a judgement
> > call on the validity of the route provided. For example, 
> lets say a peer
> > knows that this IBGP route is not really used for 
> forwarding but an IGP
> > route
> > is for the same destination, it could flag the route with a 
> new attribute
> > saying that suboptimal routing path is used with this 
> route. The external
> > peer receiving the route can reduce its priority so that 
> the BGP decision
> > process can pick another route over this one, thus avoiding the less
> > deterministic behavior.
> >
> 
> I am not sure that the other route which is used is in fact 
> 'suboptimal'. The
> only thing i really  know is that the attributes for the 
> actual route that is
> being taken, will differ from the advertised attributes.
> 
> So we would probaby end up with an indicator in the route 
> saying " attributes
> not guaranteed", but then again i think i prefer the 
> restriction in the RFC.
> 
In some cases it is not important that a route took a particular AS path,
only
that it is reachable and not looping. In this sense, my solution will be
helpfull to external peers. 

Whether you call this condition "suboptimal routing" or "no guarantee of
path traversal", it flags the issue to external peers so that they could
treat the route with a lower priority than the ones that have guaranteed
attributes. Policies could be added that could be tailored on a case by case
basis to know
how to react to such a condition.

Ben
> 
> >
> >
> > > thanks
> > > ---
> > > Hans De Vleeschouwer
> > >
> > > > "Natale, Jonathan" wrote:
> > > >
> > > > > "What if your AS is not fully meshed as Hans pointed out?"
> > > > >
> > > > > Then you are mis-configured.
> > > > >
> > > > > Also, I agree with Curtis--redistributing BGP into IGP is
> > > a bad idea.  A
> > > > > much better idea is to turn off synchronization (rumor
> > > was that it will
> > > > > be/is off by default in newer IOS).  Juniper does not
> > > even have a synch
> > > > > concept (a good thing).
> > > > >
> > > > > -----Original Message-----
> > > > > From: Abarbanel, Benjamin 
> [mailto:[e-mail]]
> > > > > Sent: Wednesday, October 02, 2002 12:41 PM
> > > > > To: '[e-mail]'; [e-mail]
> > > > > Cc: BGP mailing list
> > > > > Subject: RE: Active Route
> > > > >
> > > > > Curtis
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Curtis Villamizar 
> [mailto:[e-mail]]
> > > > > > Sent: Wednesday, October 02, 2002 12:33 PM
> > > > > > To: [e-mail]
> > > > > > Cc: BGP mailing list
> > > > > > Subject: Re: Active Route
> > > > > >
> > > > > >
> > > > > >
> > > > > > In message <[e-mail]>,
> > > > > > [e-mail] writ
> > > > > > es:
> > > > > > >
> > > > > > > Then I redistribute the routes into IGP, and at the same
> > > > > > time I forward
> > > > > > > the routes via IBGP (not full mesh) to all of the other AS
> > > > > > border routers (bu
> > > > > > > t
> > > > > > > to no other routers).
> > > > > >
> > > > > > This is an incredibly bad idea.  Only the BGP next_hop
> > > needs to be in
> > > > > > the IGP.
> > > > > >
> > > > > > > At the other side of my AS, I allow the border router
> > > > > > (router B) to pass thos
> > > > > > > e
> > > > > > > routes learned via IBGP (form router A) to the (next) AS
> > > > > > via an EBGP connecti
> > > > > > > on.
> > > > > > > (I am using the  "synchronise BGP = TRUE" option.)
> > > > > >
> > > > > > Synchronise implies that the BGP next_hop is reachable
> > > via the IGP
> > > > > > *not* the BGP prefix itself.
> > > > > >
> > > > > > There is never a need to put the destination prefix
> > > into the IGP if it
> > > > > > is carried in IBGP except for the case where you are
> > > originating a
> > > > > > prefix and you want it to go out with specific
> > > attributes such as
> > > > > > specific BGP communities or indicate through BGP
> > > communities some
> > > > > > special action such as punching a hole in an aggregate.
> > > > > >
> > > > >
> > > > > What if your AS is not fully meshed as Hans pointed out?
> > > > >
> > > > > The only way to get external BGP routes to non-BGP (IGP
> > > only) routers is by
> > > > > redistributing them via IGP, and let IGP flood them, right?
> > > > >
> > > > > > > Now in this fairly straightforward example, the router B
> > > > > > will forward routes
> > > > > > > learned via IBGP to the next AS using EBGP, whereas for
> > > > > > those routes the
> > > > > > > reachability in the FIB is taken care of by IGP (who has
> > > > > > typically a higher
> > > > > > > preference in ther FIB then IBGP).
> > > > > > >
> > > > > > > So, in theory the rule : "one must focus on the 
> rule that a
> > > > > > BGP speaker
> > > > > > > advertises to its peers  in neighboring ASs only those
> > > > > > routes that it itself
> > > > > > > uses." is broken, since it is clearly an IGP route
> > > which in the FIB.
> > > > > > >
> > > > > > > ---
> > > > > > > Hans de Vleeschouwer
> > > > > >
> > > > > > The only way to fully address all of the instances of
> > > this sort of
> > > > > > objection is to add to the spec "Most BGP
> > > implementations allow the
> > > > > > user to do things that violate the protocol
> > > specification in minor
> > > > > > ways, sometimes with valid uses, but also sometimes
> > > with questionalble
> > > > > > uses and sometimes with dire consequences".  Although
> > > this statement
> > > > > > is true, I don't don't think we need to add this.
> > > > > >
> > > > > This although is sometimes true, is bordering on being
> > > rediculous for a
> > > > > spec. I agree, you do not want to add this or the reader
> > > will stop reading
> > > > > the spec.
> > > > >
> > > > > 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 KAA29556 for <[e-mail]>; Fri, 4 Oct 2002 10:06:21 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C27FD9137D; Fri,  4 Oct 2002 10:06:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 939999137E; Fri,  4 Oct 2002 10:06: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 32F049137D for <[e-mail]>; Fri,  4 Oct 2002 10:06:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 195AB5DEE1; Fri,  4 Oct 2002 10:06: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 B747D5DED2 for <[e-mail]>; Fri,  4 Oct 2002 10:05:59 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC125VB>; Fri, 4 Oct 2002 10:05:59 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: New Issue AS path 
Date: Fri, 4 Oct 2002 10:05:58 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

The other option here is to remover references to CONFEDs as "out of scope"
and/or "refer to RFC3065" (although I am not sure if it is/will be
sufficiently covered there).

-----Original Message-----
From: Srikanth Rao [mailto:[e-mail]] 
Sent: Thursday, October 03, 2002 6:50 PM
To: [e-mail]; Natale, Jonathan
Cc: Jeffrey Haas; [e-mail]
Subject: RE: New Issue AS path 


> What about AS_CONFED_SETs?  Does anybody use these?

>>Don't think that's every used, but if so if AS_CONFED_SEQUENCE is not 
>>counted, it would apply to AS_CONFED_SET.

Juniper counts AS_CONFED_SET towards path length of one.

-sr-

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]]
Sent: Thursday, October 03, 2002 3:35 PM
To: Natale, Jonathan
Cc: 'Jeffrey Haas'; [e-mail]; [e-mail]
Subject: Re: New Issue AS path 



In message
<[e-mail]
ks.com>, "Natale, Jonathan" writes:
> What about the fact that an AS_SET counts as 1 (in IOS)???  Is that 
> already in the spec?

That's in 9.1.2.2:

      a) Remove from consideration all routes which are not tied for
      having the smallest number of AS numbers present in their AS_PATH
      attributes. Note, that when counting this number, an AS_SET counts
      as 1, no matter how many ASs are in the set, and that, if the
      implementation supports [13], then AS numbers present in segments
      of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in
      the count of AS numbers present in the AS_PATH.

> Does juniper set AS_CONFED_SEQUENCE to 0 too?

I'd say yes but don't know for sure.

> What about AS_CONFED_SETs?  Does anybody use these?

Don't think that's every used, but if so if AS_CONFED_SEQUENCE is not
counted, it would apply to AS_CONFED_SET.

> I don't think we want to put stuff in [to the draft] just because IOS 
> does it; it might be nice to put stuff in that covers Juniper and IOS, 
> if and only if it affect interoperability.

It looks like it is already covered in draft-17.  See above.

Curtis


> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Thursday, October 03, 2002 3:28 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: issue 11
> 
> 
> On Thu, Oct 03, 2002 at 03:22:02PM -0400, Curtis Villamizar wrote:
> > It would be useful to add this to the RR RFC.
> 
> That would be my preferred action.
> 
> However, I would also prefer that the AS_PATH length calculation for 
> confederation segments (i.e. they have zero value) also be moved into 
> the confed update.
> 
> > 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 JAA28475 for <[e-mail]>; Fri, 4 Oct 2002 09:44:21 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7260C9137B; Fri,  4 Oct 2002 09:43:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D5C09137C; Fri,  4 Oct 2002 09: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 E10CE9137B for <[e-mail]>; Fri,  4 Oct 2002 09:43:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C46FB5DEE1; Fri,  4 Oct 2002 09:43: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 80E6B5DEAC for <[e-mail]>; Fri,  4 Oct 2002 09:43:41 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC125RL>; Fri, 4 Oct 2002 09:43:41 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: RE: New Issue AS path 
Date: Fri, 4 Oct 2002 09:43:40 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I hate to drag "specific vendors" in, but does Juniper also count
AS_CONFED_SET as 1?
If they do, then the section below should be changed (it now says to count
it as 0), right?

Also, what to do with AS_CONFED_SET should be spec'd.

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Thursday, October 03, 2002 6:35 PM
To: Natale, Jonathan
Cc: 'Jeffrey Haas'; [e-mail]; [e-mail]
Subject: Re: New Issue AS path 



In message
<[e-mail]
ks.com>, "Natale, Jonathan" writes:
> What about the fact that an AS_SET counts as 1 (in IOS)???  Is that 
> already in the spec?

That's in 9.1.2.2:

      a) Remove from consideration all routes which are not tied for
      having the smallest number of AS numbers present in their AS_PATH
      attributes. Note, that when counting this number, an AS_SET counts
      as 1, no matter how many ASs are in the set, and that, if the
      implementation supports [13], then AS numbers present in segments
      of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in
      the count of AS numbers present in the AS_PATH.

> Does juniper set AS_CONFED_SEQUENCE to 0 too?

I'd say yes but don't know for sure.

> What about AS_CONFED_SETs?  Does anybody use these?

Don't think that's every used, but if so if AS_CONFED_SEQUENCE is not
counted, it would apply to AS_CONFED_SET.

> I don't think we want to put stuff in [to the draft] just because IOS 
> does it; it might be nice to put stuff in that covers Juniper and IOS, 
> if and only if it affect interoperability.

It looks like it is already covered in draft-17.  See above.

Curtis


> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]]
> Sent: Thursday, October 03, 2002 3:28 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: issue 11
> 
> 
> On Thu, Oct 03, 2002 at 03:22:02PM -0400, Curtis Villamizar wrote:
> > It would be useful to add this to the RR RFC.
> 
> That would be my preferred action.
> 
> However, I would also prefer that the AS_PATH length calculation for 
> confederation segments (i.e. they have zero value) also be moved into 
> the confed update.
> 
> > 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 JAA28199 for <[e-mail]>; Fri, 4 Oct 2002 09:37:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8A69B91218; Fri,  4 Oct 2002 09:36:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 584D79137A; Fri,  4 Oct 2002 09:36: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 2169591218 for <[e-mail]>; Fri,  4 Oct 2002 09:36:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F0EBD5DEDF; Fri,  4 Oct 2002 09:36: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 A270E5DEDD for <[e-mail]>; Fri,  4 Oct 2002 09:36:55 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC125QY>; Fri, 4 Oct 2002 09:36:54 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: MED for Originated Routes
Date: Fri, 4 Oct 2002 09:36:53 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

The point is:
"the base spec does not say what to set the MED to for originated routes"

...the fact that Juniper and Cisco chose sensible things to do
is not an argument for the spec to be silent, is it?

Also, didn't the old spec say to treat a missing MED as all 1's?
(not sure if this is relevant)


-----Original Message-----
From: Mathew Richardson [mailto:[e-mail]] 
Sent: Thursday, October 03, 2002 5:59 PM
To: Natale, Jonathan
Cc: 'John G. Scudder'; '[e-mail]'; [e-mail]
Subject: Re: MED for Originated Routes


> Natale, Jonathan <[e-mail]> [Thu, Oct 03, 2002 at 
>05:30:11PM -0400]: Since no MED is equivalent to MED = 0 *in this 
>case*, they are interoperable.  But the base spec does not say what to 
>set the MED to for originated routes.  So I need to disagree, an 
>addition to the spec is called for.

<snip>

The absence of an MED is equivalent to a MED of zero in all cases.

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 EAA15941 for <[e-mail]>; Fri, 4 Oct 2002 04:55:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4671291370; Fri,  4 Oct 2002 04:54:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1131B91371; Fri,  4 Oct 2002 04:54: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 C156191370 for <[e-mail]>; Fri,  4 Oct 2002 04:54:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A7E505DE55; Fri,  4 Oct 2002 04:54:57 -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 073925DDCE for <[e-mail]>; Fri,  4 Oct 2002 04:54:57 -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 g948mIG13928; Fri, 4 Oct 2002 10:48:18 +0200
Received: from alcatel.be ([138.203.142.50]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002100410544471:2849 ; Fri, 4 Oct 2002 10:54:44 +0200 
Message-ID: <[e-mail]>
Date: Fri, 04 Oct 2002 10:54:12 +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]>
Cc: BGP mailing list <[e-mail]>
Subject: Re: Active Route - OT
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 10/04/2002 10:54:45, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 10/04/2002 10:54:46, Serialize complete at 10/04/2002 10:54:46
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

Ben,

"Abarbanel, Benjamin" wrote:

> Hans:
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]
> > Sent: Thursday, October 03, 2002 9:09 AM
> > To: BGP mailing list
> > Subject: Re: Active Route - OT
> >
> >
> > All,
> >
> > thanks for your feedback on this.  Now I tend to be  more in
> > favor of  leaving
> > the text  and the restriction in the RFC.  The reasons i see
> > for this are:
> >
> > 1. The effective use of policy is endangered. Supose a bgp
> > speaker announces to
> > its external peer reachability for a route, and indicates
> > that this route
> > passes through AS 1,2 and 3, while at the same time the FIB
> > of the same router
> > would actually send the traffic so that in the end it follows
> > another path
> > passing through a different set of ASses.  If this is allowed
> > why would we even
> > bother to pass along attributes? (Also I learned of some
> > people trying to make
> > tools that use the BGP RIB to figure out how traffic is flowing in the
> > internet).
> >
>
> According to Dennis you are gauranteed that the mix of BGP and IGP routing
> will prevent any possible loops and get the packet to its destination. It
> does not gaurantee that the packet will travel the AS_PATH defined in the
> (i/e)BGP route. Thus, in a way it works and it doesn't, if you are picky
> about the attributes.

Well, I tend to be picky on the attributes. Why do we forward them, or have long
discussions about then (as the ones I see ongoing for e.g. the AS-PATH) if in
the end the attribute is not trustworthy?

What is e.g. the value of a routing policy saying that "I do not want to use
routes that to pass via this particular AS".

Unless  of course, my whole appreciation of the atributes is wrong. But in this
case it would be good to indicate what can and cannot be expected from an
attribute.


> IMHO, there should be a way to flag that suboptimal
> routing is
> taking place with this route so that any external peers can make a judgement
> call on the validity of the route provided. For example, lets say a peer
> knows that this IBGP route is not really used for forwarding but an IGP
> route
> is for the same destination, it could flag the route with a new attribute
> saying that suboptimal routing path is used with this route. The external
> peer receiving the route can reduce its priority so that the BGP decision
> process can pick another route over this one, thus avoiding the less
> deterministic behavior.
>

I am not sure that the other route which is used is in fact 'suboptimal'. The
only thing i really  know is that the attributes for the actual route that is
being taken, will differ from the advertised attributes.

So we would probaby end up with an indicator in the route saying " attributes
not guaranteed", but then again i think i prefer the restriction in the RFC.


>
> Your comment?
>
> Ben
>
>
> > thanks
> > ---
> > Hans De Vleeschouwer
> >
> > > "Natale, Jonathan" wrote:
> > >
> > > > "What if your AS is not fully meshed as Hans pointed out?"
> > > >
> > > > Then you are mis-configured.
> > > >
> > > > Also, I agree with Curtis--redistributing BGP into IGP is
> > a bad idea.  A
> > > > much better idea is to turn off synchronization (rumor
> > was that it will
> > > > be/is off by default in newer IOS).  Juniper does not
> > even have a synch
> > > > concept (a good thing).
> > > >
> > > > -----Original Message-----
> > > > From: Abarbanel, Benjamin [mailto:[e-mail]]
> > > > Sent: Wednesday, October 02, 2002 12:41 PM
> > > > To: '[e-mail]'; [e-mail]
> > > > Cc: BGP mailing list
> > > > Subject: RE: Active Route
> > > >
> > > > Curtis
> > > >
> > > > > -----Original Message-----
> > > > > From: Curtis Villamizar [mailto:[e-mail]]
> > > > > Sent: Wednesday, October 02, 2002 12:33 PM
> > > > > To: [e-mail]
> > > > > Cc: BGP mailing list
> > > > > Subject: Re: Active Route
> > > > >
> > > > >
> > > > >
> > > > > In message <[e-mail]>,
> > > > > [e-mail] writ
> > > > > es:
> > > > > >
> > > > > > Then I redistribute the routes into IGP, and at the same
> > > > > time I forward
> > > > > > the routes via IBGP (not full mesh) to all of the other AS
> > > > > border routers (bu
> > > > > > t
> > > > > > to no other routers).
> > > > >
> > > > > This is an incredibly bad idea.  Only the BGP next_hop
> > needs to be in
> > > > > the IGP.
> > > > >
> > > > > > At the other side of my AS, I allow the border router
> > > > > (router B) to pass thos
> > > > > > e
> > > > > > routes learned via IBGP (form router A) to the (next) AS
> > > > > via an EBGP connecti
> > > > > > on.
> > > > > > (I am using the  "synchronise BGP = TRUE" option.)
> > > > >
> > > > > Synchronise implies that the BGP next_hop is reachable
> > via the IGP
> > > > > *not* the BGP prefix itself.
> > > > >
> > > > > There is never a need to put the destination prefix
> > into the IGP if it
> > > > > is carried in IBGP except for the case where you are
> > originating a
> > > > > prefix and you want it to go out with specific
> > attributes such as
> > > > > specific BGP communities or indicate through BGP
> > communities some
> > > > > special action such as punching a hole in an aggregate.
> > > > >
> > > >
> > > > What if your AS is not fully meshed as Hans pointed out?
> > > >
> > > > The only way to get external BGP routes to non-BGP (IGP
> > only) routers is by
> > > > redistributing them via IGP, and let IGP flood them, right?
> > > >
> > > > > > Now in this fairly straightforward example, the router B
> > > > > will forward routes
> > > > > > learned via IBGP to the next AS using EBGP, whereas for
> > > > > those routes the
> > > > > > reachability in the FIB is taken care of by IGP (who has
> > > > > typically a higher
> > > > > > preference in ther FIB then IBGP).
> > > > > >
> > > > > > So, in theory the rule : "one must focus on the rule that a
> > > > > BGP speaker
> > > > > > advertises to its peers  in neighboring ASs only those
> > > > > routes that it itself
> > > > > > uses." is broken, since it is clearly an IGP route
> > which in the FIB.
> > > > > >
> > > > > > ---
> > > > > > Hans de Vleeschouwer
> > > > >
> > > > > The only way to fully address all of the instances of
> > this sort of
> > > > > objection is to add to the spec "Most BGP
> > implementations allow the
> > > > > user to do things that violate the protocol
> > specification in minor
> > > > > ways, sometimes with valid uses, but also sometimes
> > with questionalble
> > > > > uses and sometimes with dire consequences".  Although
> > this statement
> > > > > is true, I don't don't think we need to add this.
> > > > >
> > > > This although is sometimes true, is bordering on being
> > rediculous for a
> > > > spec. I agree, you do not want to add this or the reader
> > will stop reading
> > > > the spec.
> > > >
> > > > 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 EAA12397 for <[e-mail]>; Fri, 4 Oct 2002 04:05:27 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 87C7591245; Fri,  4 Oct 2002 04:04:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5975691370; Fri,  4 Oct 2002 04:04: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 18AB691245 for <[e-mail]>; Fri,  4 Oct 2002 04:04:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0229C5DEAF; Fri,  4 Oct 2002 04:04:53 -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 68B165DE55 for <[e-mail]>; Fri,  4 Oct 2002 04:04:51 -0400 (EDT)
Received: by GANESH with Internet Mail Service (5.5.2653.19) id <4F5VZGW3>; Fri, 4 Oct 2002 13:41:34 +0530
Message-ID: <[e-mail]>
From: "Venu Kumar G - CTD, Chennai." <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: issue 25 Next-hop Semantics.
Date: Fri, 4 Oct 2002 13:21:18 +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

Hi , 

           I think we should define semantic correctness for I-BGP and E-BGP
(with multiple hops away from the speaker)  peer also apart from the E-BGP
connection with one-hop away from each other.

    The current rfc text  describes

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

       As a first reader, this  text gives understanding that,  I-BGP and
E-BGP (with many hops away) peers MAY  receive a Route with  NEXT-HOP
attribute as "receivinging speaker's IP address", which is actully not true
for all  types  BNP peers( I-BGP and E-BGP).




Thanks &Regards
Venu 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 TAA16950 for <[e-mail]>; Thu, 3 Oct 2002 19:12:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9C6289136B; Thu,  3 Oct 2002 19:11:43 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F3E89136C; Thu,  3 Oct 2002 19:11: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 0CC169136B for <[e-mail]>; Thu,  3 Oct 2002 19:11:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E23F55DE4C; Thu,  3 Oct 2002 19:11:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web12806.mail.yahoo.com (web12806.mail.yahoo.com [216.136.174.41]) by segue.merit.edu (Postfix) with SMTP id 6007D5DDA1 for <[e-mail]>; Thu,  3 Oct 2002 19:11:41 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [208.246.215.128] by web12806.mail.yahoo.com via HTTP; Thu, 03 Oct 2002 16:11:40 PDT
Date: Thu, 3 Oct 2002 16:11:40 -0700 (PDT)
From: vrishab sikand <[e-mail]>
Subject: RE: issue 11 
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-491911259-1033686700=:78135"
Sender: [e-mail]
Precedence: bulk

--0-491911259-1033686700=:78135
Content-Type: text/plain; charset=us-ascii


 
 "Natale, Jonathan" wrote:
I don't think it should be mentioned in the base spec.


why not?

Most "major" vendors have extended their decision process (beyond router id check) to include

1) originator ID (to be substituited for router id, when present in    path attribute)

2) cluster list length

3) peer id (configured ip address of peer in the neighbor command)

Then why should others have to go to vendors sites and figure out what they have to do to be in compliance with common practice?

Isnt that what the spec is for?


-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Thursday, October 03, 2002 3:22 PM
To: vrishab sikand
Cc: Jeffrey Haas; Alex Zinin; Yakov Rekhter; [e-mail]
Subject: Re: issue 11 



In message <[e-mail]>, vrishab
sikand
writes:
> 
> --- Jeffrey Haas wrote:
> > On Mon, Sep 30, 2002 at 11:20:34AM -0700, Alex Zinin
> > wrote:
> > > 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?
> > 
> > Cisco has cluster length as part of their
> > tie-breaker.
> > 
> > I'm curious about the scenario that is trying to be addressed by 
> > this.
> > 
> hierarchical route reflector configurations. i.e.
> levels of RR clusters.
> Routes which have come through a no RR are prefferred
> over routes which come over one level of RR, are
> preffered over 2 two levels etc.
> At least one of the biggest ISP's uses RR's in this
> way.
> > > Alex
> > 
> > --
> > Jeff Haas 
> > NextHop Technologies


It would be useful to add this to the RR RFC.

It could be mentioned in the base spec. I defer to Yakov, Sue, Alex,
and Bill for that decision.

Curtis



---------------------------------
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
--0-491911259-1033686700=:78135
Content-Type: text/html; charset=us-ascii

<P>&nbsp;
<P>&nbsp;<B><I>"Natale, Jonathan" <[e-mail]></I></B>wrote:
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">
<P>I don't think it should be mentioned in the base spec.<BR></P>
<P>why not?</P>
<P>Most "major" vendors have extended their decision process (beyond router id check) to include</P>
<P>1) originator ID (to be substituited for router id, when present in&nbsp;&nbsp;&nbsp; path&nbsp;attribute)</P>
<P>2) cluster list length</P>
<P>3) peer id (configured ip address of peer in the neighbor command)</P>
<P>Then why should others have to go to vendors sites and figure out what they have to do to be in compliance with common practice?</P>
<P>Isnt that what the spec is for?</P>
<P><BR>-----Original Message-----<BR>From: Curtis Villamizar [mailto:[e-mail]] <BR>Sent: Thursday, October 03, 2002 3:22 PM<BR>To: vrishab sikand<BR>Cc: Jeffrey Haas; Alex Zinin; Yakov Rekhter; [e-mail]<BR>Subject: Re: issue 11 <BR><BR><BR><BR>In message &lt;[e-mail]&gt;, vrishab<BR>sikand<BR>writes:<BR>&gt; <BR>&gt; --- Jeffrey Haas <[e-mail]>wrote:<BR>&gt; &gt; On Mon, Sep 30, 2002 at 11:20:34AM -0700, Alex Zinin<BR>&gt; &gt; wrote:<BR>&gt; &gt; &gt; BTW, regarding the part of the spec describing the<BR>&gt; &gt; best path selection<BR>&gt; &gt; &gt; algo, I remember there was a concern that it<BR>&gt; &gt; didn't really describe<BR>&gt; &gt; &gt; what vendors actually did. Is it still the case?<BR>&gt; &gt; <BR>&gt; &gt; Cisco has cluster length as part of their<BR>&gt; &gt; tie-breaker.<BR>&gt; &gt; <BR>&gt; &gt; I'm curious about the scenario that is trying to be addressed by <BR>&gt; &gt; this.<BR>&gt; &gt; <BR>&gt; hierarchical route reflector configurations. i.e.<BR>&gt; levels of RR clusters.<BR>&gt; Routes which have come through a no RR are prefferred<BR>&gt; over routes which come over one level of RR, are<BR>&gt; preffered over 2 two levels etc.<BR>&gt; At least one of the biggest ISP's uses RR's in this<BR>&gt; way.<BR>&gt; &gt; &gt; Alex<BR>&gt; &gt; <BR>&gt; &gt; --<BR>&gt; &gt; Jeff Haas <BR>&gt; &gt; NextHop Technologies<BR><BR><BR>It would be useful to add this to the RR RFC.<BR><BR>It could be mentioned in the base spec. I defer to Yakov, Sue, Alex,<BR>and Bill for that decision.<BR><BR>Curtis</P></BLOCKQUOTE><p><br><hr size=1>Do you Yahoo!?<br>
New <a href="http://rd.yahoo.com/evt=1207/*http://sbc.yahoo.com/">DSL Internet Access</a> from SBC & Yahoo!</a>
--0-491911259-1033686700=:78135--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA16286 for <[e-mail]>; Thu, 3 Oct 2002 18:59:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EC7E391376; Thu,  3 Oct 2002 18:58:35 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9C6391375; Thu,  3 Oct 2002 18: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 6C4EE9136C for <[e-mail]>; Thu,  3 Oct 2002 18:58:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 505B35DE3A; Thu,  3 Oct 2002 18:58:27 -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 1CC425DDA1 for <[e-mail]>; Thu,  3 Oct 2002 18:58: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 SAA73877; Thu, 3 Oct 2002 18:57:33 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: "Natale, Jonathan" <[e-mail]>, "'John G. Scudder'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: MED for Originated Routes 
In-reply-to: Your message of "Thu, 03 Oct 2002 18:49:00 EDT." <[e-mail]> 
Date: Thu, 03 Oct 2002 18:57:33 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

I just reread this and I wasn't clear about what I was saying.

If one router does something unusual like puts in MED=10 by default it
would still interoperate fine with other routers.  It might surprise
someone if it replaced another router that didn't do that.

There is no NEED to specify what to put into MED, just how to handle
MED (including whatever MED the router does put in) so that routing
decisions are consistent.

Repeating my last two paragraphs..

   Although there is no NEED for this, some people might find it
   desirable to suggest a default behavior.  If we want to put
   something in, I suggested a brief outline of what implementations
   do, noting that although I thought the text was correct, there was
   no NEED to add any of it.  We now have one variation from that
   which we can reflect in any text we add, if we add any.

   First we have to come to agreement on whether we need to add
   anything at all.

I hope that made more sense.

Curtis


In message <[e-mail]>, Curtis Villamizar 
writes:
> 
> In message <[e-mail]
> or
> ks.com>, "Natale, Jonathan" writes:
> > Since no MED is equivalent to MED = 0 *in this case*, they are
> > interoperable.  But the base spec does not say what to set the
> > MED to for originated routes.  So I need to disagree, an
> > addition to the spec is called for.
> 
> 
> The two implementations don't do exactly the same thing.  They do
> interoperate.  Someone owning some of each may want to know what will
> be sent out by each router.
> 
> There is no need at all for the protocol spec to mandate what should
> be sent out or document what various implementations do in this case.
> The decisions made by routers in a BGP network of any configuration
> will be self-consistent regardless of which behavior is used.  Routing
> decisions will differ slightly if one router is replaced with the
> other, but again will be consistent across the network.
> 
> Although there is no NEED for this, some people might find it
> desirable to suggest a default behavior.  If we want to put something
> in, I suggested a brief outline of what implementations do, noting
> that although I thought the text was correct, there was no NEED to add
> any of it.  We now have one variation from that which we can reflect
> in any text we add, if we add any.
> 
> First we have to come to agreement on whether we need to add anything
> at all.
> 
> Curtis
> 
> 
> > -----Original Message-----
> > From: John G. Scudder [mailto:[e-mail]] 
> > Sent: Thursday, October 03, 2002 5:07 PM
> > To: Natale, Jonathan
> > Cc: '[e-mail]'; Natale, Jonathan; [e-mail]
> > Subject: RE: MED for Originated Routes
> > 
> > 
> > At 4:55 PM -0400 10/3/02, Natale, Jonathan wrote:
> > >Juniper sends no MED for originated routes to IBGP, Cisco sends MED = 0 
> > >for originated routes to IBGP.  So maybe this needs to be clarified in 
> > >the Base spec.
> > 
> > The two behaviors are interoperable.  I don't think any change to the 
> > specification is called for.
> > 
> > --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 SAA15892 for <[e-mail]>; Thu, 3 Oct 2002 18:50:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 42C7091365; Thu,  3 Oct 2002 18:49:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0BBB091369; Thu,  3 Oct 2002 18: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 B37BD91365 for <[e-mail]>; Thu,  3 Oct 2002 18:49:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 95FE75DE3A; Thu,  3 Oct 2002 18:49:53 -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 C51185DDA1 for <[e-mail]>; Thu,  3 Oct 2002 18:49:52 -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 SAA73680; Thu, 3 Oct 2002 18:49:00 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'John G. Scudder'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: MED for Originated Routes 
In-reply-to: Your message of "Thu, 03 Oct 2002 17:30:11 EDT." <[e-mail]> 
Date: Thu, 03 Oct 2002 18:49:00 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> Since no MED is equivalent to MED = 0 *in this case*, they are
> interoperable.  But the base spec does not say what to set the
> MED to for originated routes.  So I need to disagree, an
> addition to the spec is called for.


The two implementations don't do exactly the same thing.  They do
interoperate.  Someone owning some of each may want to know what will
be sent out by each router.

There is no need at all for the protocol spec to mandate what should
be sent out or document what various implementations do in this case.
The decisions made by routers in a BGP network of any configuration
will be self-consistent regardless of which behavior is used.  Routing
decisions will differ slightly if one router is replaced with the
other, but again will be consistent across the network.

Although there is no NEED for this, some people might find it
desirable to suggest a default behavior.  If we want to put something
in, I suggested a brief outline of what implementations do, noting
that although I thought the text was correct, there was no NEED to add
any of it.  We now have one variation from that which we can reflect
in any text we add, if we add any.

First we have to come to agreement on whether we need to add anything
at all.

Curtis


> -----Original Message-----
> From: John G. Scudder [mailto:[e-mail]] 
> Sent: Thursday, October 03, 2002 5:07 PM
> To: Natale, Jonathan
> Cc: '[e-mail]'; Natale, Jonathan; [e-mail]
> Subject: RE: MED for Originated Routes
> 
> 
> At 4:55 PM -0400 10/3/02, Natale, Jonathan wrote:
> >Juniper sends no MED for originated routes to IBGP, Cisco sends MED = 0 
> >for originated routes to IBGP.  So maybe this needs to be clarified in 
> >the Base spec.
> 
> The two behaviors are interoperable.  I don't think any change to the 
> specification is called for.
> 
> --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 SAA15270 for <[e-mail]>; Thu, 3 Oct 2002 18:37:15 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 42FC19136E; Thu,  3 Oct 2002 18:36:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3A0C9136B; Thu,  3 Oct 2002 18: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 E4B299136A for <[e-mail]>; Thu,  3 Oct 2002 18:36:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C0CD35DE48; Thu,  3 Oct 2002 18:36:09 -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 F20925DDA1 for <[e-mail]>; Thu,  3 Oct 2002 18:36:08 -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 SAA73622; Thu, 3 Oct 2002 18:35:19 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Jeffrey Haas'" <[e-mail]>, [e-mail], [e-mail]
Reply-To: [e-mail]
Subject: Re: New Issue AS path 
In-reply-to: Your message of "Thu, 03 Oct 2002 17:06:59 EDT." <[e-mail]> 
Date: Thu, 03 Oct 2002 18:35:18 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> What about the fact that an AS_SET counts as 1 (in IOS)???  Is that already
> in the spec?

That's in 9.1.2.2:

      a) Remove from consideration all routes which are not tied for
      having the smallest number of AS numbers present in their AS_PATH
      attributes. Note, that when counting this number, an AS_SET counts
      as 1, no matter how many ASs are in the set, and that, if the
      implementation supports [13], then AS numbers present in segments
      of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in
      the count of AS numbers present in the AS_PATH.

> Does juniper set AS_CONFED_SEQUENCE to 0 too?

I'd say yes but don't know for sure.

> What about AS_CONFED_SETs?  Does anybody use these?

Don't think that's every used, but if so if AS_CONFED_SEQUENCE is not
counted, it would apply to AS_CONFED_SET.

> I don't think we want to put stuff in [to the draft] just because IOS does
> it; it might be nice to put stuff in that covers Juniper and IOS, if and
> only if it affect interoperability.

It looks like it is already covered in draft-17.  See above.

Curtis


> -----Original Message-----
> From: Jeffrey Haas [mailto:[e-mail]] 
> Sent: Thursday, October 03, 2002 3:28 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: issue 11
> 
> 
> On Thu, Oct 03, 2002 at 03:22:02PM -0400, Curtis Villamizar wrote:
> > It would be useful to add this to the RR RFC.
> 
> That would be my preferred action.
> 
> However, I would also prefer that the AS_PATH length calculation for
> confederation segments (i.e. they have zero value) also be moved into the
> confed update.
> 
> > 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 SAA13496 for <[e-mail]>; Thu, 3 Oct 2002 18:00:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5A0C99135F; Thu,  3 Oct 2002 17:59:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 333BE91360; Thu,  3 Oct 2002 17:59: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 8384A9135F for <[e-mail]>; Thu,  3 Oct 2002 17:59:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 66D915DE48; Thu,  3 Oct 2002 17:59: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 76FCF5DE39 for <[e-mail]>; Thu,  3 Oct 2002 17:59:39 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g93Lxcr60977; Thu, 3 Oct 2002 17:59:38 -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 g93LxWC60965; Thu, 3 Oct 2002 17:59:32 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g93LxWM16745; Thu, 3 Oct 2002 17:59:32 -0400 (EDT)
Date: Thu, 3 Oct 2002 17:59:32 -0400
From: Mathew Richardson <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: Re: New Issue AS path
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]> [Thu, Oct 03, 2002 at 05:31:59PM -0400]:
>So what about AS_CONFED_SETs?  Are they 1 or 0?

<since>

No confederation segments count towards the path length.

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 RAA13451 for <[e-mail]>; Thu, 3 Oct 2002 17:59:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5FDBE9135E; Thu,  3 Oct 2002 17:59:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 28CEC9135F; Thu,  3 Oct 2002 17:59: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 EB0059135E for <[e-mail]>; Thu,  3 Oct 2002 17:59:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D1AAD5DE48; Thu,  3 Oct 2002 17:59: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 EB3E75DE39 for <[e-mail]>; Thu,  3 Oct 2002 17:59:20 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g93LwYE60940; Thu, 3 Oct 2002 17:58: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 g93LwVC60932; Thu, 3 Oct 2002 17:58:31 -0400 (EDT) (envelope-from [e-mail])
Received: (from mrr@localhost) by paradigm.nexthop.com (8.11.6/8.11.6) id g93LwVs16739; Thu, 3 Oct 2002 17:58:31 -0400 (EDT)
Date: Thu, 3 Oct 2002 17:58:31 -0400
From: Mathew Richardson <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: "'John G. Scudder'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: MED for Originated Routes
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]> [Thu, Oct 03, 2002 at 05:30:11PM -0400]:
>Since no MED is equivalent to MED = 0 *in this case*, they are
>interoperable.  But the base spec does not say what to set the
>MED to for originated routes.  So I need to disagree, an
>addition to the spec is called for.

<snip>

The absence of an MED is equivalent to a MED of zero in all cases.

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 RAA12417 for <[e-mail]>; Thu, 3 Oct 2002 17:36:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2B00391373; Thu,  3 Oct 2002 17:35:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6682D9136C; Thu,  3 Oct 2002 17: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 117CE9135C for <[e-mail]>; Thu,  3 Oct 2002 17:32:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EB7BA5DE4A; Thu,  3 Oct 2002 17:32: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 6E2315DDA1 for <[e-mail]>; Thu,  3 Oct 2002 17:32:00 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12X7J>; Thu, 3 Oct 2002 17:31:59 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: New Issue AS path
Date: Thu, 3 Oct 2002 17:31:59 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

So what about AS_CONFED_SETs?  Are they 1 or 0?

-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Thursday, October 03, 2002 5:21 PM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: New Issue AS path


On Thu, Oct 03, 2002 at 05:06:59PM -0400, Natale, Jonathan wrote:
> What about the fact that an AS_SET counts as 1 (in IOS)???  Is that 
> already in the spec?

That got moved into the spec.  It even makes sense, even it means aggregates
that aggregate as_paths may have shorter paths than their contributing
routes.

> What about AS_CONFED_SETs?  Does anybody use these?

GateD supports these.

> I don't think we want to put stuff in [to the draft] just because IOS 
> does it; it might be nice to put stuff in that covers Juniper and IOS, 
> if and only if it affect interoperability.

Things that affect route selection affect everyone.  Its best to be
consistant.

-- 
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 RAA12153 for <[e-mail]>; Thu, 3 Oct 2002 17:31:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 188FA9135D; Thu,  3 Oct 2002 17:30:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CDBB9135E; Thu,  3 Oct 2002 17: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 762B49135D for <[e-mail]>; Thu,  3 Oct 2002 17:30:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 84AE25DE4A; Thu,  3 Oct 2002 17:30: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 D998F5DDA1 for <[e-mail]>; Thu,  3 Oct 2002 17:30:13 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12X7B>; Thu, 3 Oct 2002 17:30:12 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'John G. Scudder'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, [e-mail]
Subject: RE: MED for Originated Routes
Date: Thu, 3 Oct 2002 17:30:11 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Since no MED is equivalent to MED = 0 *in this case*, they are
interoperable.  But the base spec does not say what to set the
MED to for originated routes.  So I need to disagree, an
addition to the spec is called for.


-----Original Message-----
From: John G. Scudder [mailto:[e-mail]] 
Sent: Thursday, October 03, 2002 5:07 PM
To: Natale, Jonathan
Cc: '[e-mail]'; Natale, Jonathan; [e-mail]
Subject: RE: MED for Originated Routes


At 4:55 PM -0400 10/3/02, Natale, Jonathan wrote:
>Juniper sends no MED for originated routes to IBGP, Cisco sends MED = 0 
>for originated routes to IBGP.  So maybe this needs to be clarified in 
>the Base spec.

The two behaviors are interoperable.  I don't think any change to the 
specification is called for.

--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 RAA11732 for <[e-mail]>; Thu, 3 Oct 2002 17:21:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5227F91359; Thu,  3 Oct 2002 17:21:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1751B9135A; Thu,  3 Oct 2002 17: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 A6F3B91359 for <[e-mail]>; Thu,  3 Oct 2002 17:21:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 92FCC5DE0A; Thu,  3 Oct 2002 17:21: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 AD82B5DDA1 for <[e-mail]>; Thu,  3 Oct 2002 17:21:15 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g93LLDF59833; Thu, 3 Oct 2002 17:21: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 g93LL9C59826; Thu, 3 Oct 2002 17:21:09 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g93LL9K02743; Thu, 3 Oct 2002 17:21:09 -0400 (EDT)
Date: Thu, 3 Oct 2002 17:21:09 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: New Issue AS path
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, Oct 03, 2002 at 05:06:59PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Oct 03, 2002 at 05:06:59PM -0400, Natale, Jonathan wrote:
> What about the fact that an AS_SET counts as 1 (in IOS)???  Is that already
> in the spec?

That got moved into the spec.  It even makes sense, even it means
aggregates that aggregate as_paths may have shorter paths than
their contributing routes.

> What about AS_CONFED_SETs?  Does anybody use these?

GateD supports these.

> I don't think we want to put stuff in [to the draft] just because IOS does
> it; it might be nice to put stuff in that covers Juniper and IOS, if and
> only if it affect interoperability.

Things that affect route selection affect everyone.  Its best to be
consistant.

-- 
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 RAA11054 for <[e-mail]>; Thu, 3 Oct 2002 17:07:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8044F91357; Thu,  3 Oct 2002 17:07:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3289E91354; Thu,  3 Oct 2002 17:07: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 0F43991351 for <[e-mail]>; Thu,  3 Oct 2002 17:07:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E3F035DE55; Thu,  3 Oct 2002 17:07:28 -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 271225DE0A for <[e-mail]>; Thu,  3 Oct 2002 17:07:28 -0400 (EDT)
Received: from [192.168.42.10] (dhcp-171-69-182-161.cisco.com [171.69.182.161]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA26877; Thu, 3 Oct 2002 17:07:02 -0400 (EDT)
Mime-Version: 1.0
X-Sender: jgs@router
Message-Id: <p05111a3cb9c260e8d27a@[192.168.42.10]>
In-Reply-To:  <[e-mail] >
References:  <[e-mail] >
Date: Thu, 3 Oct 2002 17:06:48 -0400
To: "Natale, Jonathan" <[e-mail]>
From: "John G. Scudder" <[e-mail]>
Subject: RE: MED for Originated Routes
Cc: "'[e-mail]'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 4:55 PM -0400 10/3/02, Natale, Jonathan wrote:
>Juniper sends no MED for originated routes to IBGP, Cisco sends MED = 0 for
>originated routes to IBGP.  So maybe this needs to be clarified in the Base
>spec.

The two behaviors are interoperable.  I don't think any change to the 
specification is called for.

--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 RAA11030 for <[e-mail]>; Thu, 3 Oct 2002 17:07:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0F1289134D; Thu,  3 Oct 2002 17:07:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC40991351; Thu,  3 Oct 2002 17:07: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 8BFB29134D for <[e-mail]>; Thu,  3 Oct 2002 17:07:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 71F285DE0A; Thu,  3 Oct 2002 17:07: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 2D0B25DE04 for <[e-mail]>; Thu,  3 Oct 2002 17:07:01 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12XZP>; Thu, 3 Oct 2002 17:07:00 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: New Issue AS path
Date: Thu, 3 Oct 2002 17:06:59 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

What about the fact that an AS_SET counts as 1 (in IOS)???  Is that already
in the spec?

Does juniper set AS_CONFED_SEQUENCE to 0 too?

What about AS_CONFED_SETs?  Does anybody use these?

I don't think we want to put stuff in [to the draft] just because IOS does
it; it might be nice to put stuff in that covers Juniper and IOS, if and
only if it affect interoperability.

-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Thursday, October 03, 2002 3:28 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: issue 11


On Thu, Oct 03, 2002 at 03:22:02PM -0400, Curtis Villamizar wrote:
> It would be useful to add this to the RR RFC.

That would be my preferred action.

However, I would also prefer that the AS_PATH length calculation for
confederation segments (i.e. they have zero value) also be moved into the
confed update.

> 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 RAA10892 for <[e-mail]>; Thu, 3 Oct 2002 17:04:29 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F205C9134F; Thu,  3 Oct 2002 17:03:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7FE691353; Thu,  3 Oct 2002 17:03: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 0D1A89134D for <[e-mail]>; Thu,  3 Oct 2002 17:03:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DD5295DE39; Thu,  3 Oct 2002 17:03:05 -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 164DE5DE04 for <[e-mail]>; Thu,  3 Oct 2002 17:03:05 -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 RAA72993; Thu, 3 Oct 2002 17:02:17 -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: MED for Originated Routes 
In-reply-to: Your message of "Thu, 03 Oct 2002 16:55:19 EDT." <[e-mail]> 
Date: Thu, 03 Oct 2002 17:02:17 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> I checked this.
> 
> Juniper sends no MED for originated routes to IBGP, Cisco sends MED = 0 for
> originated routes to IBGP.  So maybe this needs to be clarified in the Base
> spec.


I don't see an interoperability problem with that.

The question still stands - do we need to put anything about this in
the base spec?  Alex - your opinion?

Curtis


> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]] 
> Sent: Wednesday, October 02, 2002 11:46 PM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: MED for Originated Routes 
> 
> 
> 
> In message
> <[e-mail]
> ks.com>, "Natale, Jonathan" writes:
> > 
> > What should the MED be for originated routes to IBGP?  No Med?  All 
> > 1's? Configurable?  Is it in the draft?  Is this a new issue?  Do you 
> > want more questions?
> 
> I didn't look this up in the draft yet, but the answer is:
> 
>   for IBGP:
> 
>    The MED you got from EBGP (if any)
> 
>    or configurable:
> 
>      strip off MED (if any)
>      or configure a MED
> 
>   originating to IBGP, use no MED or configure one.
> 
>   for EBGP (IBGP learned or originating):
> 
>     default to no MED
> 
>     or configurable:
> 
>      put IGP cost into MED
>      or configure a MED
> 
> That in a nutshell is what implementations do (AFAIK).
> 
> I don't think this level of detail needs to go into the protocol spec. But
> I've been on the minority end of the consensus before so...  first lets ask
> if we need this level of detail.  I think no.  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 RAA10760 for <[e-mail]>; Thu, 3 Oct 2002 17:02:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 772D89134E; Thu,  3 Oct 2002 17:01:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31F8F9134F; Thu,  3 Oct 2002 17:01: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 8B9C09134E for <[e-mail]>; Thu,  3 Oct 2002 17:01:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6AAC85DE4A; Thu,  3 Oct 2002 17:01: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 26A4B5DE39 for <[e-mail]>; Thu,  3 Oct 2002 17:01:07 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12XYM>; Thu, 3 Oct 2002 17:01:06 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: issue 11
Date: Thu, 3 Oct 2002 17:01:06 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Folks,

It may be better if we keep each thread to one Issue.

-Jonathan

-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Thursday, October 03, 2002 3:28 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: issue 11


On Thu, Oct 03, 2002 at 03:22:02PM -0400, Curtis Villamizar wrote:
> It would be useful to add this to the RR RFC.

That would be my preferred action.

However, I would also prefer that the AS_PATH length calculation for
confederation segments (i.e. they have zero value) also be moved into the
confed update.

> 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 QAA10410 for <[e-mail]>; Thu, 3 Oct 2002 16:55:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 148599134A; Thu,  3 Oct 2002 16:55:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF8DD9134D; Thu,  3 Oct 2002 16:55: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 70F4D9134A for <[e-mail]>; Thu,  3 Oct 2002 16:55:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4D9DA5DE39; Thu,  3 Oct 2002 16:55: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 0882A5DE04 for <[e-mail]>; Thu,  3 Oct 2002 16:55:21 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12XXK>; Thu, 3 Oct 2002 16:55:20 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: MED for Originated Routes 
Date: Thu, 3 Oct 2002 16: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

I checked this.

Juniper sends no MED for originated routes to IBGP, Cisco sends MED = 0 for
originated routes to IBGP.  So maybe this needs to be clarified in the Base
spec.

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 11:46 PM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: MED for Originated Routes 



In message
<[e-mail]
ks.com>, "Natale, Jonathan" writes:
> 
> What should the MED be for originated routes to IBGP?  No Med?  All 
> 1's? Configurable?  Is it in the draft?  Is this a new issue?  Do you 
> want more questions?

I didn't look this up in the draft yet, but the answer is:

  for IBGP:

   The MED you got from EBGP (if any)

   or configurable:

     strip off MED (if any)
     or configure a MED

  originating to IBGP, use no MED or configure one.

  for EBGP (IBGP learned or originating):

    default to no MED

    or configurable:

     put IGP cost into MED
     or configure a MED

That in a nutshell is what implementations do (AFAIK).

I don't think this level of detail needs to go into the protocol spec. But
I've been on the minority end of the consensus before so...  first lets ask
if we need this level of detail.  I think no.  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 QAA10255 for <[e-mail]>; Thu, 3 Oct 2002 16:52:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2382791330; Thu,  3 Oct 2002 16:51:55 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2BC99134A; Thu,  3 Oct 2002 16:51: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 8607D91330 for <[e-mail]>; Thu,  3 Oct 2002 16:51:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5A54A5DE04; Thu,  3 Oct 2002 16:51: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 19F835DDA1 for <[e-mail]>; Thu,  3 Oct 2002 16:51:53 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12XW6>; Thu, 3 Oct 2002 16:51:52 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, vrishab sikand <[e-mail]>
Cc: Jeffrey Haas <[e-mail]>, Alex Zinin <[e-mail]>, Yakov Rekhter <[e-mail]>, [e-mail]
Subject: RE: issue 11 
Date: Thu, 3 Oct 2002 16:51:52 -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 it should be mentioned in the base spec.

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Thursday, October 03, 2002 3:22 PM
To: vrishab sikand
Cc: Jeffrey Haas; Alex Zinin; Yakov Rekhter; [e-mail]
Subject: Re: issue 11 



In message <[e-mail]>, vrishab
sikand
 writes:
> 
> --- Jeffrey Haas <[e-mail]> wrote:
> > On Mon, Sep 30, 2002 at 11:20:34AM -0700, Alex Zinin
> > wrote:
> > > 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?
> > 
> > Cisco has cluster length as part of their
> > tie-breaker.
> > 
> > I'm curious about the scenario that is trying to be addressed by 
> > this.
> > 
> hierarchical route reflector configurations. i.e.
> levels of RR clusters.
> Routes which have come through a no RR are prefferred
> over routes which come over one level of RR, are
> preffered over 2 two levels etc.
>   At least one of the biggest ISP's uses RR's in this
> way.
> > > Alex
> > 
> > --
> > Jeff Haas 
> > NextHop Technologies


It would be useful to add this to the RR RFC.

It could be mentioned in the base spec.  I defer to Yakov, Sue, Alex,
and Bill for that decision.

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 PAA06233 for <[e-mail]>; Thu, 3 Oct 2002 15:28:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8786E91345; Thu,  3 Oct 2002 15:28:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5AD8091344; Thu,  3 Oct 2002 15:28: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 D02CA91343 for <[e-mail]>; Thu,  3 Oct 2002 15:28:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B4D155DE35; Thu,  3 Oct 2002 15:28: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 32DF95DE27 for <[e-mail]>; Thu,  3 Oct 2002 15:28:15 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g93JS5u56414; Thu, 3 Oct 2002 15:28: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 g93JS1C56407; Thu, 3 Oct 2002 15:28:01 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g93JS1800507; Thu, 3 Oct 2002 15:28:01 -0400 (EDT)
Date: Thu, 3 Oct 2002 15:28:01 -0400
From: Jeffrey Haas <[e-mail]>
To: [e-mail]
Cc: [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 Thu, Oct 03, 2002 at 03:22:02PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Thu, Oct 03, 2002 at 03:22:02PM -0400, Curtis Villamizar wrote:
> It would be useful to add this to the RR RFC.

That would be my preferred action.

However, I would also prefer that the AS_PATH length calculation
for confederation segments (i.e. they have zero value) also be
moved into the confed update.

> 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 PAA05967 for <[e-mail]>; Thu, 3 Oct 2002 15:23:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id E0C0191341; Thu,  3 Oct 2002 15:22:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AFD8F91342; Thu,  3 Oct 2002 15:22: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 553A491341 for <[e-mail]>; Thu,  3 Oct 2002 15:22:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 36A835DE3B; Thu,  3 Oct 2002 15:22:56 -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 551C35DE35 for <[e-mail]>; Thu,  3 Oct 2002 15:22:55 -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 PAA72247; Thu, 3 Oct 2002 15:22:02 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: vrishab sikand <[e-mail]>
Cc: Jeffrey Haas <[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 "Thu, 03 Oct 2002 11:17:55 PDT." <[e-mail]> 
Date: Thu, 03 Oct 2002 15:22:02 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, vrishab sikand
 writes:
> 
> --- Jeffrey Haas <[e-mail]> wrote:
> > On Mon, Sep 30, 2002 at 11:20:34AM -0700, Alex Zinin
> > wrote:
> > > 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?
> > 
> > Cisco has cluster length as part of their
> > tie-breaker.
> > 
> > I'm curious about the scenario that is trying to be
> > addressed by this.
> > 
> hierarchical route reflector configurations. i.e.
> levels of RR clusters.
> Routes which have come through a no RR are prefferred
> over routes which come over one level of RR, are
> preffered over 2 two levels etc.
>   At least one of the biggest ISP's uses RR's in this
> way.
> > > Alex
> > 
> > -- 
> > Jeff Haas 
> > NextHop Technologies


It would be useful to add this to the RR RFC.

It could be mentioned in the base spec.  I defer to Yakov, Sue, Alex,
and Bill for that decision.

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 OAA03350 for <[e-mail]>; Thu, 3 Oct 2002 14:32:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 494569133B; Thu,  3 Oct 2002 14:31:16 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1FDB9133A; Thu,  3 Oct 2002 14: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 52BBD9133B for <[e-mail]>; Thu,  3 Oct 2002 14:31:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 346605DDE8; Thu,  3 Oct 2002 14:31: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 B01D05DDBF for <[e-mail]>; Thu,  3 Oct 2002 14:31: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 OAA16981; Thu, 3 Oct 2002 14:31: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 OAA13614; Thu, 3 Oct 2002 14:31:08 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7Q5BX>; Thu, 3 Oct 2002 14:31:03 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Manav Bhatia'" <[e-mail]>, BGP mailing list <[e-mail]>
Subject: RE: Active Route 
Date: Thu, 3 Oct 2002 14:31: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

I am not advocating that people do this, just that the knob is there and
we need to add a caution against it. Eventually the knob should be removed
by sensible vendors.

That is all,
Ben

> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Thursday, October 03, 2002 2:27 PM
> To: Abarbanel, Benjamin
> Cc: 'Manav Bhatia'; [e-mail]; BGP mailing list
> Subject: Re: Active Route 
> 
> 
> 
> In message 
> <[e-mail]>, 
> "Abarbanel, Benjamin" writes:
> > The world is too big and complex and it is too difficult to 
> make one size
> > fit all solution work. I guess that is why they have not 
> depracated the 
> > redistribution from BGP to IGP feature happen. IMHO, as 
> long as the main
> > stream vendors still support the feature, we must consider 
> it as a viable
> > configuration. To say your network is broken if you use it, 
> is a bit over
> > stating it. I would rather we add cautionary comments in 
> the base spec for
> > things like this that can lead into possible trouble.
> > 
> > End of Commentary,
> > Ben
> 
> 
> Ben,
> 
> If you've ever seen the results of injecting BGP into the IGP in an
> ISP network you'd know that it isn't something you'd want to do again.
> 
> The hacks for using BGP in an incomplete BGP mesh (to accommodate a
> deficient router) should be out of scope for the protocol specs.
> 
> I don't think its productive to continue this discussion so I won't
> comment further.
> 
> Curtis
> 
> 
> > > -----Original Message-----
> > > From: Manav Bhatia [mailto:[e-mail]]
> > > Sent: Thursday, October 03, 2002 6:49 AM
> > > To: [e-mail]; Abarbanel, Benjamin
> > > Cc: BGP mailing list
> > > Subject: Re: Active Route
> > > 
> > > 
> > > Curtis,
> > > | >
> > > | > What if your AS is not fully meshed as Hans pointed out?
> > > | >
> > > | > The only way to get external BGP routes to non-BGP (IGP 
> > > only) routers
> > > is by
> > > | > redistributing them via IGP, and let IGP flood them, right?
> > > |
> > > 
> > > [clipped]
> > > 
> > > | The stance as far as the protocol spec goes is that BGP/IGP
> > > | interactions are out of scope.  Special cases to 
> support a broken AS
> > > | (one with incomplete IBGP connectivity) is definitely 
> out of scope.
> > > |
> > > 
> > > What if i have one non BGP speaking router lying in 
> between the 2 BGP
> > > speaking routers carrying transit traffic. I dont think its a 
> > > broken AS if
> > > i have this kind of topology. Things will work in this case 
> > > by adding a
> > > default route here on this transit non BGP speaking router. 
> > > But it can turn
> > > really messy if the number of such transit non BGP 
> routers increase.
> > > 
> > > |
> > > | I did mention it with the intent to show that it borders on 
> > > ridiculous
> > > | to try to accommodate all ways in which you can build a 
> semi-broken
> > > | BGP network or build one with semi-broken equipment and 
> get it to
> > > | actually work.  We seem to agree that we don't want to 
> go down that
> > > | road, either enumerating all of the cases or with the 
> > > general caveat.
> > > 
> > > same comments as above.
> > > 
> > > 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 OAA03075 for <[e-mail]>; Thu, 3 Oct 2002 14:27:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5DB1691339; Thu,  3 Oct 2002 14:27:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22B909133A; Thu,  3 Oct 2002 14: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 A3CCB91339 for <[e-mail]>; Thu,  3 Oct 2002 14:27:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 801EF5DDE6; Thu,  3 Oct 2002 14:27: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 5EEEA5DDBF for <[e-mail]>; Thu,  3 Oct 2002 14:27: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 OAA71955; Thu, 3 Oct 2002 14:26:33 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'Manav Bhatia'" <[e-mail]>, [e-mail], BGP mailing list <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Active Route 
In-reply-to: Your message of "Thu, 03 Oct 2002 10:52:15 EDT." <[e-mail]> 
Date: Thu, 03 Oct 2002 14:26:33 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> The world is too big and complex and it is too difficult to make one size
> fit all solution work. I guess that is why they have not depracated the 
> redistribution from BGP to IGP feature happen. IMHO, as long as the main
> stream vendors still support the feature, we must consider it as a viable
> configuration. To say your network is broken if you use it, is a bit over
> stating it. I would rather we add cautionary comments in the base spec for
> things like this that can lead into possible trouble.
> 
> End of Commentary,
> Ben


Ben,

If you've ever seen the results of injecting BGP into the IGP in an
ISP network you'd know that it isn't something you'd want to do again.

The hacks for using BGP in an incomplete BGP mesh (to accommodate a
deficient router) should be out of scope for the protocol specs.

I don't think its productive to continue this discussion so I won't
comment further.

Curtis


> > -----Original Message-----
> > From: Manav Bhatia [mailto:[e-mail]]
> > Sent: Thursday, October 03, 2002 6:49 AM
> > To: [e-mail]; Abarbanel, Benjamin
> > Cc: BGP mailing list
> > Subject: Re: Active Route
> > 
> > 
> > Curtis,
> > | >
> > | > What if your AS is not fully meshed as Hans pointed out?
> > | >
> > | > The only way to get external BGP routes to non-BGP (IGP 
> > only) routers
> > is by
> > | > redistributing them via IGP, and let IGP flood them, right?
> > |
> > 
> > [clipped]
> > 
> > | The stance as far as the protocol spec goes is that BGP/IGP
> > | interactions are out of scope.  Special cases to support a broken AS
> > | (one with incomplete IBGP connectivity) is definitely out of scope.
> > |
> > 
> > What if i have one non BGP speaking router lying in between the 2 BGP
> > speaking routers carrying transit traffic. I dont think its a 
> > broken AS if
> > i have this kind of topology. Things will work in this case 
> > by adding a
> > default route here on this transit non BGP speaking router. 
> > But it can turn
> > really messy if the number of such transit non BGP routers increase.
> > 
> > |
> > | I did mention it with the intent to show that it borders on 
> > ridiculous
> > | to try to accommodate all ways in which you can build a semi-broken
> > | BGP network or build one with semi-broken equipment and get it to
> > | actually work.  We seem to agree that we don't want to go down that
> > | road, either enumerating all of the cases or with the 
> > general caveat.
> > 
> > same comments as above.
> > 
> > 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 OAA02660 for <[e-mail]>; Thu, 3 Oct 2002 14:19:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1DA6C91335; Thu,  3 Oct 2002 14:18:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DAE6B91337; Thu,  3 Oct 2002 14:18: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 27A1B91335 for <[e-mail]>; Thu,  3 Oct 2002 14:17:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DEEBE5DDE7; Thu,  3 Oct 2002 14:17:56 -0400 (EDT)
Delivered-To: [e-mail]
Received: from web12808.mail.yahoo.com (web12808.mail.yahoo.com [216.136.174.43]) by segue.merit.edu (Postfix) with SMTP id 5F6B35DDE6 for <[e-mail]>; Thu,  3 Oct 2002 14:17:56 -0400 (EDT)
Message-ID: <[e-mail]>
Received: from [208.246.215.128] by web12808.mail.yahoo.com via HTTP; Thu, 03 Oct 2002 11:17:55 PDT
Date: Thu, 3 Oct 2002 11:17:55 -0700 (PDT)
From: vrishab sikand <[e-mail]>
Subject: Re: issue 11
To: Jeffrey Haas <[e-mail]>, Alex Zinin <[e-mail]>
Cc: Yakov Rekhter <[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

--- Jeffrey Haas <[e-mail]> wrote:
> On Mon, Sep 30, 2002 at 11:20:34AM -0700, Alex Zinin
> wrote:
> > 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?
> 
> Cisco has cluster length as part of their
> tie-breaker.
> 
> I'm curious about the scenario that is trying to be
> addressed by this.
> 
hierarchical route reflector configurations. i.e.
levels of RR clusters.
Routes which have come through a no RR are prefferred
over routes which come over one level of RR, are
preffered over 2 two levels etc.
  At least one of the biggest ISP's uses RR's in this
way.
> > Alex
> 
> -- 
> Jeff Haas 
> NextHop Technologies


__________________________________________________
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 MAA26212 for <[e-mail]>; Thu, 3 Oct 2002 12:09:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6721C91340; Thu,  3 Oct 2002 12:06:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C77D9133C; Thu,  3 Oct 2002 12:06: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 D300F91334 for <[e-mail]>; Thu,  3 Oct 2002 12:04:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C40765DDD7; Thu,  3 Oct 2002 12:04: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 8095C5DDAA for <[e-mail]>; Thu,  3 Oct 2002 12:04:47 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12WLS>; Thu, 3 Oct 2002 12:04:46 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: Issue 32.1
Date: Thu, 3 Oct 2002 12:04:44 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Folks,

Here is an example of a confused person (see bellow).  AGAIN, I propsed we

CHANGE:

   "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."
(--current consensus(???), if I send the above to this person
he may still be confused)

TO:

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

-or-

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



Example Confused Person (sorry for making an example out of you, Mallika):

-----Original Message-----
From: mallika gautam [mailto:[e-mail]] 
Sent: Thursday, October 03, 2002 4:29 AM
To: [e-mail]
Subject: [isp-bgp] Origin value as EGP




Hi All,
The origin attribute takes values as IGP, EGP or
Incomplete. According to the text given on this topic,
IGP is when the path information is originated within
an AS. EGP, when it is learned from some other AS and Incomplete, when the
information is learnt by other means. A very elementary qn. in this regards
is whether the update coming from an EBGP peer have the origin field as EGP,
if the sending AS comes to know about this path from some 3rd AS. 

ie. 

ASN 100 learns a path from ASN 200 and then ASN 100
sends it to ASN 300. Then will the path which ASN 300
finally receive from ASN 100 has the origin attribute
as EGP.

If this is not true then can anybody pl. suggest a
scenerio when the route information will have EGP as
the origin field value.

Thanks
Mallika



(Note:  This also disproves the contention that RFCs are for DE's
[only]--they are also for CE's, SE's, QE's, FE's, 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 LAA24654 for <[e-mail]>; Thu, 3 Oct 2002 11:36:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 76D219132B; Thu,  3 Oct 2002 11:34:00 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF2209132C; Thu,  3 Oct 2002 11:33: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 3E2909132B for <[e-mail]>; Thu,  3 Oct 2002 11:33:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2264E5DDD7; Thu,  3 Oct 2002 11:33: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 9D3085DDBF for <[e-mail]>; Thu,  3 Oct 2002 11:33: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 LAA05775; Thu, 3 Oct 2002 11:33: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 LAA09170; Thu, 3 Oct 2002 11:33:35 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7QQRK>; Thu, 3 Oct 2002 11:33:32 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, BGP mailing list <[e-mail]>
Subject: RE: Active Route - OT
Date: Thu, 3 Oct 2002 11:33: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

Hans:

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Thursday, October 03, 2002 9:09 AM
> To: BGP mailing list
> Subject: Re: Active Route - OT
> 
> 
> All,
> 
> thanks for your feedback on this.  Now I tend to be  more in 
> favor of  leaving
> the text  and the restriction in the RFC.  The reasons i see 
> for this are:
> 
> 1. The effective use of policy is endangered. Supose a bgp 
> speaker announces to
> its external peer reachability for a route, and indicates 
> that this route
> passes through AS 1,2 and 3, while at the same time the FIB 
> of the same router
> would actually send the traffic so that in the end it follows 
> another path
> passing through a different set of ASses.  If this is allowed 
> why would we even
> bother to pass along attributes? (Also I learned of some 
> people trying to make
> tools that use the BGP RIB to figure out how traffic is flowing in the
> internet).
> 

According to Dennis you are gauranteed that the mix of BGP and IGP routing
will prevent any possible loops and get the packet to its destination. It
does not gaurantee that the packet will travel the AS_PATH defined in the 
(i/e)BGP route. Thus, in a way it works and it doesn't, if you are picky
about the attributes. IMHO, there should be a way to flag that suboptimal
routing is
taking place with this route so that any external peers can make a judgement
call on the validity of the route provided. For example, lets say a peer 
knows that this IBGP route is not really used for forwarding but an IGP
route
is for the same destination, it could flag the route with a new attribute
saying that suboptimal routing path is used with this route. The external
peer receiving the route can reduce its priority so that the BGP decision
process can pick another route over this one, thus avoiding the less
deterministic behavior. 

Your comment?

Ben

 
> thanks
> ---
> Hans De Vleeschouwer
> 
> > "Natale, Jonathan" wrote:
> >
> > > "What if your AS is not fully meshed as Hans pointed out?"
> > >
> > > Then you are mis-configured.
> > >
> > > Also, I agree with Curtis--redistributing BGP into IGP is 
> a bad idea.  A
> > > much better idea is to turn off synchronization (rumor 
> was that it will
> > > be/is off by default in newer IOS).  Juniper does not 
> even have a synch
> > > concept (a good thing).
> > >
> > > -----Original Message-----
> > > From: Abarbanel, Benjamin [mailto:[e-mail]]
> > > Sent: Wednesday, October 02, 2002 12:41 PM
> > > To: '[e-mail]'; [e-mail]
> > > Cc: BGP mailing list
> > > Subject: RE: Active Route
> > >
> > > Curtis
> > >
> > > > -----Original Message-----
> > > > From: Curtis Villamizar [mailto:[e-mail]]
> > > > Sent: Wednesday, October 02, 2002 12:33 PM
> > > > To: [e-mail]
> > > > Cc: BGP mailing list
> > > > Subject: Re: Active Route
> > > >
> > > >
> > > >
> > > > In message <[e-mail]>,
> > > > [e-mail] writ
> > > > es:
> > > > >
> > > > > Then I redistribute the routes into IGP, and at the same
> > > > time I forward
> > > > > the routes via IBGP (not full mesh) to all of the other AS
> > > > border routers (bu
> > > > > t
> > > > > to no other routers).
> > > >
> > > > This is an incredibly bad idea.  Only the BGP next_hop 
> needs to be in
> > > > the IGP.
> > > >
> > > > > At the other side of my AS, I allow the border router
> > > > (router B) to pass thos
> > > > > e
> > > > > routes learned via IBGP (form router A) to the (next) AS
> > > > via an EBGP connecti
> > > > > on.
> > > > > (I am using the  "synchronise BGP = TRUE" option.)
> > > >
> > > > Synchronise implies that the BGP next_hop is reachable 
> via the IGP
> > > > *not* the BGP prefix itself.
> > > >
> > > > There is never a need to put the destination prefix 
> into the IGP if it
> > > > is carried in IBGP except for the case where you are 
> originating a
> > > > prefix and you want it to go out with specific 
> attributes such as
> > > > specific BGP communities or indicate through BGP 
> communities some
> > > > special action such as punching a hole in an aggregate.
> > > >
> > >
> > > What if your AS is not fully meshed as Hans pointed out?
> > >
> > > The only way to get external BGP routes to non-BGP (IGP 
> only) routers is by
> > > redistributing them via IGP, and let IGP flood them, right?
> > >
> > > > > Now in this fairly straightforward example, the router B
> > > > will forward routes
> > > > > learned via IBGP to the next AS using EBGP, whereas for
> > > > those routes the
> > > > > reachability in the FIB is taken care of by IGP (who has
> > > > typically a higher
> > > > > preference in ther FIB then IBGP).
> > > > >
> > > > > So, in theory the rule : "one must focus on the rule that a
> > > > BGP speaker
> > > > > advertises to its peers  in neighboring ASs only those
> > > > routes that it itself
> > > > > uses." is broken, since it is clearly an IGP route 
> which in the FIB.
> > > > >
> > > > > ---
> > > > > Hans de Vleeschouwer
> > > >
> > > > The only way to fully address all of the instances of 
> this sort of
> > > > objection is to add to the spec "Most BGP 
> implementations allow the
> > > > user to do things that violate the protocol 
> specification in minor
> > > > ways, sometimes with valid uses, but also sometimes 
> with questionalble
> > > > uses and sometimes with dire consequences".  Although 
> this statement
> > > > is true, I don't don't think we need to add this.
> > > >
> > > This although is sometimes true, is bordering on being 
> rediculous for a
> > > spec. I agree, you do not want to add this or the reader 
> will stop reading
> > > the spec.
> > >
> > > 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 LAA23180 for <[e-mail]>; Thu, 3 Oct 2002 11:06:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DBC4391328; Thu,  3 Oct 2002 11:05:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A6EA091329; Thu,  3 Oct 2002 11:05: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 B971791328 for <[e-mail]>; Thu,  3 Oct 2002 11:05:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A049B5DDBC; Thu,  3 Oct 2002 11:05: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 D9ED15DDAA for <[e-mail]>; Thu,  3 Oct 2002 11:05:36 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g93F5X347784; Thu, 3 Oct 2002 11:05: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 g93F5UC47777; Thu, 3 Oct 2002 11:05:30 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g93F5Ub25736; Thu, 3 Oct 2002 11:05:30 -0400 (EDT)
Date: Thu, 3 Oct 2002 11:05:30 -0400
From: Jeffrey Haas <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: Yakov Rekhter <[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 Mon, Sep 30, 2002 at 11:20:34AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Mon, Sep 30, 2002 at 11:20:34AM -0700, Alex Zinin wrote:
> 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?

Cisco has cluster length as part of their tie-breaker.

I'm curious about the scenario that is trying to be addressed by this.

> Alex

-- 
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 KAA22589 for <[e-mail]>; Thu, 3 Oct 2002 10:54:27 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6816791321; Thu,  3 Oct 2002 10:52:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D1B091326; Thu,  3 Oct 2002 10:52: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 94E2491321 for <[e-mail]>; Thu,  3 Oct 2002 10:52:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7E9C05DD9E; Thu,  3 Oct 2002 10:52: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 0069D5DDAA for <[e-mail]>; Thu,  3 Oct 2002 10:52: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 KAA02734; Thu, 3 Oct 2002 10:52: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 KAA29263; Thu, 3 Oct 2002 10:52:18 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7QNTQ>; Thu, 3 Oct 2002 10:52:14 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Manav Bhatia'" <[e-mail]>, [e-mail], "Abarbanel, Benjamin" <[e-mail]>
Cc: BGP mailing list <[e-mail]>
Subject: RE: Active Route
Date: Thu, 3 Oct 2002 10:52: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

The world is too big and complex and it is too difficult to make one size
fit all solution work. I guess that is why they have not depracated the 
redistribution from BGP to IGP feature happen. IMHO, as long as the main
stream vendors still support the feature, we must consider it as a viable
configuration. To say your network is broken if you use it, is a bit over
stating it. I would rather we add cautionary comments in the base spec for
things like this that can lead into possible trouble.

End of Commentary,
Ben

> -----Original Message-----
> From: Manav Bhatia [mailto:[e-mail]]
> Sent: Thursday, October 03, 2002 6:49 AM
> To: [e-mail]; Abarbanel, Benjamin
> Cc: BGP mailing list
> Subject: Re: Active Route
> 
> 
> Curtis,
> | >
> | > What if your AS is not fully meshed as Hans pointed out?
> | >
> | > The only way to get external BGP routes to non-BGP (IGP 
> only) routers
> is by
> | > redistributing them via IGP, and let IGP flood them, right?
> |
> 
> [clipped]
> 
> | The stance as far as the protocol spec goes is that BGP/IGP
> | interactions are out of scope.  Special cases to support a broken AS
> | (one with incomplete IBGP connectivity) is definitely out of scope.
> |
> 
> What if i have one non BGP speaking router lying in between the 2 BGP
> speaking routers carrying transit traffic. I dont think its a 
> broken AS if
> i have this kind of topology. Things will work in this case 
> by adding a
> default route here on this transit non BGP speaking router. 
> But it can turn
> really messy if the number of such transit non BGP routers increase.
> 
> |
> | I did mention it with the intent to show that it borders on 
> ridiculous
> | to try to accommodate all ways in which you can build a semi-broken
> | BGP network or build one with semi-broken equipment and get it to
> | actually work.  We seem to agree that we don't want to go down that
> | road, either enumerating all of the cases or with the 
> general caveat.
> 
> same comments as above.
> 
> 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 KAA22268 for <[e-mail]>; Thu, 3 Oct 2002 10:47:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8382F91325; Thu,  3 Oct 2002 10:46:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C76391321; Thu,  3 Oct 2002 10:46: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 1945A91325 for <[e-mail]>; Thu,  3 Oct 2002 10:46:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E0AFA5DDA2; Thu,  3 Oct 2002 10:46:21 -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 B8FEE5DD9E for <[e-mail]>; Thu,  3 Oct 2002 10:46:20 -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 KAA71213; Thu, 3 Oct 2002 10:45:29 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, Manav Bhatia <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Active Route 
In-reply-to: Your message of "Thu, 03 Oct 2002 09:59:39 EDT." <[e-mail]> 
Date: Thu, 03 Oct 2002 10:45:28 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Gray, Eric" writes:
> Curtis,
> 
> 	Nice, useful advice.

Thanks.  :-)

You could also do the "BGP free core" thingie using MPLS/TE in the
core and LSPs that go among edge routers with full BGP information.
That assumes that the reouter in the middle is MPLS/TE capable.  :-)

[Aside: Sorry for the terse response.  I thought we sufficiently beat
up the last clueless router vendor attempting to put a router in
Internet cores in about 1995 when we finally got Wellfleet to do BGP
(unfortunately they finished BGP3 in 1994 just after BGP4 was deployed
worldwide).  As Bay they finally got a BGP4 in 1995 (with horribly
inefficient BGP policy code that made it near unusable but at least
they had finally done BGP4).]

In case its not glaringly obvious.  For a router to play in the core
of a ISP network it MUST be capable of doing BGP4.  You can build toy
networks (or real enterprise networks) with non-BGP routers.  You can
also build a BGP free core using MPLS/TE, but all MPLS/TE routers I'm
aware of are also BGP4 capable.

It is very hard for an ISP to use a non-BGP4 capable router in any
capacity.  As I mentioned earlier, you can use it near or at the edge
by front ending it with a BGP capable router and get away with default
(ie: multiple defaults if you need a secondary route).

If we're going to reflect reality, we might as well reflect the
practical reality that non-BGP rotuers have no proper place in
networks that run BGP.  Given a few hacks they can be accommodated in
limited roles.  For networks with very few BGP routes (toy or
enterprise, not saying that these are the same) you have a few more
options because you can get away with putting BGP into the IGP.  These
are hacks to accommodate deficient routers.  I don't feel they have a
place in the spec.

Curtis


> ===============================================================
> 
> Manav,
> 
> 	If you follow this advice, make sure you tell your
> management that you threw out a possibly useful router
> based on advice from the mailing list.  The problem with
> doing what you suggest is that you cannot use default
> routes to route traffic transiting an AS.  Because almost
> nobody ever implemented behavior defined for interactions 
> between BGP and any IGP, and the RFCs where these behaviors 
> were defined have been re-classified as HISTORIC, it is not 
> even possible to use an IGP to route traffic transiting an 
> AS.
> 
> 	Hence, the only way to route transit traffic in an
> AS is using (i)BGP.  But keep the router; you can use it
> for internal routing, in an non-transit AS or as a nifty
> paper-weight or boat anchor.  :-)
> 
> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> [e-mail]
> 508 305 7214


You could always try to unload it on EBay.  :-)

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 KAA19934 for <[e-mail]>; Thu, 3 Oct 2002 10:02:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F20C291320; Thu,  3 Oct 2002 09:59:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C35AE9131E; Thu,  3 Oct 2002 09:59: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 7CFDA9131D for <[e-mail]>; Thu,  3 Oct 2002 09:59:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 673835DD91; Thu,  3 Oct 2002 09:59: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 27A015DD90 for <[e-mail]>; Thu,  3 Oct 2002 09:59:44 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12VYJ>; Thu, 3 Oct 2002 09:59:40 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, Manav Bhatia <[e-mail]>
Cc: [e-mail]
Subject: RE: Active Route 
Date: Thu, 3 Oct 2002 09:59:39 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Curtis,

	Nice, useful advice.

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

Manav,

	If you follow this advice, make sure you tell your
management that you threw out a possibly useful router
based on advice from the mailing list.  The problem with
doing what you suggest is that you cannot use default
routes to route traffic transiting an AS.  Because almost
nobody ever implemented behavior defined for interactions 
between BGP and any IGP, and the RFCs where these behaviors 
were defined have been re-classified as HISTORIC, it is not 
even possible to use an IGP to route traffic transiting an 
AS.

	Hence, the only way to route transit traffic in an
AS is using (i)BGP.  But keep the router; you can use it
for internal routing, in an non-transit AS or as a nifty
paper-weight or boat anchor.  :-)

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


> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Thursday, October 03, 2002 9:34 AM
> To: Manav Bhatia
> Cc: [e-mail]; Abarbanel, Benjamin; BGP mailing list
> Subject: Re: Active Route
> 
> 
> In message <0a9101c26aca$84ce3600$[e-mail]>, Manav Bhatia
> writes
> :
> > Curtis,
> > | >
> > | > What if your AS is not fully meshed as Hans pointed out?
> > | >
> > | > The only way to get external BGP routes to non-BGP (IGP only)
> routers
> > is by
> > | > redistributing them via IGP, and let IGP flood them, right?
> > |
> >
> > [clipped]
> >
> > | The stance as far as the protocol spec goes is that BGP/IGP
> > | interactions are out of scope.  Special cases to support a broken AS
> > | (one with incomplete IBGP connectivity) is definitely out of scope.
> > |
> >
> > What if i have one non BGP speaking router lying in between the 2 BGP
> > speaking routers carrying transit traffic. I dont think its a broken AS
> if
> > i have this kind of topology. Things will work in this case by adding a
> > default route here on this transit non BGP speaking router. But it can
> turn
> > really messy if the number of such transit non BGP routers increase.
> 
> 
> Put in a requisition to replace that router and go find a dumpster.
> 
> 
> > | I did mention it with the intent to show that it borders on ridiculous
> > | to try to accommodate all ways in which you can build a semi-broken
> > | BGP network or build one with semi-broken equipment and get it to
> > | actually work.  We seem to agree that we don't want to go down that
> > | road, either enumerating all of the cases or with the general caveat.
> >
> > same comments as above.
> >
> > Manav
> 
> 
> 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 JAA18592 for <[e-mail]>; Thu, 3 Oct 2002 09:35:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CF0CD9131B; Thu,  3 Oct 2002 09:34:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A248E9131C; Thu,  3 Oct 2002 09:34: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 292219131B for <[e-mail]>; Thu,  3 Oct 2002 09:34:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0422F5DE92; Thu,  3 Oct 2002 09:34: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 485205DE8A for <[e-mail]>; Thu,  3 Oct 2002 09:34: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 JAA70824; Thu, 3 Oct 2002 09:33:49 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Manav Bhatia <[e-mail]>
Cc: [e-mail], "Abarbanel,     Benjamin" <[e-mail]>, BGP mailing list <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Active Route 
In-reply-to: Your message of "Thu, 03 Oct 2002 16:19:09 +0530." <0a9101c26aca$84ce3600$[e-mail]> 
Date: Thu, 03 Oct 2002 09:33:49 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <0a9101c26aca$84ce3600$[e-mail]>, Manav Bhatia writes
:
> Curtis,
> | >
> | > What if your AS is not fully meshed as Hans pointed out?
> | >
> | > The only way to get external BGP routes to non-BGP (IGP only) routers
> is by
> | > redistributing them via IGP, and let IGP flood them, right?
> |
> 
> [clipped]
> 
> | The stance as far as the protocol spec goes is that BGP/IGP
> | interactions are out of scope.  Special cases to support a broken AS
> | (one with incomplete IBGP connectivity) is definitely out of scope.
> |
> 
> What if i have one non BGP speaking router lying in between the 2 BGP
> speaking routers carrying transit traffic. I dont think its a broken AS if
> i have this kind of topology. Things will work in this case by adding a
> default route here on this transit non BGP speaking router. But it can turn
> really messy if the number of such transit non BGP routers increase.


Put in a requisition to replace that router and go find a dumpster.


> | I did mention it with the intent to show that it borders on ridiculous
> | to try to accommodate all ways in which you can build a semi-broken
> | BGP network or build one with semi-broken equipment and get it to
> | actually work.  We seem to agree that we don't want to go down that
> | road, either enumerating all of the cases or with the general caveat.
> 
> same comments as above.
> 
> Manav


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 JAA17312 for <[e-mail]>; Thu, 3 Oct 2002 09:09:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D18A49131A; Thu,  3 Oct 2002 09:09:07 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C9FD9131B; Thu,  3 Oct 2002 09:09: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 DCC779131A for <[e-mail]>; Thu,  3 Oct 2002 09:09:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C47B25DEED; Thu,  3 Oct 2002 09:09:05 -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 3E9315DEEC for <[e-mail]>; Thu,  3 Oct 2002 09:09:05 -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 g93D2b523644 for <[e-mail]>; Thu, 3 Oct 2002 15:02:37 +0200
Received: from alcatel.be ([138.203.142.32]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002100315090215:5447 ; Thu, 3 Oct 2002 15:09:02 +0200 
Message-ID: <[e-mail]>
Date: Thu, 03 Oct 2002 15:08:34 +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: Active Route - OT
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 10/03/2002 15:09:02, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 10/03/2002 15:09:04, Serialize complete at 10/03/2002 15:09:04
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

All,

thanks for your feedback on this.  Now I tend to be  more in favor of  leaving
the text  and the restriction in the RFC.  The reasons i see for this are:

1. The effective use of policy is endangered. Supose a bgp speaker announces to
its external peer reachability for a route, and indicates that this route
passes through AS 1,2 and 3, while at the same time the FIB of the same router
would actually send the traffic so that in the end it follows another path
passing through a different set of ASses.  If this is allowed why would we even
bother to pass along attributes? (Also I learned of some people trying to make
tools that use the BGP RIB to figure out how traffic is flowing in the
internet).

2. The restriction as it is stated does not really say HOW this restriction is
to be met. E.g. in my (admittedly very bad) example if we are sure that the IGP
will in the end guide the IP traffic through the AS in such a way that it is in
line with the advertised BGP route, no harm is done. The same is valid for a
static route. The most easy way to guarantee the restriction is to check that
the route in the FIB is in fact the BGP-owned route being advertised, but this
might not be the only possible way to guarantee this.

thanks
---
Hans De Vleeschouwer

> "Natale, Jonathan" wrote:
>
> > "What if your AS is not fully meshed as Hans pointed out?"
> >
> > Then you are mis-configured.
> >
> > Also, I agree with Curtis--redistributing BGP into IGP is a bad idea.  A
> > much better idea is to turn off synchronization (rumor was that it will
> > be/is off by default in newer IOS).  Juniper does not even have a synch
> > concept (a good thing).
> >
> > -----Original Message-----
> > From: Abarbanel, Benjamin [mailto:[e-mail]]
> > Sent: Wednesday, October 02, 2002 12:41 PM
> > To: '[e-mail]'; [e-mail]
> > Cc: BGP mailing list
> > Subject: RE: Active Route
> >
> > Curtis
> >
> > > -----Original Message-----
> > > From: Curtis Villamizar [mailto:[e-mail]]
> > > Sent: Wednesday, October 02, 2002 12:33 PM
> > > To: [e-mail]
> > > Cc: BGP mailing list
> > > Subject: Re: Active Route
> > >
> > >
> > >
> > > In message <[e-mail]>,
> > > [e-mail] writ
> > > es:
> > > >
> > > > Then I redistribute the routes into IGP, and at the same
> > > time I forward
> > > > the routes via IBGP (not full mesh) to all of the other AS
> > > border routers (bu
> > > > t
> > > > to no other routers).
> > >
> > > This is an incredibly bad idea.  Only the BGP next_hop needs to be in
> > > the IGP.
> > >
> > > > At the other side of my AS, I allow the border router
> > > (router B) to pass thos
> > > > e
> > > > routes learned via IBGP (form router A) to the (next) AS
> > > via an EBGP connecti
> > > > on.
> > > > (I am using the  "synchronise BGP = TRUE" option.)
> > >
> > > Synchronise implies that the BGP next_hop is reachable via the IGP
> > > *not* the BGP prefix itself.
> > >
> > > There is never a need to put the destination prefix into the IGP if it
> > > is carried in IBGP except for the case where you are originating a
> > > prefix and you want it to go out with specific attributes such as
> > > specific BGP communities or indicate through BGP communities some
> > > special action such as punching a hole in an aggregate.
> > >
> >
> > What if your AS is not fully meshed as Hans pointed out?
> >
> > The only way to get external BGP routes to non-BGP (IGP only) routers is by
> > redistributing them via IGP, and let IGP flood them, right?
> >
> > > > Now in this fairly straightforward example, the router B
> > > will forward routes
> > > > learned via IBGP to the next AS using EBGP, whereas for
> > > those routes the
> > > > reachability in the FIB is taken care of by IGP (who has
> > > typically a higher
> > > > preference in ther FIB then IBGP).
> > > >
> > > > So, in theory the rule : "one must focus on the rule that a
> > > BGP speaker
> > > > advertises to its peers  in neighboring ASs only those
> > > routes that it itself
> > > > uses." is broken, since it is clearly an IGP route which in the FIB.
> > > >
> > > > ---
> > > > Hans de Vleeschouwer
> > >
> > > The only way to fully address all of the instances of this sort of
> > > objection is to add to the spec "Most BGP implementations allow the
> > > user to do things that violate the protocol specification in minor
> > > ways, sometimes with valid uses, but also sometimes with questionalble
> > > uses and sometimes with dire consequences".  Although this statement
> > > is true, I don't don't think we need to add this.
> > >
> > This although is sometimes true, is bordering on being rediculous for a
> > spec. I agree, you do not want to add this or the reader will stop reading
> > the spec.
> >
> > 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 GAA11421 for <[e-mail]>; Thu, 3 Oct 2002 06:50:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2A0F29123E; Thu,  3 Oct 2002 06:50:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F008591314; Thu,  3 Oct 2002 06:50: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 98C9E9123E for <[e-mail]>; Thu,  3 Oct 2002 06:50:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 816B95DE6D; Thu,  3 Oct 2002 06:50:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: from realname (unknown [203.254.224.24]) by segue.merit.edu (Postfix) with ESMTP id 31FF35DDEB for <[e-mail]>; Thu,  3 Oct 2002 06:50:11 -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]; Thu, 03 Oct 2002 19:55:30 +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]; Thu, 03 Oct 2002 19:55:30 +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]; Thu, 03 Oct 2002 19:56:03 +0900 (KST)
Date: Thu, 03 Oct 2002 16:19:09 +0530
From: Manav Bhatia <[e-mail]>
Subject: Re: Active Route
To: [e-mail], "Abarbanel, Benjamin" <[e-mail]>
Cc: BGP mailing list <[e-mail]>
Reply-To: Manav Bhatia <[e-mail]>
Message-id: <0a9101c26aca$84ce3600$[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

Curtis,
| >
| > What if your AS is not fully meshed as Hans pointed out?
| >
| > The only way to get external BGP routes to non-BGP (IGP only) routers
is by
| > redistributing them via IGP, and let IGP flood them, right?
|

[clipped]

| The stance as far as the protocol spec goes is that BGP/IGP
| interactions are out of scope.  Special cases to support a broken AS
| (one with incomplete IBGP connectivity) is definitely out of scope.
|

What if i have one non BGP speaking router lying in between the 2 BGP
speaking routers carrying transit traffic. I dont think its a broken AS if
i have this kind of topology. Things will work in this case by adding a
default route here on this transit non BGP speaking router. But it can turn
really messy if the number of such transit non BGP routers increase.

|
| I did mention it with the intent to show that it borders on ridiculous
| to try to accommodate all ways in which you can build a semi-broken
| BGP network or build one with semi-broken equipment and get it to
| actually work.  We seem to agree that we don't want to go down that
| road, either enumerating all of the cases or with the general caveat.

same comments as above.

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 FAA07583 for <[e-mail]>; Thu, 3 Oct 2002 05:06:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1B62E9122A; Thu,  3 Oct 2002 05:06:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF1E291234; Thu,  3 Oct 2002 05:06: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 6BA2C9122A for <[e-mail]>; Thu,  3 Oct 2002 05:06:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5A64D5DE0C; Thu,  3 Oct 2002 05:06:24 -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 0AB0A5DDA4 for <[e-mail]>; Thu,  3 Oct 2002 05:06:24 -0400 (EDT)
Received: from [10.9.9.110] (helo=snoopy.runbox.com) by tramp.runbox.com with esmtp (Exim 4.05-VA-mm1) id 17x1w3-0001E3-00 for [e-mail]; Thu, 03 Oct 2002 11:06:19 +0200
Received: from [203.200.20.226] (helo=Manav) (Authenticated Sender=dovek) by snoopy.runbox.com with asmtp (Exim 3.35 #1) id 17x1vw-0004fs-00 for [e-mail]; Thu, 03 Oct 2002 11:06:12 +0200
Message-ID: <098201c26abc$001ea740$[e-mail]>
From: "Misha Dovek" <[e-mail]>
To: <[e-mail]>
Subject: BGP Marker field
Date: Thu, 3 Oct 2002 14:35:12 +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

Hi,
Is the marker field in all the BGP messages really required? Why cant it be
deprecated? Are there any issues with that (except for interoperatability as
of now!) ?

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 XAA25294 for <[e-mail]>; Wed, 2 Oct 2002 23:47:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5224291311; Wed,  2 Oct 2002 23:46:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E69C91312; Wed,  2 Oct 2002 23:46: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 C799691311 for <[e-mail]>; Wed,  2 Oct 2002 23:46:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B44B35DE0D; Wed,  2 Oct 2002 23:46: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 DAEB05DD9B for <[e-mail]>; Wed,  2 Oct 2002 23:46:31 -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 XAA69596; Wed, 2 Oct 2002 23:45:53 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Reply-To: [e-mail]
Subject: Re: MED for Originated Routes 
In-reply-to: Your message of "Wed, 02 Oct 2002 19:05:23 EDT." <[e-mail]> 
Date: Wed, 02 Oct 2002 23:45:53 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> 
> What should the MED be for originated routes to IBGP?  No Med?  All 1's?
> Configurable?  Is it in the draft?  Is this a new issue?  Do you want more
> questions?

I didn't look this up in the draft yet, but the answer is:

  for IBGP:

   The MED you got from EBGP (if any)

   or configurable:

     strip off MED (if any)
     or configure a MED

  originating to IBGP, use no MED or configure one.

  for EBGP (IBGP learned or originating):

    default to no MED

    or configurable:

     put IGP cost into MED
     or configure a MED

That in a nutshell is what implementations do (AFAIK).

I don't think this level of detail needs to go into the protocol spec.
But I've been on the minority end of the consensus before so...  first
lets ask if we need this level of detail.  I think no.  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 TAA15098 for <[e-mail]>; Wed, 2 Oct 2002 19:07:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B068891307; Wed,  2 Oct 2002 19:06:51 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F96791308; Wed,  2 Oct 2002 19:06: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 4354C91307 for <[e-mail]>; Wed,  2 Oct 2002 19:06:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 2F1135DDEB; Wed,  2 Oct 2002 19:06: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 E18B65DD9C for <[e-mail]>; Wed,  2 Oct 2002 19:06:49 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12T2T>; Wed, 2 Oct 2002 19:06:49 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: MED for Originated Routes (text)
Date: Wed, 2 Oct 2002 19:06:49 -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 TAA15098

What should the MED be for originated routes to IBGP?  No Med?  All 1's? 
Configurable?  Is it in the draft?  Is this a new issue?  Do you want more
questions?

(sorry about the 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 TAA15039 for <[e-mail]>; Wed, 2 Oct 2002 19:05:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0EE5C91306; Wed,  2 Oct 2002 19:05:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE2E191307; Wed,  2 Oct 2002 19:05: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 6132791306 for <[e-mail]>; Wed,  2 Oct 2002 19:05:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 415D25DE09; Wed,  2 Oct 2002 19:05: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 F31D65DD9C for <[e-mail]>; Wed,  2 Oct 2002 19:05:24 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12T23>; Wed, 2 Oct 2002 19:05:24 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: MED for Originated Routes
Date: Wed, 2 Oct 2002 19:05:23 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26A68.302F1450"
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_01C26A68.302F1450
Content-Type: text/plain

What should the MED be for originated routes to IBGP?  No Med?  All 1's?
Configurable?  Is it in the draft?  Is this a new issue?  Do you want more
questions?


------_=_NextPart_001_01C26A68.302F1450
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";}
h1
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	text-indent:-.25in;
	page-break-after:avoid;
	font-size:16.0pt;
	font-family:"Times New Roman";}
h2
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.8in;
	margin-bottom:.0001pt;
	text-indent:-.3in;
	page-break-after:avoid;
	font-size:12.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.StyleHeading1Arial12ptLeft, li.StyleHeading1Arial12ptLeft, div.StyleHeading1Arial12ptLeft
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	text-indent:-.25in;
	page-break-after:avoid;
	font-size:12.0pt;
	font-family:"Times New Roman";
	font-weight:bold;}
p.StyleArial22ptBoldCentered, li.StyleArial22ptBoldCentered, div.StyleArial22ptBoldCentered
	{margin:0in;
	margin-bottom:.0001pt;
	text-align:center;
	font-size:20.0pt;
	font-family:Arial;
	font-weight:bold;}
span.EmailStyle19
	{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;}
 /* List Definitions */
 ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</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 should the MED be for originated routes to IBGP?&nbsp; No
Med?&nbsp; All 1's?&nbsp; Configurable?&nbsp; Is it in the draft?&nbsp; Is this a new issue?&nbsp;
Do you want more questions?</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C26A68.302F1450--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA14807 for <[e-mail]>; Wed, 2 Oct 2002 19:00:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6B66691305; Wed,  2 Oct 2002 18:59:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 327B191306; Wed,  2 Oct 2002 18:59: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 9518A91305 for <[e-mail]>; Wed,  2 Oct 2002 18:59:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 799BD5DE0A; Wed,  2 Oct 2002 18:59:50 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 28A7C5DE09 for <[e-mail]>; Wed,  2 Oct 2002 18:59:50 -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 17wsT3-000Jc2-00; Wed, 02 Oct 2002 15:59:45 -0700
Date: Wed, 2 Oct 2002 15:57:54 -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,

  Sounds like we have another issue to fix. If so, Andrew,
  could you please put this on the list?

-- 
Alex

Tuesday, October 01, 2002, 4:36:25 PM, Curtis Villamizar wrote:

> In message <[e-mail]>, Alex Zinin writes:
>> 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


> Alex,

> Two prior issues were use of "shortest AS path" and a detail of "MED
> handling".  The former is in there, the latter is still a little
> deficient.

> The prior issue was inclusion of "shortest AS path" which wasn't in
> earlier BGP-4 but Cisco has always done.  It is now in there.  It
> reflects what Cisco does.  Everyone else seems to have a "Cisco BGP
> compatibility" knob to enable it (typically enabled by default).

> The other issue was MED handling.  In "5.1.4 MULTI_EXIT_DISC":

>    A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
>    which allows the MULTI_EXIT_DISC attribute to be removed from a
>    route. This MAY be done prior to determining the degree of preference
>    of the route and performing route selection (decision process phases
>    1 and 2).

>    An implementation MAY also (based on local configuration) alter the
>    value of the MULTI_EXIT_DISC attribute received over an external
>    link.  If it does so, it shall do so prior to determining the degree
>    of preference of the route and performing route selection (decision
>    process phases 1 and 2).

> This doesn't sufficiently address the issue.

> The MED step in the decision process is (in 9.1.2.2):

>       c) Remove from consideration routes with less-preferred
>       MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
>       between routes learned from the same neighboring AS. Routes which
>       do not have the MULTI_EXIT_DISC attribute are considered to have
>       the lowest possible MULTI_EXIT_DISC value.

>       This is also described in the following procedure:

>             for m = all routes still under consideration
>                 for n = all routes still under consideration
>                     if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
>                         remove route m from consideration

>       In the pseudo-code above, MED(n) is a function which returns the
>       value of route n's MULTI_EXIT_DISC attribute. If route n has no
>       MULTI_EXIT_DISC attribute, the function returns the lowest
>       possible MULTI_EXIT_DISC value, i.e. 0.

>       Similarly, neighborAS(n) is a function which returns the neighbor
>       AS from which the route was received.

> The problem is that a route loop can be formed.

> To avoid the route loop, two suggestions were made (2-3 years ago and
> nothing was done).  One was to make MED(n) return infinity if there
> was no MULTI_EXIT_DISC.  The other was to consider MULTI_EXIT_DISC in
> the decision process only for the purpose of selecting among the EBGP
> peers, then remove MULTI_EXIT_DISC, then use that best route in
> comparisons to IBGP learned routes.

> The statement in 5.1.4 "This MAY be done prior to determining the
> degree of preference of the route and performing route selection
> (decision process phases 1 and 2)" does not sufficiently address this.
> This implies that you MAY also remove after route selection, in which
> case field experience indicates you WILL get burned (unless you know
> about the caveat above).  Initially this came up as an
> interoperability issue but later it was proven (in the field) that a
> Cisco and another Cisco could form a route loop until Cisco made this
> change.

> Additional wording is needed either in 5.1.4 or in 9.1.2.2.  I suggest
> we put a forward reference in 5.1.4:

>    [...]. This MAY be done prior to determining the degree of preference
>    of the route and performing route selection (decision process phases
>    1 and 2).  See section 9.1.2.2 for necessary restricts on this.

> Then in 9.1.2.2 add a clarificatio to the neighborAS(n) function and
> add to the existing text.

>       Similarly, neighborAS(n) is a function which returns the
>       neighbor AS from which the route was received.  If the route is
>       learned via IBGP, it is the neighbor AS from which the other
>       IBGP speaker learned the route, not the internal AS.

>       If a MULTI_EXIT_DISC attribute is removed before redistributing
>       a route into IBGP, the MULTI_EXIT_DISC attribute may only be
>       considered in the comparison of EBGP learned routes, them
>       removed, then the remaining EBGP learned route may be compared
>       to the remaining IBGP learned routes, without considering the
>       MULTI_EXIT_DISC attribute for those EBGP learned routes whose
>       MULTI_EXIT_DISC will be dropped before advertising to IBGP.
>       Including the MULTI_EXIT_DISC of an EBGP learned route in the
>       comparison with an IBGP learned route, then dropping the
>       MULTI_EXIT_DISC and advertising the route has been proven to
>       cause route loops.

> The loop is the classic I prefer your and you prefer mine problem.  It
> occurs when the router is configured to remove MULTI_EXIT_DISC and
> advertise out a route so other routers can use IGP cost to select the
> best route.  If two routers do this, as soon as they hear the route
> with no MULTI_EXIT_DISC from the other peer they start forwarding
> toward that peer but they continue to advertise to it since others
> IBPG peers are expected to select among the MULTI_EXIT_DISC free IBGP
> learned routes using the next step in the decision process, IGP cost.

> In this case, what you want is each router to prefer its own EBGP
> route, even though it has a MULTI_EXIT_DISC and the IBGP learned route
> from the same neighbor AS has had its MULTI_EXIT_DISC stripped off (or
> didn't have one, you can't tell which it is).  You then want all of
> the IBGP peers with a MULTI_EXIT_DISC free route from that AS, or that
> have stripped the MULTI_EXIT_DISC to form one, to advertise them.
> Others in the AS will then use IGP cost to further resolve which exit
> point to use.  It make a difference when the route is the aggregate
> route of another major provider.  IGP cost yields what ISPs call "hot
> potatoe routing" and MED selects among multiple heavily loaded
> provider interconnects.

> [Aside: Having a missing MULTI_EXIT_DISC default to infinity would do
> exactly what the ISPs want it to do in the first place and be a lot
> easier to explain but we didn't fix that 2-3 years ago when the issue
> came up even though we had WG consensus that it was the right thing to
> do.  The authors didn't act on it at the time (because Cisco didn't do
> it that way and the authors preferred to sit on the draft).  At this
> point we might as well adequately document what we ended up with....
> End of soapbox.  I don't take myself all that seriously so others
> shouldn't either.  :-)]

> 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 SAA14470 for <[e-mail]>; Wed, 2 Oct 2002 18:49:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 96E6E91206; Wed,  2 Oct 2002 18:49:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 68D5B91305; Wed,  2 Oct 2002 18:49: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 E524591206 for <[e-mail]>; Wed,  2 Oct 2002 18:49:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CD4865DDE8; Wed,  2 Oct 2002 18:49: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 A07AB5DDDB for <[e-mail]>; Wed,  2 Oct 2002 18:49:26 -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 17wsIy-000JDR-00; Wed, 02 Oct 2002 15:49:20 -0700
Date: Wed, 2 Oct 2002 15:47:29 -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]>, =?ISO-8859-1?B?QWJhcmJhbmVsLA0KICAgIEJlbmphbWlu?= <[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,

  Agree with your overview of BGP multipath.

  Regarding a separate document for this... I'm trying to find a
  convincing reason that would overweight the importance of this part,
  something like "this is really new and unexplored", or "it would
  really take months for the WG to converge on", etc. But it seems
  that we know what the text should talk about and what the
  considerations are (such as ECMP load sharing that you talk about in
  your other message). If this is so, then I ask myself why is it a
  problem to put this in the spec? Maybe yourself and the chairs could
  take me off the stage and beat me up behind the curtain so I could
  then come back to the list and say "a separate doc makes sense".
  I have no problem admitting I was wrong...

-- 
Alex

Tuesday, October 01, 2002, 5:24:46 PM, Curtis Villamizar wrote:

> In message <[e-mail]>, Alex Zinin writes:
>> Yakov,
>> 
>> >> It would be smarter to assign the next hop address to a virtual
>> >> interface (e.g. Loopback Interface address) thus if the peer has two 
>> >> physical interfaces to current router, there is only one route.
>> >> Thus the load balancing issue is transparent to the BGP routing
>> >> and only obvious in the forwarding plane. 
>> 
>> > And if it is transparent to the BGP routing, then there is no
>> > need to have it in the base spec. Agreed ?
>> 
>> Note that what Ben described above is not BGP multipath, but
>> load-balancing based on IGP multipath, and right, _this_ one doesn't
>> belong in the spec.
>> 
>> Alex



> Alex,

> In addition to IGP multihop, there are two cases of BGP multipath.

> In IGP multihop there is one BGP advertisement but to ways to reach th
> BGP NEXT_HOP via the IGP.

> In one case of BGP multihop, two (or more) IBGP routers peering with
> the same external AS have equal routes to a destination and are an
> equal cost away from a third router.  BGP multihop is applicable to
> that third router.  Without BGP multihop, BGP would normally pick the
> BGP NEXT_HOP of the advertisement from only one of those IBGP peers
> (using BGP Identifier) and use that.  The IGP lookup would yield one
> next hop.  With BGP multihop, BGP uses the BGP NEXT_HOP of both
> advertisements.  Each BGP NEXT_HOP has a different IGP next hop (one
> or more IGP next hop).

> The second case is where all of the candidates routes for BGP
> multipath are external.  Seldom does IGP multipath come into play for
> EBGP (odd tunneled EBGP mutlihop cases maybe).  Typically the load is
> split among two (or more) routers in the same AS.

> If in EBGP multipath you split among routers in difference AS, an
> aggregate should be formed.  This is still prior to the IGP cost rule
> in the route selection.

> Normally one would not combine IBGP and EBGP in multihop given that
> the decsion point for multihop is after "d" in 9.1.2.2.  If the
> multihop decision was prior to "d", then two routers each with an
> external peering would forward some of the traffic to each other and
> for some src/dst pairs, they'd form a loop.  [So don't do that!]

> This is getting to be a lot to add to the base spec.  I hope we've
> convinced you that we should put it in another document.

> 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 SAA12850 for <[e-mail]>; Wed, 2 Oct 2002 18:10:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B262491301; Wed,  2 Oct 2002 18:08:28 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36BD691302; Wed,  2 Oct 2002 18:08: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 3FE1891301 for <[e-mail]>; Wed,  2 Oct 2002 18:08:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 30EAF5DE01; Wed,  2 Oct 2002 18:08: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 E09B65DDF2 for <[e-mail]>; Wed,  2 Oct 2002 18:08:21 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12TB2>; Wed, 2 Oct 2002 18:08:21 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: Refusing connections in Idle
Date: Wed, 2 Oct 2002 18:08:20 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Another "lost issue" ???...

Neither Juniper nor Cisco refuse connections for an exponentially increasing
period after closing due to an error.  Cisco actually accepts incoming
connections while in Idle. Juniper goes quickly into Active.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA12699 for <[e-mail]>; Wed, 2 Oct 2002 18:07:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 984A9912D4; Wed,  2 Oct 2002 18:07:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 659E391300; Wed,  2 Oct 2002 18:07: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 210F5912D4 for <[e-mail]>; Wed,  2 Oct 2002 18:07:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id F23D95DE09; Wed,  2 Oct 2002 18:06:59 -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 1BBA05DDF2 for <[e-mail]>; Wed,  2 Oct 2002 18:06: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 SAA68071; Wed, 2 Oct 2002 18:06:24 -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: Active Route -- OT 
In-reply-to: Your message of "Wed, 02 Oct 2002 13:29:34 EDT." <[e-mail]> 
Date: Wed, 02 Oct 2002 18:06:24 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> "Synchronise implies that the BGP next_hop is reachable via the IGP
> *not* the BGP prefix itself."
> 
> Wrong. Synchronized (Cisco Term) implies that the route (set of
> destinations) has been learned via an IGP (including connected and direct).
> IBGP learned routes must be synchronized to be advertised via EBGP, Post
> 12.0(6???) added that un-synchronized routes may not be used for local
> forwarding. Synch can be config'd off.
> 
> NEXT_HOP must always be resolvable, no way to config this off.


Maybe I'm wrong on how Cisco uses "synchronized".  Last I had the
discussion on whether to enable synchronized was a long time ago and I
quite sure that at that time the Cisco recursive lookup had to resolve
to a next hop before the route could be advertised.  I could have been
wrong then, confused with the corresponding gated restriction, or they
could have changed it.

If so I stand 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 RAA11081 for <[e-mail]>; Wed, 2 Oct 2002 17:28:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8D7CD912D0; Wed,  2 Oct 2002 17:28:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CD07912D5; Wed,  2 Oct 2002 17:28: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 2C971912D0 for <[e-mail]>; Wed,  2 Oct 2002 17:28:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 179D35DE05; Wed,  2 Oct 2002 17:28: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 C1D545DE06 for <[e-mail]>; Wed,  2 Oct 2002 17:28:21 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12S7Z>; Wed, 2 Oct 2002 17:28:21 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 8
Date: Wed, 2 Oct 2002 17:28:20 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

IOS defaults to 5 seconds for MinRouteAdvertisementInterval for IBGP, which
I think is good since you want you AS to agree, whereas in EBGP you are more
concerned with not flapping.


-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 11:50 AM
To: [e-mail]
Subject: issue 8

Folks,

I'd like to propose the following text for "BGP Timers" section:

   BGP employs five timers: ConnectRetry (see Section 8), Hold Time
   (see Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval
   (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
   Section 9.2.1.1).

   The suggested value for the ConnectRetry timer is 120 seconds.

   The suggested value for the Hold Time is 90 seconds.

   The suggested value for the KeepAlive timer is 1/3 of the Hold
   Time.

   The suggested value for the MinASOriginationInterval is 15
   seconds.

   The suggested value for the MinRouteAdvertisementInterval is 30
   seconds.

   An implementation of BGP MUST allow the Hold Time timer to be
   configurable, and MAY allow the other timers to be configurable.

   To minimize the likelihood that the distribution of BGP messages
   by a given BGP speaker will contain peaks, jitter should be
   applied to the timers associated with MinASOriginationInterval,
   Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
   given BGP speaker shall apply the same jitter to each of these
   quantities regardless of the destinations to which the updates
   are being sent; that is, jitter will not be applied on a "per
   peer" basis.

Any objections ?

Yakov.

   The amount of jitter to be introduced shall be determined by
   multiplying the base value of the appropriate timer by a random
   factor which is uniformly distributed in the range from 0.75 to
   1.0.



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA10978 for <[e-mail]>; Wed, 2 Oct 2002 17:26:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id EABFC912A7; Wed,  2 Oct 2002 17:26:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B81A6912D0; Wed,  2 Oct 2002 17:26: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 3EC62912A7 for <[e-mail]>; Wed,  2 Oct 2002 17:26:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 242FD5DE05; Wed,  2 Oct 2002 17:26: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 D43085DDF5 for <[e-mail]>; Wed,  2 Oct 2002 17:25:59 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12S7T>; Wed, 2 Oct 2002 17:25:59 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Martin, Christian'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: Active Route
Date: Wed, 2 Oct 2002 17:25:59 -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(since the new proposed paragraph has a different meaning,
maybe this should be in separate paragraph):


"A BGP speaker MUST NOT advertise sets of destinations that are not
locally reachable."


Seems obvious, but the only place I have found this is RFC1812:

"Routers MUST NOT by default redistribute routing data they do
not themselves use, trust or otherwise consider valid."

--which seems to imply that you could configure a router to
advertise routes that you do not use ("by default").  Also,
the word "redistribute" now has a different meaning
(in RFC1812 it meant "advertise", whereas in common usage
now it means "leak"/"export" routing information from
one routing protocol into another routing protocol).




-----Original Message-----
From: Martin, Christian [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 3:11 PM
To: 'Natale, Jonathan'; Martin, Christian
Cc: [e-mail]
Subject: RE: Active Route

That is what I meant.  We have two choices:

1) Announce only if it is the best BGP route and the route exists in the
rib.
-or-
2) Announce only if it is the best route and the route was learned via BGP
and it is in your RIB.

This about covers it, I think.

-chris



>-----Original Message-----
>From: Natale, Jonathan [mailto:[e-mail]] 
>Sent: Wednesday, October 02, 2002 11:33 AM
>To: 'Martin, Christian'
>Cc: [e-mail]
>Subject: RE: Active Route
>
>
>Christian,
>
>Thank you for replying.
>
>Your change would not cover the case, for example, where the 
>speaker uses a static route that is not redistributed into bgp 
>to reach a set of destinations that is also learned via bgp.
>
>I was thinking of:
>"one must focus on the rule that a BGP speaker advertises to 
>its peers only routes whose set of destinations
>are reachable per the local Routing Table."
>
>
>-----Original Message-----
>From: Martin, Christian [mailto:[e-mail]] 
>Sent: Wednesday, October 02, 2002 10:28 AM
>To: 'Natale, Jonathan'; [e-mail]
>Subject: RE: Active Route
>
>Jonathan,
>
>>
>>"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 means that if the speaker's routing table has a non-bgp
>>route to a destination but does not have bgp route to the same 
>>destination (for example, based on administrative distance), 
>>then the speaker may not advertise that route to it's peers. 
>>This is true on Juniper by default for EBGP, but is NOT TRUE 
>>[ever?] on Juniper for IBGP, and is NOT TRUE on Juniper if ~= 
>>"advertise inactive" is enabled.  This is NOT TRUE ever on Cisco.
>>
>>Now we are proposing that the quoted clause above be
>>completely removed. This means that it will be allowable to 
>>advertise a route to a destination that is not locally 
>>reachable.  This is obviously (to me, but not to all-- which 
>>is why it should not be removed) bad. 
>
>This, IMO, is not the spirit of the rule.  Juniper interpreted 
>the spec differently.  As I see it, if the route is in the 
>routing table, you can announce it.  To be more specific, and 
>to your point Jonathan, we should say this - or say the converse:
>
>"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 learned via BGP that it 
>itself uses.  "Learned via BGP" means that a router's best 
>path to a prefix is one that was either learned from a BGP 
>peer, or deliberately injected into BGP by the local router."
>
>Regards,
>-chris
>
>
>
>
>>
>>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 RAA10412 for <[e-mail]>; Wed, 2 Oct 2002 17:14:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 976AD9128C; Wed,  2 Oct 2002 17:14:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62E0B9129B; Wed,  2 Oct 2002 17:14: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 54F549128C for <[e-mail]>; Wed,  2 Oct 2002 17:14:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 372B85DE04; Wed,  2 Oct 2002 17:14: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 CCC395DDF5 for <[e-mail]>; Wed,  2 Oct 2002 17:14:35 -0400 (EDT)
Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g92LEYm79858; Wed, 2 Oct 2002 14:14:34 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
X-Exmh-Isig-CompType: repl
X-Exmh-Isig-Folder: inbox
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: Active Route 
In-reply-to: Your message of "Wed, 02 Oct 2002 15:58:43 EDT." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain
Date: Wed, 02 Oct 2002 14:14:34 -0700
From: Dennis Ferguson <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> Thank you very much for taking the time to respond and for
> actually understanding what I am [trying] to say.  I agree with
> everything you say, particularly "it is the way some of the world works"
> and this is why I am proposing the change. Also, the existing text does
> not describe Juniper either since they "strictly conform to the
> quoted behavior for both EBGP and IBGP", whereas the existing text
> only applies EBGP.

I think the existing text says you must only advertise routes you
are using for forwarding to your EBGP neighbours, but doesn't place
much of a requirement at all on what you do or don't advertise to your
IBGP neighbours.  Given the first constraint I don't think it actually
matters all that much how you handle the second, there are several
ways to end up at the same end result.  What Juniper routers prefer to
do is something the existing text gives them the freedom to do.

> I am not sure if you agree with the change or not.  On the one hand you
> say that Cisco's behavior is a bug, but on the other hand you say that
> it would be hard to find practical cases where the above algorithm
> would actually break much of anything.
> 
> Do you agree or not?

I have this view that routing protocols should be constrained to be basically
correct (i.e. do what is necessary to prevent loops and otherwise ensure
that they can actually reach the destinations they say they can), but
that anything else is fair game.  I don't like what Cisco does, and
certainly wouldn't have wanted the original BGP spec to say this, since
it is hard to think through a theoretical assurance of basic correctness
compared to just constraining routers to advertise only the routes they
are using.  On the other hand, they did it this way anyway and we now have
a lot of experience which says that routers can behave like this without
causing any particular damage, so I don't object to a change which makes
the document more closely reflect the practical reality.

Dennis Ferguson


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA09553 for <[e-mail]>; Wed, 2 Oct 2002 16:58:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 112B891236; Wed,  2 Oct 2002 16:58:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D11489128C; Wed,  2 Oct 2002 16:58: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 79C8A91236 for <[e-mail]>; Wed,  2 Oct 2002 16:58:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5A6DE5DE06; Wed,  2 Oct 2002 16:58: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 4A6EC5DDEB for <[e-mail]>; Wed,  2 Oct 2002 16:58: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 QAA67381; Wed, 2 Oct 2002 16:57:27 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Justin Fletcher <[e-mail]>
Cc: [e-mail], Yakov Rekhter <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 8 
In-reply-to: Your message of "02 Oct 2002 10:59:42 PDT." <1033581582.2301.26.camel@riga> 
Date: Wed, 02 Oct 2002 16:57:26 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <1033581582.2301.26.camel@riga>, Justin Fletcher writes:
> On Wed, 2002-10-02 at 10:23, Curtis Villamizar wrote:
> > 
> > In message <1033574178.27465.34.camel@riga>, Justin Fletcher writes:
> > > >    The amount of jitter to be introduced shall be determined by
> > > >    multiplying the base value of the appropriate timer by a random
> > > >    factor which is uniformly distributed in the range from 0.75 to
> > > >    1.0.
> > > 
> > > I'd suggest "uniformly distributed in the range from 0.75 to 1.25"
> > > to ensure the average is the configured interval.
> > > 
> > > Justin Fletcher
> > 
> > 
> > This is just a suggested default value and an implementor is free to
> > use another such as .75 to 1.25 (and it would be a good idea to
> > document it clearly).  Some conformance freak might take this as
> > gospel and also check the uniformness of the random distribution but
> > that too is a recommended default and selection from some other
> > distribution (tail truncated) would still be compliant.  Someone might
> > pick .75 to 1.25 if preserving the mean value seemed more appealing
> > and someone else might use another distribution if it saved a few CPU
> > cycles and both would be OK.
> > 
> > Briefly - it doesn't matter.
> > 
> > Curtis
> 
> That is rather the question, isn't it?  If we're looking at this from
> a new implementor's point of view, how do you know that this doesn't
> matter from reading text that reads "shall be determined"?

The wording changes I made stated this as a recommendation.  I'm sorry
for the inaccuracy in my comment.  It should be a recommendation.

> If most implementations use other values and it doesn't matter,
> I'd suggest the first line of the text to read
> 
> "A recommended amount of jitter to be introduced may be determined by"
> 
> In retrospect, I'd be happy with either the original text or any of the
> proposed changes; it's not a strong opinion :-) and I wouldn't have
> raised the issue in the first place if I'd done my homework & checked
> the RFC.
> 
> Justin

Please consider the substitute text I suggested.  Relaxing the jitter
statement to a recommended default is one of the changes I suggested.

You are correct in that as it is now stated, the jitter is not
configurable and must be implemented as specified.  This should be
fixed.

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 QAA07378 for <[e-mail]>; Wed, 2 Oct 2002 16:07:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4051E912FF; Wed,  2 Oct 2002 16:07:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DA5091300; Wed,  2 Oct 2002 16:07: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 6E0F9912FF for <[e-mail]>; Wed,  2 Oct 2002 16:07:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5CEB05DDFA; Wed,  2 Oct 2002 16:07: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 130A55DDD9 for <[e-mail]>; Wed,  2 Oct 2002 16:07:12 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12SSY>; Wed, 2 Oct 2002 16:07:11 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 62 
Date: Wed, 2 Oct 2002 16:07:10 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

d'Accord.  Thanks!

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


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, October 02, 2002 3:25 PM
> To: Gray, Eric
> Cc: [e-mail]
> Subject: Re: issue 62
> 
> Eric,
> 
> > In addition to the change Yakov proposes, something
> > may need to be done with respect to the following
> > text as well.
> > -----------------------------------------------------------------------
> > In section 2 (Introduction), sixth paragraph
> >
> >    BGP runs over a reliable transport protocol. This eliminates the
> >    need to implement explicit update fragmentation, retransmission,
> >    acknowledgment, and sequencing. Any authentication scheme used by the
> >    transport protocol (e.g., RFC2385 [10]) may be used in addition to
> >    BGP's own authentication mechanisms. The error notification mechanism
> >    used in BGP assumes that the transport protocol supports a "graceful"
> >    close, i.e., that all outstanding data will be delivered before the
> >    connection is closed.
> >
> > Could be changed to
> >
> >    BGP runs over a reliable transport protocol. This eliminates the
> >    need to implement explicit update fragmentation, retransmission,
> >    acknowledgment, and sequencing. Any authentication scheme used by
> >    the transport protocol (e.g., RFC2385 [10]) may be used. The error
> >    notification mechanism used in BGP assumes that the transport
> >    protocol supports a "graceful" close, i.e., that all outstanding
> >    data will be delivered before the connection is closed.
> 
> The "reliable transport protocol" used by BGP is TCP. With this in mind
> how about the following:
> 
>    BGP uses TCP [RFC793] as its transport protocol. This eliminates
>    the need to implement explicit update fragmentation, retransmission,
>    acknowledgment, and sequencing. BGP listens on TCP port 179. Any
>    authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may be
>    used. The error notification mechanism used in BGP assumes that TCP
>    supports a "graceful" close, i.e., that all outstanding data will
>    be delivered before the connection is closed.
> 
> > -----------------------------------------------------------------------
> > In section 4.1 (Message Header Format), after the figure
> >
> >      Marker:
> >
> >          This 16-octet field contains a value that the receiver of the
> >          message can predict.  If the Type of the message is OPEN, or if
> >          the OPEN message carries no Authentication Information (as an
> >          Optional Parameter), then the Marker must be all ones.
> >          Otherwise, the value of the marker can be predicted by some a
> >          computation specified as part of the authentication mechanism
> >          (which is specified as part of the Authentication Information)
> >          used.  The Marker can be used to detect loss of synchronization
> >          between a pair of BGP peers, and to authenticate incoming BGP
> >          messages.
> >
> > This could be changed to:
> >
> >      Marker:
> >
> >          This 16-octet field is included for compatibility; it must be
> >          set to all ones.
> > ----------------------------------------------------------------------
> > In section 6.1 (Message Header error handling), second paragraph
> >
> >    The expected value of the Marker field of the message header is all
> >    ones if the message type is OPEN.  The expected value of the Marker
> >    field for all other types of BGP messages determined based on the
> >    presence of the Authentication Information Optional Parameter in the
> >    BGP OPEN message and the actual authentication mechanism (if the
> >    Authentication Information in the BGP OPEN message is present). If
> >    the Marker field of the message header is not the expected one, then
> >    a synchronization error has occurred and the Error Subcode is set to
> >    Connection Not Synchronized.
> >
> > Which could be replaced by
> >
> >    The expected value of the Marker field of the message header is all
> >    ones. If the Marker field of the message header is not as expected,
> >    then a synchronization error has occurred and the Error Subcode is
> >    set to Connection Not Synchronized.
> > -----------------------------------------------------------------------
> > Also, the last paragraph in section 6.2 (OPEN message error handling)
> >
> >    If the OPEN message carries Authentication Information (as an
> >    Optional Parameter), then the corresponding authentication procedure
> >    is invoked.  If the authentication procedure (based on Authentication
> >    Code and Authentication Data) fails, then the Error Subcode is set to
> >    Authentication Failure.
> >
> > Could be deleted.
> > ------------------------------------------------------------------------
> > Finally, we need to deal with bullet 6 in Appendix 4 (which will
> > probably occur anyway since Appendix 4 needs to be re-written to
> > reflect that this new RFC differs from RFC 1771 instead of 1105).
> 
> Differences between this document and RFC1771 is in Appendix 1,
> not Appendix 4. Appendix 1 will have the text to indicate that
> the Authentication Information parameter is eliminated.
> 
> Yakov.
> 
> >
> >
> > Eric W. Gray
> > Systems Architect
> > Celox Networks, Inc.
> > [e-mail]
> > 508 305 7214
> >
> >
> > > -----Original Message-----
> > > From: Yakov Rekhter [mailto:[e-mail]]
> > > Sent: Wednesday, October 02, 2002 12:24 PM
> > > To: [e-mail]
> > > Subject: issue 62
> > >
> > > Folks,
> > >
> > >   62) Deprecate BGP Authentication Optional Parameter from RFC1771
> > >   --------------------------------------------------------------------
> ----
> > > ----
> > >   Status: No Consensus
> > >   Change: Potentially
> > >   Summary: We are at consensus, in that we agree that we should
> deprecate
> > >    the BGP Authentication Optional Parameter as described in RFC1771
> in
> > >    favor of the mechanism described in RFC2385.  We do not have new
> text
> > > for
> > >    the draft yet, of if we are going to pull the reference entirely.
> > >
> > > I would suggest to remove the following text from the draft:
> > >
> > >          This document defines the following Optional Parameters:
> > >
> > >          a) Authentication Information (Parameter Type 1):
> > >
> > >
> > >             This optional parameter may be used to authenticate a BGP
> > >             peer. The Parameter Value field contains a 1-octet
> > >             Authentication Code followed by a variable length
> > >             Authentication Data.
> > >
> > >                 0 1 2 3 4 5 6 7 8
> > >                 +-+-+-+-+-+-+-+-+
> > >                 |  Auth. Code   |
> > >                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
> > >                 |
> |
> > >                 |              Authentication Data
> |
> > >                 |
> |
> > >                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
> > >
> > >
> > >                Authentication Code:
> > >
> > >                   This 1-octet unsigned integer indicates the
> > >                   authentication mechanism being used. Whenever an
> > >                   authentication mechanism is specified for use within
> > >                   BGP, three things must be included in the
> > >                   specification:
> > >
> > >                   - the value of the Authentication Code which
> indicates
> > >                   use of the mechanism,
> > >                   - the form and meaning of the Authentication Data,
> and
> > >                   - the algorithm for computing values of Marker
> fields.
> > >
> > >                   Note that a separate authentication mechanism may be
> > >                   used in establishing the transport level connection.
> > >
> > >                Authentication Data:
> > >
> > >                   Authentication Data is a variable length field that
> is
> > >                   interpreted according to the value of the
> > >                   Authentication Code field.
> > >
> > > If there are objections to this, then I would add the following:
> > >
> > >    This document deprecates the use of the Authentication Information
> > >    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 PAA06978 for <[e-mail]>; Wed, 2 Oct 2002 15:59:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CA910912FE; Wed,  2 Oct 2002 15:58:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99EBF912FF; Wed,  2 Oct 2002 15: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 32DFD912FE for <[e-mail]>; Wed,  2 Oct 2002 15:58:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 17A6E5DD93; Wed,  2 Oct 2002 15:58: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 A75155DDD9 for <[e-mail]>; Wed,  2 Oct 2002 15:58:43 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12SR1>; Wed, 2 Oct 2002 15:58:43 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Dennis Ferguson'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: RE: Active Route 
Date: Wed, 2 Oct 2002 15:58:43 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Dennis,

Thank you very much for taking the time to respond and for
actually understanding what I am [trying] to say.  I agree with
everything you say, particularly "it is the way some of the world works"
and this is why I am proposing the change. Also, the existing text does
not describe Juniper either since they "strictly conform to the
quoted behavior for both EBGP and IBGP", whereas the existing text
only applies EBGP.

I am not sure if you agree with the change or not.  On the one hand you
say that Cisco's behavior is a bug, but on the other hand you say that
it would be hard to find practical cases where the above algorithm
would actually break much of anything.

Do you agree or not?

Thank you.
-Jonathan





-----Original Message-----
From: Dennis Ferguson [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 3:29 PM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: Active Route 

Jon,

> "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 means that if the speaker's routing table has a non-bgp route to a
> destination but does not have bgp route to the same destination (for
> example, based on administrative distance), then the speaker may not
> advertise that route to it's peers. This is true on Juniper by default for
> EBGP, but is NOT TRUE [ever?] on Juniper for IBGP, and is NOT TRUE on
> Juniper if ~= "advertise inactive" is enabled.  This is NOT TRUE ever on
> Cisco.

I would note that, for implementation reasons, it requires a moderately
unnatural act for Juniper routers to ever advertise a route to any
BGP peer, whether internal or external, which is not the route it is
using for forwarding.  I suspect that if you don't add "advertise inactive",
you'll find that the routers strictly conform to the quoted behaviour for
both EBGP and IBGP.  The knob is a relatively late addition added as a
concession to the fact that people are used to the Cisco behaviour, and some
have built configurations which depend on it.  I personally consider the
Cisco behaviour to be a bug, but it is the way some of the world works.

> Now we are proposing that the quoted clause above be completely removed.
> This means that it will be allowable to advertise a route to a destination
> that is not locally reachable.  This is obviously (to me, but not to all--
> which is why it should not be removed) bad. 

I think the algorithm Juniper routers use when the knob is enabled is that
there are two routes potentially available for readvertisement, the route
which the router is using for forwarding and the best BGP route which would
be usable for forwarding if the preferred (non-BGP) route(s) wasn't present.
If policy prohibits readvertisement of the first route but permits
readvertisement of the second route, the second route is readvertised.
While telling lies about the route you are using seems theoretically
fragile it is, however, hard to find practical cases where the above
algorithm would actually break much of anything.

Dennis Ferguson


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA06721 for <[e-mail]>; Wed, 2 Oct 2002 15:55:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 4D262912FD; Wed,  2 Oct 2002 15:54:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16777912FE; Wed,  2 Oct 2002 15:54: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 E2208912FD for <[e-mail]>; Wed,  2 Oct 2002 15:54:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C5D715DDF5; Wed,  2 Oct 2002 15:54:40 -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 542585DDD9 for <[e-mail]>; Wed,  2 Oct 2002 15:54:40 -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 PAA28153; Wed, 2 Oct 2002 15:54: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 PAA28018; Wed, 2 Oct 2002 15:53:37 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7PRXH>; Wed, 2 Oct 2002 15:53:35 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail], BGP mailing list <[e-mail]>
Subject: RE: Active Route 
Date: Wed, 2 Oct 2002 15:53: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

> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Wednesday, October 02, 2002 3:44 PM
> To: Abarbanel, Benjamin
> Cc: '[e-mail]'; [e-mail]; BGP
> mailing list
> Subject: Re: Active Route 
> 
> 
> 
> In message 
> <[e-mail]>, 
> "Abarbanel, Benjamin" writes:
> > Curtis
> > 
> > > -----Original Message-----
> > > From: Curtis Villamizar [mailto:[e-mail]]
> > > Sent: Wednesday, October 02, 2002 12:33 PM
> > > To: [e-mail]
> > > Cc: BGP mailing list
> > > Subject: Re: Active Route 
> > > 
> > > 
> > > 
> > > In message <[e-mail]>, 
> > > [e-mail] writ
> > > es:
> > > > 
> > > > Then I redistribute the routes into IGP, and at the same 
> > > time I forward
> > > > the routes via IBGP (not full mesh) to all of the other AS 
> > > border routers (bu
> > > > t
> > > > to no other routers).
> > > 
> > > This is an incredibly bad idea.  Only the BGP next_hop 
> needs to be in
> > > the IGP.
> > > 
> > > > At the other side of my AS, I allow the border router 
> > > (router B) to pass thos
> > > > e
> > > > routes learned via IBGP (form router A) to the (next) AS 
> > > via an EBGP connecti
> > > > on.
> > > > (I am using the  "synchronise BGP = TRUE" option.)
> > > 
> > > Synchronise implies that the BGP next_hop is reachable via the IGP
> > > *not* the BGP prefix itself.
> > > 
> > > There is never a need to put the destination prefix into 
> the IGP if it
> > > is carried in IBGP except for the case where you are originating a
> > > prefix and you want it to go out with specific attributes such as
> > > specific BGP communities or indicate through BGP communities some
> > > special action such as punching a hole in an aggregate.
> > > 
> > 
> > What if your AS is not fully meshed as Hans pointed out? 
> > 
> > The only way to get external BGP routes to non-BGP (IGP 
> only) routers is by
> > redistributing them via IGP, and let IGP flood them, right?
> 
> 
> {\begin{aside}
> 
> As someone formerly with two major ISPs, I'd say your AS is
> broken.  Use route-reflectors if its just a matter of wanting to
> reduce the mesh.  If you have routers or other device that don't do
> BGP, get rid of them or arrange so that they can use a default route
> (and then get then fixed or get rid of them).
> 
> This does happen with some very stupid and somewhat specialized edge
> boxes which end up getting used because they are somewhat specialized
> and do something right that is needed.  Its usually sufficient to give
> them a default route to something with a bit more IP intelligence (and
> then get rid of them if at all possible).  It is common to front end a
> box like this with a small router just for this purpose.  This comment
> on my part is really an aside though.
> 
> In practice, if you absolutely needed BGP injected into the IGP (and
> hopefully a subset of the 250,000 BGP routes) you can export the IBGP
> learned routes to EBGP so as not to lose the BGP attributes.  It is
> out of scope for the spec as we've already stated numerous times.
>

My only point is, if its such a TABOO thing to not export BGP to IGP, then
we
need to find a home for this point that is made very clearly as a rule for
something NOT to do. Hopefully in due time vendors will remove the knob that
allows this to happen and thus eliminate the need to document the problem.
 
BTW: If we move to IPv6, there are a maximum of only 8196 global Internet
routes in the BGP table (for EBGP routes). Would this issue become
non-existant when that happens?


> \end{aside}
> 
> The stance as far as the protocol spec goes is that BGP/IGP
> interactions are out of scope.  Special cases to support a broken AS
> (one with incomplete IBGP connectivity) is definitely out of scope.
>
 
> 
> > > > Now in this fairly straightforward example, the router B 
> > > will forward routes
> > > > learned via IBGP to the next AS using EBGP, whereas for 
> > > those routes the
> > > > reachability in the FIB is taken care of by IGP (who has 
> > > typically a higher
> > > > preference in ther FIB then IBGP).
> > > > 
> > > > So, in theory the rule : "one must focus on the rule that a 
> > > BGP speaker
> > > > advertises to its peers  in neighboring ASs only those 
> > > routes that it itself
> > > > uses." is broken, since it is clearly an IGP route 
> which in the FIB.
> > > > 
> > > > ---
> > > > Hans de Vleeschouwer
> > > 
> > > The only way to fully address all of the instances of this sort of
> > > objection is to add to the spec "Most BGP implementations 
> allow the
> > > user to do things that violate the protocol specification in minor
> > > ways, sometimes with valid uses, but also sometimes with 
> questionalble
> > > uses and sometimes with dire consequences".  Although 
> this statement
> > > is true, I don't don't think we need to add this.
> > > 
> > This although is sometimes true, is bordering on being 
> rediculous for a 
> > spec. I agree, you do not want to add this or the reader 
> will stop reading
> > the spec.
> > 
> > Ben
> 
> I did mention it with the intent to show that it borders on ridiculous
> to try to accommodate all ways in which you can build a semi-broken
> BGP network or build one with semi-broken equipment and get it to
> actually work.  We seem to agree that we don't want to go down that
> road, either enumerating all of the cases or with the general caveat.
> 
> 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 PAA06261 for <[e-mail]>; Wed, 2 Oct 2002 15:45:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2AFF4912FC; Wed,  2 Oct 2002 15:44:57 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E053C912FD; Wed,  2 Oct 2002 15:44: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 77755912FC for <[e-mail]>; Wed,  2 Oct 2002 15:44:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5CE485DDF7; Wed,  2 Oct 2002 15:44: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 EE7225DDE7 for <[e-mail]>; Wed,  2 Oct 2002 15:44: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 PAA67025; Wed, 2 Oct 2002 15:44:02 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, [e-mail], BGP mailing list <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Active Route 
In-reply-to: Your message of "Wed, 02 Oct 2002 12:41:18 EDT." <[e-mail]> 
Date: Wed, 02 Oct 2002 15:44:02 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, 
"Abarbanel, Benjamin" writes:
> Curtis
> 
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:[e-mail]]
> > Sent: Wednesday, October 02, 2002 12:33 PM
> > To: [e-mail]
> > Cc: BGP mailing list
> > Subject: Re: Active Route 
> > 
> > 
> > 
> > In message <[e-mail]>, 
> > [e-mail] writ
> > es:
> > > 
> > > Then I redistribute the routes into IGP, and at the same 
> > time I forward
> > > the routes via IBGP (not full mesh) to all of the other AS 
> > border routers (bu
> > > t
> > > to no other routers).
> > 
> > This is an incredibly bad idea.  Only the BGP next_hop needs to be in
> > the IGP.
> > 
> > > At the other side of my AS, I allow the border router 
> > (router B) to pass thos
> > > e
> > > routes learned via IBGP (form router A) to the (next) AS 
> > via an EBGP connecti
> > > on.
> > > (I am using the  "synchronise BGP = TRUE" option.)
> > 
> > Synchronise implies that the BGP next_hop is reachable via the IGP
> > *not* the BGP prefix itself.
> > 
> > There is never a need to put the destination prefix into the IGP if it
> > is carried in IBGP except for the case where you are originating a
> > prefix and you want it to go out with specific attributes such as
> > specific BGP communities or indicate through BGP communities some
> > special action such as punching a hole in an aggregate.
> > 
> 
> What if your AS is not fully meshed as Hans pointed out? 
> 
> The only way to get external BGP routes to non-BGP (IGP only) routers is by
> redistributing them via IGP, and let IGP flood them, right?


{\begin{aside}

As someone formerly with two major ISPs, I'd say your AS is
broken.  Use route-reflectors if its just a matter of wanting to
reduce the mesh.  If you have routers or other device that don't do
BGP, get rid of them or arrange so that they can use a default route
(and then get then fixed or get rid of them).

This does happen with some very stupid and somewhat specialized edge
boxes which end up getting used because they are somewhat specialized
and do something right that is needed.  Its usually sufficient to give
them a default route to something with a bit more IP intelligence (and
then get rid of them if at all possible).  It is common to front end a
box like this with a small router just for this purpose.  This comment
on my part is really an aside though.

In practice, if you absolutely needed BGP injected into the IGP (and
hopefully a subset of the 250,000 BGP routes) you can export the IBGP
learned routes to EBGP so as not to lose the BGP attributes.  It is
out of scope for the spec as we've already stated numerous times.

\end{aside}

The stance as far as the protocol spec goes is that BGP/IGP
interactions are out of scope.  Special cases to support a broken AS
(one with incomplete IBGP connectivity) is definitely out of scope.


> > > Now in this fairly straightforward example, the router B 
> > will forward routes
> > > learned via IBGP to the next AS using EBGP, whereas for 
> > those routes the
> > > reachability in the FIB is taken care of by IGP (who has 
> > typically a higher
> > > preference in ther FIB then IBGP).
> > > 
> > > So, in theory the rule : "one must focus on the rule that a 
> > BGP speaker
> > > advertises to its peers  in neighboring ASs only those 
> > routes that it itself
> > > uses." is broken, since it is clearly an IGP route which in the FIB.
> > > 
> > > ---
> > > Hans de Vleeschouwer
> > 
> > The only way to fully address all of the instances of this sort of
> > objection is to add to the spec "Most BGP implementations allow the
> > user to do things that violate the protocol specification in minor
> > ways, sometimes with valid uses, but also sometimes with questionalble
> > uses and sometimes with dire consequences".  Although this statement
> > is true, I don't don't think we need to add this.
> > 
> This although is sometimes true, is bordering on being rediculous for a 
> spec. I agree, you do not want to add this or the reader will stop reading
> the spec.
> 
> Ben

I did mention it with the intent to show that it borders on ridiculous
to try to accommodate all ways in which you can build a semi-broken
BGP network or build one with semi-broken equipment and get it to
actually work.  We seem to agree that we don't want to go down that
road, either enumerating all of the cases or with the general caveat.

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 PAA05470 for <[e-mail]>; Wed, 2 Oct 2002 15:29:27 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 89822912FA; Wed,  2 Oct 2002 15:29:05 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 54BE8912FB; Wed,  2 Oct 2002 15:29: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 4F6F7912FA for <[e-mail]>; Wed,  2 Oct 2002 15:29:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3F2A75DDE8; Wed,  2 Oct 2002 15:29: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 A06E15DDC3 for <[e-mail]>; Wed,  2 Oct 2002 15:29:03 -0400 (EDT)
Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g92JT2m71005; Wed, 2 Oct 2002 12:29:02 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: Active Route 
In-reply-to: Your message of "Wed, 02 Oct 2002 10:19:49 EDT." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 02 Oct 2002 12:29:02 -0700
From: Dennis Ferguson <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jon,

> "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 means that if the speaker's routing table has a non-bgp route to a
> destination but does not have bgp route to the same destination (for
> example, based on administrative distance), then the speaker may not
> advertise that route to it's peers. This is true on Juniper by default for
> EBGP, but is NOT TRUE [ever?] on Juniper for IBGP, and is NOT TRUE on
> Juniper if ~= "advertise inactive" is enabled.  This is NOT TRUE ever on
> Cisco.

I would note that, for implementation reasons, it requires a moderately
unnatural act for Juniper routers to ever advertise a route to any
BGP peer, whether internal or external, which is not the route it is
using for forwarding.  I suspect that if you don't add "advertise inactive",
you'll find that the routers strictly conform to the quoted behaviour for
both EBGP and IBGP.  The knob is a relatively late addition added as a
concession to the fact that people are used to the Cisco behaviour, and some
have built configurations which depend on it.  I personally consider the
Cisco behaviour to be a bug, but it is the way some of the world works.

> Now we are proposing that the quoted clause above be completely removed.
> This means that it will be allowable to advertise a route to a destination
> that is not locally reachable.  This is obviously (to me, but not to all--
> which is why it should not be removed) bad. 

I think the algorithm Juniper routers use when the knob is enabled is that
there are two routes potentially available for readvertisement, the route
which the router is using for forwarding and the best BGP route which would
be usable for forwarding if the preferred (non-BGP) route(s) wasn't present.
If policy prohibits readvertisement of the first route but permits
readvertisement of the second route, the second route is readvertised.
While telling lies about the route you are using seems theoretically
fragile it is, however, hard to find practical cases where the above
algorithm would actually break much of anything.

Dennis Ferguson



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA05430 for <[e-mail]>; Wed, 2 Oct 2002 15:28:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 436A4912F9; Wed,  2 Oct 2002 15:28:11 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10B5F912FA; Wed,  2 Oct 2002 15:28: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 C25E2912F9 for <[e-mail]>; Wed,  2 Oct 2002 15:28:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id AF6BB5DDE7; Wed,  2 Oct 2002 15:28: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 700CA5DDC3 for <[e-mail]>; Wed,  2 Oct 2002 15:28:09 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12SMT>; Wed, 2 Oct 2002 15:28:09 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>, [e-mail]
Subject: notification 3/7 gone
Date: Wed, 2 Oct 2002 15:28:08 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

The fact that notification 3/7 (and whatever else) got deprecated should
be in the "Comparison with RFC1771" section please.

Thank you.


-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 3:12 PM
To: Yakov Rekhter
Cc: [e-mail]
Subject: Re: issue 62

Yakov,

On Wed, Oct 02, 2002 at 09:23:55AM -0700, Yakov Rekhter wrote:
>   62) Deprecate BGP Authentication Optional Parameter from RFC1771
> 
> I would suggest to remove the following text from the draft:

I would also suggest that if we remove it, in the section where
we talk about optional paramters that we say something like:

>          This document defines the following Optional Parameters:
> 
>          a) Authentication Information (Parameter Type 1):

Optional parameter type 1, Authentication Information, has been deprecated.

I hate reading specs where I can see an obvious hole in the numbering
scheme and not know why.

(Much like our error subcodes for UPDATE)

-- 
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 PAA05242 for <[e-mail]>; Wed, 2 Oct 2002 15:25:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 505B7912F8; Wed,  2 Oct 2002 15:25:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F148E912FB; Wed,  2 Oct 2002 15:25: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 5E6B6912F8 for <[e-mail]>; Wed,  2 Oct 2002 15:25:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 451195DDF2; Wed,  2 Oct 2002 15:25: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 C3B675DDEB for <[e-mail]>; Wed,  2 Oct 2002 15:25: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 g92JPOm70732; Wed, 2 Oct 2002 12:25:24 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 62 
In-Reply-To: Your message of "Wed, 02 Oct 2002 13:56:27 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 02 Oct 2002 12:25:24 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Eric,

> In addition to the change Yakov proposes, something 
> may need to be done with respect to the following
> text as well.
> -----------------------------------------------------------------------
> In section 2 (Introduction), sixth paragraph
> 
>    BGP runs over a reliable transport protocol. This eliminates the
>    need to implement explicit update fragmentation, retransmission,
>    acknowledgment, and sequencing. Any authentication scheme used by the
>    transport protocol (e.g., RFC2385 [10]) may be used in addition to
>    BGP's own authentication mechanisms. The error notification mechanism
>    used in BGP assumes that the transport protocol supports a "graceful"
>    close, i.e., that all outstanding data will be delivered before the
>    connection is closed.
> 
> Could be changed to 
> 
>    BGP runs over a reliable transport protocol. This eliminates the
>    need to implement explicit update fragmentation, retransmission,
>    acknowledgment, and sequencing. Any authentication scheme used by
>    the transport protocol (e.g., RFC2385 [10]) may be used. The error
>    notification mechanism used in BGP assumes that the transport 
>    protocol supports a "graceful" close, i.e., that all outstanding 
>    data will be delivered before the connection is closed.

The "reliable transport protocol" used by BGP is TCP. With this in mind
how about the following:

   BGP uses TCP [RFC793] as its transport protocol. This eliminates
   the need to implement explicit update fragmentation, retransmission,
   acknowledgment, and sequencing. BGP listens on TCP port 179. Any
   authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may be
   used. The error notification mechanism used in BGP assumes that TCP 
   supports a "graceful" close, i.e., that all outstanding data will 
   be delivered before the connection is closed.

> -----------------------------------------------------------------------
> In section 4.1 (Message Header Format), after the figure
> 
>      Marker:
> 
>          This 16-octet field contains a value that the receiver of the
>          message can predict.  If the Type of the message is OPEN, or if
>          the OPEN message carries no Authentication Information (as an
>          Optional Parameter), then the Marker must be all ones.
>          Otherwise, the value of the marker can be predicted by some a
>          computation specified as part of the authentication mechanism
>          (which is specified as part of the Authentication Information)
>          used.  The Marker can be used to detect loss of synchronization
>          between a pair of BGP peers, and to authenticate incoming BGP
>          messages.
> 
> This could be changed to:
> 
>      Marker:
> 
>          This 16-octet field is included for compatibility; it must be
>          set to all ones.
> ----------------------------------------------------------------------
> In section 6.1 (Message Header error handling), second paragraph
> 
>    The expected value of the Marker field of the message header is all
>    ones if the message type is OPEN.  The expected value of the Marker
>    field for all other types of BGP messages determined based on the
>    presence of the Authentication Information Optional Parameter in the
>    BGP OPEN message and the actual authentication mechanism (if the
>    Authentication Information in the BGP OPEN message is present). If
>    the Marker field of the message header is not the expected one, then
>    a synchronization error has occurred and the Error Subcode is set to
>    Connection Not Synchronized.
> 
> Which could be replaced by
> 
>    The expected value of the Marker field of the message header is all
>    ones. If the Marker field of the message header is not as expected,
>    then a synchronization error has occurred and the Error Subcode is  
>    set to Connection Not Synchronized.
> -----------------------------------------------------------------------
> Also, the last paragraph in section 6.2 (OPEN message error handling)
> 
>    If the OPEN message carries Authentication Information (as an
>    Optional Parameter), then the corresponding authentication procedure
>    is invoked.  If the authentication procedure (based on Authentication
>    Code and Authentication Data) fails, then the Error Subcode is set to
>    Authentication Failure.
> 
> Could be deleted.
> ------------------------------------------------------------------------
> Finally, we need to deal with bullet 6 in Appendix 4 (which will
> probably occur anyway since Appendix 4 needs to be re-written to
> reflect that this new RFC differs from RFC 1771 instead of 1105).

Differences between this document and RFC1771 is in Appendix 1,
not Appendix 4. Appendix 1 will have the text to indicate that
the Authentication Information parameter is eliminated.
   
Yakov.

> 
> 
> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> [e-mail]
> 508 305 7214
> 
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Wednesday, October 02, 2002 12:24 PM
> > To: [e-mail]
> > Subject: issue 62
> > 
> > Folks,
> > 
> >   62) Deprecate BGP Authentication Optional Parameter from RFC1771
> >   ------------------------------------------------------------------------
> > ----
> >   Status: No Consensus
> >   Change: Potentially
> >   Summary: We are at consensus, in that we agree that we should deprecate
> >    the BGP Authentication Optional Parameter as described in RFC1771 in
> >    favor of the mechanism described in RFC2385.  We do not have new text
> > for
> >    the draft yet, of if we are going to pull the reference entirely.
> > 
> > I would suggest to remove the following text from the draft:
> > 
> >          This document defines the following Optional Parameters:
> > 
> >          a) Authentication Information (Parameter Type 1):
> > 
> > 
> >             This optional parameter may be used to authenticate a BGP
> >             peer. The Parameter Value field contains a 1-octet
> >             Authentication Code followed by a variable length
> >             Authentication Data.
> > 
> >                 0 1 2 3 4 5 6 7 8
> >                 +-+-+-+-+-+-+-+-+
> >                 |  Auth. Code   |
> >                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >                 |                                                     |
> >                 |              Authentication Data                    |
> >                 |                                                     |
> >                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > 
> >                Authentication Code:
> > 
> >                   This 1-octet unsigned integer indicates the
> >                   authentication mechanism being used. Whenever an
> >                   authentication mechanism is specified for use within
> >                   BGP, three things must be included in the
> >                   specification:
> > 
> >                   - the value of the Authentication Code which indicates
> >                   use of the mechanism,
> >                   - the form and meaning of the Authentication Data, and
> >                   - the algorithm for computing values of Marker fields.
> > 
> >                   Note that a separate authentication mechanism may be
> >                   used in establishing the transport level connection.
> > 
> >                Authentication Data:
> > 
> >                   Authentication Data is a variable length field that is
> >                   interpreted according to the value of the
> >                   Authentication Code field.
> > 
> > If there are objections to this, then I would add the following:
> > 
> >    This document deprecates the use of the Authentication Information
> >    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 PAA05215 for <[e-mail]>; Wed, 2 Oct 2002 15:25:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D3D2A912F7; Wed,  2 Oct 2002 15:24:53 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2F4E912F8; Wed,  2 Oct 2002 15:24: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 91231912F7 for <[e-mail]>; Wed,  2 Oct 2002 15:24:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7A1445DDE7; Wed,  2 Oct 2002 15:24: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 9CBB05DDD4 for <[e-mail]>; Wed,  2 Oct 2002 15:24:51 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g92JOmq25372; Wed, 2 Oct 2002 15:24: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 g92JObC25331; Wed, 2 Oct 2002 15:24:37 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g92JOb016754; Wed, 2 Oct 2002 15:24:37 -0400 (EDT)
Date: Wed, 2 Oct 2002 15:24:37 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: FW: issue 62
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, Oct 02, 2002 at 03:21:18PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Oct 02, 2002 at 03:21:18PM -0400, Natale, Jonathan wrote:
> > "This document deprecates the use of the Authentication
> > Information optional parameter [N].
> > 
> > ...does not need to be added, since this
> > will be explained in the "Comparison with RFC1771", right?

That is fine so long as we document what the number used to be.
I don't care where it goes.  :-)

-- 
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 PAA05041 for <[e-mail]>; Wed, 2 Oct 2002 15:21:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BA983912DA; Wed,  2 Oct 2002 15:21:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85E7A912F7; Wed,  2 Oct 2002 15:21: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 067DD912DA for <[e-mail]>; Wed,  2 Oct 2002 15:21:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DF1035DDD4; Wed,  2 Oct 2002 15:21: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 910685DDC3 for <[e-mail]>; Wed,  2 Oct 2002 15:21:19 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12SLZ>; Wed, 2 Oct 2002 15:21:19 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: FW: issue 62 
Date: Wed, 2 Oct 2002 15:21:18 -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: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 3:17 PM
To: Natale, Jonathan
Subject: Re: issue 62 

Jonathan,

> Just remove it.

Ok. Could you please repost it to the IDR mailing list.

Thanks.

Yakov.

> 
> "This document deprecates the use of the Authentication
> Information optional parameter [N].
> 
> ...does not need to be added, since this
> will be explained in the "Comparison with RFC1771", right?
> 
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Wednesday, October 02, 2002 2:50 PM
> To: Natale, Jonathan
> Subject: Re: issue 62 
> 
> Jonathan,
> 
> > agreed
> 
> Do you agree with the first option (removing the text), or with
> the second one (keeping the text, but adding the sentence) ?
> 
> Yakov.
> 
> > 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]] 
> > Sent: Wednesday, October 02, 2002 12:24 PM
> > To: [e-mail]
> > Subject: issue 62
> > 
> > Folks,
> > 
> >   62) Deprecate BGP Authentication Optional Parameter from RFC1771
> >  
> >
>
----------------------------------------------------------------------------
> >   Status: No Consensus
> >   Change: Potentially
> >   Summary: We are at consensus, in that we agree that we should
deprecate
> >    the BGP Authentication Optional Parameter as described in RFC1771 in
> >    favor of the mechanism described in RFC2385.  We do not have new text
> for
> >    the draft yet, of if we are going to pull the reference entirely.
> > 
> > I would suggest to remove the following text from the draft:
> > 
> >          This document defines the following Optional Parameters:
> > 
> >          a) Authentication Information (Parameter Type 1):
> > 
> > 
> >             This optional parameter may be used to authenticate a BGP
> >             peer. The Parameter Value field contains a 1-octet
> >             Authentication Code followed by a variable length
> >             Authentication Data.
> > 
> >                 0 1 2 3 4 5 6 7 8
> >                 +-+-+-+-+-+-+-+-+
> >                 |  Auth. Code   |
> >                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >                 |                                                     |
> >                 |              Authentication Data                    |
> >                 |                                                     |
> >                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > 
> >                Authentication Code:
> > 
> >                   This 1-octet unsigned integer indicates the
> >                   authentication mechanism being used. Whenever an
> >                   authentication mechanism is specified for use within
> >                   BGP, three things must be included in the
> >                   specification:
> > 
> >                   - the value of the Authentication Code which indicates
> >                   use of the mechanism,
> >                   - the form and meaning of the Authentication Data, and
> >                   - the algorithm for computing values of Marker fields.
> > 
> >                   Note that a separate authentication mechanism may be
> >                   used in establishing the transport level connection.
> > 
> >                Authentication Data:
> > 
> >                   Authentication Data is a variable length field that is
> >                   interpreted according to the value of the
> >                   Authentication Code field.
> > 
> > If there are objections to this, then I would add the following:
> > 
> >    This document deprecates the use of the Authentication Information
> >    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 PAA04772 for <[e-mail]>; Wed, 2 Oct 2002 15:15:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6989B912F5; Wed,  2 Oct 2002 15:14:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 32D0F912F7; Wed,  2 Oct 2002 15: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 F2A4C912F5 for <[e-mail]>; Wed,  2 Oct 2002 15:14:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E2BED5DDD4; Wed,  2 Oct 2002 15:14:50 -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 515015DDC3 for <[e-mail]>; Wed,  2 Oct 2002 15:14:50 -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 g92JEjm69688; Wed, 2 Oct 2002 12:14:45 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Jeffrey Haas <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 62 
In-Reply-To: Your message of "Wed, 02 Oct 2002 15:11:34 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 02 Oct 2002 12:14:45 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jeff,

> On Wed, Oct 02, 2002 at 09:23:55AM -0700, Yakov Rekhter wrote:
> >   62) Deprecate BGP Authentication Optional Parameter from RFC1771
> > 
> > I would suggest to remove the following text from the draft:
> 
> I would also suggest that if we remove it, in the section where
> we talk about optional paramters that we say something like:
> 
> >          This document defines the following Optional Parameters:
> > 
> >          a) Authentication Information (Parameter Type 1):
> 
> Optional parameter type 1, Authentication Information, has been deprecated.

That would be fine.

Yakov.

> I hate reading specs where I can see an obvious hole in the numbering
> scheme and not know why.
> 
> (Much like our error subcodes for UPDATE)
> 
> -- 
> 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 PAA04548 for <[e-mail]>; Wed, 2 Oct 2002 15:11:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 885CF912F4; Wed,  2 Oct 2002 15:11:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F992912F5; Wed,  2 Oct 2002 15: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 39B47912F4 for <[e-mail]>; Wed,  2 Oct 2002 15:11:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1E1D15DDE7; Wed,  2 Oct 2002 15:11: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 5A7F85DDC3 for <[e-mail]>; Wed,  2 Oct 2002 15:11:39 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g92JBbx24811; Wed, 2 Oct 2002 15:11: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 g92JBYC24804; Wed, 2 Oct 2002 15:11:34 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g92JBYD14855; Wed, 2 Oct 2002 15:11:34 -0400 (EDT)
Date: Wed, 2 Oct 2002 15:11:34 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 62
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, Oct 02, 2002 at 09:23:55AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

Yakov,

On Wed, Oct 02, 2002 at 09:23:55AM -0700, Yakov Rekhter wrote:
>   62) Deprecate BGP Authentication Optional Parameter from RFC1771
> 
> I would suggest to remove the following text from the draft:

I would also suggest that if we remove it, in the section where
we talk about optional paramters that we say something like:

>          This document defines the following Optional Parameters:
> 
>          a) Authentication Information (Parameter Type 1):

Optional parameter type 1, Authentication Information, has been deprecated.

I hate reading specs where I can see an obvious hole in the numbering
scheme and not know why.

(Much like our error subcodes for UPDATE)

-- 
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 PAA04520 for <[e-mail]>; Wed, 2 Oct 2002 15:11:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 80E38912F6; Wed,  2 Oct 2002 15:10:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 462DC912F5; Wed,  2 Oct 2002 15:10: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 7846F912F4 for <[e-mail]>; Wed,  2 Oct 2002 15:10:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5D4615DDF2; Wed,  2 Oct 2002 15:10:41 -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 21FC05DDE7 for <[e-mail]>; Wed,  2 Oct 2002 15:10:41 -0400 (EDT)
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2656.59) id <TRPKQ1WL>; Wed, 2 Oct 2002 15:10:40 -0400
Message-ID: <[e-mail]>
From: "Martin, Christian" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "Martin, Christian" <[e-mail]>
Cc: [e-mail]
Subject: RE: Active Route
Date: Wed, 2 Oct 2002 15:10:32 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

That is what I meant.  We have two choices:

1) Announce only if it is the best BGP route and the route exists in the
rib.
-or-
2) Announce only if it is the best route and the route was learned via BGP
and it is in your RIB.

This about covers it, I think.

-chris



>-----Original Message-----
>From: Natale, Jonathan [mailto:[e-mail]] 
>Sent: Wednesday, October 02, 2002 11:33 AM
>To: 'Martin, Christian'
>Cc: [e-mail]
>Subject: RE: Active Route
>
>
>Christian,
>
>Thank you for replying.
>
>Your change would not cover the case, for example, where the 
>speaker uses a static route that is not redistributed into bgp 
>to reach a set of destinations that is also learned via bgp.
>
>I was thinking of:
>"one must focus on the rule that a BGP speaker advertises to 
>its peers only routes whose set of destinations
>are reachable per the local Routing Table."
>
>
>-----Original Message-----
>From: Martin, Christian [mailto:[e-mail]] 
>Sent: Wednesday, October 02, 2002 10:28 AM
>To: 'Natale, Jonathan'; [e-mail]
>Subject: RE: Active Route
>
>Jonathan,
>
>>
>>"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 means that if the speaker's routing table has a non-bgp
>>route to a destination but does not have bgp route to the same 
>>destination (for example, based on administrative distance), 
>>then the speaker may not advertise that route to it's peers. 
>>This is true on Juniper by default for EBGP, but is NOT TRUE 
>>[ever?] on Juniper for IBGP, and is NOT TRUE on Juniper if ~= 
>>"advertise inactive" is enabled.  This is NOT TRUE ever on Cisco.
>>
>>Now we are proposing that the quoted clause above be
>>completely removed. This means that it will be allowable to 
>>advertise a route to a destination that is not locally 
>>reachable.  This is obviously (to me, but not to all-- which 
>>is why it should not be removed) bad. 
>
>This, IMO, is not the spirit of the rule.  Juniper interpreted 
>the spec differently.  As I see it, if the route is in the 
>routing table, you can announce it.  To be more specific, and 
>to your point Jonathan, we should say this - or say the converse:
>
>"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 learned via BGP that it 
>itself uses.  "Learned via BGP" means that a router's best 
>path to a prefix is one that was either learned from a BGP 
>peer, or deliberately injected into BGP by the local router."
>
>Regards,
>-chris
>
>
>
>
>>
>>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 OAA03647 for <[e-mail]>; Wed, 2 Oct 2002 14:54:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 97D7C912F2; Wed,  2 Oct 2002 14:51:06 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D0EC912F4; Wed,  2 Oct 2002 14:51: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 5F041912F2 for <[e-mail]>; Wed,  2 Oct 2002 14:49:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 407D65DDE3; Wed,  2 Oct 2002 14:49: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 A0FC55DDC3 for <[e-mail]>; Wed,  2 Oct 2002 14:49: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 g92Incm60748; Wed, 2 Oct 2002 11:49:38 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Gray, Eric" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 62 
In-Reply-To: Your message of "Wed, 02 Oct 2002 13:19:41 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 02 Oct 2002 11:49:38 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Eric,

> Yakov,
> 
> 	I assume you meant "If there are _no_ objections ..."

I meant "If there are objections" to removing the text, then
we can keep the text, but will add the sentence I mentioned below.

Yakov.

> 
> Eric W. Gray
> Systems Architect
> Celox Networks, Inc.
> [e-mail]
> 508 305 7214
> 
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]]
> > Sent: Wednesday, October 02, 2002 12:24 PM
> > To: [e-mail]
> > Subject: issue 62
> > 
> > Folks,
> > 
> >   62) Deprecate BGP Authentication Optional Parameter from RFC1771
> >   ------------------------------------------------------------------------
> > ----
> >   Status: No Consensus
> >   Change: Potentially
> >   Summary: We are at consensus, in that we agree that we should deprecate
> >    the BGP Authentication Optional Parameter as described in RFC1771 in
> >    favor of the mechanism described in RFC2385.  We do not have new text
> > for
> >    the draft yet, of if we are going to pull the reference entirely.
> > 
> > I would suggest to remove the following text from the draft:
> > 
> >          This document defines the following Optional Parameters:
> > 
> >          a) Authentication Information (Parameter Type 1):
> > 
> > 
> >             This optional parameter may be used to authenticate a BGP
> >             peer. The Parameter Value field contains a 1-octet
> >             Authentication Code followed by a variable length
> >             Authentication Data.
> > 
> >                 0 1 2 3 4 5 6 7 8
> >                 +-+-+-+-+-+-+-+-+
> >                 |  Auth. Code   |
> >                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >                 |                                                     |
> >                 |              Authentication Data                    |
> >                 |                                                     |
> >                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> > 
> >                Authentication Code:
> > 
> >                   This 1-octet unsigned integer indicates the
> >                   authentication mechanism being used. Whenever an
> >                   authentication mechanism is specified for use within
> >                   BGP, three things must be included in the
> >                   specification:
> > 
> >                   - the value of the Authentication Code which indicates
>                   use of the mechanism,
> >                   - the form and meaning of the Authentication Data, and
> >                   - the algorithm for computing values of Marker fields.
> > 
> >                   Note that a separate authentication mechanism may be
> >                   used in establishing the transport level connection.
> > 
> >                Authentication Data:
> > 
> >                   Authentication Data is a variable length field that is
> >                   interpreted according to the value of the
> >                   Authentication Code field.
> > 
> > If there are objections to this, then I would add the following:
> > 
> >    This document deprecates the use of the Authentication Information
> >    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 OAA02295 for <[e-mail]>; Wed, 2 Oct 2002 14:26:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7517E912D1; Wed,  2 Oct 2002 14:26:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 42637912EF; Wed,  2 Oct 2002 14: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 AF080912D1 for <[e-mail]>; Wed,  2 Oct 2002 14:26:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 90A8D5DE0B; Wed,  2 Oct 2002 14:26: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 C3D125DE02 for <[e-mail]>; Wed,  2 Oct 2002 14:26:16 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12S1X>; Wed, 2 Oct 2002 14:26:16 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "Gray, Eric" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 62
Date: Wed, 2 Oct 2002 14:26:15 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

agree

-----Original Message-----
From: Gray, Eric [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 1:56 PM
To: 'Yakov Rekhter'; [e-mail]
Subject: RE: issue 62

In addition to the change Yakov proposes, something 
may need to be done with respect to the following
text as well.
-----------------------------------------------------------------------
In section 2 (Introduction), sixth paragraph

   BGP runs over a reliable transport protocol. This eliminates the
   need to implement explicit update fragmentation, retransmission,
   acknowledgment, and sequencing. Any authentication scheme used by the
   transport protocol (e.g., RFC2385 [10]) may be used in addition to
   BGP's own authentication mechanisms. The error notification mechanism
   used in BGP assumes that the transport protocol supports a "graceful"
   close, i.e., that all outstanding data will be delivered before the
   connection is closed.

Could be changed to 

   BGP runs over a reliable transport protocol. This eliminates the
   need to implement explicit update fragmentation, retransmission,
   acknowledgment, and sequencing. Any authentication scheme used by
   the transport protocol (e.g., RFC2385 [10]) may be used. The error
   notification mechanism used in BGP assumes that the transport 
   protocol supports a "graceful" close, i.e., that all outstanding 
   data will be delivered before the connection is closed.
-----------------------------------------------------------------------
In section 4.1 (Message Header Format), after the figure

     Marker:

         This 16-octet field contains a value that the receiver of the
         message can predict.  If the Type of the message is OPEN, or if
         the OPEN message carries no Authentication Information (as an
         Optional Parameter), then the Marker must be all ones.
         Otherwise, the value of the marker can be predicted by some a
         computation specified as part of the authentication mechanism
         (which is specified as part of the Authentication Information)
         used.  The Marker can be used to detect loss of synchronization
         between a pair of BGP peers, and to authenticate incoming BGP
         messages.

This could be changed to:

     Marker:

         This 16-octet field is included for compatibility; it must be
         set to all ones.
----------------------------------------------------------------------
In section 6.1 (Message Header error handling), second paragraph

   The expected value of the Marker field of the message header is all
   ones if the message type is OPEN.  The expected value of the Marker
   field for all other types of BGP messages determined based on the
   presence of the Authentication Information Optional Parameter in the
   BGP OPEN message and the actual authentication mechanism (if the
   Authentication Information in the BGP OPEN message is present). If
   the Marker field of the message header is not the expected one, then
   a synchronization error has occurred and the Error Subcode is set to
   Connection Not Synchronized.

Which could be replaced by

   The expected value of the Marker field of the message header is all
   ones. If the Marker field of the message header is not as expected,
   then a synchronization error has occurred and the Error Subcode is  
   set to Connection Not Synchronized.
-----------------------------------------------------------------------
Also, the last paragraph in section 6.2 (OPEN message error handling)

   If the OPEN message carries Authentication Information (as an
   Optional Parameter), then the corresponding authentication procedure
   is invoked.  If the authentication procedure (based on Authentication
   Code and Authentication Data) fails, then the Error Subcode is set to
   Authentication Failure.

Could be deleted.
------------------------------------------------------------------------
Finally, we need to deal with bullet 6 in Appendix 4 (which will
probably occur anyway since Appendix 4 needs to be re-written to
reflect that this new RFC differs from RFC 1771 instead of 1105).


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


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, October 02, 2002 12:24 PM
> To: [e-mail]
> Subject: issue 62
> 
> Folks,
> 
>   62) Deprecate BGP Authentication Optional Parameter from RFC1771
>   ------------------------------------------------------------------------
> ----
>   Status: No Consensus
>   Change: Potentially
>   Summary: We are at consensus, in that we agree that we should deprecate
>    the BGP Authentication Optional Parameter as described in RFC1771 in
>    favor of the mechanism described in RFC2385.  We do not have new text
> for
>    the draft yet, of if we are going to pull the reference entirely.
> 
> I would suggest to remove the following text from the draft:
> 
>          This document defines the following Optional Parameters:
> 
>          a) Authentication Information (Parameter Type 1):
> 
> 
>             This optional parameter may be used to authenticate a BGP
>             peer. The Parameter Value field contains a 1-octet
>             Authentication Code followed by a variable length
>             Authentication Data.
> 
>                 0 1 2 3 4 5 6 7 8
>                 +-+-+-+-+-+-+-+-+
>                 |  Auth. Code   |
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                 |                                                     |
>                 |              Authentication Data                    |
>                 |                                                     |
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>                Authentication Code:
> 
>                   This 1-octet unsigned integer indicates the
>                   authentication mechanism being used. Whenever an
>                   authentication mechanism is specified for use within
>                   BGP, three things must be included in the
>                   specification:
> 
>                   - the value of the Authentication Code which indicates
>                   use of the mechanism,
>                   - the form and meaning of the Authentication Data, and
>                   - the algorithm for computing values of Marker fields.
> 
>                   Note that a separate authentication mechanism may be
>                   used in establishing the transport level connection.
> 
>                Authentication Data:
> 
>                   Authentication Data is a variable length field that is
>                   interpreted according to the value of the
>                   Authentication Code field.
> 
> If there are objections to this, then I would add the following:
> 
>    This document deprecates the use of the Authentication Information
>    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 OAA01085 for <[e-mail]>; Wed, 2 Oct 2002 14:02:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 24823912EE; Wed,  2 Oct 2002 14:01:34 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E4B3912EF; Wed,  2 Oct 2002 14:01: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 70099912EE for <[e-mail]>; Wed,  2 Oct 2002 14:01:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 45D045DDDD; Wed,  2 Oct 2002 14:01:22 -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 ED26E5DD8E for <[e-mail]>; Wed,  2 Oct 2002 14:01:21 -0400 (EDT)
Received: from riga ([10.0.0.25]) by earthquake.proficient.net with Microsoft SMTPSVC(5.0.2195.4905); Wed, 2 Oct 2002 11:01:21 -0700
Subject: Re: issue 8
From: Justin Fletcher <[e-mail]>
To: [e-mail]
Cc: Yakov Rekhter <[e-mail]>, [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: 02 Oct 2002 10:59:42 -0700
Message-Id: <1033581582.2301.26.camel@riga>
Mime-Version: 1.0
X-OriginalArrivalTime: 02 Oct 2002 18:01:21.0195 (UTC) FILETIME=[B6C8AFB0:01C26A3D]
Sender: [e-mail]
Precedence: bulk

On Wed, 2002-10-02 at 10:23, Curtis Villamizar wrote:
> 
> In message <1033574178.27465.34.camel@riga>, Justin Fletcher writes:
> > >    The amount of jitter to be introduced shall be determined by
> > >    multiplying the base value of the appropriate timer by a random
> > >    factor which is uniformly distributed in the range from 0.75 to
> > >    1.0.
> > 
> > I'd suggest "uniformly distributed in the range from 0.75 to 1.25"
> > to ensure the average is the configured interval.
> > 
> > Justin Fletcher
> 
> 
> This is just a suggested default value and an implementor is free to
> use another such as .75 to 1.25 (and it would be a good idea to
> document it clearly).  Some conformance freak might take this as
> gospel and also check the uniformness of the random distribution but
> that too is a recommended default and selection from some other
> distribution (tail truncated) would still be compliant.  Someone might
> pick .75 to 1.25 if preserving the mean value seemed more appealing
> and someone else might use another distribution if it saved a few CPU
> cycles and both would be OK.
> 
> Briefly - it doesn't matter.
> 
> Curtis

That is rather the question, isn't it?  If we're looking at this from
a new implementor's point of view, how do you know that this doesn't
matter from reading text that reads "shall be determined"?

If most implementations use other values and it doesn't matter,
I'd suggest the first line of the text to read

"A recommended amount of jitter to be introduced may be determined by"

In retrospect, I'd be happy with either the original text or any of the
proposed changes; it's not a strong opinion :-) and I wouldn't have
raised the issue in the first place if I'd done my homework & checked
the RFC.

Justin




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA00835 for <[e-mail]>; Wed, 2 Oct 2002 13:56:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 53C0091257; Wed,  2 Oct 2002 13:56:30 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25853912EE; Wed,  2 Oct 2002 13:56: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 A60C791257 for <[e-mail]>; Wed,  2 Oct 2002 13:56:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 916F55DDDD; Wed,  2 Oct 2002 13:56: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 4994C5DD8E for <[e-mail]>; Wed,  2 Oct 2002 13:56:28 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12SA5>; Wed, 2 Oct 2002 13:56:27 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 62
Date: Wed, 2 Oct 2002 13:56:27 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

In addition to the change Yakov proposes, something 
may need to be done with respect to the following
text as well.
-----------------------------------------------------------------------
In section 2 (Introduction), sixth paragraph

   BGP runs over a reliable transport protocol. This eliminates the
   need to implement explicit update fragmentation, retransmission,
   acknowledgment, and sequencing. Any authentication scheme used by the
   transport protocol (e.g., RFC2385 [10]) may be used in addition to
   BGP's own authentication mechanisms. The error notification mechanism
   used in BGP assumes that the transport protocol supports a "graceful"
   close, i.e., that all outstanding data will be delivered before the
   connection is closed.

Could be changed to 

   BGP runs over a reliable transport protocol. This eliminates the
   need to implement explicit update fragmentation, retransmission,
   acknowledgment, and sequencing. Any authentication scheme used by
   the transport protocol (e.g., RFC2385 [10]) may be used. The error
   notification mechanism used in BGP assumes that the transport 
   protocol supports a "graceful" close, i.e., that all outstanding 
   data will be delivered before the connection is closed.
-----------------------------------------------------------------------
In section 4.1 (Message Header Format), after the figure

     Marker:

         This 16-octet field contains a value that the receiver of the
         message can predict.  If the Type of the message is OPEN, or if
         the OPEN message carries no Authentication Information (as an
         Optional Parameter), then the Marker must be all ones.
         Otherwise, the value of the marker can be predicted by some a
         computation specified as part of the authentication mechanism
         (which is specified as part of the Authentication Information)
         used.  The Marker can be used to detect loss of synchronization
         between a pair of BGP peers, and to authenticate incoming BGP
         messages.

This could be changed to:

     Marker:

         This 16-octet field is included for compatibility; it must be
         set to all ones.
----------------------------------------------------------------------
In section 6.1 (Message Header error handling), second paragraph

   The expected value of the Marker field of the message header is all
   ones if the message type is OPEN.  The expected value of the Marker
   field for all other types of BGP messages determined based on the
   presence of the Authentication Information Optional Parameter in the
   BGP OPEN message and the actual authentication mechanism (if the
   Authentication Information in the BGP OPEN message is present). If
   the Marker field of the message header is not the expected one, then
   a synchronization error has occurred and the Error Subcode is set to
   Connection Not Synchronized.

Which could be replaced by

   The expected value of the Marker field of the message header is all
   ones. If the Marker field of the message header is not as expected,
   then a synchronization error has occurred and the Error Subcode is  
   set to Connection Not Synchronized.
-----------------------------------------------------------------------
Also, the last paragraph in section 6.2 (OPEN message error handling)

   If the OPEN message carries Authentication Information (as an
   Optional Parameter), then the corresponding authentication procedure
   is invoked.  If the authentication procedure (based on Authentication
   Code and Authentication Data) fails, then the Error Subcode is set to
   Authentication Failure.

Could be deleted.
------------------------------------------------------------------------
Finally, we need to deal with bullet 6 in Appendix 4 (which will
probably occur anyway since Appendix 4 needs to be re-written to
reflect that this new RFC differs from RFC 1771 instead of 1105).


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


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, October 02, 2002 12:24 PM
> To: [e-mail]
> Subject: issue 62
> 
> Folks,
> 
>   62) Deprecate BGP Authentication Optional Parameter from RFC1771
>   ------------------------------------------------------------------------
> ----
>   Status: No Consensus
>   Change: Potentially
>   Summary: We are at consensus, in that we agree that we should deprecate
>    the BGP Authentication Optional Parameter as described in RFC1771 in
>    favor of the mechanism described in RFC2385.  We do not have new text
> for
>    the draft yet, of if we are going to pull the reference entirely.
> 
> I would suggest to remove the following text from the draft:
> 
>          This document defines the following Optional Parameters:
> 
>          a) Authentication Information (Parameter Type 1):
> 
> 
>             This optional parameter may be used to authenticate a BGP
>             peer. The Parameter Value field contains a 1-octet
>             Authentication Code followed by a variable length
>             Authentication Data.
> 
>                 0 1 2 3 4 5 6 7 8
>                 +-+-+-+-+-+-+-+-+
>                 |  Auth. Code   |
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                 |                                                     |
>                 |              Authentication Data                    |
>                 |                                                     |
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>                Authentication Code:
> 
>                   This 1-octet unsigned integer indicates the
>                   authentication mechanism being used. Whenever an
>                   authentication mechanism is specified for use within
>                   BGP, three things must be included in the
>                   specification:
> 
>                   - the value of the Authentication Code which indicates
>                   use of the mechanism,
>                   - the form and meaning of the Authentication Data, and
>                   - the algorithm for computing values of Marker fields.
> 
>                   Note that a separate authentication mechanism may be
>                   used in establishing the transport level connection.
> 
>                Authentication Data:
> 
>                   Authentication Data is a variable length field that is
>                   interpreted according to the value of the
>                   Authentication Code field.
> 
> If there are objections to this, then I would add the following:
> 
>    This document deprecates the use of the Authentication Information
>    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 NAA29861 for <[e-mail]>; Wed, 2 Oct 2002 13:33:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5279B912ED; Wed,  2 Oct 2002 13:33:20 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DCCF912EE; Wed,  2 Oct 2002 13:33: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 B4D2A912ED for <[e-mail]>; Wed,  2 Oct 2002 13:33:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 942E55DDD9; Wed,  2 Oct 2002 13:33: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 458085DDD4 for <[e-mail]>; Wed,  2 Oct 2002 13:33:16 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12R8L>; Wed, 2 Oct 2002 13:33:15 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Abarbanel, Benjamin'" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Cc: BGP mailing list <[e-mail]>
Subject: RE: Active Route - OT
Date: Wed, 2 Oct 2002 13:33:15 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

"What if your AS is not fully meshed as Hans pointed out?"

Then you are mis-configured.

Also, I agree with Curtis--redistributing BGP into IGP is a bad idea.  A
much better idea is to turn off synchronization (rumor was that it will
be/is off by default in newer IOS).  Juniper does not even have a synch
concept (a good thing).

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 12:41 PM
To: '[e-mail]'; [e-mail]
Cc: BGP mailing list
Subject: RE: Active Route 

Curtis

> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Wednesday, October 02, 2002 12:33 PM
> To: [e-mail]
> Cc: BGP mailing list
> Subject: Re: Active Route 
> 
> 
> 
> In message <[e-mail]>, 
> [e-mail] writ
> es:
> > 
> > Then I redistribute the routes into IGP, and at the same 
> time I forward
> > the routes via IBGP (not full mesh) to all of the other AS 
> border routers (bu
> > t
> > to no other routers).
> 
> This is an incredibly bad idea.  Only the BGP next_hop needs to be in
> the IGP.
> 
> > At the other side of my AS, I allow the border router 
> (router B) to pass thos
> > e
> > routes learned via IBGP (form router A) to the (next) AS 
> via an EBGP connecti
> > on.
> > (I am using the  "synchronise BGP = TRUE" option.)
> 
> Synchronise implies that the BGP next_hop is reachable via the IGP
> *not* the BGP prefix itself.
> 
> There is never a need to put the destination prefix into the IGP if it
> is carried in IBGP except for the case where you are originating a
> prefix and you want it to go out with specific attributes such as
> specific BGP communities or indicate through BGP communities some
> special action such as punching a hole in an aggregate.
> 

What if your AS is not fully meshed as Hans pointed out? 

The only way to get external BGP routes to non-BGP (IGP only) routers is by
redistributing them via IGP, and let IGP flood them, right?


> > Now in this fairly straightforward example, the router B 
> will forward routes
> > learned via IBGP to the next AS using EBGP, whereas for 
> those routes the
> > reachability in the FIB is taken care of by IGP (who has 
> typically a higher
> > preference in ther FIB then IBGP).
> > 
> > So, in theory the rule : "one must focus on the rule that a 
> BGP speaker
> > advertises to its peers  in neighboring ASs only those 
> routes that it itself
> > uses." is broken, since it is clearly an IGP route which in the FIB.
> > 
> > ---
> > Hans de Vleeschouwer
> 
> The only way to fully address all of the instances of this sort of
> objection is to add to the spec "Most BGP implementations allow the
> user to do things that violate the protocol specification in minor
> ways, sometimes with valid uses, but also sometimes with questionalble
> uses and sometimes with dire consequences".  Although this statement
> is true, I don't don't think we need to add this.
> 
This although is sometimes true, is bordering on being rediculous for a 
spec. I agree, you do not want to add this or the reader will stop reading
the spec.

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 NAA29703 for <[e-mail]>; Wed, 2 Oct 2002 13:29:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2D683912EB; Wed,  2 Oct 2002 13:29:37 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8C8D912ED; Wed,  2 Oct 2002 13:29: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 90353912EB for <[e-mail]>; Wed,  2 Oct 2002 13:29:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6FFC45DDD5; Wed,  2 Oct 2002 13:29: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 301625DDD4 for <[e-mail]>; Wed,  2 Oct 2002 13:29:35 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12R7S>; Wed, 2 Oct 2002 13:29:34 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Active Route -- OT
Date: Wed, 2 Oct 2002 13:29:34 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

"Synchronise implies that the BGP next_hop is reachable via the IGP
*not* the BGP prefix itself."

Wrong. Synchronized (Cisco Term) implies that the route (set of
destinations) has been learned via an IGP (including connected and direct).
IBGP learned routes must be synchronized to be advertised via EBGP, Post
12.0(6???) added that un-synchronized routes may not be used for local
forwarding. Synch can be config'd off.

NEXT_HOP must always be resolvable, no way to config this off.


-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 12:33 PM
To: [e-mail]
Cc: BGP mailing list
Subject: Re: Active Route 


In message <[e-mail]>, [e-mail]
writ
es:
> 
> Then I redistribute the routes into IGP, and at the same time I forward
> the routes via IBGP (not full mesh) to all of the other AS border routers
(bu
> t
> to no other routers).

This is an incredibly bad idea.  Only the BGP next_hop needs to be in
the IGP.

> At the other side of my AS, I allow the border router (router B) to pass
thos
> e
> routes learned via IBGP (form router A) to the (next) AS via an EBGP
connecti
> on.
> (I am using the  "synchronise BGP = TRUE" option.)

Synchronise implies that the BGP next_hop is reachable via the IGP
*not* the BGP prefix itself.

There is never a need to put the destination prefix into the IGP if it
is carried in IBGP except for the case where you are originating a
prefix and you want it to go out with specific attributes such as
specific BGP communities or indicate through BGP communities some
special action such as punching a hole in an aggregate.

> Now in this fairly straightforward example, the router B will forward
routes
> learned via IBGP to the next AS using EBGP, whereas for those routes the
> reachability in the FIB is taken care of by IGP (who has typically a
higher
> preference in ther FIB then IBGP).
> 
> So, in theory the rule : "one must focus on the rule that a BGP speaker
> advertises to its peers  in neighboring ASs only those routes that it
itself
> uses." is broken, since it is clearly an IGP route which in the FIB.
> 
> ---
> Hans de Vleeschouwer

The only way to fully address all of the instances of this sort of
objection is to add to the spec "Most BGP implementations allow the
user to do things that violate the protocol specification in minor
ways, sometimes with valid uses, but also sometimes with questionalble
uses and sometimes with dire consequences".  Although this statement
is true, I don't don't think we need to add this.

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 NAA29424 for <[e-mail]>; Wed, 2 Oct 2002 13:24:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BCBBF912E8; Wed,  2 Oct 2002 13:24:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85FBE912EB; Wed,  2 Oct 2002 13: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 37503912E8 for <[e-mail]>; Wed,  2 Oct 2002 13:24:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 1BEDE5DDD3; Wed,  2 Oct 2002 13:24: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 3EBAE5DD8E for <[e-mail]>; Wed,  2 Oct 2002 13:24: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 NAA64679; Wed, 2 Oct 2002 13:23:51 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Justin Fletcher <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: issue 8 
In-reply-to: Your message of "02 Oct 2002 08:56:17 PDT." <1033574178.27465.34.camel@riga> 
Date: Wed, 02 Oct 2002 13:23:51 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <1033574178.27465.34.camel@riga>, Justin Fletcher writes:
> >    The amount of jitter to be introduced shall be determined by
> >    multiplying the base value of the appropriate timer by a random
> >    factor which is uniformly distributed in the range from 0.75 to
> >    1.0.
> 
> I'd suggest "uniformly distributed in the range from 0.75 to 1.25"
> to ensure the average is the configured interval.
> 
> Justin Fletcher


This is just a suggested default value and an implementor is free to
use another such as .75 to 1.25 (and it would be a good idea to
document it clearly).  Some conformance freak might take this as
gospel and also check the uniformness of the random distribution but
that too is a recommended default and selection from some other
distribution (tail truncated) would still be compliant.  Someone might
pick .75 to 1.25 if preserving the mean value seemed more appealing
and someone else might use another distribution if it saved a few CPU
cycles and both would be OK.

Briefly - it doesn't matter.

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 NAA29212 for <[e-mail]>; Wed, 2 Oct 2002 13:20:09 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0EC5891223; Wed,  2 Oct 2002 13:19:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id CEB7B912E8; Wed,  2 Oct 2002 13:19: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 796E291223 for <[e-mail]>; Wed,  2 Oct 2002 13:19:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 61C5E5DDD1; Wed,  2 Oct 2002 13:19: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 A460E5DD8E for <[e-mail]>; Wed,  2 Oct 2002 13:19:44 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12R56>; Wed, 2 Oct 2002 13:19:43 -0400
Message-ID: <[e-mail]>
From: "Gray, Eric" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 62
Date: Wed, 2 Oct 2002 13:19:41 -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 assume you meant "If there are _no_ objections ..."

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


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, October 02, 2002 12:24 PM
> To: [e-mail]
> Subject: issue 62
> 
> Folks,
> 
>   62) Deprecate BGP Authentication Optional Parameter from RFC1771
>   ------------------------------------------------------------------------
> ----
>   Status: No Consensus
>   Change: Potentially
>   Summary: We are at consensus, in that we agree that we should deprecate
>    the BGP Authentication Optional Parameter as described in RFC1771 in
>    favor of the mechanism described in RFC2385.  We do not have new text
> for
>    the draft yet, of if we are going to pull the reference entirely.
> 
> I would suggest to remove the following text from the draft:
> 
>          This document defines the following Optional Parameters:
> 
>          a) Authentication Information (Parameter Type 1):
> 
> 
>             This optional parameter may be used to authenticate a BGP
>             peer. The Parameter Value field contains a 1-octet
>             Authentication Code followed by a variable length
>             Authentication Data.
> 
>                 0 1 2 3 4 5 6 7 8
>                 +-+-+-+-+-+-+-+-+
>                 |  Auth. Code   |
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                 |                                                     |
>                 |              Authentication Data                    |
>                 |                                                     |
>                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>                Authentication Code:
> 
>                   This 1-octet unsigned integer indicates the
>                   authentication mechanism being used. Whenever an
>                   authentication mechanism is specified for use within
>                   BGP, three things must be included in the
>                   specification:
> 
>                   - the value of the Authentication Code which indicates
>                   use of the mechanism,
>                   - the form and meaning of the Authentication Data, and
>                   - the algorithm for computing values of Marker fields.
> 
>                   Note that a separate authentication mechanism may be
>                   used in establishing the transport level connection.
> 
>                Authentication Data:
> 
>                   Authentication Data is a variable length field that is
>                   interpreted according to the value of the
>                   Authentication Code field.
> 
> If there are objections to this, then I would add the following:
> 
>    This document deprecates the use of the Authentication Information
>    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 NAA29088 for <[e-mail]>; Wed, 2 Oct 2002 13:17:16 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 20DAE912EC; Wed,  2 Oct 2002 13:16:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5EC3912EB; Wed,  2 Oct 2002 13:16: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 67827912E8 for <[e-mail]>; Wed,  2 Oct 2002 13:16:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 49E0E5DDCE; Wed,  2 Oct 2002 13:16: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 9EA7D5DD8E for <[e-mail]>; Wed,  2 Oct 2002 13:16:19 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12R5N>; Wed, 2 Oct 2002 13:16:18 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 62
Date: Wed, 2 Oct 2002 13:16:18 -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, October 02, 2002 12:24 PM
To: [e-mail]
Subject: issue 62

Folks,

  62) Deprecate BGP Authentication Optional Parameter from RFC1771
 
----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: We are at consensus, in that we agree that we should deprecate
   the BGP Authentication Optional Parameter as described in RFC1771 in
   favor of the mechanism described in RFC2385.  We do not have new text for
   the draft yet, of if we are going to pull the reference entirely.

I would suggest to remove the following text from the draft:

         This document defines the following Optional Parameters:

         a) Authentication Information (Parameter Type 1):


            This optional parameter may be used to authenticate a BGP
            peer. The Parameter Value field contains a 1-octet
            Authentication Code followed by a variable length
            Authentication Data.

                0 1 2 3 4 5 6 7 8
                +-+-+-+-+-+-+-+-+
                |  Auth. Code   |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |                                                     |
                |              Authentication Data                    |
                |                                                     |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Authentication Code:

                  This 1-octet unsigned integer indicates the
                  authentication mechanism being used. Whenever an
                  authentication mechanism is specified for use within
                  BGP, three things must be included in the
                  specification:

                  - the value of the Authentication Code which indicates
                  use of the mechanism,
                  - the form and meaning of the Authentication Data, and
                  - the algorithm for computing values of Marker fields.

                  Note that a separate authentication mechanism may be
                  used in establishing the transport level connection.

               Authentication Data:

                  Authentication Data is a variable length field that is
                  interpreted according to the value of the
                  Authentication Code field.

If there are objections to this, then I would add the following:

   This document deprecates the use of the Authentication Information
   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 NAA28931 for <[e-mail]>; Wed, 2 Oct 2002 13:14:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 07D1B912E6; Wed,  2 Oct 2002 13:13:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C74CF912E8; Wed,  2 Oct 2002 13:13: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 51FF8912E6 for <[e-mail]>; Wed,  2 Oct 2002 13:13:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3F0005DDCE; Wed,  2 Oct 2002 13:13:31 -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 0F0935DDC4 for <[e-mail]>; Wed,  2 Oct 2002 13:13: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 NAA64645; Wed, 2 Oct 2002 13:12:57 -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 8 
In-reply-to: Your message of "Wed, 02 Oct 2002 08:49:34 PDT." <[e-mail]> 
Date: Wed, 02 Oct 2002 13:12:57 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Yakov Rekhter writes
:
> Folks,
> 
> I'd like to propose the following text for "BGP Timers" section:
> 
>    BGP employs five timers: ConnectRetry (see Section 8), Hold Time
>    (see Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval
>    (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
>    Section 9.2.1.1).
> 
>    The suggested value for the ConnectRetry timer is 120 seconds.
> 
>    The suggested value for the Hold Time is 90 seconds.
> 
>    The suggested value for the KeepAlive timer is 1/3 of the Hold
>    Time.
> 
>    The suggested value for the MinASOriginationInterval is 15
>    seconds.
> 
>    The suggested value for the MinRouteAdvertisementInterval is 30
>    seconds.
> 
>    An implementation of BGP MUST allow the Hold Time timer to be
>    configurable, and MAY allow the other timers to be configurable.
> 
>    To minimize the likelihood that the distribution of BGP messages
>    by a given BGP speaker will contain peaks, jitter should be
>    applied to the timers associated with MinASOriginationInterval,
>    Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
>    given BGP speaker shall apply the same jitter to each of these
>    quantities regardless of the destinations to which the updates
>    are being sent; that is, jitter will not be applied on a "per
>    peer" basis.
> 
> Any objections ?

minor improvement (not really an objection) --
   s/suggested value/suggested default value/g

Also

  s/shall apply the same jitter/may apply the same jitter/
   (to each of these quantities regardless of ...).

  s/jitter will not be applied/jitter need not be configured/
    (on a "per peer" basis).

We allow both timers and jitter to be configured with fine granularity
(per peer for BGP, down to per LSP for MPLS, with a reasonable
inheritance heirarchy to allow a change in system defaults or at the
peer group level, etc).  I think others do as well but maybe not with
quite the same flexibility.  This seems to be forbidding configurable
jitter using lower case normative (whatever difference that makes).

> Yakov.
> 
>    The amount of jitter to be introduced shall be determined by
>    multiplying the base value of the appropriate timer by a random
>    factor which is uniformly distributed in the range from 0.75 to
>    1.0.

I'd like to change that last paragraph:

   The suggested default amount of jitter shall be determined by
   multiplying the base value of the appropriate timer by a random
   factor which is uniformly distributed in the range from 0.75 to
   1.0.  A new random value should be picked each time the timer is
   set.  The range of the jitter random value MAY be configurable.

We *do* allow all timers to be configured and allow absolute values or
relative values (a percentage of the base value).  We also add the
jitter to most timers (at least the MPLS ones) rather than make them
smaller but that is a minor difference.

[and you *can* really make a mess of things by configuring timers
badly - but this is consistent with the "more rope please" customer
requirement that we are all familiar with. :) ]

Curtis

ps - I hope this does not reopen the debate on timer verbs over what
it means to "set" a timer.


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA28535 for <[e-mail]>; Wed, 2 Oct 2002 13:06:58 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7AB73912E5; Wed,  2 Oct 2002 13:06:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47FB5912EB; Wed,  2 Oct 2002 13:06: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 74C1A912E5 for <[e-mail]>; Wed,  2 Oct 2002 13:06:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5E11B5DDC4; Wed,  2 Oct 2002 13:06: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 0A3C55DD8E for <[e-mail]>; Wed,  2 Oct 2002 13:06:32 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12RZH>; Wed, 2 Oct 2002 13:06:31 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: Active Route
Date: Wed, 2 Oct 2002 13:06:30 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Ben,
No, the existing text (it was not Mike's suggestion) is fine.

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 12:16 PM
To: 'Michael C. Cambria'; [e-mail]
Subject: RE: Active Route

Michael:

Below

> -----Original Message-----
> From: Michael C. Cambria [mailto:[e-mail]]
> Sent: Wednesday, October 02, 2002 11:49 AM
> To: [e-mail]
> Subject: Re: Active Route
> 
> 
> 
> 
> Natale, Jonathan wrote:
> > Christian,
> > 
> > Thank you for replying.
> > 
> > Your change would not cover the case, for example, where the speaker
> > uses a static route that is not redistributed into bgp to reach
> > a set of destinations that is also learned via bgp.
> > 
> > I was thinking of:
> > "one must focus on the rule that a BGP speaker advertises to 
> > its peers only routes whose set of destinations
> > are reachable per the local Routing Table."
> 
> Would changing Martin's text:
> 
>  > "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 learned via BGP that it
>  > itself uses.  "Learned via BGP" means that a router's best path
>  > to a prefix is one that was either learned from a BGP peer, or
>  > deliberately injected into BGP by the local router."
> 
> to the text below work (removing the "best path" reference)?
> 
> "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 learned via BGP that it
> itself uses.  "Learned via BGP" means that the route to be
> advertised is one that was either learned from a BGP peer, or
> deliberately injected into BGP by the local router."
> 
> 
> This calls out that a speaker can't advertise a route to
> neighboring ASs that are not known to BGP.  Yet it does not 
> preclude a 
> route known to BGP from being advertised that has either the 
> destinaiton 
> or the NEXT_HOP (or both) reachable in the routing table via an IGP 
> route (e.g. due to admin distance) as required by 9.1.3:
> 
> "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."
> 
> 
I would like to slightly rephrase your suggestion:

 "A route shall not be installed in the Adj-Rib-Out unless this 
  route or a similar route (i.e. IGP route) sharing the same prefix and   
  NEXT_HOP address, is present and used for forwarding in the Routing Table.
 
Ben

> fire away :-)
> 
> MikeC
> 
> 
> > 
> > -----Original Message-----
> > From: Martin, Christian [mailto:[e-mail]] 
> > Sent: Wednesday, October 02, 2002 10:28 AM
> > To: 'Natale, Jonathan'; [e-mail]
> > Subject: RE: Active Route
> > 
> > Jonathan,
> > 
> > 
> >>"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 means that if the speaker's routing table has a non-bgp 
> >>route to a destination but does not have bgp route to the same 
> >>destination (for example, based on administrative distance), 
> >>then the speaker may not advertise that route to it's peers. 
> >>This is true on Juniper by default for EBGP, but is NOT TRUE 
> >>[ever?] on Juniper for IBGP, and is NOT TRUE on Juniper if ~= 
> >>"advertise inactive" is enabled.  This is NOT TRUE ever on Cisco.
> >>
> >>Now we are proposing that the quoted clause above be 
> >>completely removed. This means that it will be allowable to 
> >>advertise a route to a destination that is not locally 
> >>reachable.  This is obviously (to me, but not to all-- which 
> >>is why it should not be removed) bad. 
> > 
> > 
> > This, IMO, is not the spirit of the rule.  Juniper 
> interpreted the spec
> > differently.  As I see it, if the route is in the routing 
> table, you can
> > announce it.  To be more specific, and to your point 
> Jonathan, we should say
> > this - or say the converse:
> > 
> > "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 learned via BGP that it 
> > itself uses.  "Learned via BGP" means that a router's best path
> > to a prefix is one that was either learned from a BGP peer, or
> > deliberately injected into BGP by the local router."
> > 
> > Regards,
> > -chris
> > 
> > 
> > 
> > 
> > 
> >>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 NAA28508 for <[e-mail]>; Wed, 2 Oct 2002 13:06:30 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0BE87912E9; Wed,  2 Oct 2002 13:03:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5326912E5; Wed,  2 Oct 2002 13:03: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 49E44912E9 for <[e-mail]>; Wed,  2 Oct 2002 13:03:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 310175DDC4; Wed,  2 Oct 2002 13:03: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 E86DA5DDB7 for <[e-mail]>; Wed,  2 Oct 2002 13:03:38 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12RYP>; Wed, 2 Oct 2002 13:03:38 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 24 - consensus
Date: Wed, 2 Oct 2002 13:03:38 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

ok

-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 12:12 PM
To: [e-mail]
Subject: issue 24 - consensus

Folks,

I think we have consensus on this issue - add the
following text to 3.1

   Changing the attributes 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 NAA28214 for <[e-mail]>; Wed, 2 Oct 2002 13:00:14 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 12358912E3; Wed,  2 Oct 2002 12:59:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5B2F912E4; Wed,  2 Oct 2002 12:59: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 5C9E8912E3 for <[e-mail]>; Wed,  2 Oct 2002 12:59:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3F2A75DDD0; Wed,  2 Oct 2002 12:59: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 F12085DDC9 for <[e-mail]>; Wed,  2 Oct 2002 12:59:49 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12RX4>; Wed, 2 Oct 2002 12:59:49 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: RE: route to null0 
Date: Wed, 2 Oct 2002 12:59: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, I missed it, sorry. I still think it would be nice to add it in the
aggregation section:

Please change:

"Route aggregation and information reduction techniques
(see 9.2.2.1) may optionally be applied."

to:

"Route aggregation and information reduction techniques
(see 9.2.2.1) may optionally be applied."


-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 11:59 AM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: route to null0 

Jonathan,

> Yakov,
> 
> Thanks!
> 
> "A routing domain which performs summarization of multiple routes
> must discard packets which match the summarization but do not match any
> of the explicit routes which makes up the summarization."
> 
> That covers it.  
> 
> I think adding a "[8]" (currently "[8]" is not explicitly cited anywhere)
in
> a strategic spot would be a good idea; I have seen this point missed by
> some.

It is cited in Introduction:

  BGP-4 provides a new set of mechanisms for supporting Classless
  Inter-Domain Routing (CIDR) [8, 9]. 

Yakov.
> 
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Wednesday, October 02, 2002 11:27 AM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: route to null0 
> 
> Jonathan,
> 
> > If a speaker aggregates a route, a route to the aggregated set of
> > destinations with a next-hop of null is installed in the speaker's
routing
> > table.  This is done to avoid a routing loop in the event that: one of
the
> > more specific routes goes away, the peer (that the aggregate was
> advertised
> > to) advertised the default route, and the peer (that the aggregate was
> sent
> > to) sends a pkt to the speaker destined for the more specific route that
> > went away.
> > 
> > I think the current draft stipulates that this should be handled by the
> > speaker withdrawing the more specific route and/or de-aggregating or
> > something; there is no mention of the current working code's "null
> solution"
> > (as described above).
> 
> See Section 4.2 RFC1519.
> 
> Yakov.
> 
> > 
> >  
> > 
> > Not sure what Juniper does on this one (use 127.x.x.x vs null0 ???).
> > 
> > 
> > ------_=_NextPart_001_01C26A25.CBF1A260
> > 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";}
> > h1
> > 	{margin-top:0in;
> > 	margin-right:0in;
> > 	margin-bottom:0in;
> > 	margin-left:.5in;
> > 	margin-bottom:.0001pt;
> > 	text-indent:-.25in;
> > 	page-break-after:avoid;
> > 	font-size:16.0pt;
> > 	font-family:"Times New Roman";}
> > h2
> > 	{margin-top:0in;
> > 	margin-right:0in;
> > 	margin-bottom:0in;
> > 	margin-left:.8in;
> > 	margin-bottom:.0001pt;
> > 	text-indent:-.3in;
> > 	page-break-after:avoid;
> > 	font-size:12.0pt;
> > 	font-family:Arial;}
> > a:link, span.MsoHyperlink
> > 	{color:blue;
> > 	text-decoration:underline;}
> > a:visited, span.MsoHyperlinkFollowed
> > 	{color:purple;
> > 	text-decoration:underline;}
> > p.StyleHeading1Arial12ptLeft, li.StyleHeading1Arial12ptLeft,
> div.StyleHeading
> 1Arial12ptLeft
> > 	{margin-top:0in;
> > 	margin-right:0in;
> > 	margin-bottom:0in;
> > 	margin-left:.5in;
> > 	margin-bottom:.0001pt;
> > 	text-indent:-.25in;
> > 	page-break-after:avoid;
> > 	font-size:12.0pt;
> > 	font-family:"Times New Roman";
> > 	font-weight:bold;}
> > p.StyleArial22ptBoldCentered, li.StyleArial22ptBoldCentered,
> div.StyleArial22
> ptBoldCentered
> > 	{margin:0in;
> > 	margin-bottom:.0001pt;
> > 	text-align:center;
> > 	font-size:20.0pt;
> > 	font-family:Arial;
> > 	font-weight:bold;}
> > span.EmailStyle19
> > 	{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;}
> >  /* List Definitions */
> >  ol
> > 	{margin-bottom:0in;}
> > ul
> > 	{margin-bottom:0in;}
> > -->
> > </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'>If a speaker aggregates a route, a route to the
> aggregated
> > set of destinations with a next-hop of null is installed in the
speaker's
> > routing table.&nbsp; This is done to avoid a routing loop in the event
> that: 
> one
> > of the more specific routes goes away, the peer (that the aggregate was
> > advertised to) advertised the default route, and the peer (that the
> aggregate
> > was sent to) sends a pkt to the speaker destined for the more specific
> route
> > that went away.</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'>I think the current draft stipulates that this should
> be
> > handled by the speaker withdrawing the more specific route and/or
> > de-aggregating or something; there is no mention of the current working
> code'
> s
> > "null solution" (as described above).</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'>Not sure what Juniper does on this one (use 127.x.x.x
> vs
> > null0 ???).</span></font></p>
> > 
> > </div>
> > 
> > </body>
> > 
> > </html>
> > 
> > ------_=_NextPart_001_01C26A25.CBF1A260--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA27287 for <[e-mail]>; Wed, 2 Oct 2002 12:41:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 65459912E2; Wed,  2 Oct 2002 12:41:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38A79912E3; Wed,  2 Oct 2002 12:41: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 14DDB912E2 for <[e-mail]>; Wed,  2 Oct 2002 12:41:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 03C2F5DDC3; Wed,  2 Oct 2002 12:41:21 -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 84C315DD8E for <[e-mail]>; Wed,  2 Oct 2002 12:41: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 MAA14941; Wed, 2 Oct 2002 12:41: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 MAA14207; Wed, 2 Oct 2002 12:41:19 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7PFYS>; Wed, 2 Oct 2002 12:41:17 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Cc: BGP mailing list <[e-mail]>
Subject: RE: Active Route 
Date: Wed, 2 Oct 2002 12:41: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

Curtis

> -----Original Message-----
> From: Curtis Villamizar [mailto:[e-mail]]
> Sent: Wednesday, October 02, 2002 12:33 PM
> To: [e-mail]
> Cc: BGP mailing list
> Subject: Re: Active Route 
> 
> 
> 
> In message <[e-mail]>, 
> [e-mail] writ
> es:
> > 
> > Then I redistribute the routes into IGP, and at the same 
> time I forward
> > the routes via IBGP (not full mesh) to all of the other AS 
> border routers (bu
> > t
> > to no other routers).
> 
> This is an incredibly bad idea.  Only the BGP next_hop needs to be in
> the IGP.
> 
> > At the other side of my AS, I allow the border router 
> (router B) to pass thos
> > e
> > routes learned via IBGP (form router A) to the (next) AS 
> via an EBGP connecti
> > on.
> > (I am using the  "synchronise BGP = TRUE" option.)
> 
> Synchronise implies that the BGP next_hop is reachable via the IGP
> *not* the BGP prefix itself.
> 
> There is never a need to put the destination prefix into the IGP if it
> is carried in IBGP except for the case where you are originating a
> prefix and you want it to go out with specific attributes such as
> specific BGP communities or indicate through BGP communities some
> special action such as punching a hole in an aggregate.
> 

What if your AS is not fully meshed as Hans pointed out? 

The only way to get external BGP routes to non-BGP (IGP only) routers is by
redistributing them via IGP, and let IGP flood them, right?


> > Now in this fairly straightforward example, the router B 
> will forward routes
> > learned via IBGP to the next AS using EBGP, whereas for 
> those routes the
> > reachability in the FIB is taken care of by IGP (who has 
> typically a higher
> > preference in ther FIB then IBGP).
> > 
> > So, in theory the rule : "one must focus on the rule that a 
> BGP speaker
> > advertises to its peers  in neighboring ASs only those 
> routes that it itself
> > uses." is broken, since it is clearly an IGP route which in the FIB.
> > 
> > ---
> > Hans de Vleeschouwer
> 
> The only way to fully address all of the instances of this sort of
> objection is to add to the spec "Most BGP implementations allow the
> user to do things that violate the protocol specification in minor
> ways, sometimes with valid uses, but also sometimes with questionalble
> uses and sometimes with dire consequences".  Although this statement
> is true, I don't don't think we need to add this.
> 
This although is sometimes true, is bordering on being rediculous for a 
spec. I agree, you do not want to add this or the reader will stop reading
the spec.

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 MAA27158 for <[e-mail]>; Wed, 2 Oct 2002 12:39:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 71D5B912E1; Wed,  2 Oct 2002 12:39:18 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F297912E2; Wed,  2 Oct 2002 12:39: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 1F27F912E1 for <[e-mail]>; Wed,  2 Oct 2002 12:39:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id EB38B5DDC3; Wed,  2 Oct 2002 12:39:16 -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 A0E565DDB7 for <[e-mail]>; Wed,  2 Oct 2002 12:39:16 -0400 (EDT)
Received: from riga ([10.0.0.25]) by earthquake.proficient.net with Microsoft SMTPSVC(5.0.2195.4905); Wed, 2 Oct 2002 09:39:15 -0700
Subject: RE: issue 8
From: Justin Fletcher <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: Yakov Rekhter <[e-mail]>, [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: 02 Oct 2002 09:38:26 -0700
Message-Id: <1033576707.2302.5.camel@riga>
Mime-Version: 1.0
X-OriginalArrivalTime: 02 Oct 2002 16:39:15.0272 (UTC) FILETIME=[3EB47C80:01C26A32]
Sender: [e-mail]
Precedence: bulk

On Wed, 2002-10-02 at 09:27, Natale, Jonathan wrote:
> I disagree, that would not reflect current implementations.  We are not
> changing BGP, merely clarifying it.

Yes, you're correct, and would also indicate a change from RFC1771;
Yakov, consider the comment withdrawn.

The proposed timer text is very clear.

jf
 
> -----Original Message-----
> From: Justin Fletcher [mailto:[e-mail]] 
> Sent: Wednesday, October 02, 2002 11:56 AM
> To: Yakov Rekhter
> Cc: [e-mail]
> Subject: Re: issue 8
> 
> >    The amount of jitter to be introduced shall be determined by
> >    multiplying the base value of the appropriate timer by a random
> >    factor which is uniformly distributed in the range from 0.75 to
> >    1.0.
> 
> I'd suggest "uniformly distributed in the range from 0.75 to 1.25"
> to ensure the average is the configured interval.
> 
> 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 MAA26972 for <[e-mail]>; Wed, 2 Oct 2002 12:33:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5E75E912DF; Wed,  2 Oct 2002 12:33:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2FE09912E1; Wed,  2 Oct 2002 12:33: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 D195E912DF for <[e-mail]>; Wed,  2 Oct 2002 12:33:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D5C845DDB7; Wed,  2 Oct 2002 12:33: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 177075DD8E for <[e-mail]>; Wed,  2 Oct 2002 12:33: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 MAA64531; Wed, 2 Oct 2002 12:32:40 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: BGP mailing list <[e-mail]>
Reply-To: [e-mail]
Subject: Re: Active Route 
In-reply-to: Your message of "Wed, 02 Oct 2002 17:24:56 +0200." <[e-mail]> 
Date: Wed, 02 Oct 2002 12:32:40 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, [e-mail] writ
es:
> 
> Then I redistribute the routes into IGP, and at the same time I forward
> the routes via IBGP (not full mesh) to all of the other AS border routers (bu
> t
> to no other routers).

This is an incredibly bad idea.  Only the BGP next_hop needs to be in
the IGP.

> At the other side of my AS, I allow the border router (router B) to pass thos
> e
> routes learned via IBGP (form router A) to the (next) AS via an EBGP connecti
> on.
> (I am using the  "synchronise BGP = TRUE" option.)

Synchronise implies that the BGP next_hop is reachable via the IGP
*not* the BGP prefix itself.

There is never a need to put the destination prefix into the IGP if it
is carried in IBGP except for the case where you are originating a
prefix and you want it to go out with specific attributes such as
specific BGP communities or indicate through BGP communities some
special action such as punching a hole in an aggregate.

> Now in this fairly straightforward example, the router B will forward routes
> learned via IBGP to the next AS using EBGP, whereas for those routes the
> reachability in the FIB is taken care of by IGP (who has typically a higher
> preference in ther FIB then IBGP).
> 
> So, in theory the rule : "one must focus on the rule that a BGP speaker
> advertises to its peers  in neighboring ASs only those routes that it itself
> uses." is broken, since it is clearly an IGP route which in the FIB.
> 
> ---
> Hans de Vleeschouwer

The only way to fully address all of the instances of this sort of
objection is to add to the spec "Most BGP implementations allow the
user to do things that violate the protocol specification in minor
ways, sometimes with valid uses, but also sometimes with questionalble
uses and sometimes with dire consequences".  Although this statement
is true, I don't don't think we need to add this.

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 MAA26786 for <[e-mail]>; Wed, 2 Oct 2002 12:27:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CA463912DE; Wed,  2 Oct 2002 12:27:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99A1C912DF; Wed,  2 Oct 2002 12:27: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 59236912DE for <[e-mail]>; Wed,  2 Oct 2002 12:27:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4720E5DDAA; Wed,  2 Oct 2002 12:27: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 F29F95DD8E for <[e-mail]>; Wed,  2 Oct 2002 12:27:02 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12RTB>; Wed, 2 Oct 2002 12:27:02 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Justin Fletcher'" <[e-mail]>, Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 8
Date: Wed, 2 Oct 2002 12:27: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 disagree, that would not reflect current implementations.  We are not
changing BGP, merely clarifying it.

-----Original Message-----
From: Justin Fletcher [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 11:56 AM
To: Yakov Rekhter
Cc: [e-mail]
Subject: Re: issue 8

>    The amount of jitter to be introduced shall be determined by
>    multiplying the base value of the appropriate timer by a random
>    factor which is uniformly distributed in the range from 0.75 to
>    1.0.

I'd suggest "uniformly distributed in the range from 0.75 to 1.25"
to ensure the average is the configured interval.

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 MAA26600 for <[e-mail]>; Wed, 2 Oct 2002 12:24:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 95108912DD; Wed,  2 Oct 2002 12:23:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 625FC912DE; Wed,  2 Oct 2002 12:23: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 2A07A912DD for <[e-mail]>; Wed,  2 Oct 2002 12:23:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E95635DDAA; Wed,  2 Oct 2002 12:23: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 550335DD8E for <[e-mail]>; Wed,  2 Oct 2002 12:23: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 g92GNtm47128 for <[e-mail]>; Wed, 2 Oct 2002 09:23:55 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 02 Oct 2002 09:23:55 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

  62) Deprecate BGP Authentication Optional Parameter from RFC1771
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: We are at consensus, in that we agree that we should deprecate
   the BGP Authentication Optional Parameter as described in RFC1771 in
   favor of the mechanism described in RFC2385.  We do not have new text for
   the draft yet, of if we are going to pull the reference entirely.

I would suggest to remove the following text from the draft:

         This document defines the following Optional Parameters:

         a) Authentication Information (Parameter Type 1):


            This optional parameter may be used to authenticate a BGP
            peer. The Parameter Value field contains a 1-octet
            Authentication Code followed by a variable length
            Authentication Data.

                0 1 2 3 4 5 6 7 8
                +-+-+-+-+-+-+-+-+
                |  Auth. Code   |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |                                                     |
                |              Authentication Data                    |
                |                                                     |
                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


               Authentication Code:

                  This 1-octet unsigned integer indicates the
                  authentication mechanism being used. Whenever an
                  authentication mechanism is specified for use within
                  BGP, three things must be included in the
                  specification:

                  - the value of the Authentication Code which indicates
                  use of the mechanism,
                  - the form and meaning of the Authentication Data, and
                  - the algorithm for computing values of Marker fields.

                  Note that a separate authentication mechanism may be
                  used in establishing the transport level connection.

               Authentication Data:

                  Authentication Data is a variable length field that is
                  interpreted according to the value of the
                  Authentication Code field.

If there are objections to this, then I would add the following:

   This document deprecates the use of the Authentication Information
   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 MAA26500 for <[e-mail]>; Wed, 2 Oct 2002 12:22:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8A936912DC; Wed,  2 Oct 2002 12:21:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55E06912DD; Wed,  2 Oct 2002 12: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 0114A912DC for <[e-mail]>; Wed,  2 Oct 2002 12:21:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CA8365DDAA; Wed,  2 Oct 2002 12:21: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 B03265DD8E for <[e-mail]>; Wed,  2 Oct 2002 12:21: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 MAA64483; Wed, 2 Oct 2002 12:21:09 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Reply-To: [e-mail]
Subject: Re: route to null0 
In-reply-to: Your message of "Wed, 02 Oct 2002 11:10:08 EDT." <[e-mail]> 
Date: Wed, 02 Oct 2002 12:21:09 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> 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_01C26A25.CBF1A260
> Content-Type: text/plain
> 
> If a speaker aggregates a route, a route to the aggregated set of
> destinations with a next-hop of null is installed in the speaker's routing
> table.  This is done to avoid a routing loop in the event that: one of the
> more specific routes goes away, the peer (that the aggregate was advertised
> to) advertised the default route, and the peer (that the aggregate was sent
> to) sends a pkt to the speaker destined for the more specific route that
> went away.

This is specific to one implementation (and similar in others).  A
data structure is needed to represent the aggregate and the route data
structure is one that is clearly visible (in "show" commands) and
understood by the user to be an internally generated aggregate.

Avoiding the route loop with a less specific aggregate that overlaps
the aggreagate that was formed is another good reason to use a route
data structure.  The effect is to black hole the destinations for
which there are no more specific routes rather than loop.

> I think the current draft stipulates that this should be handled by the
> speaker withdrawing the more specific route and/or de-aggregating or
> something; there is no mention of the current working code's "null solution"
> (as described above).

There is no need to reflect one vendor's implementation details.  It
has no affect on the spec.  If a different data structure is used and
it doesn't appear in the "show ip route" or equivalent but is listed
by a separate command that's fine with the BGP spec.  If it also can
transform a loop into a black hole, all the better.

It would seem obvious enough that if the component routes go away, the
aggregate must be deleted.  It is also obvious enough that if you
advertised the component routes (not doing a summary aggregate) that
you still need to withdraw them if they go away.  It also seems
obvious enough that if the set of components change, the AS-SET, if
used, has to be updated if it has changed.  This is one reason why no
one uses AS-SETs anymore, preferring ATOMIC_AGGREGATE.

In no case can you advertise something and forget about it, not
withdrawing the route if it is no longer valid.  We don't need to
explicitly state that this also holds true for aggregates.

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 MAA26193 for <[e-mail]>; Wed, 2 Oct 2002 12:16:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D9F44912DB; Wed,  2 Oct 2002 12:16:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A70C7912DC; Wed,  2 Oct 2002 12:16: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 DD141912DB for <[e-mail]>; Wed,  2 Oct 2002 12:16:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C6CEE5DDAA; Wed,  2 Oct 2002 12:16: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 4EE4C5DD8E for <[e-mail]>; Wed,  2 Oct 2002 12:16: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 MAA13869; Wed, 2 Oct 2002 12:16: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 MAA10309; Wed, 2 Oct 2002 12:16:19 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7P1X7>; Wed, 2 Oct 2002 12:16:17 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Michael C. Cambria'" <[e-mail]>, [e-mail]
Subject: RE: Active Route
Date: Wed, 2 Oct 2002 12:16: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

Michael:

Below

> -----Original Message-----
> From: Michael C. Cambria [mailto:[e-mail]]
> Sent: Wednesday, October 02, 2002 11:49 AM
> To: [e-mail]
> Subject: Re: Active Route
> 
> 
> 
> 
> Natale, Jonathan wrote:
> > Christian,
> > 
> > Thank you for replying.
> > 
> > Your change would not cover the case, for example, where the speaker
> > uses a static route that is not redistributed into bgp to reach
> > a set of destinations that is also learned via bgp.
> > 
> > I was thinking of:
> > "one must focus on the rule that a BGP speaker advertises to 
> > its peers only routes whose set of destinations
> > are reachable per the local Routing Table."
> 
> Would changing Martin's text:
> 
>  > "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 learned via BGP that it
>  > itself uses.  "Learned via BGP" means that a router's best path
>  > to a prefix is one that was either learned from a BGP peer, or
>  > deliberately injected into BGP by the local router."
> 
> to the text below work (removing the "best path" reference)?
> 
> "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 learned via BGP that it
> itself uses.  "Learned via BGP" means that the route to be
> advertised is one that was either learned from a BGP peer, or
> deliberately injected into BGP by the local router."
> 
> 
> This calls out that a speaker can't advertise a route to
> neighboring ASs that are not known to BGP.  Yet it does not 
> preclude a 
> route known to BGP from being advertised that has either the 
> destinaiton 
> or the NEXT_HOP (or both) reachable in the routing table via an IGP 
> route (e.g. due to admin distance) as required by 9.1.3:
> 
> "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."
> 
> 
I would like to slightly rephrase your suggestion:

 "A route shall not be installed in the Adj-Rib-Out unless this 
  route or a similar route (i.e. IGP route) sharing the same prefix and   
  NEXT_HOP address, is present and used for forwarding in the Routing Table.
 
Ben

> fire away :-)
> 
> MikeC
> 
> 
> > 
> > -----Original Message-----
> > From: Martin, Christian [mailto:[e-mail]] 
> > Sent: Wednesday, October 02, 2002 10:28 AM
> > To: 'Natale, Jonathan'; [e-mail]
> > Subject: RE: Active Route
> > 
> > Jonathan,
> > 
> > 
> >>"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 means that if the speaker's routing table has a non-bgp 
> >>route to a destination but does not have bgp route to the same 
> >>destination (for example, based on administrative distance), 
> >>then the speaker may not advertise that route to it's peers. 
> >>This is true on Juniper by default for EBGP, but is NOT TRUE 
> >>[ever?] on Juniper for IBGP, and is NOT TRUE on Juniper if ~= 
> >>"advertise inactive" is enabled.  This is NOT TRUE ever on Cisco.
> >>
> >>Now we are proposing that the quoted clause above be 
> >>completely removed. This means that it will be allowable to 
> >>advertise a route to a destination that is not locally 
> >>reachable.  This is obviously (to me, but not to all-- which 
> >>is why it should not be removed) bad. 
> > 
> > 
> > This, IMO, is not the spirit of the rule.  Juniper 
> interpreted the spec
> > differently.  As I see it, if the route is in the routing 
> table, you can
> > announce it.  To be more specific, and to your point 
> Jonathan, we should say
> > this - or say the converse:
> > 
> > "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 learned via BGP that it 
> > itself uses.  "Learned via BGP" means that a router's best path
> > to a prefix is one that was either learned from a BGP peer, or
> > deliberately injected into BGP by the local router."
> > 
> > Regards,
> > -chris
> > 
> > 
> > 
> > 
> > 
> >>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 MAA26003 for <[e-mail]>; Wed, 2 Oct 2002 12:12:08 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id D65AA912D7; Wed,  2 Oct 2002 12:11:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B9EA912DB; Wed,  2 Oct 2002 12:11: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 736D5912D7 for <[e-mail]>; Wed,  2 Oct 2002 12:11:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5E0B15DDBE; Wed,  2 Oct 2002 12:11: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 C4E7F5DDAA for <[e-mail]>; Wed,  2 Oct 2002 12:11: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 g92GBhm46084 for <[e-mail]>; Wed, 2 Oct 2002 09:11:43 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: issue 24 - consensus
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 02 Oct 2002 09:11:43 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

I think we have consensus on this issue - add the
following text to 3.1

   Changing the attributes 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 MAA25823 for <[e-mail]>; Wed, 2 Oct 2002 12:09:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BAC9F912D6; Wed,  2 Oct 2002 12:09:22 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85DC6912D7; Wed,  2 Oct 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 22D0F912D6 for <[e-mail]>; Wed,  2 Oct 2002 12:09:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 0FD265DDC3; Wed,  2 Oct 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 C07535DDBE for <[e-mail]>; Wed,  2 Oct 2002 12:09:20 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12RRD>; Wed, 2 Oct 2002 12:09:20 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Michael C. Cambria'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Active Route
Date: Wed, 2 Oct 2002 12:09:19 -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:

""locally reachable"?  Do you mean BGP can't reach it (e.g. not
in Loc-RIB?)"

No, I mean that the router/speaker/switch/box can't reach it.  But you
bring up a good point--BGP must be able to reach it as well.  But I think
this is already covered by:

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

If you don't like "locally reachable", how about:
"installed in the routing table"
"in the local FIB"
...


-----Original Message-----
From: Michael C. Cambria [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 11:16 AM
To: Natale, Jonathan
Subject: Re: Active Route



Natale, Jonathan wrote:
> Folks,
> 
> This issue seems to have been convoluted into issue 32.2.  I am in
agreement
> with 32.2 (other than style/conciseness--I think it is a little long
winded,
> but I can live with it), but it is not what I raised.  
> 
> The issue I raised, and would like to be [re-]considered is with:
> 
> "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 agree.  This should remain and be clarified.

I want to make sure I fully understand you.  If I do, I have the same 
concern.

> This means that if the speaker's routing table has a non-bgp route to a
> destination but does not have bgp route to the same destination (for
> example, based on administrative distance), then the speaker may not
> advertise that route to it's peers. This is true on Juniper by default for
> EBGP, but is NOT TRUE [ever?] on Juniper for IBGP, and is NOT TRUE on
> Juniper if ~= "advertise inactive" is enabled.  This is NOT TRUE ever on
> Cisco.

I missed something.  I understood until your "for example, based on 
administrative distance" example.   Why would admin distance come up if 
there was no BGP route for the same destination as that of the IGP?

Crossing out your example, I read the above to say if we delete the 
quoted text from the draft as proposed, one could advertise an IGP route 
that has no corresponding destination in Loc-RIB.

Is this what you are saying?

> Now we are proposing that the quoted clause above be completely removed.
> This means that it will be allowable to advertise a route to a destination
> that is not locally reachable.  This is obviously (to me, but not to all--
> which is why it should not be removed) bad. 

"locally reachable"?  Do you mean BGP can't reach it (e.g. not in Loc-RIB?)


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 MAA25702 for <[e-mail]>; Wed, 2 Oct 2002 12:07:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 038C6912D2; Wed,  2 Oct 2002 12:07:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4CA9912D5; Wed,  2 Oct 2002 12:07: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 47A7C912D2 for <[e-mail]>; Wed,  2 Oct 2002 12:06:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 3253A5DDAA; Wed,  2 Oct 2002 12:06: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 914CD5DD8E for <[e-mail]>; Wed,  2 Oct 2002 12:06:58 -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 g92G4Xtq005607 for <[e-mail]>; Wed, 2 Oct 2002 12:04:34 -0400 (EDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 02 Oct 2002 11:49: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: Re: Active Route
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Natale, Jonathan wrote:
> Christian,
> 
> Thank you for replying.
> 
> Your change would not cover the case, for example, where the speaker
> uses a static route that is not redistributed into bgp to reach
> a set of destinations that is also learned via bgp.
> 
> I was thinking of:
> "one must focus on the rule that a BGP speaker advertises to 
> its peers only routes whose set of destinations
> are reachable per the local Routing Table."

Would changing Martin's text:

 > "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 learned via BGP that it
 > itself uses.  "Learned via BGP" means that a router's best path
 > to a prefix is one that was either learned from a BGP peer, or
 > deliberately injected into BGP by the local router."

to the text below work (removing the "best path" reference)?

"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 learned via BGP that it
itself uses.  "Learned via BGP" means that the route to be
advertised is one that was either learned from a BGP peer, or
deliberately injected into BGP by the local router."


This calls out that a speaker can't advertise a route to
neighboring ASs that are not known to BGP.  Yet it does not preclude a 
route known to BGP from being advertised that has either the destinaiton 
or the NEXT_HOP (or both) reachable in the routing table via an IGP 
route (e.g. due to admin distance) as required by 9.1.3:

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


fire away :-)

MikeC


> 
> -----Original Message-----
> From: Martin, Christian [mailto:[e-mail]] 
> Sent: Wednesday, October 02, 2002 10:28 AM
> To: 'Natale, Jonathan'; [e-mail]
> Subject: RE: Active Route
> 
> Jonathan,
> 
> 
>>"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 means that if the speaker's routing table has a non-bgp 
>>route to a destination but does not have bgp route to the same 
>>destination (for example, based on administrative distance), 
>>then the speaker may not advertise that route to it's peers. 
>>This is true on Juniper by default for EBGP, but is NOT TRUE 
>>[ever?] on Juniper for IBGP, and is NOT TRUE on Juniper if ~= 
>>"advertise inactive" is enabled.  This is NOT TRUE ever on Cisco.
>>
>>Now we are proposing that the quoted clause above be 
>>completely removed. This means that it will be allowable to 
>>advertise a route to a destination that is not locally 
>>reachable.  This is obviously (to me, but not to all-- which 
>>is why it should not be removed) bad. 
> 
> 
> This, IMO, is not the spirit of the rule.  Juniper interpreted the spec
> differently.  As I see it, if the route is in the routing table, you can
> announce it.  To be more specific, and to your point Jonathan, we should say
> this - or say the converse:
> 
> "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 learned via BGP that it 
> itself uses.  "Learned via BGP" means that a router's best path
> to a prefix is one that was either learned from a BGP peer, or
> deliberately injected into BGP by the local router."
> 
> Regards,
> -chris
> 
> 
> 
> 
> 
>>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 MAA25608 for <[e-mail]>; Wed, 2 Oct 2002 12:05:05 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 27260912CF; Wed,  2 Oct 2002 12:04:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2947912D2; Wed,  2 Oct 2002 12:04: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 DD3D6912CF for <[e-mail]>; Wed,  2 Oct 2002 12:04:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id CDDA85DDAA; Wed,  2 Oct 2002 12:04: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 59B575DD8E for <[e-mail]>; Wed,  2 Oct 2002 12:04: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 MAA13316; Wed, 2 Oct 2002 12:04: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 MAA08444; Wed, 2 Oct 2002 12:04:45 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7P12Y>; Wed, 2 Oct 2002 12:04:42 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 8
Date: Wed, 2 Oct 2002 12:04:43 -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 section does the job well. I like it. You have my vote.

Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Wednesday, October 02, 2002 11:50 AM
> To: [e-mail]
> Subject: issue 8
> 
> 
> Folks,
> 
> I'd like to propose the following text for "BGP Timers" section:
> 
>    BGP employs five timers: ConnectRetry (see Section 8), Hold Time
>    (see Section 4.2), KeepAlive (see Section 8), 
> MinASOriginationInterval
>    (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
>    Section 9.2.1.1).
> 
>    The suggested value for the ConnectRetry timer is 120 seconds.
> 
>    The suggested value for the Hold Time is 90 seconds.
> 
>    The suggested value for the KeepAlive timer is 1/3 of the Hold
>    Time.
> 
>    The suggested value for the MinASOriginationInterval is 15
>    seconds.
> 
>    The suggested value for the MinRouteAdvertisementInterval is 30
>    seconds.
> 
>    An implementation of BGP MUST allow the Hold Time timer to be
>    configurable, and MAY allow the other timers to be configurable.
> 
>    To minimize the likelihood that the distribution of BGP messages
>    by a given BGP speaker will contain peaks, jitter should be
>    applied to the timers associated with MinASOriginationInterval,
>    Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
>    given BGP speaker shall apply the same jitter to each of these
>    quantities regardless of the destinations to which the updates
>    are being sent; that is, jitter will not be applied on a "per
>    peer" basis.
> 
> Any objections ?
> 
> Yakov.
> 
>    The amount of jitter to be introduced shall be determined by
>    multiplying the base value of the appropriate timer by a random
>    factor which is uniformly distributed in the range from 0.75 to
>    1.0.
> 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA25545 for <[e-mail]>; Wed, 2 Oct 2002 12:03:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id BD565912CD; Wed,  2 Oct 2002 12:03:26 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76635912CF; Wed,  2 Oct 2002 12: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 BAF25912CD for <[e-mail]>; Wed,  2 Oct 2002 12:02:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 953025DDAA; Wed,  2 Oct 2002 12:02: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 9FF0D5DD8E for <[e-mail]>; Wed,  2 Oct 2002 12:02:58 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g92G2v218724; Wed, 2 Oct 2002 12:02: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 g92G2sG18716; Wed, 2 Oct 2002 12:02:54 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g92G2sM10801; Wed, 2 Oct 2002 12:02:54 -0400 (EDT)
Date: Wed, 2 Oct 2002 12:02:54 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: Complex AS Path Aggregating
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, Oct 02, 2002 at 11:40:30AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Oct 02, 2002 at 11:40:30AM -0400, Natale, Jonathan wrote:
> The fact is that nobody does it (if anyone does do this,
> please speak up), so I think is should be removed to reflect
> current working code.

This is one of those things that it doesn't hurt to leave it as is,
even if no one currently does it.  Someone *could* do it, and
it should still be legal to do.

> The test tested that the complex aggregation was done, it did not test
> that complex aggregation could received gracefully; this
> would be a useless test anyway, since no real world implementations do
> complex aggregation.

But if they did (and you could synthesize the packets easily enough),
it should be able to be received gracefully.

-- 
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 MAA25537 for <[e-mail]>; Wed, 2 Oct 2002 12:03:50 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 28827912CC; Wed,  2 Oct 2002 12:02:38 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E80A3912CD; Wed,  2 Oct 2002 12:02: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 4AF2C912CC for <[e-mail]>; Wed,  2 Oct 2002 12:02:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 327E85DDAA; Wed,  2 Oct 2002 12:02: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 9475A5DD8E for <[e-mail]>; Wed,  2 Oct 2002 12:02: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 g92G2Jm45390; Wed, 2 Oct 2002 09:02:19 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Justin Fletcher <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 8 
In-Reply-To: Your message of "02 Oct 2002 08:56:17 PDT." <1033574178.27465.34.camel@riga> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 02 Oct 2002 09:02:19 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Justin,

> >    The amount of jitter to be introduced shall be determined by
> >    multiplying the base value of the appropriate timer by a random
> >    factor which is uniformly distributed in the range from 0.75 to
> >    1.0.
> 
> I'd suggest "uniformly distributed in the range from 0.75 to 1.25"
> to ensure the average is the configured interval.

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 LAA25330 for <[e-mail]>; Wed, 2 Oct 2002 11:59:34 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7B25C912CE; Wed,  2 Oct 2002 11:59:25 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E7C6912CD; Wed,  2 Oct 2002 11:59: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 C3D31912CC for <[e-mail]>; Wed,  2 Oct 2002 11:59:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A94745DDAA; Wed,  2 Oct 2002 11:59:22 -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 E5B585DD8E for <[e-mail]>; Wed,  2 Oct 2002 11:59:21 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g92FxK718594; Wed, 2 Oct 2002 11:59:20 -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 g92FxFG18575; Wed, 2 Oct 2002 11:59:15 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g92FxF505649; Wed, 2 Oct 2002 11:59:15 -0400 (EDT)
Date: Wed, 2 Oct 2002 11:59:15 -0400
From: Jeffrey Haas <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 8
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, Oct 02, 2002 at 08:49:34AM -0700
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Oct 02, 2002 at 08:49:34AM -0700, Yakov Rekhter wrote:
> I'd like to propose the following text for "BGP Timers" section:

This seems like a very good idea.

-- 
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 LAA25319 for <[e-mail]>; Wed, 2 Oct 2002 11:59:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id C2C5C912CB; Wed,  2 Oct 2002 11:59:09 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92306912CC; Wed,  2 Oct 2002 11: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 27023912CB for <[e-mail]>; Wed,  2 Oct 2002 11:59:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 16F215DDAA; Wed,  2 Oct 2002 11: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 77A905DD8E for <[e-mail]>; Wed,  2 Oct 2002 11: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 g92Fx6m44946; Wed, 2 Oct 2002 08:59:06 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: route to null0 
In-Reply-To: Your message of "Wed, 02 Oct 2002 11:53:04 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 02 Oct 2002 08:59:06 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> Yakov,
> 
> Thanks!
> 
> "A routing domain which performs summarization of multiple routes
> must discard packets which match the summarization but do not match any
> of the explicit routes which makes up the summarization."
> 
> That covers it.  
> 
> I think adding a "[8]" (currently "[8]" is not explicitly cited anywhere) in
> a strategic spot would be a good idea; I have seen this point missed by
> some.

It is cited in Introduction:

  BGP-4 provides a new set of mechanisms for supporting Classless
  Inter-Domain Routing (CIDR) [8, 9]. 

Yakov.
> 
> 
> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Wednesday, October 02, 2002 11:27 AM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: route to null0 
> 
> Jonathan,
> 
> > If a speaker aggregates a route, a route to the aggregated set of
> > destinations with a next-hop of null is installed in the speaker's routing
> > table.  This is done to avoid a routing loop in the event that: one of the
> > more specific routes goes away, the peer (that the aggregate was
> advertised
> > to) advertised the default route, and the peer (that the aggregate was
> sent
> > to) sends a pkt to the speaker destined for the more specific route that
> > went away.
> > 
> > I think the current draft stipulates that this should be handled by the
> > speaker withdrawing the more specific route and/or de-aggregating or
> > something; there is no mention of the current working code's "null
> solution"
> > (as described above).
> 
> See Section 4.2 RFC1519.
> 
> Yakov.
> 
> > 
> >  
> > 
> > Not sure what Juniper does on this one (use 127.x.x.x vs null0 ???).
> > 
> > 
> > ------_=_NextPart_001_01C26A25.CBF1A260
> > 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";}
> > h1
> > 	{margin-top:0in;
> > 	margin-right:0in;
> > 	margin-bottom:0in;
> > 	margin-left:.5in;
> > 	margin-bottom:.0001pt;
> > 	text-indent:-.25in;
> > 	page-break-after:avoid;
> > 	font-size:16.0pt;
> > 	font-family:"Times New Roman";}
> > h2
> > 	{margin-top:0in;
> > 	margin-right:0in;
> > 	margin-bottom:0in;
> > 	margin-left:.8in;
> > 	margin-bottom:.0001pt;
> > 	text-indent:-.3in;
> > 	page-break-after:avoid;
> > 	font-size:12.0pt;
> > 	font-family:Arial;}
> > a:link, span.MsoHyperlink
> > 	{color:blue;
> > 	text-decoration:underline;}
> > a:visited, span.MsoHyperlinkFollowed
> > 	{color:purple;
> > 	text-decoration:underline;}
> > p.StyleHeading1Arial12ptLeft, li.StyleHeading1Arial12ptLeft,
> div.StyleHeading
> 1Arial12ptLeft
> > 	{margin-top:0in;
> > 	margin-right:0in;
> > 	margin-bottom:0in;
> > 	margin-left:.5in;
> > 	margin-bottom:.0001pt;
> > 	text-indent:-.25in;
> > 	page-break-after:avoid;
> > 	font-size:12.0pt;
> > 	font-family:"Times New Roman";
> > 	font-weight:bold;}
> > p.StyleArial22ptBoldCentered, li.StyleArial22ptBoldCentered,
> div.StyleArial22
> ptBoldCentered
> > 	{margin:0in;
> > 	margin-bottom:.0001pt;
> > 	text-align:center;
> > 	font-size:20.0pt;
> > 	font-family:Arial;
> > 	font-weight:bold;}
> > span.EmailStyle19
> > 	{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;}
> >  /* List Definitions */
> >  ol
> > 	{margin-bottom:0in;}
> > ul
> > 	{margin-bottom:0in;}
> > -->
> > </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'>If a speaker aggregates a route, a route to the
> aggregated
> > set of destinations with a next-hop of null is installed in the speaker's
> > routing table.&nbsp; This is done to avoid a routing loop in the event
> that: 
> one
> > of the more specific routes goes away, the peer (that the aggregate was
> > advertised to) advertised the default route, and the peer (that the
> aggregate
> > was sent to) sends a pkt to the speaker destined for the more specific
> route
> > that went away.</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'>I think the current draft stipulates that this should
> be
> > handled by the speaker withdrawing the more specific route and/or
> > de-aggregating or something; there is no mention of the current working
> code'
> s
> > "null solution" (as described above).</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'>Not sure what Juniper does on this one (use 127.x.x.x
> vs
> > null0 ???).</span></font></p>
> > 
> > </div>
> > 
> > </body>
> > 
> > </html>
> > 
> > ------_=_NextPart_001_01C26A25.CBF1A260--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA25209 for <[e-mail]>; Wed, 2 Oct 2002 11:57:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 258DD912CA; Wed,  2 Oct 2002 11:57:15 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2FD4912CB; Wed,  2 Oct 2002 11:57: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 EF355912CA for <[e-mail]>; Wed,  2 Oct 2002 11:57:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DA2845DDBE; Wed,  2 Oct 2002 11:57: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 57C1F5DD8E for <[e-mail]>; Wed,  2 Oct 2002 11:57:09 -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 LAA64207; Wed, 2 Oct 2002 11:56:36 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Reply-To: [e-mail]
Subject: issue 11.2 (was Re: Active Route)
In-reply-to: Your message of "Wed, 02 Oct 2002 10:19:49 EDT." <[e-mail]> 
Date: Wed, 02 Oct 2002 11:56:36 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]
ks.com>, "Natale, Jonathan" writes:
> Folks,
> 
> This issue seems to have been convoluted into issue 32.2.  I am in agreement
> with 32.2 (other than style/conciseness--I think it is a little long winded,
> but I can live with it), but it is not what I raised.  
> 
> The issue I raised, and would like to be [re-]considered is with:
> 
> "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."


That is called route orgination and it is allowed by:

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

Advice on what to put in the AS_PATH and NEXT_HOP is in the document.

> This means that if the speaker's routing table has a non-bgp route to a
> destination but does not have bgp route to the same destination (for
> example, based on administrative distance), then the speaker may not
> advertise that route to it's peers. This is true on Juniper by default for
> EBGP, but is NOT TRUE [ever?] on Juniper for IBGP, and is NOT TRUE on
> Juniper if ~= "advertise inactive" is enabled.  This is NOT TRUE ever on
> Cisco.

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

> Now we are proposing that the quoted clause above be completely removed.
> This means that it will be allowable to advertise a route to a destination
> that is not locally reachable.  This is obviously (to me, but not to all--
> which is why it should not be removed) bad. 
> 
> Thank you.

In the summary, one of the entries is incorrect:

  11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2

  ...

  Since this issue and issue 32.2 are very similar, and 32.2 is at consensus,
  this issue has also been moved to consensus in favor of 32.2.

These are not the same so the entry in Andrews summary is wrong.

We never reached full consensus on 11.2 but seemed to have more
support for either 1) leaving it as, 2) take it out.  There were some
semantic arguments about what it meant to "use" a route with a few
people offering an interpretation of "use" that would make the
statement false under some conditions.

I suggest that we change 11.2 and return it to "no consensus".

The edit to change the same paragraph in 32.2 was to reflect the
intent of the paragraph to indicate that BGP supports destination
based routing and not some form of source specified routing.

I don't think there was ever consensus on what to do with the
statement "a BGP speaker advertises to its peers (other BGP speakers
which it communicates with) in neighboring ASs only those routes that
it itself uses".  Some reasonable choices are:

  1.  Omit it (the implied consensus of the rewrite of the paragraph
      in 32.2).

  2.  Leave it as is and put it in another paragraph to separate it
      from the destination based routing statement.

  3.  Clean up the wording and put it in another paragraph to separate
      it from the destination based routing statement.

The separate paragraph for 2 would be the exact sentence we now have.

   A BGP speaker advertises to its peers (other BGP speakers which it
   communicates with) in neighboring ASs only those routes that it
   itself uses.

In possibility 3 we (try to) clear up the ambiguity about the meaning
of the word "use" in this sentence.

   A BGP speaker advertises to its peers (other BGP speakers which it
   communicates with) in neighboring ASs only those routes that it
   itself uses.  In this context a BGP speaker is said to "use" a BGP
   route if it is the most preferred BGP route and is either directly
   used in forwarding or in a specifically configured case where the
   BGP route would be forwarded internally but IGP forwarding
   information is used.  The latter case reflects a usage in which the
   IGP is used for forwarding but BGP is originated to IBGP to carry
   attributes that cannot be carried by the IGP (for example, BGP
   communities [N]).  Other special cases such as virtual routers and
   multiple instances of BGP on a single router are beyond the scope
   of this document but for each of these the statement "a BGP speaker
   advertises to its peers (other BGP speakers which it communicates
   with) in neighboring ASs only those routes that it itself uses" can
   (and should in the definition of the extension) be made true with
   an appropriate definition of the word "use".

Unless someone volunteers better wording this may be a good starting
point.  I thing the last sentence borders on ridiculous in a protocol
spec but may be necessary to address specific objections raised on
this mailing list.  If we want to elaborate on the meaning of the word
"use" and address the objections this is what we end up with.

Of course looking at what we ended up with, I'd also go along with the
other two options (leave it out or put the one sentence in a separate
paragraph as is).

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 LAA25185 for <[e-mail]>; Wed, 2 Oct 2002 11:57:13 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 648C9912C8; Wed,  2 Oct 2002 11:56:45 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 33EEA912CA; Wed,  2 Oct 2002 11:56: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 2C40A912C8 for <[e-mail]>; Wed,  2 Oct 2002 11:56:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 18C495DDBE; Wed,  2 Oct 2002 11:56:44 -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 C35945DDAA for <[e-mail]>; Wed,  2 Oct 2002 11:56:43 -0400 (EDT)
Received: from riga ([10.0.0.25]) by earthquake.proficient.net with Microsoft SMTPSVC(5.0.2195.4905); Wed, 2 Oct 2002 08:56:42 -0700
Subject: Re: issue 8
From: Justin Fletcher <[e-mail]>
To: Yakov Rekhter <[e-mail]>
Cc: [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: 02 Oct 2002 08:56:17 -0700
Message-Id: <1033574178.27465.34.camel@riga>
Mime-Version: 1.0
X-OriginalArrivalTime: 02 Oct 2002 15:56:43.0082 (UTC) FILETIME=[4D7B32A0:01C26A2C]
Sender: [e-mail]
Precedence: bulk

>    The amount of jitter to be introduced shall be determined by
>    multiplying the base value of the appropriate timer by a random
>    factor which is uniformly distributed in the range from 0.75 to
>    1.0.

I'd suggest "uniformly distributed in the range from 0.75 to 1.25"
to ensure the average is the configured interval.

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 LAA24962 for <[e-mail]>; Wed, 2 Oct 2002 11:53:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CC579912C7; Wed,  2 Oct 2002 11:53:08 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99A3B912C8; Wed,  2 Oct 2002 11:53: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 29006912C7 for <[e-mail]>; Wed,  2 Oct 2002 11:53:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 04FDE5DDBE; Wed,  2 Oct 2002 11:53:06 -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 B6D155DD8E for <[e-mail]>; Wed,  2 Oct 2002 11:53:05 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12R34>; Wed, 2 Oct 2002 11:53:05 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: RE: route to null0 
Date: Wed, 2 Oct 2002 11:53:04 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Yakov,

Thanks!

"A routing domain which performs summarization of multiple routes
must discard packets which match the summarization but do not match any
of the explicit routes which makes up the summarization."

That covers it.  

I think adding a "[8]" (currently "[8]" is not explicitly cited anywhere) in
a strategic spot would be a good idea; I have seen this point missed by
some.


-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 11:27 AM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: route to null0 

Jonathan,

> If a speaker aggregates a route, a route to the aggregated set of
> destinations with a next-hop of null is installed in the speaker's routing
> table.  This is done to avoid a routing loop in the event that: one of the
> more specific routes goes away, the peer (that the aggregate was
advertised
> to) advertised the default route, and the peer (that the aggregate was
sent
> to) sends a pkt to the speaker destined for the more specific route that
> went away.
> 
> I think the current draft stipulates that this should be handled by the
> speaker withdrawing the more specific route and/or de-aggregating or
> something; there is no mention of the current working code's "null
solution"
> (as described above).

See Section 4.2 RFC1519.

Yakov.

> 
>  
> 
> Not sure what Juniper does on this one (use 127.x.x.x vs null0 ???).
> 
> 
> ------_=_NextPart_001_01C26A25.CBF1A260
> 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";}
> h1
> 	{margin-top:0in;
> 	margin-right:0in;
> 	margin-bottom:0in;
> 	margin-left:.5in;
> 	margin-bottom:.0001pt;
> 	text-indent:-.25in;
> 	page-break-after:avoid;
> 	font-size:16.0pt;
> 	font-family:"Times New Roman";}
> h2
> 	{margin-top:0in;
> 	margin-right:0in;
> 	margin-bottom:0in;
> 	margin-left:.8in;
> 	margin-bottom:.0001pt;
> 	text-indent:-.3in;
> 	page-break-after:avoid;
> 	font-size:12.0pt;
> 	font-family:Arial;}
> a:link, span.MsoHyperlink
> 	{color:blue;
> 	text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> 	{color:purple;
> 	text-decoration:underline;}
> p.StyleHeading1Arial12ptLeft, li.StyleHeading1Arial12ptLeft,
div.StyleHeading
1Arial12ptLeft
> 	{margin-top:0in;
> 	margin-right:0in;
> 	margin-bottom:0in;
> 	margin-left:.5in;
> 	margin-bottom:.0001pt;
> 	text-indent:-.25in;
> 	page-break-after:avoid;
> 	font-size:12.0pt;
> 	font-family:"Times New Roman";
> 	font-weight:bold;}
> p.StyleArial22ptBoldCentered, li.StyleArial22ptBoldCentered,
div.StyleArial22
ptBoldCentered
> 	{margin:0in;
> 	margin-bottom:.0001pt;
> 	text-align:center;
> 	font-size:20.0pt;
> 	font-family:Arial;
> 	font-weight:bold;}
> span.EmailStyle19
> 	{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;}
>  /* List Definitions */
>  ol
> 	{margin-bottom:0in;}
> ul
> 	{margin-bottom:0in;}
> -->
> </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'>If a speaker aggregates a route, a route to the
aggregated
> set of destinations with a next-hop of null is installed in the speaker's
> routing table.&nbsp; This is done to avoid a routing loop in the event
that: 
one
> of the more specific routes goes away, the peer (that the aggregate was
> advertised to) advertised the default route, and the peer (that the
aggregate
> was sent to) sends a pkt to the speaker destined for the more specific
route
> that went away.</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'>I think the current draft stipulates that this should
be
> handled by the speaker withdrawing the more specific route and/or
> de-aggregating or something; there is no mention of the current working
code'
s
> "null solution" (as described above).</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'>Not sure what Juniper does on this one (use 127.x.x.x
vs
> null0 ???).</span></font></p>
> 
> </div>
> 
> </body>
> 
> </html>
> 
> ------_=_NextPart_001_01C26A25.CBF1A260--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA24804 for <[e-mail]>; Wed, 2 Oct 2002 11:50:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9F1BA912C6; Wed,  2 Oct 2002 11:49:36 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E6F6912C7; Wed,  2 Oct 2002 11:49: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 3A27C912C6 for <[e-mail]>; Wed,  2 Oct 2002 11:49:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 28D575DDBE; Wed,  2 Oct 2002 11:49: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 B8F205DDAA for <[e-mail]>; Wed,  2 Oct 2002 11:49: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 g92FnYm44337 for <[e-mail]>; Wed, 2 Oct 2002 08:49:34 -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: Wed, 02 Oct 2002 08:49:34 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Folks,

I'd like to propose the following text for "BGP Timers" section:

   BGP employs five timers: ConnectRetry (see Section 8), Hold Time
   (see Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval
   (see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
   Section 9.2.1.1).

   The suggested value for the ConnectRetry timer is 120 seconds.

   The suggested value for the Hold Time is 90 seconds.

   The suggested value for the KeepAlive timer is 1/3 of the Hold
   Time.

   The suggested value for the MinASOriginationInterval is 15
   seconds.

   The suggested value for the MinRouteAdvertisementInterval is 30
   seconds.

   An implementation of BGP MUST allow the Hold Time timer to be
   configurable, and MAY allow the other timers to be configurable.

   To minimize the likelihood that the distribution of BGP messages
   by a given BGP speaker will contain peaks, jitter should be
   applied to the timers associated with MinASOriginationInterval,
   Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
   given BGP speaker shall apply the same jitter to each of these
   quantities regardless of the destinations to which the updates
   are being sent; that is, jitter will not be applied on a "per
   peer" basis.

Any objections ?

Yakov.

   The amount of jitter to be introduced shall be determined by
   multiplying the base value of the appropriate timer by a random
   factor which is uniformly distributed in the range from 0.75 to
   1.0.




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA24373 for <[e-mail]>; Wed, 2 Oct 2002 11:40:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9269A912C4; Wed,  2 Oct 2002 11:40:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5DB52912C5; Wed,  2 Oct 2002 11:40: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 1926C912C4 for <[e-mail]>; Wed,  2 Oct 2002 11:40:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 042295DDC1; Wed,  2 Oct 2002 11:40: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 B3A1C5DDAA for <[e-mail]>; Wed,  2 Oct 2002 11:40:30 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12RM0>; Wed, 2 Oct 2002 11:40:30 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Jeffrey Haas'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Complex AS Path Aggregating
Date: Wed, 2 Oct 2002 11:40:30 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

The fact is that nobody does it (if anyone does do this,
please speak up), so I think is should be removed to reflect
current working code.

The test tested that the complex aggregation was done, it did not test
that complex aggregation could received gracefully; this
would be a useless test anyway, since no real world implementations do
complex aggregation.

-----Original Message-----
From: Jeffrey Haas [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 11:10 AM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: Complex AS Path Aggregating

On Wed, Oct 02, 2002 at 11:06:25AM -0400, Natale, Jonathan wrote:
> AFAIK, all implementations aggregate by either: (2nd)putting ONLY the
local
> AS in the path (and setting the atomic) OR (3rd)by creating 1 giant set
and
> adding the local AS as a seq.

If vendors choose to implement the complex as path aggregation, thats
fine.  If they do simple, thats fine.

Vendors should be able to receive and use either without problem.  *That*
is what the conformance tests should test.

-- 
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 LAA24337 for <[e-mail]>; Wed, 2 Oct 2002 11:40:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B7100912C3; Wed,  2 Oct 2002 11:39:32 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 887B3912C4; Wed,  2 Oct 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 7EC4D912C3 for <[e-mail]>; Wed,  2 Oct 2002 11:39:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5C68C5DDBE; Wed,  2 Oct 2002 11:39: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 978E35DDAA for <[e-mail]>; Wed,  2 Oct 2002 11:39: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 LAA11746; Wed, 2 Oct 2002 11:39: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 LAA03671; Wed, 2 Oct 2002 11:39:28 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7PDAV>; Wed, 2 Oct 2002 11:39:26 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, BGP mailing list <[e-mail]>
Subject: RE: Active Route
Date: Wed, 2 Oct 2002 11:39: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

Hans

> So, in theory the rule : "one must focus on the rule that a 
> BGP speaker
> advertises to its peers  in neighboring ASs only those routes 
> that it itself
> uses." is broken, since it is clearly an IGP route which in the FIB.
> 

If the IGP route in the Routing Table and the IBGP route use the same
next hop address, it is not broken. The only time I think its broken
if the next hop address is different. What we say is broken is the gaurantee
that the peer is told correctly the path the forwarding plane will work.
Reachability could still be possible. But we know IP is not an exact
science.


Ben
> ---
> Hans de Vleeschouwer
> 
> 
> "Martin, Christian" wrote:
> 
> > Jonathan,
> >
> > >
> > >"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 means that if the speaker's routing table has a non-bgp
> > >route to a destination but does not have bgp route to the same
> > >destination (for example, based on administrative distance),
> > >then the speaker may not advertise that route to it's peers.
> > >This is true on Juniper by default for EBGP, but is NOT TRUE
> > >[ever?] on Juniper for IBGP, and is NOT TRUE on Juniper if ~=
> > >"advertise inactive" is enabled.  This is NOT TRUE ever on Cisco.
> > >
> > >Now we are proposing that the quoted clause above be
> > >completely removed. This means that it will be allowable to
> > >advertise a route to a destination that is not locally
> > >reachable.  This is obviously (to me, but not to all-- which
> > >is why it should not be removed) bad.
> >
> > This, IMO, is not the spirit of the rule.  Juniper 
> interpreted the spec
> > differently.  As I see it, if the route is in the routing 
> table, you can
> > announce it.  To be more specific, and to your point 
> Jonathan, we should say
> > this - or say the converse:
> >
> > "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 learned via BGP that it
> > itself uses.  "Learned via BGP" means that a router's best path
> > to a prefix is one that was either learned from a BGP peer, or
> > deliberately injected into BGP by the local router."
> >
> > Regards,
> > -chris
> >
> > >
> > >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 LAA23984 for <[e-mail]>; Wed, 2 Oct 2002 11:33:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id A5347912C2; Wed,  2 Oct 2002 11:33:10 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7497E912C3; Wed,  2 Oct 2002 11:33: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 483CB912C2 for <[e-mail]>; Wed,  2 Oct 2002 11:32:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 182485DDBB; Wed,  2 Oct 2002 11:32: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 C45B35DDAA for <[e-mail]>; Wed,  2 Oct 2002 11:32:51 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12RLV>; Wed, 2 Oct 2002 11:32:51 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Martin, Christian'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Active Route
Date: Wed, 2 Oct 2002 11:32:50 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Christian,

Thank you for replying.

Your change would not cover the case, for example, where the speaker
uses a static route that is not redistributed into bgp to reach
a set of destinations that is also learned via bgp.

I was thinking of:
"one must focus on the rule that a BGP speaker advertises to 
its peers only routes whose set of destinations
are reachable per the local Routing Table."


-----Original Message-----
From: Martin, Christian [mailto:[e-mail]] 
Sent: Wednesday, October 02, 2002 10:28 AM
To: 'Natale, Jonathan'; [e-mail]
Subject: RE: Active Route

Jonathan,

>
>"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 means that if the speaker's routing table has a non-bgp 
>route to a destination but does not have bgp route to the same 
>destination (for example, based on administrative distance), 
>then the speaker may not advertise that route to it's peers. 
>This is true on Juniper by default for EBGP, but is NOT TRUE 
>[ever?] on Juniper for IBGP, and is NOT TRUE on Juniper if ~= 
>"advertise inactive" is enabled.  This is NOT TRUE ever on Cisco.
>
>Now we are proposing that the quoted clause above be 
>completely removed. This means that it will be allowable to 
>advertise a route to a destination that is not locally 
>reachable.  This is obviously (to me, but not to all-- which 
>is why it should not be removed) bad. 

This, IMO, is not the spirit of the rule.  Juniper interpreted the spec
differently.  As I see it, if the route is in the routing table, you can
announce it.  To be more specific, and to your point Jonathan, we should say
this - or say the converse:

"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 learned via BGP that it 
itself uses.  "Learned via BGP" means that a router's best path
to a prefix is one that was either learned from a BGP peer, or
deliberately injected into BGP by the local router."

Regards,
-chris




>
>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 LAA23735 for <[e-mail]>; Wed, 2 Oct 2002 11:27:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 28353912C1; Wed,  2 Oct 2002 11:27:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAF07912C3; Wed,  2 Oct 2002 11:27: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 BA81C912C1 for <[e-mail]>; Wed,  2 Oct 2002 11:27:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A89C15DDAA; Wed,  2 Oct 2002 11:27:25 -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 AB34D5DD93 for <[e-mail]>; Wed,  2 Oct 2002 11:27: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 g92FRMm43026; Wed, 2 Oct 2002 08:27:22 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: route to null0 
In-Reply-To: Your message of "Wed, 02 Oct 2002 11:10:08 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Wed, 02 Oct 2002 08:27:22 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> If a speaker aggregates a route, a route to the aggregated set of
> destinations with a next-hop of null is installed in the speaker's routing
> table.  This is done to avoid a routing loop in the event that: one of the
> more specific routes goes away, the peer (that the aggregate was advertised
> to) advertised the default route, and the peer (that the aggregate was sent
> to) sends a pkt to the speaker destined for the more specific route that
> went away.
> 
> I think the current draft stipulates that this should be handled by the
> speaker withdrawing the more specific route and/or de-aggregating or
> something; there is no mention of the current working code's "null solution"
> (as described above).

See Section 4.2 RFC1519.

Yakov.

> 
>  
> 
> Not sure what Juniper does on this one (use 127.x.x.x vs null0 ???).
> 
> 
> ------_=_NextPart_001_01C26A25.CBF1A260
> 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";}
> h1
> 	{margin-top:0in;
> 	margin-right:0in;
> 	margin-bottom:0in;
> 	margin-left:.5in;
> 	margin-bottom:.0001pt;
> 	text-indent:-.25in;
> 	page-break-after:avoid;
> 	font-size:16.0pt;
> 	font-family:"Times New Roman";}
> h2
> 	{margin-top:0in;
> 	margin-right:0in;
> 	margin-bottom:0in;
> 	margin-left:.8in;
> 	margin-bottom:.0001pt;
> 	text-indent:-.3in;
> 	page-break-after:avoid;
> 	font-size:12.0pt;
> 	font-family:Arial;}
> a:link, span.MsoHyperlink
> 	{color:blue;
> 	text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> 	{color:purple;
> 	text-decoration:underline;}
> p.StyleHeading1Arial12ptLeft, li.StyleHeading1Arial12ptLeft, div.StyleHeading
1Arial12ptLeft
> 	{margin-top:0in;
> 	margin-right:0in;
> 	margin-bottom:0in;
> 	margin-left:.5in;
> 	margin-bottom:.0001pt;
> 	text-indent:-.25in;
> 	page-break-after:avoid;
> 	font-size:12.0pt;
> 	font-family:"Times New Roman";
> 	font-weight:bold;}
> p.StyleArial22ptBoldCentered, li.StyleArial22ptBoldCentered, div.StyleArial22
ptBoldCentered
> 	{margin:0in;
> 	margin-bottom:.0001pt;
> 	text-align:center;
> 	font-size:20.0pt;
> 	font-family:Arial;
> 	font-weight:bold;}
> span.EmailStyle19
> 	{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;}
>  /* List Definitions */
>  ol
> 	{margin-bottom:0in;}
> ul
> 	{margin-bottom:0in;}
> -->
> </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'>If a speaker aggregates a route, a route to the aggregated
> set of destinations with a next-hop of null is installed in the speaker's
> routing table.&nbsp; This is done to avoid a routing loop in the event that: 
one
> of the more specific routes goes away, the peer (that the aggregate was
> advertised to) advertised the default route, and the peer (that the aggregate
> was sent to) sends a pkt to the speaker destined for the more specific route
> that went away.</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'>I think the current draft stipulates that this should be
> handled by the speaker withdrawing the more specific route and/or
> de-aggregating or something; there is no mention of the current working code'
s
> "null solution" (as described above).</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'>Not sure what Juniper does on this one (use 127.x.x.x vs
> null0 ???).</span></font></p>
> 
> </div>
> 
> </body>
> 
> </html>
> 
> ------_=_NextPart_001_01C26A25.CBF1A260--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA23682 for <[e-mail]>; Wed, 2 Oct 2002 11:26:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 6A20D912C9; Wed,  2 Oct 2002 11:25:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F603912CA; Wed,  2 Oct 2002 11:25: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 91CF5912C9 for <[e-mail]>; Wed,  2 Oct 2002 11:25:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 29A4B5DDB7; Wed,  2 Oct 2002 11:25: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 59C0E5DDAA for <[e-mail]>; Wed,  2 Oct 2002 11:25:06 -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 g92FIa106627 for <[e-mail]>; Wed, 2 Oct 2002 17:18:36 +0200
Received: from alcatel.be ([138.203.191.116]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002100217250051:5946 ; Wed, 2 Oct 2002 17:25:00 +0200 
Message-ID: <[e-mail]>
Date: Wed, 02 Oct 2002 17:24:56 +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: Active Route
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 10/02/2002 17:25:00, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 10/02/2002 17:25:01, Serialize complete at 10/02/2002 17:25:01
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk

I did not follow the whole discussion on this, however I am puzzeld with the
following situation:

I am acting as a transit AS. I receive routes via EBGP in an AS-border (router
A)  router of my AS.

Then I redistribute the routes into IGP, and at the same time I forward
the routes via IBGP (not full mesh) to all of the other AS border routers (but
to no other routers).

At the other side of my AS, I allow the border router (router B) to pass those
routes learned via IBGP (form router A) to the (next) AS via an EBGP connection.
(I am using the  "synchronise BGP = TRUE" option.)

Now in this fairly straightforward example, the router B will forward routes
learned via IBGP to the next AS using EBGP, whereas for those routes the
reachability in the FIB is taken care of by IGP (who has typically a higher
preference in ther FIB then IBGP).

So, in theory the rule : "one must focus on the rule that a BGP speaker
advertises to its peers  in neighboring ASs only those routes that it itself
uses." is broken, since it is clearly an IGP route which in the FIB.

---
Hans de Vleeschouwer


"Martin, Christian" wrote:

> Jonathan,
>
> >
> >"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 means that if the speaker's routing table has a non-bgp
> >route to a destination but does not have bgp route to the same
> >destination (for example, based on administrative distance),
> >then the speaker may not advertise that route to it's peers.
> >This is true on Juniper by default for EBGP, but is NOT TRUE
> >[ever?] on Juniper for IBGP, and is NOT TRUE on Juniper if ~=
> >"advertise inactive" is enabled.  This is NOT TRUE ever on Cisco.
> >
> >Now we are proposing that the quoted clause above be
> >completely removed. This means that it will be allowable to
> >advertise a route to a destination that is not locally
> >reachable.  This is obviously (to me, but not to all-- which
> >is why it should not be removed) bad.
>
> This, IMO, is not the spirit of the rule.  Juniper interpreted the spec
> differently.  As I see it, if the route is in the routing table, you can
> announce it.  To be more specific, and to your point Jonathan, we should say
> this - or say the converse:
>
> "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 learned via BGP that it
> itself uses.  "Learned via BGP" means that a router's best path
> to a prefix is one that was either learned from a BGP peer, or
> deliberately injected into BGP by the local router."
>
> Regards,
> -chris
>
> >
> >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 LAA22895 for <[e-mail]>; Wed, 2 Oct 2002 11:10:59 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CE193912BE; Wed,  2 Oct 2002 11:10:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F45A912C0; Wed,  2 Oct 2002 11:10: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 03729912BE for <[e-mail]>; Wed,  2 Oct 2002 11:10:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E3C3C5DD9C; Wed,  2 Oct 2002 11:10: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 32C235DD93 for <[e-mail]>; Wed,  2 Oct 2002 11:10:11 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g92FA9w17021; Wed, 2 Oct 2002 11:10: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 g92FA6G17014; Wed, 2 Oct 2002 11:10:06 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g92FA6Y29423; Wed, 2 Oct 2002 11:10:06 -0400 (EDT)
Date: Wed, 2 Oct 2002 11:10:06 -0400
From: Jeffrey Haas <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: Complex AS Path Aggregating
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, Oct 02, 2002 at 11:06:25AM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Wed, Oct 02, 2002 at 11:06:25AM -0400, Natale, Jonathan wrote:
> AFAIK, all implementations aggregate by either: (2nd)putting ONLY the local
> AS in the path (and setting the atomic) OR (3rd)by creating 1 giant set and
> adding the local AS as a seq.

If vendors choose to implement the complex as path aggregation, thats
fine.  If they do simple, thats fine.

Vendors should be able to receive and use either without problem.  *That*
is what the conformance tests should test.

-- 
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 LAA22875 for <[e-mail]>; Wed, 2 Oct 2002 11:10:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1586B9125E; Wed,  2 Oct 2002 11:10:13 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1432912BF; Wed,  2 Oct 2002 11:10: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 CFE119125E for <[e-mail]>; Wed,  2 Oct 2002 11:10:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C022F5DD9C; Wed,  2 Oct 2002 11:10: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 7CC675DD93 for <[e-mail]>; Wed,  2 Oct 2002 11:10:10 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12R2S>; Wed, 2 Oct 2002 11:10:10 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: route to null0
Date: Wed, 2 Oct 2002 11:10:08 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26A25.CBF1A260"
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_01C26A25.CBF1A260
Content-Type: text/plain

If a speaker aggregates a route, a route to the aggregated set of
destinations with a next-hop of null is installed in the speaker's routing
table.  This is done to avoid a routing loop in the event that: one of the
more specific routes goes away, the peer (that the aggregate was advertised
to) advertised the default route, and the peer (that the aggregate was sent
to) sends a pkt to the speaker destined for the more specific route that
went away.

 

I think the current draft stipulates that this should be handled by the
speaker withdrawing the more specific route and/or de-aggregating or
something; there is no mention of the current working code's "null solution"
(as described above).

 

Not sure what Juniper does on this one (use 127.x.x.x vs null0 ???).


------_=_NextPart_001_01C26A25.CBF1A260
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";}
h1
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	text-indent:-.25in;
	page-break-after:avoid;
	font-size:16.0pt;
	font-family:"Times New Roman";}
h2
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.8in;
	margin-bottom:.0001pt;
	text-indent:-.3in;
	page-break-after:avoid;
	font-size:12.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.StyleHeading1Arial12ptLeft, li.StyleHeading1Arial12ptLeft, div.StyleHeading1Arial12ptLeft
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	text-indent:-.25in;
	page-break-after:avoid;
	font-size:12.0pt;
	font-family:"Times New Roman";
	font-weight:bold;}
p.StyleArial22ptBoldCentered, li.StyleArial22ptBoldCentered, div.StyleArial22ptBoldCentered
	{margin:0in;
	margin-bottom:.0001pt;
	text-align:center;
	font-size:20.0pt;
	font-family:Arial;
	font-weight:bold;}
span.EmailStyle19
	{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;}
 /* List Definitions */
 ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</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'>If a speaker aggregates a route, a route to the aggregated
set of destinations with a next-hop of null is installed in the speaker's
routing table.&nbsp; This is done to avoid a routing loop in the event that: one
of the more specific routes goes away, the peer (that the aggregate was
advertised to) advertised the default route, and the peer (that the aggregate
was sent to) sends a pkt to the speaker destined for the more specific route
that went away.</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'>I think the current draft stipulates that this should be
handled by the speaker withdrawing the more specific route and/or
de-aggregating or something; there is no mention of the current working code's
"null solution" (as described above).</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'>Not sure what Juniper does on this one (use 127.x.x.x vs
null0 ???).</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C26A25.CBF1A260--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA22637 for <[e-mail]>; Wed, 2 Oct 2002 11:06:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 17C9A9125D; Wed,  2 Oct 2002 11:06:29 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFB2A9125E; Wed,  2 Oct 2002 11:06: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 1BA269125D for <[e-mail]>; Wed,  2 Oct 2002 11:06:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DC3475DD9C; Wed,  2 Oct 2002 11:06:26 -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 8E92D5DD93 for <[e-mail]>; Wed,  2 Oct 2002 11:06:26 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12RH0>; Wed, 2 Oct 2002 11:06:26 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: Complex AS Path Aggregating
Date: Wed, 2 Oct 2002 11:06:25 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26A25.46C36560"
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_01C26A25.46C36560
Content-Type: text/plain

This issue seems to have been lost, or maybe I never posted it.

 

The part in the draft about complex AS path aggregation could/should be
deleted.  The current draft implies that when aggregating, for example
(1st):

1 2 4 3

w/

3 4 6 5

and

5 6 7 8

 

then

1 2 {3 4 5 6} 7 8

 

...would be OK

 

AFAIK, all implementations aggregate by either: (2nd)putting ONLY the local
AS in the path (and setting the atomic) OR (3rd)by creating 1 giant set and
adding the local AS as a seq.

 

1 test equipment vendor went as far as to create such a test(for the 1st),
which "FAILED".  But if you read the draft carefully, clumping all the AS's
into a set passes.


------_=_NextPart_001_01C26A25.46C36560
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";}
h1
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	text-indent:-.25in;
	page-break-after:avoid;
	font-size:16.0pt;
	font-family:"Times New Roman";}
h2
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.8in;
	margin-bottom:.0001pt;
	text-indent:-.3in;
	page-break-after:avoid;
	font-size:12.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.StyleHeading1Arial12ptLeft, li.StyleHeading1Arial12ptLeft, div.StyleHeading1Arial12ptLeft
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	text-indent:-.25in;
	page-break-after:avoid;
	font-size:12.0pt;
	font-family:"Times New Roman";
	font-weight:bold;}
p.StyleArial22ptBoldCentered, li.StyleArial22ptBoldCentered, div.StyleArial22ptBoldCentered
	{margin:0in;
	margin-bottom:.0001pt;
	text-align:center;
	font-size:20.0pt;
	font-family:Arial;
	font-weight:bold;}
span.EmailStyle19
	{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;}
 /* List Definitions */
 ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</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'>This issue seems to have been lost, or maybe I never posted
it.</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'>The part in the draft about complex AS path aggregation
could/should be deleted.&nbsp; The current draft implies that when aggregating,
for example (1<sup>st</sup>):</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>1 2 4 3</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>w/</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>3 4 6 5</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>and</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>5 6 7 8</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'>then</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>1 2 {3 4 5 6} 7 8</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'>...would be OK</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'>AFAIK, all implementations aggregate by either: (2<sup>nd</sup>)putting
ONLY the local AS in the path (and setting the atomic) OR (3<sup>rd</sup>)by
creating 1 giant set and adding the local AS as a seq.</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'>1 test equipment vendor went as far as to create such a
test(for the 1<sup>st</sup>), which "FAILED".&nbsp; But if you read
the draft carefully, clumping all the AS's into a set passes.</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C26A25.46C36560--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA22224 for <[e-mail]>; Wed, 2 Oct 2002 10:58:21 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B849591252; Wed,  2 Oct 2002 10:58:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85F6F9125D; Wed,  2 Oct 2002 10: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 166DB91252 for <[e-mail]>; Wed,  2 Oct 2002 10:58:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 013215DDBF; Wed,  2 Oct 2002 10:58: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 B12B05DDBE for <[e-mail]>; Wed,  2 Oct 2002 10:57:59 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12RGN>; Wed, 2 Oct 2002 10:57:59 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: aggregating with MED and NEXT_HOP
Date: Wed, 2 Oct 2002 10:57:58 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Folks,

I think this issue got lost.  I thought we had a consensus on 
Changing it to a "MAY", "SHOULD" or some combination.

I propose we remove/or relax:

"Routes that have the following attributes shall not be aggregated
   unless the corresponding attributes of each route are identical:
   MULTI_EXIT_DISC, NEXT_HOP."

Cisco (and I think Juniper as well), does aggregate routes with different
MEDs and NEXT_HOPs, but *I think* Cisco is added, or added, a config switch
for the MED.

Old email thread:

-----Original Message-----
From: Curtis Villamizar [mailto:[e-mail]] 
Sent: Tuesday, September 10, 2002 9:22 PM
To: Natale, Jonathan
Cc: '[e-mail]'; [e-mail]
Subject: Re: 


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 KAA20736 for <[e-mail]>; Wed, 2 Oct 2002 10:28:16 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 189AD9124D; Wed,  2 Oct 2002 10:27:54 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC6E39124F; Wed,  2 Oct 2002 10: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 CC5439124D for <[e-mail]>; Wed,  2 Oct 2002 10:27:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B61595DDB2; Wed,  2 Oct 2002 10:27:52 -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 85B165DD9B for <[e-mail]>; Wed,  2 Oct 2002 10:27:52 -0400 (EDT)
Received: by entmail.gnilink.com with Internet Mail Service (5.5.2656.59) id <TRPKQDKT>; Wed, 2 Oct 2002 10:27:52 -0400
Message-ID: <[e-mail]>
From: "Martin, Christian" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, [e-mail]
Subject: RE: Active Route
Date: Wed, 2 Oct 2002 10:27:43 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Jonathan,

>
>"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 means that if the speaker's routing table has a non-bgp 
>route to a destination but does not have bgp route to the same 
>destination (for example, based on administrative distance), 
>then the speaker may not advertise that route to it's peers. 
>This is true on Juniper by default for EBGP, but is NOT TRUE 
>[ever?] on Juniper for IBGP, and is NOT TRUE on Juniper if ~= 
>"advertise inactive" is enabled.  This is NOT TRUE ever on Cisco.
>
>Now we are proposing that the quoted clause above be 
>completely removed. This means that it will be allowable to 
>advertise a route to a destination that is not locally 
>reachable.  This is obviously (to me, but not to all-- which 
>is why it should not be removed) bad. 

This, IMO, is not the spirit of the rule.  Juniper interpreted the spec
differently.  As I see it, if the route is in the routing table, you can
announce it.  To be more specific, and to your point Jonathan, we should say
this - or say the converse:

"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 learned via BGP that it 
itself uses.  "Learned via BGP" means that a router's best path
to a prefix is one that was either learned from a BGP peer, or
deliberately injected into BGP by the local router."

Regards,
-chris




>
>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 KAA20326 for <[e-mail]>; Wed, 2 Oct 2002 10:20:03 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 719C191251; Wed,  2 Oct 2002 10:19:52 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 033039124F; Wed,  2 Oct 2002 10:19: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 B5ACF9124D for <[e-mail]>; Wed,  2 Oct 2002 10:19:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A6CFE5DDB2; Wed,  2 Oct 2002 10:19: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 68AF85DD9B for <[e-mail]>; Wed,  2 Oct 2002 10:19:50 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12RBL>; Wed, 2 Oct 2002 10:19:50 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: Active Route
Date: Wed, 2 Oct 2002 10:19:49 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Folks,

This issue seems to have been convoluted into issue 32.2.  I am in agreement
with 32.2 (other than style/conciseness--I think it is a little long winded,
but I can live with it), but it is not what I raised.  

The issue I raised, and would like to be [re-]considered is with:

"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 means that if the speaker's routing table has a non-bgp route to a
destination but does not have bgp route to the same destination (for
example, based on administrative distance), then the speaker may not
advertise that route to it's peers. This is true on Juniper by default for
EBGP, but is NOT TRUE [ever?] on Juniper for IBGP, and is NOT TRUE on
Juniper if ~= "advertise inactive" is enabled.  This is NOT TRUE ever on
Cisco.

Now we are proposing that the quoted clause above be completely removed.
This means that it will be allowable to advertise a route to a destination
that is not locally reachable.  This is obviously (to me, but not to all--
which is why it should not be removed) bad. 

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 KAA20241 for <[e-mail]>; Wed, 2 Oct 2002 10:18:20 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CA94E9124E; Wed,  2 Oct 2002 10:18:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 922D39124D; Wed,  2 Oct 2002 10: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 5B9D29124E for <[e-mail]>; Wed,  2 Oct 2002 10:17:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 37EFD5DDA2; Wed,  2 Oct 2002 10:17: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 B5E735DD9B for <[e-mail]>; Wed,  2 Oct 2002 10:17: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 KAA04518; Wed, 2 Oct 2002 10:17: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 KAA12335; Wed, 2 Oct 2002 10:17:29 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R737LQ>; Wed, 2 Oct 2002 10:17:27 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>, "'Dennis Ferguson'" <[e-mail]>, Dimitry Haskin <[e-mail]>
Cc: "'Natale, Jonathan'" <[e-mail]>, [e-mail]
Subject: RE: issue 11 
Date: Wed, 2 Oct 2002 10:17: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

Dennis:
  The assumption I made is AS-SET is not used at the aggregation point.

Sorry, if I misled you on the first part. 

Thanks,
Ben

> -----Original Message-----
> From: Abarbanel, Benjamin [mailto:[e-mail]]
> Sent: Wednesday, October 02, 2002 10:06 AM
> To: 'Dennis Ferguson'; Dimitry Haskin
> Cc: 'Natale, Jonathan'; [e-mail]
> Subject: RE: issue 11 
> 
> 
> Dennis:
> 
>   The potential weakness to aggregation when AS-PATH list of component
> routes
> are left out of the aggregated route is that the downstream peers that
> receive
> the aggregate route have no knowledge of the real path taken 
> from their
> point to the origin of any component route and thus are 
> unable to gaurantee
> loop free routing from their point to any component route's 
> destination. 
> 
> In the multi-path scenario, if we aggregate two, same prefix, 
> different
> AS-PATHS, different Next Hop, routes into one aggregate route 
> we hit this
> weakness. Do you agree?
> 
> My instinct is only to use multi-path in a localized manor, 
> load balance
> between two interfaces from one router to another, if we must 
> load balance
> between two interfaces to two separate routers, limit the amount of
> divergence these routes define in their AS_PATH attributes. 
> Perhaps have 1
> router setup to multipath to 2 other routers in the same AS 
> whose AS_PATH
> entries are the same. Once we start diverging, we get into 
> all kinds of
> permutations on the AS_PATH issue, we have to use aggregation 
> or we have to
> perform more policy decisions on how to deal with this, etc.
> 
> Since BGP4 does not provide the ability to tell another peer 
> that two routes
> which have the same prefix and different attributes are to be 
> treated as
> multipath routes, we are stuck with information that is 
> advertised to peers
> that is suboptimal.  Perhaps this feature, should be added to 
> a new draft
> titled "BGP Multipath" that you can edit, since you have vast 
> knowledge on
> the subject.
> 
> 
> Regards,
> Ben
> 
> > -----Original Message-----
> > From: Dennis Ferguson [mailto:[e-mail]]
> > Sent: Tuesday, October 01, 2002 11:20 PM
> > To: Dimitry Haskin
> > Cc: 'Natale, Jonathan'; [e-mail]
> > Subject: Re: issue 11 
> > 
> > 
> > Dimitry,
> > 
> > > After all if a BGP speaker chooses to advertise a single 
> > route even when
> > > multiple component routes are used for local forwarding, 
> > this in effect
> > > constitutes an aggregation -- even if the aggregate and 
> > components have
> > > the same prefix. As such, it should comply with aggregation 
> > rules that
> > > have been defined to provide loop-free routing.
> > 
> > I think the problem with this is the assertion that the 
> rules defined
> > in the document for AS path aggregation (I'm looking at the 
> > -17 document)
> > are necessary to provide loop-free routing in any case other 
> > than yours.
> > Obtaining loop-free routing does not require combining AS 
> paths in any
> > current situation, and because of this most routers, and 
> most users of
> > routers, don't always do route aggregation as defined in 
> the document.
> > 
> > In particular, if the aggregation is strictly mask-narrowing, 
> > that is all
> > component routes of the aggregate have a more specific 
> prefix than the
> > aggregate, then loop-free routing is guaranteed even if all 
> > the AS paths in
> > the component routes are ignored and we just reset the 
> > aggregate route's
> > AS path to nothing (you used to have to throw 
> > ATOMIC_AGGREGATE in there to
> > make this strictly correct, but I understand even this is 
> > being deprecated).
> > Doing the fancier thing may provide useful policy information 
> > for downstream
> > route recipients, but providing or not providing that 
> > information is a choice
> > for the aggregator which has no effect on the correctness of 
> > the protocol.
> > Because of this most routers have a knob which tells them to 
> > not bother
> > with the fancy aggregation of AS path information at all, and 
> > in fact many
> > users get this done while avoiding any command mentioning 
> > "aggregate" by
> > doing the same thing solely with readvertisement policy, 
> creating the
> > aggregate route as a static with reject next hop and 
> > readvertising this
> > while suppressing readvertisement of the matching 
> > more-specifics.  None
> > of this really conforms to the AS path aggregation rules in the
> > specification, but all of it produces loop-free routing anyway.
> > 
> > The exception to this occurs when one (or more) of the routes being
> > aggregated is a prefix match for the aggregate route.  While you can
> > still ignore the AS paths on more specific routes in this 
> > case, guaranteeing
> > loop freedom demands that the aggregate AS path include all 
> > the AS numbers
> > in the path(s) of the matching prefix(es).  Currently, 
> however, there
> > is never more than one component route which is a prefix match for
> > the aggregate, so for loop-free routing it is sufficient to 
> advertise
> > the aggregate with the AS path of that route alone.  You can do this
> > solely with redistribution policy as well (readvertise the 
> route which
> > is a prefix match, but suppress all the more-specifics), so 
> > again it is
> > unnecessary to actually combine AS paths from multiple 
> routes for any
> > loop-avoidance purposes.
> > 
> > > I don't mind if the multi-path issues are kept out of the 
> > document. But
> > > if there is insistence to provide some guidance, I hoped 
> > that a general
> > > conceptual statement could be sufficient.
> > 
> > What you describe is a reasonable way to do this function, 
> but I think
> > the fact that it actually depends on the combination of 
> > component route
> > AS paths into the aggregate route's AS path for the purpose 
> > of ensuring
> > correct, loop-free routing, and that it can't be safely 
> > simulated by simple
> > redistribution policy, makes it unique enough to require more 
> > explanation
> > than just a conceptual statement.
> > 
> > Dennis Ferguson
> > 
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA19486 for <[e-mail]>; Wed, 2 Oct 2002 10:06:44 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id CF7E29124B; Wed,  2 Oct 2002 10:06:23 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90F089124D; Wed,  2 Oct 2002 10:06: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 712B79124B for <[e-mail]>; Wed,  2 Oct 2002 10:06:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 41C4F5DDB7; Wed,  2 Oct 2002 10:06:21 -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 94DD85DD93 for <[e-mail]>; Wed,  2 Oct 2002 10:06: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 KAA03767; Wed, 2 Oct 2002 10:06: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 KAA10058; Wed, 2 Oct 2002 10:06:19 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R736YR>; Wed, 2 Oct 2002 10:06:17 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Dennis Ferguson'" <[e-mail]>, Dimitry Haskin <[e-mail]>
Cc: "'Natale, Jonathan'" <[e-mail]>, [e-mail]
Subject: RE: issue 11 
Date: Wed, 2 Oct 2002 10:06: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

Dennis:

  The potential weakness to aggregation when AS-PATH list of component
routes
are left out of the aggregated route is that the downstream peers that
receive
the aggregate route have no knowledge of the real path taken from their
point to the origin of any component route and thus are unable to gaurantee
loop free routing from their point to any component route's destination. 

In the multi-path scenario, if we aggregate two, same prefix, different
AS-PATHS, different Next Hop, routes into one aggregate route we hit this
weakness. Do you agree?

My instinct is only to use multi-path in a localized manor, load balance
between two interfaces from one router to another, if we must load balance
between two interfaces to two separate routers, limit the amount of
divergence these routes define in their AS_PATH attributes. Perhaps have 1
router setup to multipath to 2 other routers in the same AS whose AS_PATH
entries are the same. Once we start diverging, we get into all kinds of
permutations on the AS_PATH issue, we have to use aggregation or we have to
perform more policy decisions on how to deal with this, etc.

Since BGP4 does not provide the ability to tell another peer that two routes
which have the same prefix and different attributes are to be treated as
multipath routes, we are stuck with information that is advertised to peers
that is suboptimal.  Perhaps this feature, should be added to a new draft
titled "BGP Multipath" that you can edit, since you have vast knowledge on
the subject.


Regards,
Ben

> -----Original Message-----
> From: Dennis Ferguson [mailto:[e-mail]]
> Sent: Tuesday, October 01, 2002 11:20 PM
> To: Dimitry Haskin
> Cc: 'Natale, Jonathan'; [e-mail]
> Subject: Re: issue 11 
> 
> 
> Dimitry,
> 
> > After all if a BGP speaker chooses to advertise a single 
> route even when
> > multiple component routes are used for local forwarding, 
> this in effect
> > constitutes an aggregation -- even if the aggregate and 
> components have
> > the same prefix. As such, it should comply with aggregation 
> rules that
> > have been defined to provide loop-free routing.
> 
> I think the problem with this is the assertion that the rules defined
> in the document for AS path aggregation (I'm looking at the 
> -17 document)
> are necessary to provide loop-free routing in any case other 
> than yours.
> Obtaining loop-free routing does not require combining AS paths in any
> current situation, and because of this most routers, and most users of
> routers, don't always do route aggregation as defined in the document.
> 
> In particular, if the aggregation is strictly mask-narrowing, 
> that is all
> component routes of the aggregate have a more specific prefix than the
> aggregate, then loop-free routing is guaranteed even if all 
> the AS paths in
> the component routes are ignored and we just reset the 
> aggregate route's
> AS path to nothing (you used to have to throw 
> ATOMIC_AGGREGATE in there to
> make this strictly correct, but I understand even this is 
> being deprecated).
> Doing the fancier thing may provide useful policy information 
> for downstream
> route recipients, but providing or not providing that 
> information is a choice
> for the aggregator which has no effect on the correctness of 
> the protocol.
> Because of this most routers have a knob which tells them to 
> not bother
> with the fancy aggregation of AS path information at all, and 
> in fact many
> users get this done while avoiding any command mentioning 
> "aggregate" by
> doing the same thing solely with readvertisement policy, creating the
> aggregate route as a static with reject next hop and 
> readvertising this
> while suppressing readvertisement of the matching 
> more-specifics.  None
> of this really conforms to the AS path aggregation rules in the
> specification, but all of it produces loop-free routing anyway.
> 
> The exception to this occurs when one (or more) of the routes being
> aggregated is a prefix match for the aggregate route.  While you can
> still ignore the AS paths on more specific routes in this 
> case, guaranteeing
> loop freedom demands that the aggregate AS path include all 
> the AS numbers
> in the path(s) of the matching prefix(es).  Currently, however, there
> is never more than one component route which is a prefix match for
> the aggregate, so for loop-free routing it is sufficient to advertise
> the aggregate with the AS path of that route alone.  You can do this
> solely with redistribution policy as well (readvertise the route which
> is a prefix match, but suppress all the more-specifics), so 
> again it is
> unnecessary to actually combine AS paths from multiple routes for any
> loop-avoidance purposes.
> 
> > I don't mind if the multi-path issues are kept out of the 
> document. But
> > if there is insistence to provide some guidance, I hoped 
> that a general
> > conceptual statement could be sufficient.
> 
> What you describe is a reasonable way to do this function, but I think
> the fact that it actually depends on the combination of 
> component route
> AS paths into the aggregate route's AS path for the purpose 
> of ensuring
> correct, loop-free routing, and that it can't be safely 
> simulated by simple
> redistribution policy, makes it unique enough to require more 
> explanation
> than just a conceptual statement.
> 
> Dennis Ferguson
> 


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA21788 for <[e-mail]>; Tue, 1 Oct 2002 23:20:46 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 71C88912BD; Tue,  1 Oct 2002 23:20:27 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4ADE49123F; Tue,  1 Oct 2002 23:20: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 F0EF591232 for <[e-mail]>; Tue,  1 Oct 2002 23:20:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id D2FCA5DE9D; Tue,  1 Oct 2002 23:20: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 449C25DE9A for <[e-mail]>; Tue,  1 Oct 2002 23:20:24 -0400 (EDT)
Received: from juniper.net (wawa.juniper.net [172.17.20.55]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g923Jom15848; Tue, 1 Oct 2002 20:19:50 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: exmh version 2.0.2 2/24/98
X-Exmh-Isig-CompType: repl
X-Exmh-Isig-Folder: lists/idr
To: "Dimitry Haskin" <[e-mail]>
Cc: "'Natale, Jonathan'" <[e-mail]>, [e-mail]
Subject: Re: issue 11 
In-reply-to: Your message of "Tue, 01 Oct 2002 12:05:35 EDT." <001e01c26964$63c3fd30$01ffff0a@QUICK> 
Mime-Version: 1.0
Content-Type: text/plain
Date: Tue, 01 Oct 2002 20:19:50 -0700
From: Dennis Ferguson <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Dimitry,

> After all if a BGP speaker chooses to advertise a single route even when
> multiple component routes are used for local forwarding, this in effect
> constitutes an aggregation -- even if the aggregate and components have
> the same prefix. As such, it should comply with aggregation rules that
> have been defined to provide loop-free routing.

I think the problem with this is the assertion that the rules defined
in the document for AS path aggregation (I'm looking at the -17 document)
are necessary to provide loop-free routing in any case other than yours.
Obtaining loop-free routing does not require combining AS paths in any
current situation, and because of this most routers, and most users of
routers, don't always do route aggregation as defined in the document.

In particular, if the aggregation is strictly mask-narrowing, that is all
component routes of the aggregate have a more specific prefix than the
aggregate, then loop-free routing is guaranteed even if all the AS paths in
the component routes are ignored and we just reset the aggregate route's
AS path to nothing (you used to have to throw ATOMIC_AGGREGATE in there to
make this strictly correct, but I understand even this is being deprecated).
Doing the fancier thing may provide useful policy information for downstream
route recipients, but providing or not providing that information is a choice
for the aggregator which has no effect on the correctness of the protocol.
Because of this most routers have a knob which tells them to not bother
with the fancy aggregation of AS path information at all, and in fact many
users get this done while avoiding any command mentioning "aggregate" by
doing the same thing solely with readvertisement policy, creating the
aggregate route as a static with reject next hop and readvertising this
while suppressing readvertisement of the matching more-specifics.  None
of this really conforms to the AS path aggregation rules in the
specification, but all of it produces loop-free routing anyway.

The exception to this occurs when one (or more) of the routes being
aggregated is a prefix match for the aggregate route.  While you can
still ignore the AS paths on more specific routes in this case, guaranteeing
loop freedom demands that the aggregate AS path include all the AS numbers
in the path(s) of the matching prefix(es).  Currently, however, there
is never more than one component route which is a prefix match for
the aggregate, so for loop-free routing it is sufficient to advertise
the aggregate with the AS path of that route alone.  You can do this
solely with redistribution policy as well (readvertise the route which
is a prefix match, but suppress all the more-specifics), so again it is
unnecessary to actually combine AS paths from multiple routes for any
loop-avoidance purposes.

> I don't mind if the multi-path issues are kept out of the document. But
> if there is insistence to provide some guidance, I hoped that a general
> conceptual statement could be sufficient.

What you describe is a reasonable way to do this function, but I think
the fact that it actually depends on the combination of component route
AS paths into the aggregate route's AS path for the purpose of ensuring
correct, loop-free routing, and that it can't be safely simulated by simple
redistribution policy, makes it unique enough to require more explanation
than just a conceptual statement.

Dennis Ferguson


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA19059 for <[e-mail]>; Tue, 1 Oct 2002 22:12:52 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 52F1A91230; Tue,  1 Oct 2002 22:12:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CC6B912B9; Tue,  1 Oct 2002 22:12: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 AF60D91230 for <[e-mail]>; Tue,  1 Oct 2002 22:12:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 974235DE8C; Tue,  1 Oct 2002 22:12:31 -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 8AFDD5DE0D for <[e-mail]>; Tue,  1 Oct 2002 22:12: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 WAA55112; Tue, 1 Oct 2002 22:12:02 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Enke Chen <[e-mail]>
Cc: "Stephen Gill" <[e-mail]>, [e-mail]
Reply-To: [e-mail]
Subject: Re: Removing MED (New Issue 1.0) 
In-reply-to: Your message of "Tue, 01 Oct 2002 11:05:10 PDT." <[e-mail]> 
Date: Tue, 01 Oct 2002 22:12:02 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Enke Chen writes:
> Steve,
> 
> > From: "Stephen Gill" <[e-mail]>
> > To: "'Enke Chen'" <[e-mail]>,
> > 	"'Natale, Jonathan'" <[e-mail]>
> > Cc: <[e-mail]>
> > Subject: RE: Removing MED (New Issue 1.0) 
> > Date: Tue, 1 Oct 2002 13:01:04 -0500
> > 
> > Humm. I thought with a missing MED it was prefereable to be treated as
> > worst not as 0.
> 
> It was changed a long time ago. Please see the following text in
> Sect. 9.1.2.2 of the draft:
> 
>       In the pseudo-code above, MED(n) is a function which returns the
>       value of route n's MULTI_EXIT_DISC attribute. If route n has no
>       MULTI_EXIT_DISC attribute, the function returns the lowest
>       possible MULTI_EXIT_DISC value, i.e. 0.
> 
> -- Enke
> 
> >  Cisco treats a missing med as 0, and I think Juniper
> > treats it as worst.  Cisco has a knob to change this: bgp bestpath
> > missing-as-worst.  
> > 
> > -- steve


If Juniper treats missing MULTI_EXIT_DISC as worst and Cisco has a
knob to treat missing MULTI_EXIT_DISC as worst, then IMHO we should
change the spec to say that MED(n) returns the largest value possible
is MULTI_EXIT_DISC is missing since this has better loop suppression
bahaviour if the placement of MULTI_EXIT_DISC removal is moved in its
position in the flow from Adj-In-RIB to Loc-RIB to Adj-Rib-Out.  In
other words, no matter where the removal takes place, we are loop free
without special rules about comparing EBGP before MED removal and then
IBGP after MED removal.  The only argument for MED(n) going to zero
for missing MULTI_EXIT_DISC was that Cisco routers did that (and
change would pose an operational issue if there wasn't a knob to
facilitate the change).

Note that when explicitly jamming a MULTI_EXIT_DISC value, such as
zero, the issue of where in the decision process the MULTI_EXIT_DISC
learned from the EBGP peers could still be used becomes a concern
again.  Unfortunately these implementation hints are necessary to
remain loop free and so its hard to declare them out of scope, unless
we forbid changing MULTI_EXIT_DISC and just allow it to be removed
(which does not reflect current practice).

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 UAA15978 for <[e-mail]>; Tue, 1 Oct 2002 20:51:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1CD8F91231; Tue,  1 Oct 2002 20:50:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4BA5912B9; Tue,  1 Oct 2002 20:50: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 3E6B491231 for <[e-mail]>; Tue,  1 Oct 2002 20:50:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 238AB5DE7E; Tue,  1 Oct 2002 20:50: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 A79535DE7D for <[e-mail]>; Tue,  1 Oct 2002 20:50:39 -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 UAA54081; Tue, 1 Oct 2002 20:50:16 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Reply-To: [e-mail]
Subject: was Re: issue 32.2
Date: Tue, 01 Oct 2002 20:50:16 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Yakov asked my to repost my private reply to him presumably since my
name is in the middle somewhere proposing text but I think that the
final text proposed by Yakov is fine.  I also suggested that silence
since Yakov's suggestion was made may indicate consensus.  (I hope).

Curtis


------- Forwarded Message

Return-Path: [e-mail]
Delivery-Date: Tue Oct  1 13:35:06 2002
Return-Path: <[e-mail]>
Received: from localhost (localhost.fictitious.org [127.0.0.1])
	by workhorse.fictitious.org (8.9.3/8.9.3) with ESMTP id NAA50252
	for <curtis@localhost>; Tue, 1 Oct 2002 13:35:06 -0400 (EDT)
	(envelope-from [e-mail])
Received: from gateway2.fictitious.org [209.150.1.252]
	by localhost with POP3 (fetchmail-5.5.1)
	for curtis@localhost (single-drop); Tue, 01 Oct 2002 13:35:06 -0400 (EDT)
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129])
	by gateway2.fictitious.org (8.11.6/8.11.6) with ESMTP id g8UGri893246
	for <[e-mail]>; Mon, 30 Sep 2002 12:53:44 -0400 (EDT)
	(envelope-from [e-mail])
Received: from juniper.net (garnet.juniper.net [172.17.28.17])
	by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g8UGqVm44877
	for <[e-mail]>; Mon, 30 Sep 2002 09:52:31 -0700 (PDT)
	(envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: issue 32.2 
In-Reply-To: Your message of "Mon, 30 Sep 2002 10:42:15 EDT."
             <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Mon, 30 Sep 2002 09:52:31 -0700
From: Yakov Rekhter <[e-mail]>
X-UIDL: ;2_"!*k(!!!T5"!Z8+"!

Curtis,

> >   
> >   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 t
ha
> > t
> >   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 conformin
> > g
> >       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.
> > 
> 
> 
> Looks good to me.  If silence supposed to imply agreement, we seem to
> have consensus.

Could you please repost it to the IDR mailing list.

Thanks !!!

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 UAA14999 for <[e-mail]>; Tue, 1 Oct 2002 20:27:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3504C912B5; Tue,  1 Oct 2002 20:26:33 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2967912B9; Tue,  1 Oct 2002 20:26: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 99926912B5 for <[e-mail]>; Tue,  1 Oct 2002 20:26:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 8285F5DE78; Tue,  1 Oct 2002 20:26:31 -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 709425DE7B for <[e-mail]>; Tue,  1 Oct 2002 20:26: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 UAA53715; Tue, 1 Oct 2002 20:24:47 -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]
Reply-To: [e-mail]
Subject: Re: issue 11 
In-reply-to: Your message of "Tue, 01 Oct 2002 09:42:55 PDT." <[e-mail]> 
Date: Tue, 01 Oct 2002 20:24:46 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Alex Zinin writes:
> Yakov,
> 
> >> It would be smarter to assign the next hop address to a virtual
> >> interface (e.g. Loopback Interface address) thus if the peer has two 
> >> physical interfaces to current router, there is only one route.
> >> Thus the load balancing issue is transparent to the BGP routing
> >> and only obvious in the forwarding plane. 
> 
> > And if it is transparent to the BGP routing, then there is no
> > need to have it in the base spec. Agreed ?
> 
> Note that what Ben described above is not BGP multipath, but
> load-balancing based on IGP multipath, and right, _this_ one doesn't
> belong in the spec.
> 
> Alex



Alex,

In addition to IGP multihop, there are two cases of BGP multipath.

In IGP multihop there is one BGP advertisement but to ways to reach th
BGP NEXT_HOP via the IGP.

In one case of BGP multihop, two (or more) IBGP routers peering with
the same external AS have equal routes to a destination and are an
equal cost away from a third router.  BGP multihop is applicable to
that third router.  Without BGP multihop, BGP would normally pick the
BGP NEXT_HOP of the advertisement from only one of those IBGP peers
(using BGP Identifier) and use that.  The IGP lookup would yield one
next hop.  With BGP multihop, BGP uses the BGP NEXT_HOP of both
advertisements.  Each BGP NEXT_HOP has a different IGP next hop (one
or more IGP next hop).

The second case is where all of the candidates routes for BGP
multipath are external.  Seldom does IGP multipath come into play for
EBGP (odd tunneled EBGP mutlihop cases maybe).  Typically the load is
split among two (or more) routers in the same AS.

If in EBGP multipath you split among routers in difference AS, an
aggregate should be formed.  This is still prior to the IGP cost rule
in the route selection.

Normally one would not combine IBGP and EBGP in multihop given that
the decsion point for multihop is after "d" in 9.1.2.2.  If the
multihop decision was prior to "d", then two routers each with an
external peering would forward some of the traffic to each other and
for some src/dst pairs, they'd form a loop.  [So don't do that!]

This is getting to be a lot to add to the base spec.  I hope we've
convinced you that we should put it in another document.

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 TAA12981 for <[e-mail]>; Tue, 1 Oct 2002 19:38:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 78E53912BA; Tue,  1 Oct 2002 19:37:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 345A9912C2; Tue,  1 Oct 2002 19:37: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 7E8A5912BA for <[e-mail]>; Tue,  1 Oct 2002 19:36:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 64BD75DE78; Tue,  1 Oct 2002 19:36: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 8D6695DE30 for <[e-mail]>; Tue,  1 Oct 2002 19:36: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 TAA53015; Tue, 1 Oct 2002 19:36:25 -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 "Mon, 30 Sep 2002 11:20:34 PDT." <[e-mail]> 
Date: Tue, 01 Oct 2002 19:36:25 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Alex Zinin writes:
> 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


Alex,

Two prior issues were use of "shortest AS path" and a detail of "MED
handling".  The former is in there, the latter is still a little
deficient.

The prior issue was inclusion of "shortest AS path" which wasn't in
earlier BGP-4 but Cisco has always done.  It is now in there.  It
reflects what Cisco does.  Everyone else seems to have a "Cisco BGP
compatibility" knob to enable it (typically enabled by default).

The other issue was MED handling.  In "5.1.4 MULTI_EXIT_DISC":

   A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
   which allows the MULTI_EXIT_DISC attribute to be removed from a
   route. This MAY be done prior to determining the degree of preference
   of the route and performing route selection (decision process phases
   1 and 2).

   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over an external
   link.  If it does so, it shall do so prior to determining the degree
   of preference of the route and performing route selection (decision
   process phases 1 and 2).

This doesn't sufficiently address the issue.

The MED step in the decision process is (in 9.1.2.2):

      c) Remove from consideration routes with less-preferred
      MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
      between routes learned from the same neighboring AS. Routes which
      do not have the MULTI_EXIT_DISC attribute are considered to have
      the lowest possible MULTI_EXIT_DISC value.

      This is also described in the following procedure:

            for m = all routes still under consideration
                for n = all routes still under consideration
                    if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
                        remove route m from consideration

      In the pseudo-code above, MED(n) is a function which returns the
      value of route n's MULTI_EXIT_DISC attribute. If route n has no
      MULTI_EXIT_DISC attribute, the function returns the lowest
      possible MULTI_EXIT_DISC value, i.e. 0.

      Similarly, neighborAS(n) is a function which returns the neighbor
      AS from which the route was received.

The problem is that a route loop can be formed.

To avoid the route loop, two suggestions were made (2-3 years ago and
nothing was done).  One was to make MED(n) return infinity if there
was no MULTI_EXIT_DISC.  The other was to consider MULTI_EXIT_DISC in
the decision process only for the purpose of selecting among the EBGP
peers, then remove MULTI_EXIT_DISC, then use that best route in
comparisons to IBGP learned routes.

The statement in 5.1.4 "This MAY be done prior to determining the
degree of preference of the route and performing route selection
(decision process phases 1 and 2)" does not sufficiently address this.
This implies that you MAY also remove after route selection, in which
case field experience indicates you WILL get burned (unless you know
about the caveat above).  Initially this came up as an
interoperability issue but later it was proven (in the field) that a
Cisco and another Cisco could form a route loop until Cisco made this
change.

Additional wording is needed either in 5.1.4 or in 9.1.2.2.  I suggest
we put a forward reference in 5.1.4:

   [...]. This MAY be done prior to determining the degree of preference
   of the route and performing route selection (decision process phases
   1 and 2).  See section 9.1.2.2 for necessary restricts on this.

Then in 9.1.2.2 add a clarificatio to the neighborAS(n) function and
add to the existing text.

      Similarly, neighborAS(n) is a function which returns the
      neighbor AS from which the route was received.  If the route is
      learned via IBGP, it is the neighbor AS from which the other
      IBGP speaker learned the route, not the internal AS.

      If a MULTI_EXIT_DISC attribute is removed before redistributing
      a route into IBGP, the MULTI_EXIT_DISC attribute may only be
      considered in the comparison of EBGP learned routes, them
      removed, then the remaining EBGP learned route may be compared
      to the remaining IBGP learned routes, without considering the
      MULTI_EXIT_DISC attribute for those EBGP learned routes whose
      MULTI_EXIT_DISC will be dropped before advertising to IBGP.
      Including the MULTI_EXIT_DISC of an EBGP learned route in the
      comparison with an IBGP learned route, then dropping the
      MULTI_EXIT_DISC and advertising the route has been proven to
      cause route loops.

The loop is the classic I prefer your and you prefer mine problem.  It
occurs when the router is configured to remove MULTI_EXIT_DISC and
advertise out a route so other routers can use IGP cost to select the
best route.  If two routers do this, as soon as they hear the route
with no MULTI_EXIT_DISC from the other peer they start forwarding
toward that peer but they continue to advertise to it since others
IBPG peers are expected to select among the MULTI_EXIT_DISC free IBGP
learned routes using the next step in the decision process, IGP cost.

In this case, what you want is each router to prefer its own EBGP
route, even though it has a MULTI_EXIT_DISC and the IBGP learned route
from the same neighbor AS has had its MULTI_EXIT_DISC stripped off (or
didn't have one, you can't tell which it is).  You then want all of
the IBGP peers with a MULTI_EXIT_DISC free route from that AS, or that
have stripped the MULTI_EXIT_DISC to form one, to advertise them.
Others in the AS will then use IGP cost to further resolve which exit
point to use.  It make a difference when the route is the aggregate
route of another major provider.  IGP cost yields what ISPs call "hot
potatoe routing" and MED selects among multiple heavily loaded
provider interconnects.

[Aside: Having a missing MULTI_EXIT_DISC default to infinity would do
exactly what the ISPs want it to do in the first place and be a lot
easier to explain but we didn't fix that 2-3 years ago when the issue
came up even though we had WG consensus that it was the right thing to
do.  The authors didn't act on it at the time (because Cisco didn't do
it that way and the authors preferred to sit on the draft).  At this
point we might as well adequately document what we ended up with....
End of soapbox.  I don't take myself all that seriously so others
shouldn't either.  :-)]

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 TAA12402 for <[e-mail]>; Tue, 1 Oct 2002 19:24:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 04396912AA; Tue,  1 Oct 2002 19:23:59 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3677912AB; Tue,  1 Oct 2002 19:23: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 10288912AA for <[e-mail]>; Tue,  1 Oct 2002 19:23:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id DF6D65DE74; Tue,  1 Oct 2002 19:23:51 -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 867655DD93 for <[e-mail]>; Tue,  1 Oct 2002 19:23:49 -0400 (EDT)
Received: (from andrewl@localhost) by demiurge.exodus.net (8.9.3+Sun/8.9.3) id QAA00568; Tue, 1 Oct 2002 16:20:54 -0700 (PDT)
Date: Tue, 1 Oct 2002 16:20:54 -0700
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: BGP Base Draft - Issue List v1.2
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="PEIAKu/WMn1b1Hv9"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: [e-mail]
Precedence: bulk

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

Hello all,

Attached is the updated Issue List, and a Changelog.  To summarize the
changes we have:  Added 3 issues, updated 34 and brought 18 issues to
consensus.  We're close to consensus on a couple of others too.

Andrew

--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="Issue_List-v1.2.txt"

2002-10-01
v1.2

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 "Unfeasible 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
61) Next Hop for Redistributed Routes

============================================================================
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
9) Reference to RFC904 - EGP Protocol
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 (closed in favor of issue 61)
15) Grammer Fix
16) Need ToC, Glossary and Index
17) Add References to other RFC-status BGP docs to base spec.
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
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.2) BGP Desitnation-based Forwarding Paradigm
33) Add "Optional Non-Transitive" to the MED Section
35) Fix Typo
36) Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary
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
44) Section 6.2: OPEN message error handling
50) FSM Timers 
51) FSM ConnectRetryCnt
52) Section 3: Keeping routes in Adj-RIB-In
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
59) Section 4.3 - Move text
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 opinions expressed on this were 7 in favor, 4 against.

----------------------------------------------------------------------------
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: 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: Consensus on the change, but we still need the text
Change: Potentially
Summary:
 Get rid of section 9.2.1.3 ("Jitter").
 Move the text to an Appendix: "BGP Timers"
 Expand text to indicate that jitter applies to all timers, including 
  ConnectRetry.
 
 We still need specific text for the Appendix.

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"

Yakov agreed with making some changes and suggested that we make sure
that jitter is applied to all timers.  Specifically, he proposes we
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.

Jonathan, the original commentor, agreed with Yakov's suggestion.

In a follow-up to this issue, there was a question raised about the values
we have specified for timers in the document. Specifically:

    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 ?

Curtis responded to this with:

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.

And Jonathan replied with this information about current practice:

 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.

So the question that arises from this followup, is how does this question 
affect the text of the appendix on jitter?

Curtis replied that we need to only state that jitter should be applied
to all timers.  Whether a vendor does so or not is a minor deficiency and
does not bear on interoperability.  Therefore, specifying exact details
are not necessary.

After Jonathan's response Curtis and Jonathan agreed that jitter should
be added to all timers and that we should state so in the text.

----------------------------------------------------------------------------
9) Reference to RFC904 - EGP Protocol
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
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.

Yakov agreed to this, and Jonathan seconded it.

----------------------------------------------------------------------------
10) Extending AS_PATH Attribute
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: 
  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.

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. 

Yakov stated that:

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:

After some discussion, Yakov's proposed text's last sentance was dropped
and we arrived at:

    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. 

In response to Andrew's clarification question to the list, Curtis
responded:

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.
     
After some additional discussion, it was decided that we add "and may
choose to log an error locally." to the end of Yakov's text.

Also, we agreed to change "may choose not to advertize..." to 
"MUST NOT advertise...".

So the text 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.

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

Yakov replied to this that:

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.

The "issue 11" thread this was being discussed in then digressed to the
topic, now covered in issue 11.3.

Ben readdressed the original issue with this input:

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

Ben's comment has not yet received a reponse.

We are still working on consensus on this. 

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

This text will be added to the -18 version, and since there were no
objections, this issue has been moved to consensus.

----------------------------------------------------------------------------
11.2) Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: This issue has been folded into issue 32.2.  Please see that 
 text for more information.

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.

Since this issue and issue 32.2 are very similar, and 32.2 is at consensus,
this issue has also been moved to consensus in favor of 32.2.

----------------------------------------------------------------------------
11.3) Documenting IBGP Multipath
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: The documenting of IBGP Multipath is left to another Internet 
 Draft.  The consensus is that it should not be in the base spec.

 However, we are reconsiderting this at the moment.

Discussion:

This thread began in the "issue 11" discussion.  In it it was proposed
that:

    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.

After much discussion back and forth, it was agreed that documenting
IBGP Multipath behavior is a good thing.  However, it is something that
belongs in another draft.

Alex opened this issue up again.  There were a flury of responses, most
all of them agreeing with the original consensus that we should document
this feature in a different draft, since it doesn't affect the core
interoperatbilty requirements, and we want to advance the spec in a 
timely manner.

Alex persisted in his assertion that this belongs in the base specification.
Right now, the issue is still open.

This discussion later expanded in scope to include all BGP multipath.

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

For related discussion see issue 61.

----------------------------------------------------------------------------
14) NEXT_HOP to Internal Peer
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: Closed in favor of issue 61.

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.

Since this issue and issue 61 are basically the same, except 61 proposes
text, we'll close this issue in favor of 61.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
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.

Yakov responded that this will be added to the -18 review.

Jonathan agreed.

----------------------------------------------------------------------------
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: Consensus
Change: No
Summary: The consensus is that additional references to RFC2385 are not
  necessary.

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.

Yakov replied to this:

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.

Ishi agreed with Yakov.  Jonathan disagreed since he thought no one uses
BGP auth.  Ishi replied that there are lots of people who do use it.
Jonathan replied with a clarification question: "Who uses *BGP's own* 
authentication mechanisms???"  Ron Bonica replied that they use BGP auth.
There was some additional discussion over who implements simple password
authentication vs. MD5.

After further discussion, the consensus seems to be that we should leave
the text as it is for the reasons Yakov pointed out.  There was some
discussion over opening a new issue to discuss deprecating the BGP
auth mechanism discussed in RFC1771 in favor of the mechanism in RFC2385.

The issue of Depricating BGP AUTH is discussed in issue 62.

----------------------------------------------------------------------------
22) Scope of Path Attribute Field
----------------------------------------------------------------------------
Status: Consensus
Change: No
Summary: This is already being covered by text that has been added to
 the -18 draft.

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

Yakov replied to this that:

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.

There were no objections to this statement, so this issue has been moved
into consensus.

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

Picking this thread up again, Yakov argued:

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.

Jonathan agreed with this statement, but Ben argued that the text in 
section 3 is insufficent the way it is currently written.   After
two iterations, Ben and Yakov agreed on this formulation for an
update to section 3.1:

   Changing the attributes 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.

Jeff objected somewhat to the wording, since, because of a bgp route
is defined as a <path attribute, NLRI> pair, changing either part of
that pair, by definition, changes the route.  He acknowledged that
this might fall under the category of implementation detail.

----------------------------------------------------------------------------
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: Consensus
Change: No
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. 

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.

Yakov replied to this that he would suggest we keep things as is, since
the purpose is to document current implementations.

This did not meet with any objections, so this issue has been moved into
consensus.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
Summary:  
  Add:

  "in case they become resolvable" after the last sentence on p. 46.

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"

Yakov responded that:

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.

Yakov also responded that:

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.

Jonathan, who was the original commentor, agreed with both the changed
text and the clarity of section 3.

----------------------------------------------------------------------------
30) Mention Other Message Types
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Add a reference to RFC2918 at the end of the type code list.

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.

Yakov replied that:

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.

Jonathan agreed with this change.  This issue has been moved to consensus.

----------------------------------------------------------------------------
31) Add References to Additional Options
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: Consensus to add:

   [RFC2842] defines another Optional Parameter.

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.

Yakov replied that:

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.

The original poster agreed with this modification.  This issue is at 
consensus.

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

  This is partly addressed in the 32.1 text with the addition of a RFC904
  reference to EGP ORIGIN type.

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

Yakov replied that an EGP reference will be added (see issue 9).

Yakov also stated that he doesn't see what is wrong with the current text,
and suggsted we keep it.  This includes leaving out any reference to the
status of the EGP spec.  He sees that it is clear from context that we
are talking about "the EGP" [RFC904].

----------------------------------------------------------------------------
32.1) EGP ORIGIN Clarification
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: 
 Change section 5.1.1.  Text is still being worked out.

   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.

 Consensus 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]


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.

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.

After some further discussion, we have this text on the table:

   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.

Jonathan suggested that we change "propagate this information" to
"forward this route".  He also mentioned that he would prefer something
more explicit instead of/in addition to "The attribute shall be included
in the UPDATE messages of all BGP speakers that choose to propagate this
information to other BGP speakers." such as "other speakers do not
change the ORIGIN value."

On the issue of making the EGP ORIGIN type more clear Andrew proposed:

 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.

This met with a number of agreements.

----------------------------------------------------------------------------
32.2) BGP Desitnation-based Forwarding Paradigm
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: After much discussion, this is the consensus:
 This text in the current draft:

     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.

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: Consensus
Change: Yes
Summary: Add "Optional Non-Transitive" to MED Section
         Add "well-known mandatory" to the NEXT_HOP Section

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.

Yakov agreed to make this change in -18.

Jonathan replied that:

5.1.3 NEXT_HOP also, it is missing " well-known mandatory".

Yakov also agreed to make this change.

----------------------------------------------------------------------------
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: Consensus
Change: Yes
Summary: This change requires a glossary. Yakov has committed to having
 a section where commonly used terms are defined in draft 18, so this
 issue is at consensus.

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.

Yakov replied:

will be added to the section "Definition of commonly used terms" in -18
version.

----------------------------------------------------------------------------
37) Combine "Unfeasible Routes" and "Withdrawn Routes"
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: No definition extant for "Unfeasible 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.
 
Ishi replied to this that he thought that we could combine the two terms,
since there is limited difference from an implementation standpoint.

Yakov replied:

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.

Ishi replied that he was convinved, and that the terms should stay
seperate.

Andrew asked the list if we should define these terms in the "commonly
used terms" section in draft -18.

Ben replied that if we use them alot, we should define them, and if not
local definitions will suffice.

There was some back and forth about the necessity of defining terms which
should be obvious. 

mrr actually checked the doc to see if we were consistantly using the 
terms, and found:

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:

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

Yakov agreed to drop the third and fourth parentheses in the -18 version.

Jonathan replied to this:

Disagree, the text if fine the way it is, except you need to change
"shorted" to "shorter".

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

There was some additonal discussion on this point.  Most of it was along
the lines of extracting what was really implemented and supported among
various vendors.  The conclusion was the same.

----------------------------------------------------------------------------
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: Consensus
Change: No
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.  They were later reminded that the base
  behavior is acceptable, and agreed.

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.

Yakov replied to this with:

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.

The original poster, Jonathan, agreed with this.  This issue moves to
consensus.

----------------------------------------------------------------------------
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: Text has been proposed to describe the general process of 
 a BGP connection comming up.

Discussion:

Alex suggsted we explicity define:

   - processing of incoming TCP connections (peer lookup, acceptance,
     FSM creation, collision control,)

Curtis later proposed this text:

  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.

Jonathan pointed out that there was an inaccuracy in the proposed text.
Curtis replied with this:

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.

Tom replied that:

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

And Curtis suggested that:

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.

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: Consensus
Change: Yes
Summary: 
 Replace:

   Path segment length is a 1-octet long field containing
   the number of ASs in the path segment value field.

 With:
 
   Path segment length is a 1-octet long field containing
   the number of ASs (not the number of octets) in the path
   segment value field.

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.

Yakov proposed this change:

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.

Jonathan offered this text:

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

Jeff replied that he prefered Yakov's text, but without the "but".  Yakov
agreed to that.  Andrew also agreed, and asked if there were any objections
to moving this issue into consensus.  There were no objections.

----------------------------------------------------------------------------
56) Section 6 - BGP Error Handling
----------------------------------------------------------------------------
Status: Consensus
Change: Yes
Summary: There are a variety of updates to the text that are best described
 in the discussion section.

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

There have been no objections to the updates listed above.  This issue
seems to have reached a happy ending, so it has been moved into 
consensus.

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: After some discussion, it would seem that the group is converging
 on an opinion that ATOMIC_AGGREGATE should be moved to an informational
 status.

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.

Yakov responded to this, saying that he thought these changes were 
reasonable, and unless there were objections, they would be adopted.

Ishi strongly agreed with the changes.

Curtis stated that:

 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.

 And suggested that we remove the MUSTs and indicated that this is only
 informational.

Jeff replied that:

 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.

Jonathan agreed with Curtis' idea that we should just move ATOMIC_AGGREGATE
to informational.

Curtis proposed this text:

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

Yakov was fine with this text.

So at this point we're trying to achieve consensus with the text Curtis
has proposed.

----------------------------------------------------------------------------
59) Section 4.3 - Move text 
----------------------------------------------------------------------------
Status: Consensus
Change: Yes (minimal)
Summary: Update indentation to allow a new "subsection" heading. Otherwise
 no change.

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.

Yakov agreed to update the indentation.

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. 

After Yakov's response and a posting to the list asking that this be moved
to consensus, there were no objections, so this is moved to 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.

Issue 14 closed in favor of this issue.

In response to Yakov's call for input, Michael responded that:

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 (text is above.)

----------------------------------------------------------------------------
62) Deprecate BGP Authentication Optional Parameter from RFC1771
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: We are at consensus, in that we agree that we should deprecate
 the BGP Authentication Optional Parameter as described in RFC1771 in
 favor of the mechanism described in RFC2385.  We do not have new text for
 the draft yet, of if we are going to pull the reference entirely.

Discussion:

This discussion started in issue 21: Authentication Text Update.

This topic has come up before (July timeframe), but was recently refreshed
in the context of issue 21.  It began with some questions to the list
as to who used what sort of authentication mechanisms.  From the
responses it was clear that MD5 (RFC2385) was the prefered method.

Eric Gray's message helps to flesh this out:

        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

To this Yakov responded:

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.

There have been no responses to Yakov's question.

There seems to be a consensus that, since it is little used, and since
there are better mechanisms, namely MD5 authentication, we should 
deprecate the BGP Authentication Optional Parameter from RFC1771.
 
----------------------------------------------------------------------------
63) Clarify MED Removal Text
----------------------------------------------------------------------------
Status: No Consensus
Change: Potentially
Summary: There was text suggested, but no discussion.

Discussion:

This discussion began when Jonathan posted a question to the list:

In reference to:

"A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
 which allows the MULTI_EXIT_DISC attribute to be removed from a
 route"

 Does anybody know how this can be done in IOS???  Looks like it cannot.

 Juniper???

 Other code???

 Change to "SHOULD"???

Enke responded that:

As the MED value is treated as zero when the MED attribute is missing,
removing the MED attribute is really equivalent to setting the value to
zero. Based on this logic, one can argue that "MED removal" is supported
by multiple vendors.
 
However, I do see that the current text can be consolidated and cleaned up:
 
------------------------
5.1.4 MULTI_EXIT_DISC

   ...
      
   A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
   which allows the MULTI_EXIT_DISC attribute to be removed from a
   route. This MAY be done prior to determining the degree of preference
   of the route and performing route selection (decision process phases
   1 and 2).
 
   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over an external
   link.  If it does so, it shall do so prior to determining the degree
   of preference of the route and performing route selection (decision
   process phases 1 and 2).

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

How about this:

   A BGP speaker MUST implement a mechanism based on local configuration
   which allows the value of MULTI_EXIT_DISC attribute of a received route  
   to be altered. This shall be done prior to determining the degree of
   preference of the route and performing route selection (decision process
   phases 1 and 2).

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

In responding to a question, Enke also added:

> Humm. I thought with a missing MED it was prefereable to be treated as
> worst not as 0.

It was changed a long time ago. Please see the following text in
Sect. 9.1.2.2 of the draft:
 
      In the pseudo-code above, MED(n) is a function which returns the
      value of route n's MULTI_EXIT_DISC attribute. If route n has no
      MULTI_EXIT_DISC attribute, the function returns the lowest
      possible MULTI_EXIT_DISC value, i.e. 0.




--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="Changelog.txt"

CHANGELOG

----------------------------------------------------------------------------
v1.1.1 to v1.2
2002-09-25
----------------------------------------------------------------------------

Added:
11.3) Documenting IBGP Multipath
62) Deprecate BGP Authentication Optional Parameter from RFC1771
63) Clarify MED Removal Text

Updated:

1) IDR WG Charter
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
13) Next Hop for Originated Route
14) NEXT_HOP to Internal Peer
17) Add References to other RFC-status BGP docs to base spec.
21) Authentication Text Update
22) Scope of Path Attribute Field
24) Addition or Deletion of Path Attributes
27) Allow All Non-Destructive Messages to Refresh Hold Timer
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
36) Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary
37) Combine "Unfeasable Routes" and "Withdrawn Routes"
39) Redundant Sentance Fragments
40) Section 9.2.1.1 - Per Peer vs. Per Router MinRouteAdvertisementInterval
44) Section 6.2: OPEN message error handling
48) Explicitly Define Processing of Incomming Connections
55) Section 4.3 - Description of AS_PATH length
56) Section 6 - BGP Error Handling
58) Deprication of ATOMIC_AGGREGATE
59) Section 4.3 - Move text
61) Next Hop for Redistributed Routes
62) Deprecate BGP Authentication Optional Parameter from RFC1771
63) Clarify MED Removal Text

Moved to Consensus:

9) Reference to RFC904 - EGP Protocol
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
14) NEXT_HOP to Internal Peer (closed in favor of issue 61)
17) Add References to other RFC-status BGP docs to base spec.
21) Authentication Text Update
22) Scope of Path Attribute Field
27) Allow All Non-Destructive Messages to Refresh Hold Timer
29) State Why Unresolveable Routes Should Be Kept in Adj-RIB-In
30) Mention Other Message Types
31) Add References to Additional Options
32.2) BGP Desitnation-based Forwarding Paradigm
33) Add "Optional Non-Transitive" to the MED Section
36) Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary
44) Section 6.2: OPEN message error handling
55) Section 4.3 - Description of AS_PATH length
56) Section 6 - BGP Error Handling
59) Section 4.3 - Move text

----------------------------------------------------------------------------
v1.1 to v1.1.1
2002-09-24
----------------------------------------------------------------------------

Updated:

5) Direct EBGP Peers
   Added the "consensus" line in the actual issue description.
TOC) Added issue 61 to the table-of-contents.

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

--PEIAKu/WMn1b1Hv9--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA29351 for <[e-mail]>; Tue, 1 Oct 2002 14:20:00 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id AC477912A4; Tue,  1 Oct 2002 14:19:24 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7BE2B912A5; Tue,  1 Oct 2002 14: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 22C6A912A4 for <[e-mail]>; Tue,  1 Oct 2002 14:19:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 11ECB5DE39; Tue,  1 Oct 2002 14:19: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 CB8835DE1D for <[e-mail]>; Tue,  1 Oct 2002 14:19: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 OAA51135; Tue, 1 Oct 2002 14:18:57 -0400 (EDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Alex Zinin <[e-mail]>
Cc: Curtis Villamizar <[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 10:43:26 PDT." <[e-mail]> 
Date: Tue, 01 Oct 2002 14:18:57 -0400
From: Curtis Villamizar <[e-mail]>
Sender: [e-mail]
Precedence: bulk

In message <[e-mail]>, Alex Zinin writes:
> 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


I think it would be better off in another document because unlike OSPF
multipath:

  1.  You can go outside the AS and therefore cause huge differences
      in delay over the N available paths.  In OSPF the path delays
      differences are not as great although you can still mess up TCP.

  2.  We'd have to put in wording to forbid per packet multipath
      (there is an RFC on the pitfalls of doing a naive multipath
      implementation by Dave Thaler and Chris Hopps, RFC-2991).

  3.  If we mention BGP multipath and we don't forbid multipath which
      causes massive out of order delivery, then naive vendors are
      bound to implement it in the "considered harmful" way.

I think this one belongs in a separate draft but if you insist, we
have to do an adequate job of covering multipath since some forms of
it are harmful.  We should at least reference RFC-2991, include strong
wording about reordering and use of RFC-2991 techniques (src/dst
modulo-n-hash being the current favorite) to avoid it, and put limits
on what is and is not a reasonable place to put the "cost is equal"
decision in the route selection (it must be after IGP cost, step "e"
in 9.1.2.2).

Curtis


> 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 OAA29170 for <[e-mail]>; Tue, 1 Oct 2002 14:15:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id F04AC912A3; Tue,  1 Oct 2002 14:14:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1ED9912A4; Tue,  1 Oct 2002 14:14: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 9FE79912A3 for <[e-mail]>; Tue,  1 Oct 2002 14:14:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7E66A5DE23; Tue,  1 Oct 2002 14:14:40 -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 0C37E5DE1D for <[e-mail]>; Tue,  1 Oct 2002 14:14:40 -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 OAA24577; Tue, 1 Oct 2002 14:14: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 OAA15004; Tue, 1 Oct 2002 14:14:38 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7N7PJ>; Tue, 1 Oct 2002 14:14:37 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Alex Zinin'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 11
Date: Tue, 1 Oct 2002 14:14: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

Alex,
  The assumption with multi-path in my mind is that both routes have
equal "weight" in such attributes as AS-PATH (number of ASs)  
and so on, and the route selection criteria gets down to the BGP ID/Router
ID as the tie breaker. In this case, instead of picking one route we pick
both 
routes and add them to the Routing Table, creating the forwarding multi-path
issues. We here are discussing various permutations of this result that
could work or not work depending on specifics of the two routes. By adding
various rules to limit how we pick/allow the multiple routes, we reduce our
chances for hitting topological problems.

IMHO,
Ben

> -----Original Message-----
> From: Alex Zinin [mailto:[e-mail]]
> Sent: Tuesday, October 01, 2002 12:40 PM
> To: Natale, Jonathan
> Cc: 'Yakov Rekhter'; [e-mail]
> Subject: Re: issue 11
> 
> 
> Jonathan,
> 
>   At the minimum, the text would need to say what _BGP_ routes are
>   considered equal and can be used for load balancing. We don't
>   want the reader to mistakenly assume that, e.g., paths with
>   a longer AS_PATH can be used for load-balancing.
> 
> -- 
> Alex
> 
> Tuesday, October 01, 2002, 8:14:50 AM, Natale, Jonathan wrote:
> > If the routes are equal (e.g. only next hop is different) 
> and the speaker is
> > configured to load balance, the routes are used locally to 
> load balance.
> > But the same route would be advertised to other peers as 
> would be if load
> > balance was not configured.  So it is out of scope, just as 
> administrative
> > distance is out of scope (decided previously).
> 
> > Of course you could aggregate as described below, but I 
> don't see the point.
> 
> 
> > -----Original Message-----
> > From: Yakov Rekhter [mailto:[e-mail]] 
> > Sent: Tuesday, October 01, 2002 10:49 AM
> > To: Natale, Jonathan
> > Cc: [e-mail]
> > Subject: Re: issue 11 
> 
> > Jonathan,
> 
> >> I disagree, this does not reflect current implementations 
> that I know of.
> 
> > How do implementations that you know of handle this ?
> 
> > yakov.
> 
> >> Does anybody's implementation do this? 
> >> 
> >> -----Original Message-----
> >> From: Dimitry Haskin [mailto:[e-mail]] 
> >> Sent: Monday, September 30, 2002 6:39 PM
> >> To: 'Alex Zinin'; Yakov Rekhter
> >> Cc: [e-mail]
> >> Subject: RE: issue 11
> >> 
> >> 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 OAA28759 for <[e-mail]>; Tue, 1 Oct 2002 14:05:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 1798C912A2; Tue,  1 Oct 2002 14:05:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C70B0912A3; Tue,  1 Oct 2002 14:05: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 8855D912A2 for <[e-mail]>; Tue,  1 Oct 2002 14:05:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 753F15DE28; Tue,  1 Oct 2002 14:05:12 -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 CE3D05DE1D for <[e-mail]>; Tue,  1 Oct 2002 14:05:10 -0400 (EDT)
Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 33F6D449A2F; Tue,  1 Oct 2002 11:05:10 -0700 (PDT)
Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 23D517E6C1; Tue,  1 Oct 2002 11:05:10 -0700 (PDT)
To: "Stephen Gill" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Removing MED (New Issue 1.0) 
In-Reply-To: Message from "Stephen Gill" <[e-mail]>  of "Tue, 01 Oct 2002 13:01:04 CDT." <001401c26974$8751e810$1efdfe0a@scooby> 
Date: Tue, 01 Oct 2002 11:05:10 -0700
From: Enke Chen <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Steve,

> From: "Stephen Gill" <[e-mail]>
> To: "'Enke Chen'" <[e-mail]>,
> 	"'Natale, Jonathan'" <[e-mail]>
> Cc: <[e-mail]>
> Subject: RE: Removing MED (New Issue 1.0) 
> Date: Tue, 1 Oct 2002 13:01:04 -0500
> 
> Humm. I thought with a missing MED it was prefereable to be treated as
> worst not as 0.

It was changed a long time ago. Please see the following text in
Sect. 9.1.2.2 of the draft:

      In the pseudo-code above, MED(n) is a function which returns the
      value of route n's MULTI_EXIT_DISC attribute. If route n has no
      MULTI_EXIT_DISC attribute, the function returns the lowest
      possible MULTI_EXIT_DISC value, i.e. 0.

-- Enke

>  Cisco treats a missing med as 0, and I think Juniper
> treats it as worst.  Cisco has a knob to change this: bgp bestpath
> missing-as-worst.  
> 
> -- steve
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Enke
> Chen
> Sent: Tuesday, October 01, 2002 12:58 PM
> To: Natale, Jonathan
> Cc: [e-mail]; [e-mail]
> Subject: Re: Removing MED (New Issue 1.0) 
> 
> Jonathan:
> As the MED value is treated as zero when the MED attribute is missing,
> removing the MED attribute is really equivalent to setting the value to
> zero. Based on this logic, one can argue that "MED removal" is supported
> by multiple vendors.
> 
> However, I do see that the current text can be consolidated and cleaned
> up:
> 
> ------------------------
> 5.1.4 MULTI_EXIT_DISC
> 
>    ...
> 
>    A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
>    which allows the MULTI_EXIT_DISC attribute to be removed from a
>    route. This MAY be done prior to determining the degree of preference
>    of the route and performing route selection (decision process phases
>    1 and 2).
> 
>    An implementation MAY also (based on local configuration) alter the
>    value of the MULTI_EXIT_DISC attribute received over an external
>    link.  If it does so, it shall do so prior to determining the degree
>    of preference of the route and performing route selection (decision
>    process phases 1 and 2).
> 
> -------------------------
> 
> How about this:
> 
>    A BGP speaker MUST implement a mechanism based on local configuration
>    which allows the value of MULTI_EXIT_DISC attribute of a received
> route
>    to be altered. This shall be done prior to determining the degree of
>    preference of the route and performing route selection (decision
> process
>    phases 1 and 2).
> 
> --------------------------
> 
> -- Enke
> 
> > Message-ID:
> <[e-mail].c
> om>
> > From: "Natale, Jonathan" <[e-mail]>
> > To: [e-mail]
> > Subject: Removing MED (New Issue 1.0)
> > Date: Tue, 1 Oct 2002 13:23:16 -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:
> > 
> > "A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
> >  which allows the MULTI_EXIT_DISC attribute to be removed from a
> >  route"
> > 
> >  Does anybody know how this can be done in IOS???  Looks like it
> cannot.
> > 
> >  Juniper???
> > 
> >  Other code???
> > 
> >  Change to "SHOULD"???
> 



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA28676 for <[e-mail]>; Tue, 1 Oct 2002 14:03:36 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0FEFF912A1; Tue,  1 Oct 2002 14:03:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AEBA0912A2; Tue,  1 Oct 2002 14:03: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 5A251912A1 for <[e-mail]>; Tue,  1 Oct 2002 14:03:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 437A65DE28; Tue,  1 Oct 2002 14:03: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 3B4025DE23 for <[e-mail]>; Tue,  1 Oct 2002 14:03: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 OAA23916; Tue, 1 Oct 2002 14:03: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 OAA12710; Tue, 1 Oct 2002 14:03:07 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7N6YJ>; Tue, 1 Oct 2002 14:03:06 -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 11 
Date: Tue, 1 Oct 2002 14:03: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

Yakov,


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]]
> Sent: Tuesday, October 01, 2002 11:57 AM
> To: Abarbanel, Benjamin
> Cc: [e-mail]
> Subject: Re: issue 11 
> 
> 
> Ben,
> 
> > Jonathan:
> > 
> > See Below
> > 
> > > -----Original Message-----
> > > From: Natale, Jonathan [mailto:[e-mail]]
> > > Sent: Tuesday, October 01, 2002 11:15 AM
> > > To: 'Yakov Rekhter'; Natale, Jonathan
> > > Cc: [e-mail]
> > > Subject: RE: issue 11 
> > > 
> > > 
> > > If the routes are equal (e.g. only next hop is different) and 
> > > the speaker is
> > > configured to load balance, the routes are used locally to 
> > > load balance.
> > 
> > It would be smarter to assign the next hop address to a virtual 
> > interface (e.g. Loopback Interface address) thus if the 
> peer has two 
> > physical interfaces to current router, there is only one route.
> > Thus the load balancing issue is transparent to the BGP routing
> > and only obvious in the forwarding plane. 
> 
> And if it is transparent to the BGP routing, then there is no
> need to have it in the base spec. Agreed ?
> 
> Yakov.
>

Agreed,

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 NAA28429 for <[e-mail]>; Tue, 1 Oct 2002 13:58:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 38C36912A0; Tue,  1 Oct 2002 13:57:40 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0405E912A1; Tue,  1 Oct 2002 13:57: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 D9EE4912A0 for <[e-mail]>; Tue,  1 Oct 2002 13:57:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BE7B85DE60; Tue,  1 Oct 2002 13:57:38 -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 623105DE5B for <[e-mail]>; Tue,  1 Oct 2002 13:57:38 -0400 (EDT)
Received: from popserv3.redback.com (popserv3.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id D41D7449A21; Tue,  1 Oct 2002 10:57:36 -0700 (PDT)
Received: from redback.com (fall.redback.com [155.53.36.220]) by popserv3.redback.com (Postfix) with ESMTP id 227ED7E6C1; Tue,  1 Oct 2002 10:57:31 -0700 (PDT)
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Removing MED (New Issue 1.0) 
In-Reply-To: Message from "Natale, Jonathan" <[e-mail]>  of "Tue, 01 Oct 2002 13:23:16 EDT." <[e-mail]> 
Date: Tue, 01 Oct 2002 10:57:30 -0700
From: Enke Chen <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan:
As the MED value is treated as zero when the MED attribute is missing,
removing the MED attribute is really equivalent to setting the value to
zero. Based on this logic, one can argue that "MED removal" is supported
by multiple vendors.

However, I do see that the current text can be consolidated and cleaned up:

------------------------
5.1.4 MULTI_EXIT_DISC

   ...

   A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
   which allows the MULTI_EXIT_DISC attribute to be removed from a
   route. This MAY be done prior to determining the degree of preference
   of the route and performing route selection (decision process phases
   1 and 2).

   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over an external
   link.  If it does so, it shall do so prior to determining the degree
   of preference of the route and performing route selection (decision
   process phases 1 and 2).

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

How about this:

   A BGP speaker MUST implement a mechanism based on local configuration
   which allows the value of MULTI_EXIT_DISC attribute of a received route
   to be altered. This shall be done prior to determining the degree of
   preference of the route and performing route selection (decision process
   phases 1 and 2).

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

-- Enke

> Message-ID: <[e-mail]>
> From: "Natale, Jonathan" <[e-mail]>
> To: [e-mail]
> Subject: Removing MED (New Issue 1.0)
> Date: Tue, 1 Oct 2002 13:23:16 -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:
> 
> "A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
>  which allows the MULTI_EXIT_DISC attribute to be removed from a
>  route"
> 
>  Does anybody know how this can be done in IOS???  Looks like it cannot.
> 
>  Juniper???
> 
>  Other code???
> 
>  Change to "SHOULD"???



Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA27047 for <[e-mail]>; Tue, 1 Oct 2002 13:23:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 0B7689129E; Tue,  1 Oct 2002 13:23:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6E569129F; Tue,  1 Oct 2002 13:23: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 71D4F9129E for <[e-mail]>; Tue,  1 Oct 2002 13:23:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4CB5A5DE62; Tue,  1 Oct 2002 13:23: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 C07E55DE61 for <[e-mail]>; Tue,  1 Oct 2002 13:23:18 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12MQR>; Tue, 1 Oct 2002 13:23:18 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: Removing MED (New Issue 1.0)
Date: Tue, 1 Oct 2002 13:23:16 -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:

"A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
 which allows the MULTI_EXIT_DISC attribute to be removed from a
 route"

 Does anybody know how this can be done in IOS???  Looks like it cannot.

 Juniper???

 Other code???

 Change to "SHOULD"???


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA26652 for <[e-mail]>; Tue, 1 Oct 2002 13:15:01 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 493DF9129D; Tue,  1 Oct 2002 13:14:31 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CE129129E; Tue,  1 Oct 2002 13:14: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 7B0C49129D for <[e-mail]>; Tue,  1 Oct 2002 13:14:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 5B1795DE5E; Tue,  1 Oct 2002 13: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 B55125DE54 for <[e-mail]>; Tue,  1 Oct 2002 13:14:28 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12MNR>; Tue, 1 Oct 2002 13:14:27 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: Removing MED (New Issue 1.0)
Date: Tue, 1 Oct 2002 13:14:24 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2696D.FD318D30"
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_01C2696D.FD318D30
Content-Type: text/plain

In reference to:

"A BGP speaker MUST IMPLEMENT a mechanism based on local configuration

   which allows the MULTI_EXIT_DISC attribute to be removed from a

   route"

 

Does anybody know how this can be done in IOS???  Looks like it cannot.

 

Juniper???

 

Other code???

 

Change to "SHOULD"???


------_=_NextPart_001_01C2696D.FD318D30
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";}
h1
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	text-indent:-.25in;
	page-break-after:avoid;
	font-size:16.0pt;
	font-family:"Times New Roman";}
h2
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.8in;
	margin-bottom:.0001pt;
	text-indent:-.3in;
	page-break-after:avoid;
	font-size:12.0pt;
	font-family:Arial;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.StyleHeading1Arial12ptLeft, li.StyleHeading1Arial12ptLeft, div.StyleHeading1Arial12ptLeft
	{margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	text-indent:-.25in;
	page-break-after:avoid;
	font-size:12.0pt;
	font-family:"Times New Roman";
	font-weight:bold;}
p.StyleArial22ptBoldCentered, li.StyleArial22ptBoldCentered, div.StyleArial22ptBoldCentered
	{margin:0in;
	margin-bottom:.0001pt;
	text-align:center;
	font-size:20.0pt;
	font-family:Arial;
	font-weight:bold;}
span.EmailStyle19
	{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;}
 /* List Definitions */
 ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</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'>In reference to:</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>"A BGP speaker MUST IMPLEMENT a mechanism based on
local configuration</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; which allows the MULTI_EXIT_DISC attribute to be removed
from a</span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>&nbsp;&nbsp; route"</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'>Does anybody know how this can be done in IOS???&nbsp; Looks like
it cannot.</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'>Juniper???</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'>Other code???</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'>Change to "SHOULD"???</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C2696D.FD318D30--


Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA25570 for <[e-mail]>; Tue, 1 Oct 2002 12:49:01 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 56DCB91297; Tue,  1 Oct 2002 12:48:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2471191298; Tue,  1 Oct 2002 12: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 5D70591297 for <[e-mail]>; Tue,  1 Oct 2002 12:48:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 315685DE60; Tue,  1 Oct 2002 12:48: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 9A74A5DE5F for <[e-mail]>; Tue,  1 Oct 2002 12:48:17 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12MHA>; Tue, 1 Oct 2002 12:48:16 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: "'Alex Zinin'" <[e-mail]>, "Natale, Jonathan" <[e-mail]>
Cc: "'Yakov Rekhter'" <[e-mail]>, [e-mail]
Subject: RE: issue 11
Date: Tue, 1 Oct 2002 12:48:10 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Or it could say nothing or refer to it and say ~= ..."out of scope"

:-)

-----Original Message-----
From: Alex Zinin [mailto:[e-mail]] 
Sent: Tuesday, October 01, 2002 12:40 PM
To: Natale, Jonathan
Cc: 'Yakov Rekhter'; [e-mail]
Subject: Re: issue 11

Jonathan,

  At the minimum, the text would need to say what _BGP_ routes are
  considered equal and can be used for load balancing. We don't
  want the reader to mistakenly assume that, e.g., paths with
  a longer AS_PATH can be used for load-balancing.

-- 
Alex

Tuesday, October 01, 2002, 8:14:50 AM, Natale, Jonathan wrote:
> If the routes are equal (e.g. only next hop is different) and the speaker
is
> configured to load balance, the routes are used locally to load balance.
> But the same route would be advertised to other peers as would be if load
> balance was not configured.  So it is out of scope, just as administrative
> distance is out of scope (decided previously).

> Of course you could aggregate as described below, but I don't see the
point.


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Tuesday, October 01, 2002 10:49 AM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: issue 11 

> Jonathan,

>> I disagree, this does not reflect current implementations that I know of.

> How do implementations that you know of handle this ?

> yakov.

>> Does anybody's implementation do this? 
>> 
>> -----Original Message-----
>> From: Dimitry Haskin [mailto:[e-mail]] 
>> Sent: Monday, September 30, 2002 6:39 PM
>> To: 'Alex Zinin'; Yakov Rekhter
>> Cc: [e-mail]
>> Subject: RE: issue 11
>> 
>> 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 MAA25395 for <[e-mail]>; Tue, 1 Oct 2002 12:45:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 641F691296; Tue,  1 Oct 2002 12:44:49 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 298D891297; Tue,  1 Oct 2002 12:44: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 D8EEA91296 for <[e-mail]>; Tue,  1 Oct 2002 12:44:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id C32C95DE5B; Tue,  1 Oct 2002 12:44:47 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 99F5C5DE54 for <[e-mail]>; Tue,  1 Oct 2002 12:44:47 -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 17wQ8b-000Hyq-00; Tue, 01 Oct 2002 09:44:45 -0700
Date: Tue, 1 Oct 2002 09:42: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: 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,

>> It would be smarter to assign the next hop address to a virtual
>> interface (e.g. Loopback Interface address) thus if the peer has two 
>> physical interfaces to current router, there is only one route.
>> Thus the load balancing issue is transparent to the BGP routing
>> and only obvious in the forwarding plane. 

> And if it is transparent to the BGP routing, then there is no
> need to have it in the base spec. Agreed ?

Note that what Ben described above is not BGP multipath, but
load-balancing based on IGP multipath, and right, _this_ one doesn't
belong in the spec.

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 MAA25256 for <[e-mail]>; Tue, 1 Oct 2002 12:42:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 2DDBD91284; Tue,  1 Oct 2002 12:42:04 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id F35AE91296; Tue,  1 Oct 2002 12:42: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 77C4D91284 for <[e-mail]>; Tue,  1 Oct 2002 12:42:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6088D5DE5B; Tue,  1 Oct 2002 12:42:02 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 3093C5DE54 for <[e-mail]>; Tue,  1 Oct 2002 12:42: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 17wQ5w-000Ht9-00; Tue, 01 Oct 2002 09:42:00 -0700
Date: Tue, 1 Oct 2002 09:40: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: "Natale, Jonathan" <[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

Jonathan,

  At the minimum, the text would need to say what _BGP_ routes are
  considered equal and can be used for load balancing. We don't
  want the reader to mistakenly assume that, e.g., paths with
  a longer AS_PATH can be used for load-balancing.

-- 
Alex

Tuesday, October 01, 2002, 8:14:50 AM, Natale, Jonathan wrote:
> If the routes are equal (e.g. only next hop is different) and the speaker is
> configured to load balance, the routes are used locally to load balance.
> But the same route would be advertised to other peers as would be if load
> balance was not configured.  So it is out of scope, just as administrative
> distance is out of scope (decided previously).

> Of course you could aggregate as described below, but I don't see the point.


> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Tuesday, October 01, 2002 10:49 AM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: issue 11 

> Jonathan,

>> I disagree, this does not reflect current implementations that I know of.

> How do implementations that you know of handle this ?

> yakov.

>> Does anybody's implementation do this? 
>> 
>> -----Original Message-----
>> From: Dimitry Haskin [mailto:[e-mail]] 
>> Sent: Monday, September 30, 2002 6:39 PM
>> To: 'Alex Zinin'; Yakov Rekhter
>> Cc: [e-mail]
>> Subject: RE: issue 11
>> 
>> 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 MAA25116 for <[e-mail]>; Tue, 1 Oct 2002 12:39:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 3A95B91225; Tue,  1 Oct 2002 12:39:21 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 005B191284; Tue,  1 Oct 2002 12:39: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 A12C791225 for <[e-mail]>; Tue,  1 Oct 2002 12:39:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 7DEB75DE5B; Tue,  1 Oct 2002 12:39:19 -0400 (EDT)
Delivered-To: [e-mail]
Received: from psg.com (psg.com [147.28.0.62]) by segue.merit.edu (Postfix) with ESMTP id 538E45DE54 for <[e-mail]>; Tue,  1 Oct 2002 12:39:19 -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 17wQ3J-000Hom-00; Tue, 01 Oct 2002 09:39:17 -0700
Date: Tue, 1 Oct 2002 09:37:27 -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: "Natale, Jonathan" <[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

Besides, it doesn't say anything about how the routes
are selected.

-- 
Alex

Tuesday, October 01, 2002, 5:56:07 AM, Natale, Jonathan wrote:
> I disagree, this does not reflect current implementations that I know of.
> Does anybody's implementation do this? 

> -----Original Message-----
> From: Dimitry Haskin [mailto:[e-mail]] 
> Sent: Monday, September 30, 2002 6:39 PM
> To: 'Alex Zinin'; Yakov Rekhter
> Cc: [e-mail]
> Subject: RE: issue 11

> 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




Received: from trapdoor.merit.edu ([e-mail] [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA24044 for <[e-mail]>; Tue, 1 Oct 2002 12:14:31 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 8D24F9125A; Tue,  1 Oct 2002 12:14:03 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58D4491284; Tue,  1 Oct 2002 12:14: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 1E0C39125A for <[e-mail]>; Tue,  1 Oct 2002 12:14:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 05FDE5DE58; Tue,  1 Oct 2002 12:14: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 758985DE55 for <[e-mail]>; Tue,  1 Oct 2002 12:14:01 -0400 (EDT)
Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g91GDFv86828; Tue, 1 Oct 2002 12:13: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 g91GDCG86821; Tue, 1 Oct 2002 12:13:12 -0400 (EDT) (envelope-from [e-mail])
Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g91GDC501054; Tue, 1 Oct 2002 12:13:12 -0400 (EDT)
Date: Tue, 1 Oct 2002 12:13:12 -0400
From: Jeffrey Haas <[e-mail]>
To: Dimitry Haskin <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 11
Message-ID: <[e-mail]>
References: <[e-mail]> <001e01c26964$63c3fd30$01ffff0a@QUICK>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <001e01c26964$63c3fd30$01ffff0a@QUICK>; from [e-mail] on Tue, Oct 01, 2002 at 12:05:35PM -0400
X-Virus-Scanned: by AMaViS perl-11
Sender: [e-mail]
Precedence: bulk

On Tue, Oct 01, 2002 at 12:05:35PM -0400, Dimitry Haskin wrote:
> As far as I aware, this is what has been effectively implemented when
> multiple E-BGP routes to the same prefix are used for load balancing. To
> be precise, as far as I know, those implementations restrict multi-path
> eligibility to peers in the same neighboring AS so that routes may only
> differ in the next hop attribute.

If router A peers with router X and Y in a neighboring AS, then it
is quite possible for a given prefix D to have two completely
different sets of path attributes.

At the very least, the AS_PATH may differ and thus the loop
properties will differ as well.  If you don't advertise an aggregated
AS_PATH (as one suggestion made), then you can do Bad Things.
If you make sure that at the very least the AS_PATHs are equivalent,
then thats at least one problem thats dealt with.

> Hence, in this restricted case the
> aggregate would look exactly the same as components except that if
> components differ in the next-hop attribute,

That'd work.

> the aggregate route should
> be advertised with the local address of the speaker.

And that too.

> I don't mind if the multi-path issues are kept out of the document. But
> if there is insistence to provide some guidance, I hoped that a general
> conceptual statement could be sufficient.

IMO, its best if we just left the issue of multi-path forwarding out
of the base spec as black magic.  We can publish the Necronomicon later.

>  Dimitry

-- 
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 MAA23607 for <[e-mail]>; Tue, 1 Oct 2002 12:06:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 610539121B; Tue,  1 Oct 2002 12:05:44 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 28DA69125A; Tue,  1 Oct 2002 12:05: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 D5D079121B for <[e-mail]>; Tue,  1 Oct 2002 12:05:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id BB3AF5DE4A; Tue,  1 Oct 2002 12:05:42 -0400 (EDT)
Delivered-To: [e-mail]
Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by segue.merit.edu (Postfix) with ESMTP id 2EFE45DD8E for <[e-mail]>; Tue,  1 Oct 2002 12:05:42 -0400 (EDT)
Received: from QUICK ([24.62.129.118]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021001160541.ZQD17535.rwcrmhc51.attbi.com@QUICK>; Tue, 1 Oct 2002 16:05:41 +0000
From: "Dimitry Haskin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, <[e-mail]>
Subject: RE: issue 11
Date: Tue, 1 Oct 2002 12:05:35 -0400
Message-ID: <001e01c26964$63c3fd30$01ffff0a@QUICK>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

As far as I aware, this is what has been effectively implemented when
multiple E-BGP routes to the same prefix are used for load balancing. To
be precise, as far as I know, those implementations restrict multi-path
eligibility to peers in the same neighboring AS so that routes may only
differ in the next hop attribute. Hence, in this restricted case the
aggregate would look exactly the same as components except that if
components differ in the next-hop attribute, the aggregate route should
be advertised with the local address of the speaker.

The proposed paragraph tries to be more general in its guidance for
multi-path use and to extend to the cases when routes to different ASs
are used for multi-path forwarding.

After all if a BGP speaker chooses to advertise a single route even when
multiple component routes are used for local forwarding, this in effect
constitutes an aggregation -- even if the aggregate and components have
the same prefix. As such, it should comply with aggregation rules that
have been defined to provide loop-free routing.

I don't mind if the multi-path issues are kept out of the document. But
if there is insistence to provide some guidance, I hoped that a general
conceptual statement could be sufficient.

Regards,
 Dimitry

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Natale, Jonathan
> Sent: Tuesday, October 01, 2002 8:56 AM
> To: [e-mail]
> Subject: RE: issue 11
> 
> I disagree, this does not reflect current implementations that I know
of.
> Does anybody's implementation do this?
> 
> -----Original Message-----
> From: Dimitry Haskin [mailto:[e-mail]]
> Sent: Monday, September 30, 2002 6:39 PM
> To: 'Alex Zinin'; Yakov Rekhter
> Cc: [e-mail]
> Subject: RE: issue 11
> 
> 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 LAA23331 for <[e-mail]>; Tue, 1 Oct 2002 11:57:25 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id DE96D91295; Tue,  1 Oct 2002 11:57:01 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE32C91296; Tue,  1 Oct 2002 11: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 6F77291295 for <[e-mail]>; Tue,  1 Oct 2002 11:57:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4DDE45DD8E; Tue,  1 Oct 2002 11:57: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 E47EB5DE29 for <[e-mail]>; Tue,  1 Oct 2002 11:56: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 g91Fuvm63051; Tue, 1 Oct 2002 08:56:57 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Abarbanel, Benjamin" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 11 
In-Reply-To: Your message of "Tue, 01 Oct 2002 11:33:13 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 01 Oct 2002 08:56:57 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ben,

> Jonathan:
> 
> See Below
> 
> > -----Original Message-----
> > From: Natale, Jonathan [mailto:[e-mail]]
> > Sent: Tuesday, October 01, 2002 11:15 AM
> > To: 'Yakov Rekhter'; Natale, Jonathan
> > Cc: [e-mail]
> > Subject: RE: issue 11 
> > 
> > 
> > If the routes are equal (e.g. only next hop is different) and 
> > the speaker is
> > configured to load balance, the routes are used locally to 
> > load balance.
> 
> It would be smarter to assign the next hop address to a virtual 
> interface (e.g. Loopback Interface address) thus if the peer has two 
> physical interfaces to current router, there is only one route.
> Thus the load balancing issue is transparent to the BGP routing
> and only obvious in the forwarding plane. 

And if it is transparent to the BGP routing, then there is no
need to have it in the base spec. 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 LAA22471 for <[e-mail]>; Tue, 1 Oct 2002 11:33:36 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id B319791294; Tue,  1 Oct 2002 11:33:17 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CA5F91295; Tue,  1 Oct 2002 11:33: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 5C9B191294 for <[e-mail]>; Tue,  1 Oct 2002 11:33:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 4B4C15DE53; Tue,  1 Oct 2002 11:33: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 CE55D5DE29 for <[e-mail]>; Tue,  1 Oct 2002 11:33: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 LAA14402; Tue, 1 Oct 2002 11:33: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 LAA14791; Tue, 1 Oct 2002 11:33:14 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7N4VB>; Tue, 1 Oct 2002 11:33:13 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Natale, Jonathan'" <[e-mail]>, "'Yakov Rekhter'" <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 11 
Date: Tue, 1 Oct 2002 11:33: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

Jonathan:

See Below

> -----Original Message-----
> From: Natale, Jonathan [mailto:[e-mail]]
> Sent: Tuesday, October 01, 2002 11:15 AM
> To: 'Yakov Rekhter'; Natale, Jonathan
> Cc: [e-mail]
> Subject: RE: issue 11 
> 
> 
> If the routes are equal (e.g. only next hop is different) and 
> the speaker is
> configured to load balance, the routes are used locally to 
> load balance.

It would be smarter to assign the next hop address to a virtual 
interface (e.g. Loopback Interface address) thus if the peer has two 
physical interfaces to current router, there is only one route.
Thus the load balancing issue is transparent to the BGP routing
and only obvious in the forwarding plane. Also, this is localized to
the load balancing to be contained between the current router and an
adjacent router. Once we get into load balancing between the current
router and different routers we get into all kinds of what if conditions.

Just another twist to solving load balancing issues.

> But the same route would be advertised to other peers as 
> would be if load
> balance was not configured.  So it is out of scope, just as 
> administrative
> distance is out of scope (decided previously).
>
So the current peer advertises two routes with same prefix and different
next hops. Would'nt the second route overtake the first route in the
peer's routing table such that there will only be one route present in
the peer's routing table? If so, how will that work for load balancing?
 
> Of course you could aggregate as described below, but I don't 
> see the point.
> 
>

Aggegation is good for reducing routing table size, but not to solve 
multi-path issues. IMHO.

 
Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[e-mail]] 
> Sent: Tuesday, October 01, 2002 10:49 AM
> To: Natale, Jonathan
> Cc: [e-mail]
> Subject: Re: issue 11 
> 
> Jonathan,
> 
> > I disagree, this does not reflect current implementations 
> that I know of.
> 
> How do implementations that you know of handle this ?
> 
> yakov.
> 
> > Does anybody's implementation do this? 
> > 
> > -----Original Message-----
> > From: Dimitry Haskin [mailto:[e-mail]] 
> > Sent: Monday, September 30, 2002 6:39 PM
> > To: 'Alex Zinin'; Yakov Rekhter
> > Cc: [e-mail]
> > Subject: RE: issue 11
> > 
> > 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 LAA21748 for <[e-mail]>; Tue, 1 Oct 2002 11:15:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 9F8C591292; Tue,  1 Oct 2002 11:14:58 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 021FE91294; Tue,  1 Oct 2002 11:14: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 990FB91292 for <[e-mail]>; Tue,  1 Oct 2002 11:14:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 82FB85DE55; Tue,  1 Oct 2002 11:14: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 2D9865DE54 for <[e-mail]>; Tue,  1 Oct 2002 11:14:55 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12LWN>; Tue, 1 Oct 2002 11:14:54 -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 11 
Date: Tue, 1 Oct 2002 11:14:50 -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 routes are equal (e.g. only next hop is different) and the speaker is
configured to load balance, the routes are used locally to load balance.
But the same route would be advertised to other peers as would be if load
balance was not configured.  So it is out of scope, just as administrative
distance is out of scope (decided previously).

Of course you could aggregate as described below, but I don't see the point.


-----Original Message-----
From: Yakov Rekhter [mailto:[e-mail]] 
Sent: Tuesday, October 01, 2002 10:49 AM
To: Natale, Jonathan
Cc: [e-mail]
Subject: Re: issue 11 

Jonathan,

> I disagree, this does not reflect current implementations that I know of.

How do implementations that you know of handle this ?

yakov.

> Does anybody's implementation do this? 
> 
> -----Original Message-----
> From: Dimitry Haskin [mailto:[e-mail]] 
> Sent: Monday, September 30, 2002 6:39 PM
> To: 'Alex Zinin'; Yakov Rekhter
> Cc: [e-mail]
> Subject: RE: issue 11
> 
> 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 KAA20585 for <[e-mail]>; Tue, 1 Oct 2002 10:48:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 5AEAD9128F; Tue,  1 Oct 2002 10:48:39 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A7E991290; Tue,  1 Oct 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 D5CD09128F for <[e-mail]>; Tue,  1 Oct 2002 10:48:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id B12695DE24; Tue,  1 Oct 2002 10:48: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 15E555DE16 for <[e-mail]>; Tue,  1 Oct 2002 10:48: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 g91EmUm58165; Tue, 1 Oct 2002 07:48:30 -0700 (PDT) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Natale, Jonathan" <[e-mail]>
Cc: [e-mail]
Subject: Re: issue 11 
In-Reply-To: Your message of "Tue, 01 Oct 2002 08:56:07 EDT." <[e-mail]> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <[e-mail]>
Date: Tue, 01 Oct 2002 07:48:30 -0700
From: Yakov Rekhter <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Jonathan,

> I disagree, this does not reflect current implementations that I know of.

How do implementations that you know of handle this ?

yakov.

> Does anybody's implementation do this? 
> 
> -----Original Message-----
> From: Dimitry Haskin [mailto:[e-mail]] 
> Sent: Monday, September 30, 2002 6:39 PM
> To: 'Alex Zinin'; Yakov Rekhter
> Cc: [e-mail]
> Subject: RE: issue 11
> 
> 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 KAA19537 for <[e-mail]>; Tue, 1 Oct 2002 10:25:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 7071D9128D; Tue,  1 Oct 2002 10:24:41 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 442E89128F; Tue,  1 Oct 2002 10:24: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 2BF6E9128D for <[e-mail]>; Tue,  1 Oct 2002 10:24:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 136A75DE4C; Tue,  1 Oct 2002 10:24:40 -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 880535DE48 for <[e-mail]>; Tue,  1 Oct 2002 10:24: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 KAA09002; Tue, 1 Oct 2002 10:23: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 KAA28242; Tue, 1 Oct 2002 10:22:27 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <S8R7NQG2>; Tue, 1 Oct 2002 10:22:27 -0400
Message-ID: <[e-mail]>
From: "Abarbanel, Benjamin" <[e-mail]>
To: "'Dimitry Haskin'" <[e-mail]>, "'Alex Zinin'" <[e-mail]>, Yakov Rekhter <[e-mail]>
Cc: [e-mail]
Subject: RE: issue 11
Date: Tue, 1 Oct 2002 10:22: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

Dimitry:
  Although forming an aggregate may solve the problem of unpredictable 
route path forwarding. It will cause some attributes to be lost and
thus not offer the peer the proper networking visibility. If we want 
to solve the multipath issue we must add rules for example, it works
reliable
well if the same AS providor is providing the multipath routes from its 
various links/routers. Else, it will be less deterministic and potentially
prone to problems such as routing loops and/or degradation of latency.

But in a nutshell I think Yakov does not want to start this topic here and
now. Although a good item to discuss in future revisions and possibly solve.

Ben

> -----Original Message-----
> From: Dimitry Haskin [mailto:[e-mail]]
> Sent: Monday, September 30, 2002 6:39 PM
> To: 'Alex Zinin'; Yakov Rekhter
> Cc: [e-mail]
> Subject: RE: issue 11
> 
> 
> 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 IAA15500 for <[e-mail]>; Tue, 1 Oct 2002 08:56:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 416959123D; Tue,  1 Oct 2002 08:56:14 -0400 (EDT)
Delivered-To: [e-mail]
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B36F91240; Tue,  1 Oct 2002 08:56: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 8FA1E9123D for <[e-mail]>; Tue,  1 Oct 2002 08:56:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id 6DC525DE44; Tue,  1 Oct 2002 08:56: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 1982E5DE42 for <[e-mail]>; Tue,  1 Oct 2002 08:56:12 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <RBC12LCL>; Tue, 1 Oct 2002 08:56:11 -0400
Message-ID: <[e-mail]>
From: "Natale, Jonathan" <[e-mail]>
To: [e-mail]
Subject: RE: issue 11
Date: Tue, 1 Oct 2002 08:56:07 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I disagree, this does not reflect current implementations that I know of.
Does anybody's implementation do this? 

-----Original Message-----
From: Dimitry Haskin [mailto:[e-mail]] 
Sent: Monday, September 30, 2002 6:39 PM
To: 'Alex Zinin'; Yakov Rekhter
Cc: [e-mail]
Subject: RE: issue 11

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