RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (2)

RFC 6822, "IS-IS Multi-Instance", December 2012

Note: This RFC has been obsoleted by RFC 8202

Source of RFC: isis (rtg)

Errata ID: 4519
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Alexander Okonnikov
Date Reported: 2015-11-02
Verifier Name: Alia Atlas
Date Verified: 2015-11-11

Section 2.4.1 and 4 says:

   MI-RTRs include the IID-TLV in the point-to-point Hello PDUs they
   originate.

------------------------------
Also in Section 4:

The following subsections describe the additional rules
   an MI-RTR MUST follow when establishing adjacencies.

It should say:

MI-RTRs include the IID-TLV in the point-to-point Hello PDUs associated
with non-zero instances that they originate.

-----------------------------
In Section 4:

The following subsections describe the additional rules an MI-RTR MUST
follow when establishing adjacencies for non-zero instances.

Notes:

The exception case (point-to-point hellos on a point-to-point IIHs on a point-to-point circuit (sic)) is discussed in Section 2.6.2.
The proposed text is therefore unnecessary. However, clarification is useful.

Errata ID: 4520
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Alexander Okonnikov
Date Reported: 2015-11-02
Verifier Name: Alia Atlas
Date Verified: 2015-11-11

Section 2.6.1 says:

   An MI-RTR will use the AllL1IS or AllL2IS ISIS MAC-layer address (as
   defined in [ISO10589]) as the destination address when sending an
   IS-IS PDU for the standard instance.  An MI-RTR will use one of two
   new dedicated layer 2 multicast addresses (AllL1MI-ISs or AllL2MI-
   ISs) as the destination address when sending an IS-IS PDU for any
   non-zero IID.  These addresses are specified in Section 6.  If
   operating in point-to-point mode on a broadcast circuit [RFC5309], an
   MI-RTR MUST use one of the two new multicast addresses as the
   destination address when sending point-to-point IIHs associated with
   a non-zero instance.  (Either address will do.)

   MI-RTRs MUST discard IS-IS PDUs received if either of the following
   is true:

   o  The destination multicast address is AllL1IS or AllL2IS and the
      PDU contains an IID-TLV.

   o  The destination multicast address is one of the two new addresses,
      and the PDU contains an IID-TLV with a zero value for the IID or
      has no IID-TLV.

   NOTE: If the multicast addresses AllL1IS and/or AllL2IS are
   improperly used to send IS-IS PDUs for non-zero IIDs, legacy systems
   will interpret these PDUs as being associated with IID #0.  This will
   cause inconsistencies in the LSDB in those routers, may incorrectly
   maintain adjacencies, and may lead to inconsistent DIS election.

It should say:

   An MI-RTR will use the AllL1ISs or AllL2ISs ISIS MAC-layer address
   (as defined in [ISO10589]) as the destination address when sending
   an IS-IS PDU for the standard instance.  An MI-RTR will use one of
   two new dedicated layer 2 multicast addresses (AllL1MI-ISs or
   AllL2MI-ISs) as the destination address when sending an IS-IS PDU
   for any non-zero IID.  These addresses are specified in Section 6.

   If operating in point-to-point mode on a broadcast circuit
   [RFC5309], an MI-RTR will use the AllL1ISs, AllL2ISs or AllISs
   MAC-layer address (as defined in [ISO10589]) as the destination
   address when sending an IS-IS PDU for the standard instance,
   and will use one of two new multicast addresses (AllL1MI-ISs or
   AllL2MI-ISs; either address will do) as the destination address
   when sending an IS-IS PDU for any non-zero IID.

   MI-RTRs MUST discard IS-IS PDUs received if either of the    
   following is true:

   o  The destination multicast address is AllL1ISs, AllL2ISs or 
      AllISs and the PDU contains an IID-TLV.

   o  The destination multicast address is one of the two new 
      addresses and the PDU contains an IID-TLV with a zero value for 
      the IID or has no IID-TLV.

   NOTE: If the multicast addresses AllL1ISs and/or AllL2ISs and/or 
   AllISs are improperly used to send IS-IS PDUs for non-zero IIDs, 
   legacy systems will interpret these PDUs as being associated with 
   IID #0.  This will cause inconsistencies in the LSDB in those 
   routers, may incorrectly maintain adjacencies, and may lead to 
   inconsistent DIS election.

Notes:

1. While operating in point-to-point mode over broadcast circuit, MI-RTR can use any of three multicast addresses for PDUs in standard instance - AllL1ISs, AllL2ISs or AllISs.

2. New multicast addresses must be used for all kinds of IS-IS PDUs, not only for IIHs

3. AllL1IS and AllL2IS are replaced by AllL1ISs and AllL2ISs, respectively (according to ISO 10589:2002).

Status: Held for Document Update (1)

RFC 6822, "IS-IS Multi-Instance", December 2012

Note: This RFC has been obsoleted by RFC 8202

Source of RFC: isis (rtg)

Errata ID: 4521
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Alexander Okonnikov
Date Reported: 2015-11-02
Held for Document Update by: Alia Atlas
Date Held: 2015-11-11

Section 2.6.2 says:

   In order for an MI-RTR to interoperate over a point-to-point 
   circuit with a router that does NOT support this extension, the 
   MI-RTR MUST NOT send IS-IS PDUs for instances other than IID #0 
   over the point-to-point circuit as these PDUs may affect the state 
   of IID #0 in the neighbor.

It should say:

   Note: The procedure below should not be used when MI-RTR is 
   operating in point-to-point mode over broadcast circuit 
   [RFC 5309].

   In order for an MI-RTR to interoperate over a point-to-point 
   circuit with a router that does NOT support this extension, the 
   MI-RTR MUST NOT send IS-IS PDUs for instances other than IID #0 
   over the point-to-point circuit as these PDUs may affect the state 
   of IID #0 in the neighbor.

Notes:

In Section 2.6.1, it clearly says "If operating in point-to-point mode on a broadcast circuit [RFC5309]" which reinforces that Section 2.6.2 is about point-to-point circuits and not broadcast circuits.

However, there isn't any harm in adding a bit of clarity going forward. This can be looked at if and when RFC 6822 is updated.

Report New Errata



Advanced Search