Subject: [sfc] Question on the Information of SFs in load balance

From: <[email-masked]>
Date: Tue, 11 Dec 2018 14:24:46 +0800 (CST)

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 Dec 2018 08:30:04 +0000

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, [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Trossen, Dirk" <[email-masked]>
Date: Tue, 11 Dec 2018 10:14:18 +0000

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 <[email-masked]> On Behalf Of Joel M. Halpern
Sent: 11 December 2018 08:30
To: [email-masked]; [email-masked]
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, [email-masked] 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

---

From: "Purkayastha, Debashish" <[email-masked]>
Date: Tue, 11 Dec 2018 21:53:03 +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:[email-masked]] On Behalf Of Trossen, Dirk
Sent: Tuesday, December 11, 2018 5:14 AM
To: Joel M. Halpern <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [sfc] Question on the Information of SFs in load balance

Ting Ao,

Best,

Dirk

-----Original Message-----
From: sfc <[email-masked]> On Behalf Of Joel M. Halpern
Sent: 11 December 2018 08:30
To: [email-masked]; [email-masked]
Subject: Re: [sfc] Question on the Information of SFs in load balance

Both are allowed.

Yours,
Joel