(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 > _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
