Skip to main content

Minutes IETF113: pals

Meeting Minutes Pseudowire And LDP-enabled Services (pals) WG
Title Minutes IETF113: pals
State Active
Other versions markdown
Last updated 2022-04-01


IETF 113 PALS/MPLS/DetNet 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

    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
[Tarek]: do we have to repeat the ISD header for each action (with
opcode, and E2E bits)?
[Jags]: yes

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

    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
    [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.


●Jabber room:
●MPLS Open Design Team Wiki (The MPLS open design team keeps a log of
its work here:
●If you have any general issues with Meetecho, the meeting audio, etc.,
send an email to (Note: a Meetecho tech will be
monitoring Jabber during the meeting)