RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (1)

RFC 8013, "Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)", February 2017

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rtg

Errata ID: 5357
Status: Verified
Type: Editorial

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: Reported (2)

RFC 8013, "Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)", February 2017

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: rtg

Errata ID: 5358
Status: Reported
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2018-05-13

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.

Errata ID: 5363
Status: Reported
Type: Editorial

Reported By: Nikolai Malykh
Date Reported: 2018-05-18

Section 3.2.8 says:

   An interesting issue related to class inheritance is backward
   compatibility between a descendant and an ancestor class.  Consider
   the following hypothetical scenario where a standardized LFB class
   "L1" exists.  Vendor A builds an FE that implements LFB "L1", and
   vendor B builds a CE that can recognize and operate on LFB "L1".
   Suppose that a new LFB class, "L2", is defined based on the existing
   "L1" class by extending its capabilities incrementally.  Let us
   examine the FE backward-compatibility issue by considering what would
   happen if vendor B upgrades its FE from "L1" to "L2" and vendor C's





Halpern & Hadi Salim         Standards Track                   [Page 29]

RFC 5812                     ForCES FE Model                  March 2010


   CE is not changed.  The old L1-based CE can interoperate with the new
   L2-based FE if the derived LFB class "L2" is indeed backward
   compatible with the base class "L1".

It should say:

   An interesting issue related to class inheritance is backward
   compatibility between a descendant and an ancestor class.  Consider
   the following hypothetical scenario where a standardized LFB class
   "L1" exists.  Vendor A builds an FE that implements LFB "L1", and
   vendor B builds a CE that can recognize and operate on LFB "L1".
   Suppose that a new LFB class, "L2", is defined based on the existing
   "L1" class by extending its capabilities incrementally.  Let us
   examine the FE backward-compatibility issue by considering what would
   happen if vendor A upgrades its FE from "L1" to "L2" and vendor B's





Halpern & Hadi Salim         Standards Track                   [Page 29]

RFC 5812                     ForCES FE Model                  March 2010


   CE is not changed.  The old L1-based CE can interoperate with the new
   L2-based FE if the derived LFB class "L2" is indeed backward
   compatible with the base class "L1".

Notes:

Confusion in the notation of vendors.

Report New Errata