Minutes IETF110: pals
minutes-110-pals-00

*********************************************************************
IETF 110 PALS/MPLS/DetNet/SPRING Joint Meeting
Friday, 12 March 2021 - 12:00-14:00 UTC Room:7
120/120 min allocated
**********************************************************************
Chairs: Stewart Bryant and Andy Malis
Secretary: David Sinicrope

1. 5 min - Chairs’ intro - Andy MALIS
Andy opened the session - the Chairs are Andy Malis (PALS), Nic Leyman (MPLS),
Lou Berger (DetNet) and Jim G (SPRING) Andy presented the Chair's slides. It
was requested that questions during the talk be limited to clarification and
keep the bulk of the discussion for the 45 min slot toward the end of the
meeting.

2. 20 min - MPLS architectural considerations - Stewart BRYANT
Stewart presented the MPLS architecture slides noting the recent activity that
motivated this meeting, and the MPLS architecture and model. It was noted that
since only the top label is processed, the forwarding is light weight and
efficient, in particular for the fastpath (hardware forwarding). It was
stressed that Extended Special Purpose Labels (ESPLs) are the antithesis of the
original approach.  There is concern about the size of the label stack and
complexity. It was noted that PWs and DetNet have OAM for themselves at the end
of the label stack which was kept mutually exclusive with data and never more
than one ACH. We need to examine and understand when to use SPLs vs a regular
label and signaling in the control plane. It was stressed that the list of
proposals is not exhaustive, there are likely others. (e.g., It was noted that
the "path id draft" is missing.) Is it easier for hard ware to process data
after the stack or in the stack.  It is normal to process data after the stack
has been processed at termination.  It was noted that the forwarding buffer
where forwarding processing takes place is incredibly expensive.  Not every
function can have large number of labels. It was noted that in the original
model the forwarding was not to look beyond the top of stack label and there
was also processing of the TC and TTL.

3. 10 min - DetNet data plane, RFCs 8938, 8939, 8964 - Balázs VARGA

Balázs presented the slides.  It was noted that the DetNet function looks
similar to the Pseudowire processing and control word. No questions.

4. 10 min - Generic delivery functions -  Zhaohui (Jeffrey) ZHANG
https://tools.ietf.org/html/draft-zzhang-intarea-generic-delivery-functions-00
Jeffery presented the slides.
Must GDFH always be BoS, it must always follow a BoS label, but after the GDFH
there could be additional label stacks.  This is the current thinking but may
change.  But could GDFH be anywhere in the stack?  Currently, yes, but may
evolved. e.g., if it is applied to hop by hop behavior.  There was some concern
as to how it would work with segment routing.

5. 15 min - MPLS in-situ OAM - Rakesh GANDHI
https://tools.ietf.org/html/draft-gandhi-mpls-ioam-sr-06
Rakesh presented the slides.
It was noted that the IOAM is carried past the end of stack in the MPLS header.
It was noted that putting the ACH at the end would be disruptive to DetNet
where the processing is time sensitive and in this proposal comes after a long
and variable length set of IOAM data. It was noted that currently the G-ACH
does not have a "next header" concept. However the channel defines what
follows.  There is no intrinsic endoding of what follows, but one can define
what follows depending on the G-ACH type. It was noted that there are 64K and
that it would be an expensive table look up which would be expensive but still
feasible.

6. 10 min - Multi-purpose Special Purpose Label for Forwarding Actions -
Kireeti KOMPELLA https://tools.ietf.org/html/draft-kompella-mpls-mspl4fa-00
Kireeti presented the slides.  In particular, see slide 3 on the Behavior of
Forwarding Engines on the Label Stack.  It was noted that processing anything
beyond the top label, is not treating the label stack as a stack.  It was noted
that the architecture was designed at a time when the forwarding processing
power was far less than today.  There are questions we should be asking: What
is the architecture of the label stack? What is the architecture of what comes
after the label stack?  What functions are needed today?  How does this map
into the power of NPs today? See slide 9 It was noted that we do need to be
concerned about legacy, but we should also be looking at how we can be doing
more.  It was noted that jumping to the BoS, especially with the label stack
size SPRING has introduced can be difficult.  In examining whether the ELI
should be at the top of stack, the label stack ends up not being a stack any
longer.

