PALS/MPLS/DetNet/SPRING Joint Meeting IETF 115
\?
************************

Meeting Information

Wednesday, 9 Nov 2022 - 9:30-11:30 Meeting/London time
Room: Richmond 2
110/120 min allocated (as of 8 Nov 2022)

Chairs: Stewart Bryant
Secretary: Dave Sinicrope
Minute-taker: Dave Sinicrope (+attendees on HedgeDoc- HedgDoc notes from
meeting incorporated)

Note: all persons with questions and comments (including those
physically present) will need to line up into the virtual queue on
Meetecho
************************

Agenda

1. Chairs Intro (Agenda Bashing, etc.)

Duration: 10 min
Chairs: Stewart BRYANT
Stewart opened the meeting and went through the Chair's slides. Of
special note is the continuation of the MPLS Open DT. No questions or
comments.

2. Open DT Report

Duration: 10 min
Presenter: Tarek SAAD
Tarek presented the slides providing an update on the MPLS Open DT work
on MPLS Network Actions (MNA).
It was noted that the Open DT is looking for volunteers to help with
the wiki migration.
See in particular the Next Steps slide for continued work in the Open
DT.
No questions or comments.

3. https://datatracker.ietf.org/doc/draft-ietf-mpls-mna-requirements/

Duration: 10 min
Presenter: Mathew BOCCI
Matthew presented the slides providing an update on the MNA
requirements draft. It was noted particularly that the requirements are
on protocol design, not on implementation. The comments from the WG
adoption call are in an appendix as they are addressed. Note that the
draft has been renamed.

• Jie Dong: I also made some comments to the requirements draft, not
  sure whether they have been considered in the updated version? And
  do we have some other way to track the remaining issues which have
  been removed from the appendix?
• Matthew: We did address your comments. please review and ensure we
  haven't missed anything
• Loa Andersson: @Jie, you can look at prior versions on Datatracker
  so you can see the appendix there.
• Stewart: need to see if we missed his comments
• Loa: do a simple diff to see what was addressed.

• Stewart: we will look as Editors, but good if Jie also takes a look

  No further comments or questions.

4. https://datatracker.ietf.org/doc/draft-jags-mpls-mna-hdr/

Duration: 20 minutes
Presenter: Jaganbabu RAJAMANICKAM
Jags presented the slides updating on the MNA Header Encodings
individual draft. The presentation goes through details of proposed MNA
encodings. It is a merge of a number of prior encoding proposals. It
introduces the Network Action Sub Stack (NASS) for both instack and
post-stack ancillary data.
It was noted that questions will be held to the end of the
presentation.
See Next Steps.

• Loa: claim alignment with the framework, but the abbreviations uses
  NASS while the framework uses NAS. Will this be updated?
• Jags: Yes
• Loa: please go through the entire framework
• Joel Halpern: fundamental approach is fine. If understood the draft
  detailed concerns:
  • a number of different ways to solve he same problem. Need to
    focus on consolidating the ways a problem is solved
  • there is the ordered bit that tells process to process in order.
    not sure what problem this solves. Could say alwasy process them in
    order that would simplify implementation
  • Jags: there is a mix of operations some ordered some not, to
    ensure order the bit can be set so intermediate nodes that don't
    support ordering can drop the packet.
  • Joel: either some class of nodes don't support the bit in which
    case they can drop the packet, but not clear why we need a bit.
  • if we have an MPLS label stack with one or more substacks and
    instack data. If all of the instack references are popped what
    happens to the post stack data. Also what happens if the last node
    doesn't understand post stack data? There seems to be some
    interactions between the network actions and post stack data than
    need though
• Greg Mirsky: p bit and option 1 relationship - it appears that the p
  bit (slide 7 and 10) two ways of indicating post stack data objects.
  First with p bit and then it says there is post stack
• jags the PSD is not to indicate post stack data. The post stack data
  will come right after the label stack. If there is some data between
  the end of stack and post stack actions then need offset.
• Greg: if opcode 1 is post stack data then why do we need offset
• Jags: if the post stack data is not immediately after the label
  stack then need the offset. This would be used if there was in stack
  data after the label stack then this is used to point to the
  post-stack data.
