Subject: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

From: "Kent Leung (kleung)" <[email-masked]>
Date: Fri, 14 Jul 2017 17:58:21 +0000

Hi. We are working on a revision for this draft. There were 4 proposed solution options in section 5. During some discussions, most folks seem to favor the use of algorithmic method in section 5.4. However, there are 2 sub-options. One is based on same Service Path ID and using Service Index to determine flow direction (sect. 5.4.1). The other is based on setting high order bit on Serve Path ID, which determines flow direction (sect. 5.4.2). There are mixed opinions. One reason is that there may be the assumption the Service Path ID is uni-directional. No explicit wording of that nature has been encountered in the RFCs, maybe we missed something?

If Serve Path ID is required to be uni-directional, then the answer is easy (=> 5.4.2). We would like to solicit WG comments to get rough consensus and revised the next version with that solution. This problem is critical to address for Service Function that generate packet in reverse direction, especially security service functions as mentioned in draft-wang-sfc-ns-use-cases.

Thanks.

Kent

---

From: James N Guichard <[email-masked]>
Date: Fri, 14 Jul 2017 18:24:42 +0000

Hi Kent,

[personal opinion ...] I have always assumed that the service path ID would be uni-directional given that it would be difficult to avoid collision in all forwarding scenarios. If you look at a basic SFC a-b-c and the service index is set to 255 at the classifiers a & c (which imho will be the normal practice) then at b you would have a conflict if the same service path ID is used in both directions.

Jim

From: sfc [mailto:[email-masked]] On Behalf Of Kent Leung (kleung)
Sent: Friday, July 14, 2017 1:58 PM
To: [email-masked]
Subject: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Thanks.

Kent

---

From: Dave Dolson <[email-masked]>
Date: Fri, 14 Jul 2017 18:50:42 +0000

There is not actually forwarding ambiguity, since SFF forwarding depends on *both* SPI and SI.
So for example, there is no ambiguity in forwarding to use SI in the range [0,127] of up-link and range [128,255] for down-link, on the same SPI.
The limitation is ~127 SFs per path instead of ~255.

As I see it, Kent's question is one of aesthetics. Do folks like the same SPI used for two directions?

Personally, I find use of a single SPI to be more elegant,  consuming only one path ID instead of two. (section 5.4.1).
It may make debugging easier as well.

Also, for what it's worth, we demonstrated this method of section 5.4.1 at a previous IETF hackathon.

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of James N Guichard
Sent: Friday, July 14, 2017 2:25 PM
To: Kent Leung (kleung); [email-masked]
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Hi Kent,

Jim

From: sfc [mailto:[email-masked]] On Behalf Of Kent Leung (kleung)
Sent: Friday, July 14, 2017 1:58 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Thanks.

Kent

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 Jul 2017 16:08:05 -0400

I find myself torn.  (And speaking personally in all that follows.)

There are actually two issues buried onder here.
Unless the reverse SFP is set up, and is congurent, the forwarding state 
may not exist.
Congruent reverse is only required when the nature of the SFP is such 
that reverse traffic must go through the same seqeunce of SFs, albeit in 
the reverse order, as the forward traffic.  That is not mandatory.  Even 
if some elements are common (as for example a TCP proxy), that doe snot 
mean that all are common and that full congruence is required.

To make this clearer, given an SFP that goes through SFFs A, B, and C, 
there is no requirement that SFF B have forwarding state for any 
specific SPI / SI to take reverse traffic.

So one of the points is to be explicit that a backwards path needs to be 
established (by control, routing, magic, ...) from those entities which 
need to send such reverse packets.  Which means that someone has to be 
able to determine where that is required.

Now, if we assume that piece of knowledge gets communicated, and the 
path is established, the quesiton you are asking is how to identify that 
reverse path.

I take Dave's point that there is a simplicity and efficiency in using 
the same SPI.  I find it conflicts with my personal view on how SPIs 
work.  But that is my problem, not the WGs.  The strong argument in 
favor is in fact that there can only be 64 different SIs in each 
direction, so there is plenty of room to keep things far enough apart 
that accidental wrap is not possible.

Net: using the SI grates on my nerves, but is probably sufficiently 
robust that it is a very reasonable choice.

Yours,
Joel

On 7/14/17 2:50 PM, Dave Dolson wrote:
> There is not actually forwarding ambiguity, since SFF forwarding depends 
> on **both** SPI and SI.
> 
> So for example, there is no ambiguity in forwarding to use SI in the 
> range [0,127] of up-link and range [128,255] for down-link, on the same SPI.
> 
> As I see it, Kent’s question is one of aesthetics. Do folks like the 
> same SPI used for two directions?
> 
> Personally, I find use of a single SPI to be more elegant,  consuming 
> only one path ID instead of two. (section 5.4.1).
> 
> Also, for what it’s worth, we demonstrated this method of section 5.4.1 
> at a previous IETF hackathon.
> 
> -Dave
> 
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *James N Guichard
> *Sent:* Friday, July 14, 2017 2:25 PM
> *To:* Kent Leung (kleung); [email-masked]
> *Subject:* Re: [sfc] clarification on Service Path ID for 
> draft-penno-sfc-packet
> 
> Hi Kent,
> 
> [personal opinion …] I have always assumed that the service path ID 
> would be uni-directional given that it would be difficult to avoid 
> collision in all forwarding scenarios. If you look at a basic SFC a-b-c 
> and the service index is set to 255 at the classifiers a & c (which imho 
> will be the normal practice) then at b you would have a conflict if the 
> same service path ID is used in both directions.
> 
> Jim
> 
> *From:* sfc [mailto:[email-masked]] *On Behalf Of *Kent Leung (kleung)
> *Sent:* Friday, July 14, 2017 1:58 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [sfc] clarification on Service Path ID for draft-penno-sfc-packet
> 
> Hi. We are working on a revision for this draft. There were 4 proposed 
> solution options in section 5. During some discussions, most folks seem 
> to favor the use of algorithmic method in section 5.4. However, there 
> are 2 sub-options. One is based on same Service Path ID and using 
> Service Index to determine flow direction (sect. 5.4.1). The other is 
> based on setting high order bit on Serve Path ID, which determines flow 
> direction (sect. 5.4.2). There are mixed opinions. One reason is that 
> there may be the assumption the Service Path ID is uni-directional. No 
> explicit wording of that nature has been encountered in the RFCs, maybe 
> we missed something?
> 
> If Serve Path ID is required to be uni-directional, then the answer is 
> easy (=> 5.4.2). We would like to solicit WG comments to get rough 
> consensus and revised the next version with that solution. This problem 
> is critical to address for Service Function that generate packet in 
> reverse direction, especially security service functions as mentioned in 
> draft-wang-sfc-ns-use-cases.
> 
> Thanks.
> 
> Kent
> 
> 
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Fri, 14 Jul 2017 20:15:38 +0000

