[{"author": "Jie Dong", "text": "

\u4f60\u597d\uff01

", "time": "2026-03-20T01:00:24.000Z"}, {"author": "Zafar Ali", "text": "

\u4f60\u597d\uff01

", "time": "2026-03-20T01:02:09.000Z"}, {"author": "Jie Dong", "text": "

Welcome to collaborate on notes taking: https://notes.ietf.org/notes-ietf-125-idr?both

", "time": "2026-03-20T01:03:05.000Z"}, {"author": "Jeffrey Haas", "text": "

https://www.ietf.org/proceedings/97/slides/slides-97-idr-code-point-management-00.pdf

", "time": "2026-03-20T01:03:59.000Z"}, {"author": "Jeffrey Haas", "text": "

https://datatracker.ietf.org/wg/ianabis/about/

", "time": "2026-03-20T01:05:08.000Z"}, {"author": "Ketan Talaulikar", "text": "

Yes, sure - this document can ask the existing registry name to be updated. Please check with IANA desk - I think it should be possible ?

", "time": "2026-03-20T01:11:09.000Z"}, {"author": "Jie Dong", "text": "

Thanks Ketan, will check with IANA about the name update

", "time": "2026-03-20T01:11:31.000Z"}, {"author": "Ketan Talaulikar", "text": "

Thank you.

", "time": "2026-03-20T01:11:50.000Z"}, {"author": "Joel Halpern", "text": "

If one wants to turn BGP into a topology-visibility protocol, isn't that what LSVR is for?

", "time": "2026-03-20T01:17:11.000Z"}, {"author": "Jeffrey Haas", "text": "

BGP-LS was first, Joel. :-)

", "time": "2026-03-20T01:17:28.000Z"}, {"author": "Joel Halpern", "text": "

So :-)

", "time": "2026-03-20T01:17:45.000Z"}, {"author": "Zafar Ali", "text": "

I agree with Jeff!

", "time": "2026-03-20T01:17:49.000Z"}, {"author": "Jie Dong", "text": "

The protocol in LSVR is called BGP-LS-SPF:)

", "time": "2026-03-20T01:18:03.000Z"}, {"author": "Jeffrey Haas", "text": "

lsvr is a particular use case of that state along with link discovery

", "time": "2026-03-20T01:18:08.000Z"}, {"author": "Joel Halpern", "text": "

What I am asking is, given that BGP-LS-SPR is defined, why do we need another definition for how to carry topology in BGP?

", "time": "2026-03-20T01:19:01.000Z"}, {"author": "Tony Przygienda", "text": "

so we're back to telephony routing here basically ;-) a controller to rule them all ;-) next we will be having a draft of a \"OOB\" network needed so controller can reach e'one ;-)

", "time": "2026-03-20T01:19:34.000Z"}, {"author": "Srihari Sangli", "text": "

Controller = God box!

", "time": "2026-03-20T01:20:13.000Z"}, {"author": "Jeffrey Haas", "text": "

The analogy Joel is even the IGPs added TLVs for use cases like BGP edges. In many cases, the \"features\" being added are existing TLVs from the IGPs

", "time": "2026-03-20T01:20:17.000Z"}, {"author": "Jeffrey Haas", "text": "

As Aravind touches on, even if it's an existing code point in the IGP, the code points are not identical and thus require allocation.

", "time": "2026-03-20T01:21:06.000Z"}, {"author": "Tony Przygienda", "text": "

@Srihari. yepp, deus ex machina. in greek theater a dead giveaway of a broken down plot ;-)

", "time": "2026-03-20T01:21:08.000Z"}, {"author": "Zafar Ali", "text": "

BGP-LS adv are done in IDR which has produced current RFCs in this area.

", "time": "2026-03-20T01:21:14.000Z"}, {"author": "Joel Halpern", "text": "

I have seen a lot of efforts this week to add various aspects of topology visiblity to base BGP or base BGP-LS, rather than eithernusing an actual IGP or using LSVR. Do we really need yet another approach? And will it actually address the needs of customers who didn't want to run either of those two alternatives? I am having trouble getting my head around this.

", "time": "2026-03-20T01:22:25.000Z"}, {"author": "Jeffrey Haas", "text": "

Speaking specifically about the \"why -ls rather than IGP\", the LSR chairs don't want other people's dump trucks. :-)

", "time": "2026-03-20T01:23:55.000Z"}, {"author": "Tony Li", "text": "