• Greg: this seems to be a gap that needs further discussion in
  particular for non-IP payload
• Matthew: second Joel's comment in particular about the last node not
  knowing what to do with the post stack data on PHP at egress node
• Stewart: some may be assuming that implementations know what to do
  with post stack data and this is not the case.
• Matthew: may need to strip the post stack data when you see the MNA
  label but not sure this is possible all the time.
• Jags: see slide 22 - this is the case you are referring to -
• Matthew: this only addresses the IP case, not the non-IP case
• Jags: this is where the Op code 1 comes in
• Matthew: but if you are doing PHP you are going beyond the control
  word
• Stewart: we need to think about this more
• Vishnu Beeram: see slide 11 - how does the flag based data operate
  ???
• Jags: all the NAI belongs to the same group
• Stewart: we need to continue this discussion in the Open DT meetings
  and understand how this works. Concern regarding the complexity of
  the encodings in the draft.
  No further comments or questions.

5. https://datatracker.ietf.org/doc/draft-gandhi-mpls-ioam/

Duration: 10 minutes
Presenter: Rakesh GANDHI
Rakesh presented the slides. It was noted that this draft is based on
draft-jags above. Authors are still taking comments before asking for WG
adoption request.

• Greg: so proposal is to use preallocated and incremental IOAM data
  collection in the post stack data
• Rakesh: where IOAM data fields are present, they will be updated
  (after BoS and before payload) No recommendation on which should be
  used
• Greg: this is the issue. According to the RFC If pre-allocated and
  incremental are used, where is the data collected?
• Rakesh: it would be carried in the bottom of stack before the
  payload
• Greg: ok if the preallocated space is large e.g., 1K how much
  payload is carried? it doesn't leave much room for payload.
• Rakesh: these are implementation and deployment details depending on
  hardware capability
• Greg: what woudl be the impact on a DetNet data plane?
• Rakesh: we dont' address that here
• Greg: for incremental space must be added to the packet, and the
  packet re-written so what is performance impact
• Rakesh: for incremental it was noted that not much hardware can
  support this so this will be noted
• Greg: the RFC defines a number of modes not all of which are
  applicable to the MPLS data plane so we need to decide which to use.
• Stewart: need to do a detailed review
• Greg: need to have this discussion once we have an encoding in the
  course of adopting the draft
• Loa: the draft is mature, but relies on draft-jags so need to adopt
  draft-jags first
• Rakesh: yes
• Kireeti Kompella: there is a separate discussion on what one can do
  with iOAM and this is a discussion of how to encode it. Good point
  that we may want some modes but not all iOAM modes.
• Haoyu Song: same point as Kireeti, but up to implementation to
  choose support
  No further comments or questions.

6. https://datatracker.ietf.org/doc/draft-huang-detnet-rdi/

Duration: 10 min
Presenter: Hongyi HUANG
Hongyi presented the slides on the new DetNet OAM draft.

• Jeff Haas: this mechanism is not intended to cause the BFD session
  to go down, correct?
• Hongyi: we can discuss first in DetNet then in another session.
• Jeff: Not really answering what was asked. The BFD session stays up,
  correct?
• Hongyi: yes
• Jeff: First, for what you are doing the timers need to be longer
  than set or reordering and latency can disturb BFD, so BFD not a
  good solution. Second point is that the proposal carries data not
  intended to be in BFD. Greg Mirsky is doing similar work in a draft
  that might be used. Please consider coordination with him.
• Sasha Vainshtein - nothing to add to prior commenter, agree with
  comment. Please refer to RFC 5880.
  No further comments or questions.

7. https://datatracker.ietf.org/doc/draft-tan-detnet-cap-discovery/

Duration: 10 min
Presenter: Ren TAN
Ren presented the slides also on DetNet OAM.
No comments or questions.

8. Open Discussion

Duration: 30 min

• Stewart: originally we intended to discuss closing the Open DT
  meetings. Good discussion in the chat room. Any comments
