RFC 5960, "MPLS Transport Profile Data Plane Architecture", August 2010Source of RFC: mpls (rtg)
See Also: RFC 5960 w/ inline errata
Errata ID: 2534
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).
There was considerable confusion about the distinction between peer and neighbour. This was first raised in a liaison from the ITU-T visible at
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.