Session Date/Time: 01 Jun 2023 14:00

MPLS

Summary

This was a joint interim meeting of the MPLS, PALS, and DETNET working groups. Key discussions included updates on the label 14 reclamation effort, a detailed review of options for using the "first nibble" in MPLS Post-Stack Data (PSD) headers, and a presentation of an In-situ OAM (iOAM) use case for PSD. A significant part of the discussion also centered on the feasibility and implications of modifying In-Stack Data (ISD) by transit nodes within the MPLS label stack.

Key Discussion Points

Meeting Logistics and Agenda Review:
- The interim was a joint meeting between MPLS, PALS, and DETNET.
- The Note Well was reviewed, and participants were reminded that the session was being recorded and would be broadcast.
- The agenda was presented and accepted without objection.
Action Items from Previous Meeting:
- PSD Questions: A set of five questions for the working group regarding PSD was reiterated. Laura clarified that the primary request is to gather how existing use cases respond to these questions, rather than solicit new use cases.
- PSD Use Cases: Input was requested for strong PSD use cases. Rakesh Gandhi presented one during this meeting.
Label 14 Reclamation Update:
- A liaison to ITU-T is being drafted to inquire about the possibility of reclaiming Label 14.
- A poll to the working group on this topic is on hold until the liaison to ITU-T is sent.
- Concerns were raised that reclaiming Label 14 might be a difficult process as it was primarily allocated for ITU-T purposes.
First Nibble Discussion for MA-PSD:
- Laura presented three cases for the first nibble in MA-PSD:
  1. Allocate a unique value, sender sets, receiver checks. (Uncertain/unnecessary as other packet info is sufficient for identification).
  2. Set to zero. (Similar uncertainty).
  3. Set to an allocated value, ignore on receipt. (Allows non-MA-capable devices to infer MA-PSD).
- Tony advocated for the first nibble to be a well-defined demultiplexing (D-Max) point, separate from other signaling.
- Greg and Joel (and Stewart) expressed caution about using the first nibble as a D-Max point, citing its small size, existing heuristic uses, and potential for confusion. It was noted that DETNET uses 0 and 1, and NSH uses a value to avoid accidental confusion (not for D-Max). Beer also uses a value other than zero.
- A concern was raised about potential conflicts with Ethernet pseudo-wires without a control word if the first nibble is solely used for D-Max.
- Stewart suggested that while the first nibble might not be a general D-Max point, it could serve for D-Max within the MA protocol after the MA-PSD is identified via the label stack (e.g., for future OAM features).
- Jags questioned the coexistence of NSH and MA headers, to be added to the list of interactions to consider.
- Tarak suggested that the first nibble could be examined only when a specific service label is present, potentially mitigating confusion.
- Stewart proposed crafting a set of questions for the MPLS mailing list to gather wider input on the preferred approach for the first nibble.
iOAM Use Case for PSD (Rakesh Gandhi):
- Rakesh presented an iOAM use case focusing on telemetry, outlining four options:
  1. Flag-based: A simple in-stack flag triggers telemetry on nodes; collector reconciles data. Candidate for ISD.
  2. Alternate Marking: In-stack flags for delay/latency and flow identifiers. Easier for collector, local policy for data export. Candidate for ISD.
  3. Direct Export (iOAM RFC 9326/9197): More information carried in-packet (flow ID, flags for requested data). Each node exports to collector. Candidate for PSD due to potential data size.
  4. Recording Option (iOAM RFC 9197): Information collected in a fixed/pre-allocated header by each node and passed to the egress PE, which then performs telemetry. Collector does not need to reconcile data from multiple nodes. Candidate for PSD.
- Discussion on iOAM Use Case:
  - Greg compared option 1 to alternate marking and suggested considering the IPPM hybrid two-step for out-of-band telemetry collection to reduce in-band load, especially for DETNET. He highlighted iOAM direct export's flexibility with limited in-stack impact.
  - Tony questioned the practicality of hop-by-hop recording (incremental option) due to potential MTU problems.
  - Laura and Rakesh clarified that the "pre-allocated" iOAM option (RFC 9197) does not cause the packet to grow, as space is reserved at ingress. However, if the pre-allocated size is large (e.g., 4x32 bits per node for many hops), it could still exceed practical in-stack limits (e.g., a suggested 5 LSEs). Rakesh provided an example of 3 bytes/node, 48 bytes for 13 hops.
  - Tarak noted an advantage of in-band hop-by-hop recording: only the egress PE needs to export telemetry, reducing the load on transit nodes compared to direct export from every node.
  - Tony reiterated MTU concerns, especially for customer payload, and stated 13 hops is insufficient for some large networks.
  - Jianing argued that MTU issues are common to any protocol that increases packet size, and ingress nodes should account for it.
  - Stewart concurred that for MPLS in limited domains, LSP length is often known, and protocols can define actions for exceeding size.
  - Greg further argued that out-of-band collection improves latency measurement accuracy by avoiding queuing delays associated with in-band stamping.
  - Rakesh suggested that instead of full iOAM options, a few specific flags in MA could be defined for common telemetry items (e.g., interface ID, timestamp, node ID) to avoid provisioning every P-node.
  - Tarak proposed segmenting paths for iOAM recording if the number of hops is too high.
Feasibility of Modifying In-Stack Data (ISD):
- Stewart inquired whether ISD (e.g., for "no further fast-reroute" or decrementing a latency budget) could be modified by transit nodes within the MPLS label stack, as this would require the stack to be a read-write cache rather than just read-only. He expressed concern about potential hardware limitations.
- Tony clarified that while "cheap" SoC routers generally allow full write access, the concern is more with hardware-optimized routers. He noted that the ISD draft is designed to avoid writing to the first LSE to prevent hashing issues.
- Tarak observed that SRv6 allows SRH header modification, but MPLS typically involves push/pop operations.
- Jianing raised a critical point: if multiple copies of ISD are placed deep in the stack (to be accessible after pops), modifying only the top accessible copy would lead to synchronization problems.
- Stewart agreed that synchronization rules would be needed but was primarily asking about the raw hardware capability for simple modification of a single field not at the top of the stack.
- Stewart requested that individuals with access to hardware teams inquire about the feasibility of such modifications (inserting or changing a bit within the label stack, not at the top).

Decisions and Action Items

Action Items:

Chairs: Discuss Stuart's proposal to draft a set of questions for the MPLS mailing list regarding the first nibble discussion to gather wider input.
Greg Mirsky: Offer to prepare a presentation for a future meeting on the IPPM hybrid two-step mechanism for out-of-band telemetry collection, if there is interest.
All Participants (with hardware access): Inquire with their respective hardware teams about the feasibility of modifying fields within the MPLS label stack (not just the top label) by transit nodes.

Next Steps

The discussion on the first nibble will continue, potentially with questions posed to the mailing list.
Participants are encouraged to provide further input on PSD use cases, specifically addressing how existing use cases respond to the five questions previously circulated.
Further investigation into hardware capabilities for ISD modification is needed.
Requests for slots for future interim meetings should be sent as early as possible for planning.