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
Lou Berger <lberger@labn.net> Tue, 03 July 2018 15:42 UTC
Return-Path: <lberger@labn.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CFF130F27 for <spring@ietfa.amsl.com>; Tue, 3 Jul 2018 08:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3217PJBCgpGI for <spring@ietfa.amsl.com>; Tue, 3 Jul 2018 08:42:10 -0700 (PDT)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C62D130F08 for <spring@ietf.org>; Tue, 3 Jul 2018 08:42:10 -0700 (PDT)
Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id CEC57216D2F for <spring@ietf.org>; Tue, 3 Jul 2018 09:17:16 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id aN3LfMqabp1y6aN3MfFegP; Tue, 03 Jul 2018 09:17:16 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=En5kHrsveOgE9dSMmLCCvbYK7ps4GbsvcBZehVHWLUg=; b=kppk++YR+P+uwGeYgjO41vVRN8 I7WPLO+T4qsJpek9/IuNrK7NBwIFeSUhHfKU5szwxgMxwPSkXlUNuRVWZwEtW4NVVAKNs57DwmNbn eBJhjzDLi85X1g18UAgh9Z3f8;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:43398 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1faN3L-000KX1-Da; Tue, 03 Jul 2018 09:17:15 -0600
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Robert Raszuk <robert@raszuk.net>, Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: SPRING WG List <spring@ietf.org>, Linda Dunbar <linda.dunbar@huawei.com>
References: <4A95BA014132FF49AE685FAB4B9F17F66B07A77E@sjceml521-mbs.china.huawei.com> <CA+b+ERnB_6XUWmGFORxfLbvsEqMG-QrduvFJQZ2LvfdpPdq7jw@mail.gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B07A7B3@sjceml521-mbs.china.huawei.com> <0D03E661-E302-46E4-B459-A155EFA295C7@gmail.com> <CA+b+ERm62KDq5mNSkCKqQPe+y_58oVAG03ArO0-iJ+O+2_KzPw@mail.gmail.com> <CA+b+ERkmYix=bb=81FFaNE_aPxdQNRFj3WsjqGyjDaB+i9OPgQ@mail.gmail.com> <55961CCD-1466-46DE-8203-F0B6620A6738@gmail.com> <CA+b+ERndJsU94rDX+AZfpmQpguUYr+=ZfKQ4ux63mx5nuRYsOA@mail.gmail.com> <3e872e88-d868-a2d7-9478-fc435f2a627e@labn.net> <DB5PR0301MB1909B4FD15523DAFC2CAD05D9D420@DB5PR0301MB1909.eurprd03.prod.outlook.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <6bc5a73a-bc3a-7392-e865-307f49e1f0ee@labn.net>
Date: Tue, 03 Jul 2018 11:17:14 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <DB5PR0301MB1909B4FD15523DAFC2CAD05D9D420@DB5PR0301MB1909.eurprd03.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.86.101
X-Source-L: No
X-Exim-ID: 1faN3L-000KX1-Da
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:43398
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/8-5awFBjHUsjtzmLQNjmjiz1s6U>
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
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jul 2018 15:42:14 -0000
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.Vainshtein@ecitele.com > > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Tuesday, July 3, 2018 4:54 PM > To: Robert Raszuk <robert@raszuk.net>; Jeff Tantsura > <jefftant.ietf@gmail.com> > Cc: SPRING WG List <spring@ietf.org>; Linda Dunbar > <linda.dunbar@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
- Re: [spring] solicit feedback on draft-dunbar-sr-… Robert Raszuk
- [spring] solicit feedback on draft-dunbar-sr-sdwa… Linda Dunbar
- Re: [spring] solicit feedback on draft-dunbar-sr-… Jeff Tantsura
- Re: [spring] solicit feedback on draft-dunbar-sr-… Jeff Tantsura
- Re: [spring] solicit feedback on draft-dunbar-sr-… Linda Dunbar
- Re: [spring] solicit feedback on draft-dunbar-sr-… Robert Raszuk
- Re: [spring] solicit feedback on draft-dunbar-sr-… Robert Raszuk
- Re: [spring] solicit feedback on draft-dunbar-sr-… Jeff Tantsura
- Re: [spring] solicit feedback on draft-dunbar-sr-… Robert Raszuk
- Re: [spring] solicit feedback on draft-dunbar-sr-… Lou Berger
- Re: [spring] solicit feedback on draft-dunbar-sr-… Robert Raszuk
- Re: [spring] solicit feedback on draft-dunbar-sr-… Lou Berger
- Re: [spring] solicit feedback on draft-dunbar-sr-… James N Guichard
- Re: [spring] solicit feedback on draft-dunbar-sr-… Robert Raszuk
- Re: [spring] solicit feedback on draft-dunbar-sr-… Robert Raszuk
- Re: [spring] solicit feedback on draft-dunbar-sr-… Alexander Vainshtein
- Re: [spring] solicit feedback on draft-dunbar-sr-… Lou Berger
- Re: [spring] solicit feedback on draft-dunbar-sr-… Alexander Vainshtein
- Re: [spring] solicit feedback on draft-dunbar-sr-… Linda Dunbar
- Re: [spring] solicit feedback on draft-dunbar-sr-… Linda Dunbar
- Re: [spring] solicit feedback on draft-dunbar-sr-… Linda Dunbar
- Re: [spring] solicit feedback on draft-dunbar-sr-… Linda Dunbar