7. 45 min - Discussion - all

Rakesh: If in the Forwarding Actions Indicator always at bottom stack.
Kireeti: it isn't it can appear anywhere in the stack and be processed.
Rakesh: if not at BoS it could break existing network by introducing new
forwarding semantics. Kireeti: this would happen at the introduction of a new
special purpose label.  If the hardware doesn't understand the label it will
not parse it correctly anyway and should be ignored or the packet should be
dropped which will not necessarily break anything. Rakesh: the pros and cons
would need to be weighed. Kireeti: There are issues with special purpose labels
anyway, however with this it can be repeated and pushed to the top so it is
processed right away. Stewart: This is only one proposal, we should come up a
level and consider a general approach and then dig into details Haoyu Song: it
was noted that a few years ago there would be several bottom of stack functions
such as IOAM, Service Chain, etc. that may require hop by hop or end to end
processing.   Tried to borrow IPv6 extension headers to allow them to be jumped
over for processing.  Several related drafts are published describing the
extension headers that list the ways the headers can be used along with the
pros and cons.  There was little interest at the time, but now seems to be a
good time to look at them again. Andy: the drafts referenced are in the
non-exhaustive list provided in the overview at the start of the session
Jeffery: on reason for the GDF is to make it applicable to many layers.  e.g.,
insitu OAM can be done for MPLS, BIER, etc.  A general function would be more
useful if applicable to other layers and technologies. Toerless: We have done a
very much ad hoc set of solutions.  It would be good to have more of a
strategic approach with an encoding language or scheme.  This would have an
adjacency to P4 so the IETF can come up with more flexibile headers. Rakesh:
one important aspect of hop by hop processing is that we shouldn't have to walk
the entire stack to figure out that something should be done, it should be
presented up front. Zhenbin Li: Most of this general processing is done for
IPv6. For Ethernet and for Bier it would be difficult and the generic delivery
function causes complications. Jeffery: Don't agree. Fragmentation are defined
for IP, but can be done for MPLS and BIER if we go with a generic function.  It
is a bigger topic but we should be resolving the issue for all layers if
possible. Rakesh: we should optimize the midpoint processing of the header
without diving into the metadata and/or G-ACH. Jeffery: currently we are only
dealing with edge to edge, but hop by hop are other functions to be considered.
 Those functions can alos be abstracted to generic delivery function.  More
homework is needed. Tarek: the usecase for mulitple G-ACH and a G-ACH type and
having multiples after the BoS.  it is not clear that the way it was described
is how IANA is allocating the types. Also for every combination a new type is
needed. Not sure this is the road we want to be on. Weiqiang: it was noted that
the third draft on the list draft-cheng was adopted by the MPLS WG Stewart: we
need to build better list of drafts via the email lists Rakesh: the label +
G-ACH defines the action on the node. not a cascading of the G-ACH Greg Mirsky:
RFC 8169 resident time measurement uses ACH type that defines the encoding of
what follows.  This is a good example of the ACH type use.

8. 5 min - Chairs’ summary - Stewart BRYANT

Stewart summarized the situation noting that there is sufficient interest and
there is some urgency.  There was some assertion that we should let the normal
progression of drafts continue.  It was noted from the ADs that indeed the
urgency and interest is there and that waiting for the next IETF is not
sufficient. There were suggestions for an interim and for a design team
although there was concern about a design team being as large as the Working
Group.

The discussion of next steps is to be done on the MPLS email list.
Stewart will update the slides and they will be posted to the meeting materials.

None of the proposals were noted as being bletcherous.