Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Robert Raszuk <robert@raszuk.net> Sun, 31 January 2021 13:08 UTC

Return-Path: <robert@raszuk.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 3D5E93A0D05 for <spring@ietfa.amsl.com>; Sun, 31 Jan 2021 05:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.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 e5n4cdnzCZVZ for <spring@ietfa.amsl.com>; Sun, 31 Jan 2021 05:08:21 -0800 (PST)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 C6D843A0D03 for <spring@ietf.org>; Sun, 31 Jan 2021 05:08:20 -0800 (PST)
Received: by mail-lf1-x129.google.com with SMTP id h12so18956070lfp.9 for <spring@ietf.org>; Sun, 31 Jan 2021 05:08:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OMOmvbjEUrbViBgWWpg6f9aIVyBrw+ltMgvXgw301Hs=; b=EV8xTC3/mdqbEwQi0grAlOCteE1wr4bmWGQLOoimkSkGQUNnXIoBZuPXkdwZikPcei f4hbaXT4jL5yI2sLHXrgYyX9VRmgHDuH2enSpUmuDtB0xACfq8PfVp1zS4XEmUWbjbMq CR3ITPX0VQx0F9PYhxA5QPMi12VpTkeN52c23txywNssdAQCj5dA8xpnLnqOLlqlSRih LGaEbEVDr5G0UDRrynSTtnePYoG/sCXNmTKqVdhmY+1jvV8n12aArex7wkuOXeMDjS2M mCSo5VLJon2VyOVxRkbLPRsnWhWsNiNjHl5EZ+cqHZ6jBcRovtbW9KvhHMtuVQ0xmzD3 XWNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OMOmvbjEUrbViBgWWpg6f9aIVyBrw+ltMgvXgw301Hs=; b=Yi4WB+rOF+WE5sjetLKE1Ge7V8bdQ9Pl6aulocmF+TSnB8x4F4e3GsFpR29CPAPQj4 vBW0RjwW//5GvtBkH8C1lsv38plw4hS+SDLIEQY3mYmFjaDydqzewUQiShywLssGh5az 6vEG/cZoBV0ylkpVNWDGj9RbYDo1VeUNuqWfn+W2OKGlAeZwrTEJ9gIDLPKcf4BaZQI8 zDnKa8nHILre5myoJQpO1Sr9C/BUWBivd6vCOFdWzPAHa0GWvFKax70/gS5si51B5xzd YuMLxNPx//7vxHfnJbOD8p9PSPB0CRW7nCY9HtQ+BZyRSsICFCv7+GcxhBD4zpJulGdL uPXg==
X-Gm-Message-State: AOAM53145hiTm0YxVCFSq2d+1lqbDlK3IpGJDNa9BYDm8RM4Tu+rKuTG 12u6rKXRMU81anoxusfPuA+g419CTzQek8dQjhL+OQ==
X-Google-Smtp-Source: ABdhPJxh8U4ugwHaJ6pZFtY+EectgfuVqGajjk9qYlK3ryGrFmvUUY9FIyqdqg3fLKWDyfzKKvlEL3XWBkc1fD4V4yI=
X-Received: by 2002:a19:4017:: with SMTP id n23mr6778559lfa.541.1612098498252; Sun, 31 Jan 2021 05:08:18 -0800 (PST)
MIME-Version: 1.0
References: <MN2PR13MB42061AD1E295598F1F2726BDD2BB9@MN2PR13MB4206.namprd13.prod.outlook.com> <05b301d6f756$1485ced0$3d916c70$@olddog.co.uk> <CAOj+MMG4ObcXwCfE9f2yd4Nts4juguX5QO7Hje0TszUAM-62KA@mail.gmail.com> <05e801d6f7c9$7f1184b0$7d348e10$@olddog.co.uk>
In-Reply-To: <05e801d6f7c9$7f1184b0$7d348e10$@olddog.co.uk>
From: Robert Raszuk <robert@raszuk.net>
Date: Sun, 31 Jan 2021 14:08:08 +0100
Message-ID: <CAOj+MMGaWXFFFmc9CabGF4gRL-r_v2aab9hvQNOqAF5iSSvS_g@mail.gmail.com>
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: James Guichard <james.n.guichard@futurewei.com>, SPRING WG <spring@ietf.org>, spring-chairs@ietf.org
Content-Type: multipart/alternative; boundary="00000000000054e4a805ba31eeed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/t33y4QMn4KDvSdpBVEguzK42fYs>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
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: Sun, 31 Jan 2021 13:08:23 -0000

Hi Adrian,

