*********************************************************************
IETF 112 PALS/MPLS/DetNet Joint Meeting
Joint session with PALS, MPLS, DetNet
Monday, 8 November 2021 - 16:00-18:00 UTC Room: 6
120/120 min allocated 
**********************************************************************
Chairs: Stewart Bryant and Andy Malis
Secretary: David Sinicrope

1. 5 min - Chairs’ intro - Andy MALIS
Andy opened the meeting at approximately 16:02 UTC, approx 70 participants.
There were no questions or comments on the agenda.


2. 20 min - Requirements for MPLS Label Stack Indicators for Ancillary Datas - Matthew BOCCI
http://datatracker.ietf.org/doc/draft-bocci-mpls-miad-adi-requirements
Objective: Provide status update on the draft and solicit comments and feedback.
Matthew went through the slides and summarized the requirements draft purpose, progress and issues.  In particular the General Requirements note fundamental "dos and don'ts" for the Design Team solution formulation.

Looking to continue gathering requirements from emerging applications.  Also would like early review and feedback to the Open Design Team.
Kireeti: we should use the special purpose labels as a last resort: We've been using them for other things. The FAI approach uses one SPL for multiple things.  This requirement should be relaxed if the SPL is used for multiple purposes.  The last resort should be applied if there is only one purpose to the SPL.
Matthew: agree it multiple purposes for an SPL should be allowable.
Kireeti: slide on backward compatibility - There was an issue with the first bullet - "Neither an ADI or ancillary data must be delivered to a node that is not capable of processing it" - When we did ELI we sent the info and if the node was capable of processing, fine - if not, it was disregarded - no big deal.  This distinction, comprehension required or not, should be clarified and perhaps the requirement relaxed a bit.

3. 20 min - DetNet ACH Update - Greg MIRSKY
https://datatracker.ietf.org/doc/draft-varga-detnet-service-sub-layer-oam/
Objective: Present and discuss updated d-ACH (DetNet ACH)

Greg went over the slides highlighting the work in DetNet on Data Plane and OAM.
Kireeti:  The space of the 1st nibble is very short, to be covered later, but we need an extension field with sub types and extend the space that way rather than live within the small space.
Greg: Perhaps a more generic mechanism would be versioning.
Kireeti: yes, but versioning is for different versions of the same thing vs different uses, but still this warrants an offline discussion of how to achieve a more general use for the first nibble.

4. 15 min - MPLS First Nibble - Kireeti KOMPELLA
http://datatracker.ietf.org/doc/draft-kbbma-mpls-1stnibble (TBD)
Objective: Make people aware of this work; start discussion on what’s currently in the draft; paint a roadmap of future updates.

Kireeti presented the slides addressing the first nibble issues.
Haoyu Song: why should we care about the first nibble given we know what follows the label stack.
Kireeti: We should take the best path going forward
Loa: supporting Haoyu that we actually know from the flag field what follows, but even we didn't know that, we could increase the subtype to 8 bits.  Take one 
MFN and then extend with 8 bits
Kireeti: this is currently just a proposal perhaps every MFN would have such a qualifier
Stewart: we have a qualifier in the CW
Kireeti: we can group more things under the top four bit field.  We seem to be in basic agreement. 
Wim: the PSD <audio cut out>
Kireeti: would like the PSD to be self describing - so you use indicator track structure not PSD there. Once you have a structure, it is self describing so that you can parse and process a good deal of data within a TLV structure.
Wim: dont we need something for the order? wouldn't there be a use case where a PSD can't occur before another?
Kireeti:  The total length of PSD comes into play.  If for example there is a TLV structure, the total length can let the implementation take all of them and then order them as needed.  The MFN is independent of this - here is the MFN, the subtype and the length and then all after that is dependent on the application
Wim: yes, but the order is something to consider.
Greg: this might look similar to IPv6 ext headers - we can discuss on the list, but they have their own pain that we can learn from.
Stewart: The WG should be under no illusion that there will be random raw Ethernet packets floating around the network and thus there can be no assumptions about the first nibble without other qualifiers indicating the packet is NOT an Ethernet packet.
Kireeti: we sadi there would not be a protocol identifier, but we need to find a way to move forward.
Stewart: we do need to move forward, but within the constraint that we don't obsolete any existing LSPs

5. 15 min - Multi-purpose Special Purpose Label for Forwarding Actions - Kireeti KOMPELLA
https://datatracker.ietf.org/doc/draft-kompella-mpls-mspl4fa   
Objective: Make people aware of this work; start discussion on what’s currently in the draft; paint a roadmap of future updates.

Kireeti presented the slides.
There was no time for questions or comments immediately following the presentation.  The participants were asked to hold their questions until the discussion part of the session.


6. 15 min - Network function Indicator - John DRAKE
https://trac.ietf.org/trac/mpls/wiki/NFIProposal
Objective: Make people aware of this work; start discussion on what’s currently in the wiki.
John presented the slides 
See Discussion for questions

7. 20 min - Discussion - All

