Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?

Jeff Tantsura <jefftant.ietf@gmail.com> Mon, 15 July 2019 22:48 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 CA2AD1200A4; Mon, 15 Jul 2019 15:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 ZOtUC14NXja6; Mon, 15 Jul 2019 15:48:19 -0700 (PDT)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 7F18B120091; Mon, 15 Jul 2019 15:48:19 -0700 (PDT)
Received: by mail-pl1-x635.google.com with SMTP id k8so9044127plt.3; Mon, 15 Jul 2019 15:48:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=oxLgAKRC/TDX7rthM19I8sMf/0EXmFgdOjvbKP+wwfk=; b=EYeXV+D0Hxdrf/4Qqdq4TmQgdVMpUzPOZqovZdHk2DOJUgLFkQaRVr68l9SRMpSx7B sYG2a0skKv5An9xQdWtykoff4iCnHUioYat7skIa291kmT30s+Do5tkgV53xW1FTDcmE mzwitgypzXRPHGB0MyLxCM9s596gH3vEyNMGoiihRLGVGi9WJFUSaKITShesjp3PtRuK ww2uE8oH5zUJ4DCavIsF5KncMNd8m7rVUJaKX9K8MM3Vt1fwESa1LnVfYBrpZVtvQcO5 R0ArGxjT/arkL6naBHare/0w2nYhgPehdaIMCxTLKYrXTz8I2qVZN67BJOHmfQmj9Lxo ZMwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=oxLgAKRC/TDX7rthM19I8sMf/0EXmFgdOjvbKP+wwfk=; b=iZpceCe7pwchsG4xtc9os7AvKnzRAxSftidudqqTC5QpiXJHC2N/Y1bBh6y0iPIT2C n9IDwQE59x4tdkd0qbDhXYVc+Nwt/AqsJ6nxIWlhw5PX388/DZhgqh2F3/SNGCtYgpjH EQ0JxH5MTvjPYrk7aShMXoGLxoQRVsP+jHzyxBAUAKblAVYteIwGhMHIE4/gAw3LPugp Vajj3AUoj7fYXy8SvoqbDKuPRXDcXSWHu9c5ogSCa1i3qWeSVkeRE1GwpGiukmB+Zjwt q2ePd8CcOXAstDV8G13IuBBWiec1EZl6sxKzA5Mx6Q4l6zQGWVtudQkfptybr6L9WrVp /gVw==
X-Gm-Message-State: APjAAAUaFGT/Rjpw54hjWTcKOLEQBjMXsL2FTtOnkBdgiRetYf35Sf8s fJBMWHgAg+ageFQfDyXZXk5GTd5r
X-Google-Smtp-Source: APXvYqx5IImdG0YG80yC/eUkVrLiiYqc2xH/uC4fnFjUDk/iI23lOG2bNSDgIhcZHJa7ZyIilgTeTA==
X-Received: by 2002:a17:902:704c:: with SMTP id h12mr29714387plt.318.1563230898785; Mon, 15 Jul 2019 15:48:18 -0700 (PDT)
Received: from [10.5.5.194] ([50.235.77.202]) by smtp.gmail.com with ESMTPSA id e10sm18549187pfi.173.2019.07.15.15.48.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jul 2019 15:48:18 -0700 (PDT)
Date: Mon, 15 Jul 2019 15:48:08 -0700
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: spring <spring-bounces@ietf.org>, SPRING WG <spring@ietf.org>, "徐小虎(义先)" <xiaohu.xxh@alibaba-inc.com>, Linda Dunbar <linda.dunbar@futurewei.com>
Message-ID: <b1f72412-c484-41ad-b5f9-1922458819c6@Spark>
In-Reply-To: <MN2PR13MB358219A35895BE96008D1DDB85CF0@MN2PR13MB3582.namprd13.prod.outlook.com>
References: <MN2PR13MB35821DA403CCE784CB3B065D85F60@MN2PR13MB3582.namprd13.prod.outlook.com> <MN2PR13MB3582CAA473AD49E7357B6CD085F60@MN2PR13MB3582.namprd13.prod.outlook.com> <c4f2a5ff-cac2-4d5f-9f9d-2dd810009384.xiaohu.xxh@alibaba-inc.com> <53f3a00b-2dc1-4762-99c3-de7f57b592d2@Spark> <MN2PR13MB358219A35895BE96008D1DDB85CF0@MN2PR13MB3582.namprd13.prod.outlook.com>
X-Readdle-Message-ID: b1f72412-c484-41ad-b5f9-1922458819c6@Spark
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="5d2d02b0_495c0ea5_c7f7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/AIyPpu-K4cry6Sy7GHY5OUdC1Nc>
Subject: Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
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, 15 Jul 2019 22:48:22 -0000

Linda,

What you want is to use native MPLS when available and encapsulate MPLS packets in IP/UDP when you need to travers IP, you destination in the imposed IP header would be that of the next SR capable device as described in draft-ietf-mpls-sr-over-ip.