BGP is not a dump truck. Using it as such is poor architecture.

", "time": "2026-03-20T01:24:02.000Z"}, {"author": "krishnaswamy ananthamurthy", "text": "

This draft is not changing the routing mechanism. ROuting still remains with BGP and BGP LS is only exporting the topological information to Controller

", "time": "2026-03-20T01:24:19.000Z"}, {"author": "Tony Li", "text": "

That is a change.

", "time": "2026-03-20T01:24:34.000Z"}, {"author": "Jeffrey Haas", "text": "

indeed. constrained distribution is NOT a property of these proposals. But there's room to do better for specific use cases.

", "time": "2026-03-20T01:25:06.000Z"}, {"author": "Susan Hares", "text": "

How is the sound remotely?

", "time": "2026-03-20T01:26:32.000Z"}, {"author": "Srihari Sangli", "text": "

good, Sue

", "time": "2026-03-20T01:26:42.000Z"}, {"author": "Jeffrey Haas", "text": "

https://datatracker.ietf.org/doc/html/rfc9815#name-extensions-to-bgp-ls covers the extensions to BGP-LS. LSVR is a superset of BGP-LS.

", "time": "2026-03-20T01:28:56.000Z"}, {"author": "Susan Hares", "text": "

\u03b4\u03b5\u03c5\u03c2 \u03b5\u03bd \u03bc\u03b1\u03c7\u03b9\u03bd\u03b1...

", "time": "2026-03-20T01:29:11.000Z"}, {"author": "Tony Li", "text": "

That's all Greek to me...

", "time": "2026-03-20T01:29:38.000Z"}, {"author": "Kireeti Kompella", "text": "

Although the content is Latin

", "time": "2026-03-20T01:30:00.000Z"}, {"author": "Srihari Sangli", "text": "

google says \"two in a flght\". is that what she meant ?

", "time": "2026-03-20T01:30:40.000Z"}, {"author": "Andrew Stone", "text": "

I'm a bit unclear in the BGP EPE case why you need a reverse correlation check when it's meant for \"Egress\" steering? i.e you don't need a reverse EPE SID to steer out your egress peer SID

", "time": "2026-03-20T01:30:41.000Z"}, {"author": "Vishnu Beeram", "text": "

Given the many use cases proposed that require topology acquisition in DCs, it is time to revisit RFC 7938.

", "time": "2026-03-20T01:30:45.000Z"}, {"author": "krishnaswamy ananthamurthy", "text": "

LSVR is a superset. The proposal is to enable BGP-LS on top of existing routing such that no changes needed for routing.

", "time": "2026-03-20T01:31:26.000Z"}, {"author": "Kireeti Kompella", "text": "

I support that

", "time": "2026-03-20T01:31:42.000Z"}, {"author": "Joel Halpern", "text": "

Kireeti, I can't believe you said that with a straight face.

", "time": "2026-03-20T01:33:28.000Z"}, {"author": "Jeffrey Haas", "text": "

You may get your wish, Pavan. The SAV use case will push people to talk about scaling. :-)

", "time": "2026-03-20T01:33:30.000Z"}, {"author": "Jie Dong", "text": "

Is this part of the BGP peer discovery?

", "time": "2026-03-20T01:33:57.000Z"}, {"author": "Jie Dong", "text": "

And it seems DC would be the major use case?

", "time": "2026-03-20T01:34:37.000Z"}, {"author": "Jeffrey Haas", "text": "

The use case is dump trucks. :-)

", "time": "2026-03-20T01:34:42.000Z"}, {"author": "Tony Przygienda", "text": "

re'inventing _badly_ to be more clear

", "time": "2026-03-20T01:34:52.000Z"}, {"author": "Tony Przygienda", "text": "

Justin ran all the AMZN DCs on slightly mod'ed OSPF ;-)

", "time": "2026-03-20T01:35:21.000Z"}, {"author": "Shunwan Zhuang", "text": "

I think that bgp-only-fabric doc is useful.

", "time": "2026-03-20T01:35:41.000Z"}, {"author": "Acee Lindem", "text": "

@jie We could also learn the interface index via any of the single-hop BGP discovery mechanisms.

", "time": "2026-03-20T01:36:38.000Z"}, {"author": "Jie Dong", "text": "

@Acee correct

", "time": "2026-03-20T01:37:21.000Z"}, {"author": "Tony Przygienda", "text": "

