Re: [sfc] TTL field within the NSH base header
Ron Parker <Ron_Parker@affirmednetworks.com> Thu, 27 April 2017 20:08 UTC
Return-Path: <Ron_Parker@affirmednetworks.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 894D7127201 for <sfc@ietfa.amsl.com>; Thu, 27 Apr 2017 13:08:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 l2v0TyKd7jzR for <sfc@ietfa.amsl.com>; Thu, 27 Apr 2017 13:08:53 -0700 (PDT)
Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D7D129C13 for <sfc@ietf.org>; Thu, 27 Apr 2017 13:05:06 -0700 (PDT)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0319.002; Thu, 27 Apr 2017 13:05:06 -0700
From: Ron Parker <Ron_Parker@affirmednetworks.com>
To: Dave Dolson <ddolson@sandvine.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/h0bahW5bvXGwSoCeYu3QIaIxxgAAqFVgAAHGe0AAABDMYA==
Date: Thu, 27 Apr 2017 20:05:05 +0000
Message-ID: <CDF2F015F4429F458815ED2A6C2B6B0B839920AD@MBX021-W3-CA-2.exch021.domain.local>
References: <BF1BE6D99B52F84AB9B48B7CF6F17DA3DD5F8E@SJCEML701-CHM.china.huawei.com> <CDF2F015F4429F458815ED2A6C2B6B0B83991FDC@MBX021-W3-CA-2.exch021.domain.local> <E8355113905631478EFF04F5AA706E98705BB593@wtl-exchp-1.sandvine.com>
In-Reply-To: <E8355113905631478EFF04F5AA706E98705BB593@wtl-exchp-1.sandvine.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [50.205.79.154]
Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B839920ADMBX021W3CA2exch_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/yyxwEWMD03WLBhia6MM_uvLm3vM>
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: Thu, 27 Apr 2017 20:08:55 -0000
Thanks, Dave. Do you think it is possible to combine that backward compatibility with the simpler (to me) concept of testing for a packet that arrives with TTL=1 and conditioning behavior on whether the SFF is the terminating SFF of the path? Ron From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Thursday, April 27, 2017 4:03 PM To: Ron Parker <Ron_Parker@affirmednetworks.com>; James N Guichard <james.n.guichard@huawei.com>; sfc@ietf.org Subject: RE: TTL field within the NSH base header Ron, Decrementing from zero to reach 63, and checking for zero after decrementing provides a degree of backwards compatibility with the prior header format. This permits packets on the wire to have 0 in the bits that were previously "reserved". -Dave From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker Sent: Thursday, April 27, 2017 3:21 PM To: James N Guichard; sfc@ietf.org<mailto:sfc@ietf.org> Subject: Re: [sfc] TTL field within the NSH base header I had to really think about the language around decrementing by 1 from 0 and reaching 63. This would only occur in an error scenario where a preceding SFF misbehaved, wouldn't it? Why are we insistent that the test for 0 happen after decrement, thereby creating this problem. I suspect that this has been already discussed and I apologize if I missed it, but if the language were simplified to say an SFF that receives an NSH with TTL=1 shall not forward it to another SFF (e.g., allowing it to engage its local SF instances, still). Otherwise, it must decrement by 1 before forwarding to another SFF. An exact wording along these lines might be something like: TTL: Service plane time-to-live. An SFF MUST test the TTL before forwarding to another SFF for a given Service Function Chain. If the received TTL value is 1, the SFF MUST drop packets that would otherwise have been forwarded to another SFF, but SHALL send such packets to attached service functions if the SFF terminates the Service Function Chain. If the TTL value is greater than 1, the SFF must decrement the TTL by 1 before forwarding to another SFF. The default for originating an NSH packet is a TTL value of 63. From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of James N Guichard Sent: Thursday, April 27, 2017 2:54 PM To: sfc@ietf.org<mailto:sfc@ietf.org> Subject: [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