Found 1 record.

Status: Verified (1)

RFC 4428, "Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration)", March 2006

Errata ID: 94
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-12
Verifier Name: Dimitri Papadimitriou
Date Verified: 2006-08-14

(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]

Notes:

from pending

Report New Errata