Internet-Draft	MPLS Network Action Encodings	October 2022
Rajamanickam, et al.	Expires 13 April 2023	[Page]

Workgroup:: MPLS Working Group
Internet-Draft:: draft-jags-mpls-mna-hdr-02
Published:: 10 October 2022
Intended Status:: Standards Track
Expires:: 13 April 2023
Authors:: J. Rajamanickam, Ed.

Cisco Systems, Inc.

R. Gandhi, Ed.

Cisco Systems, Inc.

R. Zigler, Ed.

Broadcom

H. Song, Ed.

Futurewei Technologies

K. Kompella, Ed.

Juniper Networks

MPLS Network Action (MNA) Header Encodings

Abstract

This document defines the MPLS Network Action (MNA) Header encoding formats to carry Network Actions and optionally Ancillary Data in the label stack and post label stack. The MPLS Network Action can be used for example, to influence the forwarding decisions or to carry additional OAM information in the MPLS packet. This document addresses the MNA requirements specified in draft-ietf-mpls-mna-requirements. This document follows the MNA framework specified in draft-ietf-mpls-mna-fwk.¶

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 13 April 2023.¶

Copyright Notice

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

▲

1. Introduction

[RFC3032] defines MPLS Header for carrying a stack of MPLS labels which are used to forward packets in an MPLS network. Today's new applications require the MPLS packets to carry network action indicators and optional Ancillary Data (AD) that can be used for example, in MPLS packet forwarding decision or for OAM purpose. Ancillary Data can be used to carry additional information, for example, a network slice identifier, In-Situ OAM (IOAM) data, etc. Several MNA applications are described in [I-D.ietf-mpls-mna-usecases].¶

This document defines a solution to encode MPLS Network Actions (MNA) in an MPLS Label Stack those are efficient to process in hardware. The MPLS Network Actions are encoded in the form of flags and opcodes. These MPLS Network Actions can be encoded without Ancillary Data (AD) or with In-Stack Ancillary Data (ISD) or with Post-Stack Ancillary Data (PSD) (i.e., after the Bottom of the Stack (BOS)). A new base Special Purpose Label (bSPL) (value TBA1) is to be assigned to indicate the presence of MPLS Network Action Sub-Stack (MNAS) in the MPLS packet. This document addresses the MNA requirements specified in [I-D.ietf-mpls-mna-requirements]. This document follows the MNA framework specified in [I-D.ietf-mpls-mna-fwk].¶

2. Conventions Used in This Document

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.2. Abbreviations

The MNA terminology defined in [I-D.ietf-mpls-mna-fwk] and [I-D.ietf-mpls-mna-requirements] are used in this document.¶

AD: Ancillary Data.¶
BOS: Bottom Of Stack.¶
IHS: I2E, HBH, Select Scope.¶
I2E: Ingress-To-Egress.¶
HBH: Hop-By-Hop Scope.¶
ISD: In-Stack Data.¶
IS-NA: In-Stack Network Action.¶
IS-NAI-Opcode: In-Stack Network Action Opcode.¶
LSE: 32-bit Label Stack Entry.¶
MPLS: Multiprotocol Label Switching.¶
MNA: MPLS Network Action.¶
NAI: Network Action Indicator.¶
NAI-OP: Network Action Indicator Opcode.¶
NAL: Length of Network Action in number of LSEs, excluding the LSE for Opcode.¶
NASL: Length of Network Action sub-stack in number of LSEs.¶
NASI: Network Action Sub-Stack Indicator.¶
NASS: Network Action Sub-Stack.¶
PS-NA: Post-Stack Network Action.¶
P,H: Post-Stack Network Action Presence and Post-Stack Hop-By-hop presence Indicator.¶
PSD: Post-Stack Data.¶
bSPL: Base Special Purpose Label in the range of 0-15.¶
TC: Traffic Class.¶
TTL: Time To Live.¶

3. Overview

The solution for encoding MPLS Network Actions includes two high-level parts as shown in Figure 1.¶