Thanks for clarifying that in the case of same service path ID for both flows of a connection, the service index range is partitioned as described in sect. 5.4.1. I'm not sure if this is purely "aesthetics" as there may be assumption that service path ID identifies the direction of the flow. The meaning of service index is the sequence of service functions in the path. There are two distinct flows and each flow follows a path. That's why I lean toward sect. 5.4.2 (unique service path ID per flow/direction). But I can be convinced to using one service path ID. :)

Kent

From: Dave Dolson [mailto:[email-masked]]
Sent: Friday, July 14, 2017 8:51 PM
To: James N Guichard <[email-masked]>; Kent Leung (kleung) <[email-masked]>; [email-masked]
Subject: RE: clarification on Service Path ID for draft-penno-sfc-packet

-Dave

From: sfc [mailto:[email-masked]] On Behalf Of James N Guichard
Sent: Friday, July 14, 2017 2:25 PM
To: Kent Leung (kleung); [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Hi Kent,

Jim

Thanks.

Kent

---

From: Dave Dolson <[email-masked]>
Date: Fri, 14 Jul 2017 21:12:27 +0000

Joel,
Both of the algorithmic approaches discussed need to make assumptions about the symmetry of the reverse path. (Same SFs, in reverse order.)

-Dave

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Friday, July 14, 2017 4:08 PM
To: Dave Dolson; James N Guichard; Kent Leung (kleung); [email-masked]
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

There are actually two issues buried onder here.
Unless the reverse SFP is set up, and is congurent, the forwarding state may not exist.
Congruent reverse is only required when the nature of the SFP is such that reverse traffic must go through the same seqeunce of SFs, albeit in the reverse order, as the forward traffic.  That is not mandatory.  Even if some elements are common (as for example a TCP proxy), that doe snot mean that all are common and that full congruence is required.

To make this clearer, given an SFP that goes through SFFs A, B, and C, there is no requirement that SFF B have forwarding state for any specific SPI / SI to take reverse traffic.

So one of the points is to be explicit that a backwards path needs to be established (by control, routing, magic, ...) from those entities which need to send such reverse packets.  Which means that someone has to be able to determine where that is required.

Now, if we assume that piece of knowledge gets communicated, and the path is established, the quesiton you are asking is how to identify that reverse path.

I take Dave's point that there is a simplicity and efficiency in using the same SPI.  I find it conflicts with my personal view on how SPIs work.  But that is my problem, not the WGs.  The strong argument in favor is in fact that there can only be 64 different SIs in each direction, so there is plenty of room to keep things far enough apart that accidental wrap is not possible.

Net: using the SI grates on my nerves, but is probably sufficiently robust that it is a very reasonable choice.

Yours,
Joel

On 7/14/17 2:50 PM, Dave Dolson wrote:
> There is not actually forwarding ambiguity, since SFF forwarding 
> depends on **both** SPI and SI.
> 
> [personal opinion ...] I have always assumed that the service path ID 
> collision in all forwarding scenarios. If you look at a basic SFC 
> a-b-c and the service index is set to 255 at the classifiers a & c 
> (which imho will be the normal practice) then at b you would have a 
> conflict if the same service path ID is used in both directions.
> 
> Jim
> 
> solution options in section 5. During some discussions, most folks 
> seem to favor the use of algorithmic method in section 5.4. However, 
> there are 2 sub-options. One is based on same Service Path ID and 
> using Service Index to determine flow direction (sect. 5.4.1). The 
> other is based on setting high order bit on Serve Path ID, which 
> determines flow direction (sect. 5.4.2). There are mixed opinions. One 
> reason is that there may be the assumption the Service Path ID is 
> uni-directional. No explicit wording of that nature has been 
> encountered in the RFCs, maybe we missed something?
> 
> consensus and revised the next version with that solution. This 
> problem is critical to address for Service Function that generate 
> packet in reverse direction, especially security service functions as 
> mentioned in draft-wang-sfc-ns-use-cases.
> 
> Thanks.
> 
> Kent
> 
> 
>

---

From: James N Guichard <[email-masked]>
Date: Fri, 14 Jul 2017 23:08:54 +0000

Yes understood but I was assuming no manipulation of the SI and my point was more from an operational perspective; if I use the same path ID in both directions then I cannot immediately tell in which direction the packets are flowing unless I go one step deeper and look at the SI leading to a correlation of SPI + SI to be able to figure out my traffic matrix. Not so if the SPI is uni-directional.

Jim

From: Dave Dolson [mailto:[email-masked]]
Sent: Friday, July 14, 2017 2:51 PM
To: James N Guichard <[email-masked]>; Kent Leung (kleung) <[email-masked]>; [email-masked]
Subject: RE: clarification on Service Path ID for draft-penno-sfc-packet

-Dave

Hi Kent,

Jim

Thanks.

Kent

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Sun, 16 Jul 2017 11:37:48 +0000

Good discussion. I hope to correctly capture the preference of folks who had chimed in on this topic. It doesn't seem we've reached rough consensus.

Sect 5.4.1 (one service path ID, service index indicates flow direction):

-          Sumandra, Jim, Kent, Renaldo

Sect 5.4.2 (two service path IDs, each indicate flow direction):

-          Dave, Joel

BTW, I think both methods can support asymmetric paths as described in sect. 4.

Kent

From: James N Guichard [mailto:[email-masked]]
Sent: Saturday, July 15, 2017 1:09 AM
To: Dave Dolson <[email-masked]>; Kent Leung (kleung) <[email-masked]>; [email-masked]
Subject: RE: clarification on Service Path ID for draft-penno-sfc-packet

Jim

From: Dave Dolson [mailto:[email-masked]]
Sent: Friday, July 14, 2017 2:51 PM
To: James N Guichard <[email-masked]<mailto:[email-masked]>>; Kent Leung (kleung) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: clarification on Service Path ID for draft-penno-sfc-packet

-Dave

Hi Kent,

Jim

Thanks.

Kent

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Sun, 16 Jul 2017 20:10:53 +0000

Sorry. Corrected below.

-          Dave, Joel

From: sfc [mailto:[email-masked]] On Behalf Of Kent Leung (kleung)
Sent: Sunday, July 16, 2017 1:38 PM
To: James N Guichard <[email-masked]>; Dave Dolson <[email-masked]>; [email-masked]
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

-          Dave, Joel

Kent

From: James N Guichard [mailto:[email-masked]]
Sent: Saturday, July 15, 2017 1:09 AM
To: Dave Dolson <[email-masked]<mailto:[email-masked]>>; Kent Leung (kleung) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: clarification on Service Path ID for draft-penno-sfc-packet

Jim

-Dave

Hi Kent,

Jim

Thanks.

Kent

---

From: "Roberta Maglione (robmgl)" <[email-masked]>
Date: Mon, 17 Jul 2017 08:59:58 +0000

I agree on the operational aspect: having different SPI's for each direction simplifies the troubleshooting procedures, as statistics on the packets counters for each direction on each SF, can be displayed just based on SPI.
Regards,
Roberta

Inviato da iPad

Il giorno 15 lug 2017, alle ore 01:09, James N Guichard <[email-masked]<mailto:[email-masked]>> ha scritto:

Jim

-Dave

Hi Kent,

Jim

Thanks.

Kent
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: Dave Dolson <[email-masked]>
Date: Mon, 17 Jul 2017 13:01:02 +0000

Strictly, stats should be per SPI and SI, in order to support the so-called spiral.
But I can see how folks might find the lazy implementation to be useful.

From: Roberta Maglione (robmgl) [mailto:[email-masked]]
Sent: Monday, July 17, 2017 11:00 AM
To: James N Guichard
Cc: Dave Dolson; Kent Leung (kleung); [email-masked]
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Inviato da iPad

Jim

-Dave

Hi Kent,

Jim

Thanks.

Kent

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 17 Jul 2017 13:36:56 +0000

Why can't there be stats for per SPI and more granular stats for per SPI/SI? They seem to serve different purposes. The former is providing counters for all flows in each service path. The latter is provide counters for all flows served at each hop in the service path.

Can you explain the "spiral" scenario and how that pertains to usefulness of having per service path stats? Thanks.

Kent

From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, July 17, 2017 3:01 PM
To: Roberta Maglione (robmgl) <[email-masked]>; James N Guichard <[email-masked]>
Cc: Kent Leung (kleung) <[email-masked]>; [email-masked]
Subject: RE: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

From: Roberta Maglione (robmgl) [mailto:[email-masked]]
Sent: Monday, July 17, 2017 11:00 AM
To: James N Guichard
Cc: Dave Dolson; Kent Leung (kleung); [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Inviato da iPad

Jim

-Dave

Hi Kent,

Jim

Thanks.

Kent

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Mon, 17 Jul 2017 13:59:11 +0000

Hi Kent/others,

this decision is quite important for real deployments, as opposed to demos and related.  I hope as the first step we all agree that we cannot have more than one way of interpreting directionality of paths and associated reverse paths. That would be an interoperability nightmare and reduce the usefulness of NSH considerably.

So, whatever way it goes the WG needs to embrace it.

Thanks,

From: sfc <[email-masked]> on behalf of "Kent Leung (kleung)" <[email-masked]>
Date: Monday, July 17, 2017 at 10:36 AM
To: Dave Dolson <[email-masked]>, "Roberta Maglione (robmgl)" <[email-masked]>, James N Guichard <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Why can’t there be stats for per SPI and more granular stats for per SPI/SI? They seem to serve different purposes. The former is providing counters for all flows in each service path. The latter is provide counters for all flows served at each hop in the service path.

Can you explain the “spiral” scenario and how that pertains to usefulness of having per service path stats? Thanks.

Kent

Inviato da iPad

Jim

As I see it, Kent’s question is one of aesthetics. Do folks like the same SPI used for two directions?

Also, for what it’s worth, we demonstrated this method of section 5.4.1 at a previous IETF hackathon.

-Dave

Hi Kent,

[personal opinion …] I have always assumed that the service path ID would be uni-directional given that it would be difficult to avoid collision in all forwarding scenarios. If you look at a basic SFC a-b-c and the service index is set to 255 at the classifiers a & c (which imho will be the normal practice) then at b you would have a conflict if the same service path ID is used in both directions.

Jim

Thanks.

Kent

---

From: Dave Dolson <[email-masked]>
Date: Mon, 17 Jul 2017 16:16:16 +0000

"Spiral" means a path can traverse the same SF twice.
E.g., you might do "before" and "after" policies from the same SF device.

From: Kent Leung (kleung) [mailto:[email-masked]]
Sent: Monday, July 17, 2017 3:37 PM
To: Dave Dolson; Roberta Maglione (robmgl); James N Guichard
Cc: [email-masked]
Subject: RE: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Kent

Inviato da iPad

Jim

-Dave

Hi Kent,

Jim

Thanks.

Kent

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 17 Jul 2017 16:20:52 +0000

Thanks for clarifying the term. So the flow is going through the service path once, but re-enters the same SF in transit. In that case, the counter for the service path and counter for each hop would still be helpful.

Kent

From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, July 17, 2017 6:16 PM
To: Kent Leung (kleung) <[email-masked]>; Roberta Maglione (robmgl) <[email-masked]>; James N Guichard <[email-masked]>
Cc: [email-masked]
Subject: RE: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Cc: [email-masked]<mailto:[email-masked]>

Kent

From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, July 17, 2017 3:01 PM
To: Roberta Maglione (robmgl) <[email-masked]<mailto:[email-masked]>>; James N Guichard <[email-masked]<mailto:[email-masked]>>
Cc: Kent Leung (kleung) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Inviato da iPad

Jim

-Dave

Hi Kent,

Jim

Thanks.

Kent

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 18 Jul 2017 08:54:17 +0000

Hi Reinaldo. I agree we need to get agreement in WG and update the draft soon as folks are unsure what to implement.

It seems most folks have chimed in. Here’s the latest count. I’m putting names down to make sure the count is accurate.

-          (2) Dave, Joel

-          (6) Sumandra, Jim, Kent, Renaldo, Roberta, Paul

Do we have some rough consensus yet? Or wait for more opinions to decide?

Kent

From: Reinaldo Penno (repenno)
Sent: Monday, July 17, 2017 3:59 PM
To: Kent Leung (kleung) <[email-masked]>; Dave Dolson <[email-masked]>; Roberta Maglione (robmgl) <[email-masked]>; James N Guichard <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Hi Kent/others,

Thanks,

From: sfc <[email-masked]<mailto:[email-masked]>> on behalf of "Kent Leung (kleung)" <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 17, 2017 at 10:36 AM
To: Dave Dolson <[email-masked]<mailto:[email-masked]>>, "Roberta Maglione (robmgl)" <[email-masked]<mailto:[email-masked]>>, James N Guichard <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Kent

Inviato da iPad

Jim

-Dave

Hi Kent,

Jim

Thanks.

Kent

---

From: Kyle Larose <[email-masked]>
Date: Tue, 18 Jul 2017 08:56:01 +0000

I support 5.4.1 (one SPI), for the same reasons Dave mentioned.

From: sfc [mailto:[email-masked]] On Behalf Of Kent Leung (kleung)
Sent: Tuesday, July 18, 2017 2:24 PM
To: Reinaldo Penno (repenno); Dave Dolson; Roberta Maglione (robmgl); James N Guichard
Cc: [email-masked]
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

-          (2) Dave, Joel

Kent

To: Kent Leung (kleung) <[email-masked]<mailto:[email-masked]>>; Dave Dolson <[email-masked]<mailto:[email-masked]>>; Roberta Maglione (robmgl) <[email-masked]<mailto:[email-masked]>>; James N Guichard <[email-masked]<mailto:[email-masked]>>

Hi Kent/others,

Thanks,

Kent

Inviato da iPad

Jim

-Dave

Hi Kent,

Jim

Thanks.

Kent

---

From: Dave Dolson <[email-masked]>
Date: Tue, 18 Jul 2017 09:14:42 +0000

I was looking at 5.4.2 again, and from the arguments for it, I’m not sure folks realize it is the upper bit that it used for direction. So if presented in decimal, e.g., paths 4 and 2147483652 are opposite directions (pairs). For some reason I’d been thinking even/odd pairs.
Kent pointed out to me that this is a UI issue, but if we are going to lean on the UI crutch, all of the approaches are equally easy to understand.

Also, I think we found it appealing that the reverse can be calculated with one field change instead of two.

-Dave

From: Kyle Larose
Sent: Tuesday, July 18, 2017 10:56 AM
To: Kent Leung (kleung); Reinaldo Penno (repenno); Dave Dolson; Roberta Maglione (robmgl); James N Guichard
Cc: [email-masked]
Subject: RE: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

-          (2) Dave, Joel

Kent

Hi Kent/others,

Thanks,

Kent

Inviato da iPad

Jim

-Dave

Hi Kent,

Jim

Thanks.

Kent

---

From: Ron Parker <[email-masked]>
Date: Tue, 18 Jul 2017 13:12:11 +0000

I support 5.4.1 (single SPI with direction indicated in SI).   That being said, the approach effectively reduces SI by 1 bit and reallocates that bit to direction.   Is it feasible to instead be explicit by creating an direction bit?   Also, how do we refer to directions?   East/West?   North/South?  Left/Right?   Upstream/Downstream?

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of Kent Leung (kleung)
Sent: Tuesday, July 18, 2017 4:54 AM
To: Reinaldo Penno (repenno) <[email-masked]>; Dave Dolson <[email-masked]>; Roberta Maglione (robmgl) <[email-masked]>; James N Guichard <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

-        (2) Dave, Joel

Kent

Hi Kent/others,

Thanks,

Kent

Inviato da iPad

Jim

-Dave

Hi Kent,

Jim

Thanks.

Kent
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc<https://url.serverdata.net/?a_R6iwBQImYWCr69g6-h0raXDRY2EORuQb3vcjuo_jYzi8LHrrWr1VlAzSt23U6FhEXpHwQ1RPMguMZ7RGyHHPw~~>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 18 Jul 2017 09:58:02 -0400

Since there are not always two directions, I would prefer not to define 
that bit as always meaning direction.  I do not mind if the bit is used 
by configuration in a directional fashion.  (It is odd, but clearly works.)

Yours,
Joel

On 7/18/17 9:12 AM, Ron Parker wrote:
> I support 5.4.1 (single SPI with direction indicated in SI).   That 
> being said, the approach effectively reduces SI by 1 bit and reallocates 
> that bit to direction.   Is it feasible to instead be explicit by 
> creating an direction bit?   Also, how do we refer to directions?   
> East/West?   North/South?  Left/Right?   Upstream/Downstream?
> 
>     Ron
> 
> *Sent:* Tuesday, July 18, 2017 4:54 AM
> *To:* Reinaldo Penno (repenno) <[email-masked]>; Dave Dolson 
> <[email-masked]>; Roberta Maglione (robmgl) <[email-masked]>; 
> James N Guichard <[email-masked]>
> *Cc:* [email-masked]
> Hi Reinaldo. I agree we need to get agreement in WG and update the draft 
> soon as folks are unsure what to implement.
> 
> It seems most folks have chimed in. Here’s the latest count. I’m putting 
> names down to make sure the count is accurate.
> 
> -(2) Dave, Joel
> -(6) Sumandra, Jim, Kent, Renaldo, Roberta, Paul
> 
> *From:* Reinaldo Penno (repenno)
> *Sent:* Monday, July 17, 2017 3:59 PM
> *To:* Kent Leung (kleung) <[email-masked] <mailto:[email-masked]>>; 
> Dave Dolson <[email-masked] <mailto:[email-masked]>>; 
> Roberta Maglione (robmgl) <[email-masked] <mailto:[email-masked]>>; 
> James N Guichard <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>
> this decision is quite important for real deployments, as opposed to 
> demos and related.  I hope as the first step we all agree that we cannot 
> have more than one way of interpreting directionality of paths and 
> associated reverse paths. That would be an interoperability nightmare 
> and reduce the usefulness of NSH considerably.
> 
> *From: *sfc <[email-masked] <mailto:[email-masked]>> on 
> behalf of "Kent Leung (kleung)" <[email-masked] <mailto:[email-masked]>>
> *Date: *Monday, July 17, 2017 at 10:36 AM
> *To: *Dave Dolson <[email-masked] <mailto:[email-masked]>>, 
> "Roberta Maglione (robmgl)" <[email-masked] 
> <mailto:[email-masked]>>, James N Guichard 
> <[email-masked] <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> *Subject: *Re: [sfc] clarification on Service Path ID for 
> draft-penno-sfc-packet
> 
> Why can’t there be stats for per SPI and more granular stats for per 
> SPI/SI? They seem to serve different purposes. The former is providing 
> counters for all flows in each service path. The latter is provide 
> counters for all flows served at each hop in the service path.
> 
> Can you explain the “spiral” scenario and how that pertains to 
> usefulness of having per service path stats? Thanks.
> 
> Kent
> 
> *From:* Dave Dolson [mailto:[email-masked]]
> *Sent:* Monday, July 17, 2017 3:01 PM
> *To:* Roberta Maglione (robmgl) <[email-masked] 
> <mailto:[email-masked]>>; James N Guichard 
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* Kent Leung (kleung) <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
> *Subject:* RE: [sfc] clarification on Service Path ID for 
> draft-penno-sfc-packet
> 
> *From:*Roberta Maglione (robmgl) [mailto:[email-masked]]
> *Sent:* Monday, July 17, 2017 11:00 AM
> *To:* James N Guichard
> *Cc:* Dave Dolson; Kent Leung (kleung); [email-masked] <mailto:[email-masked]>
> I agree on the operational aspect: having different SPI's for each 
> direction simplifies the troubleshooting procedures, as statistics on 
> the packets counters for each direction on each SF, can be displayed 
> just based on SPI.
> 
> Regards,
> 
> Roberta
> 
> Inviato da iPad
> 
> 
> Il giorno 15 lug 2017, alle ore 01:09, James N Guichard 
> <[email-masked] <mailto:[email-masked]>> ha 
> scritto:
> 
>     Yes understood but I was assuming no manipulation of the SI and my
>     point was more from an operational perspective; if I use the same
>     path ID in both directions then I cannot immediately tell in which
>     direction the packets are flowing unless I go one step deeper and
>     look at the SI leading to a correlation of SPI + SI to be able to
>     figure out my traffic matrix. Not so if the SPI is uni-directional.
> 
>     Jim
> 
>     *From:* Dave Dolson [mailto:[email-masked]]
>     *Sent:* Friday, July 14, 2017 2:51 PM
>     *To:* James N Guichard <[email-masked]
>     <mailto:[email-masked]>>; Kent Leung (kleung)
>     <[email-masked] <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>     *Subject:* RE: clarification on Service Path ID for
>     draft-penno-sfc-packet
> 
>     Personally, I find use of a single SPI to be more elegant,
>       consuming only one path ID instead of two. (section 5.4.1).
> 
>     *To:* Kent Leung (kleung); [email-masked] <mailto:[email-masked]>
>     Hi. We are working on a revision for this draft. There were 4
>     proposed solution options in section 5. During some discussions,
>     most folks seem to favor the use of algorithmic method in section
>     5.4. However, there are 2 sub-options. One is based on same Service
>     Path ID and using Service Index to determine flow direction (sect.
>     5.4.1). The other is based on setting high order bit on Serve Path
>     ID, which determines flow direction (sect. 5.4.2). There are mixed
>     opinions. One reason is that there may be the assumption the Service
>     Path ID is uni-directional. No explicit wording of that nature has
>     been encountered in the RFCs, maybe we missed something?
> 
>     If Serve Path ID is required to be uni-directional, then the answer
>     is easy (=> 5.4.2). We would like to solicit WG comments to get
>     rough consensus and revised the next version with that solution.
>     This problem is critical to address for Service Function that
>     generate packet in reverse direction, especially security service
>     functions as mentioned in draft-wang-sfc-ns-use-cases.
> 
>     Thanks.
> 
>     Kent
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://url.serverdata.net/?a_R6iwBQImYWCr69g6-h0raXDRY2EORuQb3vcjuo_jYzi8LHrrWr1VlAzSt23U6FhEXpHwQ1RPMguMZ7RGyHHPw~~>
> 
> 
>

---

From: Ron Parker <[email-masked]>
Date: Tue, 18 Jul 2017 14:11:36 +0000

Good point on the optionality of this bidirectional concept.

For the bidirectional case, we would ultimately like to know the correlation of the 2 paths.    I'm thinking that this is more, even, than correlating the "forward" SPI and the "reverse" SPI.   It also becomes useful to correlate the position of a particular service function.   A strict presumption of mirrored order for the 2 directions does not always hold.   Lets say in the forward direction we want SF types A, B, C, D but in the reverse direction we want A, D, C, B.   It would be useful to know that SF D appears at the 4th position of the forward flow and the 2nd position of the correlated reverse flow.   This starts to become too heavy to insert into the encapsulation itself.   Instead, this full knowledge can be achieved through control plane distribution and stateful elements (e.g., SFF, SF).

So, the encapsulation can carry all of the correlation information, none of the correlation information, or some of the correlation information.    I'm not so sure "some" is that useful.

   Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Tuesday, July 18, 2017 9:58 AM
To: Ron Parker <[email-masked]>; Kent Leung (kleung) <[email-masked]>; Reinaldo Penno (repenno) <[email-masked]>; Dave Dolson <[email-masked]>; Roberta Maglione (robmgl) <[email-masked]>; James N Guichard <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Since there are not always two directions, I would prefer not to define that bit as always meaning direction.  I do not mind if the bit is used by configuration in a directional fashion.  (It is odd, but clearly works.)

Yours,
Joel

On 7/18/17 9:12 AM, Ron Parker wrote:
> Hi Reinaldo. I agree we need to get agreement in WG and update the 
> draft soon as folks are unsure what to implement.
> 
> It seems most folks have chimed in. Here’s the latest count. I’m 
> putting names down to make sure the count is accurate.
> 
> *To:* Kent Leung (kleung) <[email-masked] 
> <mailto:[email-masked]>>; Dave Dolson <[email-masked] 
> <mailto:[email-masked]>>; Roberta Maglione (robmgl) 
> <[email-masked] <mailto:[email-masked]>>; James N Guichard 
> demos and related.  I hope as the first step we all agree that we 
> cannot have more than one way of interpreting directionality of paths 
> and associated reverse paths. That would be an interoperability 
> nightmare and reduce the usefulness of NSH considerably.
> 
> *To: *Dave Dolson <[email-masked] 
> <mailto:[email-masked]>>, "Roberta Maglione (robmgl)" 
> <[email-masked] <mailto:[email-masked]>>, James N Guichard 
> *Cc:* Kent Leung (kleung) <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>     https://url.serverdata.net/?a_R6iwBQImYWCr69g6-h0raXDRY2EORuQb3vcjuo_jYzi8LHrrWr1VlAzSt23U6FhEXpHwQ1RPMguMZ7RGyHHPw~~
>     
> <https://url.serverdata.net/?a_R6iwBQImYWCr69g6-h0raXDRY2EORuQb3vcjuo_
> jYzi8LHrrWr1VlAzSt23U6FhEXpHwQ1RPMguMZ7RGyHHPw~~>
> 
> 
> 
> https://url.serverdata.net/?a_R6iwBQImYWCr69g6-h0raXDRY2EORuQb3vcjuo_j
> Yzi8LHrrWr1VlAzSt23U6FhEXpHwQ1RPMguMZ7RGyHHPw~~
>

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 19 Jul 2017 08:29:40 +0000

Hi Ron. The control plane (sect. 5.1) and encoded (sect. 5.3) methods are covered in the draft along with the pros and cons of each of the options. A method to generate asymmetric paths for asymmetric SFC is described in sect. 6. This technique is based on symmetric SI sequence with NOP. Both algorithmic (sects. 5.4.1 & 5.4.2) methods can leverage this SI scheme to support asymmetric SFC. So maybe we need to reword the draft better to explain that mirrored order for both directions is not assumed.

Just updating the running count:

-	(4) Dave, Joel, Ron, Kyle

 Kent

-----Original Message-----
From: Ron Parker [mailto:[email-masked]] 
Sent: Tuesday, July 18, 2017 4:12 PM
To: Joel M. Halpern <[email-masked]>; Kent Leung (kleung) <[email-masked]>; Reinaldo Penno (repenno) <[email-masked]>; Dave Dolson <[email-masked]>; Roberta Maglione (robmgl) <[email-masked]>; James N Guichard <[email-masked]>
Cc: [email-masked]
Subject: RE: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

   Ron

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]]
Sent: Tuesday, July 18, 2017 9:58 AM
To: Ron Parker <[email-masked]>; Kent Leung (kleung) <[email-masked]>; Reinaldo Penno (repenno) <[email-masked]>; Dave Dolson <[email-masked]>; Roberta Maglione (robmgl) <[email-masked]>; James N Guichard <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 19 Jul 2017 10:37:40 -0400

