On 7/3/2018 10:17 AM, Robert Raszuk wrote:
Hi Lou,
> *allocation* of resources (i.e., configuration of data plane queuing
and even per flow shaping and policing).
I will continue this topic as I do think it is quite important to be
on the same page in this WG and beyond. I guess we are at the
fudamental question what does it mean to "allocate or reserve a
resource".
to me
reserve = bookkeeping
allocate = assign specific resource to ensure specific traffic treatment
Clearly configuration of shaping and policing does not fall under such
definition.
why not? I agree it's not needed for reservation, but it is needed for
allocation.
Also as stated already sizing the queues is basic diffserv. Remember
that diffserv does not hard reserve anything too. It prioritizes
traffic and I have not seen any implementation which would
automatically adjust queue depths based on the reception of RSVP-RESV
msg.
I've seen ones that adjust based on Path;-)
To me "resource allocation" brings memory of SDH containers and TDM
networks which is a bit misleading if someone even remotely tries to
map it to diffserv.
Fair enough. Keep not every TE LSP is and E-LSP or L-LSP.
And since this is SPRING SR since day one claims full support for
diffserv both in SR-MPLS as well as SRv6 architectures.
Sure - feel free to see my comments in the context of SR-TE (only)
rather than SR with DiffServ.
Lou
Best,
R.
On Tue, Jul 3, 2018 at 3:53 PM, Lou Berger <[email protected]
<mailto:[email protected]>> wrote:
Hi Robert,
On 7/3/2018 4:07 AM, Robert Raszuk wrote:
Hello Jeff,
“What exactly do you call by "resource allocation" in WAN ?” –
anything that is not “best effort”, BW reservation, protection
type, number of hops, latency, you name it…
Somehow, between ATM and now
**
*we managed to build a technology that would work in both,
control
and data planes* 😉
TE with BW reservation is a working technology, with all
the bugs,
whether done as a soft state on a device and enforced in
FW, aka
RSVP-TE or computed on a controller and enforced by policing
configuration out of band. We also know pretty well how to
compute
a constrain path that is loop free and with the
constrains. Either
way, working stuff.
It has been nearly 20 years and it seems that some marketing
slides from vendors are still in minds of many many people ...
I think this is *quite* true. There's also quiet a bit of
marketing documents on what constitutes QoS (vs CoS).
MPLS-TE does *NOT* do any data plane reservations nor any data
plane resource allocation. It is all control plane game. Let
me shock you even more today ... what we call "Guaranteed
Bandwidth TE" also does *NOT* perform any data plane
reservations. This up to current days is the most
misunderstood element (or hidden secret) of one of the
technologies which has been made available during the last two
decades.
This *completely* depends on which vendor and platform you choose.
From the IETF perspective, the RFCs certainly support both
reservation (i.e., book keeping) and *allocation* of resources,
(i.e., configuration of data plane queuing and even per flow
shaping and policing). This is something that continues to be
included in all TE related RFCs to date.
If you signal MPLS TE LSP with 5M "reservation" to check if
such a path in your network can be established such check is
*ONLY* done at the control plane (RP/RE) pools of available
bandwidth (per priority level) registers and physical
interfaces nor any data plane queues are never aware of it.
again, this depends on the vendor and the platform. Informed users
understand this and those that care, buy equipment that satisfy
their requirements. I have worked on projects on both sides
(vendors and users/providers) and some care quite a bit about the
queuing behavior associated with TE, others are perfectly happy
with TE as a path selection/distribution/pinning tool.
Now what is a direct consequence of this is if you like to
really do control plane reservations and think of it as actual
data plane you must do it in 1:1 fashion - again all done in
control plane. That means that two fundamental conditions must
be met:
A) All traffic must be sent over MPLS-LSPs - be it IPv4, IPv6,
multicast etc ... - even if I have seen 3 networks trying to
do that for IPv4 no one did it for all traffic types.
B) All traffic entering your network must be subject to very
strict admission control and excess shaped or dropped which is
very hard thing to do considering statistical multiplexing
gains you count on in any IP network (Explanation: On any
single ingress node you must apply strict CAC as you are not
aware about what traffic is coming from other ingress nodes.
So you may be dropping or shaping traffic which could flow
through your network just fine end to end due to absence of
competing class from different ingress).
All RSVP-TE does is traffic steering in normal steady state
or during protection. That's all. In the WAN's data plane it
is all back to basic Diff Serve at each router's data plane.
The only technology which does provide interface data plane
reservation is RSVP IntServ - but I doubt anyone here or Linda
in her draft meant to use such tool.
While this statement may be true for certain vendors, it is not
true a *technology* or standards perspective.
Why am I jumping on this here in SPRING WG list ... Well few
months ago I have witnessed a discussion where someone was
arguing that SR is much worse then MPLS-TE as it does not
provide any data plane reservations. When I tried to nicely
and politely explain how confused the person is the look I got
was comparable to those green folks walking down from just
arrived UFO.
While I certainly accept that for some vendors SR-TE is just as
good as MPLS-TE, if SR-TE is defined as only supporting path
control this will be the first instance of a TE RFC/definition (at
least that I'm aware of) that won't support resource allocation,
i.e., *any* form of traffic treatment (queue) control.
So to conclude SR just like MPLS-TE does a good job in packet
steering via your domain. (SR can do actually more via
embedded functions/apps). But the fundamental difference is
that SR does that steering without necessity of number of
control plane protocols and their required extensions - so
does simplify control plane significantly. Neither of those do
any data plane reservations and all bandwidth contentions need
to be resolved via classic QoS.
There is a major difference here in what you characterize here,
i.e., SR-TE, and how the 'TE' term is used in the existing set of
RFCs. I don't know how we (the IETF) want to denote this
difference - I suspect this will depend on which WG is asked. In
this group it seems that some (perhaps many) are perfectly happy
to have SR-TE *not* include actual resource allocation and traffic
treatment (queue) control - I personally would prefer that it be
included so that the part of the market that cares about such can
be supported albeit with the need for users to evaluate actual
vendor TE implementations as is done today.
Lou
Cheers,
R.
_______________________________________________
spring mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
<https://www.ietf.org/mailman/listinfo/spring>
_______________________________________________
spring mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/spring
<https://www.ietf.org/mailman/listinfo/spring>
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