1. Network Action Sub-Stack Header - The Network Action Sub-Stack Indicator label indicates the presence of MPLS Network Action Sub-Stack in the MPLS label stack. The NASS encoding parameters indicate the structure of the NASS.¶
2. In-Stack Network Actions Encoding - The encoding in which the MPLS Network Actions are carried in the MPLS header. This includes Network Action Indicator (NAI) and Ancillary Data (AD). The Network Action can be In-Stack and Post-Stack.¶



 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI Label = bSPL (TBA1)          | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode    | Flag-Based NAIs or AD |R|NAL|S|P,H|IHS|  NASL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                                |<--NASS Param->|

Figure 1: Network Action Sub-Stack Header

Both parts of the encoding solution are described below.¶

3.1. Network Action Sub-Stack Header

Network Action Sub-Stack Header contains NASI Label and NASS encoding parameters as described below.¶

NASI Label:¶

A new bSPL value (value TBA1) is assigned to indicate the presence of the MPLS Network Action Sub-Stack (NASS).¶

Note: The TC and TTL fields of the new bSPL are not re-purposed for NASS encoding parameters, as the penultimate node on the MPLS packet path may propagate TTL and TC fields from the transport (or forwarding) LSE to the next LSE on the label stack, overwriting the TTL and TC fields of the next LSE, as specified in Section 3.5 of [RFC3443]. When the penultimate node is not aware of the NASI bSPL (value TBA1) e.g., in case of legacy network, this can cause NASS parameters in the TTL of the NASI label to be corrupted.¶

NASS Encoding Parameters:¶

The TTL field in the second LSE is used to encode NASS encoding parameters. The NASS encoding parameters contain scope and the length of NASS as well as presence flags for Post-Stack Network Action and Ancillary Data.¶

NASS Scope:¶

This indicates the scope (HBH / Select / I2E) of NASS for different nodes (e.g., midpoint nodes and egress node) where it needs to be processed.¶

Separate NASS Per Scope:¶

If a packet requires to carry both HBH and I2E scoped In-Stack NAs, then one NASS with scope of HBH and one NASS with scope I2E are added in the MPLS label stack. The I2E scoped NASS is added closer to the BOS whereas HBH and Select scoped NASS are added closer to the top of the label stack. This makes it easier for the midpoint nodes to process only the NASS with HBH scope in hardware.¶

IHS (I2E, HBH, and Select Scope): This 2-bit value indicates the scope of In-Stack NAIs.¶

Table 1: In-Stack NAI Scope Table
Bits	Scope
00	I2E
01	HBH
10	Select
11	Reserved

P,H (Post-Stack Network Action Presence and Post-Stack Hop-By-hop processing Indicator):¶

This is 2-bit flag, where "P" bit indicates the presence of Post-Stack Network Actions and "H" bit indicates the presence of Post-Stack Hop-By-Hop and/or Select processing scope options. While encoding the Post-Stack NAs, the HBH/Select scope NAs MUST be encoded first (closer to the BOS) and then I2E.¶

NASL (Network Action Sub-Stack Length):¶

This is a 4-bit field in the TTL. This indicates the total length of the current NASS. This value does not include the first two LSEs in the NASS. This value is used by the ASICs to process the NASS.¶

NAL (Network Action Length):¶

The 2-bit field in TC is used to carry the number of additional LSEs used to carry the Ancillary Data for the Network Action. It does not include the 1st LSE that contains the NAI-Opcode.¶

In the case where the node does not support the NAI-Opcode value, the NA length is used to skip the NAI-Opcode and move to the next Opcode and continue processing.¶

R bit:¶

R bit in the TC field is Reserved for future use.¶

3.2. In-Stack Network Action Encoding

The MPLS Network Action encoding carried as part of the MPLS label stack uses Opcodes for indicating Network Actions (called NAI-Opcodes).¶

The encoding format defined is flexible (e.g., stackable opcodes in desired order), extensible (by defining new NAI-Opcodes) and ASIC friendly (by using Sub-Stack Length, Opcode and Data in the same LSE). This encoding format also allows to carry the Flag-Based NAIs that do not require AD and the Flag-Based NAIs that require AD in the same packet.¶

The opcode method of identifying a specific Network Actions are common in today's hardware ASICs (Similar to any IPv4/IPv6/VxLAN header processing), so this method is easy to be adopted by the existing hardware. This will allow the hardware ASICs to serially or in-parallel process the Network Actions.¶


 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Label                    | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      NASI=bSPL (TBA1)                 | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode    |    Ancillary Data     |R|NAL|S|P,H|IHS|  NASL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode    |    Ancillary Data     |R|NAL|S| Ancillary Data|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: MPLS Label Stack Entry (LSE) Format