Just for clarity, my preference between the algorithmic encoding methods 
is quite small.
Yours,
Joel

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 19 Jul 2017 15:48:20 +0000

My preference (as I explained to Dave offline) is based a lot on current implementations and the draft. 

- I re-read NSH base and all examples have, as far as I can tell, unidirectional SPI. It might be legacy, an overlook, but that it is how I interpret it
- Many vendors might have taken that to heart. Yes, I know, you should not cast in stone your implementations based on draft…still.

Irrespective if we change that or not I believe NSH base should clearly state the relationship between forwarding and Path (or Path + ID). Saying nothing is asking for one of those IETF mile-long threads where somebody will argue that saying nothing is the same as ‘allowed’.

Thanks,

On 7/19/17, 11:37 AM, "Joel M. Halpern" <[email-masked]> wrote:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 19 Jul 2017 11:50:51 -0400

I beg you not to ask for more changes to NSH.  The document is in good 
shape.  It will never be perfect.  We need to finish it.

Having said that, if you really think we need to fix something in the 
document, you need to say so on the list.  I would VERY strongly request 
that if you do so, please include explicit new text and a clear 
description of where you think it goes.

Yours,
Joel

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 19 Jul 2017 15:55:04 +0000

Oh, how can I not defer toa request like that (;)

