Subject: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

From: Linda Dunbar <[email-masked]>
Date: Fri, 4 Jul 2014 20:48:40 +0000

Hi, 

This draft describes the framework of protection and restoration of
   Service Chain Instance Path when some instances on the path fail or
   need to be replaced.

Appreciate to hear your comments or suggestions. 

Linda & Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 30, 2014 11:25 AM
To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar
Subject: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

A new version of I-D, draft-dunbar-sfc-fun-instances-restoration-00.txt
has been successfully submitted by Linda Dunbar and posted to the IETF repository.

Name:		draft-dunbar-sfc-fun-instances-restoration
Revision:	00
Title:		Framework for Service Function Instances Restoration
Document date:	2014-04-29
Group:		Individual Submission
Pages:		12
URL:            http://www.ietf.org/internet-drafts/draft-dunbar-sfc-fun-instances-restoration-00.txt
Status:         https://datatracker.ietf.org/doc/draft-dunbar-sfc-fun-instances-restoration/
Htmlized:       http://tools.ietf.org/html/draft-dunbar-sfc-fun-instances-restoration-00

Abstract:
   This draft describes the framework of protection and restoration of
   Service Chain Instance Path when some instances on the path fail or
   need to be replaced.

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

---

From: Ron Parker <[email-masked]>
Date: Mon, 7 Jul 2014 12:52:27 +0000

Linda & Andy,

Thanks for putting this together.   I'm happy to see more work on the "chain-to-path" topic.   I agree with all of your analysis regarding pros/cons of various approaches.     Encapsulation and Control Plane will be dependent on our architectural decisions in this area.   The elusive thing for all of us, as a group, is to come to some conclusions!

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Friday, July 04, 2014 4:49 PM
To: [email-masked]'
Subject: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Hi, 

Linda & Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 30, 2014 11:25 AM
To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar
Subject: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Abstract:

The IETF Secretariat

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: Qin Wu <[email-masked]>
Date: Mon, 7 Jul 2014 13:12:45 +0000

Ron:
We also have draft to discuss how to instantiate service function path using PCE-initiate LSP instantiation.
http://tools.ietf.org/html/draft-wu-pce-traffic-steering-sfc-04
It supports dynamic creation and deletion of service function path.
Your may check out.

Regards!
-Qin
-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 Ron Parker
发送时间: 2014年7月7日 20:52
收件人: Linda Dunbar; [email-masked]'
主题: Re: [sfc] New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Linda & Andy,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Friday, July 04, 2014 4:49 PM
To: [email-masked]'
Subject: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Hi, 

Linda & Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 30, 2014 11:25 AM
To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar
Subject: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Abstract:

The IETF Secretariat

---

From: Ron Parker <[email-masked]>
Date: Mon, 7 Jul 2014 13:46:48 +0000

Qin,

I agree that RSVP-TE style MPLS is a close architectural match to what SFC is trying to achieve, and that an MPLS label stack in this context is likely the most efficient way to encode explicit source routing, packet-by-packet, while preserving all the resiliency capabilities that are required for real-world SFC.    

But one concern I have is the ubiquity, or lack thereof, of MPLS where SFC would be used.   In mobile carrier environments, the SFC is seen as applicable to the "Gi-LAN" set of value added services that are deployed between the subscriber management system (i.e., GGSN/PDN-GW) and the Internet.    In some cases, this may be MPLS underpinning this part of the network, but in others it is simple Ethernet or SDN overlay over Ethernet.

Please share your thoughts on this.

Thanks.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, July 07, 2014 9:13 AM
To: Ron Parker; Linda Dunbar; [email-masked]'
Subject: Re: [sfc] New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Ron:

Regards!
-Qin
-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 Ron Parker
发送时间: 2014年7月7日 20:52
收件人: Linda Dunbar; [email-masked]'
主题: Re: [sfc] New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Linda & Andy,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Friday, July 04, 2014 4:49 PM
To: [email-masked]'
Subject: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Hi, 

Linda & Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 30, 2014 11:25 AM
To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar
Subject: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Abstract:

The IETF Secretariat

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 8 Jul 2014 02:11:52 +0000

(Note that I changed the subject since this is a totally different topic)

Hi Ron,

