Re: AD-review comments on draft-ietf-idr-bgp4-20
"Tom Petch" <nwnetworks@dial.pipex.com> Thu, 05 June 2003 14:25 UTC
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28010 for <idr-archive@ietf.org>; Thu, 5 Jun 2003 10:25:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nvev-0007NT-00 for idr-archive@ietf.org; Thu, 05 Jun 2003 10:24:05 -0400
Received: from trapdoor.merit.edu ([198.108.1.26] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19Nveu-0007NO-00 for idr-archive@ietf.org; Thu, 05 Jun 2003 10:24:04 -0400
Received: by trapdoor.merit.edu (Postfix) id 6AF4991220; Thu, 5 Jun 2003 10:25:40 -0400 (EDT)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3EC9891221; Thu, 5 Jun 2003 10:25:40 -0400 (EDT)
Delivered-To: idr@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BB26D91220 for <idr@trapdoor.merit.edu>; Thu, 5 Jun 2003 10:25:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A04185DE02; Thu, 5 Jun 2003 10:25:38 -0400 (EDT)
Delivered-To: idr@merit.edu
Received: from shockwave.systems.pipex.net (shockwave.systems.pipex.net [62.241.160.9]) by segue.merit.edu (Postfix) with ESMTP id 46A925DDE8 for <idr@merit.edu>; Thu, 5 Jun 2003 10:25:38 -0400 (EDT)
Received: from tom3 (1Cust85.tnt2.lnd4.gbr.da.uu.net [62.188.131.85]) by shockwave.systems.pipex.net (Postfix) with SMTP id 424CD16000B07; Thu, 5 Jun 2003 15:25:34 +0100 (BST)
Message-ID: <005e01c32b6e$3445ea60$0301a8c0@tom3>
Reply-To: Tom Petch <nwnetworks@dial.pipex.com>
From: Tom Petch <nwnetworks@dial.pipex.com>
To: Alex Zinin <zinin@psg.com>, Yakov Rekhter <yakov@juniper.net>
Cc: idr@merit.edu, rtg-dir@ietf.org
Subject: Re: AD-review comments on draft-ietf-idr-bgp4-20
Date: Thu, 05 Jun 2003 15:23:27 +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: owner-idr@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit
Some nits below but chiefly, what happened to the comments on section 8, the section closest to my processing engine/heart? Tom Petch nwnetworks@dial.pipex.com >> >> > 5.1.2 AS_PATH >> ... >> > b) When a given BGP speaker advertises the route to an external >> > peer, then the advertising speaker updates the AS_PATH attribute >> > as follows: >> > >> > 1) if the first path segment of the AS_PATH is of type >> > AS_SEQUENCE, the local system prepends its own AS number as the >> > last element of the sequence (put it in the leftmost position). >> >> 'Leftmost position'... isn't this still open for interpretation? How >> about wording this relative to the position of the octets in the >> protocol message? > >I'll replace "the leftmost position" with "the leftmost position with >respect to the position of octets in the protocol message". I find this less clear - and I am never comfortable with left as I do not know how well it translates in other cultures; I prefer a numeric reference which I believe translates better. But here, I see the problem arising from the use of first and last without saying first or last what; first octet/AS number/path segment encountered in decoding the packet? first prepend? I think it is that that needs fixing rather than left. Also, while the order of AS within a path segment is said to be significant, I see nothing about the order of the path segments themselves which matters as much(in 4.3 perhaps) And can we get ie do we need to cater for an AS_PATH consisting of AS_SEQUENCE AS_SET AS_SEQUENCE ? >> > 6. BGP Error Handling. >> ... >> > The phrase "the BGP connection is closed" means that the TCP connec- >> > tion has been closed, the associated Adj-RIB-In has been cleared, and >> > that all resources for that BGP connection have been deallocated. >> > Entries in the Loc-RIB associated with the remote peer are marked as >> > invalid. The fact that the routes have become invalid is passed to >> > other BGP peers before the routes are deleted from the system. >> >> What does "the fact is passed" mean? Should we instead say that local >> route recalculation happens and peers are sent either updated best >> routes or withdrawals? > >How about the following replacement for the last sentence: > > The local system recalculates its best routes for the destinations > of the routes marked as invalid, and advertises to its peers either > withdraws for the routes marked as invalid, or the new best routes > before the invalid routes are deleted from the system. I find this ambiguous. Does it mean The local system recalculates its best routes for the destinations of the routes marked as invalid and - before the invalid routes are deleted from the system - advertises to its peers either the new best routes or, if no route now exists, withdrawals for the routes marked as invalid. ? >> > If the UPDATE message is received from an external peer, the local >> > system MAY check whether the leftmost AS in the AS_PATH attribute is >> >> Same comment about 'leftmost'... Maybe we should define this somewhere >> in the beginning of the spec? > >I will replace "the leftmost AS" with "the leftmost AS with >respect to the position of octets in the protocol message". as above > >> > 9.1.1 Phase 1: Calculation of Degree of Preference >> ... >> > If the route is learned from an external peer, then the local BGP >> > speaker computes the degree of preference based on preconfigured >> > policy information. If the return value indicates that the route >> > is ineligible, the route MAY NOT serve as an input to the next >> > phase of route selection; otherwise the return value is used as >> > the LOCAL_PREF value in any IBGP readvertisement. >> >> So, AFAIK, the major implementations do not follow this step >> (calculating the degree of preference, and then announcing). Instead, >> implementations allow setting the LOCAL_PREF value locally, which is >> taken into consideration during the best path selection, and is also >> reannounced further. > >It is important to keep in mind that the whole section on the BGP >decision process does *not* mean that an implementation must implement >it precisely as it is described in the spec, as long as the implementation >support the described functionality and its externally visible behavior >is the same. With this in mind how about if I'll add the following: > > The BGP Decision Process in this document is conceptual and do does > not have to be implemented precisely as described here, as long > as the implementations support the described functionality and > their externally visible behavior is the same.
- AD-review comments on draft-ietf-idr-bgp4-20 Alex Zinin
- Re: AD-review comments on draft-ietf-idr-bgp4-20 Yakov Rekhter
- Re: AD-review comments on draft-ietf-idr-bgp4-20 Tom Petch
- Re: AD-review comments on draft-ietf-idr-bgp4-20 Curtis Villamizar
- Re: AD-review comments on draft-ietf-idr-bgp4-20 Yakov Rekhter