# IETF 113 PALS/MPLS/DetNet Joint Meeting   {#ietf-113-palsmplsdetnet-joint-meeting}

Joint session with PALS, MPLS, DetNet  
Thursday, 24 March 2022 - 10:00-12:00 Meeting time/Vienna Room: Park
Suite 3  
120/120 min allocated   
**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}*\*\**

Chairs: Stewart Bryant and Nic Leyman  
Minute-taker: Tarek Saad (+attendees on CodiMD)

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

* Chairs Intro (Agenda Bashing, etc.)  
  Duration: 5 min  
  Chairs: Stewart, Nic  
  \[Stewart\]: presented Intro

* Open DT Report  
  Duration: 10 min  
  Presenter: Loa

* MIAD Requirements Doc.  
  Duration: 15 min  
  Presenter: Stewart and Matthew  
  \[Matthew\]: presented

* MIAD Use Cases  
  Duration: 10 min  
  Presenter: Tarek  
  \[Tarek\]: presented  
  \[Wim\]: wouldn't solving for usecase 5 allow us to cover most of
  other usecases?  
  \[Tarek\]: the network programming is generic and allows encoding any
  program/instruction. It is currently under investigation.

* MIAD Framework  
  Duration: 10 min  
  Presenter: Loa/Stewart/Matthew

* https://datatracker.ietf.org/doc/draft-jags-mpls-ext-hdr/  
  Duration: 15 minutes  
  Presenter: Jags  
  Replaces draft-jags-mpls-ext-hdr-entropy-lbl  
  \[Greg\]: if all nodes need to be upgraded to support the new ELI
  interpretation, then why not assign a new SPL?  
  \[Jags\]: not all nodes need to be upgraded?  
  \[Hoayo\]: we have several other options (including new SPL), and
  format on how to encode the post-stack-data  
  \[Jie\]: do we need to have multiple SPL in the label stack?  
  \[Jags\]: only 1 SPL is needed  
  \[Jie\]: ISD can be at the bottom of stack? what about MSD limitation?
  Do we need to repeat the SPL? Bottom of stack label can be any label? 
  
  \[Jags\]: yes can be any label  
  \[Jie\]: it is not safe to identify the PSD only based on the first
  nibble.   
  \[Tarek\]: do we have to repeat the ISD header for each action (with
  opcode, and E2E bits)?  
  \[Jags\]: yes

* https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-entropy-label-id
  
  Presenter: Bruno  
  Duration: 5 mins  
  \[Bruno\]: presented  
  \[Jeff T\]: are we expecting more than 8 actions? Is that not enough? 
  
  \[Bruno\]: yes, agreed  
  \[Rakesh\]: this proposal is independent of the other extended header
  encoding, and can progress independently

* https://datatracker.ietf.org/doc/html/draft-kompella-mpls-mspl4fa  
  Duration: 10 minutes  
  Presenter: Kireeti  
  \[Kireeti\]: presented  
  \[Rakesh\]: two other solution drafts are asking for adoption too.  
  \[Darren\]: bits and data associated with it.. Some concern on
  back-n-forth  
  \[Kireeti\]: we looked at this and implementation is possible

* ID: draft-kbbma-mpls-1stnibble  
  Duration: 5 minutes  
  Presenter: Kireeti  
  \[Kireeti\]: presented  
  \[Tarek\]: mandating routers MUST NOT rely on the 1st nibble -
  wouldn't that make it hard for router to figure what is the
  application (e.g. application aware routing)?  
  \[Kireeti\]: yes, but it's a hack and can be mis interpretted.  
  \[Stewart\]: there is a draft on the dangers of doing this in PALS  
  \[Greg\]: support WG adoption of this work

* Open Discussion (followup on Open DT activities)  
  Duration: 30 min  
  Chairs: TBD  
  \[Wim\]: I think adopting a solution 'starting point' that may have a
  limit on number of indicators (e.g. 8 actions) may be preferred.
  Consider ELI after 10 yrs till today you can find it is not supported
  by many LSRs  
  \[Haoyu\]: need understanding and analysis if we want to go down the
  path of flags  
  \[Kireeti\]: 8 is plenty - the SPL is an example of where we put
  ourself in a corner. FAI proposal allows up to 11 bits in 1 LSE. A
  second LSE can grow it to 30 bits.  
  \[Wim\]: I said 8 as a start  
  \[Jie\]: reqts mentions importance of backward compatibility, and the
  efficiency of MPLS. Keep those in mind when we want to introduce
  flexibility. Anyalysis on forwarding efficiency and backward
  compatibility is needed for each proposal.   
  \[Jeff T\]: from deployability perspective. We need to start with
  something straight forward (simple)  
  \[Darren\]: we have a problem when we go to the bottom of stack and CW
  exists. Would like to see how that is being solved.  
  \[Zafar\]: second what Wim said. ELI/Bruno's ID is a good start.  
  \[JeffreyZ\]: allowing ISD does not preclude PSD. Suggest allowing
  both options  
  \[Bruno\]: the ELI approach is closer to deployability.  
  \[Tianran\]: similar concern on adopting multiple solutions. There are
  several analysis on hardware. The instack solution cannot convince
  most people, cannot show any advantage/benifit.  
  \[Ketan\]: WG should consider adopting the Bruno draft as interim  
  \[Kireeti\]: suggest attending talk by Tony on danger of reusing ELI
  before making any decision.

* * *

AGENDA INFORMATION FOR THE SESSION  
**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}**\*\***{::}*\*\**

●Agenda  
https://datatracker.ietf.org/meeting/113/materials/agenda-113-pals  
●Etherpad/CODIMD  
https://codimd.ietf.org/notes-ietf-113-pals  
●Jabber room: xmpp:pals@jabber.ietf.org?join  
●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 Jabber during the meeting)