IETF Logo Mail Archive

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

Kyle Larose <klarose@sandvine.com> Thu, 23 March 2017 15:30 UTC

Return-Path: <klarose@sandvine.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 EC45B12948E for <sfc@ietfa.amsl.com>; Thu, 23 Mar 2017 08:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 tF8AtZ3kdGjb for <sfc@ietfa.amsl.com>; Thu, 23 Mar 2017 08:30:52 -0700 (PDT)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CB231270FC for <sfc@ietf.org>; Thu, 23 Mar 2017 08:30:52 -0700 (PDT)
Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 23 Mar 2017 11:30:50 -0400
From: Kyle Larose <klarose@sandvine.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, "lizho.jin" <lizho.jin@gmail.com>, sfc <sfc@ietf.org>, paulq <paulq@cisco.com>, "uri.elzur" <uri.elzur@intel.com>
Thread-Topic: [sfc] Doubt about draft-ietf-sfc-nsh-12
Thread-Index: AQHSo+fuTeiD2XxbtEWnHWdHrsxQ7qGizj+A//+95bA=
Date: Thu, 23 Mar 2017 15:30:49 +0000
Message-ID: <D76BBBCF97F57144BB5FCF08007244A7705953C4@wtl-exchp-1.sandvine.com>
References: <0C4ABB6D-6E5F-4C87-8EF0-F8D7FF8C95A9@gmail.com> <66bf1a04-d01a-e651-707f-f325edd9f0ef@joelhalpern.com>
In-Reply-To: <66bf1a04-d01a-e651-707f-f325edd9f0ef@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.200.51]
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/8d7LhWcgzrhwZ3qp-2bL6cIsiko>
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:30:54 -0000

Hi,


> -----Original Message-----
> From: sfc [mailto:sfc-bounces@ietf.org] 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 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.
> 

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.


> 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
> >
> 
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc

v2.23.0 | Report a Bug | By Email