On 7/3/2018 10:12 AM, Alexander Vainshtein wrote:
Hi all,
Looking at this thread I come to conclusion (probably knew that before
as well) that existing RFCs dealing with MPLS-TE simply do not define
whether Diff-Serv resources are or are not allocated per LSP.
Specifically, RFC 3270 (not sure what else to look at) only says
<quote>
When bandwidth requirements are signaled at the establishment of an
L-LSP, the signaled bandwidth is obviously associated with the L-
LSP's PSC. Thus, LSRs which use the signaled bandwidth to perform
admission control may perform admission control over Diff-Serv
resources, which are dedicated to the PSC (e.g., over the bandwidth
guaranteed to the PSC through its scheduling weight).
When bandwidth requirements are signaled at the establishment of an
E-LSP, the signaled bandwidth is associated collectively with the
whole LSP and therefore with the set of transported PSCs. Thus, LSRs
which use the signaled bandwidth to perform admission control may
perform admission control over global resources, which are shared by
the set of PSCs (e.g., over the total bandwidth of the link).
<end quote>
Note that this text does not even define some optional behavior, as it
does not use the IETF capitalized MAY.
I don't think you can read too much on the use of lower/uppercase given
the age of the document (look at inconsistent usage of must/MUST in the
document for example.)
Did I miss something?
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: alexander.vainsht...@ecitele.com
-----Original Message-----
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Lou Berger
Sent: Tuesday, July 3, 2018 4:54 PM
To: Robert Raszuk <rob...@raszuk.net>; Jeff Tantsura
<jefftant.i...@gmail.com>
Cc: SPRING WG List <spring@ietf.org>; Linda Dunbar
<linda.dun...@huawei.com>
Subject: Re: [spring] solicit feedback on
draft-dunbar-sr-sdwan-over-hybrid-networks-02 proposing SD-WAN source
node using UDP port to indicate to SR ingress node how to map to
appropriate Binding SID
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
> spring@ietf.org <mailto:spring@ietf.org>
> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org <mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
___________________________________________________________________________
This e-mail message is intended for the recipient only and contains
information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have
received this
transmission in error, please inform us by e-mail, phone or fax, and
then delete the original
and all copies thereof.
___________________________________________________________________________
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
