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

[Robert Raszuk <[e-mail]>]

Hi,

Admission control is extremely important on ingress to the TE-LSPs. Without
it even the pure control plane reservation games all melt. That is also
fundamentally supported by any vendor I am ware of with MPLS-TE. For SR - I
do not know.

But this is still not what I consider data plane hard reservation over
entire LSP end to end path.

Best,
R.


On Tue, Jul 3, 2018 at 4:12 PM, Alexander Vainshtein <
[e-mail]> 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.
>
>
>
> Did I miss something?
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: [phone]
>
> Cell:      [phone]
>
> Email:   [e-mail]
>
>
>
> -----Original Message-----
> From: spring [mailto:[e-mail]] On Behalf Of Lou Berger
> Sent: Tuesday, July 3, 2018 4:54 PM
> To: Robert Raszuk <[e-mail]>; Jeff Tantsura <
> [e-mail]>
> Cc: SPRING WG List <[e-mail]>; Linda Dunbar <
> [e-mail]>
> 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
>
> > [e-mail]
>
> > https://www.ietf.org/mailman/listinfo/spring
>
>
>
> _______________________________________________
>
> spring mailing list
>
> [e-mail]
>
> 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.
> ____________________________________________________________
> _______________
>