We can always say that sfc-packet ‘updates rfc xxxx’.

On 7/19/17, 12:50 PM, "Joel M. Halpern" <[email-masked]> wrote:

    
    Yours,
    Joel

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 25 Jul 2017 22:32:03 +0000

It seems enough time has elapsed for folks to chime in their preferences on the solution option. 

I believe that communication between two endpoints is based on flow traffic from source to destination. A service path dictates which service functions are applied for the traffic. Technically, a flow is terminated at the receiving endpoint. So, the service path ended at the last hop. Communication may be uni-directional (one flow) or bi-directional (two flows). RFC 7665 describes SFC as steering of traffic flows through service functions. My interpretation is that the service path is associated with the flow. A new flow going in the reverse direction should be treated with a new service path (set up to handle that flow) and not continuation of the same service path (set up to handle original flow) in the forward direction. Seems logical to me from that perspective.

The service path ID is used to identify the service path and the service index is used to identify the location within the service path as stated in current NSH draft:

" NSH contains a Service Path Identifier (SPI) and a Service Index (SI).  The SPI is, as per its name, an identifier" of the service path. 

"The Service Index provides an indication of location within a service path."

Given that both options support asymmetric and symmetric SFCs, has anyone change their mind on selecting an option to go forth? Based on the feedback, it seems that we all agree to choose one solution instead of allowing multiple options for addressing reverse packet generation scenario. Now, what should we need to do to achieve that? Rock-paper-scissor? :)

