RFC Errata
Found 5 records.
Status: Verified (1)
RFC 4364, "BGP/MPLS IP Virtual Private Networks (VPNs)", February 2006
Note: This RFC has been updated by RFC 4577, RFC 4684, RFC 5462
Source of RFC: l3vpn (int)
Errata ID: 3649
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bharat Joshi
Date Reported: 2013-06-12
Verifier Name: Brian Haberman
Date Verified: 2013-06-13
Section 4.3.2 says:
Then if a route is potentially reachable over more than one attachment circuit, the PE/CE routing can switch the preferred path for a route from one attachment circuit to another, without there being any need to distribute new a label for that route.
It should say:
Then if a route is potentially reachable over more than one attachment circuit, the PE/CE routing can switch the preferred path for a route from one attachment circuit to another, without there being any need to distribute a new label for that route.
Notes:
'distribute new a label' should be 'distribute a new label'.
Status: Held for Document Update (2)
RFC 4364, "BGP/MPLS IP Virtual Private Networks (VPNs)", February 2006
Note: This RFC has been updated by RFC 4577, RFC 4684, RFC 5462
Source of RFC: l3vpn (int)
Errata ID: 113
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-20
Held for Document Update by: ron bonica
(1) Section 1 (Introduction)
The 1st paragraph on page 3 contains the sentence:
[...]. The PE routers distribute, to the CE
routers in a particular VPN, the routes from other the CE routers in
that VPN. [...]
It should say:
[...]. The PE routers distribute, to the CE
| routers in a particular VPN, the routes from the other CE routers in
that VPN. [...]
^^^^^^^^^
(2) Section 3.3 (Populating the VRFs)
The last paragraph of Section 3.3, on mid-page 12, says:
If an attachment circuit leads to a site which is in multiple VPNs,
the attachment circuit may still associated with a single VRF, in
which case the VRF will contain routes from the full set of VPNs of
which the site is a member.
It should say:
vvvv
If an attachment circuit leads to a site which is in multiple VPNs,
| the attachment circuit may still be associated with a single VRF, in
which case the VRF will contain routes from the full set of VPNs of
which the site is a member.
(3) Section 6 (Maintaining Proper Isolation of VPNs)
At the bottom of page 26, and extending to page 27, the text says:
The first condition ensure that any labeled packets received from
non-backbone routers have a legitimate and properly assigned label at
<< page break >>
the top of the label stack. [...]
It should say:
vv
| The first condition ensures that any labeled packets received from
non-backbone routers have a legitimate and properly assigned label at
<< page break >>
the top of the label stack. [...]
(4) Section 7 (How PEs Learn Routes from CEs)
The descrition of 'technique #4', on mid-page 28 says:
4. The PE and CE routers may be BGP peers, and the CE router may
use BGP (in particular, EBGP to tell the PE router the set of
address prefixes that are at the CE router's site. (This
technique can be used in stub VPNs or transit VPNs.)
It should say:
vvv
4. The PE and CE routers may be BGP peers, and the CE router may
| use BGP (in particular, EBGP) to tell the PE router the set of
address prefixes that are at the CE router's site. (This
technique can be used in stub VPNs or transit VPNs.)
(5) Section 9 (Carriers' Carriers)
The last paragraph at the bottom of page 31 contains the sentence:
[...]. All that
is required is that the external routes be known to whatever routers
are responsible for putting the label stack on a hitherto unlabeled
packet and that there be label switched path that leads from those
routers to their BGP peers at other sites. [...]
It should say:
[...]. All that
is required is that the external routes be known to whatever routers
are responsible for putting the label stack on a hitherto unlabeled
| packet and that there be a label switched path that leads from those
routers to their BGP peers at other sites. [...]
^^^
Notes:
To facilitate the recognition of the text changes proposed,
I have added change bars ('|') in column 1, and up/down pointing
marker lines ('^^^'/'vvv').
from pending
Errata ID: 7180
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Angély
Date Reported: 2022-10-24
Held for Document Update by: John Scudder
Date Held: 2024-01-12
Section 4.3.4 says:
Note that this VPN architecture does not require the capability to distribute unlabeled VPN-IPv4 addresses.
It should say:
Note that this VPN architecture does not require the capability to distribute unlabeled IPv4 addresses.
Notes:
From my understanding, VPN-IPv4 addresses are necessarily labeled, but IPv4 adresses are not indeed. Section 10 seems to confirm the error by using the correct term: "distribute unlabeled IPv4 addresses to each other."
Additional note from verifier: this was reported as technical, but I have changed it to editorial following the guidelines in https://www.ietf.org/about/groups/iesg/statements/processing-errata-ietf-stream/ (“Technical errata are expected to be things that would likely cause significant misunderstandings of the technical specification and might result in faulty implementations if they are not corrected. Editorial errata are, as the name implies, editorial - for example, typos, missing commas, etc. Errors in examples will generally be editorial…”) Since the text in question is a “note that” I take the view that it’s similar in character to an example. Furthermore, I don’t think it’s likely the error would result in faulty implementations. Finally, the uncorrected text, while kind of silly, isn’t strictly speaking untrue, so I have chosen “hold for document update“ rather than “verified”.
Status: Rejected (2)
RFC 4364, "BGP/MPLS IP Virtual Private Networks (VPNs)", February 2006
Note: This RFC has been updated by RFC 4577, RFC 4684, RFC 5462
Source of RFC: l3vpn (int)
Errata ID: 3647
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bharat Joshi
Date Reported: 2013-06-12
Rejected by: Brian Haberman
Date Rejected: 2013-06-13
Section 3.2 says:
If it is desired to have a particular host be in multiple virtual sites, then that host must determine, for each packet, which virtual site the packet is associated with.
It should say:
If it is desired to have a particular host to be in multiple virtual sites, then that host must determine, for each packet, which virtual site the packet is associated with.
Notes:
'host be' should be 'host to be'
--VERIFIER NOTES--
The original text is correct.
Errata ID: 3648
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bharat Joshi
Date Reported: 2013-06-12
Rejected by: Brian Haberman
Date Rejected: 2013-06-13
Section 4 says:
If two routes to the same IP address prefix are actually routes to different systems, it is important to ensure that BGP not treat them as comparable.
It should say:
If two routes to the same IP address prefix are actually routes to two different systems, it is important to ensure that BGP not treat them as comparable.
Notes:
'routes to different system' should be 'routes to two different system'
--VERIFIER NOTES--
The original text is correct.