In-Stack Network Actions are encoded in the TLV format. NAI-Opcode represents NA Indicator Type, NAL represents NA Length and Ancillary Data represents NA Value.¶

It uses MPLS Label field to carry the Network Action Indicator Opcode and associated In-Stack Ancillary Data (can be NAI Flags).¶
It uses Traffic Class (TC) field to carry the Length of the In-Stack Network Action's Ancillary Data.¶
It uses MPLS Label and Time-To-Live (TTL) fields to carry the In-Stack Ancillary Data (can be NAI Flags).¶

NAI-Opcode:¶

This is the first 8-bit value in the Label Field.¶

Ancillary Data:¶

This is the additional Data carried to process the Network Action specified by the NAI-Opcode.¶

The 12 bits of the Label field is used to carry the Ancillary Data¶
Apart from the Label field, part of AD is also carried in the 8-bit TTL field except for the 2nd LSE in the NASS. If an application needs only 12-bit of AD, then 2nd LSE can be used for NAI-Opcode otherwise it can use the next LSE for 20-bit of AD.¶
Some applications need to change the Ancillary Data for the same flow, in those cases the data is encoded in the the TTL field.¶

NOTE: ECMP Hash Using Label Stack:¶

A midpoint node may use the entire MPLS Label Stack for ECMP hash computation hence the In-Stack MPLS extension header MUST NOT change the Label Field part of the Ancillary Data within the same traffic flow. But the TTL part of In-Stack Ancillary Data can change for the same traffic flow without affecting the ECMP hash. The In-Stack Network Action encoding defined above ensures this.¶

4. Reserved In-Stack MPLS Network Action Opcodes

This opcode ranges from 1 to 255.¶

NAI-Opcode value of 0 is marked as invalid to avoid the label value from aliasing with the reserved bSPLs.¶

Some of the opcodes are reserved as described below for the basic functionality and the rest of the opcodes are assigned by IANA.¶

IS-NAI-Opcode Value:1 (PSD Offset) - Opcode reserved to indicate the start offset of the Post-Stack Network Actions header after the MPLS Label Bottom of the Stack. This can allow to carry Generic Control Word (0000b) [RFC4385] and G-ACh (0001b) [RFC5586] fields immediately after the BOS. Adding of this opcode is not required when the BOS data starts immediately after the Bottom of the Label Stack (i.e. when offset is 0)¶

IS-NAI-Opcode Value:2 (Flag-Based NAIs with No AD) - Opcode reserved to carry the Flag-Based NAIs those do not require Ancillary Data. These NAI flag bits are carried in the Ancillary Data field of the Opcode.¶


 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      NASI=bSPL (TBA1)                 | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=2  |   Flag-Based NAIs     |R| 0 |S|P,H|IHS|NASL=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: In-Stack Flags-Based NA Encoding Format

The Flags bit position for a specific application will be maintained and allocated by IANA.¶

IS-NAI-Opcode Value:3 (Flag-Based NAIs with ADs) - Opcode reserved to carry the Flag-based NAIs with ADs in the next LSEs.¶


 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=bSPL (TBA1)                  | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=3  |   Flag-Based NAIs     |R| 1 |S|P,H|IHS|NASL=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|             Ancillary Data                |S|Ancillary Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: In-Stack Flag-Based NAs with Ancillary Data

The NASS is carrying the reserved opcode 3 for Flags-Based NAIs that require ADs.¶

IS-NAI-Opcode Value:4 (PSD Network Action Indicator Opcode) - Opcode reserved to indicate that a specific Post-Stack Network Action has to be executed in order with respect to the In-Stack Opcode.¶


 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      NASI=bSPL (TBA1)                 | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=4  |   Post-Stack-NAI      |R| 0 |S|P,H|IHS|NASL=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 5: In-Stack PSD Opcode Indicator Encoding Format

A NAI-Opcode 4 is reserved to carry Post-Stack NA as AD. This NAI-Opcode can be used to specify the ordering between In-Stack and Post-Stack Network Actions.¶

