Session Date/Time: 25 May 2023 14:00

MPLS

Summary

This was the inaugural interim meeting of a series jointly hosted by the MPLS, PALS, and DETNET Working Groups. The session covered administrative updates regarding the new Meetecho platform, discussed the inconclusive poll on the "first nibble" value, proposed the retrieval of MPLS Label 14, and engaged in a significant technical discussion regarding the necessity and use cases for Post-Stack Data (PSD) in MPLS OAM. Participants were encouraged to document and present compelling use cases for PSD.

Key Discussion Points

Administrative Updates
- This is the first of a series of interim meetings, a collaboration between MPLS, PALS, and DETNET WGs.
- Meetings are now formally conducted via Meetecho, providing automated blue sheets, recording, and a formal note-taking tool (minutes were encouraged to be contributed to via the provided URL).
- The action item tracking wiki will be updated for these interim meetings. Owners of existing action items were reminded to prepare status reports.
- Weekly interim meetings are scheduled, booked up to IETF 117. Chairs will meet on Tuesdays to finalize agendas.
First Nibble Discussion
- A poll was previously conducted to determine the value for the first nibble (options included a unique M&A value, reusing zero, or ignoring if stack indication is sufficient).
- The poll is now closed, but results were inconclusive, indicating a lack of convergence among participants.
- It was noted that the first nibble's importance might be primarily for PSD M&A.
- Decision: The discussion on the first nibble will be revisited and continued at the next interim meeting.
MPLS Label 14 Retrieval
- Label 14 (OEM Alert Label) was assigned in RFC 3429 (informational) in 2002.
- Follow-up inquiries to companies that previously indicated use of Label 14, as well as active market players, confirmed no current implementations or products using it.
- Proposal: The chairs have prepared a poll to be sent to the working group, suggesting the deprecation of RFC 3429 and retrieval of Label 14.
- Concurrently, a liaison will be sent to ITU-T Study Group 15 (which owns this part of the technology) and the T-SBP regarding this proposal.
- Retrieving Label 14 would make it available for future assignments and could ease the process of assigning a new M&A label if needed.
- Once retrieved, Label 14 would be placed in a "lost in queue" state to ensure sufficient time before any potential reuse.
Post-Stack Data (PSD) Discussion
- Context: A poll in May 2022 indicated a need for both In-Stack Data (ISD) and PSD. An ISD draft has been adopted by the working group. The current discussion focuses on whether PSD is still necessary and for which use cases.
- Arguments Against/Concerns Regarding PSD:
  - Joel: Questioned if sufficient use cases exist to justify the complexity introduced by PSD. Noted ambiguity in proposals (end-to-end vs. hop-by-hop).
  - Greg: Agreed that the adopted ISD solution does not preclude future PSD. Emphasized that no documented and adopted use cases currently mandate PSD. Argued for reviewing use cases to see if any require PSD over ISD. Highlighted that DETNET architecture prohibits increasing packet size with non-client information due to on-time delivery expectations, suggesting out-of-band OEM (e.g., IAM Direct Export) as more suitable for DETNET.
  - Tariq: Raised concerns that mutable data (like timestamps) placed in-stack could cause "havoc" if changing in flight, suggesting post-stack might be more suitable. Clarified that PSD should be an augmentation to ISD, not a separate, parallel solution for all use cases (avoiding competition like CR-LDP vs. RSVP-TE).
  - A sense of those present indicates a desire to avoid two different methods for the same functionality if one is sufficient.
- Arguments For/Support for PSD:
  - Jianping: ISD and PSD are complementary, not competing solutions. ISD has limitations on data size/variable length. Suggested IOAM and DETNET as potential PSD use cases. Argued that complexity is inherent in both ISD and PSD and should be addressed holistically.
  - Rakesh: Documented use cases for PSD include IOAM (similar to IPv6 options for hop-by-hop recording) and DETNET time-bound applications. Argued that PSD encoding could be similar to ISD, making implementation complexity manageable. Emphasized the desire for parity with IPv6 behavior (e.g., fixed-size, pre-allocated IOAM) to aid adoption and simplify multi-data plane environments.
  - Tony: Disagreed that PSD necessarily requires ISD; they have different properties, and some use cases may solely need PSD. Stated that IPv6 behavior is not a strict precedent for MPLS if increasing data space in PSD is needed.
- Chairs' Direction: The discussion should be a "waterfall" process, starting with establishing sufficient use cases for PSD before delving into other questions (such as format, interaction with ISD). The mailing list will be used for consensus calls if needed.
- Action for Participants: Individuals with strong opinions on the need for PSD are asked to document specific use cases, explain why PSD is the optimal mechanism, and present these at future interim meetings, addressing the questions posed by the chairs.

Decisions and Action Items

Decision: The discussion on the "first nibble" will be continued at the next interim meeting.
Decision: MPLS WG Chairs will send a poll to the working group and a liaison to ITU-T Study Group 15 (and T-SBP) regarding the deprecation of RFC 3429 and the retrieval of Label 14.
Action Item: All participants interested in PSD are encouraged to document and present specific use cases, detailing why PSD is necessary or optimal for those cases. (Rakesh volunteered to present an IOAM PSD use case as early as next week).
Action Item: MPLS WG Chairs to update the action item tracking wiki for the interim meetings.
Action Item: MPLS WG Chairs to meet on Tuesdays to finalize the agenda for upcoming weekly interim meetings.
Action Item: Rakesh to submit a request to present the IOAM PSD use case for the next meeting.

Next Steps

The next interim meeting is scheduled for next Thursday.
Chairs will communicate the agenda and any potential cancellations based on presentation requests.
Participants are encouraged to submit requests for presentation slots or discussion topics related to M&A via email as early as possible.