(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 (according to the Verifier):
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 [RFC4204]).
(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 (according to the Verifier):
[...]. Dynamic restoration enables on-demand
path computation based on the information received through failure
| notification message(s), 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]