IS-NAI-Opcode Value:5-254 (Application Defined Opcode) - MUST be assigned by IANA. When this opcode is allocated for a specific applications Network Action, the respective application MUST define the Ancillary Data format and other required attributes like functionality, scope (I2E / HBH/ SEL) of the Network Action.¶
IS-NAI-Opcode Value:255 (Extended Opcode) - IANA Allocated for IS-NAI-Opcode range extension. This gives the extensibility for opcode range beyond 255. The Extended 8-bit opcode value will be encoded next to base opcode value 255.¶


 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      NASI=bSPL (TBA1)                 | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=2  |   Flag-Based NAIs     |R| 0 |S|P,H|IHS|NASL=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NAI-Opcode=255 |Ex-NAI-Opcode=9|  AD9  |R| 0 |S|    AD9        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: In-Stack Extended Opcode Encoding Format

In the above example, the extended Opcode "9" is encoded in the packet. In this case only 12 bits of AD could be encoded in the same LSE, if the application requires to encode more than 12 bits then it had to use next LSE to encode the rest of the AD.¶

5. Post-Stack MPLS Network Action Encoding

Based on the P and H flags, the Post-Stack Network Actions are processed. The details of the Post-Stack Network Action Extension Header encoding is specified in [I-D.song-mpls-extension-header].¶

6. Network Action Processing Order

Depending on the application, each NA will be processed at different stages of the ASICs pipeline. But in some cases, there may be contention between processing two NAs at the same stage of ASICs, in those cases the processing order should be maintained, so that the result of the packet forwarding and OAM data collection will be predictable.¶

6.1. In-Stack NA Processing Order

This section talks about maintaining the ordering between the In-Stack NA processing.¶

The order of processing the NA should follow the order of NAs encoded in the NASS.¶


 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=bSPL (TBA1)                  |  TC |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=2  |    Flag-Based NAIs    |R| 0 |S|P,H|IHS|NASL=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=5  |    Ancillary Data5    |R| 0 |S|Ancillary Data5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: Example In-Stack NA Processing Order

In the above example, a node will process the Flags-Based-NAIs first and then the NAI-Opcode "5".¶

In some cases, some Flag-Based NAIs may need to be processed before the NAI-Opcode "5" and some Flag-Based NAIs may need to be process after the NAI-Opcode "5".¶


 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=bSPL (TBA1)                  |  TC |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=2  |      0x01             |R| 0 |S|P,H|IHS|NASL=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=5  |    Ancillary Data5    |R| 0 |S|Ancillary Data5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=2  |      0x02             |R| 0 |S|   0x00        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8: Example In-Stack NA Processing Order

In the above example, the Flag-Based NAI "0x1" is processed before the NAI-Opcode "5" and the Flags-Based NAI "0x2" is processed after the NAI-Opcode "5".¶

6.2. Post-Stack NA Processing Order

Post-Stack NAs follow ordering specified in [I-D.song-mpls-extension-header].¶

6.3. Mix of In-Stack and Post-Stack NA Processing Order

In some cases, Post-Stack NA needs to be processed before In-Stack NA. This section describes how to prioritize the Post-Stack NAs over the In-Stack NAs.¶


 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=bSPL (TBA1)                  |  TC |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=2  |      0x01             |R| 0 |S|P,H|IHS|NASL=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=4  |    Post-Stack-NAI6    |R| 0 |S| PS-NAI6       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=5  |    Ancillary Data5    |R| 0 |S|Ancillary Data5|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: Example Post-Stack and In-Stack NA Processing Order

In the above example, the Flag-Based NAIs required to be processed first, followed by the Post-Stack NA "6" and then In-Stack NAI-Opcode "5". The NAI-Opcode "4" is a reserved opcode which can be used for ordering between the In-Stack and Post-Stack. In this example, the AD field of the NAI-Opcode "4" carries the Post-Stack NA that is processed before processing the NAI-Opcode "5".¶

7. Handling of Unsupported Network Actions

When a node encounters an unsupported NAI-Opcode in the NASS it is processing, the node skips processing that NAI-Opcode using the NAL field and moves to processing the next NAI-Opcode.¶

When a node encounters a Flag-based NAI that it doesn't support, it stops further processing the Flag-Based NAIs in that NAI-Opcode. This is because the Flag-Based NAI may or may not have AD and a node will not be able to know the length for each Flag-Based-NAI.¶

