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

Tarek Saad <tsaad@juniper.net> Tue, 02 February 2021 04:48 UTC

Return-Path: <tsaad@juniper.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 3D9223A1391; Mon, 1 Feb 2021 20:48:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.358
X-Spam-Level:
X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=JfSt3rT8; dkim=pass (1024-bit key) header.d=juniper.net header.b=bAOE2ewV
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 eho0amTh_Vga; Mon, 1 Feb 2021 20:48:27 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 07CA53A135A; Mon, 1 Feb 2021 20:48:26 -0800 (PST)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 1124hvvL027283; Mon, 1 Feb 2021 20:48:24 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=103IRxB7YQnzTamekd2xEP6TE200kiAjMDmvAhcl6OE=; b=JfSt3rT85ABt2vR90xXFEgF9xJIKLhy4hq7zsHSVxtao6Kkfj2mwQ+3aI8K5kOsA+MgT Ir34wme+zOFXrNiUSElDyaxQWcClrA2kvrHDt5OI+EU+CUVwcf7PAMdKQDblGPtjyP9a WwQgMOyEJkPu5CTqMW9ijumEjWXH00X5ebuDZBpAG/Mfza+UuBaR16EijJVMAb41iN9J awhhLFGlbb9cSlsiFDValuGS9lzTKe/JQIMkgSSlenjBUiAvulznKkWKbnxLqEbm3odO 2MLKd8/Atq+AO35In33HEiSGOYRA+dONqyF905Q91JxTuq7V4g2ugUeT6Yt6Vs6UV34j 8g==
Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2101.outbound.protection.outlook.com [104.47.58.101]) by mx0b-00273201.pphosted.com with ESMTP id 36d7f2krtd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 Feb 2021 20:48:23 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZK4THi1PdiT8XNH+9K/NHWh5SJrOkNlARdpa5f0GWUl70mh3eu/BAHXYSiPmRSFG1EkvpQ1SCo3Tq6FBeTFmYy5wFQdpjEv3Ex4hU98J3RcjHtuF2AtqrsllSJclfQvmhr/+6zoFy61aP+bYnfy1v/Mzcaoja8rZjF2HVCjSOuzg7q73qjL5ECktpCgPsnzuoi1dMlqPYZ83tcbmpt2fy+cSY7NJY9PZ4MT8topNGDw7C2Axl981SZYE5pVDqrEOGlT3Pcmed58sfBBZ1Pm3dlj25UwqpNFfZkJetb5e43xGGxodONEjNKu8U5+TtcluF5mzUf1sysApKZ8Qk7vq0Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=103IRxB7YQnzTamekd2xEP6TE200kiAjMDmvAhcl6OE=; b=cUdZolIIPMuGdJ7aBQ+ZuNQrUXkk3Ik672U1XUf3Su3zcnaYVRuW48lCY6jdgxR7vM4B2CzffxREwCN2/CoGqF/mLiS6ZuCL/SbK6kdMoluLOokMN97DLgNonsFz53UYZVtl0IFf/tIDcsO7JPLMHYV4NpimMdci1qyUCGg9ppMkvWwNe+x+yua1BkzmQzEXAE8N61yGNdDpHtD0wwBksEgjENMAjSsk5dno//HPRZOwOqGKETQn2UQHXlO/wOCwBQGQLCsUNaO0Un14wW9RRKll5gDA0Y/9/Go/2npmAVblPXNOnNLFmO6gtQ3X+s/C72rtMZM8/DrQjTlSOleABQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=103IRxB7YQnzTamekd2xEP6TE200kiAjMDmvAhcl6OE=; b=bAOE2ewVgkSL+hmAarAQhgLt6qC+0OlGxzlF3nwKsnMEzeW7oSy/PUMywJCZTDSaP0XANZiJKOvi7eYSO+9ll2tOeUhwynQDfmeiZfJ7qryYKpSEf1oAEe/FXc6AGU0xcNQuVMzWP1ybgwjGOAwtcNJr4LqO9gfn1Lqg5qX8ZqI=
Received: from (2603:10b6:a02:85::18) by BYAPR05MB5478.namprd05.prod.outlook.com (2603:10b6:a03:1a::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.8; Tue, 2 Feb 2021 04:48:19 +0000
Received: from BYAPR05MB4136.namprd05.prod.outlook.com ([fe80::cd99:e95b:705c:2420]) by BYAPR05MB4136.namprd05.prod.outlook.com ([fe80::cd99:e95b:705c:2420%4]) with mapi id 15.20.3825.017; Tue, 2 Feb 2021 04:48:19 +0000
From: Tarek Saad <tsaad@juniper.net>
To: Robert Raszuk <robert@raszuk.net>, Lou Berger <lberger@labn.net>
CC: James Guichard <james.n.guichard@futurewei.com>, Adrian Farrel <adrian@olddog.co.uk>, SPRING WG <spring@ietf.org>, "spring-chairs@ietf.org" <spring-chairs@ietf.org>
Thread-Topic: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
Thread-Index: AQHW+R6fN78dKu1qokmhE0z4/frS7A==
Date: Tue, 2 Feb 2021 04:48:19 +0000
Message-ID: <0BF4F050-823F-4708-B6D4-5A851F53A8FC@juniper.net>
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> <CAOj+MMGaWXFFFmc9CabGF4gRL-r_v2aab9hvQNOqAF5iSSvS_g@mail.gmail.com> <BL0PR14MB377920A3EF085308CF7545ECC3B79@BL0PR14MB3779.namprd14.prod.outlook.com> <CAOj+MMHjkc8__0HSDAJ-t8DDaDdGMrGCvUbSzQEtOcfbpN6RmA@mail.gmail.com>
In-Reply-To: <CAOj+MMHjkc8__0HSDAJ-t8DDaDdGMrGCvUbSzQEtOcfbpN6RmA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=43cb173d-9d29-4f79-b6e0-dbef30f79348; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-02-02T04:31:12Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true;
user-agent: Microsoft-MacOutlook/16.45.21011103
authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [2607:fea8:e320:6800:5060:6a44:9d2f:7443]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: e997e30e-3e78-4459-ed3c-08d8c735c32b
x-ms-traffictypediagnostic: BYAPR05MB5478:
x-microsoft-antispam-prvs: <BYAPR05MB54782F29C26728F918683263B7B59@BYAPR05MB5478.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ksmXyFDQ/VU/CUmYWVWWdy8Q8XZKprLkbXoxaNDvl50iMsnhZOGOogXgR/7lbrBk/fCi0/HRvk7z0b5eHakdtsaWKALaPNGzH6/FqbEb6OSvUylQQtQR5m4ZT8vr/7a4s32hThe8TR7ARvpwVcwFQS6qwXOyYFgGD8QD23Is75F8vAC1pPBIeK/ekXpeRCmj+1gBqTqYud85X/eM/TL9BJJOWMuWJgJB+31fJe5ehrqQVkfiesyeUDen7LMkmEXFLSyzs3nRZS+SZR1F3XNEm6GqEstDJb2w//oQxBKrT9leSwghN/9Y8MoT8yfMm8I0MAEnPxGJQlhYRjw+5HPwANzxckDa+OThaNwQfDY95E3cVweDlz1Qs5MieQ+yM4lAR8vS7AvMnIflMkCHFp5yRhXmh7UqcuWhxaAk+DXE5RplxM5cZfEYPQ7Vdu60ccihEA/Ods3v1QirNX1ZRh7Zxagdsjtd0aQzD3pZRy1/HJ8NBWgG186OjbpHjxfBvMJOUKplHYPg4QxOErH9FO1bob5aw3svScggHEoT3R84qwnk6sOUwWAqDeV8JQgpXLd3L8pSt2wIxkHX8WWa3zk/DXw6yB64qr0Fwj14W2WUkNekttGIfxMgrF2c2PGQzxz7pUjYqm7odsUGcYofKyOQjuvLT++b7sO5CnMW2hkgCVXdzuKebC6xxepb3Y0fO5O9
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR05MB4136.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(396003)(39860400002)(376002)(136003)(71200400001)(6486002)(478600001)(76116006)(5660300002)(86362001)(83380400001)(186003)(8676002)(54906003)(53546011)(36756003)(316002)(33656002)(66476007)(8936002)(6506007)(66946007)(66446008)(4326008)(6512007)(66556008)(2616005)(110136005)(2906002)(966005)(166002)(9326002)(64756008)(160933001)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?akx1a0lCRm1TeHYzU3pSaHpRampEcmRlaHNUZjhBbXZFNXlGL2tpMDhuV2hm?= =?utf-8?B?b3ZzRDdZWjUycDJuN0dUSFBhTFJqRWk4OXRrSHpDbU9RL1NmTUNkdnBkRVJG?= =?utf-8?B?bEtXTDNkSk5RbGhFbnlsTmVnSSt0Ym5USTNwZ3FBcEJaWnZyUkZ0dkE4NWsy?= =?utf-8?B?eUh5ZHp3TW9XUWtnbmJBcjZJd3JQeEFDL24yTG1SMnZUb0dXYk5kc21QV0hV?= =?utf-8?B?ZjQ3UFNGdUdkUFZpblpaUmIwMzlSa3c3Uk9WUFdaS3RoWHpnTGxzWldGKzlr?= =?utf-8?B?ZVBoYktVTnE0NS9Jc3pyNGkzcldCRnp0SGl2SXJJVlo1T2lHcHpyZXFuMWJQ?= =?utf-8?B?Sm12U3QrNHZVVzdoaFVuNlJDekpQRitiMnk1VHd0RmhkQU5jNWRCOWl4MHVo?= =?utf-8?B?czRmUFlGMTZ6U0dkMk1QNk81UlRPaG5mTWgrcFo5cGVyUDRMZnlJdVBHdzdv?= =?utf-8?B?NGF5OXRlSFpoM203UXZQK0xWK0NEeUlQNFgrSStQYmxlRExveisxMnMrem9K?= =?utf-8?B?Nm0wUVpsSFFnYUhHdzV0RGVUcGgvUWdHVll6M2Y0NkMrWktMZVRHN3Y2bjNi?= =?utf-8?B?SENzUnhaMHFZRkZHNkd0SWtmc3g3S1RrTXFzSmJhQ2VEdU9Qa2s2ZW1mVE9C?= =?utf-8?B?SG8rb2FyUVlTSmxlV1pFVGgwdmNnSDJ2bTk0K204SldjZE55a2RDajVKcWQv?= =?utf-8?B?UTJXM1drOUVsS1FRN3NhOFNLcVIyMlhUZWxsTUswUURvTzJGZ1NTRlZLNERh?= =?utf-8?B?dGpLMWVHOFlTaFZXOVEwMmVBSFo0OVZ3MWVmV3J0aWlMdW9JWXFBVjlDb3E0?= =?utf-8?B?MjBpVHZOTDhTVExBdW1uSUxJNnl3QVhYOGVvczh6dml1MEpZWTBuTW9Qelk1?= =?utf-8?B?SG13aXNoSFhQTDBCYW81M2l3VEpKcXQxTTFGSWh4cmhNNGtobVd1OWNDNnFi?= =?utf-8?B?UkI2R0FmVW5NWWd1R0dweThlUEk0L09MYldYODIrZXh2NlhrNWVscGhpWTVU?= =?utf-8?B?VjUyQmphOWltZk9tYjhacE9wdENOaGhrK1B3VTVsRSt3Umo2Y0l2WDZISjhj?= =?utf-8?B?dVh2d0Zlb2dWcUhNSzYxQ2lZQWxRaDFQNy9JbFNKVmY2WjU4VEpLNC9WVGY3?= =?utf-8?B?ditnOFRnd0RGamJnallGQ2pJa3d6SDdsK0luSDNiS0ZRQ0cvekJETENmeFdk?= =?utf-8?B?Y0xqSncvNElKcERtU1pjdldKZS9aVDJ6UUJaZHBhUUhNdTRLYlo5RGNtV1Rk?= =?utf-8?B?M1R3YUlnN05TQlRkbTVxS2swTUdoM1RMRGVBYUtoUVg5UmR2MGpHdERtekR1?= =?utf-8?B?LzFBdnoyTDNBeGdLM1M1MDNWa3l4ak5wKzEyNnpPdnpxNGN4cXhRUkVRenE1?= =?utf-8?B?cWJMak5IWWZiQU9kU29oTVdIWm9jc2dKMURPR3J5N1lJM3RVaWdHNG9JRDNC?= =?utf-8?B?ZDZiVHR3SnRQVkI0OHlGZkJvb3JrOS8yVU1hNEo0WXZkOUMvODl2RTRnUEJM?= =?utf-8?B?bnBrTEdFM3ZuZndIaFpMbTVvQUpEdUZoRlRCM3JYQllkcTFLL0hlYndML1Rr?= =?utf-8?B?NVRDZz09?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_0BF4F050823F4708B6D45A851F53A8FCjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR05MB4136.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e997e30e-3e78-4459-ed3c-08d8c735c32b
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2021 04:48:19.3395 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 2SYJBKvf0zkPWKk8QDI+1UFsiuW+R8e+E2VH1Lf3UDK+QuLjJ0wCMTFEPxQoaZRRWpv9Tou8wU5btld30AcHrA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5478
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-02-02_03:2021-01-29, 2021-02-02 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 bulkscore=0 mlxlogscore=999 adultscore=0 mlxscore=0 clxscore=1011 impostorscore=0 malwarescore=0 lowpriorityscore=0 suspectscore=0 phishscore=0 spamscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102020032
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/5WwBRSWbxrlqjS_7XiHHyz2yAlA>
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: Tue, 02 Feb 2021 04:48:30 -0000

Hi Robert,

RFC3270 talks about two models for reserving resources for LSPs in a MPLS Diffserv network (namely E-LSP and L-LSP). While former is the more popular implementation amongst vendors, implementations of the latter exist for some vendors – i.e. L-LSP which will do per LSP resource allocation.
I agree in non DS-TE deployments, most RSVP-TE implementations I worked with will just do control plane reservations/validation for LSP path placement. However, for RSVP DS-TE deployments, there is still resources provisioned per class in the dataplane – this is to ensure the differentiated treatment for class traffic on shared links.

Along those lines, draft-bestbar-teas-ns-packet extends this and proposes ability to apply QoS treatment on slice aggregate traffic that traverses a shared resource/link. The packet will need to be identified as belonging to the slice aggregate. For this, draft-bestbar-teas-ns-packet proposes that a separate field can be carried in the packet so it can be used to identify the slice aggregate the packet belongs to.

Regards,
Tarek



On 1/31/21, 12:24 PM, "spring on behalf of Robert Raszuk" <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org> on behalf of robert@raszuk.net<mailto:robert@raszuk.net>> wrote:

Lou,

If you mean ingress policing that this is not what I was referring to - however for most if not all shipping RSVP-TE aka MPLS-TE implementation I am not aware of any per TE-LSP data plane resource allocation in the date plane. Keen on being corrected, but with facts and proof not with claims and statements.

If there are any please kindly enumerate what resources are being reserved and how (ie. what RE/RP tells LC to "reserve"). No need to reveal the implementation name(s), but if you provide a detailed pointer it would be helpful.

Cheers,
R.


On Sun, Jan 31, 2021 at 6:10 PM Lou Berger <lberger@labn.net<mailto:lberger@labn.net>> wrote:

Robert,

I'm amazed that after all these decades of RSVP and rsvp-te implementations there are those who still state that there is no resource allocation or management in the data plane. The RFCs are quiet on the topic of how reservations are managed/enforced and it is up to the vendor to choose what to implement and the user to decide what features are important to them, i.e., that they are willing to pay for.

While it is certainly true that there is a well-known vendor that doesn't do much in the data plane and there are some who wish that this was the only choice, there are certainly TE implementations that do manage/allocate resources in the data plane to match reservations established via RSVP or more modern sdn-te techniques.

Lou

________________________________

On January 31, 2021 8:08:31 AM Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:
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<mailto: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<mailto:robert@raszuk.net>>
Sent: 31 January 2021 00:46
To: Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Cc: James Guichard <james.n.guichard@futurewei.com<mailto:james.n.guichard@futurewei.com>>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; spring-chairs@ietf.org<mailto: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


Juniper Business Use Only