RFC Errata
Found 1 record.
Status: Verified (1)
RFC 5150, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering (GMPLS TE)", February 2008
Source of RFC: ccamp (rtg)
Errata ID: 1345
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-03-03
Verifier Name: Adrian Farrel
Date Verified: 2009-08-24
Section 5.1.1,p.8 says:
If an egress node receiving a Path message with the "LSP stitching | desired" bit set in the Flags field of received LSP_ATTRIBUTES object ^^^^ | recognizes the object, the TLV TLV, and the bit and also supports the ^^^^^^^ desired stitching behavior, then it MUST allocate a non-NULL label for that S-LSP in the corresponding Resv message. Also, so that the head-end node can ensure that the correct label (forwarding) actions will be carried out by the egress node and that the S-LSP can be used for stitching, the egress node MUST set the "LSP segment stitching ready" bit defined in the Flags field of the RRO Attribute subobject.
It should say:
If an egress node receiving a Path message with the "LSP stitching | desired" bit set in the Flags field of the Attributes Flags TLV of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | the received LSP_ATTRIBUTES object recognizes the object, the TLV, ^^^^ ^^^ and the bit and also supports the desired stitching behavior, then it MUST allocate a non-NULL label for that S-LSP in the corresponding Resv message. Also, so that the head-end node can ensure that the correct label (forwarding) actions will be carried out by the egress node and that the S-LSP can be used for stitching, the egress node MUST set the "LSP segment stitching ready" bit defined in the Flags field of the RRO Attribute subobject.
Notes:
Location is 6th paragraph of Section 5.1.1 (i.e., 3rd paragraph on page 8).
Rationale:
a) apparently significant text dropped
b) spurious word replication