IETF 125 LSR Minutes

Chairs:
Acee Lindem (acee.ietf@gmail.com)
Chris Hopps (chopps@chopps.org)
Yingzhen Qu (yingzhen.ietf@gmail.com)

WG Page: https://datatracker.ietf.org/group/lsr/about/
Materials:

Monday Session I 9:00 - 11:00, Monday 16, 2026

9:00 [9:00-9:12]
Meeting Administrivia and WG Update
Chairs (10 mins)

Gunter: OSPF LSInfinity draft to be added to RFC queue.
IS-IS/OSPF Flex Algo Drafts are on upcoming IESG telechat.
Tony Li: Would like to WG last call of "Algorithm for Computing
Dynamic Flooding Topologies"
Yingzhen: Experimental or Informational? Has changed to information.
Tony Li: Don't care - whatever is appropriate.
Acee: Typically we have done experimental.
Gunter: Will handle justification of document status with IESG.
Gunter: add a draft to WG's milestones when adoption.

9:10 [9:14-9:24]
Advertisement of Remote Interface Identifiers for Layer 2 Bundle
Members
https://datatracker.ietf.org/doc/draft-ietf-lsr-l2-bundle-member-remote-id/

Liyan Gong (10 mins)

Jeff Haas: BFD for LAGs could also be used to discover the remote
IDs.
Acee: No need to list every way the remote ID could be discovered in
the draft since it is out of scope.
Les: Agreed
Yingzhen: It's up to the authors to decide possible solutions for
finding the IDs.

9:20 [9:24-9:30]
LSR YANG Models Updates
Yingzhen Qu (10 mins)
9:30 [9:30-9:48]
IGP Flooding Reduction Algorithms Framework
https://datatracker.ietf.org/doc/draft-ietf-lsr-flood-reduction-arch/

Tony P (10 mins)

Acee: Interesting that more CPU is used with flood reduction despite
the reduction in I/O. With this reduction, nodes coverage noticeable
faster.
Tony P: If the topology is stable, the benefit is huge. This is the
worse case where the topology is unstable and there is about 20%
more CPU usage due to cache thrashing. For isolated changes in
stable topologies, this will be much less.

9:40 [9:48-10:10]
A Power Conserving Path Placement Strategy (PCPPS)
https://www.ietf.org/archive/id/draft-many-teas-power-steering-00.txt

Tony Li (15 mins)

Probably missing one question due to lost audio.

