Minutes IETF113: pals
|Meeting Minutes||Pseudowire And LDP-enabled Services (pals) WG|
|Title||Minutes IETF113: pals|
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
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
MIAD Requirements Doc.
Duration: 15 min
Presenter: Stewart and Matthew
MIAD Use Cases
Duration: 10 min
[Wim]: wouldn't solving for usecase 5 allow us to cover most of
[Tarek]: the network programming is generic and allows encoding any
program/instruction. It is currently under investigation.
Duration: 10 min
Duration: 15 minutes
[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)?
Duration: 5 mins
[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
[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
Duration: 5 minutes
[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
[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
[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.
AGENDA INFORMATION FOR THE SESSION
●Jabber room: xmpp:email@example.com?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 firstname.lastname@example.org (Note: a Meetecho tech will be
monitoring Jabber during the meeting)