Subject: [sfc] FW: New Version Notification for draft-kang-sfc-dynamic-path-selection-00.txt

From: 강태호(SDN Project) <[email-masked]>
Date: Mon, 6 Jul 2015 18:15:12 +0000

Hi,
We uploaded a draft describing dynamic path selection between SFF & SF, and failover.
It would help overall stability of service chain.

We appreciate your comments and/or suggestions.
Thanks.

Best regards,
Taeho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 07, 2015 3:01 AM
To: 백은경(SDNFV TF); 백은경(SDNFV TF); 강태호(SDN Project); 김성수(SDN Project); 강태호(SDN Project); 김성수(SDN Project); 김남곤(NFV Project); 김남곤(NFV Project); 한영태(SDN Project); 한영태(SDN Project)
Subject: New Version Notification for draft-kang-sfc-dynamic-path-selection-00.txt

A new version of I-D, draft-kang-sfc-dynamic-path-selection-00.txt
has been successfully submitted by Taeho Kang and posted to the IETF repository.

Name:           draft-kang-sfc-dynamic-path-selection
Revision:       00
Title:          Dynamic Service Path Selection over Multiple Links between SFF and SF for Enhancing Service Stability
Document date:  2015-07-06
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/internet-drafts/draft-kang-sfc-dynamic-path-selection-00.txt
Status:         https://datatracker.ietf.org/doc/draft-kang-sfc-dynamic-path-selection/
Htmlized:       https://tools.ietf.org/html/draft-kang-sfc-dynamic-path-selection-00

Abstract:
   In this document, we use SF classification of 1)indispensible SF for
   packet delivery, allegedly mandatory SFs, such as NAT and 2)optional
   SFs that a packet can be delivered without them, such as Firewall and
   IDS.

   The nodes of SFC-enabled domain can be various.  Different vendors
   make different types of equipments, and this causes performance
   issues.  Considering this diversity, the kind of SFs can be in myriad
   form.  Thus, we should distinguish some mandatory SFs from not
   mandatory SFs and treat distinctively.  Mandatory SFs should be
   matched with higher-performance SFF to achieve high availability as
   well as lower the probability of failure.  Above all, whether each SF
   is mandatory or optional should be registered in advance.  Mandatory
   SFs are to allocated to relatively higher-performance, larger
   capacity, more stable SFFs.  SFC constructed using this way of
   allocation becomes the path for packets and packets are transferred
   to classifier through C1 interface, and to SFF through C2 interface,
   respectively.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못 전송된 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다.
This E-mail may contain confidential information and/or copyright material. This email is intended for the use of the addressee only. If you receive this email by mistake, please either delete it without reproducing, distributing or retaining copies thereof or notify the sender immediately.

---

From: Ron Parker <[email-masked]>
Date: Mon, 6 Jul 2015 18:42:13 +0000

Taeho,

Thank you for putting this draft together.    I am fully supportive of dynamic path selection for increased resiliency.   I think the concept can be further extended to simultaneously support SFC-level load balancing and resiliency.   For example, in your figure 1, if you extended your instance of SF2 to include multiple entities capable of providing equivalent functionality (eg SF2-a, SF2-b, SF2-c, ...) you could then have different SF2 instances having different connectivity.   For example, perhaps SF2-a connets to all 3 SFF's as your diagram indicates for the current "SF2".   Further, SF2-b could connect only to SFF2 and SFF4 and SF2-c could connect only to SFF1.    Additionally, you could characterize the capacity and/or current load of each instance separately.    Now, the same dynamic path selection logic you envision could account for policy-based load balancing and resiliency.

This also provides a good example to remind of the previous terminology discussions that we had on this thread regarding SFC, SFP, and RSP.   When we last left it, and per my interpretation, the SFC was the abstract sequence of logical service functions exactly as you describe in your draft (i.e., SF1-->SF2-->SF3).    The SFP, however, was not necessarily a fully constrained sequence of actual hops as you describe in your draft (i.e., SFP1: SFF1 -> SF1 -> SFF1 -> SFF2 -> SF2 -> SFF2 -> SF3 -> SFF2 -> SFF4).   That was described as the RSP (Rendered Service Path).   The "SFP" term was described as an intermediate level between SFC and RSP, which admittedly seems hard to understand at first glance.    What was intended here was the ability to describe certain constraining policy but to still allow some dynamic selection.   For example, SFC1, having SFP1 and SFP2, might describe SFP1 as { SFF1/SF1, { SFF2/SF2 or SFF4/SF2 }, {SFF2/SF3 or SFF4/SF3} } (i.e., policy states that the SFF1/SF2 path is not allowed for this particular SFP, as related to your figure 1).

Thanks.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of ???(SDN Project)
Sent: Monday, July 6, 2015 2:15 PM
To: [email-masked]
Subject: [GRAYMAIL] [sfc] FW: New Version Notification for draft-kang-sfc-dynamic-path-selection-00.txt

Hi,

Best regards,
Taeho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 07, 2015 3:01 AM
To: 백은경(SDNFV TF); 백은경(SDNFV TF); 강태호(SDN Project); 김성수(SDN Project); 강태호(SDN Project); 김성수(SDN Project); 김남곤(NFV Project); 김남곤(NFV Project); 한영태(SDN Project); 한영태(SDN Project)
Subject: New Version Notification for draft-kang-sfc-dynamic-path-selection-00.txt

Abstract:

The IETF Secretariat

이 메일은 지정된 수취인만을 위해 작성되었으며, 중요한 정보나 저작권을 포함하고 있을 수 있습니다. 어떠한 권한 없이, 본 문서에 포함된 정보의 전부 또는 일부를 무단으로 제3자에게 공개, 배포, 복사 또는 사용하는 것을 엄격히 금지합니다. 만약, 본 메일이 잘못 전송된 경우, 발신인 또는 당사에 알려주시고, 본 메일을 즉시 삭제하여 주시기 바랍니다.
This E-mail may contain confidential information and/or copyright material. This email is intended for the use of the addressee only. If you receive this email by mistake, please either delete it without reproducing, distributing or retaining copies thereof or notify the sender immediately.
_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc