RFC Errata
Found 4 records.
Status: Held for Document Update (4)
RFC 3746, "Forwarding and Control Element Separation (ForCES) Framework", April 2004
Source of RFC: forces (rtg)
Errata ID: 5337
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-04-27
Held for Document Update by: Martin Vigoureux
Date Held: 2019-09-09
Section 5 says:
[4] Section 5, requirement #9 dictates "Any proposed ForCES
It should say:
[4] Section 4, requirement #9 dictates "Any proposed ForCES
Notes:
Incorrect reference to Section 5.
[Additional notes added at status change]
In fact The 5 to 4 change need to also be applied to these:
(see [4], Section 5, requirement #6)
(see [4] Section 5, requirement #11)
(See [4], Section 5, Requirement #3)
(see [4] Section 5, requirement #1)
(see [4] Section 5, requirements #12)
(see [4] Section 5, requirement #7)
Errata ID: 5338
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-04-27
Held for Document Update by: Martin Vigoureux
Date Held: 2019-09-09
Section 3.2 says:
a change via asynchronous messages (see [4], Section 5, requirement #6). ... This architecture permits multiple FEs to be present in an NE. [4] dictates that the ForCES Protocol must be able to scale to at least hundreds of FEs (see [4] Section 5, requirement #11). Each of these FEs may potentially have a different set of packet processing ... When multiple FEs are present, ForCES requires that packets must be able to arrive at the NE by one FE and leave the NE via a different FE (See [4], Section 5, Requirement #3). Packets that enter the NE
It should say:
a change via asynchronous messages (see [4], Section 4, requirement #6). ... This architecture permits multiple FEs to be present in an NE. [4] dictates that the ForCES Protocol must be able to scale to at least hundreds of FEs (see [4] Section 4, requirement #11). Each of these FEs may potentially have a different set of packet processing ... When multiple FEs are present, ForCES requires that packets must be able to arrive at the NE by one FE and leave the NE via a different FE (See [4], Section 4, Requirement #3). Packets that enter the NE
Notes:
Incorrect reference to Section 5.
see also: https://www.rfc-editor.org/verify_errata_select.php?eid=5338
Errata ID: 5339
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-04-27
Held for Document Update by: Martin Vigoureux
Date Held: 2019-09-09
Section 4.2.1 says:
The ForCES Working Group has made a conscious decision that the first version of ForCES will be focused on "very close" CE/FE localities in IP networks. Very Close localities consist of control and forwarding elements that are either components in the same physical box, or separated at most by one local network hop ([8]). CEs and FEs can be connected by a variety of interconnect technologies, including Ethernet connections, backplanes, ATM (cell) fabrics, etc. ForCES should be able to support each of these interconnects (see [4] Section 5, requirement #1). When the CEs and FEs are separated beyond a single L3 routing hop, the ForCES Protocol will make use of an existing RFC 2914 [3] compliant L4 protocol with adequate reliability, security, and congestion control (e.g., TCP, SCTP) for transport purposes.
It should say:
The ForCES Working Group has made a conscious decision that the first version of ForCES will be focused on "very close" CE/FE localities in IP networks. Very Close localities consist of control and forwarding elements that are either components in the same physical box, or separated at most by one local network hop ([8]). CEs and FEs can be connected by a variety of interconnect technologies, including Ethernet connections, backplanes, ATM (cell) fabrics, etc. ForCES should be able to support each of these interconnects (see [4] Section 4, requirement #1). When the CEs and FEs are separated beyond a single L3 routing hop, the ForCES Protocol will make use of an existing RFC 2914 [3] compliant L4 protocol with adequate reliability, security, and congestion control (e.g., TCP, SCTP) for transport purposes.
Notes:
https://www.rfc-editor.org/errata/eid5337
Errata ID: 5340
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2018-04-27
Held for Document Update by: Martin Vigoureux
Date Held: 2019-09-09
Section 4.3 says:
FEs and CEs may join and leave NEs dynamically (see [4] Section 5, requirements #12). When an FE or CE leaves the NE, the association with the NE is broken. If the leaving party rejoins an NE later, to re-establish the association, it may need to re-enter the pre- association phase. Loss of association can also happen unexpectedly due to a loss of connection between the CE and the FE. Therefore, the framework allows the bi-directional transition between these two phases, but the ForCES Protocol is only applicable for the post- association phase. However, the protocol should provide mechanisms to support association re-establishment. This includes the ability for CEs and FEs to determine when there is a loss of association between them, and to restore association and efficient state (re)synchronization mechanisms (see [4] Section 5, requirement #7). Note that security association and state must also be re-established to guarantee the same level of security (including both authentication and authorization) exists before and after the association re-establishment.
It should say:
FEs and CEs may join and leave NEs dynamically (see [4] Section 4, requirements #12). When an FE or CE leaves the NE, the association with the NE is broken. If the leaving party rejoins an NE later, to re-establish the association, it may need to re-enter the pre- association phase. Loss of association can also happen unexpectedly due to a loss of connection between the CE and the FE. Therefore, the framework allows the bi-directional transition between these two phases, but the ForCES Protocol is only applicable for the post- association phase. However, the protocol should provide mechanisms to support association re-establishment. This includes the ability for CEs and FEs to determine when there is a loss of association between them, and to restore association and efficient state (re)synchronization mechanisms (see [4] Section 4, requirement #7). Note that security association and state must also be re-established to guarantee the same level of security (including both authentication and authorization) exists before and after the association re-establishment.
Notes:
Incorrect reference to Section 5.
https://www.rfc-editor.org/errata/eid5337