Jeff T: Are you going to provide BGP-LS?
Tony L: One thing at a time.
Acee: This presumes that majority of traffic is engineered, maybe
you should also say something about best effort.
Tony Li: Most of our customers traffic engineer most of their
traffic.
Acee: The "many" document belongs to TEAS, but the power group
belongs to LSR.
Les: The question is to the WG. There are many ideas about
incorporating power group in routing, I'd like to know this is the
solution that customers want.
Tony Li: This is what our customers want.
Zafar: There is some unknown here. The matrix is being discussed in
GREEN. Your presentation is about a draft in TEAS, and request
adoption LSR?
Tony Li: We're ignoring the GREEN WG as they're modeling the world,
and we're just trying to save money.
Zafar: If you have issues with the GREEN WG, you should talk to
them. Please look at the GREEN charter.
Tony Li: I helped to write the charter and create the WG, and also
contributed the first draft, but it was ignored. They don't want to
solve customer problems and we're going to let them do that.
Zafar: I'll leave this to the chairs and AD.
Jie: What if the metrics are calculated by different nodes with
different algorithms?
Tony Li: You can use whatever power metric you like.
Jie: How can you guarantee consistency?
Tony Li: (slide #5) It doesn't matter, head end allows to compute
whatever path it wants.
Chris H: When you have a centralized controller, it doesn't matter.
We should have a discussion on the list.
Tony Li: It can be optimized from different aspects.
Rakesh: slide #4, You're optimizing energy metric instead of TE
metric. There is also requirement to minimize latency, for example.
Tony Li: We're not talking about every constraint.
Zafar: Without consistency, you may not get the right traffic
engineering. Some normalization is needed.
Acee: Speaking as WG chair. Let's take this offline. The draft says
it's out of scope.
Ron Bonica: There are a couple of things we can agree on. First, is
that we have customers who want to save power. Second, we have CSPF.
There is enough motivation for adoption.
Jeff T: what's the relationship between adjacency and ASICs?
Tony Li: This is why we have power groups. Multiple adjacencies may
be dependent on a single ASIC. Power group can model a single ASIC
or severl ASICs, and we left it vague on purposely. You have
multiple ways to model it.
Jeff T: It's an abstraction. Would you support hierarchy of
abstractions?
Tony L: You're welcome to do whatever you want.
Martin: I like the abstraction of power groups. Just wondering the
hiearchical and topology may make it less optimal.
Tony Li: We don't claim it's perfect.

9:55 [10:10-10:15]
Advertising IGP Measurement Group using TLV
https://datatracker.ietf.org/doc/draft-admnr-lsr-igp-measurement-group/ ?

Derek Yeung (15 mins)

Acee: This is analogous to what we did in LSR for advertising
seamless BFD discriminators. Very small amount of information.

10:10 [10:16-10:35]
ISIS Hierarchical SNPs
https://datatracker.ietf.org/doc/draft-prz-lsr-hierarchical-snps/.
Tony P (10 mins)

Chris Hopps: Can you summarize why 48 bits yields less collisions
than 64 bits?
Tony P: I think that the partitioning of the LSP IDs maps more
naturally with 48 bits but that is just a feeling. For 64 bits, the
hash is more uniformly distributed and causes more collision.

10:20 [10:35-10:48]
IGP Extensions for Sub-interface Relationship Information
https://datatracker.ietf.org/doc/draft-zl-lsr-igp-sub-interface-relationship/

Li Zhang

Tony Li: Seems this only happens with parallel VLANs. Why would you
design a network like this?
Li: Can provide the use case in next version.
Tony Li: I understand the need for traffic separation but normally
these are different IS-IS instances.
Les: Agreed with Tony, this is a weird use case. There will be two
separate neighbors for the two VLANS, why not put the bandwidth
usage for each neighbor in the neighbor advertisement. No new
invention is needed.
Li: We can discuss in the list.
Les: slide #3, bullet point two is false. You don't need to
advertise the same bandwidth.
Acee: In the draft, you have separate TLVs, and you didn't include
them in the presentation, section 2.1.
Liyan: (slide #5) Is the purpose to know the relationship between
VLANs and physical interface? If so, you need to consider the length
of the advertisement with many VLANs.

10:30
AOB and Open Discussion

Kireeti Kompella: Have LSR MPTE draft that will be required to
signal node capabilities if the companion draft is adopted in TEAS.
Acee: That's a very drafty draft. It needs more work. You can
reference other drafts that do similar thing.
Acee: As WG chair, we need to discuss the power group draft.

Chat History

Ketan Talaulikar
00:00:50

@Yingzhen better to get the mic levels adjusted upwards
Ketan Talaulikar
00:02:12

sorry but still low for me :-(
Joel Halpern
00:04:48

Seems that everyone needs to lean close to the microphones please.
Joel Halpern
00:10:02

Personally, trying to make the milestones reflect what the datatracker
already captures seems a bad idea.
Ron Bonica
00:10:16

Could we please adjust the mic level in the room?
Joel Halpern
00:10:24

The chairs can do what they deem most useful.
Jeffrey Haas
00:13:48

other chairs should be able to abort screen share and do a new one
Yingzhen Qu
00:15:28

how about the mic level now?
Jeffrey Haas
00:16:28

liyan is fine on remote
Yingzhen Qu
00:16:49

note taking: https://notes.ietf.org/notes-ietf-125-lsr?both
Jeffrey Haas
00:22:06

Liyan, RFC 7130 permits LAGs to be created.
Jeffrey Haas
00:22:22

That mechanism does not advertise port IDs.
Stephane Litkowski
00:22:39

How the LAG is built and how the ID is learned is out of scope MO
Jeffrey Haas
00:23:13

So, the draft is fine. However, it means that in circumsances where BFD
is the mechanism, it cannot advertise the members. My question was
whether this was discussed. The answer is no.
Les Ginsberg
00:23:51

Jeff - I am frankly very confused by your posts. Perhaps you could
clarify in an email to the list?
Jeffrey Haas
00:24:43

Honestly, why bother. My question is "was it considered". The answer is
no. I have no intention to standardize it, only to point out there's a
gap.
Tony Przygienda
00:25:30

having a L3 control protocol starting to advertise L2 control constructs
(commonly called shortcutting architectural abstraction levels ;-) will
predictably lead to the usual ball-of-yarn problems.
Les Ginsberg
00:25:48

And I do not understand what the "gap" is? If it is another means of
obtaining the link IDs - OK - but that doesn't seem to be what you are
saying.
Jeffrey Haas
00:26:03

I suggest reading RFC 7130 and understanding it before making incorrect
claims, Tony P.
Christian Hopps
00:26:26

@Jeffrey Haas are you asking for it to be mentioned along side the other
methods that are mentioned, like adding 2-3 words? Seems fine to me [as
wg-member]. :)
Tony Przygienda
00:27:23

I consider BFD L2 actually ;-)
Jeffrey Haas
00:27:34

I am asking for no changes to the presented draft.
Les Ginsberg
00:27:40

Tony P - we crossed that bridge years go - see RFC8668
Tony Li
00:28:13

We made a mistake. Doesn't mean we have to keep making it.
Les Ginsberg
00:28:51

Matter of opinion - but my point is there is precedent.
Christian Hopps
00:28:52

@Tony Przygienda are you aware you are sending video?
Tony Przygienda
00:29:19

really? my thing is off
Christian Hopps
00:34:02

Renato is an LSR hero at this point, implementing all sorts of things
and providing useful feedback :)
Jeffrey Haas
00:43:56

