Welcome to IDR interim meeting
", "time": "2024-02-26T15:01:34Z"}, {"author": "Robert Raszuk", "text": "Imagine you have 1000 clients on the RR. And imagine each will send you a different number as to the max add-paths willing to receive. How does this not result in per peer update generation ?
", "time": "2024-02-26T15:35:43Z"}, {"author": "Keyur Patel", "text": "Bunch of error handling rules are missing
", "time": "2024-02-26T15:37:51Z"}, {"author": "Keyur Patel", "text": "Or so it see
", "time": "2024-02-26T15:37:57Z"}, {"author": "Keyur Patel", "text": "a
", "time": "2024-02-26T15:37:57Z"}, {"author": "Keyur Patel", "text": "Seems
", "time": "2024-02-26T15:38:06Z"}, {"author": "Robert Raszuk", "text": "indeed ..
", "time": "2024-02-26T15:38:18Z"}, {"author": "Ketan Talaulikar", "text": "@Jeff this isnt the same as RTC. The sender needs to maintain a per prefix per peer count of paths?
", "time": "2024-02-26T15:40:10Z"}, {"author": "Keyur Patel", "text": "Yes it\u2019s not the same as rtc
", "time": "2024-02-26T15:40:26Z"}, {"author": "Jeffrey Haas", "text": "It's analogous solely on the idea that it's selective advertisement of routes. If you advertise exactly one, like rtc, then it looks like that
", "time": "2024-02-26T15:41:06Z"}, {"author": "Jeffrey Haas", "text": "If it's add-paths with rtc, then it's same as suppressing specific subsets
", "time": "2024-02-26T15:41:27Z"}, {"author": "Jeffrey Haas", "text": "But these are analogies. It's up to your implementation and we're not trying to mandate someone's specific implementation behave a specific way.
", "time": "2024-02-26T15:41:53Z"}, {"author": "Robert Raszuk", "text": "RTC is doing filtering based on the information in the UPDATE ... here you need to keep track what was sent before ... think implicit withdraws
", "time": "2024-02-26T15:42:12Z"}, {"author": "Jeffrey Haas", "text": "yes, think implicit withdraws, which is the state our implementation tracks.
", "time": "2024-02-26T15:43:08Z"}, {"author": "Ketan Talaulikar", "text": "@robert .. exactly my point. This is a challenge on the sending side.
", "time": "2024-02-26T15:43:12Z"}, {"author": "Keyur Patel", "text": "@robert, @ketan - yep
", "time": "2024-02-26T15:44:13Z"}, {"author": "Keyur Patel", "text": "But local configuration mode already solves it. So what\u2019s the motivation behind signaling
", "time": "2024-02-26T15:44:46Z"}, {"author": "Ketan Talaulikar", "text": "+1 to Keyur
", "time": "2024-02-26T15:45:09Z"}, {"author": "Robert Raszuk", "text": "@keyur - indeed especially that this is static config anyway on the \"sender\"
", "time": "2024-02-26T15:46:50Z"}, {"author": "Keyur Patel", "text": "Now how does this work in multiple tiered Clos? Disclaimer - haven\u2019t read the draft
", "time": "2024-02-26T15:48:46Z"}, {"author": "Keyur Patel", "text": "And why not use igp if you really need this feature?
", "time": "2024-02-26T15:49:07Z"}, {"author": "Keyur Patel", "text": "If the next nexthop link is congested would you withdraw it? Does it generate more updates?
", "time": "2024-02-26T15:49:47Z"}, {"author": "Shyam Sethuram", "text": "I guess there was some previous work using DMZ-LB to solve a similar issue
", "time": "2024-02-26T15:49:53Z"}, {"author": "Robert Raszuk", "text": "I am actually not sure what problem are we solving ? different multipaths at different stages ?
", "time": "2024-02-26T15:50:16Z"}, {"author": "Robert Raszuk", "text": "I am not buying the RAM issue ... you do not need to negotiate addpaths if you are running Raspberry Pi as PE/TOR
", "time": "2024-02-26T15:51:03Z"}, {"author": "Kaliraj Vairavakkalai", "text": "Can MPLS-Label (Pop-n-Fwd) be used to indicate the next-nexthop? Along with Addpath.
", "time": "2024-02-26T15:55:40Z"}, {"author": "Jie Dong", "text": "Can this problem be solved by using BGP-SPF?
", "time": "2024-02-26T15:55:41Z"}, {"author": "Jie Dong", "text": "Here is the link to BGP-SPF draft: https://datatracker.ietf.org/doc/html/draft-ietf-lsvr-bgp-spf-29
", "time": "2024-02-26T15:57:44Z"}, {"author": "Jeffrey Haas", "text": "LSVR can provide a flavor of the solution, but is again meant to operate on the distribute topology rather than bandwidth availability.
", "time": "2024-02-26T15:58:03Z"}, {"author": "Jeffrey Haas", "text": "The goal remains to locally bias at a given ECMP the weighting of individual links. This may not simply be \"the upstream path is down\", it may be congested.
", "time": "2024-02-26T15:58:31Z"}, {"author": "Jeffrey Haas", "text": "Any mechanism that carries congestion in the topology distribution makes for huge noise in the topology.
", "time": "2024-02-26T15:58:52Z"}, {"author": "Jeffrey Haas", "text": "The second draft will likely be applicable to lsvr scenarios as well.
", "time": "2024-02-26T15:59:17Z"}, {"author": "Keyur Patel", "text": "The graph using bgp spf gives you exactly that
", "time": "2024-02-26T15:59:27Z"}, {"author": "Jeffrey Haas", "text": "I doubt you really wan to shake the graph every few ms.
", "time": "2024-02-26T15:59:46Z"}, {"author": "Keyur Patel", "text": "And the link congestion would still need an out of band signaling
", "time": "2024-02-26T16:00:08Z"}, {"author": "Jeffrey Haas", "text": "we said that
", "time": "2024-02-26T16:00:16Z"}, {"author": "Jeffrey Haas", "text": "The described NNHN draft is just providing a topology binding for that technology
", "time": "2024-02-26T16:00:33Z"}, {"author": "Keyur Patel", "text": "Igp guys claim they doesn\u2019t need to worry about running spf frequently
", "time": "2024-02-26T16:00:40Z"}, {"author": "Jeffrey Haas", "text": "There's a few igp experts online. Feel free to discuss. :-)
", "time": "2024-02-26T16:01:37Z"}, {"author": "Keyur Patel", "text": "Point being - graphs are good way to solve and can be re evaluated frequently. :)
", "time": "2024-02-26T16:01:40Z"}, {"author": "Keyur Patel", "text": "I will let them chime in
", "time": "2024-02-26T16:02:04Z"}, {"author": "Keyur Patel", "text": ":)
", "time": "2024-02-26T16:02:09Z"}, {"author": "Kevin Wang", "text": "@keyur, sorry I lost my mic for a moment while you were asking questions. Would you mind to send the draft you mentioned offline so that we can address your question offline?
", "time": "2024-02-26T16:03:50Z"}, {"author": "Jeffrey Haas", "text": "See Jie's message above, Kevin.
", "time": "2024-02-26T16:04:12Z"}, {"author": "Ketan Talaulikar", "text": "@Kevin @Jeff can this proposal be generalized to more layers of CLOS? That is the key question ...
", "time": "2024-02-26T16:07:45Z"}, {"author": "Jeffrey Haas", "text": "Ketan, possibly so, but the work we're currently addressing is geared toward a local balancing decision based on the immediate upstream's congestion.
", "time": "2024-02-26T16:08:35Z"}, {"author": "Donatas Abraitis", "text": "\n", "time": "2024-02-26T16:09:05Z"}, {"author": "Robert Raszuk", "text": "Imagine you have 1000 clients on the RR. And imagine each will send you a different number as to the max add-paths willing to receive. How does this not result in per peer update generation ?
\n
\nRobert, it results in update-group creation per-peer if the different numbers are used between the peers. But the same is with ADD-PATHS \"Disable-RX\" flag combination.
That does not scale. And it is not the same as disable-rx .. as then you have only two groups ON and OFF
", "time": "2024-02-26T16:10:01Z"}, {"author": "Donatas Abraitis", "text": "Frankly, I can't imagine 1000 peers with 1000 different limits :)
", "time": "2024-02-26T16:10:47Z"}, {"author": "Jeffrey Haas", "text": "And similarly, the feature is predicated on it being an option. Your choice if you understand the path-limit capability and don't like its suggestion is to either ignore it - or not permit the session to be established. This is no different than any other capability.
", "time": "2024-02-26T16:12:43Z"}, {"author": "Robert Raszuk", "text": "Practically you do not always know how many paths to ask for .. as you do not know how many is present or will be present on RRs.
", "time": "2024-02-26T16:15:18Z"}, {"author": "Robert Raszuk", "text": "As suggested on the list instead of raw number let's add add-paths deployment scenario from the draft instead or in addition to
", "time": "2024-02-26T16:15:48Z"}, {"author": "Jeffrey Haas", "text": "List discussion is good, but fundamentally it comes down to letting the reflector be configured for a common number of paths it thinks the downstreams in the network would like and letting the clients - which know their own limitations or needs - signal the choice.
", "time": "2024-02-26T16:19:22Z"}, {"author": "Jeffrey Haas", "text": "Very similar to prior discussion on the RD-orf, don't make the client have to throw it all away and don't make the reflector clog its pipes with things that are trash to the client.
", "time": "2024-02-26T16:19:58Z"}, {"author": "Donatas Abraitis", "text": "1 full-feed is ~700Mb of memory, it's quite easy to calculate. For a small leaf device, that's a huge issue actually to run add-paths at all. At least we had similar issue when enabled add-paths with only 5 paths per prefix, and everything just melted.
", "time": "2024-02-26T16:20:21Z"}, {"author": "Robert Raszuk", "text": "Then do not run add-paths at all
", "time": "2024-02-26T16:20:57Z"}, {"author": "Ketan Talaulikar", "text": "@Jeff, but this is also solved via sender (RR) side config knobs today as well. right? If so, perhaps the draft should at least state that and then justify the need for signaling the value.
", "time": "2024-02-26T16:21:00Z"}, {"author": "Robert Raszuk", "text": "Or run with add-paths 2
", "time": "2024-02-26T16:21:06Z"}, {"author": "Donatas Abraitis", "text": "What do you mean \"with add-paths 2\"?
", "time": "2024-02-26T16:21:35Z"}, {"author": "Donatas Abraitis", "text": "@Ketan, some implementations have, some not, thus it might be a helpful defining this (what this draft also does technically)...
", "time": "2024-02-26T16:23:01Z"}, {"author": "Robert Raszuk", "text": "Add-paths 2 - sender side cfg
", "time": "2024-02-26T16:24:02Z"}, {"author": "Ketan Talaulikar", "text": "@Donatas, the sender side config knob option will be a simpler thing for implementations that do not have this already ... than the dynamic signaling part.
", "time": "2024-02-26T16:24:39Z"}, {"author": "Donatas Abraitis", "text": "simpler, but undefined :) and technically, VERY LITTLE simpler :)
", "time": "2024-02-26T16:25:42Z"}, {"author": "Robert Raszuk", "text": "What do you mean \"undefined\" ? google for \"bgp additional-paths select best <number>\"
", "time": "2024-02-26T16:27:43Z"}, {"author": "Ketan Talaulikar", "text": "@ Donatas, please feel free to pivot your draft to define the config knob behavior ;-)
", "time": "2024-02-26T16:29:30Z"}, {"author": "Donatas Abraitis", "text": "I know that it's possible by some implementations, but... What if I'm not under the administrative domain? Or what if I want to change that dynamically (paths limit), but the RR side has template? Then reconfiguration must happen at some level.
", "time": "2024-02-26T16:30:07Z"}, {"author": "Ketan Talaulikar", "text": "@ Donatas, that sort of justification for dynamic signaling in the draft will be helpful
", "time": "2024-02-26T16:31:12Z"}, {"author": "Donatas Abraitis", "text": "I mean it's much more dynamic, than trusting the sender-side. In other words: \"clients-side throtheling\".
", "time": "2024-02-26T16:31:17Z"}, {"author": "Donatas Abraitis", "text": "@Ketan for example? Could you reply in the IDR list, would be easier to track? :) Thanks.
", "time": "2024-02-26T16:31:51Z"}, {"author": "Jeffrey Haas", "text": "ketan, the addpaths limit is absolutely a provisioning discussion. yes, you can always do it at the sender. do that if you like. this is an option.
", "time": "2024-02-26T16:39:09Z"}, {"author": "Robert Raszuk", "text": "But the same OPS will configure either the RR or 1000s of PEs which in turn are to push stuff to this RR - which one is less error prone ?
", "time": "2024-02-26T16:40:21Z"}, {"author": "Ketan Talaulikar", "text": "@Robert - great point!
", "time": "2024-02-26T16:42:30Z"}, {"author": "Jeffrey Haas", "text": "\"Which one is less error prone\" makes up way too much of my discussions with service providers, especially large ones with territorial arguments about backbones vs. edge devices.
", "time": "2024-02-26T16:42:38Z"}, {"author": "Jeffrey Haas", "text": "in any case, you don't like it, don't implement it. we already have the capability code.
", "time": "2024-02-26T16:43:17Z"}, {"author": "Robert Raszuk", "text": "@jeff with that approach we may as well avoid any WG input ...
", "time": "2024-02-26T16:51:49Z"}, {"author": "Jie Dong", "text": "@Ketan we will think about the terminology alignment with PCEP
", "time": "2024-02-26T16:52:19Z"}, {"author": "Ketan Talaulikar", "text": "@Jie ... thanks. It will help clarify that this is bringing something from PCEP into BGP-SRTE.
", "time": "2024-02-26T16:53:18Z"}, {"author": "Jie Dong", "text": "@Kaliraj we can add some details about the allocation in the draft
", "time": "2024-02-26T16:55:14Z"}]