Found 2 records.

Status: Verified (2)

RFC 5960, "MPLS Transport Profile Data Plane Architecture", August 2010

Note: This RFC has been updated by RFC 7274

Errata ID: 2534
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Italo Busi
Date Reported: 2010-09-29
Verifier Name: Adrian Farrel
Date Verified: 2010-11-18

Section 6 says:

   Where enhanced security is desirable, and a trust relationship exists
   between an LSR and its peer, the LSR MAY choose to implement the
   following policy for the processing of MPLS packets received from one
   or more of its neighbors:

      Upon receipt of an MPLS packet, discard the packet unless one of
      the following two conditions holds:

      1.  Any MPLS label in the packet's label stack processed at the
          receiving LSR, such as an LSP or PW label, has a label value
          that the receiving LSR has distributed to that neighbor; or

      2.  Any MPLS label in the packet's label stack processed at the
          receiving LSR, such as an LSP or PW label, has a label value
          that the receiving LSR has previously distributed to the peer
          beyond that neighbor (i.e., when it is known that the path
          from the system to which the label was distributed to the
          receiving system is via that neighbor).

It should say:

   Where enhanced security is desirable, and a trust relationship exists
   between two LSRs, an LSR receiving an MPLS packet MAY choose to 
   implement an additional policy for processing the received packet as
   follows:

      The receiving LSR discards the packet unless every MPLS label
      stack entry that it processes from the packet's label stack has a 
      label that has been agreed for use by the sender of the packet
      (for example, is a reserved label or has been distributed using
      the management plane or control plane upstream or downstream 
      allocation). 

Notes:

There was considerable confusion about the distinction between peer and neighbour. This was first raised in a liaison from the ITU-T visible at
https://datatracker.ietf.org/liaison/916/

Clarification was also added about which labels are acceptable.

This does not result in a technical change to the specification, but introduces clarity about the processes described.

Errata ID: 2533
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Italo Busi
Date Reported: 2010-09-29
Verifier Name: Adrian Farrel
Date Verified: 2010-11-10

Section 3.2 says:

   A section MUST provide a means of identifying the type of payload it
   carries.  If the section is a data-link, link-specific mechanisms
   such as a protocol type indication in the data-link header MAY be
   used.  If the section is an LSP, this information MAY be implied by
   the LSP label or, if the LSP payload is MPLS-labeled, by the setting
   of the S bit.  Additional labels MAY also be used if necessary to
   distinguish different payload types; see [RFC5921] for examples and
   further discussion.

It should say:

   A section MUST provide a means of identifying the type of payload it
   carries. This mechanism may be used to facilitate multiplexing MPLS
   with other protocols on the section if that function is supported by
   the section. Support or non-support of multiplexing on sections is
   out-of-scope for this document.

   If the section is a data-link, link-specific mechanisms
   such as a protocol type indication in the data-link header MAY be
   used.  If the section is an LSP, this information MAY be implied by
   the LSP label or, if the LSP payload is MPLS-labeled, by the setting
   of the S bit.  Additional labels MAY also be used if necessary to
   distinguish different payload types; see [RFC5921] for examples and
   further discussion.

Notes:

This change clarifies the requirement to support payload identification, the way it is used, and the use to which it is put. Furthermore, it clarifies the standing of protocol multiplexing onto underlying sections.

This issue was first raised in a liaison from the ITU-T
See https://datatracker.ietf.org/liaison/916/

Report New Errata