Re: AD-review comments on draft-ietf-idr-bgp4-20

["Tom Petch" <nwnetworks@dial.pipex.com>]

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.