Re: [spring] Dynamic Proxy in SR service programming

"Francois Clad (fclad)" <fclad@cisco.com> Sun, 26 July 2020 19:32 UTC

Return-Path: <fclad@cisco.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 A974A3A13E4 for <spring@ietfa.amsl.com>; Sun, 26 Jul 2020 12:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.62
X-Spam-Level:
X-Spam-Status: No, score=-9.62 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=J0hXZ/2p; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=N4ctdmqg
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 HE2IT8qOpu1h for <spring@ietfa.amsl.com>; Sun, 26 Jul 2020 12:32:44 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77DE73A1361 for <spring@ietf.org>; Sun, 26 Jul 2020 12:32:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7440; q=dns/txt; s=iport; t=1595791964; x=1597001564; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=G57URZrBVCSyjspMer1LAds5/f8t5ww/TWybifybw54=; b=J0hXZ/2pE3c+XAJAP9/RWJp3g3hjXCVOG/H1S/6ra1L3188+Fos6+h7I a6pFjxR92xSYG5x9mpIWdoihWbmA+DEvAq/05p7VCSpxdcc4vXRpW7N6d 01d4jNSwEAySUpyEAeKoZ7g4jo4Gah52LLW9rUPKQ61HmcsitD/mYBXqB c=;
IronPort-PHdr: =?us-ascii?q?9a23=3Asngd2R1e0ZaOicJksmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWFu6dvi1LNXYzf8/9ejazdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZVrfpn276SYfAB?= =?us-ascii?q?O5Pg1wdaz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0R?= =?us-ascii?q?DO5HBPfrdb?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYBQAd2R1f/4kNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUlEHb1gvLIQ0g0YDjVWYYYFCgREDVQsBAQEMAQEYCwo?= =?us-ascii?q?CBAEBhAhEAheCCwIkOBMCAwEBCwEBBQEBAQIBBgRthVwMhXIBAQQBARAREQw?= =?us-ascii?q?BASwMDwIBCBgCAiYCAgIlCxUQAgQBEiKDBAGCSwMuAQ6hDQKBOYhhdoEygwE?= =?us-ascii?q?BAQWFJRiCDgMGgQ4qgm2DWYY3GoFBP4E4HIIfLj6CXAEBgSoBEgEhFxWCajO?= =?us-ascii?q?CLY9OgxKSK5BjCoJejxCKXgMen2SSFp8aAgQCBAUCDgEBBYFqI2dwcBU7KgG?= =?us-ascii?q?CPlAXAg2OHgwXg06FFIVCdDcCBgEHAQEDCXyPIAEB?=
X-IronPort-AV: E=Sophos;i="5.75,399,1589241600"; d="scan'208";a="518145997"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Jul 2020 19:32:43 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 06QJWhnr025539 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 26 Jul 2020 19:32:43 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 26 Jul 2020 14:32:42 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 26 Jul 2020 14:32:42 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Sun, 26 Jul 2020 14:32:42 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dvs5G18CHlaXvFuxFOZlQCjmp3AEpSyuJzikM6QagWWjSnCgK2TFRCIcCpLew0iMQI5e2iqlQd3ECmUdaVdxagDGPNM59S44m+pxq5xQg2/Fgqgh2DwZCmFY523QMl/G5fVoKzmaXvdI3XyrDxkA86gz0EkA2E6M9Ep0aHt4V9vF0APeLWVjP+hSI+HA1v6Fw43xEkxaOZmI2qflTgDOtmkmsooXNQeh+SQdurnS5RxEoalvb4xdHXVOmjFtmqSOI60N5aqVou5RTg70zHpeGayZ1NxKts+tGD2gzV2VRx08AM9UXj01PWuMPUl0YeXU1kceIsyXS/DDjXX1PzPiiA==
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=G57URZrBVCSyjspMer1LAds5/f8t5ww/TWybifybw54=; b=lwT2Ms6q2kE/EKGxh6rpNTXSQcI2UqfbDWAhz6zoz0Haiz1vZX1VKEoWlJ6/M2AMeFf9IvoE22riiusoL0KNdQ9rMYsjyCVHd/BDLZEyl2cJ/hv1uXjfDqS0LBmdZdNFhjnsyBEq/Zm+BErNeA7Y/WcBsW2oKc4AUL7HzSTTBoCj9z+eaTzDhLwiZdU1trzxHGswEOsLdrMLnWA0DEgro28W0QlQDP0++kdt/uZ0HkRU0kTug6ydKeH+9ZWMVWyUccVQzkcDIHKRPRFiQB+hzhxIpwLPa0n9MtMQIcilclhqBcXRG2J5/YnHZ/k0onACkIoFk2SQCOeRWZF0XfapyA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G57URZrBVCSyjspMer1LAds5/f8t5ww/TWybifybw54=; b=N4ctdmqg0cTAsfAFOd+5wkIqqTUiNbsbbatiJBLmBrFrLZKUjfg4zYJ0hdfHK1MuFNSdl2IGGUCQkli57m+NRfSxCNamZKpzZy/rjS2SLW6wqRZS4+nGgPclP4fM6XOtciwQlkIwWLPpj3ODTOu1qVJ0AAyuD7Ncv2GO/jhjTxA=
Received: from DM5PR11MB1979.namprd11.prod.outlook.com (2603:10b6:3:10b::19) by DM6PR11MB3050.namprd11.prod.outlook.com (2603:10b6:5:71::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.23; Sun, 26 Jul 2020 19:32:40 +0000
Received: from DM5PR11MB1979.namprd11.prod.outlook.com ([fe80::791d:5c52:f954:f85c]) by DM5PR11MB1979.namprd11.prod.outlook.com ([fe80::791d:5c52:f954:f85c%10]) with mapi id 15.20.3216.031; Sun, 26 Jul 2020 19:32:40 +0000
From: "Francois Clad (fclad)" <fclad@cisco.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Stefano Salsano <stefano.salsano@uniroma2.it>, "spring@ietf.org" <spring@ietf.org>
Thread-Topic: [spring] Dynamic Proxy in SR service programming
Thread-Index: AQHWYqvz9VvWn1pEgEWEQe6/xUc086kZAucAgAAHAQCAAVlTAA==
Date: Sun, 26 Jul 2020 19:32:40 +0000
Message-ID: <421B04D6-14B1-4A46-A2B9-93B999A5424F@cisco.com>
References: <9175c5f7-0f1a-38db-55e5-0a0255a43622@joelhalpern.com> <acffc87a-7918-5b06-8bc5-a36fc175ba76@uniroma2.it> <47f13681-caf9-64ed-8ca7-604f4d552983@joelhalpern.com>
In-Reply-To: <47f13681-caf9-64ed-8ca7-604f4d552983@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.39.20071300
authentication-results: joelhalpern.com; dkim=none (message not signed) header.d=none;joelhalpern.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a01:cb10:43:4400:65d5:2221:f9c5:145a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e5a9e0f0-3091-4949-ebc2-08d8319aa94f
x-ms-traffictypediagnostic: DM6PR11MB3050:
x-microsoft-antispam-prvs: <DM6PR11MB3050BDFAD1EB041526601AE5AC750@DM6PR11MB3050.namprd11.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: ZHDMnPat4Ii5ZI3m+vfW52f++2r8+eWrakDO7rzdYgN+xjfHgcTyRoToB7zvTojiTZ2wgUlFeutxF2eNf6kQbOQP1zv6F61LLMrfK0ctYcma5wBM8cztJYLe8Ee2+lQLEQDXvxxYc1I8g4ULzNh8hHn8Z31DrV7Kbg4/lo2Pu1X7L4b0/8IMY7TLX44w3LbjPRaJJadCNQab/8ig4vPDDo7yYYT4Gw5XEXNGUAqnng/J92GJ7LcYbRXXAbQwvZWphW2mwvB+UOHJaOIgZjqLdS9sBFcUmdQn+hxPNgRVTOh6ysGciQjat99PXkgmyn7voWauiOKgqIuFO9M/H0h37M/LsbrU5FsiX61c0izafk5LkEKqMuWKQtzmh71dwS8V7MTNB3rYe20glY9nbPpNlg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR11MB1979.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(136003)(396003)(376002)(366004)(8676002)(66476007)(66946007)(71200400001)(2616005)(86362001)(33656002)(2906002)(110136005)(83380400001)(8936002)(5660300002)(186003)(64756008)(66556008)(66446008)(316002)(36756003)(6506007)(53546011)(91956017)(6486002)(478600001)(6512007)(76116006)(966005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 3T1pD3gM2koohFFt5U3qgv1WRjnahf+3RKPpeW6DFrvP8v8Ph3qfSlkoTGg8AfPvafJ1I6Y0y7OoxGWcnhkeAyw3CyQo99QfO6R9E0baV/6fmdmBdS7byxG2RCCBFVJup9ofJD8CcUAUwmSdKR/vPUjbiZ6UXFpfNgn/Cj+g9ZQ9QYoyypDtjNzPsco2UPUZiQTJ8aimBSbyESuX4oo3TOwj9N/RXHJyds7EeFQ+C2FAnKAgMJRVDmgJ2oKLnjMD/cnSlalmHuDokQ+bviXTOXgzuY+LtoFlk9luE/gjHGx9pwbPCgAfOhNTP/xpuckvx7jZ4BeYd92ndBF1gWhElg95LRad9wLHVr0UQlALDuJ4YWW//RlXmqFd4neDHuy7dMA6E4lwgyZP+nI3IbNT147MyzfzqgFjDBDeuEeWXNYC73rmIr/gsgpw1axVDbZwZvCVUEkOf4Sd2qwhduPMXraCzwkJIyh23XF+HxsdFbJh2tMtV/NMwVhFusb+6Wh500OKPIHI9lxxbf3X2alFrhomLB/UinzzqbV1csTTQSA=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <ACBC7ED21CC4B249916B517FE8C936DC@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM5PR11MB1979.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e5a9e0f0-3091-4949-ebc2-08d8319aa94f
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2020 19:32:40.7047 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: tCExx7n0ncX+mP07BCwZ3Y1sKoopTIXCvuZUyIr7vu8gvtSoKVk+0jBplbB9SVAC
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3050
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/p9IoGe-HtKVnYZQFG11j7CoBbPw>
Subject: Re: [spring] Dynamic Proxy in SR service programming
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, 26 Jul 2020 19:32:47 -0000

Hi Joel,

Thank you for your email.

At high-level, the dynamic proxy combines a caching mechanism with a mapping scheme that associates cache entries to packets or flows.

There are many possible mapping schemes, each has pros and cons that make it more suitable in some environments and less in others. This I-D describes a simple one, which is interface-based (or VLAN-based), and implies that a dynamic proxy SID is used in a single SID-list at a time. This makes it particularly suitable for container-based environments, where VNFs are spawned on a per-SFC basis.

In different environments, other mapping techniques could be used, such as those described in draft-song-sfc-legacy-sf-mapping.

Cheers,
Francois


On 26/07/2020 02:57, "spring on behalf of Joel M. Halpern" <spring-bounces@ietf.org on behalf of jmh@joelhalpern.com> wrote:

    Thank you.  That does clarify, and it would probably be good to be 
    explicit in the document.  (The restriction makes sense, we just need to 
    be clear.)

    Yours,
    Joel

    On 7/25/2020 8:31 PM, Stefano Salsano wrote:
    > Il 2020-07-25 19:49, Joel M. Halpern ha scritto:
    >> <chair hat off; speaking only as an individual member of the WG>
    >>
    >> In looking at the description of the dyanmic proxy behavior, I was 
    >> reminded of a problem that the SFC working group wrestled with and 
    >> never resolved to our satisfaction.  (In the SFC case, since we were 
    >> not specifying the behavior of the proxy, we could leave it to 
    >> implementors.   This document seems to be more specific.)
    >>
    >> As I understand the draft, the dyanicm proxy for a non-SR aware 
    >> service function can be handling packets subject ot multiple service 
    >> policies. That is desirable.  These separate policies will have 
    >> separate cache entries.  Also good.
    >> But as far as I can tell, the re-attachment of the cached header to 
    >> the returned packet (from the non-SR aware SF) is done based on first 
    >> come, first cache.
    > 
    > Hi Joel,
    > 
    > I'm speaking as an author of draft-ietf-spring-sr-service-programming-02 
    > (but I do not know if my opinion is agreed by all the authors)
    > 
    > my understanding of the dynamic proxy scenario is that a given "non-SR 
    > aware service function" (aka "legacy VNF") can be associated with a 
    > single Service Chain at a given time
    > 
    > so you can dynamically change the Service Chain by sending a Packet-2 
    > with a different SR policy with respect to Packet-1, but this is meant 
    > to change the Service Chain for the following packets of the flow, 
    > rather than to operate on a packet-by-packet basis
    > 
    > you are right that operating on a packet-by-packet basis leads to 
    > inconsistent behavior!
    > 
    > In draft-ietf-spring-sr-service-programming-02, the following limitation 
    > is associated to the static SR proxy, but it also applies to the dynamic 
    > proxy:
    > 
    >     However, a static SR proxy
    >     segment can be used in only one service policy at a time.  As opposed
    >     to most other segment types, a static SR proxy segment is bound to a
    >     unique list of segments, which represents a directed SR service
    >     policy.  This is due to the cached SR information being defined in
    >     the segment configuration.  This limitation only prevents multiple
    >     segment lists from using the same static SR proxy segment at the same
    >     time, but a single segment list can be shared by any number of
    >     traffic flows.
    > 
    > This is he description of the dynamic proxy:
    > 
    >     The dynamic proxy is an improvement over the static proxy that
    >     dynamically learns the SR information before removing it from the
    >     incoming traffic.
    > 
    > Maybe it would be better to explicitly clarify that the same limitation 
    > of the static SR proxy is applicable: "only one service policy at a 
    > time"... the difference is that you can change this association 
    > dynamically, e.g. in the order of few seconds but NOT on a 
    > packet-by-packet basis
    > 
    > hope that it clarifies...
    > 
    > ciao
    > Stefano
    > 
    > 
    >> What happens if, due to differences in internal processing, packets 
    >> from different service policies get swapped in time.  So packets go in 
    >> Packet-1, Packet-2, but come out Packet-2, Packet-1.  The text seems 
    >> to result in the proxy reattaching the SR information to the wrong 
    >> packets?
    >>
    >> Am I misreading the text?
    >>
    >> Depending upon ones, reading, this may apply to a case where a single 
    >> device is service as multiple static proxies for a single non-SR aware 
    >> SF.  It was not clear if that was intended to be allowed, but if so 
    >> the same issue would seem to apply.
    >>
    >> Yours,
    >> Joel
    >> <chair hat returning to wherever it belongs.>
    >>
    >> _______________________________________________
    >> spring mailing list
    >> spring@ietf.org
    >> https://www.ietf.org/mailman/listinfo/spring
    > 
    > 

    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring