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

From: [email-masked]
Date: Thu, 7 Jul 2016 15:13:03 +0800

Dear Dave,

  SFC-Packet is really a practical draft which guides us about how to 
generate the reverse packet during our SFC deployment.
  And here I still have some confusion, could you please help me out?

  1.  Section 5.4.2 describing Flip Path-ID and Index High Order bits is 
really a feasible solution. 
       I guess here means flip Path-id or Service Index high order bit 
either, not flip both Path-id and Service Index high order bit, right? 
       And the SPI mentioned in this section means Service Path Identifier 
or Service Path Index? Because this section first says 'to make
       use of a different Service Path ID', so I guess SPI here you mean 
is Service Path Identifier, but later it takes 8-bit SPI 6 and 134 for 
example.

  2.   Section 5.2 using two different solutions to request SFF 
cooperation, one is OAM packet and the other one is Reserved bit. 
        We really like the Reserved bit solution, but it mentions an issue 
'the metadata in the original packet might be overwritten by SFs or SFFs'.
        I cannot understand what the issue actually is ?

  3.   This draft aims how SFs generate reverse packets. But in fact, 
section 5.3 and section 5.4  can be also used as a synchronous mechanism 
        between mirrored classifiers.

 Many thanks:)

BRs,
Linda Wang

"sfc" <[email-masked]> 写于 2016/05/27 05:28:35:

> Dave Dolson <[email-masked]> 
> 发件人:  "sfc" <[email-masked]>
> 
> 2016/05/27 05:28
> 
> 收件人
> 
> "Surendra Kumar (smkumar)" <[email-masked]>, "Bottorff, Paul" 
> <[email-masked]>, Christian Koenning <[email-masked]>, 
> "[email-masked]" <[email-masked]>, 
> 
> 抄送
> 
> 主题
> 
> Re: [sfc] Service Path Identifier (SPI) and symmetry
> 
> This question of the reversal problem (and packet injection in 
> general) keeps coming up.
> 
> Please read https://tools.ietf.org/html/draft-penno-sfc-packet-03
> and provide feed-back.
> 
> In particular, various methods are discussed using (a) OAM packets, 
> (b) reversal information in meta-data, (c) algorithmic approaches to
> computing reversed fields.
> 
> Let us know what works for you.
> 
> -Dave
> 
> 
> From: sfc [mailto:[email-masked]] On Behalf Of Surendra Kumar 
(smkumar)
> Sent: Thursday, May 26, 2016 2:46 PM
> To: Bottorff, Paul; Christian Koenning; [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]>; [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]
> 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]
>  _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc