IETF 124 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: https://datatracker.ietf.org/meeting/124/session/lsr

Monday Session I 9:30 - 11:30, November 3, 2025

9:30 [9:30-9:41]
Meeting Administrivia and WG Update
Chairs (10 mins)

9:40 [9:43-10:00]
Using IS-IS To Advertise Power Group Membership
https://datatracker.ietf.org/doc/draft-many-lsr-power-group/
Colby Barth (15 mins)

Les: Asking IGPs to advertise the adjancencies since we can't
maintain liveness, how do we maintain correctness while the power is
off? What happens if the connection changes while the resource is
sleeping?
Colby: The assumption is that the system will make its own decision
to power it off. The decision to power sleep is made in advance of
power sleep, and the advertising can be made before sleep.
Les: Once it's off, are you sure the connection is still there?
Colby: I understand your question, how do we make sure the link
isn't going down after we put it to power sleep?
Les: Or the link is changed to connect to something else.
Colby: Haven't thought much about connection changes. We have some
idea, let's discuss more offline on how to maintain or check the
liveness.
Acee: Regarding Les' point, we have precedents, e.g., the OSPF
demand circuits (e.g., DoNotAge LSAs), but you can't be sure.
Acee: Is anyone doing work in the GREEN WG, like a problem
statement?
Colby: Yes, there are some documents describing use cases about
saving energy etc., but not aware of something like this.
Keyur: Is there consideration for removing resources gracefully?
Colby: That's system specific. Yes, you can do make-before-break to
avoid problems, moving traffic somewhere else.
Tony Li:
To Les, once marked as sleeping no guarantees for the link to come
back up. It may come up in a different place. The point is to have
sleeping adjacency so that TE can compute things that might come
back up. One thing that can be done is to signal to bring it back
when the traffic is up.
To Acee: Yes, GREEN WG has many documents. None of them seem to be
useful.
To Keyur: Yes, you can take the link off gracefully. One easy thing
to do is to use max-metric and take the traffic away.
Yingzhen: How do you make sure power group definition is consistent
across vendors or across different equipment?
Colby: Good question, part of the point of the abstraction is trying
to get something like this defined so we can describe past, present,
and future power consumption; how do we compute a metric based on
this power group. Second, we assume a policy that can be defined by
the operator. For example, use the most efficient power groups. The
operators need to guarantee the same policy. Even the authors had
different opinions about this, but one example is to use the most
efficient power group first. Also normalize the metrics, and have a
consistent mechanism across the network. Also not in document, but
the CSPF changes.
Yingzhen: Please add some examples.
Tony Li: If vendors provide different definitions then TE won't
work. If a vendor is lying, you will compute it wrong.
Colby: So don't lie.
Yingzhen: The same power group from different vendors can mean
different things.
Tony Li: Power group definition is an abstraction. It's not supposed
to be normalized across the network. We're asking for accurate power
usage in watts. There are different kind of wattage, and we really
want to have the best effort wattage. That's the best we can do.

Adoption MeetEcho Show-of-Hands Poll:

Les: There isn't "not yet" in the adoption poll.
Yingzhen: If you think the document is not yet ready for adoption,
please vote for No.
Tony Li: For people who voted No, please say why.
Zafar: There is a dependency on the proper definition of power group
and across vendors. This should be sorted out.
Acee: We will do more discussion. As WG member, I can look at it and
see how TE can use this info. That's why I was asking whether there
is a problem statement.
Zafar: There is more work to be done beyond IGP.
Chris: It doesn't need to be standardized.
Zafar: The work in GREEN WG is relevant.
Chris: I thought Tony said there are lots of documents in GREEN.
Sometimes we can't wait.
Yingzhen: About half of the people voted, and the result is about
50/50.
Acee: Let's have more discussion on the list.
Ketan: Is there a liaison from LSR to GREEN? Maybe the chairs can
send an email.
Tony Li: We believe nothing we've done requires liaison with GREEN
wg.

Poll Result

Q: Do you think the draft is ready for adoption?
(Present when poll closed: 46)

| | Number | Percentage |
|----------
| Yes | 12 | 43% |
| No | 12 | 43% |
| No Opinion | 4 | 14% |

9:55 [10:07]
Metric Normalize for IGP Flex-algo
https://datatracker.ietf.org/doc/draft-gl-lsr-metric-normalize/
Liyan Gong (15 mins)

