Minutes IETF111: pals
minutes-111-pals-00

IETF 111 PALS/MPLS/DetNet Joint Meeting

Joint session with PALS, MPLS, DetNet

Tuesday, 27 July 2021 - 16:00-18:00 PDT 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 session at 16:00 and presented the Intro slides.
Roughly 50 participants attended the session.

2. 20 min - MPLS Open DT summary and status - Stewart BRYANT
Stewart presented the slides providing the summary and status.
Tarek: are the meta-data/extended headers going to all be processed in the fast
path, slow path or both? Stewart: both e.g., fast reroute needs fast path. 
Will depend on whether action needs to be done in realtime with packet or if
action can wait. Latency sensitive processing/forwarding needs to happen in
fast path. Kireeti: in 6man there was discussion of making the hop by hop
option work again.  The questions they had echo questions here. e.g., how much
do you process in fast path?  Helpful even to align terminology, approach and
issues, to combine with folks there e.g., Bob [Hinden] Loa:  Additional piece
of information, not the TEAS WG but the SPRING WG that were initially involved
in the DT.  The list of DT agreements reflect the results of a DT meeting, but
will be sent for a consensus call to the MPLS and other WGs. Toerless: need to
also say that ignoring all the new things is also considered and valid.

3. In-stack Indicators

    3.1 10 min - draft-kompella-mpls-mspl4fa FAI MSPL I-D: Kireeti KOMPELLA
    Kireeti presented the slides.
    Toerless: In 6man there was one draft that was a generic next generation
    router alert, perhaps there is something to bring up in LSR for consistency
    in the control plane.

    3.2 10 min - draft-bryant-mpls-aux-data-pointer-00: Stewart BRYANT
        Stewart presented the slides.
        Kireeti: There may be a way to combine the TC TTL bits with the pointer
        concept.  In the 01 draft [draft-kompella-mpls-mspl4fa] it addresses
        when to put data right there or when to refer to data beyond end of
        stack.  It will depend on the use as two when you need things in the
        label stack or outside the label stack, similar to a cache to a disk. 
        Label stacks are getting fairly big and we need to discuss with those
        doing silicon about the practical limits and boundaries.  Also a reason
        to work with 6man on how to do the processing. Tarek: normally extend
        headers are process sequentially. But it sounds like what is being
        proposed is that a header is processed not sequentially. Stewart: there
        are some cases where you want to skip over or share specific data, but
        only on some hops. Need to look at the applications and then decide
        what the stack processing must do.


    3.3 5 mins- draft-song-mpls-eh-indicator: Haoyo SONG
    Haoyo presented the slides.
    Jaganbabu: the concept seems like it would make complex hardware and would
    create compatibility issues with existing routers. Haoyo: no more difficult
    than existing headers.  With any enhancement we will need additional
    processing so we need to limit the headers in a single packet. Jeffery: at
    the begining of the DT there were criticisms of the head of extension
    header. Haoyo: Perhaps not sure of discussion, but the EH would be used to
    summarize the headers.  Still open for discussion. Andrew: reminder any
    decisions taken in the DT need to be ratified by the MPLS WG Greg Mirsky:
    do the proposed headers immediately follow the label stack? Haoyo: yes in
    most cases Greg: how will this be used with a GAL label? Haoyo: covered in
    the draft Tarek: a packet may arrive with an EH on a router and the router
    wants to insert EH. How is the insertion done and how are the EHs popped at
    intermediate nodes? Haoyo: you insert and modify the next header fields of
    the previous headers Stewart:  Haoyo mentioned could put a header after the
    ACH, but current ACH has not length so you could not put headers after them.

4. Meta-data Encoding Options:

    4.1 20 min - MPLS Extension Header: Enabling Extensible In-Network Services
    - Haoyu SONG Objective: Recap the solution proposal with some updates based
    on the DT meeting discussion.

    draft-song-mpls-eh-indicator
    draft-song-mpls-extension-header
    draft-andersson-mpls-eh-architecture
    Draft-andersson-mpls-eh-label-stack-operations

   See Notes for item 3.3 above.

    4.2 10 min - draft-zzhang-intarea-generic-delivery-functions GFD Encodings
    - Jeffery ZHANG

    Jeffery presented the slides.
    Andy: this is the last formal presentation. Floor is open for comments on
    any presentation. Kireeti: common formats between MPLS, BIER and IPv6 is
    intriguing because perhaps microcode can be optimized.  Does this idea
    actually play out in real life? Have you actually spoken with anyone from a
    silicon vendor to confirm? Jeffery: would be surprised if it is not done
    that way