The node MUST NOT drop the packet when it encounters any NA in the MNA NASS that it does not support.¶

8. MNA for Segment Routing Label Stack

For packets with Segment Routing [RFC8662] MPLS label stack, a copy of NASS with HBH and Select scope is placed at regular depth throughout the MPLS label stack, with the understanding that the current copy of the NASS will eventually rise to the top of the label stack.¶

For HBH scope, every node processes the current copy of the NASS and the node that pops the forwarding label that exposes the NASS will not remove it but forward it to the next node (i.e., segment endpoint node). The segment endpoint node that receives the NASS at the top of the label stack has to remove it.¶

For I2E scope, only one copy of NASS needs to be added and it is added near the bottom of the stack.¶

9. Node Capability Signaling

The node capability for the MPLS Network Action must be signaled before the MPLS Encapsulating node can add the necessary MPLS Network Action in the MPLS Label Stack. The capability signaling will be added in LDP, RSVP-TE, BGP, IS-IS, OSPF, BGP-LS, etc. This is outside the scope of this document.¶

10. Security Considerations

The security considerations in [RFC3032] also apply to the procedures defined in this document. The NASI Label (bSPL TBA1) MUST NOT be exposed on the node which does not support it.¶

11. Backward Compatibility

For the legacy node that does not advertise the MPLS Network Action capability, the Encapsulating node MUST make sure that the MPLS Network Action Sub-Stack indicator is not at the top of the MPLS Label Stack to avoid dropping the packets. Based on the signalling, if the MPLS egress node is not capable of the processing MPLS Network Actions then it should not add MNA in the packet. In the worst case, if the legacy routes that does not understand the new bSPL allocated then those routers will drop the packets.¶
The MPLS Network Action Encoding format is designed to make sure that it does not alias with any reserved bSPL.¶
The MPLS Network Actions can co-exist with the existing GAL / G-ACh based encoding of data.¶
The TC and TTL fields of the NASI bSPL are not re-purposed for encoding, as the penultimate node on the MPLS packet path may propagate TTL from the transport (or forwarding) label to the next label on the label stack, overwriting the TTL on the next label. When the penultimate node is not aware of the NASI bSPL (value TBA1), this can cause encoding format flags in the TTL of the NASI (label TBA1) label to be corrupted.¶

12. Processing In-Stack MPLS Network Actions

Encapsulating Node:¶

MUST NOT add In-Stack MPLS Network Action Sub-Stack if the decapsulation node is not capable of In-Stack MPLS Network Action.¶
SHOULD NOT change the IS-NAI-Opcode and the first 12 bits of the In-Stack Ancillary Data for the same packet flow to avoid ECMP path change.¶
MAY change In-Stack Ancillary Data part present only in the TTL field for the same packet flow.¶
MUST ensure that the penultimate node does not remove the NASS.¶

Midpoint Node:¶

MUST ignore the IS-NAI-Opcode that are not supported.¶
MUST NOT add In-Stack NASS if the decapsulation node is not capable of In-Stack MPLS Network Actions.¶
SHOULD NOT change the IS-NAI-Opcode and the first 12 bits of the In-Stack Ancillary Data for the same packet flow.¶
MAY change In-Stack Ancillary Data part present only in the TTL field for the same packet flow.¶
MAY remove the IS-NAI-Opcode and its Ancillary Data for all matching packet flow.¶

Penultimate Node:¶

MUST ignore the IS-NAI-Opcode that are not supported.¶
MUST NOT remove the NASS when it is exposed after removing the forwarding (transport) label.¶

Decapsulating Node:¶

MUST remove the MPLS Network Action Sub-Stack.¶

13. IANA Considerations

Below are the IANA actions which this document is requesting.¶

The registries created by this document will be collected in a new registry grouping called "MPLS Network Action," which will be located at https://www.iana.org/assignments/mpls-network-action.¶

13.1. IANA Considerations for MNA NASS Encoding Parameters

IANA is requested to create a new registry with name "MNA NASS Encoding Parameters" to assign the bit position and the meaning to the Parameters that re-purpose TTL and TC fields in the Label Stack Entry (LSE).¶

Table 2: MNA NASS Encoding Parameters Registry
Bit Position	Description	Reference
20-31	IETF Review	This document

Following NASS Encoding Parameter values are assigned from this registry.¶