Acee: Speaking as WG member, clever way to normalize metric. 1)
Should use "normalize" term throughout in draft and not
"standardize". 2) TE is a big domain. Normally TE is calculated in
one place, head end or controller, and you don't need to normalize
it. 3) People have already done unequal paths with weights, so would
we really want to do this? By advertising it, everyone is
calculating it, so you could argue less chance of looping but there
are checks to prevent that unequal path multipath.
Liyan: 1) Yes, we mean to "normalize", not to "standardize" SPF
metric. We will update to use "normalize". 2) The TE metric is
calculated by controller, for most cases, it's not used. But there
are other scenarios, the head-end router can use the normalized
metric to calculate paths. There might be other types of paths we
can use these metrics, and it's good for future extension.
Peter: 1) Normalizing metrics is a good thing, but nothing needs to
be advertised, it can just be done on the local router. You can do a
local measurement and normalize it based on your use case and
requirement, and just advertise the normalized value. 2) If you take
an example from someone's documentation then please add citation to
the draft.
Liyan: 2) Yes, ok, in next version, we will add a reference. For 1),
I just mentioned it can also achieve what static configuration can
do. It simplifies configuration.
Peter: If you want to synchronize management data there are tools
for that, flex-algo is not the correct mechanism for that.
Liyan: We want to comply with the current principle, like FAD. The
other advantage is that it's a simple way to keep all routers
consistent. I agree it's not a MUST, but a better way to do it.

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

Acee: Will this be used mainly for flooding reduction?
Tony: No, it's not related. It's orthogonal and different
optimization.
Chris Hopps: Are those A, B, C, D on the slides represent entries in
the CSNP? Individual LSP segments.
Tony: Yes.
Chris: you're trying to reduce the periodic update, why don't we
send the ranges the first time to the neighbors? Then you know what
the ranges will be. Later, your neighbors will know.
Tony: That's valid thinking, except you have to multiply that by
2000 neighbors and their 2000 neighbors.
Chris: you're saying if you standardize the splitting algorithm,
it's the same for all neighbors.
Les: I agree the math work you've done, but they're irrelevant. We
both know the protocol can generate an LSP that is undetectably
different from another version of that LSP. The HSNP doesn't impact
that or change the occurrence of that behavior. That's the nature
how LSPs are generated and flooded. What's more important is whether
this proposal is going to be of practical value. It seems where it
has the most value is periodic CSNPs with a large LSP database, but
the base protocol doesn't use periodic CSNPs on P2P links, it was
added later.
Tony: Practically everyone does it on P2P links.
Les: I don't think that's true. There are implementations with
default enablement, and some not. I don't see issues resolved by the
use of periodic CSNPs over years. OSPF doesn't have periodic CSNPs
and nobody is claiming that OSPF is broken. You need to focus on the
case where periodic CSNPs are really needed and you have to look at
the case where HSNP is different only because the database is not
synced. In that case, you will get a mismatch, this isn't going to
add value.
Tony: You're saying if you don't need CSNPs, you don't need this.
Les: If you're going to use this, you need to make sure you don't
get false positive. If there is a mismatch, it doesn't mean there is
a flooding issue, you just need to wait a bit longer for the
database to sync. So to me the big question is focus on the case
where it has practical value and not theoretical.
Tony: I have a hard time following the reasoning.
Tony Li: The practical situation is for where we like CSNPs, the
HSNP size is logarithmic to the size of LSDB, not linear. This is a
key scalability point.
Les: The motivation of periodic CSNPs is based on the possibility
that flooding is compromised in some way, and that's not the case in
most cases. In the dynamic flooding document, the transient cases is
discussed when you're changing the flooding topology. Please review
RFC 9677 for what we defined already.
Tony Li: There are case where periodic CSNPs can save us, and this
is a cheap way to actually use them.
Chris: I wasn't aware of the discussion on the dynamic flooding
draft. From my personal experience, I always counted on periodic
CSNPs. I think we designed things the way we did because it's safe
to do so due to periodic CSNPs.
Tony Li: All flooding reduction algorithms we did have sketchy cases
and we always said we're depending on CSNPs.
Chris: I did see circular stuff on the list. Les wasn't claiming
anything 100% reliable. Another point, 1 in 65000 is really low. The
same node coming up with same sequence number is really low.
Tony P: Fletcher even with very little deviation in entropy
generates wildly different values and I measured that. Those were in
my emails.
Chris: I'm just talking about CSNP collisions.
Tony Li: Tony P's numbers are very conservative. The structure and
syntax of LSPs alone will guarantee there's lot of redundancy.
Chris: My point is CSNPs are structured, with HSNP, you're getting
closer to randomized data set. They're apples and oranges.
Tony P: We've been talking about fears and feelings the whole day.
Chris: I don't like the comparison, it makes me uncomfortable. I
want to look at HSNP alone, not to bring in CSNP collisions.
Tony P: fair enough. I wanted to normalize something so people have
a reference.
Peter; I agree your math is solid. We need to look at the
consequences. For CSNP, if there is a collision, it impacts one
fragment. In case of HSNP, it may affect many.
Tony P: The chance is very small.
Chris: What happens at the top level, if you have one hash and you
have a collision?
Tony P: That's the probability, like half a million. The 32 bits
have to correlate with half a million, the probability is really
low. The most likely is that two hashes clash. Without math, we can
fear monsters in the dark.
Peter: You're calculating a checksum on top of checksums, if you get
into collision, you don't know where the collision is.
Tony P: I get your fear, but we need to quantify it.
Peter: We can work on probability, my point is that if it happens,
what's the impact?
Tony P: If your database is half a million, it takes half an hour to
send all the CSNPs. It's difficult to use.
Chris: Please continue on the mailing list.

