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

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

> -----Original Message-----
> 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.
> 
> Please share your thoughts on this.
> 
> Thanks.
> 
>    Ron
>

---

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