Table 3: MNA NASS Encoding Parameter Values
Value	Description	Reference
28-31	In-Stack Network Action Sub-Stack Length (NASL)	This document
26-27	In-Stack Scope value E2H/HBH/SEL(IHS)	This document
25	Post-Stack Hop-By-Hop Processing Indicator	This document
24	Post-Stack Network Action Presence Indicator	This document
23	End of Stack (S)	RFC 3032
21-22	In-Stack Network Action Length (NAL)	This document
20	Reserved Bit (R)	This document

13.2. IANA Considerations Flag-Based Network Actions

IANA is requested to create a new registry with name "In-Stack MPLS Network Action Indicator Flags" to assign a bit position and the meaning to the Flag-Based Network Action upon the user request. Based on the need this registry can be extended beyond 12 bit positions.¶

Table 4: In-Stack MPLS Network Action Indicator Flags Registry
Bit Position	Description	Reference
11-0	Unassigned	This document

13.3. IANA Considerations for I2E and HBH/Select IS-NAI-Opcode

IANA is requested to create a new registry with name "I2E In-Stack MPLS Network Action Indicator Opcodes" to assign IS-NAI-Opcode values. All code-points in the range 1 through 175 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. Code points in the range 176 through 239 in this registry shall be allocated according to the "First Come First Served" procedure as specified in [RFC8126]. Remaining code-points are allocated according to Table 5:¶

Table 5: I2E In-Stack MPLS Network Action Indicator Opcodes Registry
Value	Description	Reference
0 - 175	IETF Review	This document
176 - 239	First Come First Served	This document
240 - 251	Experimental Use	This document
252 - 254	Private Use	This document

Following I2E IS-NAI-Opcode Indicator values are assigned from this registry.¶

Table 6: I2E In-Stack Network Action Indicator Opcode Values
Value	Description	Reference
0	Reserved	This document
1	Offset of start of Post-Stack Network Action Header	This document
2	Flag-Based Network Action Indicators with No AD	This document
3	Flag-Based Network Action Indicators with AD	This document
4	Post-Stack Network Action Indicator	This document
255	Opcode Range Extension Beyond 255	This document

IANA is requested to create a new registry with name "HBH and Select In-Stack MPLS Network Action Indicator Opcodes" to assign IS-NAI-Opcode values. This registry is also used for Select scope. All code-points in the range 1 through 175 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. Code points in the range 176 through 239 in this registry shall be allocated according to the "First Come First Served" procedure as specified in [RFC8126]. Remaining code-points are allocated according to Table 5:¶

Table 7: HBH and Select In-Stack MPLS Network Action Indicator Opcodes Registry
Value	Description	Reference
0 - 175	IETF Review	This document
176 - 239	First Come First Served	This document
240 - 251	Experimental Use	This document
252 - 254	Private Use	This document

Following HBH and Select IS-NAI-Opcode Indicator values are assigned from this registry.¶

Table 8: HBH and Select In-Stack Network Action Indicator Opcode Values
Value	Description	Reference
0	Reserved	This document
1	Offset of start of Post-Stack Network Action Header	This document
2	Flag-Based Network Action Indicators with No AD	This document
3	Flag-Based Network Action Indicators with AD	This document
4	Post-Stack Network Action Indicator	This document
255	Opcode Range Extension Beyond 255	This document

13.4. IANA Considerations for NASI bSPL Label

IANA is requested to allocate a value TBA1 for the NASI bSPL label from the "Base Special-Purpose MPLS Label Values" registry to indicate the presence of MNA Sub-Stack in MPLS header.¶

14. Appendix

14.1. Network Action Encoding Examples

14.1.1. Example-1 - Flag-Based In-Stack NA without AD


 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=bSPL (TBA1)                  |  TC |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=2  |    Flag-Based NAIs    |R| 0 |S|P,H|IHS|NASL=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10: Example NASS with In-Stack Network Action Encoding Carrying Flag-Based NA

Second LSE:¶

Label Field:¶

NAI-Opcode is set to "2".¶
Next 12 bits are used to encode the Flag-Based Network Actions that do not need Ancillary Data. Each bit encoded is a unique Flag-Based Network Action. This bit position will be assigned by IANA. For example, an application A can be allocated Flag position as "2" and another application B can be allocated Flag position as "5". If application A and B needs to set their Network Actions then the bit positions "2" and "5" will be set to 1.¶

