Minutes IETF112: pals
minutes-112-pals-00

*********************************************************************
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)