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

welcome to collaborate on the note taking

", "time": "2025-03-17T06:06:13Z"}, {"author": "Tony Przygienda", "text": "

from the preso I see a subtle hole (I didn't read draft in detail yet): \"if a node is configured to advertise transitive and receives non-transitive, does it still push it on? In the same vain, if it receives transitive but it's configured to advertise non-transitive, does it flip the flag?\"

", "time": "2025-03-17T06:28:48Z"}, {"author": "Kaliraj Vairavakkalai", "text": "

a node supports receiving both transitive/non-transitive. it is independent of send-side policy config.

", "time": "2025-03-17T06:31:09Z"}, {"author": "Tony Przygienda", "text": "

ok, as I said, didn't read draft in detail (yet)

", "time": "2025-03-17T06:31:44Z"}, {"author": "Tony Przygienda", "text": "

and no mike, listening in my office on my hi-fi speakers to give the IDR wisdom it's due ;-)

", "time": "2025-03-17T06:32:06Z"}, {"author": "Jeff Tantsura", "text": "

:)

", "time": "2025-03-17T06:32:37Z"}, {"author": "Tony Przygienda", "text": "

AFAIS choosing the lowest/transitive is the best, conservative choice since one must be made in case of multiplicity.

", "time": "2025-03-17T06:35:45Z"}, {"author": "Jeffrey Haas", "text": "

The choice of which is best, transitive or non-transitive is part of the discussion.

", "time": "2025-03-17T06:37:01Z"}, {"author": "Tony Przygienda", "text": "

transitive because it carries more information so to speak so there's a better chance to make a better decision (do not ask what \"better\" is here ;-)

", "time": "2025-03-17T06:37:51Z"}, {"author": "Jeffrey Haas", "text": "

the choice for non-transitive was partially motivated by \"this is the more restricted scope that this was added\"

", "time": "2025-03-17T06:38:17Z"}, {"author": "Jeffrey Haas", "text": "

so yes... better is debateable.

", "time": "2025-03-17T06:38:26Z"}, {"author": "Jeff Tantsura", "text": "

+1,TonyP, deafult as well

", "time": "2025-03-17T06:38:54Z"}, {"author": "Tony Przygienda", "text": "

transitive gives you a chance to react a bottleneck \"upstream\"

", "time": "2025-03-17T06:39:03Z"}, {"author": "Stephane Litkowski", "text": "

As Maria is currently pointing, leaking the LBW community where it should not go, may have side effect.

", "time": "2025-03-17T06:39:11Z"}, {"author": "Maria Mat\u011bjka", "text": "

exactly, thanks for reformulating, the community scrubbing and leaking, as this is a magic community, is at least worth mentioning

", "time": "2025-03-17T06:41:02Z"}, {"author": "Jeffrey Haas", "text": "

I'll repeat at the mic at the end, but not only is repeating to list good but there's a github we can open issues and propose text

", "time": "2025-03-17T06:41:34Z"}, {"author": "Mingqing(Michael) Huang", "text": "

sorry I have not read the draft yet. the LBW here is about current available bw or not

", "time": "2025-03-17T06:43:06Z"}, {"author": "Jeffrey Haas", "text": "

It's typically how much bw is provisioned on the link or similar, not the remainder.

", "time": "2025-03-17T06:44:20Z"}, {"author": "Mingqing(Michael) Huang", "text": "

I feel like if it is about the link static bw, it might have some side effect

", "time": "2025-03-17T06:44:33Z"}, {"author": "Susan Hares", "text": "

I have posted a shepherd's review for -08 to IDR mail list today and posted on the web (https://wiki.ietf.org/group/idr/Shepherd-SR-BGP-LS/BGP-SR/draft-zhang-idr-sr-policy-scheduling)

", "time": "2025-03-17T06:51:44Z"}, {"author": "Jeffrey Haas", "text": "

Sue, is the draft in the adoption queue already or do the authors need to send the formal request to the list?

", "time": "2025-03-17T06:56:24Z"}, {"author": "Susan Hares", "text": "

Authors need to send formal request to list.

", "time": "2025-03-17T06:56:55Z"}, {"author": "Dhruv Dhody", "text": "

A reference for the scheduling authors - https://datatracker.ietf.org/doc/rfc8934/ from PCE WG

", "time": "2025-03-17T06:57:20Z"}, {"author": "Ketan Talaulikar", "text": "

Does TVR recommend protocol extensions for such requirements?

", "time": "2025-03-17T07:02:03Z"}, {"author": "Jie Dong", "text": "

@dhruv thanks for mentioning the pce rfc\uff0cfor sure some alignment between bgp and pce on this is needed

", "time": "2025-03-17T07:07:42Z"}, {"author": "Jeffrey Haas", "text": "

FWIW, if the scheduler pattern is something that should be common, consider also standardizing it in a YANG grouping.

", "time": "2025-03-17T07:08:37Z"}, {"author": "Jeffrey Haas", "text": "

perhaps pce has already done so?

", "time": "2025-03-17T07:09:14Z"}, {"author": "Susan Hares", "text": "

Link for shepherd draft-zzz-idr-policy-scheduling-08