Current count as Joel is OK with either option.

-	(7) Sumandra, Jim, Kent, Renaldo, Roberta, Paul, Joel
 
Kent

<snip>

---

From: Dave Dolson <[email-masked]>
Date: Wed, 26 Jul 2017 01:55:04 +0000

Are the 5.4.2 folks willing to consider using the lower bit for odd/even pairs instead of the upper bit?

David Dolson
Sandvine
  Original Message
From: Kent Leung (kleung)
Sent: Tuesday, July 25, 2017 6:32 PM
To: Reinaldo Penno (repenno); Joel M. Halpern; Ron Parker; Dave Dolson; Roberta Maglione (robmgl); James N Guichard
Cc: [email-masked]
Subject: RE: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Kent

<snip>

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 26 Jul 2017 07:07:43 +0000

I think that would be a good compromise. If that would swing some of the 5.4.1 folks over, then I'm in favor of such an idea.

Kent
 
-----Original Message-----
From: Dave Dolson [mailto:[email-masked]] 
Sent: Tuesday, July 25, 2017 6:55 PM
To: Kent Leung (kleung) <[email-masked]>; Reinaldo Penno (repenno) <[email-masked]>; Joel M. Halpern <[email-masked]>; Ron Parker <[email-masked]>; Roberta Maglione (robmgl) <[email-masked]>; James N Guichard <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

