Found 4 records.

Status: Verified (4)

RFC 7139, "GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks", March 2014

Note: This RFC has been updated by RFC 7892

Errata ID: 3944
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Fred Gruman
Date Reported: 2014-04-02
Verifier Name: Adrian Farrel
Date Verified: 2014-04-11

Section 5.1 says:

      ODUk.ts       Minimum          Nominal          Maximum
      -----------------------------------------------------------
      ODU2.ts    1,249,384.632    1,249,409.620     1,249,434.608
      ODU3.ts    1,254,678.635    1,254,703.729     1,254,728.823
      ODU4.ts    1,301,683.217    1,301,709.251     1,301,735.285

              Table 1: Actual TS Bit Rate of ODUk (in Kbps)

It should say:

      ODTUk.ts       Minimum          Nominal           Maximum
      ------------------------------------------------------------
      ODTU2.ts    1,249,384.632    1,249,409.620     1,249,434.608
      ODTU3.ts    1,254,678.635    1,254,703.729     1,254,728.823
      ODTU4.ts    1,301,683.217    1,301,709.251     1,301,735.285

              Table 1: Actual TS Bit Rate of ODUk (in Kbps)

Errata ID: 3945
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Fred Gruman
Date Reported: 2014-04-02
Verifier Name: Adrian Farrel
Date Verified: 2014-04-11

Section 7 says:

For the ingress node, a Path message with SE style SHOULD also be
sent for decreasing the ODUflex bandwidth.

It should say:

For the ingress node, a Path message with SE style MUST also be
sent for decreasing the ODUflex bandwidth.

Notes:

Section 7 requires that Shared Explicit (SE) MUST be used at the beginning when creating a resizable ODUflex connection. Thus, the SE style MUST also be used when signaling for bandwidth increase or decrease. The increase procedure mandates the use of SE style; however, the decrease procedure uses SHOULD. The decrease procedure should also make the SE signaling mandatory.

This change, that looks to be a change of substance, has been verified with the authors to be an editorial issue that was caused by not keeping the paragraphs in synch.

Errata ID: 3946
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Fred Gruman
Date Reported: 2014-04-02
Verifier Name: Adrian Farrel
Date Verified: 2014-04-11

Section 7 says:

After decreasing the bandwidth, the ingress node
SHOULD send a ResvErr message to tear down the old control state.

It should say:

After decreasing the bandwidth, the ingress node
SHOULD send a PathTear message to tear down the old control state.

Notes:

PathTear is the usual mechanism to teardown old control state. This is would also make the bandwidth decreasing procedure consistent with the bandwidth increasing procedure (bandwidth increasing procedure uses PathTear to teardown old control state.)

This change looks like a change of substance, but the authors confirm that their intent was to use the same process for both the increase and decrease in bandwidth.

Errata ID: 3928
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adrian Farrel
Date Reported: 2014-03-22
Verifier Name: Adrian Farrel
Date Verified: 2014-03-22

Section 11 says:

      6        Och at 2.5 Gbps                       [RFC4328]

It should say:

      6        OCh at 2.5 Gbps                       [RFC4328]

Notes:

Trivial capitalization issue that is reflected in the IANA registry and could be tidied up as the registry action is still in the process of being completed.

Report New Errata