roughly what tony li said but IME it was a big company in Seattle that ended up driving it and IME because they failed to find a really good open source IGP they could easily hack (and generally hacking IGPs is more difficult than BGP since once you do something funny to flooding it just melts, BGP just keeps on \"working\" oscillating happily ;-) And then you abuse AS numbering and then you start use LS as flooding and then you hope you still can hire enough PhDs per year and make them work day and night to kepp the edifice wobbling ;-)

", "time": "2026-03-20T01:38:19.000Z"}, {"author": "Jeffrey Haas", "text": "

https://datatracker.ietf.org/doc/draft-ietf-lsr-l2-bundle-member-remote-id/ - presentation from LSR earlier in the week covering interface components. Requires a discovery mechanism.

", "time": "2026-03-20T01:40:06.000Z"}, {"author": "Tony Przygienda", "text": "

but then again, what's new. rfc1925 (3) spelled stuff out long time ago ;-)

", "time": "2026-03-20T01:41:43.000Z"}, {"author": "Vishnu Beeram", "text": "

You can use existing service-mapping mechanisms/protocol-extensions (e.g., service \"color\") to map the service to an NRP policy at the head-end. I don't see the explicit need to carry the NRP ID as a Community.

", "time": "2026-03-20T01:47:37.000Z"}, {"author": "Zafar Ali", "text": "

Yes, agreed Pavan.

", "time": "2026-03-20T01:48:15.000Z"}, {"author": "Jeffrey Haas", "text": "

Repeating in chat for @song Liu, only pass the minimal information BFD needs. Discriminator. Maybe end point. The timers should not be sent in the state.

", "time": "2026-03-20T01:56:02.000Z"}, {"author": "Jeffrey Haas", "text": "

I agree this use case can't use RFC 9026 encoding - this is per SR path.

", "time": "2026-03-20T01:56:24.000Z"}, {"author": "Andrew Stone", "text": "

+1 to Zafar. If the attributes are often common or similar amonst many tunnels - use a policy/profile

", "time": "2026-03-20T01:56:51.000Z"}, {"author": "Zafar Ali", "text": "

Or pass some profile ID that maps to a local confif intended to be used

", "time": "2026-03-20T01:56:59.000Z"}, {"author": "Zafar Ali", "text": "

was responding to Jeff. Agreed Andrew. Thanks!

", "time": "2026-03-20T01:57:27.000Z"}, {"author": "Andrew Stone", "text": "

**amongst

", "time": "2026-03-20T01:57:50.000Z"}, {"author": "Zafar Ali", "text": "

Yes indeed that also enables sharing of profiles with Policies.

", "time": "2026-03-20T01:58:37.000Z"}, {"author": "Jeffrey Haas", "text": "

It is highly likely for SR use cases that a common endpoint profile won't be enough in all cases. Especially for S-BFD, distinct BFD session discriminators are likely needed to verify connectivity for an sr path.

", "time": "2026-03-20T01:58:40.000Z"}, {"author": "Jeffrey Haas", "text": "

if we don't like all of the endpoints, we wouldn't do sr-policy. :-)

", "time": "2026-03-20T01:59:10.000Z"}, {"author": "Andrew Stone", "text": "

if it's only the descriminator ( i assume for a specific tunnel reponse verification) then treat that as an override? I have trouble seeing every tunnel having unique timers, for example

", "time": "2026-03-20T01:59:28.000Z"}, {"author": "Jie Dong", "text": "

Yes there is one draft on extending SR Policy with profiles

", "time": "2026-03-20T01:59:43.000Z"}, {"author": "Jeffrey Haas", "text": "

my feedback was NOT to try to override local timers

", "time": "2026-03-20T01:59:49.000Z"}, {"author": "Andrew Stone", "text": "

true, so if local timers anyways then no policy -> gotcha, see where you are now with send \"minimal\"

", "time": "2026-03-20T02:00:11.000Z"}, {"author": "Jie Dong", "text": "

https://datatracker.ietf.org/doc/html/draft-zhang-idr-sr-policy-template-07

", "time": "2026-03-20T02:00:37.000Z"}, {"author": "Jeffrey Haas", "text": "

the RFC 9026 state is probably enough. if so, the PDU for SR policy could be copy and paste.

", "time": "2026-03-20T02:00:42.000Z"}, {"author": "Andrew Stone", "text": "

Thanks Jie - what's the value of signalling down the template name? if the router already has the template id with its characteristics wouldn't the name already be defined there?

\n

and if thinking about the reverse (discovery with BGPLS) would the name really be valuable if it doesn't tell you anything that's actually inside of it?

", "time": "2026-03-20T02:04:02.000Z"}, {"author": "Jie Dong", "text": "

@Andrew, the name is optional, it was added based on some comments received on a previous IETF meeting

", "time": "2026-03-20T02:07:48.000Z"}, {"author": "Jie Dong", "text": "

I guess it would mainly be used to correlate the name with the ID in some display commands

", "time": "2026-03-20T02:08:48.000Z"}, {"author": "Zafar Ali", "text": "

Is there any implementation that allow admin shut of SL in a policy?

", "time": "2026-03-20T02:09:01.000Z"}, {"author": "Andrew Stone", "text": "

thanks - yeah it's optional but can still bloat things if someone can decide to put something in it. The local node can still correlate the ID to its local config to display the name anyways in a show-cmd

", "time": "2026-03-20T02:09:26.000Z"}, {"author": "Zafar Ali", "text": "

There is already a shut at the CP level (which makes more sense)

", "time": "2026-03-20T02:09:32.000Z"}, {"author": "Susan Hares", "text": "

@Zafar - I do not know of implementations -- ask the speaker.

", "time": "2026-03-20T02:10:27.000Z"}, {"author": "Zafar Ali", "text": "

Or operator can remove a (explicit) SL

", "time": "2026-03-20T02:10:31.000Z"}, {"author": "Jie Dong", "text": "

@Andrew point taken, we will discuss and see whether the name is needed or not for some cases

", "time": "2026-03-20T02:11:18.000Z"}, {"author": "Ketan Talaulikar", "text": "

@Yao Liu, consider if setting weigth of the SL to 0 achieves the same objective?

", "time": "2026-03-20T02:13:33.000Z"}, {"author": "Zafar Ali", "text": "

+1

", "time": "2026-03-20T02:13:57.000Z"}, {"author": "Andrew Stone", "text": "

Zafar not related to this draft itself: but i'm aware of an implementation where the locally configured (not bgp or pcep originated) SR Policy can be configured with multiple SID lists, and each SID List can be shut/no shut independently.

\n

Value is the config can remain. Add/remove means config disapears so operationally might be more preferred to just shut rather than delete

", "time": "2026-03-20T02:14:09.000Z"}, {"author": "Jeffrey Haas", "text": "

remote sound is fine

", "time": "2026-03-20T02:14:41.000Z"}, {"author": "Andrew Stone", "text": "

but also agree that weight 0 is fundamentally the same except if you are doing any oam/bfd on that specific sid list

", "time": "2026-03-20T02:14:42.000Z"}, {"author": "Ketan Talaulikar", "text": "

@Andrew OAM still works with weight = 0 but might not work with shut?

", "time": "2026-03-20T02:15:18.000Z"}, {"author": "Andrew Stone", "text": "

correct

", "time": "2026-03-20T02:15:26.000Z"}, {"author": "Jeffrey Haas", "text": "

IGP folk should decide if they want this much state in the IGP for this use case. :-)

