Re: [sfc] Question on the Information of SFs in load balance
"Purkayastha, Debashish" <Debashish.Purkayastha@InterDigital.com> Tue, 11 December 2018 21:53 UTC
Return-Path: <Debashish.Purkayastha@InterDigital.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B64F1286E7 for <sfc@ietfa.amsl.com>; Tue, 11 Dec 2018 13:53:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Level:
X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=interdigital.onmicrosoft.com
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 TonnJUddKwbg for <sfc@ietfa.amsl.com>; Tue, 11 Dec 2018 13:53:06 -0800 (PST)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780133.outbound.protection.outlook.com [40.107.78.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8477127AC2 for <sfc@ietf.org>; Tue, 11 Dec 2018 13:53:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interdigital.onmicrosoft.com; s=selector1-interdigital-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sexfxovUlNQ+PU09nlhvWvRrbU99/r2ljHOnGBQzeKs=; b=ErXFqPsQVzCoQeoBqrW9oS4ei4631YmIYyBHXdLNoR2a3Dpd4xC4x4r+MfZyIyw+EnSeCVqzVMdbttRsL5q/rUeZiD/QQfazhHuu5441qeOkL6NIQJ5tzczuGuxySKEIFFcsbrt6EgPIqTOsh+DPBYFJ5T0PAoc96p7VEmY7Kmg=
Received: from BN6PR1001MB2161.namprd10.prod.outlook.com (10.174.87.28) by BN6PR1001MB2193.namprd10.prod.outlook.com (10.174.87.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.19; Tue, 11 Dec 2018 21:53:03 +0000
Received: from BN6PR1001MB2161.namprd10.prod.outlook.com ([fe80::3c39:5bc0:ab65:bef8]) by BN6PR1001MB2161.namprd10.prod.outlook.com ([fe80::3c39:5bc0:ab65:bef8%3]) with mapi id 15.20.1404.026; Tue, 11 Dec 2018 21:53:03 +0000
From: "Purkayastha, Debashish" <Debashish.Purkayastha@InterDigital.com>
To: "Trossen, Dirk" <Dirk.Trossen@InterDigital.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, "ao.ting@zte.com.cn" <ao.ting@zte.com.cn>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: [sfc] Question on the Information of SFs in load balance
Thread-Index: AQHUkRqNkuP5UVGbvEWOuWgfhqEDP6V5NTgAgAAdIACAAMATIA==
Date: Tue, 11 Dec 2018 21:53:03 +0000
Message-ID: <BN6PR1001MB2161BB661A7D23138700035085A60@BN6PR1001MB2161.namprd10.prod.outlook.com>
References: <201812111424468101520@zte.com.cn> <4fd618f3-690a-cb05-4c5e-813cb61cbaa0@joelhalpern.com> <DM6PR10MB277742A86C803C285781947DF3A60@DM6PR10MB2777.namprd10.prod.outlook.com>
In-Reply-To: <DM6PR10MB277742A86C803C285781947DF3A60@DM6PR10MB2777.namprd10.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Debashish.Purkayastha@InterDigital.com;
x-originating-ip: [38.140.198.106]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR1001MB2193; 6:1lY2oGF/aMQrLEkai9IoRe04iANdGmhiwwpFeJPEIoLQU3dlfES9EVoo/8mlKjNGaODMgwkjx22EY3OSD972INleFAzUgG3hvM0n5NJJKApE0s9ZdR0HXhIlBy2rXKUlJY90g513w4aNbqkEIjsACH0Hi0aLlg5HJWNdp1qtMMnJEKrQ2rnBv4ZwWi9ofTkQEX2P5S2UKT4Ka/Dq4JuYG7X3Ij1+1FpsM8GsXb+s0F3J7Ksqg4h6Upz3UW0PBvp4vwWZKheFrIx03dvhnr9OULB78nAPqPjdrF9gSz+Jdzgpn381ey9kFsSFnpqKwjHtNN/tXkH7/9RczvidvOg+/WFpAuTNpSmETn+pN3zhMUFiBVyxD8uz8+qDDBbqEVc85t1bodXuSiDn0n6lDUKZTrWrF9CfMbhinlYB/o2ZaiQmsgs6aRlCsuejScTRp155Aihpqzj6qEPV0aX0SSRrjA==; 5:jXnG5bAO2lbpjD5UMtVyTP7olJd3RD4fomuh9+YhHUho1ZyV/GUwAZaZgVLlgigyGxJqCBgcdRfQZP6VuOJbRXeMKMx4Aw/6uFxZQGY7Dyo8GZsZwQY9UgVATg1qsQDS5z+T/R9RVnB96JuCSEsTU8uwgLflX1LSWBVww31SgEg=; 7:xYrBhr7abONBBQ1DNf4QUPkbJvCdOeULLeiEtMzSjwYARiPNai+6olfLQtJFFU7AxgTOe9XHaiKc9EXQUj9DKdYkm8QV/F1R++F2qa/keI7sz/OpPFM1J6j3fZGST8QJVCGUEBEkxO9sYi2LlPGE9A==
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-ms-office365-filtering-correlation-id: 1224de3b-abf9-47bd-5b4b-08d65fb3068a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BN6PR1001MB2193;
x-ms-traffictypediagnostic: BN6PR1001MB2193:
x-microsoft-antispam-prvs: <BN6PR1001MB2193F67BD9ACDDF03403CDD385A60@BN6PR1001MB2193.namprd10.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230017)(999002)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231472)(944501520)(52105112)(148016)(149066)(150057)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BN6PR1001MB2193; BCL:0; PCL:0; RULEID:; SRVR:BN6PR1001MB2193;
x-forefront-prvs: 08831F51DC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39850400004)(366004)(346002)(376002)(136003)(199004)(189003)(13464003)(53754006)(66574011)(5024004)(33656002)(110136005)(105586002)(106356001)(14444005)(66066001)(5660300001)(74316002)(14454004)(256004)(305945005)(7736002)(53546011)(26005)(102836004)(478600001)(72206003)(9686003)(81166006)(186003)(6306002)(966005)(8936002)(8676002)(6246003)(53936002)(81156014)(6506007)(86362001)(2501003)(2201001)(2906002)(486006)(476003)(6116002)(3846002)(99286004)(446003)(11346002)(6436002)(55016002)(7696005)(229853002)(76176011)(25786009)(4001150100001)(71190400001)(71200400001)(97736004)(316002)(68736007)(85282002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR1001MB2193; H:BN6PR1001MB2161.namprd10.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: InterDigital.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 5cE1u5Sq+FqWTk9lg4cOJoX6p9P+EMZ8sCLVhMTyjnejNpyo1rWf6riYsh/BzwXaQAC/fkIyMnmMQU3tU4bB85MyUBO8aOsZCGKtdyfNdRsvv66hNbETDmC8YZcfKMR7P3FCJYRbWzKcbio8JwlpY8EXs6ygccSeJsWDmwClQidurYHnIJQgKR7YPviajajZAHNPuWhbK62cHg1643Xn5QOi0teUlO1lgvtU08SXSCsVFoVLkM0zMOmre2VfQ/PFZcFfO+f0vZMKjviN56N5U9RTM099JLAhe1hdxsj1h6STSVDEuPMwRefYw9OA/ib/
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: interdigital.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1224de3b-abf9-47bd-5b4b-08d65fb3068a
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2018 21:53:03.2188 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: e351b779-f6d5-4e50-8568-80e922d180ae
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1001MB2193
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/SR_8zIx_GIXkb6WHQs8ymQ2w550>
Subject: Re: [sfc] Question on the Information of SFs in load balance
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Dec 2018 21:53:09 -0000
Hello All, Following up on Dirk's comment, we just submitted an update to the draft "draft-trossen-sfc-name-based-sff ". It addresses comments from the reviewers in the email list as well as some comments from the meeting. This describes in details the extension of the SFC concepts to handle named relations. Please provide any comments/suggestions you may have to improve the work. Thanks Debashish. ************************* A new version of I-D, draft-trossen-sfc-name-based-sff-02.txt has been successfully submitted by Debashish Purkayastha and posted to the IETF repository. Name: draft-trossen-sfc-name-based-sff Revision: 02 Title: Name-Based Service Function Forwarder (nSFF) component within SFC framework Document date: 2018-12-11 Group: Individual Submission Pages: 25 URL: https://www.ietf.org/internet-drafts/draft-trossen-sfc-name-based-sff-02.txt Status: https://datatracker.ietf.org/doc/draft-trossen-sfc-name-based-sff/ Htmlized: https://tools.ietf.org/html/draft-trossen-sfc-name-based-sff-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-trossen-sfc-name-based-sff Diff: https://www.ietf.org/rfcdiff?url2=draft-trossen-sfc-name-based-sff-02 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Trossen, Dirk Sent: Tuesday, December 11, 2018 5:14 AM To: Joel M. Halpern <jmh@joelhalpern.com>; ao.ting@zte.com.cn; sfc@ietf.org Subject: Re: [sfc] Question on the Information of SFs in load balance Ting Ao, Albeit still in early stages of discussions and SFC WG input, the name-based SFF work we presented in Bangkok aims at load balancing scenarios, e.g., in 5G control plane realization, but uses a proposed extension of the SFC concepts onto named relations (here URIs) with the nSFF utilizing paths to SF instances; those paths provided by a name resolver. Such name resolver could apply load balancing policies in that decision making. Best, Dirk -----Original Message----- From: sfc <sfc-bounces@ietf.org> On Behalf Of Joel M. Halpern Sent: 11 December 2018 08:30 To: ao.ting@zte.com.cn; sfc@ietf.org Subject: Re: [sfc] Question on the Information of SFs in load balance There are multiple ways that this load balancing can be done. One way is to make the multiple SF instances visible to the SFF, and have the SFF perform the laod balancing. That is allowed. Another way of doing it is to have a single (or redundant pair of) load balancer visible to the SFF, and have the load balancer handle the multiple SF instances, including localizing the knowledg eof changes in the set and how to deal with those changes, keeping the SFF out of it. Both are allowed. In both cases, the delivery address known to the SFF will be whatever transport is used between the SFF and the succeeding element. There is no requirement that alternative next elements use the same transport. Of course, the carried packet is whatever it is, which is separate from what transport is used to carry the packet with the NSH header to the load balancer or SFF. Yours, Joel On 12/11/18 6:24 AM, ao.ting@zte.com.cn wrote: > > Hi all, > > > When we consider to collect the information of SFs which are attached > to one SFF for load balancing, we know that these SFs have same same > Service Function Type and Service Index, but do they have to have the > same locator? Is it possible that one of these SFs has a IPv4 address, > while the aother one has a IPv6 address? > > > Best Regards. > > Ting Ao > > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc
- [sfc] Question on the Information of SFs in load … ao.ting
- Re: [sfc] Question on the Information of SFs in l… Trossen, Dirk
- Re: [sfc] Question on the Information of SFs in l… Joel M. Halpern
- Re: [sfc] Question on the Information of SFs in l… Purkayastha, Debashish