> To your 3209 comments: I believe that **some** implementations have
pushed the “reservation”
> into the data plane so that in-network policing is performed to conform
data flows with reservations or,

Sure thing that any decent TE implementation and deployment must provide
ingress policing into TE-LSPs. But this is ingress policing not reservation
of actual data plane resources which explicitly Jie explained as the
intention here.

Best,
R.


> On Sun, Jan 31, 2021 at 1:06 PM Adrian Farrel <adrian@olddog.co.uk> wrote:

> Yeah, thanks Robert.
>
>
>
> Actually, removing the comparison with other protocols is probably wise.
> This is a document describing how to do stuff with SR. In that context we
> don’t need to talk about the benefits or limitations of other protocols.
>
>
>
> To your 3209 comments: I believe that **some** implementations have
> pushed the “reservation” into the data plane so that in-network policing is
> performed to conform data flows with reservations or, at least, ensure that
> the parts of any flow that exceed reservation are treated as best effort.
> But this is an aside to the discussion of the draft at hand.
>
>
>
> I think that the document should note that the SR control plane does not
> currently have the capability to make reservations (in the control plane)
> at the network nodes. This can be achieved using a central controller to
> keep tabs on all resource accounting, and it could use a southbound
> interface to install that information in the (management/control parts of
> the) network nodes.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* 31 January 2021 00:46
> *To:* Adrian Farrel <adrian@olddog.co.uk>
> *Cc:* James Guichard <james.n.guichard@futurewei.com>om>; SPRING WG <
> spring@ietf.org>gt;; spring-chairs@ietf.org
> *Subject:* Re: [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> Hi Adrian,
>
>
>
> Just to make sure my point was correctly understood ... I am not
> questioning if either data plane or control plane resource reservations
> should or should not be done for SR.
>
>
>
> What I am questioning is that the draft says:
>
>
>
>    When
>    compared with RSVP-TE [RFC3209], SR currently does not have the
>    capability to reserve network resources or identify different sets of
>    network resources reserved for different customers and/or services.
>
>
>
> The crux of the matter is that RFC3209 DOES NOT reserve anything in the
> data plane of any network element while this spec clearly intends to.
> RSVP-TE keeps all reservations in control plane counters only.
> Constrained based path computation/selection happens based on those
> control plane information. (Yes nearly 20 years after this feature shipped
> I am still meeting people who believe otherwise :).
>
>
>
> So to start I recommend we remove any reference to RSVP-TE as this is
> purely not applicable to what this document is trying to accomplish.
>
>
>
> I admit I did not follow all the recent advancements in TEAS nor in DETNET
> as far as actually reserving data plane resources in data plane for some
> traffic types. If authors want to build a solution with that - by all means
> green light and full speed ahead - market will decided - especially when it
> will really understand the cost :) But let's make sure the document is
> crystal clear on what building blocks it is talking about.
>
>
>
> Best,
> R.
>
>
>
>
>
> On Sat, Jan 30, 2021 at 11:20 PM Adrian Farrel <adrian@olddog.co.uk>
> wrote:
>
> Thanks, Jim,
>
>
>
> I’ve been following the enhanced VPN work in TEAS and I see it as a key
> piece of the network slicing work.
>
>
>
> It’s time that we had some protocol solutions that serve the VPN
> framework, and this is a suitable starting point. I like that it is not
> specifying additional protocol widgets but has looked at what we already
> have and is pointing up ways to use those tools to deliver new function.
>
>
>
> I see Robert’s point about the resource reservation aspects of traffic
> engineering applied to an SR network, but this is not an insurmountable
> problem. The question might be asked, “Why would you want to do that?” but
> that is a question that (as Yakov would have said) the market can decide.
> It seems that there are a couple of vendors and a couple of operators who
> have an interest.
>
>
>
> So I think we should adopt this draft and see whether we can turn it into
> something that has great utility.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *James Guichard
> *Sent:* 27 January 2021 11:47
> *To:* spring@ietf.org
> *Cc:* spring-chairs@ietf.org
> *Subject:* [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> Dear WG:
>
>
>
> This message starts a 2 week WG adoption call for
> https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/
> ending February 10th 2021.
>
>
>
> After review of the document please indicate support (or not) for WG
> adoption to the mailing list and if you are willing to work on the
> document, please state this explicitly. This gives the chairs an indication
> of the energy level of people in the working group willing to work on this
> document. Please also provide comments/reasons for your support (or lack
> thereof) as this is a stronger way to indicate your (non) support as this
> is not a vote.
>
>
>
> Thanks!
>
>
>
> Jim, Bruno & Joel
>
>
>
>
>
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
>