> We run away from RSVP years ago :-). Good ! Would never suggest RSVP-TE any longer :)
I rather meant end to end performance routing when applied to your WAN. Maybe just with few anchor nodes to diversify the paths. Could be SR based could be plain UDP. Thx On Thu, Apr 30, 2020 at 11:59 AM Mark Tinka <mark.ti...@seacom.mu> wrote: > > > On 30/Apr/20 11:31, Robert Raszuk wrote: > > > The problem here is that you are all correct in a sense :) The > fundamental > > issue is that routing protocols today just don't know how to create > stable > > routing topologies based on dynamic metrics (of any sort). And this is > the > > same for IGPs or BGP too. > > I just don't see that, in our implementation. > > I agree that bandwidth-only metrics aren't sufficient. But combining > that with device functions and latency, really works. Has for us. > > > > Good news however is that overlays come to the rescue and if you really > > care you can assure your customers packet get best end to end service. > Sure > > a lot of space for improvement there as well, but at least we are at good > > start. > > We run away from RSVP years ago :-). Our model + simple LDP has worked > very well. Fair point, we are in a position to have the kind of capacity > we need on any segment, which goes a long way to realizing this. > > > Mark. > _______________________________________________ > cisco-nsp mailing list cisco-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