Cheers,
Jeff
On Jul 15, 2019, 3:24 PM -0700, Linda Dunbar <linda.dunbar@futurewei.com>, wrote:
>
> Jeff,
>
> The draft-ietf-mpls-sr-over-ip only has MPLS packets being tunneled by IP, but not reversed (IP packets tunneled over MPLS).
>
> Do you think it worthwhile to add some similar sections (of course with different content), such as Forwarding entry Construction, forwarding procedures as in draft-ietf-mpls-sr-over-ip?
>
> Linda
>
> From: Jeff Tantsura <jefftant.ietf@gmail.com>
> Sent: Tuesday, July 09, 2019 4:03 PM
> To: spring <spring-bounces@ietf.org>; Linda Dunbar <linda.dunbar@futurewei.com>; SPRING WG <spring@ietf.org>; 徐小虎(义先) <xiaohu.xxh@alibaba-inc.com>
> Subject: Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?
>
> +1
>
> take a look at draft-ietf-mpls-sr-over-ip
>
> Cheers,
> Jeff
> On Jul 8, 2019, 11:45 PM -0700, 徐小虎(义先) <xiaohu.xxh@alibaba-inc.com>, wrote:
>
> > Hi Linda,
> >
> > Why not directly use the MPLSoUDP encapsulation to carry the B-SID label so as to indicate the preferred path? For more details, please read https://tools.ietf.org/html/draft-dukes-spring-sr-for-sdwan-02#section-7.3
> >
> > Best regards,
> > Xiaohu
> >
> > > ------------------------------------------------------------------
> > > From:Linda Dunbar <linda.dunbar@futurewei.com>
> > > Send Time:2019年7月9日(星期二) 06:26
> > > To:Linda Dunbar <linda.dunbar@futurewei.com>; SPRING WG <spring@ietf.org>
> > > Subject:Re: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?
> > >
> > > Sorry, I meant to ask:
> > >
> > > When the SDWAN edge nodes are NOT directly connected to the PEs of SR domain, is it appropriate for SDWAN edge nodes to use GRE/VxLAN header bits to indicate the desired SR Path?
> > >
> > > Linda
> > >
> > > From: spring <spring-bounces@ietf.org> On Behalf Of Linda Dunbar
> > > Sent: Monday, July 08, 2019 5:11 PM
> > > To: SPRING WG <spring@ietf.org>
> > > Subject: [spring] Seeking comments for draft-dunbar-sr-sdwan-over-hybrid-networks: is it appropriate for not-directly connect SDWAN edges to use GRE/VxLAN header bits to indicate the desired SR path?
> > >
> > > SD-WAN, as described by ONUG (Open Network User Group), is about pooling WAN bandwidth from multiple service providers to get better WAN bandwidth management, visibility & control.
> > > Because of the ephemeral property of the selected Cloud DCs, an enterprise or its network service provider may not have the direct links to the Cloud DCs that are optimal for hosting the enterprise’s specific workloads/Apps. Under those circumstances, SD-WAN is a very flexible choice to interconnect the enterprise on-premises data centers & branch offices to its desired Cloud DCs...
> > > However, SD-WAN paths over public internet can have unpredictable performance, especially over long distances and cross state/country boundaries. Therefore, it is highly desirable to place as much as possible the portion of SD-WAN paths over service provider VPN (e.g. enterprise’s existing VPN) that have guaranteed SLA and to minimize the distance/segments over public internet.
> > >
> > > https://datatracker.ietf.org/doc/draft-dunbar-sr-sdwan-over-hybrid-networks/ describes a method to enforce a SD-WAN path’s head-end selected route traversing through a list of specific nodes of multiple network segments without requiring the nodes in each network segments to have the intelligence (or maintaining states) of selecting next hop or next segments.
> > >
> > > When a SR domain has multiple PEs with ports facing the external networks (such as the public internet or LTE termination), SD-WAN paths can traverse the SR domain via different ingress/egress PEs resulting in different E2E performance.
> > >
> > > Even with the same ingress/egress, some flows may need different segments across the SR Domain. It is not practical, or even possible, for PEs to determine which Apps’ flows should egress.
> > > Segment Routing can be used to steer packets (or path) to traverse the explicit egress node, or explicit segments through the SR Domain based on the SLA requested by the SD-WAN head-end nodes.
> > >
> > > When the SDWAN edge nodes are directly connected to the PEs of SR domain, is it appropriate for SDWAN edge nodes to use GRE/VxLAN header bits to indicate the desired SR Path?
> > >
> > > We are looking for feedback, criticisms, or suggestion on the the proposed approach.
> > >
> > > Thank you,
> > > Linda
> > _______________________________________________
> > spring mailing list
> > spring@ietf.org
> > https://www.ietf.org/mailman/listinfo/spring