Welcome to the JOINT MPLS/PALS/DETNET Interim MNA Meeting


  1. Meeting Introduction and Agenda Bashing
    Tarek gave the introduction, no comments and questions.
  2. New meeting series (changes)
       Loa introduced the motivations, plans of the interim meeting
  3. New List of Action Items(Tarek)
    https://wiki.ietf.org/group/mpls will be used to track the Actiion
  4. Update on ‘The First nibble’ Outstanding poll(Loa)
    Poll closed, the discussion did not converge enough to make a
    consensus call. We will continue to discuss it at next meeting.
  5. Upcoming Poll for retrieving Label 14 bSPL(Loa)
    A poll will be sent out for retrieving Label 14 bSPL. At the same
    time as the poll is sent out there will be a liasison
    to SG15, SG13 and TSB
  6. A decision on whether to use PSD or not? (Loa) The following
    question was posted:

    1. Are there sufficient use cases to motivate PSD?

      • If yes, can the use cases be solved with ISD?
      • If no, why not? what are the prohibiting issues?
    2. Is the PSD use case / solution compellingly less complex than

    3. Do some use cases for ISD prohibitively increase the stack
    4. Are the use cases motivating PSD such that PSD solutions are
      required urgently/immediately? 
      What is the time window to target?
    5. Are there compatibility issues with PSD?  What are they and what
      is the impact?

[Joel]: the old poll was to pick between 'only PSD' and 'ISD and PSD'.

[Greg]: agree with Joel and there may be cases for PSD.
[Jie]: The previous discussion and conclusion was that both ISD and
PSD are needed in the framework. Agree there are cases for PSD that we
documented/discussed. The complexity of MNA cannot be attribute to PSD
[Rakesh]: there are number of usecases (e.g., iOAM, DetNet) that we
described for PSD.
[Rakesh]: MPLS iOAM should do the same way as IPv6 OAM did.
[Tony]: it may be more appropriate to use PSD for some use cases.
[Tarek][1]: what I want to avoid is having 2 competing proposals for
solving the same thing
[Tony]: Suggest to check the optimal mechanism for each use case.
Suggest to disable IPv6 to avoid complexity.

[Joel?]It was noted that the questions presented 1.-5. from the
Chair's slides are a waterfall, i.e., we should answer the former
questions before considering the latter as the latter may not be
relevant depending on the conclusions of the former. i.e., Are their use
cases for PSD? If so, can they be resolved with ISD? If not, what is the
urgency? etc.
[Tarek][1]:There were concerns about some potential use cases with
potentially "mutable" data that might theoretically cause concern if it
were to be placed in-stack.
[Greg]:It was noted that we will consider ISD and PSD options and work
on solutions that don't preclude either. We have an agreement on a
solution for ISD, which doesn't preclude development for PSD. There
might be theoretical cases, in the future that might benefit from PSD.
Those should be framed and evaluated at that time. There are currently
no adopted use cases that can't be addressed using the adopted ISD
solution. Perhaps we should review these and other practical, urgent use
cases to see if they can or can't be resolved with ISD avoiding
potential PSD complexity.
[Jie?]There are use cases e.g., IOAM that have solutions proposing
PSD. They may not be as complex as thought to be.
[Greg]:It was noted that the IOAM PSD proposal is prohibited for
DetNet as increasing the packet size for DetNet for non-client data will
change the on-time delivery characteristics. Even active-OAM traffic
resource must be considered to ensure delivery characteristics are
preserved. IOAM direct export option is a reasonable solution that keeps
IOAM overhead limited. It was proposed to look at what is necessary to
do vs what we want to do in terms of solutions.
[Tarek][1]:It was noted that when we discuss PSD we are talking about
leveraging what we have done for ISD, but there may be ISD and PSD data
in the same packet. We are not talking about a parallel solution between
ISD and PSD.
[Rakesh]:There are several trace drafts - IPv6 states it will not
support such where the packet grows. MPLS should follow the same path
where the packet doesn't grow.
[Tony]:It was noted that PSD does not required ISD - see the list.

[Greg]:It is not clear what the relevance of this discussion is to
IPv6. If we decide we need increasing data space, that seems like a
reasonable thing to do. It is unclear why the MPLS data plane should
replicate what is required for IPv6. IOAM in an MPLS network is a method
that provides some information where IOAM export is sufficient. Other
information is useful and helpful but not essential. The original RFC
that describes 'trigger packets' but direct export IOAM RFC can be
supported by ISD. We don't need to support function that is not
conducive to the existing MPLS architecture.
[Tarek][1]Are we saying, by saying that PSD does not require ISD, that
we can develop parallel ISD and PSD solutions to the same problem? The
goal was not to develop parallel solutions but leave flexibility to
develop solutions using PSD that have no dependency on ISD.
[Rakesh]:It was clarified that incremental packet size growth can be
supported in MPLS and earlier comment was not intended to limit this. We
may use IPv6 as a consideration but will do what is needed for MPLS.

Following the questions laid out by the Chairs, we should consider use
cases and whether the can be solved with ISD, and if not we consider
The Chairs noted that we should look at the usecases, what we've done
and determine what must be done to support the usecases going forward.
It was noted that DetNet applicability of what we do for MNA is
It was noted by the Chairs that those who need/want PSD should document
the use cases, answering the questions in the slides, bringing the
content to an interim for discussion.

  1. Items for next meeting (2023-06-01)
    It was noted that the Chairs will meet each Tuesday and finalize the
    agenda for the Thursday meeting, based on input they receive from
    participants. It was noted that those requesting slots can request
    as early as they wish, and the earlier the better.
  2. AOB

[1]: there are concern when data is mutable and is carried in the stack (ISD). This can be provided by PSD.