• Tarek: could us remaining time to discuss post stack data and where
  it sits. Useful comments in the chat. Good topic to continue now or
  later.
• Loa: agree with Tarek. Would like to hear elaboration on complexity
  and MPLS simplicity to kick off discussion.
• Stewart: (queasy) the processing model I was aware of for MPLS is
  very simple. Clearly need for ancillary data, but concerned that as
  we move to vector and predefined action that we need to pick apart
  components to determine what to do with the packet. Concerned the
  effective hardware friendly method will no longer be sustainable.
• Kireeti: Share concern. (queasy) A few features put into MNA
  approach e.g., processing at select nodes, may be in there just
  incase without distinct use yet. order of processing also the same,
  in there just in case but no distinct use case. These need
  discussion.
• Stewart: don't want to derail progress, but need to keep concern
• Tony Li: extra concern (nausea) of the complexity. e.g., arbitrary
  ordering seem liked something people wanted, same with instack and
  post stack. If we want to simplify which requirements can we relax?
• Andrew Alston: (no hats) can see how to make all of this work, but
  concern because of complexity in long term implementations would
  have a "buggy period" that will cause operators to steer away from
  it.
• Kireeti: propose in a place we used 8 of 16 labels and concern of
  how fast we would use the rest. we would use one for MNA for 10-20
  functions - why would we not take approach to step into new waters,
  keep problem constrained determine how this works and what problems
  it's solving. Once we get past one reserved water has to do
  everything we can start and see where
• Haoyu: regarding the ordering issue we lack tangible use cases to
  ask for ordering of applications. Better to find solid cases before
  making design mechanisms and choices. To make simple we might say to
  execute ISD before Post Stack, but not a good idea. If an action
  requires a good deal of ancillary data it goes into post stack so
  instack not always higher priority than post stack applications.
  Suggest that the encoding dictates how things are executed
• Tony: we went over the need for ordering in the DT meetings several
  times. This should not be undone.
• Adrian Farrel: Concerned (nausea) Suggest reexamine requirements and
  focus on what we need to do vs what we could do.
• Matthew: Agree w/ Adrian. Where did we start with requirements was
  with the solutions not with the use cases. A bit backwards, but use
  cases were not sufficiently defined at the time. Perhaps we should
  refocus on use cases. Many requirements based on what could be done
  e.g. on future hardware
• Haoyu: aware of ordering discussions and fine example cases, but one
  example is ordering of slicing and iOAM applications, however
  questioning the usecases for ordering
• Tony: no way to determine order based on assumption. Not having
  ordering can cause different results for different execution order.
  Either say order is irrelevant or specify. If we specify then we end
  up where we are.
• Jie: Agree we need to look at requirements again. Top priority
  requirement is backward compatibility so not to break current
  networks. Regarding ordering, perhaps we don't need to be so
  flexible but perhaps can be based on default processing rules rather
  than the position in packet. For full flexility we need use cases so
  not to over engineer solution.
• Matthew: one thing that may help in addition to basing requirements
  on use cases would be to structure architecture a bit better, a bit
  more layered.
• Tony: please add text.
• Matthew: similar to MPLS-TP and PW, we have fairly prescriptive
  architecture which may help
• Stewart: closing remarks, queue empty
• Tarek, Loa: thanks for interesting discussion. Chairs will have a
  coordination meeting on Tue and DT meeting on Thur.
  No further comment or questions
  Stewart closed the session. 11:21 local time.

Support Information for the Sesson

• This Agenda:
  https://datatracker.ietf.org/meeting/115/materials/agenda-115-pals
• HedgeDoc Meeting Notes: https://notes.ietf.org/notes-ietf-115-pals
• Chat room: https://zulip.ietf.org/#narrow/stream/pals
• MPLS Open Design Team Wiki (The MPLS open design team keeps a log of
  its work here: https://trac.ietf.org/trac/mpls/wiki/MPLSOpenDT
• If you have any general issues with Meetecho, the meeting audio,
  etc., send an email to support@ietf.org (Note: a Meetecho tech will
  be monitoring the chat during the meeting)