[{"author": "Reshad Rahman", "text": "

I\u2019m on my phone and I can\u2019t hear anything. I assume the problem is at my end ie others are hearing fine?

", "time": "2025-11-07T16:31:01.000Z"}, {"author": "Reshad Rahman", "text": "

All good now

", "time": "2025-11-07T16:31:16.000Z"}, {"author": "Srihari Sangli", "text": "

yes, its good

", "time": "2025-11-07T16:31:26.000Z"}, {"author": "Jie Dong", "text": "

Good morning, welcome to collaborate on note taking: https://notes.ietf.org/notes-ietf-124-idr

", "time": "2025-11-07T16:34:24.000Z"}, {"author": "Jeffrey Haas", "text": "

For the scheduling draft, I believe the primary bit of prior feedback was that the scheduler encoding wasn't aligned with other forms in ietf. @dhruv weren't those comments yours?

", "time": "2025-11-07T16:48:09.000Z"}, {"author": "Dhruv Dhody", "text": "

Yes, I was just checking what are the difference, I would have prefereed if they just refer RFC 8934

", "time": "2025-11-07T16:49:20.000Z"}, {"author": "Jeffrey Haas", "text": "

Is the issue encoding or appears to be re-defining?

", "time": "2025-11-07T16:49:47.000Z"}, {"author": "Jeffrey Haas", "text": "

Note for minutes: scheduling draft requesting adoption.

", "time": "2025-11-07T16:49:55.000Z"}, {"author": "Dhruv Dhody", "text": "

But the present are asking a bigger question to use TVR instead?

", "time": "2025-11-07T16:50:28.000Z"}, {"author": "Jeffrey Haas", "text": "

I believe the authors are looking for \"please use this\".

", "time": "2025-11-07T16:51:10.000Z"}, {"author": "Dhruv Dhody", "text": "

Another note is PCE RFC does scheduling at CP level only and this one is also proposing at per-SL

", "time": "2025-11-07T16:53:05.000Z"}, {"author": "Dhruv Dhody", "text": "

Not BGP-LS but BGP-SR Policy :smile:

", "time": "2025-11-07T16:55:07.000Z"}, {"author": "Jeffrey Haas", "text": "

Channeling the wisdom of our elders, bgp-ls has become \"the dump truck\". :-)

", "time": "2025-11-07T16:55:53.000Z"}, {"author": "Keyur Patel", "text": "

correct. but we do need multiple ways to enforce same functionality?

", "time": "2025-11-07T16:55:53.000Z"}, {"author": "Jie Dong", "text": "

Yes, this is about the scheduling of BGP SR Policy

", "time": "2025-11-07T16:57:16.000Z"}, {"author": "Jeffrey Haas", "text": "

The contentious discussion seems (from my perspective) to be about \"there is more than one way to schedule things\". The question is whether the mechanisms are discordant.

", "time": "2025-11-07T16:58:02.000Z"}, {"author": "Keyur Patel", "text": "

@jie - quick question... how do we enforce if these policies are enforced by the routers? Seems like it is a best effort in sense that the controller sends it and hopes to get accepted by the router?

", "time": "2025-11-07T17:00:23.000Z"}, {"author": "Jeffrey Haas", "text": "

crontab -e

", "time": "2025-11-07T17:00:38.000Z"}, {"author": "Jeffrey Haas", "text": "

note for minutes, request for adoption on changwang's draft.

", "time": "2025-11-07T17:01:04.000Z"}, {"author": "Boris Khasanov", "text": "

@Keyur +1

", "time": "2025-11-07T17:02:48.000Z"}, {"author": "Jeffrey Haas", "text": "

The broad concern about the constituent colors is that more granular policies may make sense, but they need to work in harmony with the prior use cases. How do they work with each other?

", "time": "2025-11-07T17:02:54.000Z"}, {"author": "Jie Dong", "text": "

@Keyur, I think it would be similar to the provisioning of SR Policy today.

", "time": "2025-11-07T17:03:07.000Z"}, {"author": "Keyur Patel", "text": "

basically what your saying is newer extensions don't have anything that says what controller sends is what router will program... (ie what if router doesn't have the extension)

", "time": "2025-11-07T17:04:12.000Z"}, {"author": "Boris Khasanov", "text": "

@Jie - yes, and the same problem, that we cannot be sure that those SR Policies were actually accepted. No feedback, only possible via LS - if vendor supports that.

", "time": "2025-11-07T17:04:15.000Z"}, {"author": "Jeffrey Haas", "text": "

I think this is a broader concern with sr policy as a mechanism rather than this extension in particular?

", "time": "2025-11-07T17:04:50.000Z"}, {"author": "Boris Khasanov", "text": "

It's just a drawback of BGP SR usage for that purpose.

", "time": "2025-11-07T17:06:07.000Z"}, {"author": "Jeffrey Haas", "text": "

Current presentation on draft-li-idr-bgpls-sr-policy-composite-path

", "time": "2025-11-07T17:06:59.000Z"}, {"author": "Dhruv Dhody", "text": "

Sue - were you asking for relationship between this color https://www.rfc-editor.org/rfc/rfc9012.html#section-3.4.2, and SR policy color, and now color in the composite SR-policy?

", "time": "2025-11-07T17:07:32.000Z"}, {"author": "Jeffrey Haas", "text": "

That is at least part of my observation, @dhruv

", "time": "2025-11-07T17:07:48.000Z"}, {"author": "Jeffrey Haas", "text": "

Our \"routes with color\" discussions of recent years have made us very cautious about chasing \"where is the color for this?\"

", "time": "2025-11-07T17:08:22.000Z"}, {"author": "Susan Hares", "text": "

@dhruv - Yes, it could interact with RFC9012 Color TLV, Color community

", "time": "2025-11-07T17:09:24.000Z"}, {"author": "Jeffrey Haas", "text": "

In particular for these SR activities, we need a well understood hierarchy where color lives.

\n

The same thing is true where various topology identifiers live. MT, NRP, etc.

", "time": "2025-11-07T17:11:26.000Z"}, {"author": "Jeffrey Haas", "text": "

Perhaps our authors could consider documenting this intended hierarchy in the wiki?

", "time": "2025-11-07T17:12:01.000Z"}, {"author": "Dhruv Dhody", "text": "

the relationship between SR policy color and composite candidate path color ought to be what is set in RFC 9256 - https://www.rfc-editor.org/rfc/rfc9256.html#section-2.13; the color in RFC9012 and its relationship to color should be as set in https://www.rfc-editor.org/rfc/rfc9830.html#section-2.3 - may be i am missing something....

", "time": "2025-11-07T17:14:57.000Z"}, {"author": "Jeffrey Haas", "text": "

Framed slightly differently Dhruv, if 9256 is clear about color... why another draft?

", "time": "2025-11-07T17:17:38.000Z"}, {"author": "Robert Raszuk", "text": "

This functionality is available since day 1 of RFC5575 - you redirect to VRF and in the VRF you can have predefined action to capture packet, header whatever you imagine

", "time": "2025-11-07T17:19:07.000Z"}, {"author": "Jeffrey Haas", "text": "

The protocol request here is to do a packet match based on payload. The request here is not to redirect the traffic to something that does that matching.

", "time": "2025-11-07T17:19:50.000Z"}, {"author": "Jeffrey Haas", "text": "

note for minutes, request from author for adoption of payload filter for fsv2

", "time": "2025-11-07T17:20:42.000Z"}, {"author": "Dhruv Dhody", "text": "

@jeff - i see this as RFC 9830 BGP extn for SR-policy does not define how to encode composite SR policy in BGP and the proposed extensions are doing just that...

", "time": "2025-11-07T17:21:19.000Z"}, {"author": "Robert Raszuk", "text": "

@jeff ... Cool packet match based on payload ... at what rate ? You want to look at each packet payload at 800 Gbps ???

", "time": "2025-11-07T17:22:10.000Z"}, {"author": "Jeffrey Haas", "text": "

@dhruv I'll review the doc chain in question. Thanks for the pointers and perspective.

", "time": "2025-11-07T17:22:15.000Z"}, {"author": "Li Zhang", "text": "

@Keyur, if the device does not support the extened sub-TLV, then the update should not be considerable, this is described in secion 4.2.2 of RFC9830

", "time": "2025-11-07T17:23:20.000Z"}, {"author": "Susan Hares", "text": "

IANA registry is a good insight for extensibility.

", "time": "2025-11-07T17:23:59.000Z"}, {"author": "Li Zhang", "text": "

sorry, just update a mistake. If the device does not support the extened sub-TLV, then the update should not be considered useabel, this is described in secion 4.2.2 of RFC9830

", "time": "2025-11-07T17:25:10.000Z"}, {"author": "Susan Hares", "text": "

@robert - good point that scaling should be included.

", "time": "2025-11-07T17:25:21.000Z"}, {"author": "Nat Kao", "text": "

I believe this filter is attempting to distribute something like the u32 iptables filter via BGP.

", "time": "2025-11-07T17:25:39.000Z"}, {"author": "Jeffrey Haas", "text": "

There are multiple vendor features that cover such filters already. However no standardized flowspec mechanism for them.

", "time": "2025-11-07T17:26:38.000Z"}, {"author": "Nat Kao", "text": "

@Jeffrey +1

", "time": "2025-11-07T17:27:09.000Z"}, {"author": "Robert Raszuk", "text": "

@Jeff - Thank You for voicing my comment. The main issue is that once even one such rule is installed to match on payload the game is over for those forwarding engines it is enabled on

", "time": "2025-11-07T17:27:20.000Z"}, {"author": "Jeffrey Haas", "text": "

There is a conversation on \"where can you apply fs(v2) filters\" that has happened over fsv2 discussions, especially covering inconsistently deployed new features. This scaling discussion is a good input toward the deployment considerations.

", "time": "2025-11-07T17:28:23.000Z"}, {"author": "Jeffrey Haas", "text": "

This draft covering \"is this installed\" is one such example of the deployment discussion.

", "time": "2025-11-07T17:29:28.000Z"}, {"author": "Jeffrey Haas", "text": "

(note for minutes, current draft is fsv2 feedback from Yujia)

", "time": "2025-11-07T17:29:43.000Z"}, {"author": "John Scudder", "text": "

I don't love using BMP as a feedback channel, it seems like mission creep.

", "time": "2025-11-07T17:36:27.000Z"}, {"author": "Jeffrey Haas", "text": "

we need some back channel. BMP isn't lovely, but it's not the worst example.

", "time": "2025-11-07T17:36:47.000Z"}, {"author": "Jeffrey Haas", "text": "

it has some niceness that streaming yang telemetry doesn't have.

", "time": "2025-11-07T17:37:02.000Z"}, {"author": "Reshad Rahman", "text": "

On the fence on using BMP for this, it's a great tool but I see John's point.

", "time": "2025-11-07T17:37:42.000Z"}, {"author": "Jeffrey Haas", "text": "

There is room to have BMP as the channel, even if it's not in the same stream as other bmp applications. That's been part of the motivation for the filtered feeds discussion in grow

", "time": "2025-11-07T17:37:50.000Z"}, {"author": "Jeffrey Haas", "text": "

That said, BMP has become our BGP \"does this go into BGP or DNS\" joke.

", "time": "2025-11-07T17:38:16.000Z"}, {"author": "Maria Mat\u011bjka", "text": "

i'm very much scared about the feedback across AS boundaries, i'm almost leaning to mandating to not propagate across AS boundaries unless explicitly allowed by operators

", "time": "2025-11-07T17:38:38.000Z"}, {"author": "Jeffrey Haas", "text": "

That is already the current operational practice, Maria.

", "time": "2025-11-07T17:38:54.000Z"}, {"author": "Reshad Rahman", "text": "

Or \"the answer is BMP! What was your question?\"

", "time": "2025-11-07T17:38:59.000Z"}, {"author": "John Scudder", "text": "

At the very least if we're looking at using BMP for more than its current purpose, we need to liaise that with GROW sooner rather than later. But I still think it's a mistake. It would potentially have knock-on effects for the ability of the BMP spec to be iterated quickly. Which IMO is one of the strengths of BMP.

", "time": "2025-11-07T17:39:01.000Z"}, {"author": "Jeffrey Haas", "text": "

inter-as flowspec is deployed, but under controlled circumstances. It's also where some of more terrifying outages originate.

", "time": "2025-11-07T17:39:25.000Z"}, {"author": "Yujia Gao", "text": "

BMP is just a example; we'll have more options to do that. We welcome all comments and need more feedback :)

", "time": "2025-11-07T17:39:27.000Z"}, {"author": "Maria Mat\u011bjka", "text": "

well the section 6 says quite explicitly that the feedback action must be propagated unchanged across AS boundaries \u2026

", "time": "2025-11-07T17:39:58.000Z"}, {"author": "Boris Khasanov", "text": "

@Yujia - would be good to know other options too

", "time": "2025-11-07T17:40:42.000Z"}, {"author": "Jeffrey Haas", "text": "

@john I don't speak for the authors on that fsv2 draft, but prior discussion is that such \"telemetry\" becomes either a statistic type (already defined) or route monitoring message.

", "time": "2025-11-07T17:40:43.000Z"}, {"author": "Jeffrey Haas", "text": "

but i think we're at the point where concrete proposals are needed for specific hate mail rather than general idea hate.

", "time": "2025-11-07T17:41:04.000Z"}, {"author": "Jeffrey Haas", "text": "

note this also overlaps the \"router capabilities\" discussion kicked off by Tony Li a while back.

", "time": "2025-11-07T17:41:28.000Z"}, {"author": "John Scudder", "text": "

Sure, if it can be cleanly fit into the existing model I'm less worried. And point taken.

", "time": "2025-11-07T17:41:43.000Z"}, {"author": "Jeffrey Haas", "text": "

@boris YANG streaming telemetry is a similar idea. That one is mostly just a matter of defining the schema.

", "time": "2025-11-07T17:41:53.000Z"}, {"author": "Robert Raszuk", "text": "

For feedback I recommend to think about Operational Message proposal ... https://www.ietf.org/archive/id/draft-ietf-idr-operational-message-00.txt

", "time": "2025-11-07T17:42:04.000Z"}, {"author": "Jeffrey Haas", "text": "

The challenge for op message, @robert, is that this status is likely needed by a controller that is not directly connected.

", "time": "2025-11-07T17:42:46.000Z"}, {"author": "Robert Raszuk", "text": "

Well if we are considering BMP I presume there could be a session to such controller too

", "time": "2025-11-07T17:43:41.000Z"}, {"author": "Jeffrey Haas", "text": "

That's more the typical deployment model already for bmp or streaming telemetry, hence the likely fit for purpose discussion.

", "time": "2025-11-07T17:44:11.000Z"}, {"author": "Boris Khasanov", "text": "

@Jeffrey Agree, Yang-telemetry with proper scheme could work. @Robert - thanks for pointing this Op Message info.

", "time": "2025-11-07T17:44:46.000Z"}, {"author": "Maria Mat\u011bjka", "text": "

what if we allowed propagating the op messages transitively

", "time": "2025-11-07T17:44:48.000Z"}, {"author": "Maria Mat\u011bjka", "text": "

of course we have to create a subtree with something like rtfilters or so

", "time": "2025-11-07T17:45:07.000Z"}, {"author": "Jeffrey Haas", "text": "

@maria consider current vpn-orf discussion. I think you'll find the propagation discussion is somewhat similar.

", "time": "2025-11-07T17:46:12.000Z"}, {"author": "Maria Mat\u011bjka", "text": "

gonna check, thanks!

", "time": "2025-11-07T17:46:43.000Z"}]