Hi folks,
I'm glad the thread spun up an interesting discussion but my original
question was more around why would anyone prefer IntServ to DiffServ in an
RSVP-TE environment.
Personally I prefer RSVP-TE solely for TE purposes and QoS for QoS purposes,
but there are always compromises if you haven't found one you're not looking
hard enough, so here I am looking...
So couple facts first,
If you're willing to use IntServ with RSVP-TE then:
1) You're willing to introduce another set of constrains to how tunnels are
routed across the core links in terms of available BW in pools and
sub-pools.
- These constrains however are not static like say SRLGs/Link colouring, but
very dynamic and will be changing through time.
2) You're willing to introduce another dynamic factor and that is BW
requirements for the tunnel
- once again this will be changing in time
Of course both of these will introduce a whole battalion of dynamic
variables that will all have effect on each other in various feedback loops.
And also since none of these variables is updated in real-time due to
scaling reasons (btw there's no such thing as real-time anyways) there will
be all kinds of trailing effects and race conditions where the network will
not respond to the actual situation on links in a timely fashion.
Not to mention the bin packing problem
- and the need to make the system even more granular thereby introducing
ever more state and change in order to manage the bin packing problem.
And the only advantage of IntServ I could think of is admission control,
But again this seems a bit dubious considering the non-real-time nature of
this solution.
And besides, I'm not sure I'd ever want to be in a position where I allow my
core links to max out and have TE to try and shuffle flows around so that I
can squeeze all traffic in.
- sure this would probably not be the case of day to day operation but most
likely only employed during link failures,
My Conclusion,
But still me experience is that designing and managing RSVP-TE solutions for
backbones is very complicated even with statically pre-defined path and
failure modes.
Now I can't even start to imagine the level of complexity if all this would
be one dynamic system -how would I know if the system performs as expected
or intended whether it's trying to work around some bottleneck or whether
what I'm looking at is just normal operation.
But maybe there are use cases that are indeed dependent on IntServ RSVP-TE.
I'd like to hear your thoughts.
Thank you
adam
netconsultings.com
-----Original Message-----
Sent: Monday, October 01, 2018 11:16 AM
Subject: [j-nsp] Use cases for IntServ in MPLS backbones
Hi folks,
Another pooling question from me,
This time I'm interested on what are your thoughts on DiffServ vs IntServ
in
MPLS backbones and what use cases for IntServ can you think of please.
So what I have in mind specifically is RSVP-TE in combination with
DiffServ
(standard QoS) vs IntServ (in all its glory i.e. BW pools and sub-pools,
allocation models RDM/MAM, etc..).
adam
netconsultings.com
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/