IETF Logo Mail Archive

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

Lizhong Jin <lizho.jin@gmail.com> Fri, 24 March 2017 02:18 UTC

Return-Path: <lizho.jin@gmail.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 CEBFC129464 for <sfc@ietfa.amsl.com>; Thu, 23 Mar 2017 19:18:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 V2a7zzQa-gmF for <sfc@ietfa.amsl.com>; Thu, 23 Mar 2017 19:18:16 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA95D12940C for <sfc@ietf.org>; Thu, 23 Mar 2017 19:18:16 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id 20so882138pfk.2 for <sfc@ietf.org>; Thu, 23 Mar 2017 19:18:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iSnUIUwMmzZJ5tw6qZ5sbPRbzZFDs3arJXrEegvbmD4=; b=D9N4UrpWyS6IpdCEh3igeJZ6szCXb1FsEVkw3CiEQF1SfctdhywYygL3ojO6VkvLmr bV0kU6I90ZOzR6JNI+5Gu+BFmDhpVnLkz1fh0uTSIB4deE60LqAOk41ys3QoSOpO268+ inFAfJjUyCg0cxwdjPZPr+mPsYqrZOS1sdPZhpYmioJpCEtttsKisecvMnWS4Ips09UU 0m9H525fmiYmz4rQZSQqrpWEuoqzMzU3p17W71izGJ9v6A8m7LL5F3XVmGgjUaUKRMek mO9odsqKbsjrZWH3liKlXUp3xicUae83cwq8jxHp+RczB0C7a7eijvfgZ/rQk+t9ntPC bkpA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iSnUIUwMmzZJ5tw6qZ5sbPRbzZFDs3arJXrEegvbmD4=; b=dA/gM6HPh4hub8NUURoh0cdMWD8hnal+AMBfEIayQiq3IWAm/NUjaWuqDg/ZyLvTI7 Rjv4ImKcB9EOtAOwwBi3Jbv7CiaMmSUe8b8UmRBkxtd1Lr+yQiE/JNCB8Pd9fJeZWRG3 PQFYh6rdRT30aFPwabhujV23U6+nuSK9HGr0izs1/DJPtNG5aVyVeSR9T1cIZy4NIV3s JvwUbYIRrxgTuydVkIB6U4aXVd1YCTWDTD34s+SKl3XOz2jnYRrJxlxwqIRe4DICjjMx DVbuDYN2GRj0bTlJMUCKywq1FneXyipYTpPaW4nSfTFm+NUtCoTeXqV+pOE1VPpAG24x XiJg==
X-Gm-Message-State: AFeK/H3hSFww/KfCFGViH1wNukYVEjN8FvH4+8gKOJvG3H7YZ9NzyRQuextjhbEn7Q8y2bMidDKIpkg/GqWDHw==
X-Received: by 10.98.95.197 with SMTP id t188mr6419854pfb.150.1490321896393; Thu, 23 Mar 2017 19:18:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.128.130 with HTTP; Thu, 23 Mar 2017 19:18:15 -0700 (PDT)
In-Reply-To: <f2f47c9f-c3f0-0245-bc6e-1a2d5a7b7812@joelhalpern.com>
References: <0C4ABB6D-6E5F-4C87-8EF0-F8D7FF8C95A9@gmail.com> <66bf1a04-d01a-e651-707f-f325edd9f0ef@joelhalpern.com> <905ED664-B5EC-434C-A823-99C68761E254@gmail.com> <f2f47c9f-c3f0-0245-bc6e-1a2d5a7b7812@joelhalpern.com>
From: Lizhong Jin <lizho.jin@gmail.com>
Date: Fri, 24 Mar 2017 10:18:15 +0800
Message-ID: <CAH==cJw=6Sj436VzParBadF8M1OOUbOstt-dthL_th+Wsb=32w@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: sfc <sfc@ietf.org>, paulq <paulq@cisco.com>, "uri.elzur" <uri.elzur@intel.com>
Content-Type: multipart/alternative; boundary="94eb2c0456a43c5186054b709bb1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/JMgqLDnxi_Y0rGEI4kY13bCqB9Q>
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: Fri, 24 Mar 2017 02:18:19 -0000

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 <jmh@joelhalpern.com>
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).
>
> 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