", "time": "2026-03-20T02:15:36.000Z"}, {"author": "Jeffrey Haas", "text": "

customer cones are per-interface.

", "time": "2026-03-20T02:16:01.000Z"}, {"author": "Tony Li", "text": "

The IGP is not a dump truck.

", "time": "2026-03-20T02:16:41.000Z"}, {"author": "Tony Przygienda", "text": "

not the question. As I pointed out repeatedly IGP use case simply won't work (but of course you can redefine what \"works\" means as 50% of what igp allows today)

", "time": "2026-03-20T02:16:59.000Z"}, {"author": "Andrew Stone", "text": "

Kafka shall be the dump truck

", "time": "2026-03-20T02:16:59.000Z"}, {"author": "Tony Li", "text": "

+1

", "time": "2026-03-20T02:17:16.000Z"}, {"author": "Jeffrey Haas", "text": "

kafka must be fed from something.

", "time": "2026-03-20T02:17:20.000Z"}, {"author": "Tony Przygienda", "text": "

and BGP should carry the stuff over IGP via YAAF (yet anotehr AF) if needed

", "time": "2026-03-20T02:17:34.000Z"}, {"author": "Tony Li", "text": "

What would feed things into the IGP?

", "time": "2026-03-20T02:17:49.000Z"}, {"author": "Andrew Stone", "text": "

