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 > -----Original Message----- > From: sfc [mailto:[email protected]] On Behalf Of Xuxiaohu > Sent: Tuesday, July 08, 2014 10:12 AM > To: Ron Parker > Cc: <[email protected]>; [email protected] > Subject: [sfc] Taking the MPLS label stack representing an SFP as an > overlay=Transport Derived SFF > > (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 > > > -----Original Message----- > > From: sfc [mailto:[email protected]] On Behalf Of Ron Parker > > Sent: Monday, July 07, 2014 9:47 PM > > To: Qin Wu; Linda Dunbar; '[email protected]' > > 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. > > > > Please share your thoughts on this. > > > > Thanks. > > > > Ron > > > > _______________________________________________ > sfc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