10:30 (skipped)
LSR YANG Models Updates
Yingzhen Qu (15 mins)

Yingzhen: The slides were uploaded to the meeting materials, please
look at them. If there are questions, please send an email to the
mailing list.

10:45
AOB

Chat History

David Lamparter
00:13:18

the mic/speakers are rather quiet in-room
Yingzhen Qu
00:13:55

how about now?
David Lamparter
00:14:31

better, thanks! 👍
Siddhant Mehta
00:21:35

Is everyone able to hear the ppt?
Srihari Sangli
00:22:15

connection flapped couple time for me. not sure if its my connection
issue
Siddhant Mehta
00:23:12

I am keep on getting the message "Audio capture device disconnected"
Tony Przygienda
00:24:07

in short "Internet works as advertised"
Srihari Sangli
00:24:44

\:)
Boris Khasanov
00:26:07

@Tony "as good as it gets"..
Siddhant Mehta
00:27:44

Thus it remains best effort always :)
Tony Przygienda
00:35:04

well, like, not like, adopt, not adopt. what matters the problem is real
talking to customers now so the group better moves before we get some
atrocious extended community draft in BGP trying to hack it together
somehow ;-)
Vishnu Beeram
00:35:07

https://datatracker.ietf.org/doc/html/draft-barth-teas-yang-pg-aware-topo-01
-- Equivalent data model draft
John Scudder
00:35:43

Something something perfect is the enemy of good.
John Scudder
00:37:17

Two other observations: instead of deferring to GREEN without even
asking, wouldn't it be better to check in with the GREEN chairs and/or
full WG?
John Scudder
00:37:33

Oh, that's kind of what Ketan said.
Tony Przygienda
00:37:42

the green folks (chair excepted) are probably too green to muck around
in IGP ;-)
John Scudder
00:39:39

Second point, it seems like we are experiencing the common problem where
the bar is being set too high for adoption. A draft shouldn't be perfect
to be adopted. It should be (a) in-charter, (b) something there is
energy to work on, and (c) a reasonable starting point. ISTM this draft
meets all those bars.
John Scudder
00:40:03

There is ample opportunity to unsnarl turf wars before WGLC.
Les Ginsberg
00:41:42

From my POV, the "big question" has nothing to do w dependency on
another WG. It is whether this is an appropriate use of the IGP. Still
considering that...
Tony Przygienda
00:42:39

it's basically another TE metric, we seem to have been doing a little
bit of that in IGP already
Christian Hopps
00:43:03

Yeah.. The main reason not to adopt I think are (logic or), 1) no one
cares about problem, 2) LSR should not try to solve problem 3) this
particular draft is not a good vehicle for working on a solution to
problem, otherwise
Christian Hopps
00:43:51

and thus should adopt if !1 && !2 && !3 :)
Tony Przygienda
00:44:28

eeeh, rather !(l1||l2||l3) ;-)
Christian Hopps
00:44:45

tomahto tomayto
Les Ginsberg
00:44:54

Not really. It seems to me we are proposing to advertise more
information that is not of use to the IGP itself - and is certainly not
of any use to most nodes in the network. That deserves more thought. I
appreciate the TE analogy - but not sure that is a sufficient
justification.
Tony Przygienda
00:44:55

nah, I read the ! as small l, sorry
Martin Horneffer
00:46:25