if you're discussing fast convergence as it impacts bgp, converging
faster means bgp will do less work as it re-resolves its nexthops if it
does so consistently and in fewer spf rounds (if > 1 round()
Christian Hopps
00:44:57

@Jeffrey Haas I think we're just looking at IGP convergence here.
Jeffrey Haas
00:45:30

I understand that Chris. Faster IGP, less work for BGP. (saying a second
time a second way)(
Christian Hopps
00:45:45

Did anyone else jsut experience a glitch? I lost most speakers
David Lamparter
00:45:58

yes it's in all rooms
Andrew Stone
00:46:09

yeah feed is bouncing
David Lamparter
00:46:14

there seems to be something in the venue uplink that drops out
Les Ginsberg
00:46:15

and happened again...
Christian Hopps
00:46:43

yeah, can't hear anything right now
Zafar Ali
00:46:45

for me too. Lost it.
Tony Li
00:46:59

How many network engineers does it take to fix a network?
David Lamparter
00:47:31

@Tony Li might be ∞ on this one, might be a matter for politicians ;)
Jeffrey Haas
00:47:47

Tony Przygienda
00:48:02

stuff's flippng
Zafar Ali
00:48:02

I am good now
Tony Przygienda
00:48:04

I hear you
Andrew Stone
00:48:13

can hear Christian and the room now
Tony Przygienda
00:48:14

oh, on the flips it's switching off the mike
Tony Przygienda
00:48:17

probably a feature ;-)
Andrew Stone
00:48:46

no video feed for the room now though
Yingzhen Qu
00:49:18

@Tony P. I think the meetecho flipped you off. :)
Tony Przygienda
00:49:37

as I say, probably a feature (sigh) ;-)
Tony Przygienda
00:49:49

I probably talked too fast again and nobody tested the BPS I generated
;-)
Yingzhen Qu
00:50:05

@meetecho, camera to the presenter please
Yingzhen Qu
00:50:50

how about the voice level for remote?
Tony Przygienda
00:50:53

My mike suppressed rant to Acee was roughly "worst case scenario does
not generate lots I/O tax and in best case we save a lot"
Tony Przygienda
00:51:14

sound levels are good for me here
Jeffrey Haas
00:51:15

sounds good on remote
Yingzhen Qu
00:51:30

cool. thanks
Christian Hopps
00:51:41

