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