LLM obivously

", "time": "2026-03-20T02:18:02.000Z"}, {"author": "Jeffrey Haas", "text": "

smaller dump trucks, obviously.

", "time": "2026-03-20T02:18:03.000Z"}, {"author": "Tony Przygienda", "text": "

yepp, literally what I told Jeff after the \"BMP as dumptruck\" first session. Thsoe are _message bus_ problems and not a _routing protocol_ problems architecturally

", "time": "2026-03-20T02:18:06.000Z"}, {"author": "Joel Halpern", "text": "

Apparently, BGP-LS is the delviery fleet.

", "time": "2026-03-20T02:18:07.000Z"}, {"author": "Jeffrey Haas", "text": "

FWIW, I don't find the use case for SAV into BGP-LS directly compelling - but it'd work with minor changes in route distribution. BGP-LS is in need of that anyway.

", "time": "2026-03-20T02:18:55.000Z"}, {"author": "Tony Przygienda", "text": "

using a database push approach (which BGP will force) at scale will melt miserably (but of course this will be defined as \"working\") compared to a message bus which is _not_ a database in traditional sense

", "time": "2026-03-20T02:19:00.000Z"}, {"author": "Ketan Talaulikar", "text": "

Surely you mean \"Message Broker\" :-) ... https://datatracker.ietf.org/doc/draft-ietf-nmop-message-broker-telemetry-message/

", "time": "2026-03-20T02:19:30.000Z"}, {"author": "Susan Hares", "text": "

This \"melt\" message has been conveyed to authors. Jeff you want to comment on this on the chat?

", "time": "2026-03-20T02:20:06.000Z"}, {"author": "Jeffrey Haas", "text": "

{BGP,IGP,BGP-LS,BMP} -> YANG -> dump for the dump trucks.

", "time": "2026-03-20T02:20:07.000Z"}, {"author": "Yao Liu", "text": "

@zafar\uff0cas andrew pointed out, sometimes one wants to remain the configuration without using the sid list.

", "time": "2026-03-20T02:20:25.000Z"}, {"author": "Jeffrey Haas", "text": "

The authors were responding to my on-list comments.

", "time": "2026-03-20T02:20:27.000Z"}, {"author": "Tony Przygienda", "text": "

the proper name would be \"discrete event synchronization\" ;-)

", "time": "2026-03-20T02:20:28.000Z"}, {"author": "Zhenqiang Li", "text": "

@jeff, thank you very much for your comments on SR Policy for BFD

", "time": "2026-03-20T02:20:50.000Z"}, {"author": "Tony Li", "text": "

@Jeff Redirect that stream to Kafka

", "time": "2026-03-20T02:20:59.000Z"}, {"author": "Zafar Ali", "text": "

@yao Like Ketan mentioned, the weight can be set to 0 - which is good to test OAM too

", "time": "2026-03-20T02:21:02.000Z"}, {"author": "Susan Hares", "text": "

I've even suggested compression of data - thinki of it as, \"compactors\" for material going into the BGP dump truck.

", "time": "2026-03-20T02:21:36.000Z"}, {"author": "Tony Przygienda", "text": "

@Sue: chairs are smart people and they have tools, I have none and as long it's 179 people think it's sanctified best solution for everything so my cycles are not well spent there ;-)

", "time": "2026-03-20T02:21:42.000Z"}, {"author": "Jeff Tantsura", "text": "

Friday feel :)

", "time": "2026-03-20T02:21:45.000Z"}, {"author": "Tony Przygienda", "text": "

@Jeff, try that with average 3-4 hours sleep at odd hours for 4-5 days and you'll really know what \"friday feel\" means ;-)

", "time": "2026-03-20T02:22:20.000Z"}, {"author": "Zhenqiang Li", "text": "

we will consider them further after this meeting and consult you when needed@Jeff

", "time": "2026-03-20T02:22:23.000Z"}, {"author": "Jeffrey Haas", "text": "

Happy to help, Zhenqiang Li.

", "time": "2026-03-20T02:22:43.000Z"}, {"author": "Tony Przygienda", "text": "

yepp, state compression and timing out state on e.g. slow receivers what makes event distribution different from a database. plus, filtering or rather subscription architecture

", "time": "2026-03-20T02:23:47.000Z"}, {"author": "Joel Halpern", "text": "