", "time": "2025-03-17T07:11:41Z"}, {"author": "Susan Hares", "text": "

https://wiki.ietf.org/en/group/idr/Shepherd-SR-BGP-LS/BGP-SR/draft-zzd-idr-sr-policy-scheduling

", "time": "2025-03-17T07:11:53Z"}, {"author": "Tony Li", "text": "

Ketan Talaulikar said:

\n
\n

Does TVR recommend protocol extensions for such requirements?

\n
\n

[TVR chair hat on]: TVR only specifies a YANG model for describing scheduled changes.

", "time": "2025-03-17T07:11:54Z"}, {"author": "Jeffrey Haas", "text": "

Note that our excellent discussion has pushed us to be a little tighter with the remaining presentations.

", "time": "2025-03-17T07:22:42Z"}, {"author": "Dhruv Dhody", "text": "

@Jeffery - see RFC 8934 which predates TVR

", "time": "2025-03-17T07:25:50Z"}, {"author": "Dhruv Dhody", "text": "

I have a presentation to give in OPSAWG/OPSArea and thus had to leave IDR early :smile:

", "time": "2025-03-17T07:27:12Z"}, {"author": "Jeffrey Haas", "text": "

https://www.rfc-editor.org/rfc/rfc8934.html#name-sched-lsp-attribute-tlv

", "time": "2025-03-17T07:30:14Z"}, {"author": "Li Zhang", "text": "

Actually, there are some little different in the formate of fields between the RFC8934 and TVR YANG model. But they are similar.

", "time": "2025-03-17T07:32:22Z"}, {"author": "Keyur Patel", "text": "

@gyan - We will most probably move your preso to the second IDR session

", "time": "2025-03-17T07:42:55Z"}, {"author": "Keyur Patel", "text": "

@changwang - We will move your press to the second IDR session!

", "time": "2025-03-17T07:47:25Z"}, {"author": "Gyan Mishra", "text": "

@Keyur Thank you will plan to present at 2nd IDR session.

", "time": "2025-03-17T07:48:39Z"}, {"author": "Acee Lindem", "text": "

@li Zhang - note that the TVR model imports and uses types and groupings from https://datatracker.ietf.org/doc/draft-ietf-netmod-schedule-yang/ which is in NETMOD last call.

", "time": "2025-03-17T07:48:42Z"}, {"author": "Changwang Lin", "text": "

OK, noted@Keyur Patel

", "time": "2025-03-17T07:48:59Z"}, {"author": "Jeffrey Haas", "text": "

Thanks for highlighting that Acee

", "time": "2025-03-17T07:49:05Z"}, {"author": "Li Zhang", "text": "

@Acee Lindem, thanks for your reminding

", "time": "2025-03-17T07:52:40Z"}, {"author": "Keyur Patel", "text": "

Thank you @Gyan and @Changwang

", "time": "2025-03-17T07:54:04Z"}, {"author": "Tony Przygienda", "text": "

to protect against replay using peer-2-peer session mechanisms is simpler since you need to renegotiate \"nonces\" from both sides.

", "time": "2025-03-17T07:59:29Z"}, {"author": "Jeffrey Haas", "text": "

This mechanism has no nonces

", "time": "2025-03-17T07:59:42Z"}, {"author": "Tony Przygienda", "text": "

yepp, and even if it had, it would a \"sequence number\" and those can be always attacked by replaying a higher version recorded before

", "time": "2025-03-17T08:00:06Z"}, {"author": "Tony Przygienda", "text": "

you end up inventing igp flooding then ;-)

", "time": "2025-03-17T08:00:16Z"}, {"author": "Jeffrey Haas", "text": "

There was a prior idea for bgpsec during development of \"beacons\"

", "time": "2025-03-17T08:00:27Z"}, {"author": "Maria Mat\u011bjka", "text": "

we can protect against replay by time-limiting the validity but it looks quite crazy to have to re-sign and re-flood the whole internet with new advertisements

", "time": "2025-03-17T08:01:10Z"}, {"author": "Tony Przygienda", "text": "

different architecture and you start to slide towards SCION but yeah, different approach that AFAIS does not scale particularly well, especially if topoiogy is dynamic

", "time": "2025-03-17T08:01:16Z"}, {"author": "Jeffrey Haas", "text": "

that's why beacons were disconsidered, maria

", "time": "2025-03-17T08:01:24Z"}, {"author": "Maria Mat\u011bjka", "text": "

yet in the end our reason to not implement BGPsec yet, has been performance, and only now it looks actually viable \u2026 and we don't see any reason to go for FC-BGP when we can just go for full BGPsec

", "time": "2025-03-17T08:02:37Z"}, {"author": "Tony Przygienda", "text": "

ROV and ASPA (plus of course RPKI) are practially what is economically and practically best thing right now. my personal 2c

", "time": "2025-03-17T08:03:31Z"}, {"author": "John Scudder", "text": "

+lots to Jeff. It\u2019s not a question of \u201ccan this be done\u201d\u2018it\u2019s a question of where to expend our collective energy

", "time": "2025-03-17T08:03:33Z"}]