RFC Errata
Found 11 records.
Status: Verified (1)
RFC 5036, "LDP Specification", October 2007
Note: This RFC has been updated by RFC 6720, RFC 6790, RFC 7358, RFC 7552
Source of RFC: mpls (rtg)
Errata ID: 3156
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
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 (6)
RFC 5036, "LDP Specification", October 2007
Note: This RFC has been updated by RFC 6720, RFC 6790, RFC 7358, RFC 7552
Source of RFC: mpls (rtg)
Errata ID: 2133
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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"
Errata ID: 5587
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna Rao DTV
Date Reported: 2018-12-28
Held for Document Update by: Deborah Brungard
Date Held: 2019-01-08
Section 2.6.2.2 says:
"In Downstream Unsolicited advertisement mode, label mapping advertisements for all routes may be received from all LDP peers. When using Liberal Label retention, every label mappings received from a peer LSR is retained regardless of whether the LSR is the next hop for the advertised mapping..."
It should say:
"In Downstream Unsolicited advertisement mode, label mapping advertisements for all routes may be received from all LDP peers. When using Liberal Label retention, every label mapping received from a peer LSR is retained regardless of whether the LSR is the next hop for the advertised mapping..."
Notes:
s/mappings/mapping/
Errata ID: 5674
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna Rao DTV
Date Reported: 2019-03-25
Held for Document Update by: Deborah Brungard
Date Held: 2019-05-30
Section A.2.8 says:
- FEC. The FEC for which a label request is to be sent.
It should say:
- FEC. The FEC for which a label mapping is to be sent.
Notes:
Prepare_Label_Mapping_Attributes is used for sending label mapping message and
NOT label request message.
Status: Rejected (4)
RFC 5036, "LDP Specification", October 2007
Note: This RFC has been updated by RFC 6720, RFC 6790, RFC 7358, RFC 7552
Source of RFC: mpls (rtg)
Errata ID: 3416
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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.
Errata ID: 5597
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna Rao DTV
Date Reported: 2019-01-10
Rejected by: Deborah Brungard
Date Rejected: 2019-01-10
Section 2.5.3 says:
The session establishment setup attempt following a NAK'd Initialization message MUST be delayed no less than 15 seconds, and subsequent delays MUST grow to a maximum delay of no less than 2 minutes. The specific session establishment action that must be delayed is the attempt to open the session transport connection by the LSR playing the active role.
It should say:
The session establishment setup attempt following a NAK'd Initialization message MUST be delayed no less than 15 seconds, and subsequent delays MUST grow to a maximum delay of no more than 2 minutes. The specific session establishment action that must be delayed is the attempt to open the session transport connection by the LSR playing the active role.
Notes:
In the 3rd line, "less" is changed to "more".
The intention is to cap the maximum delay. But the existing text implies no cap
essentially.
--VERIFIER NOTES--
This change is a technical change as it changes from no cap to a cap of 2 minutes. This request needs to go via the consensus process (e.g. RFC).