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

From: Christian Koenning <[email-masked]>
Date: Tue, 17 May 2016 19:49:08 +0000

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]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 17 May 2016 15:57:35 -0400

Most of us have assumed that a bi-directional symmetric path pair is set 
up by control, and has separate Service Path IDs (and indicies) in each 
direction.  This does lead to a need for service functions which 
originate reverse direction packets to have a means to get the correct 
SPI / Index in place for those packets.  There are drafts discussing 
approaches to that question.

Yours,
Joel

On 5/17/16 3:49 PM, Christian Koenning wrote:
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Christian Koenning <[email-masked]>
Date: Tue, 17 May 2016 20:02:49 +0000

Thanks Joel,

that is where I was getting confused.

When looking e.g. at a stateful Service Function (SF), there needs to be
an instruction which two of the Service Path Identifiers co-releate in
order to establish state.

Further to that, could you define if Service Path Identifiers allows for 
overloading of address namespace? 

Many Thanks

Christian Koenning
--
F5 Networks Inc.
[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 17 May 2016 16:07:04 -0400

Correlation of packets in two directions for an SF which works seems to 
require that the SF know how to correlate packets.  Id does not need to 
look at the SPI for that, since SPI are coarser than flow.  It may need 
to look at metadata (such as subscriber identity) if the SF is inside a 
domain where IP addresses are reused (NAT being a service function 
itself, so one could be on the reuse side of a NAT.)

I am not sure what you are referring to by address namespaces.  SPIs do 
not segregate subscribers, nor are they qualifiers for disambiguating 
addresses where NAT is in use.  Metadata in the packet is used for such 
disambiguation.  So, in the presence of suitable metadata, SFC and NSH 
support inner (subscriber) address reuse / duplication.  NAT is an 
envisioned service function.  Just don't try to use the SPI as the key. 
It won't tell you what you need.

Yours,
Joel

---

From: Christian Koenning <[email-masked]>
Date: Tue, 17 May 2016 20:45:36 +0000

Thanks Joel,

thanks for confirming flow correlation (L4) is expected as usual, even
with ingress and egress on two different Service Path IDs. The question
of overloading address space tried to clarify the (rare) the situation where
 2 endpoint pairs have the same addresses and have agreed on the same
src/dst port/protocol, which leads to flow collisions.

You mention that Service Path ID will now allow to reuse- /duplication.

However, you mentioned that metadata will provide address reuse- /
duplication. Therefore the flow correlation would need to happen on
including the metadata as part of the tuple as well.

Also, allow me to ask if we expect ingress and egress Service Path IDs
on the same transport/tunnel ?

Many Thanks

Christian Koenning
--
F5 Networks Inc.
[email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 17 May 2016 16:51:08 -0400

I do not think that the SFC archtiecture or the NSH mechanisms  specify 
anything about the inter-SFF paths used in the two different directions 
for a pair of symmetrically correlated Service Function Paths.

That said, given that the transports are running between the same two 
end-points, I would expect that operational practices will result in 
them using the same kind of transport.

For most of the transports we are looking at, it is not clear what it 
means to ask if they are using the same tunnel.  For example, if the 
transport is native Ethernet, then one direction uses a particular 
src/dest Ethernet address pari, and the other direction will typically 
(but not always) use the same addresses in the other order.  If we are 
using VxLAN, in each direction the source UDP port will be random, as 
that is the way VxLAN works.  If we are using LISP, the tunnels are 
considered to be unidirectional.

Yours,
Joel

---

From: Christian Koenning <[email-masked]>
Date: Tue, 17 May 2016 21:02:39 +0000

Thanks for the quick reply. 

Specifically for VXLAN-GPE, will the co-relating SPI be using the same VXLAN Segment ID/VXLAN Network Identifier (VNI)? 

Sorry for the broad question, i realise that i rather should go into the detail directly.

Many Thanks,

Christian

> On 17 May 2016, at 21:51, Joel M. Halpern <[email-masked]> wrote:
> 
> I do not think that the SFC archtiecture or the NSH mechanisms  specify anything about the inter-SFF paths used in the two different directions for a pair of symmetrically correlated Service Function Paths.
> 
> That said, given that the transports are running between the same two end-points, I would expect that operational practices will result in them using the same kind of transport.
> 
> For most of the transports we are looking at, it is not clear what it means to ask if they are using the same tunnel.  For example, if the transport is native Ethernet, then one direction uses a particular src/dest Ethernet address pari, and the other direction will typically (but not always) use the same addresses in the other order.  If we are using VxLAN, in each direction the source UDP port will be random, as that is the way VxLAN works.  If we are using LISP, the tunnels are considered to be unidirectional.
> 
> Yours,
> Joel
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 17 May 2016 17:12:18 -0400

Neither NSH nor SFC Architecture would force the same VNI to be used in 
each direction for the paired SFPs.  I would not assume that in my SFF 
design.
Hwoe3ver, it would seem a very good practice, and something I would 
expect control to do.

This does get back to your earlier, welltaken, question about where teh 
SFF gets the VNI to put into the VxLAN header.  One approach is to 
declare that all of service chaining is a single VNI, and so it is an 
SFF-wide configuration parameter.  Another approach is that specific 
portions use specific VNI, which would lead to wanting the VNI 
configured in the SPI mapping table.  It seems to depend upon where the 
VTEP is understood to be.  I think we need to allow both cases.

It should be remembered that the table entries in the NSH draft are 
exemplars, not specification.  The NSH draft does not standardize the 
transport mappings.  (And the WG charter makes appears to make it out of 
scope for the WG.)  So I am not sure where the question of interoperable 
VNI use for VxLAN transport can be answered.  (And VLAN use for Ethernet 
Transport.)

Yours,
Joel

On 5/17/16 5:02 PM, Christian Koenning wrote:
> Specifically for VXLAN-GPE, will the co-relating SPI be using the
> same VXLAN Segment ID/VXLAN Network Identifier (VNI)?
>
>> I do not think that the SFC archtiecture or the NSH mechanisms
>> specify anything about the inter-SFF paths used in the two
>> different directions for a pair of symmetrically correlated Service
>> Function Paths.
>>
>> That said, given that the transports are running between the same
>> two end-points, I would expect that operational practices will
>> result in them using the same kind of transport.
>>
>> For most of the transports we are looking at, it is not clear what
>> it means to ask if they are using the same tunnel.  For example, if
>> the transport is native Ethernet, then one direction uses a
>> particular src/dest Ethernet address pari, and the other direction
>> will typically (but not always) use the same addresses in the other
>> order.  If we are using VxLAN, in each direction the source UDP
>> port will be random, as that is the way VxLAN works.  If we are
>> using LISP, the tunnels are considered to be unidirectional.
>>
>> Yours, Joel
>>
>>> thanks for confirming flow correlation (L4) is expected as usual,
>>> even with ingress and egress on two different Service Path IDs.
>>> The question of overloading address space tried to clarify the
>>> (rare) the situation where 2 endpoint pairs have the same
>>> addresses and have agreed on the same src/dst port/protocol,
>>> which leads to flow collisions.
>>>
>>> However, you mentioned that metadata will provide address reuse-
>>> / duplication. Therefore the flow correlation would need to
>>> happen on including the metadata as part of the tuple as well.
>>>
>>> Also, allow me to ask if we expect ingress and egress Service
>>> Path IDs on the same transport/tunnel ?
>>>
>>> Many Thanks
>>>
>>> Christian Koenning -- F5 Networks Inc. [email-masked]
>>>
>>>
>>>
>>>
>>>
>>>
>>>> Correlation of packets in two directions for an SF which works
>>>> seems to require that the SF know how to correlate packets.  Id
>>>> does not need to look at the SPI for that, since SPI are
>>>> coarser than flow.  It may need to look at metadata (such as
>>>> subscriber identity) if the SF is inside a domain where IP
>>>> addresses are reused (NAT being a service function itself, so
>>>> one could be on the reuse side of a NAT.)
>>>>
>>>> I am not sure what you are referring to by address namespaces.
>>>> SPIs do not segregate subscribers, nor are they qualifiers for
>>>> disambiguating addresses where NAT is in use.  Metadata in the
>>>> packet is used for such disambiguation.  So, in the presence of
>>>> suitable metadata, SFC and NSH support inner (subscriber)
>>>> address reuse / duplication.  NAT is an envisioned service
>>>> function.  Just don't try to use the SPI as the key. It won't
>>>> tell you what you need.
>>>>
>>>> Yours, Joel
>>>>
>>>>> On 5/17/16 4:02 PM, Christian Koenning wrote: Thanks Joel,
>>>>>
>>>>> When looking e.g. at a stateful Service Function (SF), there
>>>>> needs to be an instruction which two of the Service Path
>>>>> Identifiers co-releate in order to establish state.
>>>>>
>>>>>
>>>>> Further to that, could you define if Service Path Identifiers
>>>>> allows for overloading of address namespace?
>>>>>
>>>>> Christian Koenning -- F5 Networks Inc. [email-masked]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Most of us have assumed that a bi-directional symmetric
>>>>>> path pair is set up by control, and has separate Service
>>>>>> Path IDs (and indicies) in each direction.  This does lead
>>>>>> to a need for service functions which originate reverse
>>>>>> direction packets to have a means to get the correct SPI /
>>>>>> Index in place for those packets.  There are drafts
>>>>>> discussing approaches to that question.
>>>>>>
>>>>>> Yours, Joel
>>>>>>
>>>>>>> On 5/17/16 3:49 PM, Christian Koenning wrote: Good
>>>>>>> Evening,
>>>>>>>
>>>>>>> looking at RFC 7665 Service Function Chaining (SFC)
>>>>>>> Architecture https://tools.ietf.org/html/rfc7665
>>>>>>>
>>>>>>> " 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
>>>>>>> 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.
>>>>>>>
>>>>>>> However, when looking at this together with Network
>>>>>>> Service Header draft-ietf-sfc-nsh-04.txt
>>>>>>> " Service Path Identifier (SPI): identifies a service
>>>>>>> path. Participating nodes MUST use this identifier for
>>>>>>> Service Function Path selection. "
>>>>>>>
>>>>>>> Can you please confirm that a bidirectional Service
>>>>>>> Function Chain will be represented by one single Service
>>>>>>> Path Identifier, ingress symmetric to egress ?
>>>>>>>
>>>>>>>
>>>>>>> Christian Koenning -- F5 Networks Inc. [email-masked]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________ sfc
>>>>>>> mailing list [email-masked]

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Tue, 17 May 2016 21:25:31 +0000

Hi Christian,

> On May 17, 2016, at 5:02 PM, Christian Koenning <[email-masked]> wrote:
> 

The GPE VNI is orthogonal to the NSH information.  I expect (and have seen) two cases: a common shared VNI for the service path, or a per-tenant VNI, imposed at the SFF(s).

> Sorry for the broad question, i realise that i rather should go into the detail directly.

Not at all, let's keep the discussion going!

---

From: Christian Koenning <[email-masked]>
Date: Tue, 17 May 2016 22:28:52 +0000

Thanks Joel,

Would it be possible to add all this clarification into the draft ?
It will remove the ambiguity.

Many Thanks
Christian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 17 May 2016 19:04:34 -0400

I am not sure which aspects can reasonably go in the NSH draft.  For 
example, although the VxLAN example can be enhanced, it is still an 
example, not anything normative.

Basically, additions are up to the WG.  Within the scope of the document 
and WG charter.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 17 May 2016 19:11:21 -0400

I realized reading my reply that I left out something important.
The fact that you found this confusing is a good indication that we 
should try to improve the text.

Yours,
Joel

On 5/17/16 7:04 PM, Joel M. Halpern wrote:
>> On 17/05/2016, 22:12, "sfc on behalf of Joel M. Halpern"
>> <[email-masked] on behalf of [email-masked]> wrote:
>>

---

From: Christian Koenning <[email-masked]>
Date: Wed, 18 May 2016 22:18:52 +0000

Thanks Joel!

Allow me to elaborate on the confusion further.

<CONTEXT>

>Identifiers co-releate in order to establish state.

</CONTEXT>

Taking the case of the Service Function (SF) e.g. terminating the
connection, or allowing for late binding, the SF would need to sent the
TCP SYN/ACK segment back. If there is no a-prio knowledge of the return
SPI', then what SPI' would the SF choose ?

Many Thanks

Christian Koenning 
-- 
F5 Networks Inc. 
[email-masked]

---

From: Dave Dolson <[email-masked]>
Date: Wed, 18 May 2016 22:27:58 +0000

Christian,
These type of questions are contemplated in draft-penno-sfc-packet
Please give your feedback on which solutions work or don't work for you.

-Dave

  Original Message
From: Christian Koenning
Sent: Wednesday, May 18, 2016 6:19 PM
To: Joel M. Halpern
Cc: [email-masked]
Subject: Re: [sfc] Service Path Identifier (SPI) and symmetry

Thanks Joel!

<CONTEXT>

</CONTEXT>

Many Thanks

Christian Koenning
--
F5 Networks Inc.
[email-masked]

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 18 May 2016 18:36:24 -0400

Yep, that is indeed a challenge.  There are a couple of approaches 
proposed.  One draft:
https://datatracker.ietf.org/doc/draft-penno-sfc-packet/

describes some of the issues and possible approaches.

Yours,
Joel

---

From: "Bottorff, Paul" <[email-masked]>
Date: Thu, 26 May 2016 18:02:24 +0000

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

"

   ...

3.3.  Service Path Header

"

Many Thanks

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

---

From: "Surendra Kumar (smkumar)" <[email-masked]>
Date: Thu, 26 May 2016 18:46:08 +0000

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.

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

"

   ...

3.3.  Service Path Header

"

Many Thanks

Christian Koenning

---

From: Dave Dolson <[email-masked]>
Date: Thu, 26 May 2016 21:28:35 +0000

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,

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.

Cheers,

Paul

Good Evening,

looking at RFC 7665

"

   ...

3.3.  Service Path Header

"

Many Thanks

Christian Koenning