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."/
>