Anonymized Responses to a Poll on MPLS Forwarder Behavior

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 27 April 2023.¶

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

MPLS Network Actions (MNAs) indicate actions for Label Switched Paths (LSPs) and/or MPLS packets and to transfer data needed for these actions [I-D.ietf-mpls-mna-fwk].¶

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) [RFC9017]].¶

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) [RFC3032] and the Traffic Class (TC) field [RFC5462] of the Explicit Label Indicator (ELI) and Explicit Label (EL) Label Stack Entries (LSEs) [RFC6790].¶

In order to discover what deployed implementations currently do, the MPLS working group chairs polled participants to answer specific questions [URL-poll]. 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.¶

2. Questions

The questions asked in the poll were as follows:¶

1. Does your implementation look at anything more than the top label in the label stack? If so, does it:¶

   a)

   "scan ahead" examining the labels,¶

   b)

   Simply use the Label Stack Entries as input to a hash,¶

   c)

   Just search for the Bottom of Stack?¶

   d)

   Something else.¶

2. In the case where your implementation looks at label values below Top of Stack:¶

   a)

   Does the scan-ahead recognise SPLs.¶

   b)

   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 [RFC3031]/[RFC3032] implementations as well as [RFC6790]/[RFC8662] implementations.¶

3. What value does your implementation set as:¶

   a)

   The ELI TC field¶

   b)

   The ELI TTL¶

   c)

   The EL TC field¶

   d)

   The EL TTL¶

   In each case what happens if the received bits in those fields are not as expected?¶

4. Penultimate Hop Pop¶

   a)

   How does your Penultimate Hop Pop implementation ([RFC3031]/[RFC3032]/[RFC3270]/[RFC3443]) process the TTL and TC (as EXP) from the popped Label Stack Entry?¶

   b)

   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)?¶

5. 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?¶

3. Anonymized Responses

Six responses were received and are reported here. One response reported two separate implementations which are shown separately, below.¶

4. Security Considerations

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

5. IANA Considerations

This document makes no requests for IANA action.¶

Author's Address