RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (1)

RFC 5302, "Domain-Wide Prefix Distribution with Two-Level IS-IS", October 2008

Source of RFC: isis (rtg)

Errata ID: 3994

Status: Verified
Type: Technical

Reported By: Amit Kalita
Date Reported: 2014-05-20
Verifier Name: Alia Atlas
Date Verified: 2014-06-10

Section 3.1 says:

L2->L1 inter-area external routes with external metric:  These are
      advertised in L1 LSPs, in TLV 130.  The up/down bit is set to one,
      metric-type is external metric.  These IP prefixes are learned via
      L2 routing, and were derived during the L1 SPF computation from
      prefixes advertised in L2 LSPs in TLV 130 with external metrics.

It should say:

L2->L1 inter-area external routes with external metric:  These are
      advertised in L1 LSPs, in TLV 130.  The up/down bit is set to one,
      metric-type is external metric.  These IP prefixes are learned via
      L2 routing, and were derived during the L2 SPF computation from
      prefixes advertised in L2 LSPs in TLV 130 with external metrics.

Notes:

The following part has been corrected:

"These IP prefixes are learned via
L2 routing, and were derived during the L1 (should be L2) SPF computation from
prefixes advertised in L2 LSPs in TLV 130 with external metrics."

The IP prefixes which are learned via L2 routing were derived during L2 SPF computation instead of L1 SPF computation from prefixes advertised in L2 LSPs. As these prefixes were originally advertised in L2 area hence the SPF for these prefixes should run on the L2 LSPs and eventually the prefixes derived through L2 LSP should be leaked into L1 area.

Status: Held for Document Update (2)

RFC 5302, "Domain-Wide Prefix Distribution with Two-Level IS-IS", October 2008

Source of RFC: isis (rtg)

Errata ID: 1541

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-10-08
Held for Document Update by: Adrian Farrel
Date Held: 2012-08-09

Section 3.1,1st para says:

   The combination IP Internal Reachability Information and external
   metric-type is not allowed.  Also, the up/down bit MUST NOT be set in
|  L2 LSPs.  This leaves us with 8 different types of IP advertisements
|  in IS-IS.  However, there are more than 8 reasons for IP prefixes to
   be advertised in IS-IS.  The following list describes the types of IP
   prefixes and how they are encoded.

It should say:

   The combination IP Internal Reachability Information and external
   metric-type is not allowed.  Also, the up/down bit MUST NOT be set in
|  L2 LSPs.  This leaves us with 9 different types of IP advertisements
|  in IS-IS.  However, there are more than 9 reasons for IP prefixes to
   be advertised in IS-IS.  The following list describes the types of IP
   prefixes and how they are encoded.

Notes:

Rationale:
Each of the two restrictions mentioned in the initial part
of the quoted paragraph indeed excludes 4 possibilities
of the original set of 16 combinations. However, these
restrictions are not exclusive; they overlap in one case,
thus reducing the number of forbidden combinations to 7.

Therefore, we are left with *9* different types of combinations.

This can also be seen from the subsequent list of 12 items
(unfortunately, the numbering of these has been lost on the way
from RFC 2966 to its successor). That list contains 3 pairs of
entries, i.e. 6 entries that contain the wording
"These prefixes cannot be distinguished from ... routes." ,
thus reducing the number of distinguishable cases from 12 to 9.

Virtually restoring the list item numbering as (1) ... (12),
the following table shows a decision matrix:

+----------------------+---------------+-------------------+
| Metric U/D \ Level | L1 | L2 |
| Type Bit \ TLV# | 128 | 130 | 128 | 130 |
+----------------------+-------+-------+---------+---------+
| 0 | (1) | (2) | (3),(5) | (4),(6) |
| Int --------------+-------+-------+---------+---------+
| 1 | (7) | (8) | N/A | N/A |
+----------------------+-------+-------+---------+---------+
| 0 | N/A | (9) | N/A |(10),(11)|
| Ext --------------+-------+-------+---------+---------+
| 1 | N/A | (12) | N/A | N/A |
+----------------------+-------+-------+---------+---------+

Errata ID: 1542

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-10-08
Held for Document Update by: Stewart Bryant

Section 5, 2nd para says:

                                              [...].  In this case, the
   solution defined in this document, which requires only an upgrade of
   L1L2 routers in selected areas, might be a good alternative to the
|  solution defined in 5305.

It should say:

                                              [...].  In this case, the
   solution defined in this document, which requires only an upgrade of
   L1L2 routers in selected areas, might be a good alternative to the
|  solution defined in RFC 5305.
                       ^^^^

Notes:

Rationale: inconsistent, too colloquial verbiage.

Report New Errata



Search RFCs
Advanced Search
×