Kireeti: say there are 5 labels and there is an SPL that says it should be processed at each hop. I can do forwarding by the top label, but will need to parse the stack and determine if SPLs are interesting to "me" as a P or PE router.
John: the hop by hop SPL always precedes the end to end SPL
Kireeti: so you have to parse the whole stack
John: yes, the same as the PSD proposal.  The thing is to fill in 
Kireeti yes but there are differences. Don't want to have to parse the stack to find end to end items.
John: if it is essential to forwarding it goes in the stack, if not it should not go into the stack.
Kireeti: If it is a network function it could be heavy weight.  The forwarding actions could be in the label stack. Other things are in the post stack data. If not hop by hop then put it in the post stack data.  There should not be in stack data that is hop by hop mixed with end to end.  
John: this is consistent with what is proposed.
Tariq: where is the option to not process
John: the ancillary data did not make it in. There could be an option that is just throw the packet away
Stewart: There could be other things that come into play such as an indicator that indicates whether it is worth parsing the stack.  
John: This is part of the network action definition.
Stewart: people were assuming that data hop by hop is at the top of the stack.  
John: no the indicator says what you do and where you can find the data.
Stewart: some hop by hop data may go in the stack, but other hop by hop data may be outside the stack 
Kireeti: The FAI says everything hop by hop is in stack, Not in stack end to end, post stack is end to end. No need to put end to end in the label stack.
John: there may be network actions that say what is the ancillary data and where it goes.
Haoyou Song: Once we have a clear way of defining the label stack we should reorganize information to the definition. No doing so complicates the parsing.
John: one of the criteria for proposals is to check the proposals with the hardware designers engaged.
Kireeti: there my be data that you want in stack so it is right there so you can process it.  Anything you put post stack you have to parse the label stack to get it which can be onerous.  The entropy can be done without going to the end of stack there is a hash value right there.
Loa:  Because it can do something doesn't mean you do it.  There are alternatives that we should consider
John: yes when we define a function, we define where the data goes.
Loa: There is a WG Chair decision there are 8 SPLs left, if we take 25% of those for handling indicators, then there is a concern we are on the low side of SPLs. 
John: once we have the 2 SPLs the hop by hop and end ot end functions are extensions of those 2
Loa: we should look whether we can do this as efficiently with one base SPL.
Kireeti: don't see a reason to carry in stack data that is end ot end. If not urgent to process it then put it at the end of the stack.  We have four cases, but not all four cases are valid.
Stewart: Do we need physical or logical definitions of these bits. MPLS gets around some of this via definition via the control plane. This could reduce the number we need.
Adrian: Wondering about Kireeti's point about end to end. A routing operation that must take place at the final router, not clear whether that is end to end data after the stack or end to end data where you are at the end of the path and you are about to take off the last label.
John: it may be neither hopy by hop or end to end or the router popping the the top of stack label e.g., end of the tunnel.
Loa: when we did MPLS-TP we dealt with MIPS and MEPS - a MIP could be allocated anywhere along the LSP is this similar?
John: yes alluding to it in response to Adrian.
Loa: could be in the middle of the LSP but still want to address it
John: Yes it is an area we can work.
Kireeti: when hop by hop it doesn't mean every node in the path must process it. if we have a dichotomy that is end of tunnel or hop by hop - if noone in the middle interested then "end to end"   When then would you put data in the ISD that is not processed by some intermediate node?  ISD is hop by hope, PSD is hop by hop or end to end.
Adrian: came up long ago is whether it should be distinguished if there are actions that a router must operate on (if not the packet is not forwarded), vs actions actions a router may operate on (if not the packet is forwarded).  
Kireeti: this is in my slides
John: this would be in the definitions.
Adrian: can't be in the definitions because they would need to know if understood or not
Andy: queue closed

8. 10 min - Chairs’ summary - Stewart BRYANT  
This is a body of work that turned out to be much more complex and detailed than anticipated.  Need to dig further.  The requirements are the foundation to the decisions that need to be made and there needs to be more quality time spent reviewing and refining them. 

The matters of how to encode the information (Kireeti and John) will need focused time by e.g., a break out group more than the weekly calls and this session.  The Chairs may set up some specialist discussion.

Another thing to discuss is the processing model. This is fundamental to the decisions to be made. i.e., how an MPLS router processes the packets.  This needs to be discussed without becoming a proxy debate for the proposed solutions.

The breakout discussions can report into the weekly meeting. Concern that 1.5hrs/wk in the weekly meetings will not be enough to fully consider the details.
Lou: if you need more discussion time then schedule more discussion times or schedule more virtual meetings.
Kireeti: We have had several weekly meetings postponed for several reasons. We could fit this into the weekly meetings.  The calls are 1.5 hrs and we do need to do status, but we could dedicate a meeting to a specific topic (e.g., sans status).  However, there would need to be offline work first.
Stewart: The Chairs need to discuss how to get the volume of work done in a sensible time.

No further comments, questions or discussion.
Andy closed the session at 17:55 UTC



**********************************************************************
AGENDA INFORMATION FOR THE SESSION
**********************************************************************
This is both formal reporting of the progress on the MPLS Open Design Team and a working session to progress the work.

●Agenda
https://datatracker.ietf.org/meeting/112/materials/agenda-112-pals
●Etherpad/CODIMD
https://codimd.ietf.org/notes-ietf-112-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)