RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 8 records.

Status: Verified (1)

RFC 5036, "LDP Specification", October 2007

Source of RFC: mpls (rtg)

Errata ID: 3156

Status: Verified
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2012-03-15
Verifier Name: Adrian Farrel
Date Verified: 2012-03-17

Section 3.5.8 says:

   Path Vector
      Specifies the LSRs along the LSR being set up by the Label Request
      message.  Section "Path Vector Procedures" describes how to handle
      this TLV.

It should say:

   Path Vector
      Specifies the LSRs along the LSP being set up by the Label Request
      message.  Section "Path Vector Procedures" describes how to handle
      this TLV.

Notes:

Erroneously typed LSR instead of the LSP.

Status: Held for Document Update (4)

RFC 5036, "LDP Specification", October 2007

Source of RFC: mpls (rtg)

Errata ID: 2133

Status: Held for Document Update
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2010-04-07
Held for Document Update by: Adrian Farrel

Section 2.5.4 says:

   NON EXISTENT  Session TCP connection established  INITIALIZED
                 established


It should say:

   NON EXISTENT  Session TCP connection established  INITIALIZED


Errata ID: 3155

Status: Held for Document Update
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2012-03-12
Held for Document Update by: Adrian Farrel

Section 3.5.1.2.1 says:

      -  The LDP protocol version is not supported by the receiver, d or
         it is supported but is not the version negotiated for the
         session during session establishment.  This is a fatal error
         signaled by the Bad Protocol Version Status Code.


It should say:

      -  The LDP protocol version is not supported by the receiver, or
         it is supported but is not the version negotiated for the
         session during session establishment.  This is a fatal error
         signaled by the Bad Protocol Version Status Code.


Errata ID: 3415

Status: Held for Document Update
Type: Editorial

Reported By: Jeff Wheeler
Date Reported: 2012-11-26
Held for Document Update by: Adrian Farrel
Date Held: 2012-11-26

Section 3.1 says:

Prior to completion of the negotiation, the
maximum allowable length is 4096 bytes.

It should say:

Prior to completion of the negotiation, the
maximum allowable length is 4096 octets.

Notes:

"octets" instead of "bytes"
Although "octet" is technically correct, there will be little confusion caused by the use of "byte"

Errata ID: 3425

Status: Held for Document Update
Type: Editorial

Reported By: Jeff Wheeler
Date Reported: 2012-12-08
Held for Document Update by: Adrian Farrel

Section 3.5 says:

The specification assigns type values for related messages, such as
the Label messages, from of a contiguous block in the 16-bit message
type number space.

It should say:

The specification assigns type values for related messages, such as
the Label messages, from a contiguous block in the 16-bit message
type number space.

Notes:

"from of a contiguous block" changed to "from a contiguous block"

Status: Rejected (3)

RFC 5036, "LDP Specification", October 2007

Source of RFC: mpls (rtg)

Errata ID: 3416

Status: Rejected
Type: Technical

Reported By: Jeff Wheeler
Date Reported: 2012-11-26
Rejected by: Adrian Farrel
Date Rejected: 2012-11-26

Section 3.1 says:

For a platform-wide label space, these SHOULD both be zero.

It should say:

For a platform-wide label space, these MUST both be zero.

Notes:

See Section 2.2.2 text, "The last two octets of LDP Identifiers for platform-wide label spaces are always both zero."
--VERIFIER NOTES--
The text in 2.2.2 is descriptive of the LDP identifiers, but not a requirement. The text in 3.1 describes how the LDP identifier is constructed.

The purpose of the "SHOULD" is to direct normal behavior, but not to absolutely require the use of zero in these two octets if a good reason can be found.

Furthermore, there is nothing that would actually prohibit the use of non-zero values. The identifier of a label space is a local matter and another node, seeing a label space identifier, should not make any assumptions about the label space (e.g., it being a global label space or not), nor should it really matter.

Errata ID: 4465