5. 35 min - Discussion - All
    Tarek: we've seen 3 encodings of metadata after the label stack. We
    eventually want one standard encoding. Should we evaluate the pros and cons
    of each encoding and choose the best? Stewart: a proposal made to the DT
    was to understand the applications before focusing the design.  Then it
    will likely be more obvious what we shoudl pick. Greg M: Should we have a
    list of requirements, and would backward compatibility with ACH be one of
    the requirements for any encapsulation scheme. Jeffery: (audio issues) -
    the co-existence of the ACH and the EH the DT confirmed they wanted to
    support that.  It was noted that it should be possible if there are
    indications that both are present. Greg: ACH is only known if it is
    supported. There is no length. Stewart: confirmed Greg: then Stewarts
    proposal can coexist with ACH.  No need for extensive discussion, just need
    to understand what ACH is and how it is to be supported. Stewart: one of
    the things that made MPLS successful was its simplicity. This
    characteristic seems to be lost in the current proposals.  We should be
    asking for simple proposals going forward. Kireeti: Noted in the chat that
    perhaps it is time to put ACH to bed (deprecate it). It may be better to
    come up with a comprehensive way to encode data after end of stack and work
    ACH into it. Jeffery: three poitns 1. coexistence of ACH and EH if we are
    not going to allow coexistence or (bad audio) then how you discuss
    coexistence might be provided by an offset to determine where the EH
    starts. 2. complexity- if we have requriement, then we need to support it,
    but what is the definition of complexity and when would we cross it.  3....
    Jeff: In backward compatible regards the GAL GACH is relatively expensive
    and perhaps it should be deprecated. Greg: In one geographic area ACH is
    widely deployed and supported. Whether it is needed for us to support
    compatibility is another question. May not be easy to get reliable info on
    what has been deployed. Stewart: ACH has been widely deployed as an OAM
    technique for Pseudowires. Jeffery: my point 3... backward compatibility if
    you have a router that only understands ACH and there is an EH present then
    this would not create a compatibility issue, it would process the ACH and
    not the EHs. Kireeti: when we redesign the stuff below BoS rather than cope
    with current definition of ACH, we incorporate the ACH info to make it
    extensible.  This approach would be preferred to just throwing it out or
    trying to coexist as it exists today. If there is a way to coexist without
    adding complexity then OK, otherwise we should take the information and
    work it into the redesign. 6man is doing similar with router alert, where a
    proposal was to just do away with router alert. Stewart: We can't break ACH
    implementations deployed today.  If we need to put EHs and ACH in the same
    packet, it does create a compatibility problem. If the router processes the
    ACH and doesn't know about the EH it will likely pass the EH as payload
    which will cause problems up the stack.  In cases where we want to use an
    OAM mechanism like the one ACH provides AND do something new, then we
    should likely migrate the OAM to a new design and system Jeffery: clarify
    the compatibility issue is not specific to the coexistence and is present
    with the EH itself.

6. 5 min - Chairs’ summary - Stewart BRYANT
Stewart briefly summarized the take aways from the session:
a. need to include the TEAS WG in this work - (Lou via chat: need to discuss
with the co-chair) b. need to establish a relationship with the 6man WG. The
HxH options discussions they are having may have some overlap with our own
problem space. Perhaps a joint call? c. Some of the approaches can be merged,
(e.g., Kireeti and Bryant have overlap and synergy) Need to see how these can
be used together and/or merged.  There is a need for both ready-data and
pointed/referenced-data. d. protocol needs to support multiple independent
auxiliary data (Aux Data) elements and multiple actions e. there are still some
matters outstanding (e.g., ACH coexistence (or not) with other meta/aux data)
that must be resolved. The DT needs to continue working.

Andy pointed to the DT wiki link in the resources slide (and below)
Loa: all is on the wiki but may be hard to find due to structure - if you have
questions or can't find something - ask the chairs Tarek: there is a use case
page with a pointer on the wiki - please provide use cases that need to be
addressed so we come up with complete solutions and evaluation of solutions.

Andy closed the meeting at 17:57

************************

Chat Room comments: (Note: timestamps are in EDT. Subtract 3 for PDT)
Jeff Tantsura: +1 to on-demand programmable bindings (as opposed to SRv6 fixed
actions) 19:39:07 Tarek Saad: +1 19:39:21 if programmable-then the limited
number of flags becomes less of an issue 19:40:15 Kireeti Kompella: maybe it's
time to put GAL/ACH to bed? 20:21:34 Andy Malis: @meetecho we're having
intermittent breakup on the audio 20:22:33 Kireeti Kompella:it's mainly with
jeffrey 20:22:53 Andy Malis: We had it with at least one other person as well
20:23:42 Meetecho: If everyone gets the same bad audio, it's likely an issue on
the speaker side, as audio is then mixed before it's sent to everyone 20:24:05
Stewart Bryant:@Kireeti - agree - we did not design GAL/ACH for the
applications we are considering with this work 20:24:41 Mach Chen:For now,
GAL/ACH is only for OAM packets, maybe we could extend the new EH to support
the functions of GAL/ACH,20:39:42 Adrian Farrel: It is interesting to wonder
why the very flexible and extensible GAL/ACH mechanism did not take off for any
uses except for OAM 20:42:59 Could it be that there is a shortage of problems
to be solved? 20:43:18 This comes to Stewart's point that it would really help
if knew the use cases for this proposed work 20:43:40 Jeff Tantsura: +1 @adrian
Cheng Li: no screen sharing or my issue? 20:49:58 Lou Berger: none for me too
20:50:13 Joel Halpern: We are done with presentations, so no screen sharing to
be done. 20:50:21 Jeff Tantsura:at some point we stopped supporting IPX?
20:50:25 Cheng Li:ok, thanks Joel:20:50:34 Jeff Tantsura:natively over the
wire, encapsulation into a generic header (IPv4) was the way forward 20:52:36
Lou Berger:need to discuss with co-chair20:53:09 -- thank you either way
20:53:19
**********************************************************************

AGENDA INFORMATION FOR THE SESSION

**********************************************************************

Note: This meeting is focused on Meta/Ancillary data in MPLS packets - how we
know it is there and how we carry it.

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/111/materials/agenda-111-pals

●Etherpad/CODIMD

https://codimd.ietf.org/notes-ietf-111-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)