If I tried to deal with this time shift by only getting 3-4 hours sleep per night, at this point I would simply be asleep at my keyboard.

", "time": "2026-03-20T02:23:59.000Z"}, {"author": "Jeff Tantsura", "text": "

@TonyP - we aren't getting any younger indeed

", "time": "2026-03-20T02:24:19.000Z"}, {"author": "Tony Przygienda", "text": "

but yeah, kafka solved things well but there are further depths to it once you start to deal with multiple entities receiving and resulting clock sync

", "time": "2026-03-20T02:24:45.000Z"}, {"author": "Tony Przygienda", "text": "

but thoes are 2nd order things as we know

", "time": "2026-03-20T02:24:53.000Z"}, {"author": "Tony Przygienda", "text": "

@Joel, trick is, get up 1hour before and have a good, rich, hot bowl of soup and a coffee ;-)

", "time": "2026-03-20T02:25:22.000Z"}, {"author": "Jeffrey Haas", "text": "

remote is fine

", "time": "2026-03-20T02:25:25.000Z"}, {"author": "Joel Halpern", "text": "

@Tony, well, for me the trick is to sleep most of the day starting a few days before the meeting. Still tough, but much easier than the alternative.

", "time": "2026-03-20T02:26:11.000Z"}, {"author": "Susan Hares", "text": "

Zhengqiang - also let IDR chairs if you need help..

", "time": "2026-03-20T02:26:21.000Z"}, {"author": "Tony Przygienda", "text": "

@Joel, works well for 1-2 days for me, a whole week the buffer is not enough

", "time": "2026-03-20T02:26:32.000Z"}, {"author": "Joel Halpern", "text": "

For this QP presentation, did I read it right that this is basically just port pairs as we use for TCP and UDP for anotehr ULP?

", "time": "2026-03-20T02:26:59.000Z"}, {"author": "Susan Hares", "text": "

This is a FSv2 - presentation -- so yes..

", "time": "2026-03-20T02:28:37.000Z"}, {"author": "Jeffrey Haas", "text": "

Similar to most FSv2 discussions, the question is where do these rules fit into the fw forwarding chain.

", "time": "2026-03-20T02:29:09.000Z"}, {"author": "Susan Hares", "text": "

Yep.. more input on the flow ordering...

", "time": "2026-03-20T02:29:42.000Z"}, {"author": "Jeffrey Haas", "text": "

I am unclear whether the flow being steered is a 5-tuple or 3?

", "time": "2026-03-20T02:30:14.000Z"}, {"author": "Jeff Tantsura", "text": "

this is not needed...

", "time": "2026-03-20T02:30:33.000Z"}, {"author": "Tony Przygienda", "text": "

OpenFlow raises its head again ;-) Get the Ipsilon guys into the room

", "time": "2026-03-20T02:30:35.000Z"}, {"author": "Jeff Tantsura", "text": "

DQP is basically 6th tuple

", "time": "2026-03-20T02:31:08.000Z"}, {"author": "Susan Hares", "text": "

thanks for that..

", "time": "2026-03-20T02:31:27.000Z"}, {"author": "Jeffrey Haas", "text": "

fine - but does it need to be 5tuple steered or dos it aggregate at a higher layer?

", "time": "2026-03-20T02:31:31.000Z"}, {"author": "Tony Przygienda", "text": "

nah, it ain't because when you just use it to do \"better ECMP\" how the hell you prevent congestion?

", "time": "2026-03-20T02:31:47.000Z"}, {"author": "Tony Przygienda", "text": "

or rather, yes, it is but it does not solve congestion in any deterministic manner unless I miss something

", "time": "2026-03-20T02:32:53.000Z"}, {"author": "Tony Przygienda", "text": "

and ultimately in IP it's much simpler to go hack ports on host as people do

", "time": "2026-03-20T02:33:51.000Z"}, {"author": "Zhenqiang Li", "text": "

Susan Hares10:26

\n

Zhengqiang - also let IDR chairs if you need help..

", "time": "2026-03-20T02:34:07.000Z"}, {"author": "Tony Przygienda", "text": "

I missed they use flowspec as basically TE signalling ? head spins ;-)

", "time": "2026-03-20T02:34:49.000Z"}, {"author": "Zhenqiang Li", "text": "

Thanks sue. We will. And you have helped us a lot.

