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 <robert@raszuk.net> Mon, 02 July 2018 21:50 UTC

Return-Path: <rraszuk@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 F26C9130E27 for <spring@ietfa.amsl.com>; Mon, 2 Jul 2018 14:50:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=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 pboT95R3o6sB for <spring@ietfa.amsl.com>; Mon, 2 Jul 2018 14:50:18 -0700 (PDT)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 AC09D130E26 for <spring@ietf.org>; Mon, 2 Jul 2018 14:50:18 -0700 (PDT)
Received: by mail-pf0-x22a.google.com with SMTP id j17-v6so8093339pfn.5 for <spring@ietf.org>; Mon, 02 Jul 2018 14:50:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=w1+gL5FFxUhJcmZL+ugv1ZrSG8Z8a6L1pwi9y9TELB4=; b=VktS6F6lwDicPGEbgMxdBOY4ON+zeoI91bKhXJd68NozdwFpDT5MRaEEeNjzQM3xfv x8P5EI5+Srh/e/5n5My4iVYEKvNN6QPKkB0T9+FUNrFDMlKvCyHYqc7TKzpbfGGown4P yUOHOJbo3C0pn66Tw7tPs3s2WpRxns88o47nwwTbaUcK1D6GTGFsaAe9SAMld2cRw66D 5+5kiGAC/C0eegziEmh2v6sit9X6aHpYM0lBD3MXdCUoYoaMADjo1byF33PFFYFhxWM+ m1lZ06jryIwisSgjP/KXGaNmVMTvH6OYvKWxP9y0oMOW4X+XwYVcwE40X6ZSZl8Hpppj B9lQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=w1+gL5FFxUhJcmZL+ugv1ZrSG8Z8a6L1pwi9y9TELB4=; b=glCTZDETaR9RoGd/IWoXJXrHbTHyZoyj2ydW8rjKiMScrgPJqPpqCqlVDRIXgADFwh Wx7JtrynarWSwc7PzmQSCsv4T8KzKP24kgTZfoJZwZgSKATT58cKefRGQPqliURn8sgC u8PiXgW7E7KMXSkQrobe6hJ9nGq0S7Q7sJGg5DkmfYwtiMuMXrGqCu92PT7JpD+i/ACn 2CnVokPXJmMdZkwi/d5V7zPrW/0zAIlFsHviYWTzp3F7BayZDkArHqUubzxsrPJz5aYZ k4WJTfAaO21z/dcjMzMHXfLx4OLEFf2Q8W9yefHW5g5QkClfaRzMukU6dnRjfyBjml+X UOeQ==
X-Gm-Message-State: APt69E0nmyDYHTEp6JEgH5VLQKxLypejLhZpGZageg/7ydBlH0d5MdgD qphfujvm+opx/NckKzEuqMfS4Os2IY3RCQFckKk=
X-Google-Smtp-Source: AAOMgpfm6miBcoLd3jBZRqQAPG4KgGc6ikGlVypdTbwta9iB3kP05aU9BJS9oiuX3fEJzI4etqN5uwmEli7CrwarbcM=
X-Received: by 2002:a62:4704:: with SMTP id u4-v6mr4784148pfa.76.1530568217852; Mon, 02 Jul 2018 14:50:17 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 2002:a17:90a:6d62:0:0:0:0 with HTTP; Mon, 2 Jul 2018 14:50:17 -0700 (PDT)
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B07A77E@sjceml521-mbs.china.huawei.com>
References: <4A95BA014132FF49AE685FAB4B9F17F66B07A77E@sjceml521-mbs.china.huawei.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 02 Jul 2018 23:50:17 +0200
X-Google-Sender-Auth: XPs93PB2JFTwcQOlRwgK6AEUGzo
Message-ID: <CA+b+ERnB_6XUWmGFORxfLbvsEqMG-QrduvFJQZ2LvfdpPdq7jw@mail.gmail.com>
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: SPRING WG List <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000edffcd05700b2ee6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/uet_1oa6ivZoUMA5bC4pE4rgikc>
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 21:50:21 -0000

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
>