Re: [sfc] TTL field within the NSH base header
Dave Dolson <ddolson@sandvine.com> Fri, 28 April 2017 14:33 UTC
Return-Path: <ddolson@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 93A07127866 for <sfc@ietfa.amsl.com>; Fri, 28 Apr 2017 07:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 bL1seLu4zoR4 for <sfc@ietfa.amsl.com>; Fri, 28 Apr 2017 07:33:23 -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 3DE95128B38 for <sfc@ietf.org>; Fri, 28 Apr 2017 07:29:17 -0700 (PDT)
Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 28 Apr 2017 10:29:16 -0400
Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Fri, 28 Apr 2017 10:29:15 -0400
From: Dave Dolson <ddolson@sandvine.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, James N Guichard <james.n.guichard@huawei.com>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: TTL field within the NSH base header
Thread-Index: AdK/h0bahW5bvXGwSoCeYu3QIaIxxgAl9XdgAAMaEWA=
Date: Fri, 28 Apr 2017 14:29:15 +0000
Message-ID: <E8355113905631478EFF04F5AA706E98705BD0A0@wtl-exchp-1.sandvine.com>
References: <BF1BE6D99B52F84AB9B48B7CF6F17DA3DD5F8E@SJCEML701-CHM.china.huawei.com> <787AE7BB302AE849A7480A190F8B933009E5E3B9@OPEXCNORMAD.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933009E5E3B9@OPEXCNORMAD.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.200.114]
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E98705BD0A0wtlexchp1sandvi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/dDRLrtk-KcyFXTojLKJbji1YwlM>
Subject: Re: [sfc] TTL field within the NSH base header
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, 28 Apr 2017 14:33:25 -0000
Med, "SFFs that terminate a service chain MUST forward the packet to attached SFs even if SHL is decremented to 0." I don't think this is right. If TTL/SHL is decremented to 0, this must not be forwarded as NSH. I see that *receiving* a packet with SHL=1 can result in chain termination, i.e., NSH decapsulation. But not forwarding as NSH with SHL=0. -Dave From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Friday, April 28, 2017 9:36 AM To: James N Guichard; sfc@ietf.org Subject: Re: [sfc] TTL field within the NSH base header Hi Jim, all, I have the following comments : · Change "TTL" to "SFF Hop Limit (SHL)" because this field is not about a time to live but about a limit of SFF hops to be crossed. · I don't understand what is meant by "testing". · I suggest to make this change to cover the following points: o SHL should be configurable by the control plane. o Packets can be forwarded to SFs even if SHL is decremented to 0 for the terminating SFF. o I don't think it is a good idea to include "Decrementing by a value of 1 from 0 shall result in a TTL value of 63" because this will lead to a broken mechanism. OLD: TTL: Service plane time-to-live. An SFF MUST decrement the TTL by a value of 1 for all NSH packets it receives. Decrementing by a value of 1 from 0 shall result in a TTL value of 63. The default for originating an NSH packet is a TTL value of 63. The decrement SHALL occur before testing for 0. After decrement, if the TTL is 0, the NSH packet MUST NOT be forwarded. NEW: SHL (SFF Hop Limit): Indicates the maximum SFF hops for a service chain. The initial SHL value SHOULD be configurable via the control plane; the configured initial value can be specific to a chain or all chains. If no initial value is explicitly provided, the default initial SHL value 63 MUST be used. Each SFF involved in forwarding an NSH packet MUST decrement SHL value by 1. The packet MUST NOT be forwarded to a next hop SFF if SHL is decremented to zero. SFFs that terminate a service chain MUST forward the packet to attached SFs even if SHL is decremented to 0. Thank you. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de James N Guichard Envoyé : jeudi 27 avril 2017 20:54 À : sfc@ietf.org<mailto:sfc@ietf.org> Objet : [sfc] TTL field within the NSH base header Dear WG: Having reviewed all of the email discussion on the mailing list it appears to the chairs that we have consensus to add a TTL field to the NSH base header. We would like to propose the following changes: Section 3.2: Update figure 2 as follows: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|O|R| TTL | Length |R|R|R|R|MD Type| Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Add the following text after figure 2: TTL: Service plane time-to-live. An SFF MUST decrement the TTL by a value of 1 for all NSH packets it receives. Decrementing by a value of 1 from 0 shall result in a TTL value of 63. The default for originating an NSH packet is a TTL value of 63. The decrement SHALL occur before testing for 0. After decrement, if the TTL is 0, the NSH packet MUST NOT be forwarded. Section 3.4: Update figure 4 to reflect the new base header format as per section 3.2 base header. Section 3.5: Update figure 5 to reflect the new base header format as per section 3.2 base header. Section 12.2.1: Current text is as follows: There are ten bits at the beginning of the NSH Base Header. New bits are assigned via Standards Action [RFC5226]. Bits 0-1 - Version Bit 2 - OAM (O bit) Bit 3 - Critical TLV (C bit) Bits 4-9 - Reserved Replace entire text as follows: There are eight reserved bits in the NSH Base Header. New bits are assigned via Standards Action [RFC5226]. Bits 0-1 - Version Bit 2 - OAM (O bit) Bit 3 - Reserved Bits 16-19 - Reserved Section 12.2.3: Current text has the MD-type as 8-bit values. Update text for this section and table 1 to reflect 4-bit values *not* 8-bit values. Please review carefully and indicate support for these changes (or any changes to the suggested text). Thanks, Jim & Joel
- Re: [sfc] TTL field within the NSH base header Ron Parker
- Re: [sfc] TTL field within the NSH base header Dave Dolson
- [sfc] TTL field within the NSH base header James N Guichard
- Re: [sfc] TTL field within the NSH base header James N Guichard
- Re: [sfc] TTL field within the NSH base header James N Guichard
- Re: [sfc] TTL field within the NSH base header Andrew G. Malis
- Re: [sfc] TTL field within the NSH base header Ron Parker
- Re: [sfc] TTL field within the NSH base header Joel M. Halpern
- Re: [sfc] TTL field within the NSH base header Jim Guichard
- Re: [sfc] TTL field within the NSH base header Andrew G. Malis
- Re: [sfc] TTL field within the NSH base header Ron Parker
- Re: [sfc] TTL field within the NSH base header Dave Dolson
- Re: [sfc] TTL field within the NSH base header Joe Clarke
- Re: [sfc] TTL field within the NSH base header Ron Parker
- Re: [sfc] TTL field within the NSH base header mohamed.boucadair
- Re: [sfc] TTL field within the NSH base header Dave Dolson
- Re: [sfc] TTL field within the NSH base header jmh.direct
- Re: [sfc] TTL field within the NSH base header Dave Dolson
- Re: [sfc] TTL field within the NSH base header Joel M. Halpern
- Re: [sfc] TTL field within the NSH base header Joel M. Halpern
- Re: [sfc] TTL field within the NSH base header mohamed.boucadair
- Re: [sfc] TTL field within the NSH base header mohamed.boucadair
- Re: [sfc] TTL field within the NSH base header Dave Dolson
- Re: [sfc] TTL field within the NSH base header Dave Dolson
- Re: [sfc] TTL field within the NSH base header Dave Dolson
- Re: [sfc] TTL field within the NSH base header mohamed.boucadair
- Re: [sfc] TTL field within the NSH base header Andrew G. Malis
- Re: [sfc] TTL field within the NSH base header James N Guichard
- Re: [sfc] TTL field within the NSH base header Ron Parker
- Re: [sfc] TTL field within the NSH base header Kyle Larose
- Re: [sfc] TTL field within the NSH base header James N Guichard
- Re: [sfc] TTL field within the NSH base header Ron Parker
- Re: [sfc] TTL field within the NSH base header Joel M. Halpern
- Re: [sfc] TTL field within the NSH base header Dave Dolson
- Re: [sfc] TTL field within the NSH base header Ron Parker
- Re: [sfc] TTL field within the NSH base header Dave Dolson
- Re: [sfc] TTL field within the NSH base header Ron Parker
- Re: [sfc] TTL field within the NSH base header Dave Dolson
- Re: [sfc] TTL field within the NSH base header Ron Parker
- Re: [sfc] TTL field within the NSH base header Joel M. Halpern
- Re: [sfc] TTL field within the NSH base header Greg Mirsky
- Re: [sfc] TTL field within the NSH base header James N Guichard
- Re: [sfc] TTL field within the NSH base header Ron Parker
- Re: [sfc] TTL field within the NSH base header Ron Parker
- Re: [sfc] TTL field within the NSH base header Eric C Rosen
- Re: [sfc] TTL field within the NSH base header Joel Halpern Direct
- Re: [sfc] TTL field within the NSH base header James N Guichard
- Re: [sfc] TTL field within the NSH base header Joe Clarke
- Re: [sfc] TTL field within the NSH base header mohamed.boucadair
- Re: [sfc] TTL field within the NSH base header Greg Mirsky
- Re: [sfc] TTL field within the NSH base header mohamed.boucadair
- Re: [sfc] TTL field within the NSH base header mohamed.boucadair
- Re: [sfc] TTL field within the NSH base header mohamed.boucadair
- Re: [sfc] TTL field within the NSH base header mohamed.boucadair
- Re: [sfc] TTL field within the NSH base header Dave Dolson
- Re: [sfc] TTL field within the NSH base header mohamed.boucadair
- Re: [sfc] TTL field within the NSH base header Dave Dolson
- Re: [sfc] TTL field within the NSH base header mohamed.boucadair
- Re: [sfc] TTL field within the NSH base header James N Guichard
- Re: [sfc] TTL field within the NSH base header Dave Dolson
- Re: [sfc] TTL field within the NSH base header Ron Parker
- Re: [sfc] TTL field within the NSH base header mohamed.boucadair
- Re: [sfc] TTL field within the NSH base header Joel M. Halpern
- Re: [sfc] TTL field within the NSH base header Joel M. Halpern
- Re: [sfc] TTL field within the NSH base header Dave Dolson
- Re: [sfc] TTL field within the NSH base header Dave Dolson
- Re: [sfc] TTL field within the NSH base header Greg Mirsky
- Re: [sfc] TTL field within the NSH base header James N Guichard
- Re: [sfc] TTL field within the NSH base header mohamed.boucadair