IETF Logo Mail Archive

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

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 23 March 2017 15:58 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6D812956A for <sfc@ietfa.amsl.com>; Thu, 23 Mar 2017 08:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uarP08eIeYLa for <sfc@ietfa.amsl.com>; Thu, 23 Mar 2017 08:58:09 -0700 (PDT)
Received: from mailb2-alt.tigertech.net (mailb2-alt.tigertech.net [74.114.91.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0F3126C23 for <sfc@ietf.org>; Thu, 23 Mar 2017 08:58:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A9AC830A712; Thu, 23 Mar 2017 08:58:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1490284688; bh=jwibBtIgo9g81fWJJZ8mu0Pnkj2a5QSzM0EdeKKKppM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=gHQzIys69u0+qVkgbdCJ++3vwQ392jFaePe2Yn21gAKyaZMiik8kl80Tri5W2bXaq UiAMKeMUNQ/JPXyvRdtoH8jNQPwUAxbuGG7gMwtCsz2bMDimwt+8QO5TToOD4k6cLF MG70vZreG06m+JViyhCghY24UpXdGM0vZLnJCEV4=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 12BB430A704; Thu, 23 Mar 2017 08:58:07 -0700 (PDT)
To: "lizho.jin" <lizho.jin@gmail.com>
References: <0C4ABB6D-6E5F-4C87-8EF0-F8D7FF8C95A9@gmail.com> <66bf1a04-d01a-e651-707f-f325edd9f0ef@joelhalpern.com> <905ED664-B5EC-434C-A823-99C68761E254@gmail.com>
Cc: sfc <sfc@ietf.org>, paulq <paulq@cisco.com>, "uri.elzur" <uri.elzur@intel.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <f2f47c9f-c3f0-0245-bc6e-1a2d5a7b7812@joelhalpern.com>
Date: Thu, 23 Mar 2017 11:58:07 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <905ED664-B5EC-434C-A823-99C68761E254@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/Vng4oAsY2QfzTnhZ_lKPgGENtrY>
Subject: Re: [sfc] Doubt about draft-ietf-sfc-nsh-12
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2017 15:58:18 -0000

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:
> Joel,
> Thanks for the reply. See inline below.
>
> Regards
> Lizhong
>
> On 03/23/2017 23:24，Joel M. Halpern<jmh@joelhalpern.com>
> <mailto:jmh@joelhalpern.com> wrote：
>
>     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.
>
>     [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
>
>     On 3/23/17 11:15 AM, lizho.jin wrote:
>     > 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
>     >
>     >
>     >
>     > _______________________________________________
>     > sfc mailing list
>     > sfc@ietf.org
>     > https://www.ietf.org/mailman/listinfo/sfc
>     >
>

v2.23.0 | Report a Bug | By Email