David Dolson
Sandvine
  Original Message

Kent

<snip>

---

From: <[email-masked]>
Date: Wed, 26 Jul 2017 08:39:01 +0000

Hi Kent,

FWIW, there was an attempt to define this term in https://tools.ietf.org/html/draft-boucadair-sfc-requirements-06. Below an excerpt from that draft:

==
   o  Service Function Loop: If a Service Function Chain is structured
      to not invoke Service Functions multiple times, a loop is the
      error that occurs when the same Service Function is invoked
      several times when handling data bound to that Service Function
      Chain.  In other words, a loop denotes an error that occurs when a
      packet handled by a Service Function, forwarded onwards, and
      arrives once again at that Service Function while this is not
      allowed by the Service Function Chain it is bound to.

   o  Service Function Spiral: denotes a Service Function Chain in which
      data is handled by a Service Function, forwarded onwards, and
      arrives once again at that Service Function.

      *  Note that some Service Functions support built-in functions to
         accommodate spirals; these service-specific functions may
         require that the data received in a spiral should differ in a
         way that will result in a different processing decision than
         the original data.  This document does not make such
         assumption.

      *  A Service Function Chain may involve one or more Service
         Function Spirals.

      *  Unlike Service Function loop, spirals are not considered as
         errors.
==

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Kent Leung (kleung)
Envoyé : lundi 17 juillet 2017 15:37
À : Dave Dolson; Roberta Maglione (robmgl); James N Guichard
Cc : [email-masked]
Objet : Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Kent

Inviato da iPad

Jim

-Dave

Hi Kent,

Jim

Thanks.

Kent

---

From: <[email-masked]>
Date: Wed, 26 Jul 2017 11:22:09 +0000

Re-,

I do have the following comments:

* I do agree with Reinaldo with regards to unidirectional SPIs.

* Assuming by default that the SPI is inherited from the received NSH packet may lead to failures. Consider the example of a chain with NATs and FWs. Because the packet will be generated by an SF (that may not be the ultimate destination of the original packet), no corresponding state will be found in those NATs (non EIM/EIF)/FW. I'm not sure whether "no-op" feature softens the problem. 

