RFC Errata
Found 4 records.
Status: Verified (1)
RFC 6371, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", September 2011
Note: This RFC has been updated by RFC 6435
Source of RFC: mpls (rtg)
Errata ID: 3956
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Liu Lin
Date Reported: 2014-04-10
Verifier Name: Adrian Farrel
Date Verified: 2014-04-11
Section 3.2 says:
When an SPME is instantiated after the transport path has been instantiated, the TTL distance to the MIPs may change for the short-pipe model of TTL copying, and may change for the uniform model if the SPME is not co-routed with the original path.
It should say:
When an SPME is instantiated after the transport path has been instantiated, the TTL distance to the MIPs may change for the short-pipe model, and may change for the uniform model if the SPME is not co-routed with the original path.
Notes:
The original report notes that there is no TTL copying in short-pipe model and states confusion arising from the text. The suggestion was to change it to:
When an SPME is instantiated after the transport path has been
instantiated, the TTL distance to the MIPs may change for the
short-pipe model of no TTL copying, and may change for the uniform
model if the SPME is not co-routed with the original path.
The authors point out that the TTL copying mode in short-pipe is "no copying". This is true, but leaves some potential confusion in the text.
The corrected text removes all mention of TTL copying (which is not relevant in this case).
Status: Held for Document Update (3)
RFC 6371, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", September 2011
Note: This RFC has been updated by RFC 6435
Source of RFC: mpls (rtg)
Errata ID: 3958
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Liu Lin
Date Reported: 2014-04-11
Held for Document Update by: Adrian Farrel
Date Held: 2014-04-11
Section 3.3 says:
Figure 3 describes four examples of per-interface Up MEPs: an Up Source MEP in a source node (case 1), an Up Sink MEP in a destination node (case 2), a Down Source MEP in a source node (case 3), and a Down Sink MEP in a destination node (case 4).
It should say:
Figure 3 describes four examples of per-interface MEPs: an Up Source MEP in a source node (case 1), an Up Sink MEP in a destination node (case 2), a Down Source MEP in a source node (case 3), and a Down Sink MEP in a destination node (case 4).
Notes:
per-interface Up MEPs ----> per-interface MEPs
The four instances listed include Up and Down MEPs, so the text should be more general.
Errata ID: 3961
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Liu Lin
Date Reported: 2014-04-11
Held for Document Update by: Adrian Farrel
Date Held: 2014-04-12
Section 3.7 says:
This packet will be delivered by the forwarding plane to all intermediate nodes at the same TTL distance of the target MIP and to any leaf that is located at a shorter distance.
It should say:
This packet will be delivered by the forwarding plane to all nodes at the same TTL distance as the target MIP and to any leaf that is located at a shorter distance.
Notes:
The packet will also be deliverd to any leaf that has the same TTL distance of the target MIP.
Errata ID: 3963
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Liu Lin
Date Reported: 2014-04-15
Held for Document Update by: Adrian Farrel
Date Held: 2014-04-15
Section 7.1.2 says:
The peer MEP, upon receiving an LKI removal request, can either accept or reject the removal instruction and replies with an LK removal reply OAM packet indicating whether or not it has accepted the instruction.
It should say:
The peer MEP, upon receiving an LKI removal request, can either accept or reject the removal instruction and replies with an LKI removal reply OAM packet indicating whether or not it has accepted the instruction.
Notes:
LK ---> LKI