TC Field:¶

NAL - This value depends on the number of LSEs carrying the NAI Flags in the MPLS In-Stack header is carrying. In this case, the packet is carrying only bit position "1" and "3", both in one LSE, the NAL will be set to "0".¶

TTL Field:¶

NASL value is set to "0" as no additional LSEs are encoded.¶


 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=bSPL (TBA1)                  | TC  |S|     TTL       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=2  |    Flag-Based NAIs    |R| 1 |S|P,H|IHS|NASL=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Additional Flag-Based NAIs                |S|Flag-Based-NAIs|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 11: Example NASS carrying Flag-Based NA with more than 12 Flags

In this example, let us assume that an application-C has been allocated a Flag position of "21" by IANA, If the application-C needs to execute its Network Action on the MPLS packet then the 2nd bit in the third Label field will be set to indicate the Flags position "13".¶

NAL is set to "1" indicates the Flag-Based NAIs are also encoded in the next LSE.¶

NASL is set to "1" indicates the additional In-Stack LSE is encoded.¶

While encoding the Additional Ancillary Data in the 3rd LSE, the Most Significant bit MUST be set to "1" to prevent from aliasing with the reserved bSPLs.¶

14.1.2. Example-2 - In-Stack NA with 12-bit AD


 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=bSPL (TBA1)                  | TC  |S|    TTL        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=6  |   Ancillary Data6     |R| 0 |S|P,H|IHS|NASL=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 12: Example NASS carrying In-Stack Network Action that requires Ancillary Data

In this example, the NASS is carrying only the In-Stack Network Action that requires 12-bit Ancillary Data.¶

The 8-bit value contains the NAI-Opcode.¶

Next 12 bits carries the AD for the NAI-Opcode "6".¶

No additional LSE is encoded so NAL value is set to "0".¶

14.1.3. Example-3 - Carry only Post-Stack NA Indicator


 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=bSPL (TBA1)                  |  TC |S|     TTL       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=2  |               0       |R| 0 |S|P,H|IHS|NASL=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 13: Example NASS carrying only Post-Stack NA Indicator

In this example, the NASS is carrying only the indicator for the presence of Post-Stack NA and its Hop-By-Hop Option.¶

In this case only "P" and "H" bits are set to "1" as required.¶

14.1.4. Example-4 - In-Stack NA with more than 20-bit AD

An In-Stack Network Action may require more than 20 bits of Ancillary Data. In this example, the following Ancillary Data encoding is used.¶


 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=bSPL (TBA1)                  | TC  |S|      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=2  |    Flag-Based NAIs    |R| 0 |S|P,H|IHS|NASL=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=8  |    Ancillary Data8    |R| 1 |S|Ancillary Data8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|                  Ancillary Data8          |S|Ancillary Data8|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 14: Example In-Stack Network Action With Additional Ancillary Data Encoding Format

In this example, the In-Stack NAI-Opcode "8" requires more than 20 bits of Ancillary Data to be encoded. The NA and AD are encoded in the 3rd and 4th LSEs.¶

Third LSE:¶

Label Field¶

The 8-bit in the Label Field carries the NAI-Opcode value "8".¶
Next 12 bits in the Label Field carries the part of AD.¶

TC Field¶

The 2-bit of the TC field carries Network Action Length (NAL). In this case, since it uses additional LSE to carry its AD the NAL value is set to "1".¶

TTL Field¶

This 8-bit field carries second part of the AD.¶

Fourth LSE:¶

Label Field¶

The first bit in the Label field MUST be set to "1". This is to prevent aliasing the label field with other bSPLs on the legacy routers. The AD value encoded could vary and it cannot be controlled. If we assume in the above example, the application encodes the 4th LSEs Label field as value "7", then legacy node could miss-understood for Entropy label indicator and may start processing the packet accordingly, which could end-up in wrong packet forwarding behaviour.¶
Next 19 bits in the Label field carries 3rd part of AD.¶

TC Field¶

3-bit TC field carries the continuation of 3rd part of AD.¶

TTL Field¶

8-bit TTL field carries the rest of AD.¶

