RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search