Re: [sfc] #24 (nsh): -07 review (M. Boucadair)
"sfc issue tracker" <trac+sfc@tools.ietf.org> Thu, 27 October 2016 12:30 UTC
Return-Path: <trac+sfc@tools.ietf.org>
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 08A99129517 for <sfc@ietfa.amsl.com>; Thu, 27 Oct 2016 05:30:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level:
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.431] 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 IotTBxO8zdTw for <sfc@ietfa.amsl.com>; Thu, 27 Oct 2016 05:30:33 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (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 EC4961294F8 for <sfc@ietf.org>; Thu, 27 Oct 2016 05:30:31 -0700 (PDT)
Received: from localhost ([::1]:51172 helo=durif.tools.ietf.org) by durif.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+sfc@tools.ietf.org>) id 1bzjpH-0002wV-1l; Thu, 27 Oct 2016 05:30:31 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: sfc issue tracker <trac+sfc@tools.ietf.org>
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com
X-Trac-Project: sfc
Date: Thu, 27 Oct 2016 12:30:31 -0000
X-URL: https://tools.ietf.org/sfc/
X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/sfc/trac/ticket/24#comment:1
Message-ID: <082.a2e18c78dce614a1c6dda649cc12672c@tools.ietf.org>
References: <067.8a174ca9f70d425565b9b7d036fb00ae@tools.ietf.org>
X-Trac-Ticket-ID: 24
In-Reply-To: <067.8a174ca9f70d425565b9b7d036fb00ae@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-sfc-nsh@tools.ietf.org, mohamed.boucadair@orange.com, sfc@ietf.org
X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: draft-ietf-sfc-nsh@ietf.org
Resent-Message-Id: <20161027123031.EC4961294F8@ietfa.amsl.com>
Resent-Date: Thu, 27 Oct 2016 05:30:31 -0700
Resent-From: trac+sfc@tools.ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/GOhxIKRoyNiD9xfv3fRAkKmSNLY>
Cc: sfc@ietf.org
Subject: Re: [sfc] #24 (nsh): -07 review (M. Boucadair)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.17
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 Oct 2016 12:30:38 -0000
#24: -07 review (M. Boucadair) Comment (by mohamed.boucadair@orange.com): Updating the tracker to record the pending points: == (1) Section 2: I suggest to delete the following sentence: NSH is designed to be easy to implement across a range of devices, both physical and virtual, including hardware platforms. Reason: the use of "easy to implement" should be justified if that text is maintained. Otherwise, this is subjective. or to reword it as follows: "NSH can be implemented in both physical and virtual platforms." (2) Section 2.3: CLOSED (3) Section 2.3- Not sure I would maintain this text: 5. NSH offers a common and standards-based header for service chaining to all network and service nodes. "to all" is not accurate as "legacy" nodes are still there. (4) Section 2.3: CLOSED (5) Section 3.2: NSH implementations MUST support MD-Type = 0x1, and SHOULD support MD- Type = 0x2. Because: * of potential interoperability issues. * MD#2 is more compact when no metadata is to be supplied * MD#2 allows to convey more information compared to MD#1 I suggest we revisit that sentence to have MD#2 be mandatory to be supported (my favorite option), or at least require that both MDs defined in this spec MUST be supported. (6) Section 3.2: C bit: Indicates that a critical metadata TLV is present. This bit acts as an indication for hardware implementers to decide how to handle the presence of a critical TLV without necessarily needing to parse all TLVs present. For an MD Type of 0x1 (i.e. no variable length metadata is present), the C bit MUST be set to 0x0. 6.1. What is the behavior of the implementation if C-bit is set but not critical metadata is found in the payload? 6.2. What is the behavior of the implementation if C-bit is unset but a critical metadata is found in the payload? 6.3. What is the behavior of the implementation with regards to this bit if a critical metadata is added in-path? 6.4. What is the behavior of the implementation with regards to this bit if a critical metadata is stripped in-path? 6.5. Should the specification recommend an order of metadata so that critical metadata are always positioned first? (7) Section 3.3: CLOSED (8) Section 3.4: 8.2. The specification does not forbid that all context headers are set to zero. Otherwise, MD#2 should be used instead. 8.3. The specification does not specify how these context headers are to be validated. 8.4. I still don't understand why four headers are chosen. (9) Section 3.5.1: The length of "Metadata Class" is over-dimensioned. I suggest to reduce the length of this field and increase the length of "Type". For example, let's consider the proposal in https://tools.ietf.org/html /draft-napper-sfc-nsh-broadband-allocation-00#section-4.2: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class = 3GPP |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ Figure 5: TLV Allocation The intended use of the header is for TLVs associated with 3GPP Radio Access Networks as described in [TS.29.230]. This TLV can be used by 3GPP to extend the metadata as per use cases. Having this TLV helps to carry more information that does not fit within the MD Type 0x01. The list of codes in Table 7.1 of TS.29.230 cannot be conveyed with a "Type" field of 7 bits. (10) Section 4: OLD: +---------------+------------------+-------+----------------+---------+ | | Insert |Select | Update |Service | | | or remove NSH |Service| NSH |policy | | | |Function| |selection| | Component +--------+--------+Path +----------------+ | | | | | | Dec. |Update | | | | Insert | Remove | |Service |Context| | | | | | | Index |Header | | +----------------+--------+--------+-------+--------+-------+---------+ | | + | + | | | + | | |Classifier | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |Service Function| | + | + | | | | |Forwarder(SFF) | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |Service | | | | + | + | + | |Function (SF) | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |SFC Proxy | + | + | | + | | | +----------------+--------+--------+-------+--------+-------+---------+ NEW: +---------------+------------------+-------+----------------+---------+ | | Insert |Select | Update |Service | | | or remove NSH |Service| NSH |policy | | | |Function| |selection| | Component +--------+--------+Path +----------------+ | | | | | | Dec. |Update | | | | Insert | Remove | |Service |Context| | | | | | | Index |Header | | +----------------+--------+--------+-------+--------+-------+---------+ | | + | + | | | + | | |Classifier | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |Service Function| | + | + | | | | |Forwarder(SFF) | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |Service | | | | + | + | + | |Function (SF) | | | | | | | +--------------- +--------+--------+-------+--------+-------+---------+ |SFC Proxy | + | + | | + | + | | +----------------+--------+--------+-------+--------+-------+---------+ (11) Section 7.2: CLOSED. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | nsh@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nsh | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: <https://trac.tools.ietf.org/wg/sfc/trac/ticket/24#comment:1> sfc <https://tools.ietf.org/sfc/>
- [sfc] #24 (nsh): -07 review (M. Boucadair) sfc issue tracker
- Re: [sfc] #24 (nsh): -07 review (M. Boucadair) sfc issue tracker
- Re: [sfc] #24 (nsh): -07 review (M. Boucadair) sfc issue tracker
- Re: [sfc] #24 (nsh): -07 review (M. Boucadair) mohamed.boucadair