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

Adrian Farrel <adrian@olddog.co.uk> Sun, 31 January 2021 12:06 UTC

Return-Path: <adrian@olddog.co.uk>
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 106BA3A0CB0; Sun, 31 Jan 2021 04:06:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.915
X-Spam-Level:
X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Jqxpzz463s6N; Sun, 31 Jan 2021 04:06:32 -0800 (PST)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D87F3A0CAF; Sun, 31 Jan 2021 04:06:30 -0800 (PST)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 10VC6Pj0022214; Sun, 31 Jan 2021 12:06:25 GMT
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D7D9D22044; Sun, 31 Jan 2021 12:06:24 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id C91A622048; Sun, 31 Jan 2021 12:06:24 +0000 (GMT)
Received: from LAPTOPK7AS653V ([84.93.31.76]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 10VC6N4S023318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 31 Jan 2021 12:06:24 GMT
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Robert Raszuk'" <robert@raszuk.net>
Cc: "'James Guichard'" <james.n.guichard@futurewei.com>, "'SPRING WG'" <spring@ietf.org>, <spring-chairs@ietf.org>
References: <MN2PR13MB42061AD1E295598F1F2726BDD2BB9@MN2PR13MB4206.namprd13.prod.outlook.com> <05b301d6f756$1485ced0$3d916c70$@olddog.co.uk> <CAOj+MMG4ObcXwCfE9f2yd4Nts4juguX5QO7Hje0TszUAM-62KA@mail.gmail.com>
In-Reply-To: <CAOj+MMG4ObcXwCfE9f2yd4Nts4juguX5QO7Hje0TszUAM-62KA@mail.gmail.com>
Date: Sun, 31 Jan 2021 12:06:23 -0000
Organization: Old Dog Consulting
Message-ID: <05e801d6f7c9$7f1184b0$7d348e10$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_05E9_01D6F7C9.7F130B50"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGPDWyPdOZKMreitsHnlsMR1NOhUQLP2QWhAY0BBF2qro2FAA==
Content-Language: en-gb
X-Originating-IP: 84.93.31.76
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25942.003
X-TM-AS-Result: No--14.420-10.0-31-10
X-imss-scan-details: No--14.420-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003
X-TMASE-Result: 10--14.420400-10.000000
X-TMASE-MatchedRID: 8HTFlOrbAtHxIbpQ8BhdbI61Z+HJnvsOBGwExtNOAA86ievrBsJv23fE zJW8WARr+FOJhZQihuErySg2QcGzB/UE/gV19jDjgDtJKYCns0Tu7w4HbIs/OKtxm12JYaHY1fc e4C9pfzKyR3POpjClmtcBziqkh+zlGgF/ZmvKfTqecgASc+pqBQoXSOLC5a44Vxk27EKh25ILHI LfupNIi4ErlAzUZVeAXl9v5CQ2BAFclopM/DKZPbIGMNfiwa5Nh4A8KRmrGe25IifwYL1+q4Lga 6by6q/l1TRrdVHWMtSKEi5WIFttz+w0HgGvyMQFsmly7ZcJ2RxIxFsMLu9ebLV5fSMRD1zqCX0h YHHH6QG/jrDM22faPJXX+I+PsjLTR0noGmyTNMsD2WXLXdz+AX5Lmbb/xUuaUaAaJmXc+cU/PJ8 p+RzsAQ7e7WIcWPbRW8S235kaguKeQz5UA/x898qtGqLtQ+lsvO2R6qeLYS8xpzFoCZKUaGkBwE Y/k+85TYj9r6V3iaUzLDHtH2pD0y/TUG89Otu1yAGbkGU4ZS6A5msho6TMYVSOymiJfTYXGVggQ kf1ACP2CIazwjfCzTxssdnRo9LtfLhnY32jLqqzdV9T3JcQSDJbFnUcIQJtK8VLPDcP9n75gc6a kIiNTdz+FvoB0agSvbDCimDYdUWHdRPQsQpSrAXGi/7cli9jBWX3vb5j1vKynk7TnYzMuokisBp QuGVeJ6TstuqB6zUuf2xxB7N99cMJX3UpvTQR/QrUTNJyjikZSo6PM4LsiiuGKh4AkqKVfxVG9d a4NceLPt/bZ02RYUu9b6yxSsh3/LBu6KSAbeaeAiCmPx4NwGmRqNBHmBveGtkvK5L7RXGw7M6dy uYKg4VH0dq7wY7u1GXgLTCXvD0qY06/y6o7eKPOVal9tOjqPVkjYTNUQc51/4DfStkZdZe0D7RC Z6LPDZe7oxYCpHgztjcvnt9UzhEDXc4qlqJKAzUYu7AE55E=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/ry6S3Glvy4xym47_mo-Pg2JP8Cc>
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 12:06:35 -0000

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>rg>; 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 <mailto: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 <mailto:spring-bounces@ietf.org> > On Behalf Of James Guichard
Sent: 27 January 2021 11:47
To: spring@ietf.org <mailto:spring@ietf.org> 
Cc: spring-chairs@ietf.org <mailto: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 <mailto:spring@ietf.org> 
https://www.ietf.org/mailman/listinfo/spring