Anonymized Responses to a Poll on MPLS Forwarder Behavior

MPLS Network Actions (MNAs) indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions . Various proposals have been made for how MNAs and the associated data may be encoded within MPLS packets, and these depend on the use of a new Special Purpose Label (SPL) ]. The details of MNA protocol extensions may depend on how existing implementations may react when they see those extensions. In particular, how base SPLs (bSPLs) and extended SPLs (eSPLs) are processed when they are present in an MPLS label stack processed by an MPLS router. Furthermore, questions arose about the processing of the Time to Live (TTL) and the Traffic Class (TC) field of the Explicit Label Indicator (ELI) and Explicit Label (EL) Label Stack Entries (LSEs) . In order to discover what deployed implementations currently do, the MPLS working group chairs polled participants to answer specific questions . This document is intended to report anonymized answers to that poll. This document is presented as a snap-shot of information. It is possible that implementations will be modified in future, or that the poll responses reported here were not accurate. Therefore, beyond acting as information to be input to the working group, this document is not intended to advance further.

The questions asked in the poll were as follows: Does your implementation look at anything more than the top label in the label stack? If so, does it: "scan ahead" examining the labels, Simply use the Label Stack Entries as input to a hash, Just search for the Bottom of Stack? Something else. In the case where your implementation looks at label values below Top of Stack: Does the scan-ahead recognise SPLs. If so, what does it do if the label value is an SPL (bSPL or eSPL) that it does not recognise? (Note that this question applies to / implementations as well as / implementations. What value does your implementation set as: The ELI TC field The ELI TTL The EL TC field The EL TTL In each case what happens if the received bits in those fields are not as expected? Penultimate Hop Pop How does your Penultimate Hop Pop implementation (///) process the TTL and TC (as EXP) from the popped Label Stack Entry? In particular, does it copy either field into the exposed top-of-stack Label Stack Entry (in the case where the popped label was not bottom of stack)? Does your Penultimate Hop Pop implementation examine the exposed top-of-stack label to see whether it is a bSPL? If so, what does it do?

Responses were collected over the period from the intial email until 26th October 2022. Six responses were received and are reported here. One response reported two separate implementations which are shown separately, below.

Answers are summarised as follows: d) Only top label examined. Scan ahead (only for hash) does not recognise SPLs. No ELI/EL support. Penultimate Hop Pop Pipe mode. Does not copy. No further examination.

Answers are summarised as follows: b) except if any EL is found in which case each ELI is used. Below top of stack All known SPLs are parsed. Treated as a normal label. These are set in compliance with Section 4.2 of . Ignore EL TTL on reception, per . ELI TTL/TC are expected to be the same as the transport label. Penultimate Hop Pop TC bits used depending on QoS policy. TTL is decremented. The TTL of a forwarded IP packet is set to MIN(MPLS_TTL-1, IP_TTL), where MPLS_TTL refers to the TTL in the outermost label in the popped stack. The TTL of a forwarded MPLS packet is set to MIN(MPLS_TTL-1, INNER_MPLS_TTL), where MPLS_TTL refers to the TTL in the outermost label in the popped stack and INNER_MPLS_TTL refers to the TTL in the exposed label. Ignore it except for potentially overwriting the TC based on egress QoS policy.

Answers are summarised as follows: I have no idea. I don't know our implementations in detail. I have no idea. I have no idea. Penultimate Hop Pop I have no idea. I have no idea.

Answers are summarised as follows: Default b). Some cases for c). Does not look at labels below top of stack. Fields set according to section 4.2. In uniform mode the TTL and TC are copied to the exposed LSE. No further examination.

Answers are summarised as follows: a) and b) in different implementations. a) and b) skip the unrecognised SPL. Set values ECI TC = 0 ELI TTL = Assign a value or copied from IP header EL TC = 0 EL TTL = Assign a value or copied from IP header No check on received fields. In one mode, both fields are copied. In another mode, neither field is copied. No check on received fields.

Answers are summarised as follows: c) Below top of stack: All known SPLs are parsed. Treated as a normal label. Set values Copied from LSE inserted above ELI Copied from LSE inserted above ELI Copied from LSE inserted above ELI 0 by default with (unused) option to override Penultimate Hop Pop The TTL and TC are used in the forwarding plane Two configuration options exist: If "explicit null" is configured, the TC is copied to the explicit null LSE If "propagate TTL" is configured, the TTL is copied to the next LSE Otherwise, no change is made to the next LSE Check is applied only to ELI, in which case ELI and EL are popped.

Answers are summarised as follows: b) Scan ahead (only for hash) does not recognise SPLs. No ELI/EL support. Penultimate Hop Pop Pipe mode. Does not copy. No further examination.

Development of a solution that is not disruptive to deployed implementations is important for a stable and secure network.

This document makes no requests for IANA action.