Status: Rejected
Type: Technical

Reported By: Guijuan Wang
Date Reported: 2015-09-05
Rejected by: Deborah Brungard
Date Rejected: 2015-11-18

Section 3.5.3 says:

The first rule: 
In section 3.5.3 
   A, Label Advertisement Discipline
         [omitting the first paragraph]

         If one LSR proposes Downstream Unsolicited and the other
         proposes Downstream on Demand, the rules for resolving this
         difference is:

         -  If the session is for a label-controlled ATM link or a
            label-controlled Frame Relay link, then Downstream on Demand
            MUST be used.

         -  Otherwise, Downstream Unsolicited MUST be used.


The second rule: 
In section 3.5.7.1.3.

   In general, the upstream LSR is responsible for requesting label
   mappings when operating in Downstream on Demand mode.  However,
   unless some rules are followed, it is possible for neighboring LSRs
   with different advertisement modes to get into a livelock situation
   where everything is functioning properly, but no labels are 
   distributed.  For example, consider two LSRs Ru and Rd where Ru is
   the upstream LSR and Rd is the downstream LSR for a particular FEC.
   In this example, Ru is using Downstream Unsolicited advertisement
   mode and Rd is using Downstream on Demand mode.  In this case, Rd may
   assume that Ru will request a label mapping when it wants one and Ru
   may assume that Rd will advertise a label if it wants Ru to use one.
   If Rd and Ru operate as suggested, no labels will be distributed from
   Rd to Ru.

   This livelock situation can be avoided if the following rule is
   observed: an LSR operating in Downstream on Demand mode SHOULD NOT be
   expected to send unsolicited mapping advertisements.  Therefore, if
   the downstream LSR is operating in Downstream on Demand mode, the
   upstream LSR is responsible for requesting label mappings as needed.

It should say:

[not provided]

Notes:

Label advertisement mode negotiation rule is different in two sections.

when the label advertisement mode is different between LSR peers,
the resolving rule is defined twice in two chapters,
both use "must" or "SHOULD NOT", but they are completely different.

It's better to settle down which rule to use for this case.
Seems the first one is simpler for implementation.

Or if you want to keep both rules,
better to enumerate both of those two rules in each section,
and say the implementer can choose any of them.

--VERIFIER NOTES--
This suggested errata requires an update to the RFC, which requires consensus.

Errata ID: 4512

Status: Rejected
Type: Technical

Reported By: Jiessie
Date Reported: 2015-10-26
Rejected by: Deborah Brungard
Date Rejected: 2015-11-18

Section 2.5.2 says:

2.4.1.  Basic Discovery Mechanism

   To engage in LDP Basic Discovery on an interface, an LSR periodically
   sends LDP Link Hellos out the interface.  LDP Link Hellos are sent as
   UDP packets addressed to the well-known LDP discovery port for the
   "all routers on this subnet" group multicast address.


2.5.2.  Transport Connection Establishment

   Note that when an LSR sends a Hello, it selects the transport address
   for its end of the session connection and uses the Hello to advertise
   the address, either explicitly by including it in an optional
   Transport Address TLV or implicitly by omitting the TLV and using it
   as the Hello source address.

Notes:

According to 2.4.1, an LSR send Hellos to "all routers on this subnet", the eligible reception LSR should be on this subnet.

2.5.2 states that one way for an LSR to advertise Transport Address is to uses it as Hello source address.

On the topology below, LSRa uses 1.1.1.1 as Transport Address and sends Hello(source:1.1.1.1 destination:224.0.0.2) to LSRb.
LSRb will ignore this packet which is not on its interface subnet.

1.1.1.1
|LSRa|--------------|LSRb|
10.1.1.1 10.1.1.2

My question is:
What's the scenario to use "implicitly" way to send Hello?
--VERIFIER NOTES--
This is not an errata, it is a question to be asked on the MPLS mailing list.

Report New Errata



Search RFCs
Advanced Search
×