I agree there are some cases where the underlay network is not MPLS-capable. In those cases, you could actually just take the MPLS label stack which represents a given SFP (http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02) as an overlay, just like the SFC encapsulation header (http://tools.ietf.org/html/draft-merged-sfc-architecture-00). The MPLS packets on the overlay could be transported over IP underlay networks with MPLS-over-IP tunnels (http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-00). IMHO, this MPLS label stack based (or SPRING based) SFC approach is a concrete example of Transport Derived SFF (see below) as defined in section 4.3.1 of the SFC arch draft (http://tools.ietf.org/html/draft-merged-sfc-architecture-00):

4.3.1.  Transport Derived SFF

   Service function forwarding, as described above, directly depends
   upon the use of the service path information contained in the SFC
   encapsulation.  Existing implementations may not be able to act on
   the SFC encapsulation.  These platforms may opt to use a transport
   mechanism which carries the service path information from the SFC
   encapsulation, and information derived from the SFC encapsulation, to
   build transport information.

   This results in the same architectural behavior and meaning for
   service function forwarding and service function paths.  It is the
   responsibility of the control components to ensure that the transport
   path executed in such a case is fully aligned with the path
   identified by the information in the service chaining encapsulation.

Best regards,
Xiaohu

> From: sfc [mailto:[email-masked]] On Behalf Of Ron Parker
> Sent: Monday, July 07, 2014 9:47 PM
> To: Qin Wu; Linda Dunbar; [email-masked]'
> Subject: Re: [sfc] New Version Notification for
> draft-dunbar-sfc-fun-instances-restoration-00.txt
> 
> Qin,
> 
> I agree that RSVP-TE style MPLS is a close architectural match to what SFC is
> trying to achieve, and that an MPLS label stack in this context is likely the most
> efficient way to encode explicit source routing, packet-by-packet, while
> preserving all the resiliency capabilities that are required for real-world SFC.
> 
> But one concern I have is the ubiquity, or lack thereof, of MPLS where SFC
> would be used.   In mobile carrier environments, the SFC is seen as applicable
> to the "Gi-LAN" set of value added services that are deployed between the
> subscriber management system (i.e., GGSN/PDN-GW) and the Internet.    In
> some cases, this may be MPLS underpinning this part of the network, but in
> others it is simple Ethernet or SDN overlay over Ethernet.
>

---

From: Qin Wu <[email-masked]>
Date: Tue, 8 Jul 2014 03:08:45 +0000

Hi, Ron:
The PCE based approach we proposed in draft-wu-pce-traffic-steering-sfc-04 can be applied to MPLS network, but not necessary to RSVP-TE style MPLS.
You can use whatever signaling you like to instantiate Service Function Path. But not necessary to limite to only using RSVP as signaling.

You are right, SFC can be used without MPLS, e.g., IP network, but we are hoping the approach we proposed also can be used together with SDN controller or OSS/NMS since
Stateful PCE as centralized controller supports either static service function placement or dynamic creation and deletion of the path.
Therefore It doesn't matter what signaling you are using to setup path.

Regards!
-Qin
-----邮件原件-----
发件人: Ron Parker [mailto:[email-masked]] 
发送时间: 2014年7月7日 21:47
收件人: Qin Wu; Linda Dunbar; [email-masked]'
主题: RE: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Qin,

Thanks.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Monday, July 07, 2014 9:13 AM
To: Ron Parker; Linda Dunbar; [email-masked]'
Subject: Re: [sfc] New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Ron:

Regards!
-Qin
-----邮件原件-----
发件人: sfc [mailto:[email-masked]] 代表 Ron Parker
发送时间: 2014年7月7日 20:52
收件人: Linda Dunbar; [email-masked]'
主题: Re: [sfc] New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Linda & Andy,

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Friday, July 04, 2014 4:49 PM
To: [email-masked]'
Subject: [sfc] FW: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Hi, 

Linda & Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 30, 2014 11:25 AM
To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar
Subject: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Abstract:

The IETF Secretariat

---

From: 이승익 <[email-masked]>
Date: Tue, 8 Jul 2014 04:31:21 +0000

Linda,

Also glad to see this in active.

1. Regarding terminologies: "service function instance component" and "service chain instance path",
what differences do you have in your mind comparing with "service function instance" and "service function path", respectively?

2. It seems to me that your text is about dynamic update of SFC rather than restoration from failure. What do you think?

Regards,
Seung-ik.

> Sent: Monday, July 07, 2014 9:52 PM
> To: Linda Dunbar; [email-masked]'
> Thanks for putting this together.   I'm happy to see more work on the
> "chain-to-path" topic.   I agree with all of your analysis regarding
> pros/cons of various approaches.     Encapsulation and Control Plane will
> be dependent on our architectural decisions in this area.   The elusive
> thing for all of us, as a group, is to come to some conclusions!
> 
>    Ron
> 
> 
> 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
>

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 9 Jul 2014 04:00:29 +0000

Hi all,

The following are some drafts related to the SPRING-based SFC approach which may be useful for you to get the whole picture of the SRPING-based SFC approach. Any comments and suggestions are welcome.

Use Case draft:
http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02

SF Auto-discovery through IGP:
http://tools.ietf.org/html/draft-xu-isis-service-function-adv-02
http://tools.ietf.org/html/draft-xu-ospf-service-function-adv-02

SF Auto-discovery through DNS-SD:
http://tools.ietf.org/html/draft-xu-dnssd-sf-discovery-01

SFP Computation through PCE:
http://tools.ietf.org/html/draft-xu-spring-pce-based-sfc-arch-01
http://tools.ietf.org/html/draft-xu-pce-sr-sfc-01

Best regards,
Xiaohu

> From: sfc [mailto:[email-masked]] On Behalf Of Xuxiaohu
> Sent: Tuesday, July 08, 2014 10:12 AM
> To: Ron Parker
> Cc: <[email-masked]>; [email-masked]
> Subject: [sfc] Taking the MPLS label stack representing an SFP as an
> overlay=Transport Derived SFF
> 
> I agree there are some cases where the underlay network is not MPLS-capable.
> In those cases, you could actually just take the MPLS label stack which
> represents a given SFP
> (http://tools.ietf.org/html/draft-xu-spring-sfc-use-case-02) as an overlay, just
> like the SFC encapsulation header
> (http://tools.ietf.org/html/draft-merged-sfc-architecture-00). The MPLS packets
> on the overlay could be transported over IP underlay networks with
> MPLS-over-IP tunnels
> (http://tools.ietf.org/html/draft-xu-spring-islands-connection-over-ip-00).
> IMHO, this MPLS label stack based (or SPRING based) SFC approach is a concrete
> example of Transport Derived SFF (see below) as defined in section 4.3.1 of the
> SFC arch draft (http://tools.ietf.org/html/draft-merged-sfc-architecture-00):
> 
> > I agree that RSVP-TE style MPLS is a close architectural match to what
> > SFC is trying to achieve, and that an MPLS label stack in this context
> > is likely the most efficient way to encode explicit source routing,
> > packet-by-packet, while preserving all the resiliency capabilities that are
> required for real-world SFC.
> >
> > some cases, this may be MPLS underpinning this part of the network,
> > but in others it is simple Ethernet or SDN overlay over Ethernet.
> >

---

From: Linda Dunbar <[email-masked]>
Date: Sat, 12 Jul 2014 19:50:36 +0000

Seung-ik,

Thanks for reading the draft and the comments.

Sorry for the delayed response due to traveling abroad.

Answers are inserted below:

-----Original Message-----
From: 이승익 [mailto:[email-masked]]
Sent: Monday, July 07, 2014 11:31 PM
To: Linda Dunbar
Cc: Ron Parker; [email-masked]'
Subject: RE: New Version Notification for draft-dunbar-sfc-fun-instances-restoration-00.txt

Linda,

1. Regarding terminologies: "service function instance component" and "service chain instance path", what differences do you have in your mind comparing with "service function instance" and "service function path", respectively?

      [Linda] Service Chain Instance path is the "sequence of service function instances", whereas the "Service Function path" is a "sequence of Service Functions" at functional level.
      One service function could have multiple identical instances, potentially attached to different SFF nodes.
      At functional level, the order of service functions, e.g. Chain#1 {s1, s4, s6}, Chain#2{s4, s7}, is important, but very often which instance of the Service Function “s1” is selected for the Chain #1 is not. It is also possible that multiple instances of one service function can be reached by different network nodes. The actual instance selected for a service chain is called “Service Chain Instance Path”.

      [Linda] The “instance failure” requires the update of the Service Function Instance Path. Yes, there could be other reasons to trigger the update of the service function instances path, such as administrative reasons, utilization, etc.

Regards,
Seung-ik.

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
> A new version of I-D,
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>