Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry

From: Sumandra Majee <[email-masked]>
Date: Fri, 27 May 2016 00:14:00 +0000

While I acknowledge it is an issue, there is no need to have a single solution for this.

  1.  Have two distinct SPI-F and SPI-R. If controller and classifiers are able to coordinate that then that is one solution.
  2.  Having SPI-R |= HI bit. That simplifies the allocation but it is again an implementation issue. PathID (fortunately) has many bits and will have many uses for those bits.
  3.  Some services and forwarder has complete flow state which makes the reverse path problem, not a problem. The reverse flow match would automatically forward pkts where it came from. Even in one Armed case the forward path is SIP -> DIP while reverse path is DIP->SIP.

It really depends on amount of context information a forwarding entity can use.

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of Surendra Kumar <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 26, 2016 at 11:46 AM
To: "Bottorff, Paul" <[email-masked]<mailto:[email-masked]>>, Christian Koenning <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry

Hi Paul,

In general I can see how having two Service headers may help.
In practice however, a single one with high-order bit differentiating the forward/reverse name space works well where bi-directional behavior is needed and has for us. I support using the high-order bit as an implementation detail.

One option with MD-TYPE2 may be to use TLVs to carry the other service-header, that achieves the desired effect while not taxing all implementations.

Surendra.

From: sfc [mailto:[email-masked]] On Behalf Of Bottorff, Paul
Sent: Thursday, May 26, 2016 11:02 AM
To: Christian Koenning <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry

Hi Christian:

A very good question.

IMHO the SPI can’t be bi-directional because the forwarding direction would be ambiguous for single armed SFs.

The reversal problem points out a basic deficiency of the SPI+SI NSH fields. These fields form the server layer network address (not the transport layer address). What we lack is a way to encode the reverse address.

The direct method for handling forward and backward addressing is to encode both a forward and reverse path in the NSH header (SPIF/SPIR). This would be similar to Ethernet DA/SA or IP SIP/SIP. Such an encoding would be the most flexible way to build the NSH header, however for a more space efficient method which offers the minimum modification to the existing NSH fields we have had success encoding a reverse address by reserving the high order bit of the SPI to designate the reverse address. So in this method the SPIF always has high order bit 0 and the SPIR always has high order bit 1. An SF or OAM which needs to send along the reverse path can always form the reverse address by flipping the high order bit of the SPI.

Cheers,

Paul

From: sfc [mailto:[email-masked]] On Behalf Of Christian Koenning
Sent: Tuesday, May 17, 2016 12:49 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] Service Path Identifier (SPI) and symmetry

Good Evening,

looking at RFC 7665
Service Function Chaining (SFC) Architecture
https://tools.ietf.org/html/rfc7665

there is a clear definition of chain symetry

"
2.2.  Service Function Chain Symmetry

   SFCs may be unidirectional or bidirectional.  A unidirectional SFC
   requires that traffic be forwarded through the ordered SFs in one
   direction (sf1 -> sf2 -> sf3), whereas a bidirectional SFC requires a
   symmetric path (sf1 -> sf2 -> sf3 and sf3 -> sf2 -> sf1), and in
   which the SF instances are the same in opposite directions.  A hybrid
   SFC has attributes of both unidirectional and bidirectional SFCs;
   that is to say some SFs require symmetric traffic, whereas other SFs
   do not process reverse traffic or are independent of the
   corresponding forward traffic.

   ...

    Further, there are state trade-offs in symmetry.  Symmetry may be
   realized in several ways depending on the SFF and classifier
   functionality.  In some cases, "mirrored" classification (i.e., from
   Source to Destination and from Destination to Source) policy may be
   deployed, whereas in others shared state between classifiers may be
   used to ensure that symmetric flows are correctly identified, then
   steered along the required SFP.  At a high level, there are various
   common cases.  In a non-exhaustive way, there can be for example:

   o  A single classifier (or a small number of classifiers), in which
      case both incoming and outgoing flows could be recognized at the
      same classifier, so the synchronization would be feasible by
      internal mechanisms internal to the classifier.

   o  Stateful classifiers where several classifiers may be clustered
      and share state.

   o  Fully distributed classifiers, where synchronization needs to be
      provided through unspecified means.

   o  A classifier that learns state from the egress packets/flows that
      is then used to provide state for the return packets/flow.

   o  Symmetry may also be provided by stateful forwarding logic in the
      SFF in some implementations.

   This is a non-comprehensive list of common cases. "

However, when looking at this together with
Network Service Header
draft-ietf-sfc-nsh-04.txt
https://tools.ietf.org/html/draft-ietf-sfc-nsh-04

3.3.  Service Path Header

"
   Service Path Identifier (SPI): identifies a service path.
   Participating nodes MUST use this identifier for Service Function
   Path selection.
"

there is no notion of symmetry.

Can you please confirm that a bidirectional Service Function Chain
will be represented by one single Service Path Identifier, ingress symmetric to egress ?

Please allow us to clarify this.

Many Thanks

Christian Koenning
--
F5 Networks Inc.
[email-masked]<mailto:[email-masked]>