Subject: [sfc] Doubt about draft-ietf-sfc-nsh-12

From: "lizho.jin" <[email-masked]>
Date: Thu, 23 Mar 2017 23:15:16 +0800

Hi Authors,

I have a doubt with following description:

Next Protocol: indicates the protocol type of the encapsulated data.
NSH does not alter the inner payload, and the semantics on the inner
protocol remain unchanged due to NSH service function chaining.
Please see IANA Considerations section below.

It says NSH does not alter the inner payload, but what if the SF is NAT,

then the payload will be changed, right?

Regards

Lizhong

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 Mar 2017 11:24:03 -0400

The content of the inner payload may change.  Lots of service functions 
change the content.  NAT, HTTP annotators, ...
THe semantics of the inner protocol (TCP is still TCP,...) remain the 
same.  if the semantics are changing, then the service function 
terminates one chain and starts another.

Yours,
Joel

On 3/23/17 11:15 AM, lizho.jin wrote:
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Kyle Larose <[email-masked]>
Date: Thu, 23 Mar 2017 15:30:49 +0000

Hi,

> -----Original Message-----
> From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Thursday, March 23, 2017 11:24 AM
> To: lizho.jin; sfc; paulq; uri.elzur
> Subject: Re: [sfc] Doubt about draft-ietf-sfc-nsh-12
> 
> THe semantics of the inner protocol (TCP is still TCP,...) remain the same.
> if the semantics are changing, then the service function terminates one
> chain and starts another.
> 

I interpret the beginning of the text to mean that the act of encapsulating the packet in an NSH header
does not require that the inner payload be changed at all.

This does not mean that service functions cannot change it; it only means that implementers of the NSH
protocol need not do something special to the packet to push the encapsulation.

---

From: "lizho.jin" <[email-masked]>
Date: Thu, 23 Mar 2017 23:55:15 +0800

Joel,

Thanks for the reply. See inline below.

Regards

Lizhong

On 03/23/2017 23:24，Joel M. Halpern<[email-masked]> wrote：

[Lizhong] then do you mean, a service chain is represented not only by the SPI, but also the Next protocol? There does exist some case to change the Next protocol after function process.

Yours,

Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 Mar 2017 11:58:07 -0400

No, the service function path is does not consider the next_protocol 
field at all.  SFC as a data plane behavior does not care what the next 
protocol is (except possibly for the case of OAM shims, and even those 
do not change the path).

I am not quite sure how you got there from my response.

Again ignoring OAM, as Kyle correctly notes, an SFF does not look at or 
modify the next protocol field.  It may use the carried packet for laod 
balancing in some implementations, but that is outside not mandated by NSH.

It is possible that both Kyle and I are misunderstanding your question.

Yours,
Joel

On 3/23/17 11:55 AM, lizho.jin wrote:
> On 03/23/2017 23:24，Joel M. Halpern<[email-masked]>
> <mailto:[email-masked]> wrote：
>
>     [Lizhong] then do you mean, a service chain is represented not only
>     by the SPI, but also the Next protocol? There does exist some case
>     to change the Next protocol after function process.
>
>     Yours,
>     Joel
>

---

From: Lizhong Jin <[email-masked]>
Date: Fri, 24 Mar 2017 10:18:15 +0800

Hi,
"if the semantics are changing, then the service function
    terminates one chain and starts another."
That's why I thought SFC care about the next protocol (the semantics you
are referring is next protocol).
Anyway I got the actual meaning of the sentence in SFC draft. Thanks Joel
and Kyle for the clarification.

Regards
Lizhong

On Thu, Mar 23, 2017 at 11:58 PM, Joel M. Halpern <[email-masked]>
wrote:

> No, the service function path is does not consider the next_protocol field
> at all.  SFC as a data plane behavior does not care what the next protocol
> is (except possibly for the case of OAM shims, and even those do not change
> the path).
>