RFC Errata
RFC 5065, "Autonomous System Confederations for BGP", August 2007
Source of RFC: idr (rtg)
Errata ID: 1005
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-08-17
Held for Document Update by: Stewart Bryant
Date Held: 2013-09-19
(1) obsolete reference tag - #1
Apparently, some reference tags have not been updated when the
'References' Section (10.) has been modified to incorporate
current versions of the relevant documents.
The second paragraph of Section 1, on page 3 of RFC 5065, says:
This scaling problem has been well documented and a number of
| proposals have been made to alleviate this, such as [RFC2796] and
[RFC1863] (made historic by [RFC4223]). [...]
RFC 2796 has been obsoleted by RFC 4456, and Section 10.2 only
contains an entry for [RFC4456], which is only used in the
second paragraph of Section 2, but no entry for [RFC 2796].
Therefore, the above sentence should better say:
This scaling problem has been well documented and a number of
| proposals have been made to alleviate this, such as [RFC4456] and
[RFC1863] (made historic by [RFC4223]). [...]
or, if you prefer, for the sake of historical precision:
This scaling problem has been well documented and a number of
| proposals have been made to alleviate this, such as [RFC4456]
| (first version published in [RFC 2796]) and [RFC1863] (made historic
by [RFC4223]). [...]
For the latter variant, an entry for [RFC2796] must be restored into
Section 10.2, as well.
(2) sluggish / imprecise language
The third paragraph of Section 4, at the bottom of page 5, says:
A BGP speaker receiving an AS_PATH attribute containing an autonomous
| system matching its own AS Confederation Identifier SHALL treat the
path in the same fashion as if it had received a path containing its
own AS number.
Preferably, the text should not mess up the terms 'autonomous system'
and 'autonomous system number'.
Thus, it should say:
A BGP speaker receiving an AS_PATH attribute containing an autonomous
| system number matching its own AS Confederation Identifier SHALL
treat the path in the same fashion as if it had received a path
containing its own AS number.
(3) misleading specification, with bad wording
In Section 4.1, the bullets b) 1) (on page 6) and c) 2) (on page 7)
have been amended by instructions for the case of AS_PATH segment
overflow. Although the details of the action necessary according
to the spirit of BGP differ in a small, but important way, the
same wording is used in both cases. That might be very misleading.
I propose to explicitely specify the AS number to be inserted in
both cases, using the terms defined in Section 1.2.
Furthermore, the word 'prepend' is abused in the last part of the
amendments and might even be misleading.
I propose to use 'include' in there, as the text already does in
similar context, for instance in the immediately subsequent bullets.
Therefore, the text in bullet b) 1) (on page 6),
[...]. If the act of prepending will cause an
overflow in the AS_PATH segment (i.e., more than 255 ASs), it
SHOULD prepend a new segment of type AS_CONFED_SEQUENCE and
| prepend its own AS number to this new segment.
^^^^^^^ ^^^^^^^^^ ^^
should say:
[...]. If the act of prepending will cause an
overflow in the AS_PATH segment (i.e., more than 255 ASs), it
SHOULD prepend a new segment of type AS_CONFED_SEQUENCE and
| include its own Member-AS number in this new segment.
^^^^^^^ ^^^^^^^^^^^^^^^^ ^^
Similarly, the identical text in bullet c) 2) (on page 7),
[...]. If the act of prepending will cause an
overflow in the AS_PATH segment (i.e., more than 255 ASs), it
| SHOULD prepend a new segment of type AS_SEQUENCE and prepend
| its own AS number to this new segment.
^^^^^^^^^ ^^ ^^^^^^^
should say:
[...]. If the act of prepending will cause an
overflow in the AS_PATH segment (i.e., more than 255 ASs), it
| SHOULD prepend a new segment of type AS_SEQUENCE and include
| its own AS Condeferation Identifier in this new segment.
^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^ ^^^^^^^
(4) textual enhancement
Still in Section 4.1, in the lower half of pgae 7, the bullets a) and
b) under headline:
When a BGP speaker originates a route then:
deal with similar cases using (almost) similar wording.
Bullet b) says:
b) the originating speaker includes its own Member-AS Number in a
path segment, of type AS_CONFED_SEQUENCE, in the AS_PATH attribute
of all UPDATE messages sent to BGP speakers located in neighboring
| Member Autonomous Systems that are members of the local
confederation. [...]
To finalize the similarity, and to remove the unnecessary repetition
of the word 'member', it would perhaps have been better to say:
b) the originating speaker includes its own Member-AS Number in a
path segment, of type AS_CONFED_SEQUENCE, in the AS_PATH attribute
of all UPDATE messages sent to BGP speakers located in neighboring
| autonomous systems that are members of the local confederation.
[...]
(5) typo, and unnecessarily differing case
The last paragraph of the new Section 5 says:
vv
| It is a error for a BGP speaker to receive an update message from a
confederation peer that is not in the same Member-AS that does not
have AS_CONFED_SEQUENCE as the first segment. [...]
To correct the grammar, and to harmonize the case of 'UPDATE message'
throughout the whole section, it should say:
vvv
| It is an error for a BGP speaker to receive an UPDATE message from a
confederation peer that is not in the same Member-AS that does not
have AS_CONFED_SEQUENCE as the first segment. [...]
Alternatively, perhaps, the obstinate double 'that' could easily be
removed as well:
vvv
| It is an error for a BGP speaker to receive an UPDATE message from a
| confederation peer not located in the same Member-AS that does not
have AS_CONFED_SEQUENCE as the first segment. [...]
(6) grammar
The first paragraph of Section 6, on top of page 10, says:
vv
| All BGP speakers participating as members of a confederation MUST
recognize the AS_CONFED_SET and AS_CONFED_SEQUENCE segment type
extensions to the AS_PATH attribute.
IMHO, it should be ... participating *in* ...
Thus, the RFC should say:
vv
| All BGP speakers participating as members in a confederation MUST
recognize the AS_CONFED_SET and AS_CONFED_SEQUENCE segment type
extensions to the AS_PATH attribute.
(7) obsolete reference tag - #2
Section 8 (at the bottom of page 10) says:
This extension to BGP does not change the underlying security issues
inherent in the existing BGP protocol, such as those described in
| [RFC2385] and [BGP-VULN].
^^^^^^^^
There is no such reference tag '[BGP-VULN]' in Section 10.
Apparently, the RFC should say:
This extension to BGP does not change the underlying security issues
inherent in the existing BGP protocol, such as those described in
| [RFC2385] and [RFC4272].
^^^^^^^
(8) obsolete reference tag - #3
The first paragraph of Section 9, on top of page 11, says:
The general concept of BGP confederations was taken from IDRP's
Routing Domain Confederations [ISO10747]. Some of the introductory
| text in this document was taken from [RFC2796].
^^^^
As in item (1) above, either the tag '[RFC2796]' is updated:
The general concept of BGP confederations was taken from IDRP's
Routing Domain Confederations [ISO10747]. Some of the introductory
| text in this document was taken from [RFC4456].
^^^^
or an entry for '[RFC2796]' must be restored into Section 10.2 .
(9) obsolete RFCs listed as Normative References ?!?
RFC 5065, on page 11, lists its obsolete predecessors as Normative
References, [RFC1965] and [RFC3065], in Section 10.1.
According to common sense, general practice, and the rules for
Normative References, I would have preferred to see these entries
placed into Section 10.2, as Informative References.
Notes:
This proposed no normative changes, and the clarifications do not appear to be urgent.