Re: [sfc] TTL field within the NSH base header

<mohamed.boucadair@orange.com> Fri, 05 May 2017 06:01 UTC

Return-Path: <mohamed.boucadair@orange.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 D61E9129435 for <sfc@ietfa.amsl.com>; Thu, 4 May 2017 23:01:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level:
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 hAeCt0InjXAB for <sfc@ietfa.amsl.com>; Thu, 4 May 2017 23:01:01 -0700 (PDT)
Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20308129440 for <sfc@ietf.org>; Thu, 4 May 2017 23:01:00 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id CAC511C0324; Fri, 5 May 2017 08:00:58 +0200 (CEST)
Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.14]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id AE06340075; Fri, 5 May 2017 08:00:58 +0200 (CEST)
Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORM3C.corporate.adroot.infra.ftgroup ([fe80::6ca9:97b1:8a5:a764%21]) with mapi id 14.03.0339.000; Fri, 5 May 2017 08:00:58 +0200
From: mohamed.boucadair@orange.com
To: 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/h0bahW5bvXGwSoCeYu3QIaIxxgFXmrGgAB/CvTA=
Date: Fri, 05 May 2017 06:00:57 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E62055@OPEXCNORMAD.corporate.adroot.infra.ftgroup>
References: <BF1BE6D99B52F84AB9B48B7CF6F17DA3DD5F8E@SJCEML701-CHM.china.huawei.com> <BF1BE6D99B52F84AB9B48B7CF6F17DA3DD797B@SJCEML701-CHM.china.huawei.com>
In-Reply-To: <BF1BE6D99B52F84AB9B48B7CF6F17DA3DD797B@SJCEML701-CHM.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E62055OPEXCNORMADcorp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/6ch9wnwHwu8BQSxigC0_IxwXFyI>
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, 05 May 2017 06:01:04 -0000

Hi Jim,

Please note that the proposed wording includes a normative language in an example "e.g. decrement SHALL occur before testing TTL for 0". This is odd in an example. I would delete that example.

Cheers,
Med

De : sfc [mailto:sfc-bounces@ietf.org] De la part de James N Guichard
Envoyé : jeudi 4 mai 2017 16:53
À : James N Guichard; sfc@ietf.org
Objet : Re: [sfc] TTL field within the NSH base header

Dear WG:

Here is the latest text that I have captured from the email thread. Please review carefully and indicate support for these 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: Indicates the maximum SFF hops for an SFP. The initial TTL value SHOULD be configurable via the control plane; the configured initial value can be specific to one or more SFPs. If no initial value is explicitly provided, the default initial TTL value 63 MUST be used. Each SFF involved in forwarding an NSH packet MUST decrement the TTL value by 1 prior to NSH forwarding lookup. Decrementing by 1 from an incoming value of 0 shall result in a TTL value of 63. The packet MUST NOT be forwarded if TTL is, after decrement, 0 e.g. decrement SHALL occur before testing TTL for 0.

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 five 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.

Thanks!

Jim

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