RFC Errata
Found 3 records.
Status: Verified (2)
RFC 8013, "Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)", February 2017
Source of RFC: IETF - NON WORKING GROUPArea Assignment: rtg
Errata ID: 6938
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Pedro Tammela
Date Reported: 2022-04-19
Verifier Name: Alvaro Retana
Date Verified: 2022-04-20
Section 5.1.1 says:
Caution needs to be exercised on how low the resulting reported link MTU could be: for IPv4 packets, the minimum size is 64 octets [RFC791] and for IPv6 the minimum size is 1280 octets [RFC2460].
It should say:
Caution needs to be exercised on how low the resulting reported link MTU could be: for IPv4 the recommended minimum size is 576 octets [RFC1122] and for IPv6 the minimum size is 1280 octets [RFC2460].
Notes:
The original text mixed minimum packet size with minimum MTU size.
Errata ID: 5357
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-05-13
Verifier Name: RFC Editor
Date Verified: 2018-05-15
Section 5.1.1 says:
configuration. In essence, the control plane when explicitly making a decision for the MTU settings of the egress port is implicitly deciding how much metadata will be allowed. Caution needs to be exercised on how low the resulting reported link MTU could be: for IPv4 packets, the minimum size is 64 octets [RFC791] and for IPv6 the minimum size is 1280 octets [RFC2460].
It should say:
configuration). In essence, the control plane when explicitly making a decision for the MTU settings of the egress port is implicitly deciding how much metadata will be allowed. Caution needs to be exercised on how low the resulting reported link MTU could be: for IPv4 packets, the minimum size is 64 octets [RFC791] and for IPv6 the minimum size is 1280 octets [RFC2460].
Notes:
The closing parenthesis is missing.
Status: Held for Document Update (1)
RFC 8013, "Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)", February 2017
Source of RFC: IETF - NON WORKING GROUPArea Assignment: rtg
Errata ID: 5358
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-05-13
Held for Document Update by: Alvaro Retana
Date Held: 2020-07-21
Section 6.1 says:
The inter-FE LFB (instance) can be positioned at the ingress of a receiving FE. Figure 5 illustrates an example destination FE in the form of FE1. In such a case, an inter-FE LFB receives, via an LFB port in the IngressInGroup, an encapsulated Ethernet frame. Successful processing of the packet will result in a raw packet with associated metadata IDs going downstream to an LFB connected on OUT2. On failure, the data is sent out EXCEPTIONOUT.
It should say:
The inter-FE LFB (instance) can be positioned at the ingress of a receiving FE. Figure 5 illustrates an example destination FE in the form of FE2. In such a case, an inter-FE LFB receives, via an LFB port in the IngressInGroup, an encapsulated Ethernet frame. Successful processing of the packet will result in a raw packet with associated metadata IDs going downstream to an LFB connected on OUT2. On failure, the data is sent out EXCEPTIONOUT.
Notes:
Destination FE is FE2 not FE1.