* Generating packets by an SF may not be triggered by a received NSH packet. Obviously, inheriting NSH-related information may not be possible in that case. A typical example is a service chain that involves an MPTCP proxy. The proxy can at any time during the connection add new subflows to the source.    

* I don't think that we should assume that SF-generated packets must always be stamped with an NSH header. This is IMHO deployment-specific. Like any other packets generated by a (SFC-unware) node in the forwarding path, packets generated by an SFC-aware SF should be able to fly back without any SFC processing at all, too. Again, this is deployment-specific. 

* Putting aside other aspects, that are btw discussed appropriately in the draft such as metadata cloning, which destination IP address to use to send back the packet? Some complications may arise when NATs are involved.

Given that, I'm less for an algorithmic approach but for control-based approach at the SFC-aware SF and/or classifier.  

Cheers,
Med

> -----Message d'origine-----
> Envoyé : mercredi 26 juillet 2017 00:32
> À : Reinaldo Penno (repenno); Joel M. Halpern; Ron Parker; Dave Dolson;
> Roberta Maglione (robmgl); James N Guichard
> Cc : [email-masked]
> I believe that communication between two endpoints is based on flow
> traffic from source to destination. A service path dictates which service
> functions are applied for the traffic. Technically, a flow is terminated
> at the receiving endpoint. So, the service path ended at the last hop.
> Communication may be uni-directional (one flow) or bi-directional (two
> flows). RFC 7665 describes SFC as steering of traffic flows through
> service functions. My interpretation is that the service path is
> associated with the flow. A new flow going in the reverse direction should
> be treated with a new service path (set up to handle that flow) and not
> continuation of the same service path (set up to handle original flow) in
> the forward direction. Seems logical to me from that perspective.
> 
> The service path ID is used to identify the service path and the service
> index is used to identify the location within the service path as stated
> in current NSH draft:
> 
> " NSH contains a Service Path Identifier (SPI) and a Service Index (SI).
> The SPI is, as per its name, an identifier" of the service path.
> 
> Given that both options support asymmetric and symmetric SFCs, has anyone
> change their mind on selecting an option to go forth? Based on the
> feedback, it seems that we all agree to choose one solution instead of
> allowing multiple options for addressing reverse packet generation
> scenario. Now, what should we need to do to achieve that? Rock-paper-
> scissor? :)
>

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 26 Jul 2017 15:31:14 +0000

Hi Mohamed. Thanks for the reference. Dave did explain "spiral" as described below.

Kent

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 26, 2017 1:39 AM
To: Kent Leung (kleung) <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Hi Kent,

==

Cheers,
Med

Cc : [email-masked]<mailto:[email-masked]>

Kent

Inviato da iPad

Jim

-Dave

Hi Kent,

Jim

Thanks.

Kent

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 26 Jul 2017 16:08:00 +0000

Hi Mohamed. See comments below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 26, 2017 4:22 AM
To: Kent Leung (kleung) <[email-masked]>
Cc: [email-masked]
Subject: RE: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Re-,

KL> OK. One more for unidirectional SPI.

KL> There are various use cases when SF generates packet. See https://tools.ietf.org/html/draft-wang-sfc-ns-use-cases-03#page-14. We believe this draft is helpful in understanding various scenarios and want to pursue informational track. If you or others want to help, please let us know. The NOP is dealing with asymmetric SFC.

KL> Agree. See draft mentioned above.

KL> Agree. See Option #2 in the reference above. Let us know if that's clear.

KL> The draft-penno-sfc-packet is dealing with this use case, "generate packets in the reverse flow direction destined to the source of the current in-process packet/flow." So the dest IP address is the source IP address of the received packet. A packet that is NAT'ed needs to be addressed as an independent topic.

KL> The control plane option (sect. 5.1) does require controller/SF interface. There are additional operational responsibility on SF to maintain state for reverse path, controller to ensure consistency between SF and SFF for SPIs, timing window when SPIs are configured, etc. It seems algorithmic method avoids chances for problems to be encountered in deployment. Simple is better in terms there's only one touch point (automatic) vs. two touch points (control).

Thanks for your feedback.

Kent

Cheers,
Med

> De : sfc [mailto:[email-masked]] De la part de Kent Leung 
> (kleung) Envoyé : mercredi 26 juillet 2017 00:32 À : Reinaldo Penno 
> (repenno); Joel M. Halpern; Ron Parker; Dave Dolson; Roberta Maglione 
> (robmgl); James N Guichard Cc : [email-masked] Objet : Re: [sfc] 
> clarification on Service Path ID for draft-penno-sfc- packet
> 
> traffic from source to destination. A service path dictates which 
> service functions are applied for the traffic. Technically, a flow is 
> terminated at the receiving endpoint. So, the service path ended at the last hop.
> associated with the flow. A new flow going in the reverse direction 
> should be treated with a new service path (set up to handle that flow) 
> and not continuation of the same service path (set up to handle 
> original flow) in the forward direction. Seems logical to me from that perspective.
> 
> The service path ID is used to identify the service path and the 
> service index is used to identify the location within the service path 
> as stated in current NSH draft:
> 
> Given that both options support asymmetric and symmetric SFCs, has 
> anyone change their mind on selecting an option to go forth? Based on 
> the feedback, it seems that we all agree to choose one solution 
> instead of allowing multiple options for addressing reverse packet 
> generation scenario. Now, what should we need to do to achieve that? 
> Rock-paper- scissor? :)
>

---

From: <[email-masked]>
Date: Thu, 27 Jul 2017 06:36:21 +0000

Hi Kent, 

Please see inline. 

Cheers,
Med

> De : Kent Leung (kleung) [mailto:[email-masked]]
> Envoyé : mercredi 26 juillet 2017 18:08
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]
> Objet : RE: [sfc] clarification on Service Path ID for draft-penno-sfc-
> packet
> 
> * Assuming by default that the SPI is inherited from the received NSH
> packet may lead to failures. Consider the example of a chain with NATs and
> FWs. Because the packet will be generated by an SF (that may not be the
> ultimate destination of the original packet), no corresponding state will
> be found in those NATs (non EIM/EIF)/FW. I'm not sure whether "no-op"
> feature softens the problem.
> 
> KL> There are various use cases when SF generates packet. See
> https://tools.ietf.org/html/draft-wang-sfc-ns-use-cases-03#page-14. We
> believe this draft is helpful in understanding various scenarios and want
> to pursue informational track. If you or others want to help, please let
> us know. The NOP is dealing with asymmetric SFC.

[Med] Thanks for the pointer. draft-wang-sfc-ns-use-cases mixes various functions of a "firewall": TCP proxy, NAT, stateful filtering, etc.  
My main comment is that the packet generated by an SF may be blocked by other stateful SFs because no mapping will be matching packets from the SF. I would expect such details to be included in the sfc-packet draft.  