", "time": "2026-03-20T02:34:54.000Z"}, {"author": "Jeffrey Haas", "text": "

There are many suggested uses for flowspec (firewalls) to act as an ingress classifier to apply steering. This doesn't scale well and the fs rule order complicates the matching of general 5+ tuple traffic.

", "time": "2026-03-20T02:35:35.000Z"}, {"author": "Jeff Tantsura", "text": "

JeffH IP/UDP + DQP

", "time": "2026-03-20T02:35:41.000Z"}, {"author": "Jeffrey Haas", "text": "

Any sense of the desired scale for this use case, JeffT?

", "time": "2026-03-20T02:36:22.000Z"}, {"author": "Tony Przygienda", "text": "

architecturally, making all this stuff an I/O intensive architecture (which controller is with all that BGP-LS, FlowSpec, centralized pixie dust) rather than CPU intense (distributed) is massively more expensive with scale in long term. But as the VCs say, growth and exessive free cash flow masks all sins ;-) Networks over time are economies. And we are basically going from Nash equilibrium of distributed capital allocation to a 5-year plan approach assuming all the entities are synchornized to the 5 year plan immeidately and the 5 year plan adjusts every millisecond ;-)

", "time": "2026-03-20T02:40:05.000Z"}, {"author": "Jeff Tantsura", "text": "

yes, however it also depends on mapping/distribution model, if each QP is mapped to a dedicated UDP port, there's 0 variablity, e.g 5 tuple = 6 tuple, if each QP is mapped into a number of UDP ports (usualy single digit), entropy can be increased by feeding QP-id into the hash.
\nIn general, each GPU wouldn't open more than 16 QPs (rather expensive state)

", "time": "2026-03-20T02:40:41.000Z"}, {"author": "Tony Przygienda", "text": "

we know how this \"never more than 16\" assumptions go longer term ;-)

", "time": "2026-03-20T02:41:13.000Z"}, {"author": "Jeff Tantsura", "text": "

don't think so :)

", "time": "2026-03-20T02:41:47.000Z"}, {"author": "Susan Hares", "text": "

Dhruv - is there something you want to say?

", "time": "2026-03-20T02:42:16.000Z"}, {"author": "Jeffrey Haas", "text": "

For Yujia - the feedback use case is valuable. I owe you a longer write-up on this.

", "time": "2026-03-20T02:43:43.000Z"}, {"author": "Dhruv Dhody", "text": "

No sorry

", "time": "2026-03-20T02:43:45.000Z"}, {"author": "Yao Liu", "text": "

@ketan, setting the weight of the SL to zero can achieve the same purpose\uff0cbut there's difference between the status \"invalid\" and \"shut\", you may need to look twice in the \"invlaid\" state for the reason,after you see the weight 0\uff0cyou may want to further check is the weigh 0 is a misconfig or set by the intent of the operator, not that direct

", "time": "2026-03-20T02:43:51.000Z"}, {"author": "Dhruv Dhody", "text": "

issues with my system

", "time": "2026-03-20T02:43:59.000Z"}, {"author": "Susan Hares", "text": "

@Dhruv - no problem. IAB get noticed in case of \"human protocol\" issue.

", "time": "2026-03-20T02:46:00.000Z"}, {"author": "Roman", "text": "

@Jeff \"In general, each GPU wouldn't open more than 16 QPs (rather expensive state)\"

\n

Do you mean 16 QPs between a two GPUs? Or in general 16 QPs for a single GPU?

", "time": "2026-03-20T02:47:06.000Z"}, {"author": "Jeffrey Haas", "text": "

Perversely, FIB state is often already decorated by BGP information for flow telemetry protocols like IPFIX

", "time": "2026-03-20T02:50:06.000Z"}, {"author": "Jeffrey Haas", "text": "

But it's not in the forwarding state usually

", "time": "2026-03-20T02:50:22.000Z"}, {"author": "Yujia Gao", "text": "

Thanks Jeff, really appreciate it! Glad the feedback use case resonates\u2014looking forward to your write-up when you have time. @Jeff

", "time": "2026-03-20T02:59:11.000Z"}, {"author": "Jeff Tantsura", "text": "

NCCL default \"QP_per_connections\" is 1, common variations are single digit

", "time": "2026-03-20T03:01:28.000Z"}, {"author": "Jeffrey Haas", "text": "

See everyone in Vienna

", "time": "2026-03-20T03:01:58.000Z"}]