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

Jeff Tantsura <jefftant.ietf@gmail.com> Mon, 02 July 2018 23:55 UTC

Return-Path: <jefftant.ietf@gmail.com>
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 68469131476 for <spring@ietfa.amsl.com>; Mon, 2 Jul 2018 16:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level:
X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 XJ_G4lKno0Kw for <spring@ietfa.amsl.com>; Mon, 2 Jul 2018 16:55:37 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7E24131459 for <spring@ietf.org>; Mon, 2 Jul 2018 16:55:37 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id w76-v6so51770ywg.4 for <spring@ietf.org>; Mon, 02 Jul 2018 16:55:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=PbvRqZ8MyJ6CPBR++e4jDxiNeQdRoh7yFbN9QvJKNHg=; b=Lw0SgHq2UqGwBnnCCxRaw9MxJn78XWIalfEeLNtd+nglNEJtkWKsUgfXbj/S60hlad 2idkoBfP2mkfgGTHkSfD7Xh6pp0KYsxv0FQNSqBhmpUYEUHcQZru+dzH2b9SDqTVgZYZ yFhJfyvL51Wg6QuKicR41nqHF6nhd3fdilCZxGmMp72D7nzIs3IiJdxpPuUXtY5tZCg+ ZVE7rm949P3bnor/G5EXbjf2W7jI3OSQg1CO0QkcwqDotpb0MYPTKlN2u9sqJ92/ulRD wNHp3kFn1zKw9zu1w8aerfqKtbyAWFpDlZvETMK9gQH1BfgR4meDOEN8Fml7EBhUq91H uXlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=PbvRqZ8MyJ6CPBR++e4jDxiNeQdRoh7yFbN9QvJKNHg=; b=njC9epDz2qSnj42urKBrmxnbNw3CXeVHZNvSHctOGzaVPnsYkftny9bU8HJd5qm4Ue vGyM4zL+U4eVwGa6uaWuVBnS9cTHJqJClHFJL2wkgs/bzTJXncak71W8A7spdNwuJeMp RGXSt+8RQ7mMk6tjr/dnA/+Tzb1KXWAOvvBd+JqDdLqI7MyBiBaiabtlBCaN6OpX813u oM2M5xlenyTzNgSDQ7GeaTtVpti41XhIv67Ar8+Ho5OyOouaNSZWU2vdsTYW1SEl8Mai hwizCVF61nCDYAhK13fqlEjR1nPEwCoGm6y5+NENCXMrXvDBM9ZyZoPpt8k4n7pvbDxr fYWQ==
X-Gm-Message-State: APt69E0BvS/mZpDSNmJFeknpD/GibA6u0FCGtFLjY6r2cDHg0gMmnwKm lRGdHV4TEtHglVH0reLKcSw+hQ==
X-Google-Smtp-Source: AAOMgpdfYijcczCtahwotQCZHVWjprgn6YeuLIViDkFMobDa6oc6dNivnSkL26/SHLsakPYZDJhNQg==
X-Received: by 2002:a81:160c:: with SMTP id 12-v6mr972357yww.254.1530575736797; Mon, 02 Jul 2018 16:55:36 -0700 (PDT)
Received: from [135.227.239.108] ([66.201.62.254]) by smtp.gmail.com with ESMTPSA id d11-v6sm6918189ywd.1.2018.07.02.16.55.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Jul 2018 16:55:36 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/10.e.1.180613
Date: Mon, 02 Jul 2018 16:55:34 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Robert Raszuk <robert@raszuk.net>
CC: Linda Dunbar <linda.dunbar@huawei.com>, SPRING WG List <spring@ietf.org>
Message-ID: <55961CCD-1466-46DE-8203-F0B6620A6738@gmail.com>
Thread-Topic: [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
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>
In-Reply-To: <CA+b+ERkmYix=bb=81FFaNE_aPxdQNRFj3WsjqGyjDaB+i9OPgQ@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3613395335_1568815137"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/rMnlRuO4G925mMzcCyFhQHTshrc>
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: Mon, 02 Jul 2018 23:55:50 -0000

Robert,

 

“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.

 

While I agree with caution, there’s business push to provide technology where overlay’s business logic could interwork with underlay. 

 

To make my points clear – I’m not arguing with the business need but have my doubts about the technology proposed.

 

Cheers,

Jeff

 

From: <rraszuk@gmail.com> on behalf of Robert Raszuk <robert@raszuk.net>
Date: Monday, July 2, 2018 at 16:05
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Linda Dunbar <linda.dunbar@huawei.com>, SPRING WG List <spring@ietf.org>
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

 

Sorry ... sent too soon. 

 

What exactly do you call by "resource allocation" in WAN ? 

 

ATM PVCs ? 

 

If not all "reservations" are just control plane reservations and they *only* make any sense when you do the same for entire traffic you carry. Even worse unexpected events and vendor bugs will easily destroy your plan !

 

I advise a lot of caution when anyone is talking about "resource allocation" in IP networks. 

 

Thx,
R.

 

On Tue, Jul 3, 2018 at 1:02 AM, Robert Raszuk <robert@raszuk.net> wrote:

Jeff,

 

I am not sure if I should even get into this ... but oh well why not :) 

 