> 
> 
> * Generating packets by an SF may not be triggered by a received NSH
> packet. Obviously, inheriting NSH-related information may not be possible
> in that case. A typical example is a service chain that involves an MPTCP
> proxy. The proxy can at any time during the connection add new subflows to
> the source.
> 

[Med] I would expect this to be discussed in the sfc-packet draft since this have an implication on the solution to be recommended (if we need such reco). Typically, how algorithmic approaches solves the issue for this particular case should be discussed. 

> 
> 
> * I don't think that we should assume that SF-generated packets must
> always be stamped with an NSH header. This is IMHO deployment-specific.
> Like any other packets generated by a (SFC-unware) node in the forwarding
> path, packets generated by an SFC-aware SF should be able to fly back
> without any SFC processing at all, too. Again, this is deployment-
> specific.
> 

[Med] Idem as above. I would expect this to be covered in the sfc-packet I-D. 

> 
> 
> * Putting aside other aspects, that are btw discussed appropriately in the
> draft such as metadata cloning, which destination IP address to use to
> send back the packet? Some complications may arise when NATs are involved.
> 
> KL> The draft-penno-sfc-packet is dealing with this use case, "generate
> packets in the reverse flow direction destined to the source of the
> current in-process packet/flow." So the dest IP address is the source IP
> address of the received packet.

[Med] This may be intuitive but this cannot be generalized to all SFs. Let's consider the example of an MPTCP proxy that receives an ADD_ADDR from a client, the MPTCP proxy can send back an MP_JOIN to the address conveyed in ADD_ADDR, not the source IP address of the initial packet. 

 A packet that is NAT'ed needs to be
> addressed as an independent topic.
> 

[Med] Why NAT should be treated as a special SF?

> 
> Given that, I'm less for an algorithmic approach but for control-based
> approach at the SFC-aware SF and/or classifier.
> 
> KL> The control plane option (sect. 5.1) does require controller/SF
> interface.

[Med] Yes. That interface can leverage on existing interface to provision other non-SFC SF features. Further, as mentioned above, packets generated by an SF may or may not be stamped with an NSH header.  

 There are additional operational responsibility on SF to
> maintain state for reverse path, controller to ensure consistency between
> SF and SFF for SPIs, timing window when SPIs are configured, etc. It seems
> algorithmic method avoids chances for problems to be encountered in
> deployment.

[Med] I disagree. See the example I cited above. The algorithmic approach may work with some assumptions on the SFs; those assumptions are not generic.  

 Simple is better in terms there's only one touch point
> (automatic) vs. two touch points (control).

[Med] I cannot argue that it is simple at this stage.

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Fri, 28 Jul 2017 21:25:09 +0000

Hi Med. Thanks for clarifying with the MPTCP example.

In general, draft-wang-sfc-ns-use-cases covers the two fundamental use cases in sects 4.3.1 and 4.3.2. The solution for the former is documented in draft-penno-sfc-packet, which puts the generated packet for "reverse flow direction" in the correct reverse SPI/SI. The latter is when SF initiates a new flow, which is not the problem statement addressed by draft-penno-sfc-packet, AFAIK. I think the right solution for this particular scenario would be using internal classifier or external classifier.

The MPTCP MP_JOIN example seems to map to the SF initiated flow use case. Perhaps an internal classifier in SF would map associated subflows to a common service path used by the MPTCP session. Just a thought for implementation option.

Are you asking to expand the scope of this draft beyond injected new packet to include the initiated connection use case? I'll let other authors chime in if that's the case.

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 26, 2017 11:36 PM
To: Kent Leung (kleung) <[email-masked]>
Cc: [email-masked]
Subject: RE: [sfc] clarification on Service Path ID for draft-penno-sfc-packet

Hi Kent, 

Please see inline. 

Cheers,
Med

> De : Kent Leung (kleung) [mailto:[email-masked]] Envoyé : mercredi 
> 26 juillet 2017 18:08 À : BOUCADAIR Mohamed IMT/OLN Cc : [email-masked] 
> Objet : RE: [sfc] clarification on Service Path ID for 
> draft-penno-sfc- packet
> 
> Subject: RE: [sfc] clarification on Service Path ID for 
> draft-penno-sfc- packet
> 
> Re-,
> 
> packet may lead to failures. Consider the example of a chain with NATs 
> and FWs. Because the packet will be generated by an SF (that may not 
> be the ultimate destination of the original packet), no corresponding 
> state will be found in those NATs (non EIM/EIF)/FW. I'm not sure whether "no-op"
> believe this draft is helpful in understanding various scenarios and 
> want to pursue informational track. If you or others want to help, 
> please let us know. The NOP is dealing with asymmetric SFC.

> packet. Obviously, inheriting NSH-related information may not be 
> possible in that case. A typical example is a service chain that 
> involves an MPTCP proxy. The proxy can at any time during the 
> connection add new subflows to the source.
> 

> Like any other packets generated by a (SFC-unware) node in the 
> forwarding path, packets generated by an SFC-aware SF should be able 
> to fly back without any SFC processing at all, too. Again, this is 
> deployment- specific.
> 

> 
> 
> * Putting aside other aspects, that are btw discussed appropriately in 
> the draft such as metadata cloning, which destination IP address to 
> use to send back the packet? Some complications may arise when NATs are involved.
> 
> KL> The draft-penno-sfc-packet is dealing with this use case, 
> KL> "generate
> current in-process packet/flow." So the dest IP address is the source 
> IP address of the received packet.

> maintain state for reverse path, controller to ensure consistency 
> between SF and SFF for SPIs, timing window when SPIs are configured, 
> etc. It seems algorithmic method avoids chances for problems to be 
> encountered in deployment.

> > (repenno); Joel M. Halpern; Ron Parker; Dave Dolson; Roberta 
> > Maglione (robmgl); James N Guichard Cc : [email-masked] Objet : Re: 
> > [sfc] clarification on Service Path ID for draft-penno-sfc- packet
> >
> > service functions are applied for the traffic. Technically, a flow 
> > is terminated at the receiving endpoint. So, the service path ended 
> > at the
> last hop.
> > Communication may be uni-directional (one flow) or bi-directional 
> > (two flows). RFC 7665 describes SFC as steering of traffic flows 
> > through service functions. My interpretation is that the service 
> > path is associated with the flow. A new flow going in the reverse 
> > direction should be treated with a new service path (set up to 
> > handle that flow) and not continuation of the same service path (set 
> > up to handle original flow) in the forward direction. Seems logical 
> > to me from that
> perspective.
> >
> > service index is used to identify the location within the service 
> > path as stated in current NSH draft:
> >
> > anyone change their mind on selecting an option to go forth? Based 
> > on the feedback, it seems that we all agree to choose one solution