Re: [sfc] [RTG-DIR] Routing Directorate Last Call Review for draft-ietf-sfc-nsh-18.txt
"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 11 August 2017 03:27 UTC
Return-Path: <jmh@joelhalpern.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 EF47F132021; Thu, 10 Aug 2017 20:27:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 mZCla4xmxwPn; Thu, 10 Aug 2017 20:27:06 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B69131D2C; Thu, 10 Aug 2017 20:27:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1AFB0C00454; Thu, 10 Aug 2017 20:27:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1502422026; bh=DCQyiqThEAY47O5VF4Nm0Ycn8/MSFnW2mbSWmdZ3aQc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jwWATAiGkJPwObj5Je8v3ruQzu/8PNSOqlx3TwPUS4+vGAFAdSaK2tPo81NEbomqi 1jRp/kMEc2a7a1GecaUFYdNLLo77EEwLxv7Cgg3YDVri5q3asdN6XO2fazjHJfDC+L XqL1e6yMmR18kyXTDbNjJV1YBs+SjXAjwDCQwUCk=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 03452C0044D; Thu, 10 Aug 2017 20:27:04 -0700 (PDT)
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, Alia Atlas <akatlas@gmail.com>
Cc: Routing Directorate <rtg-dir@ietf.org>, "draft-ietf-sfc-nsh@ietf.org" <draft-ietf-sfc-nsh@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>, Routing ADs <rtg-ads@tools.ietf.org>
References: <D5B27C52.C036D%acee@cisco.com> <CAG4d1rdee8sz5Afk_jY9YJx7pDAvkTxkzQjSYbv=HGGOzwscTg@mail.gmail.com> <3DB664F5-C6DE-4B57-A666-5573C8625AAA@cisco.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <9dc9458f-037f-7ec6-93c9-465102cbbbf8@joelhalpern.com>
Date: Thu, 10 Aug 2017 23:27:03 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <3DB664F5-C6DE-4B57-A666-5573C8625AAA@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/vUQg607bepSCl-bN7dPwcSX4Zxk>
Subject: Re: [sfc] [RTG-DIR] Routing Directorate Last Call Review for draft-ietf-sfc-nsh-18.txt
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, 11 Aug 2017 03:27:09 -0000
I would like to wait until we also get the secdir review and Alia's own review before posting the new draft. Joel On 8/10/17 11:23 PM, Carlos Pignataro (cpignata) wrote: > Alia, > >> On Aug 10, 2017, at 10:24 PM, Alia Atlas <akatlas@gmail.com >> <mailto:akatlas@gmail.com>> wrote: >> >> Acee, >> >> Thank you for your review. I look forward to the editors & WG discussing >> how to improve >> the draft. > > Seems all these minor review items are fairly localized, clear, and > non-contentious. > > We have provided responses and diffs on the list, and a new revision is > ready to be submitted when Joel / you wants us to pull the trigger > (addressing Ops and RTG Dirs). > > Thanks, > > — Carlos. > >> >> Regards, >> Alia >> >> On Thu, Aug 10, 2017 at 9:10 PM, Acee Lindem (acee) <acee@cisco.com >> <mailto:acee@cisco.com>> wrote: >> >>> Hello, >>> >>> I have been selected as the Routing Directorate reviewer for this draft. >>> The Routing Directorate seeks to review all routing or routing-related >>> drafts as they pass through IETF last call and IESG review, and sometimes >>> on special request. The purpose of the review is to provide assistance to >>> the Routing ADs. For more information about the Routing Directorate, >>> please >>> see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>> >>> Although these comments are primarily for the use of the Routing ADs, it >>> would be helpful if you could consider them along with any other IETF >>> Last >>> Call comments that you receive, and strive to resolve them through >>> discussion or by updating the draft. >>> >>> Document: draft-ietf-sfc-nsh-18.txt >>> Reviewer: Acee Lindem >>> Review Date: August 10, 2017 >>> IETF LC End Date: Not started yet. >>> Intended Status: Standards Track >>> >>> Summary: >>> I have some minor concerns about this document that I think should be >>> resolved before publication. It needs to be consumed along with the >>> Service >>> Function Chaining architecture. >>> >>> Comments: >>> The document is an important piece of the Service Function Chaining >>> work. I think the readability could be greatly improved with the >>> editorial >>> changes I have suggested. For example, using articles, e.g. “the”, when >>> referring to the NSH. >>> >>> Major Issues: N/A >>> >>> Minor Issues: >>> >>> Section 1: Run-on sentense that makes up the entire third paragraph >>> is too hard to parse. Please split it up and avoid >>> cascading so many dependent clauses. >>> >>> >>> Section 2.2: The discussion of meta-data support for MD types 0x1 or >>> 0x3 is out of context. >>> >>> Section 2.4: The MUST's are contradictory. First it says the context >>> header MUST be 16 bytes than it says it MUST >>> be 0 bytes if >>> it contains no meta-data. This is hardly >>> "fixed". >>> >>> Section 2.5.1: Mandating that the unassigned bit MUST NOT be set >>> will >>> without saying it MUST be ignored on >>> receipt is >>> not be backward compatible. >>> >>> Section 11.2.1: List the bits that are assigned. >>> >>> Section 11.2.6: MD types 1 and 2 are assigned by the document yet >>> this section states that no values are >>> assigned. >>> >>> Nits: >>> >>> ACEE-M-G2HR:Desktop acee$ diff -c draft-ietf-sfc-nsh-18.txt.orig >>> draft-ietf-sfc-nsh-18.txt >>> *** draft-ietf-sfc-nsh-18.txt.orig 2017-08-04 07:27:08.000000000 -0400 >>> --- draft-ietf-sfc-nsh-18.txt 2017-08-10 20:50:45.000000000 -0400 >>> *************** >>> *** 18,24 **** >>> >>> This document describes a Network Service Header (NSH) inserted onto >>> packets or frames to realize service function paths. NSH also >>> ! provides a mechanism for metadata exchange along the instantiated >>> service paths. NSH is the SFC encapsulation required to support the >>> Service Function Chaining (SFC) architecture (defined in RFC7665). >>> >>> --- 18,24 ---- >>> >>> This document describes a Network Service Header (NSH) inserted onto >>> packets or frames to realize service function paths. NSH also >>> ! provides a mechanism for metadata exchange along instantiated >>> service paths. NSH is the SFC encapsulation required to support the >>> Service Function Chaining (SFC) architecture (defined in RFC7665). >>> >>> *************** >>> *** 181,187 **** >>> >>> Metadata: Defined in [RFC7665]. >>> >>> ! Network Locator: dataplane address, typically IPv4 or IPv6, used to >>> send and receive network traffic. >>> >>> Network Node/Element: Device that forwards packets or frames based >>> --- 181,187 ---- >>> >>> Metadata: Defined in [RFC7665]. >>> >>> ! Network Locator: Dataplane address, typically IPv4 or IPv6, used to >>> send and receive network traffic. >>> >>> Network Node/Element: Device that forwards packets or frames based >>> *************** >>> *** 191,204 **** >>> (the underlay). Packets are encapsulated or tunneled to create >>> the overlay network topology. >>> >>> ! NSH-aware SFC-encapsulation-aware, or SFC-aware [RFC7665]. >>> >>> ! Service Classifier: Logical entity providing classification >>> function. Since they are logical, classifiers may be co-resident >>> with SFC elements such as SFs or SFFs. Service classifiers >>> perform classification and impose NSH. The initial classifier >>> imposes the initial NSH and sends the NSH packet to the first SFF >>> ! in the path. Non-initial (i.e. subsequent) classification can >>> occur as needed and can alter, or create a new service path. >>> >>> Service Function (SF): Defined in [RFC7665]. >>> --- 191,204 ---- >>> (the underlay). Packets are encapsulated or tunneled to create >>> the overlay network topology. >>> >>> ! NSH-aware: SFC-encapsulation-aware, or SFC-aware [RFC7665]. >>> >>> ! Service Classifier: Logical entity providing the classification >>> function. Since they are logical, classifiers may be co-resident >>> with SFC elements such as SFs or SFFs. Service classifiers >>> perform classification and impose NSH. The initial classifier >>> imposes the initial NSH and sends the NSH packet to the first SFF >>> ! in the path. Non-initial (i.e., subsequent) classification can >>> occur as needed and can alter, or create a new service path. >>> >>> Service Function (SF): Defined in [RFC7665]. >>> *************** >>> *** 269,277 **** >>> >>> 2. Network Service Header >>> >>> ! NSH contains service path information and optionally metadata that >>> are added to a packet or frame and used to create a service plane. >>> ! An outer transport header is imposed, on NSH and the original >>> packet/ >>> frame, for network forwarding. >>> >>> >>> --- 269,277 ---- >>> >>> 2. Network Service Header >>> >>> ! The NSH contains service path information and optionally >>> metadata that >>> are added to a packet or frame and used to create a service plane. >>> ! An outer transport header is imposed on the NSH and the original >>> packet/ >>> frame, for network forwarding. >>> >>> >>> *************** >>> *** 282,293 **** >>> Internet-Draft Network Service Header (NSH) July 2017 >>> >>> >>> ! A Service Classifier adds NSH. NSH is removed by the last SFF >>> in the >>> service chain or by an SF that consumes the packet. >>> >>> 2.1. Network Service Header Format >>> >>> ! NSH is composed of a 4-byte Base Header, a 4-byte Service Path >>> Header >>> and optional Context Headers, as shown in Figure 1 below. >>> >>> 0 1 2 3 >>> --- 282,293 ---- >>> Internet-Draft Network Service Header (NSH) July 2017 >>> >>> >>> ! A Service Classifier adds the NSH. The NSH is removed by the last >>> SFF in the >>> service chain or by an SF that consumes the packet. >>> >>> 2.1. Network Service Header Format >>> >>> ! The NSH is composed of a 4-byte Base Header, a 4-byte Service Path >>> Header >>> and optional Context Headers, as shown in Figure 1 below. >>> >>> 0 1 2 3 >>> *************** >>> *** 304,316 **** >>> >>> Figure 1: Network Service Header >>> >>> ! Base header: provides information about the service header and the >>> payload protocol. >>> >>> ! Service Path Header: provides path identification and location >>> within >>> a service path. >>> >>> ! Context header: carries metadata (i.e., context data) along a >>> service >>> path. >>> >>> 2.2. NSH Base Header >>> --- 304,316 ---- >>> >>> Figure 1: Network Service Header >>> >>> ! Base header: Provides information about the service header and the >>> payload protocol. >>> >>> ! Service Path Header: Provides path identification and location >>> within >>> a service path. >>> >>> ! Context header: Carries metadata (i.e., context data) along a >>> service >>> path. >>> >>> 2.2. NSH Base Header >>> *************** >>> *** 368,374 **** >>> for service plane loop detection. 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 >>> --- 368,374 ---- >>> for service plane loop detection. 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 of 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 >>> *************** >>> *** 380,389 **** >>> elements. Elements which do not understand the meaning of any of >>> these bits MUST NOT modify their actions based on those unknown bits > > — > Carlos Pignataro, carlos@cisco.com <mailto:carlos@cisco.com> > > /“Sometimes I use big words that I do not fully understand, to make > myself sound more photosynthesis."/ >
- [sfc] Routing Directorate Last Call Review for dr… Acee Lindem (acee)
- Re: [sfc] Routing Directorate Last Call Review fo… Alia Atlas
- Re: [sfc] Routing Directorate Last Call Review fo… Carlos Pignataro (cpignata)
- Re: [sfc] [RTG-DIR] Routing Directorate Last Call… Joel M. Halpern
- Re: [sfc] Routing Directorate Last Call Review fo… Carlos Pignataro
- Re: [sfc] [RTG-DIR] Routing Directorate Last Call… Carlos Pignataro (cpignata)
- Re: [sfc] Routing Directorate Last Call Review fo… Acee Lindem (acee)
- Re: [sfc] Routing Directorate Last Call Review fo… Carlos Pignataro (cpignata)