adding information to thew IGP that does not really have to be there
worries me. link state db size is a concern in some network.
Tony Przygienda
00:46:29

we should never gone and do any kind of SRLG either, what an abuse of
IGP that was ;-)
John Scudder
00:57:35

I would be more sympathetic to the "don't put it in the IGP" arguments
if the proponents of such arguments put some solid effort behind a Dump
Truck Protocol. As it is, I'm more convinced by the argument that it's
basically TE information, we already carry around TE information, the
IGP is the second-best place to put it, and the best place hasn't been
implemented or standardized yet.
John Scudder
00:59:50

Regarding the LSDB size in some networks, presumably the operators of
such networks aren't forced to turn this feature on. Admittedly, it
would be better if they could turn it on, but I don't see this as an
existential threat to such networks.
Tony Przygienda
01:00:46

with good implementations and some smarts we can stretch the overall
size of LSDB still by a very sizeable margin. Our enemy is the 255
fragments per node really
Tony Przygienda
01:02:56

and yes, there are hacks like RFC3786 but ideally we'll get the wide
ISIS implementations rolling (forgot RFC)
Les Ginsberg
01:03:36

RFC7356
Tony Przygienda
01:06:00

yeah, sigh. lifting a routing protocol must be the most immovable object
in the universe ;-)
David Lamparter
01:08:48

If not clear for remote people, the fire alarm is too loud/disruptive to
continue anything. (Probably a good thing if there's an actual fire)
Martin Horneffer
01:09:03

a standardized, abstract representation of power related components
makes a lot of sense to me. I'd just think the right way would be to
standardize a model and use netconf. bad, of course, if green wg cannot
agree on the right thing :-(
David Lamparter
01:10:09

Fire alarm gone, but half the room wandered off 😅
John Scudder
01:10:23

@meetecho any way to get the remote speaker volume a little higher in
the room?
Lorenzo Miniero
01:10:58

@John Scudder I'll ping the AV team
David Lamparter
01:13:36

Our presentations are on fire
Boris Khasanov
01:17:27

Now Tony's voice level became lower for the remote
John Scudder
01:19:21

s/cashes/hashes/ ?
Henk Smit
01:45:29

Fully agree with Les.
David Lamparter
01:46:00

(Idon't care enough to bring to mic, it really doesn't make a
distinction for the operation, but —) I'd consider this a "new" protocol
feature and don't see why we'd keep using Fletcher checksums. Intel &
ARM CPUs got SHA2 instructions 10+ years ago. If you make something new,
just go SHA2?
Henk Smit
01:48:11

In my implementation there are zero periodic CNSPs. That scales even
better.
What TonyP does is optimize for bandwidth. While the expensive resource
is CPU power.
Tony Przygienda
01:50:28

then you don't need HSNP either. good luck to yoiur large customers ;-)

Tony Przygienda
01:51:09

@David, yeah, we could and we may go there. I didn't measure SHA but
generally it's 10x slower than fletcher
John Scudder
01:51:17

The present debate about whether or not to periodic CSNP sounds a bit
like an argument about who is assuming air resistance doesn't exist.
Henk Smit
01:51:43

Oh, Tony. You think we don't have, and never had any customers with
large networks? OK.
John Scudder
01:52:31

If one accepts the premise that some people do periodic CSNPs then I
don't hear anybody saying this isn't valuable.
John Scudder
01:53:20

As Tony says, don't use periodic CSNPs? Great. Then you can ignore this
whole discussion.
Les Ginsberg
01:58:11

The question I am raising is how likely it is, in a very large LSPDB,
that an HSNP mismatch will occur simply due to transient - not
pathological - out of sync on the neighbors. If that is large, then we
end up reverting to CSNPs frequently and the value of HSNP is greatly
diminished.
Les Ginsberg
01:58:27

The discussion of collisions is irrelevant.
Tony Przygienda
01:59:25

@Les, and yes, this is then assumptions/deployment scenarios
Tony Przygienda
01:59:36

for us huge networks most of time it's an adjacency bleep
Tony Przygienda
01:59:43

and then HSNP is about the best thing
Henk Smit
02:00:51

Then you can ignore this whole discussion. My favorite rule:
https://datatracker.ietf.org/doc/html/rfc1925#section-2
Rule 12
Les Ginsberg
02:01:14

You are suggesting that flooding - in the absence of CSNPs - is
unreliable. That s not the case.

Automatic LSR Minutes

https://ietfminutes.org/minutes/ietf124/lsr.html