Re: [spring] Taking the MPLS label stack representing an SFP as an overlay=Transport Derived SFF

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:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu
> Sent: Tuesday, July 08, 2014 10:12 AM
> To: Ron Parker
> Cc: <spring@ietf.org>; sfc@ietf.org
> 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:sfc-bounces@ietf.org] On Behalf Of Ron Parker
> > Sent: Monday, July 07, 2014 9:47 PM
> > To: Qin Wu; Linda Dunbar; 'sfc@ietf.org'
> > 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
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc