RFC Errata

Errata Search

Source of RFC  
Summary Table Full Records

RFC 4873, "GMPLS Segment Recovery", May 2007

Note: This RFC has been updated by RFC 9270

Source of RFC: ccamp (rtg)

Errata ID: 944
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-05-08
Rejected by: Adrian Farrel
Date Rejected: 2010-10-30


The rules given in the two paragraphs on top of page 18,

   The resulting Path message is used to create the recovery LSP.  While
   the recovery LSP exists, the PROTECTION object in the original Path
   message  (unless overridden by local policy) MUST also be updated
   with the In-Place bit set (1).  From this point on, Standard Path
   message processing is used in processing the resulting and original
   Path messages.

   The merge node of a dynamically controlled recovery LSP SHOULD reset
   (0) the In-Place bit in the PROTECTION object of the outgoing Path
   message associated with the terminated recovery LSP.

apparently make dynamic 'overlapping' segment protection impossible.

One scenario that came to my mind was node failure protection
envisioned to be implemented by recovery LSPs for the primary LSP
A-B-C-D-E-F-G, depicted as follows:

                  H ----- I   J ----- K
                 /         \ /         \
          A --- B --- C --- D --- E --- F --- G
           \         / \         / \         /
            L ----- M   N ----- O   P ----- Q

The specified rules apparently inhibit the setup of such overlapping
segment protection LSPs.  Has this been intended ?

It should say:

[see above]


from pending
This is not an Erratum. If there is technical discussion to be had about the function enabled or prohibited by the specification, and the requirements for the provision of services in a network, these need to be taken to the CCAMP mailing list and might result in a revision to the RFC or a new draft.

Report New Errata

Advanced Search