@Yingzhen Qu a bit soft but still ok.
Tony Przygienda
00:53:21

stuff flips again
Christian Hopps
00:53:23

and gone
Christian Hopps
00:53:44

and back :)
Joel Halpern
00:54:03

Starting to look like a frustrating week for the NOC and meetecho teams.

Yingzhen Qu
00:54:10

I see the vedio feed flips quite often
Jeffrey Haas
00:54:34

first two monday sessions are often a bit rough at the best of times.
Christian Hopps
00:54:52

sigh
Zafar Ali
00:55:13

and gone for me :(
Andrew Stone
00:55:20

yeah full gone
Yingzhen Qu
00:55:20

hopefully things get smoother later. I hope we don't lose the chat
history
Ron Bonica
00:55:21

me too
Les Ginsberg
00:55:23

audio gone as well...
Keyur Patel
00:55:24

connection is pretty choppy
Keyur Patel
00:55:28

same for me
Tony Przygienda
00:56:11

yepp, stuff's up and down all the time
Christian Hopps
00:56:29

Here's hoping the recording is capturing everything
Vishnu Beeram
00:59:08

@Acee, yes draft-many-teas-power-steering is targeted for TEAS WG; it
will be presented in Thursday's TEAS session
Tony Przygienda
00:59:14

yepp, economic drivers for the power stuff are real (I've been sceptical
initally as well)
Tony Przygienda
01:00:41

it's not only saving = $, it's also provisioning more power is becoming
a non trivial problem for folks
Tony Przygienda
01:01:29

and every W you push in you need to cool out again as well obviously
Vishnu Beeram
01:02:17

@Zafar -- the same slide deck is being used in both LSR and TEAS
sessions; the ask in the last slide is for the appopriate home WG for
the draft (which imho would be TEAS in this case)..
Les Ginsberg
01:04:31

I would not question the real interest in saving power - my question is
whether the approach of turning components on/off is something which
customers find practical/desirable. There are other strategies
possible...
Tony Przygienda
01:04:33

The semantics of the metrics does NOT matter. Only important thing is
that e'one agrees on the distance function (folding) just like in normal
SPF. you can set SPF metric as "better delay" and another node as "km
distance" and as long both use + and shortest path things will work
Tony Przygienda
01:05:29

@Les. ok. so if you don't turn off what else you suggest. stuff like
frequency scaling is possible but incredibly capital intensive. There is
a good rfc/draft on all that BTW but I forgo which
Les Ginsberg
01:06:21

Tony P - I am asking the question - not intending to answer it at this
time. :-) I would hope our customers would be the ones to answer that.
Tony Przygienda
01:07:20

normalization of metric is sufficient but NOT necessary
Zafar Ali
01:07:57

@pavan Ack on TEAS WG session and the discussion needs to happen there.
Thanks!
Zafar Ali
01:08:51

The draft being presented is a TEAS draft.
Vishnu Beeram
01:10:22

@Zafar, yes. But it is being presented here in LSR to address questions
that were raised when draft-many-lsr-power-group was presented in LSR
last time..
Jie Dong
01:11:34

It different nodes use different algorithms for calculating the metric,
it is like for the same power consumption, some nodes set the metric to
1, while some others set the metric to 100, then the lowest metric path
does not represent a path with lowest power consumption
Zafar Ali
01:12:32

Yes, this is where calling the metric definition out of scope does not
work.
Tony Li
01:13:24

If a head end does something stupid, then it will get bad paths. Not a
problem.
Tony Li
01:14:32

There is no reasons why this draft cannot be jointly adopted by TEAS and
LSR.
Vishnu Beeram
01:16:12

With regard to the comment about not being able to guarantee consistency
in the power attribute advertised on each node across the network, the
same applies to the delay attribute. There is an assumption that the
advertisements are "appropriate" and that anomalies, if any, would be
addressed over time.
Yingzhen Qu
01:18:58

@meetecho, the auto script stopped working
Lorenzo Miniero
01:19:15

Yes, we know, sorry about that, working on a wider audio issue
Zafar Ali
01:42:18

The delay attribute and other TE metrics advertised in IGP have precise
definition and consistency (e.g., see rfc7810).