> Resource allocation could happen by either WAN controller pre-allocating resources 

> and then exposing them to SD-WAN controller for consumption (ala carte) or SD-WAN 

> controller asking for a particular set of resources (on demand) and WAN controller providing these.

 

 

On Tue, Jul 3, 2018 at 12:36 AM, Jeff Tantsura <jefftant.ietf@gmail.com> wrote:

Hi Linda,

 

(not speaking as rtgwg chair, where you might want to present the draft) 

 

The scenario we are talking about is really - WAN (underlay/transport) controller interworking with SD-WAN (overlay) controller.

Resource allocation could happen by either WAN controller pre-allocating resources and then exposing them to SD-WAN controller for consumption (ala carte) or SD-WAN controller asking for a particular set of resources (on demand) and WAN controller providing these. In any case – there’s business relationship between 2 or more parties, so from functionality prospective a node that is transit (not service aware) should forward the traffic based on the destination, while node that is service aware (BSID anchor) should pop IP/UDP and lookup the BSID/steer the traffic into SR policy, using SPRING lingo. 

 

SRinUDP encap provides ability to traverse non SR /3rd party networks, BSID (has to be provided by WAN controller at the resource allocation time) is pushed by source SD-WAN node with the FEC that is associated with the particular behavior and hence doesn’t require any additional mapping, e.g BSID value is the mapping (BSID lookup yields an egress adj/tunnel)   

 

Hope this makes sense to you

 

Cheers,

Jeff

 

From: spring <spring-bounces@ietf.org> on behalf of Linda Dunbar <linda.dunbar@huawei.com>
Date: Monday, July 2, 2018 at 15:11
To: Robert Raszuk <robert@raszuk.net>


Cc: SPRING WG List <spring@ietf.org>
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

 

Robert, 

 

There are many definitions for SD-WAN in the industry. I used the one from ONUG, who claims that “SD-WAN” concept was created by them in 2013: https://www.onug.net/software-defined-wide-area-network-sd-wan/. 

 

In terms of real time deployment, there are plenty. For example, here are some public available cases & services: 

https://youtu.be/JRoTXMSxtCY; 

http://www.verizonenterprise.com/products/networking/managed-network-services/managed-sdwan/

http://www.centurylink.com/business/networking/sd-wan.html

 

It is CPE pooling together paths from different ISPs.   The draft proposes a method for Service Provider to attract flows which would otherwise traverse public internet, to traverse its own domain. 

 

Linda

 

From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: Monday, July 02, 2018 4:50 PM
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: SPRING WG List <spring@ietf.org>
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 Linda,

 

You mentioned in the document the below quote:

 

   "SD-WAN, as described by ONUG (Open Network User Group), is about

   pooling WAN bandwidth from n service providers to get better WAN

   bandwidth management, visibility & control."

 

Can you provide some real life examples listing which service providers allow to be externally pooled for their available WAN bandwidth as well as what interface is used to get such pooling instantiated in place ? 

 

Once we understand above next natural question would be to ask how accurate is such pooling in the light of the observation that due to basic characteristics of the service provider's traffic patterns available bandwidth or in other words congestion usually have very transient nature ? 

 

If I were writing such document I would give up any pooling and instead use one of many available techniques to measure the end to end path quality when making at the ingress the decision of the preferred path to be taken. That is in fact what number of SD-WANs today already do without any need to  make any attempts to enforce anything at the ingress to the transit journey :). 

 

Many thx,

Robert.

 

 

 

On Mon, Jul 2, 2018 at 11:33 PM, Linda Dunbar <linda.dunbar@huawei.com> wrote:

https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/ describes a method for end-to-end (E2E) SD-WAN paths (most likely encrypted) to traverse specific list of network segments, some of which are SR enabled and others may be IP networks that do not support SR, to achieve the desired optimal E2E quality. 
In another word, one or both SD-WAN end points are NOT directly attached to SR PE nodes. 

Under many circumstances the SR's Binding SID can't be exposed to the SD-WAN source node (e.g. if the SD-WAN source node belongs to a different administrator than the one who manage/own the SR domain). 

The draft propose a method for SR Controller to expose a "Key" to the SD-WAN source node. The SR Ingress node will map the "Key" carried by the SD-WAN traffic/flows to their designated Binding SID. 
The "Key" can be carried by GRE key field, or be encoded as UDP Source Port used by SD-WAN source node to differentiate flows. 

We understand that UDP source port is usually used for Entropy purpose. 

We want to hear feedback, flaws or allergic reaction to our proposed method for some deployment scenarios like: 
  1) only one or two 3rd party hops are between SD-WAN end points and PE and those hops may not even use Entropy (like LTE links); or 
  2) Grouping Applications by UDP ports may enforce same application traverse through same route, which is acceptable by many deployment scenarios).

Thank you very much. 

Linda Dunbar

_______________________________________________
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