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

Robert Raszuk <> Sun, 31 January 2021 00:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 593C53A129D for <>; Sat, 30 Jan 2021 16:46:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UguY9rArblgm for <>; Sat, 30 Jan 2021 16:46:30 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 19C7E3A1298 for <>; Sat, 30 Jan 2021 16:46:29 -0800 (PST)
Received: by with SMTP id a25so15078701ljn.0 for <>; Sat, 30 Jan 2021 16:46:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Li+wpg2y9ee6q/22p6sltOhhjeO7eaggome9sv662vw=; b=HPpjVri0QImC1Cl4fdmgYqOWB+A5S3cb+JS/1sO3jlCgeqk9ViYl+hiBm6+HsPQqUP yRfoh2cwCpxGScJCxCaHWuvcyd8UCmgVn8XqkG76WgzdoOrEn32vBWDHgNf+LzYh97d/ IaWOq15p4t27u5Z+Of6/QN6oOdgpW5e0qd4ZePJ2VdTwQdzU/Idh2EY3BZG9mfxmDThL l+zrcw9+0r45Czicu6u2qvzHrnXVoEGpoKWlV5IOiLtti4J+avDrBtC2wQK9v/UbFMqY vckuTxv/rahK48NrRVDqQCDVC+Arf4P2ulKGdX4W4Oj7oqxDXqjhHEFWMi5p/v6kEDQP iIGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Li+wpg2y9ee6q/22p6sltOhhjeO7eaggome9sv662vw=; b=rohigQQoy8unX60pM12k3rU7A4svqaoEG/2GyPMr26PJhOePMVht4iLRfyb3jALPd+ kMcYygznEiks8p/AJFeLE6nyyHrKi08W/8rM7PdUr0q1RM4krTXaZo0vra/BBflFNU6P fwKsd0DSikFaHEz9PSdWl8ZvP3v4g1a5/EfcbqdrtDBkSwVQ9BvGWZt9/lXRwdymTkrg N9MJ0nKxNGjsfTuIgi5Rm2bZ+DrQywfZGJllQqY4OeYLiAE8mUMgw++8fjjNHjlI/b0z J8nTtP2KnVn5dLLkWWIwWJNTLm0kh6F5cd/NRHzocWov/FE+ohucpqGqTPFVutdI5Ur4 Q9bg==
X-Gm-Message-State: AOAM532aiDWY2QLDN6r4CiOQtVEkmwMh0VmeRDd3NopScNR/mUMIA1tA 8Y2ycQmgR4EwiQiruqCEkdM6zNYKpveobWWbUuwGDw==
X-Google-Smtp-Source: ABdhPJyxoONIx/YMylRJ9y4P4A4Bmxwd+eWfcON3DCCQi0ssrqgcZTnxwjxcoPPHDJ1ad5u3UqyBtKF9Eq64mk1E7eE=
X-Received: by 2002:a2e:3317:: with SMTP id d23mr6529115ljc.199.1612053987990; Sat, 30 Jan 2021 16:46:27 -0800 (PST)
MIME-Version: 1.0
References: <> <05b301d6f756$1485ced0$3d916c70$>
In-Reply-To: <05b301d6f756$1485ced0$3d916c70$>
From: Robert Raszuk <>
Date: Sun, 31 Jan 2021 01:46:17 +0100
Message-ID: <>
To: Adrian Farrel <>
Cc: James Guichard <>, SPRING WG <>,
Content-Type: multipart/alternative; boundary="00000000000050309505ba279152"
Archived-At: <>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 31 Jan 2021 00:46:32 -0000

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:

   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.


On Sat, Jan 30, 2021 at 11:20 PM Adrian Farrel <> 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 <> *On Behalf Of *James Guichard
> *Sent:* 27 January 2021 11:47
> *To:*
> *Cc:*
> *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
> 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