14.1.5. Example-5 - Carry Both I2E and HBH Scope NASS


 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=bSPL (TBA1)                  |  TC |S|     TTL       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=2  |    Flag-Based NAIs    |R| 0 |S|P,H|H01|NASL=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=bSPL (TBA1)                  |  TC |S|     TTL       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=6  |   Ancillary Data6     |R| 0 |S|P,H|E00|NASL=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 15: Example NASS carrying Both I2E and HBH Scope NAs

In this example, one NASS is added for HBH scope with IHS field set to 01b and another NASS is added for I2E scope with IHS field set to 00b.¶

14.1.6. Example-6 - Carry Both Select and HBH Scope NASS


 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=bSPL (TBA1)                  |  TC |S|     TTL       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=2  |    Flag-Based NAIs    |R| 0 |S|P,H|H01|NASL=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     NASI=bSPL (TBA1)                  |  TC |S|     TTL       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAI-Opcode=6  |   Ancillary Data6     |R| 0 |S|P,H|S10|NASL=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 16: Example NASS carrying Both Select and HBH Scope NAs

In this example, one NASS is added for HBH scope with IHS field set to 01b and another NASS is added for Select scope with IHS field set to 10b.¶

15. References

15.1. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3032]: Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>.
[RFC8126]: Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC3443]: Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", BCP 26, RFC 8126, DOI 10.17487/RFC8126, January 2003, <https://www.rfc-editor.org/info/rfc3443>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

15.2. Informative References

[I-D.song-mpls-extension-header]: Song, H., Li, Z., Zhou, T., Andersson, L., Zhang, Z., Gandhi, R., Rajamanickam, J., and J. Bhattacharya, "MPLS Extension Header", Work in Progress, Internet-Draft, draft-song-mpls-extension-header-10, 1 September 2022, <https://www.ietf.org/archive/id/draft-song-mpls-extension-header-10.txt>.
[I-D.ietf-mpls-mna-fwk]: Andersson, L., Bryant, S., Bocci, M., and T. Li, "MPLS Network Actions Framework", Work in Progress, Internet-Draft, draft-ietf-mpls-mna-fwk-01.txt, 8 September 2022, <https://www.ietf.org/archive/id/draft-ietf-mpls-mna-fwk-01.txt>.
[I-D.ietf-mpls-mna-requirements]: Bocci, M., Bryant, S., and J. Drake, "Requirements for MPLS Network Action Indicators and MPLS Ancillary Data", Work in Progress, Internet-Draft, draft-ietf-mpls-mna-requirements-03.txt, 19 August 2022, <https://www.ietf.org/archive/id/draft-ietf-mpls-mna-requirements-03.txt>.
[I-D.ietf-mpls-mna-usecases]: Saad, T., Makhijani, K., and H. Song, "Usecases for MPLS Indicators and Ancillary Data", Work in Progress, Internet-Draft, draft-ietf-mpls-mna-usecases-00, 19 May 2022, <https://www.ietf.org/archive/id/draft-ietf-mpls-mna-usecases-00.txt>.
[RFC5586]: Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, <https://www.rfc-editor.org/info/rfc5586>.
[RFC4385]: Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, <https://www.rfc-editor.org/info/rfc4385>.

Acknowledgments

The authors of this document would like to thank the MPLS Working Group Design Team for the discussions and comments on this document. The authors would also like to thank Amanda Baber for reviewing the IANA Considerations and providing many useful suggestions.¶

Contributors

The following people have substantially contributed to this document:¶


Jisu Bhattacharya
Cisco Systems, Inc.
Email: jisu@cisco.com


Bruno Decraene
Orange
Email: bruno.decraene@orange.com


Weiqiang Cheng
China Mobile
Email: chengweiqiang@chinamobile.com


Xiao Min
ZTE Corp.
Email: xiao.min2@zte.com.cn


Luay Jalil
Verizon
Email: luay.jalil@verizon.com


Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing  100095
China
Email: jie.dong@huawei.com


Tianran Zhou
Huawei Technologies
China
Email: zhoutianran@huawei.com


Bin Wen
Comcast
Email: Bin_Wen@cable.comcast.com


Sami Boutros
Ciena
Email: sboutros@ciena.com


Tony Li
Juniper Networks
United States
Email: tony.li@tony.li


John Drake
Juniper Networks
United States
Email: jdrake@juniper.net

Figure 17