|
|
|
|
Found 4 records.
Errata ID: 150
Status: Reported
Type: Technical
Reported By: Nikolai Malykh
Date Reported: 2006-01-26
Section 9.1.1 says:
The Phase 1 decision function is a separate process,f which completes when it has no further work to do.
It should say:
The Phase 1 decision function is a separate process, which completes when it has no further work to do.
Errata ID: 1332
Status: Reported
Type: Technical
Reported By: Aaron Hughes
Date Reported: 2008-02-26
Section 4.5 says:
OPEN Message Error subcodes:
1 - Unsupported Version Number.
2 - Bad Peer AS.
3 - Bad BGP Identifier.
4 - Unsupported Optional Parameter.
5 - [Deprecated - see Appendix A].
6 - Unacceptable Hold Time.
It should say:
OPEN Message Error subcodes:
1 - Unsupported Version Number.
2 - Bad Peer AS.
3 - Bad BGP Identifier.
4 - Unsupported Optional Parameter.
5 - [Deprecated - see Appendix A].
6 - Unacceptable Hold Time.
7 - Unsupported Capability
Notes:
7 - Unsupported Capability orig from RFC3392 seems to have accidently disappeared.
Thanks!
Aaron
Errata ID: 1633
Status: Reported
Type: Technical
Reported By: John Scudder
Date Reported: 2008-12-12
Section 6.3 says:
If an optional attribute is recognized, then the value of this attribute MUST be checked. If an error is detected, the attribute MUST be discarded, and the Error Subcode MUST be set to Optional Attribute Error. The Data field MUST contain the attribute (type, length, and value).
It should say:
If an optional attribute is recognized, then the value of this attribute MUST be checked. If an error is detected, the Error Subcode MUST be set to Optional Attribute Error. The Data field MUST contain the attribute (type, length, and value).
Notes:
This simply removes the clause "the attribute MUST be discarded", which doesn't make sense since the peering is to be terminated anyway.
Errata ID: 149
Status: Reported
Type: Editorial
Reported By: Alfred Hoenes
Date Reported: 2006-07-09
(1) [missing articles]
In Section 4.1, the third paragraph on page 7 says:
In pre-OTN networks, a failure may be masked by intermediate O-E-O
based Optical Line System (OLS), preventing a Photonic Cross-Connect
(PXC) from detecting upstream failures. In such cases, failure
detection may be assisted by an out-of-band communication channel,
and failure condition may be reported to the PXC control plane. This
can be provided by using [RFC4209] extensions that deliver IP
message-based communication between the PXC and the OLS control
plane. [...]
It should say:
| In pre-OTN networks, a failure may be masked by an intermediate O-E-O
based Optical Line System (OLS), preventing a Photonic Cross-Connect
(PXC) from detecting upstream failures. In such cases, failure
detection may be assisted by an out-of-band communication channel,
| and a failure condition may be reported to the PXC control plane.
This can be provided by using [RFC4209] extensions that deliver IP
message-based communication between the PXC and the OLS control
plane. [...]
(2) [unexpected break]
Again on page 7, later on in the same paragraph as mentioned above,
the RFC says:
[...]. If the intermediate OLS supports electrical (digital)
mechanisms, using the LMP communication channel, these failure
| conditions are reported to
|
the PXC and subsequent recovery actions are performed as described in
Section 5. As such, from the control plane viewpoint, this mechanism
turns the OLS-PXC-composed system into a single logical entity, thus
having the same failure management mechanisms as any other O-E-O
capable device.
It should say:
[...]. If the intermediate OLS supports electrical (digital)
mechanisms, using the LMP communication channel, these failure
| conditions are reported to the PXC and subsequent recovery actions
are performed as described in Section 5. As such, from the control
plane viewpoint, this mechanism turns the OLS-PXC-composed system
into a single logical entity, thus having the same failure management
mechanisms as any other O-E-O capable device.
(3) [incomplete wording]
At the end of Section 4.1, in the last bullet, on page 8, the RFC says:
o with out-of-band communication between entities: entities are
physically separated, but an out-of-band communication channel is
provided between them (e.g., using [RFCF4204]).
It should say:
o with out-of-band communication between entities: entities are
physically separated, but an out-of-band communication channel is
| provided between them (e.g., using LMP [RFCF4204]).
(4) [unexpected blank line]
In Section 5.5.1, the diagram for option '2. Overbooking', near the
bottom of page 22, suffers from an unexpected blank line.
The RFC says:
+----- Dedicated (for instance: 1+1, 1:1, etc.)
|
|
|
+----- Shared (for instance: 1:N, M:N, etc.)
|
Level of |
Overbooking -----+----- Unprotected (for instance: 0:1, 0:N)
It should say:
+----- Dedicated (for instance: 1+1, 1:1, etc.)
|
|
+----- Shared (for instance: 1:N, M:N, etc.)
|
Level of |
Overbooking -----+----- Unprotected (for instance: 0:1, 0:N)
(5) [typo: missing underscore]
In Section 7.2, the second-to-last paragraph on page 29 says:
In SONET/SDH environments, one typically considers the VT_SPE/LOVC
and STS SPE/HOVC as independent layers (for example, VT_SPE/LOVC LSP
uses the underlying STS_SPE/HOVC LSPs as links). [...]
It should say:
In SONET/SDH environments, one typically considers the VT_SPE/LOVC
| and STS_SPE/HOVC as independent layers (for example, VT_SPE/LOVC LSP
uses the underlying STS_SPE/HOVC LSPs as links). [...]
(6) [singular-->plural]
In Section 8, the second-to-last paragraph on page 33 says:
[...]. For instance, it is obvious that
providing a 1+1 LSP protection minimizes the LSP downtime (in case of
| failure) while being non-scalable and consuming recovery resource
without enabling any extra-traffic.
^^
It should say:
[...]. For instance, it is obvious that
providing a 1+1 LSP protection minimizes the LSP downtime (in case of
| failure) while being non-scalable and consuming recovery resources
without enabling any extra-traffic.
(7) [singular-->plural]
The third paragraph of Section 8.2, on page 34, says:
[...]. Dynamic restoration enables on-demand
path computation based on the information received through failure
notification message, and as such, it is more robust with respect to
the failure scenario scope.
It should say:
[...]. Dynamic restoration enables on-demand
path computation based on the information received through failure
| notification messages, and as such, it is more robust with respect to
the failure scenario scope.
(8) [singular-->plural]
At the bottom of page 35, Section 8.3 of RFC 4428 says:
[...]. Recovery schemes, in particular
restoration, with pre-signaled resource reservation (with or without
pre-selection) should be capable of reserving an adequate amount of
resource to ensure recovery from any specific set of failure events,
such as any single SRLG failure, any two SRLG failures, etc.
It should say:
[...]. Recovery schemes, in particular
restoration, with pre-signaled resource reservation (with or without
pre-selection) should be capable of reserving an adequate amount of
| resources to ensure recovery from any specific set of failure events,
such as any single SRLG failure, any two SRLG failures, etc.
(9) [punctuation: adjustment for 'logical quoting']
In Section 12.2, some Informative References, as found in the RFC,
do not conform to the RFC style guidelines regarding 'logical quoting'.
E.g., the RFC says, at the bottom of page 44:
[BOUILLET] E. Bouillet, et al., "Stochastic Approaches to Compute
Shared Meshed Restored Lightpaths in Optical Network
| Architectures," IEEE Infocom 2002, New York City, June
2002.
^^
It should say:
[BOUILLET] E. Bouillet, et al., "Stochastic Approaches to Compute
Shared Meshed Restored Lightpaths in Optical Network
| Architectures", IEEE Infocom 2002, New York City, June
2002.
Similar changes should be applied to the following entries on page 45:
[DEMEESTER]
[GLI]
[KODIALAM1]
[KODIALAM2]
[MANCHESTER]
[T1.105]
[WANG]
[G.707]
[G.709]
and on page 46:
[G.783]
[G.798]
[G.841]
[G.842]
[G.874]
Notes:
from pending