Re: [sfc] Routing Directorate Last Call Review for draft-ietf-sfc-nsh-18.txt

"Acee Lindem (acee)" <acee@cisco.com> Fri, 11 August 2017 15:59 UTC

Return-Path: <acee@cisco.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 28CDB13239C; Fri, 11 Aug 2017 08:59:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 R5-SlrGinbwh; Fri, 11 Aug 2017 08:59:00 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F5913235A; Fri, 11 Aug 2017 08:58:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=70760; q=dns/txt; s=iport; t=1502467131; x=1503676731; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vgOv8HrqlcMfCB0ov8ZUxeCOgeITMR/8M8WIjV0Y3E4=; b=jkUjb4YcG6rOm22xcZwDaiLy9HrHHm6YoRxAzgYj1kLLfWjwuZfB934F 1b6qMdvVDBrZ7FH3XfVYUmO4Cir3XY+e7HKNAGPCYp416NF1mtK+4HX7c Rgq9EKbBbPtNQjLwlIyrFQrwhTknuJipmnKEXX1k7lxTc/Ub8zgGiN6MC E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BbAwCh041Z/40NJK1dGQEBAQEBAQEBAQEBBwEBAQEBgy0tZIEBEweDLIpdkAyBbneHP41hDoIELIE7AYNfAhqEXD8YAQIBAQEBAQEBayiFGQEFDA4BCAQNMxIQAgEGAhICBAICERUCAgIfERUCDgIEDgWKFwMVEI08nWSBbDqHMQ2EIQEBAQEBAQEDAQEBAQEBAQEBH4ELghkEgWIggy4BgnM0gleBWSsYFyiCVIJhAQSRBIcAh2Y8AodRg1OEIIR0gg9ZhQSKaIlkgk2JYQEfOIEKdxUfKoUUH4FmAXYBiSKBDwEBAQ
X-IronPort-AV: E=Sophos;i="5.41,358,1498521600"; d="scan'208";a="470361623"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Aug 2017 15:58:48 +0000
Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v7BFwm5m010056 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 11 Aug 2017 15:58:48 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 11 Aug 2017 11:58:47 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 11 Aug 2017 11:58:47 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
CC: Routing ADs <rtg-ads@tools.ietf.org>, Routing Directorate <rtg-dir@ietf.org>, "draft-ietf-sfc-nsh@ietf.org" <draft-ietf-sfc-nsh@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Thread-Topic: Routing Directorate Last Call Review for draft-ietf-sfc-nsh-18.txt
Thread-Index: AQHTErq3m3nqN4YHf0KPrcz5mpN8/w==
Date: Fri, 11 Aug 2017 15:58:47 +0000
Message-ID: <D5B34A5A.C048B%acee@cisco.com>
References: <D5B27C52.C036D%acee@cisco.com> <F405D015-E842-4C3B-BD02-35B06E56D02F@cisco.com>
In-Reply-To: <F405D015-E842-4C3B-BD02-35B06E56D02F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.201]
Content-Type: text/plain; charset="utf-8"
Content-ID: <BAE4E348A654BC42B2B46554C7EB57C9@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/JBpDEH0TYLQcD7vPROmcU8_GGU8>
Subject: Re: [sfc] 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 15:59:04 -0000

Hi Carlos, 

On 8/11/17, 12:06 AM, "Carlos Pignataro on behalf of Carlos Pignataro
(cpignata)" <cpignata@gmail.com on behalf of cpignata@cisco.com> wrote:

>Hi, Acee,
>
>Many thanks for the thorough review! Certainly can apply this patch :-)
>
>    The editors also acknowledge comprehensive reviews and respective
>-    suggestions by Med Boucadair and Adrian Farrel.
>+    suggestions by Med Boucadair, Adrian Farrel, and Acee Lindem.
>
>It is encouraging to see that your thorough and comprehensive review
>found only a handful of Minor issues, nothing Major, and nits.
>
>Please see inline.
>
>
>> On Aug 10, 2017, at 9:10 PM, Acee Lindem (acee) <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.
>
>Thanks! Of course we will resolve.
>
>> 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.
>
>Yes, we will fix all nits and editorials. However, in regards to having
>an article preceding “NSH” (e.g., “the NSH” or “an NSH”), I also wanted
>to change that earlier when I started actively editing the document —
>however I was instructed that the earlier WG consensus was to leave “NSH”
>without articles.
>
>> 
>> Major Issues: N/A
>> 
>
>Ack.
>
>> 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.
>> 
>> 
>
>OK, reworded as follows, welcome other suggestions if you have:
>
>  New data center network and cloud architectures require more flexible
>  service function deployment models.  Additionally, the transition to
>  virtual platforms demands an agile service insertion model that
>  supports dynamic and elastic service delivery.  Specifically, the
>  following functions are necessary:
>
>     The movement of service functions and application workloads in the
>     network.
>
>     The ability to easily bind service policy to granular information,
>     such as per-subscriber state.
>
>     The capability to steer traffic to the requisite service
>     function(s).

This is much better.

>
>
>>      Section 2.2: The discussion of meta-data support for MD types 0x1
>>or
>>                             0x3 is out of context.
>> 
>
>It seems to me it is well within the context of the specification of MD
>Type. Since that is an important piece of text that the WG crafted, do
>you have a concrete and specific suggestion of where else in the document
>it might fit better? Otherwise, I recommend leaving it as-is.

Perhaps then you could add a forward reference to section.
>
>
>>      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”.
>
>You are mis-reading, the text tries to say that the content MBZ. Not the
>length:
>
>  When the Base Header specifies MD Type = 0x1, a Fixed Length Context
>  Header (16-bytes) MUST be present immediately following the Service
>  Path Header, as per Figure 4.  A Fixed Length Context Header that
>  carries no metadata MUST be set to zero.
>
>I will reword to:
>
>  When the Base Header specifies MD Type = 0x1, a Fixed Length Context
>  Header (16-bytes) MUST be present immediately following the Service
>  Path Header, as per Figure 4.  The value of a Fixed Length Context
>  Header that carries no metadata MUST be set to zero.
>
>Better?

Much better. 

>
>> 
>
>>      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.
>
>OK, changed:
>
>  Unassigned bit: one unassigned bit is available for future use.  This
>  bit MUST be set to 0b.
>
>To:
>
>  Unassigned bit: one unassigned bit is available for future use.  This
>  bit MUST be set to 0b and MUST be ignored on receipt.

Yes - except capitalize “One”.
>
>> 
>>     Section 11.2.1: List the bits that are assigned.
>
>The whole header is not a bit mask:
>
>     0                   1                   2                   3
>     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|U|    TTL    |   Length  |U|U|U|U|MD Type| Next Protocol |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>I can add the “O” bit, but otherwise those are fields and not bits.
>
>Happy to do this for completeness.
>
>OLD:
>
>11.2.1.  NSH Base Header Unassigned Bits
>
>  There are five unassigned bits in the NSH Base Header.  New bits are
>  assigned via Standards Action [RFC8126].
>  Bit 3 - Unassigned
>  Bits 16-19 - Unassigned
>
>NEW:
>
>11.2.1.  NSH Base Header Bits
>
>  There are five unassigned bits in the NSH Base Header, and one bit
>  assigned (O-bit).  New bits are assigned via Standards Action
>  [RFC8126].
>
>  Bit 2 - O (OAM) bit
>  Bit 3 - Unassigned
>  Bits 16-19 - Unassigned

Ok. 
>
>
>
>> 
>>     Section 11.2.6: MD types 1 and 2 are assigned by the document yet
>>                                 this section states that no values are
>>assigned. 
>> 
>
>This is about Section 2.5.1, not about MD Type. The title is incorrect.
>
>NEW:
>
>11.2.6.  New IETF Assigned Optional Variable Length Metadata Type
>        Registry
>
>  This document requests IANA to create a registry for the type values
>  owned by the IETF (i.e., MD Class set to 0x0000) called the "IETF
>  Assigned Optional Variable Length Metadata Type Registry", as
>  specified in Section 2.5.1.
>
>  The type values are assigned via Standards Action [RFC8126].
>
>  No initial values are assigned at the creation of the registry.

This clears up the confusion.
>
>
>
>> Nits:
>
>Will take care of these nits, except “article NSH”.

I think this has always been confusing in this draft since the Network
Service Header is nothing more than a protocol construct in the Service
Chaining Architecture. NSH is not an architecture itself. However, I’ll
leave it to thew WG.

Thanks,
Acee 

>
>Thanks!
>
>Carlos.
>
>> 
>> 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.
>> 
>> !    Length: The total length, in 4-byte words, of NSH including the
>>Base
>>     Header, the Service Path Header, the Fixed Length Context Header or
>> !    Variable Length Context Header(s).  The length MUST be of value 0x6
>> !    for MD Type equal to 0x1, and MUST be of value 0x2 or greater for
>>MD
>>     Type equal to 0x2.  The length of the NSH header MUST be an integer
>> 
>> 
>> --- 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.
>> 
>> !    Length: The total length, in 4-byte words, of the NSH including
>>the Base
>>     Header, the Service Path Header, the Fixed Length Context Header or
>> !    Variable Length Context Header(s).  The length MUST be 0x6
>> !    for MD Type equal to 0x1, and MUST be 0x2 or greater for MD
>>     Type equal to 0x2.  The length of the NSH header MUST be an integer
>> 
>> 
>> ***************
>> *** 397,431 ****
>>     multiple of 4 bytes, thus variable length metadata is always padded
>>     out to a multiple of 4 bytes.
>> 
>> !    MD Type: indicates the format of NSH beyond the mandatory Base
>>Header
>>     and the Service Path Header.  MD Type defines the format of the
>>     metadata being carried.  Please see the IANA Considerations
>>     Section 11.2.3.
>> 
>>     This document specifies the following four MD Type values:
>> 
>> !    0x0 - this is a reserved value.  Implementations SHOULD silently
>>     discard packets with MD Type 0x0.
>> 
>> !    0x1 - which indicates that the format of the header includes a
>>fixed
>>     length Context Header (see Figure 4 below).
>> 
>> !    0x2 - which does not mandate any headers beyond the Base Header and
>>     Service Path Header, but may contain optional variable length
>>Context
>>     Header(s).  The semantics of the variable length Context Header(s)
>>     are not defined in this document.  The format of the optional
>>     variable length Context Headers is provided in Section 2.5.1.
>> 
>> !    0xF - this value is reserved for experimentation and testing, as
>>per
>>     [RFC3692].  Implementations not explicitly configured to be part of
>>     an experiment SHOULD silently discard packets with MD Type 0xF.
>> 
>>     The format of the Base Header and the Service Path Header is
>>     invariant, and not affected by MD Type.
>> 
>> !    NSH implementations MUST support MD type = 0x1 and MD Type = 0x2
>> !    (where the length is of value 0x2).  NSH implementations SHOULD
>> !    support MD Type 0x2 with length > 0x2.  There exists, however, a
>>     middle ground, wherein a device will support MD Type 0x1 (as per the
>>     MUST) metadata, yet be deployed in a network with MD Type 0x2
>>     metadata packets.  In that case, the MD Type 0x1 node, MUST utilize
>> --- 397,431 ----
>>     multiple of 4 bytes, thus variable length metadata is always padded
>>     out to a multiple of 4 bytes.
>> 
>> !    MD Type: Indicates the format of NSH beyond the mandatory Base
>>Header
>>     and the Service Path Header.  MD Type defines the format of the
>>     metadata being carried.  Please see the IANA Considerations
>>     Section 11.2.3.
>> 
>>     This document specifies the following four MD Type values:
>> 
>> !    0x0 - This is a reserved value.  Implementations SHOULD silently
>>     discard packets with MD Type 0x0.
>> 
>> !    0x1 - This indicates that the format of the header includes a fixed
>>     length Context Header (see Figure 4 below).
>> 
>> !    0x2 - This does not mandate any headers beyond the Base Header and
>>     Service Path Header, but may contain optional variable length
>>Context
>>     Header(s).  The semantics of the variable length Context Header(s)
>>     are not defined in this document.  The format of the optional
>>     variable length Context Headers is provided in Section 2.5.1.
>> 
>> !    0xF - This value is reserved for experimentation and testing, as
>>per
>>     [RFC3692].  Implementations not explicitly configured to be part of
>>     an experiment SHOULD silently discard packets with MD Type 0xF.
>> 
>>     The format of the Base Header and the Service Path Header is
>>     invariant, and not affected by MD Type.
>> 
>> !    NSH implementations MUST support MD types 0x1 and 0x2
>> !    (where the length is 0x2).  NSH implementations SHOULD
>> !    support MD Type 0x2 with a length greater than 0x2.  There exists,
>>however, a
>>     middle ground, wherein a device will support MD Type 0x1 (as per the
>>     MUST) metadata, yet be deployed in a network with MD Type 0x2
>>     metadata packets.  In that case, the MD Type 0x1 node, MUST utilize
>> ***************
>> *** 485,503 ****
>> 
>>     The meaning of these fields is as follows:
>> 
>> !    Service Path Identifier (SPI): identifies a service path.
>>     Participating nodes MUST use this identifier for Service Function
>>     Path selection.  The initial classifier MUST set the appropriate SPI
>>     for a given classification result.
>> 
>> !    Service Index (SI): provides location within the SFP.  The initial
>>     classifier for a given SFP SHOULD set the SI to 255, however the
>>     control plane MAY configure the initial value of SI as appropriate
>>     (i.e., taking into account the length of the service function path).
>> !    Service Index MUST be decremented by a value of 1 by Service
>>     Functions or by SFC Proxy nodes after performing required services
>> !    and the new decremented SI value MUST be used in the egress NSH
>> !    packet.  The initial Classifier MUST send the packet to the first
>>SFF
>> 
>> 
>> 
>> --- 485,503 ----
>> 
>>     The meaning of these fields is as follows:
>> 
>> !    Service Path Identifier (SPI): Identifies a service path.
>>     Participating nodes MUST use this identifier for Service Function
>>     Path selection.  The initial classifier MUST set the appropriate SPI
>>     for a given classification result.
>> 
>> !    Service Index (SI): Provides location within the SFP.  The initial
>>     classifier for a given SFP SHOULD set the SI to 255, however the
>>     control plane MAY configure the initial value of SI as appropriate
>>     (i.e., taking into account the length of the service function path).
>> !    The Service Index MUST be decremented by a value of 1 by Service
>>     Functions or by SFC Proxy nodes after performing required services
>> !    and the new decremented SI value MUST be used in the egress
>>packet's  
>> !    NSH.  The initial Classifier MUST send the packet to the first SFF
>> 
>> 
>> 
>> ***************
>> *** 511,519 ****
>>     SPI, the (re)classifier is, in effect, the initial classifier for
>>the
>>     resultant SPI.
>> 
>> !    The SI is used in conjunction with Service Path Identifier for
>>     Service Function Path Selection and for determining the next SFF/SF
>> !    in the path.  The SI is also valuable when troubleshooting/
>>reporting
>>     service paths.  Additionally, while the TTL field is the main
>>     mechanism for service plane loop detection, the SI can also be used
>>     for detecting service plane loops.
>> --- 511,519 ----
>>     SPI, the (re)classifier is, in effect, the initial classifier for
>>the
>>     resultant SPI.
>> 
>> !    The SI is used in conjunction with the Service Path Identifier for
>>     Service Function Path Selection and for determining the next SFF/SF
>> !    in the path.  The SI is also valuable when
>>troubleshooting/reporting
>>     service paths.  Additionally, while the TTL field is the main
>>     mechanism for service plane loop detection, the SI can also be used
>>     for detecting service plane loops.
>> ***************
>> *** 603,609 ****
>>        0                   1                   2                   3
>>        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
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> !      |          Metadata Class       |      Type     |U|       Len   |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |                      Variable Metadata                        |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> --- 603,609 ----
>>        0                   1                   2                   3
>>        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
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> !      |          Metadata Class       |      Type     |U|    Length   |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |                      Variable Metadata                        |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> ***************
>> *** 618,643 ****
>>  Internet-Draft        Network Service Header (NSH)             July
>>2017
>> 
>> 
>> !    Metadata Class (MD Class): defines the scope of the 'Type' field to
>>     provide a hierarchical namespace.  The IANA Considerations
>>     Section 11.2.4 defines how the MD Class values can be allocated to
>>     standards bodies, vendors, and others.
>> 
>> !    Type: indicates the explicit type of metadata being carried and is
>> !    the responsibility of the MD Class owner.
>> 
>> !    Unassigned bit: one unassigned bit is available for future use.
>>This
>> !    bit MUST be set to 0b.
>> 
>> !    Length: indicates the length of the variable metadata, in single
>>byte
>> !    words.  In case the metadata length is not an integer number of
>>     4-byte words, the sender MUST add pad bytes immediately following
>>the
>>     last metadata byte to extend the metadata to an integer number of
>>     4-byte words.  The receiver MUST round up the length field to the
>>     nearest 4-byte word boundary, to locate and process the next field
>>in
>>     the packet.  The receiver MUST access only those bytes in the
>> !    metadata indicated by the length field (i.e., actual number of
>>single
>> !    byte words) and MUST ignore the remaining bytes up to the nearest
>>     4-byte word boundary.  The Length may be 0 or greater.
>> 
>>     A value of 0 denotes a Context Header without a Variable Metadata
>> --- 618,643 ----
>>  Internet-Draft        Network Service Header (NSH)             July
>>2017
>> 
>> 
>> !    Metadata Class (MD Class): Defines the scope of the 'Type' field to
>>     provide a hierarchical namespace.  The IANA Considerations
>>     Section 11.2.4 defines how the MD Class values can be allocated to
>>     standards bodies, vendors, and others.
>> 
>> !    Type: Indicates the explicit type of metadata being carried.
>>Definition 
>> !    of the Type is the responsibility of the MD Class owner.
>> 
>> !    Unassigned bit: One unassigned bit is available for future use.
>>This
>> !    bit MUST NOT be set.
>> 
>> !    Length: Indicates the length of the variable metadata, in bytes.
>> !    When the metadata length is not an integer number of
>>     4-byte words, the sender MUST add pad bytes immediately following
>>the
>>     last metadata byte to extend the metadata to an integer number of
>>     4-byte words.  The receiver MUST round up the length field to the
>>     nearest 4-byte word boundary, to locate and process the next field
>>in
>>     the packet.  The receiver MUST access only those bytes in the
>> !    metadata indicated by the length field (i.e., actual number bytes)
>> !    and MUST ignore the remaining bytes up to the nearest
>>     4-byte word boundary.  The Length may be 0 or greater.
>> 
>>     A value of 0 denotes a Context Header without a Variable Metadata
>> ***************
>> *** 647,669 ****
>>     that are mandatory-to-implement or those that are mandatory-to-
>>     process.  These considerations are deployment-specific.  However,
>>the
>>     control plane is entitled to instruct SFC-aware SFs with the data
>> !    structure of context header together with their scoping (see
>>     Section 3.3.3 of [I-D.ietf-sfc-control-plane]).
>> 
>> !    Upon receipt of a packet that belong to a given SFP, if a
>>mandatory-
>>     to-process context header is missing in that packet, the SFC-aware
>>SF
>>     MUST NOT process the packet and MUST log at least once per the SPI
>> !    for which a mandatory metadata is missing.
>> 
>>     If multiple mandatory-to-process context headers are required for a
>> !    given SFP, the control plane MAY instruct the SFC-aware SF with the
>> !    order to consume these Context Headers.  If no instructions are
>>     provided, the SFC-aware SF MUST process these Context Headers in the
>>     order their appear in an NSH packet.
>> 
>>     If multiple instances of the same metadata are included in an NSH
>>     packet, but the definition of that context header does not allow for
>> !    it, the SFC-aware SF MUST process first instance and ignore
>>     subsequent instances.
>> 
>> 
>> --- 647,669 ----
>>     that are mandatory-to-implement or those that are mandatory-to-
>>     process.  These considerations are deployment-specific.  However,
>>the
>>     control plane is entitled to instruct SFC-aware SFs with the data
>> !    structure of context header together with its scoping (see
>>     Section 3.3.3 of [I-D.ietf-sfc-control-plane]).
>> 
>> !    Upon receipt of a packet that belongs to a given SFP, if a
>>mandatory-
>>     to-process context header is missing in that packet, the SFC-aware
>>SF
>>     MUST NOT process the packet and MUST log at least once per the SPI
>> !    for which the mandatory metadata is missing.
>> 
>>     If multiple mandatory-to-process context headers are required for a
>> !    given SFP, the control plane MAY instruct the SFC-aware SF
>> !    to consume these Context Headers.  If no instructions are
>>     provided, the SFC-aware SF MUST process these Context Headers in the
>>     order their appear in an NSH packet.
>> 
>>     If multiple instances of the same metadata are included in an NSH
>>     packet, but the definition of that context header does not allow for
>> !    it, the SFC-aware SF MUST process the first instance and ignore
>>     subsequent instances.
>> 
>> 
>> ***************
>> *** 677,693 ****
>>  3.  NSH Actions
>> 
>>     NSH-aware nodes are the only nodes that may alter the content of NSH
>> !    headers.  NSH-aware nodes include: service classifiers, SFF, SF and
>>     SFC proxies.  These nodes have several possible NSH-related actions:
>> 
>> !    1.  Insert or remove NSH: These actions can occur at the start and
>> !        end respectively of a service path.  Packets are classified,
>>and
>> !        if determined to require servicing, NSH will be imposed.  A
>> !        service classifier MUST insert NSH at the start of an SFP.  An
>> !        imposed NSH MUST contain valid Base Header and Service Path
>>         Header.  At the end of a service function path, an SFF, MUST be
>> !        the last node operating on the service header and MUST remove
>>NSH
>> !        before forwarding or delivering the un-encapsulated packet
>> 
>>         Multiple logical classifiers may exist within a given service
>>         path.  Non-initial classifiers may re-classify data and that re-
>> --- 677,693 ----
>>  3.  NSH Actions
>> 
>>     NSH-aware nodes are the only nodes that may alter the content of NSH
>> !    headers.  NSH-aware nodes include: service classifiers, SFFs, SFs,
>>and
>>     SFC proxies.  These nodes have several possible NSH-related actions:
>> 
>> !    1.  Insert or remove NSH: These actions can occur respectively at
>>the start or
>> !        end of a service path.  Packets are classified, and
>> !        if determined to require servicing, an NSH will be imposed.  A
>> !        service classifier MUST insert an NSH at the start of an SFP.
>>An
>> !        imposed NSH MUST contain both a valid Base Header and Service
>>Path
>>         Header.  At the end of a service function path, an SFF, MUST be
>> !        the last node operating on the service header and MUST remove
>>the NSH
>> !        before forwarding or delivering the un-encapsulated packet.
>> 
>>         Multiple logical classifiers may exist within a given service
>>         path.  Non-initial classifiers may re-classify data and that re-
>> ***************
>> *** 696,702 ****
>>         classification that results in a change of service path, it MUST
>>         remove the existing NSH and MUST impose a new NSH with the Base
>>         Header and Service Path Header reflecting the new service path
>> !        information and set the initial SI.  Metadata MAY be preserved
>>in
>>         the new NSH.
>> 
>> 
>> --- 696,702 ----
>>         classification that results in a change of service path, it MUST
>>         remove the existing NSH and MUST impose a new NSH with the Base
>>         Header and Service Path Header reflecting the new service path
>> !        information and MUST set the initial SI.  Metadata MAY be
>>preserved in
>>         the new NSH.
>> 
>> 
>> ***************
>> *** 719,725 ****
>>         Service Index and MAY update contexts.  When an SFC proxy
>>         receives an NSH-encapsulated packet, it MUST remove NSH before
>>         forwarding it to an NSH unaware SF.  When the SFC Proxy receives
>> !        a packet back from an NSH unaware SF, it MUST re-encapsulates
>>it
>>         with the correct NSH, and MUST decrement the Service Index by
>>         one.
>> 
>> --- 719,725 ----
>>         Service Index and MAY update contexts.  When an SFC proxy
>>         receives an NSH-encapsulated packet, it MUST remove NSH before
>>         forwarding it to an NSH unaware SF.  When the SFC Proxy receives
>> !        a packet back from an NSH unaware SF, it MUST re-encapsulate it
>>         with the correct NSH, and MUST decrement the Service Index by
>>         one.
>> 
>> ***************
>> *** 763,778 ****
>> 
>>  4.  NSH Transport Encapsulation
>> 
>> !    Once NSH is added to a packet, an outer encapsulation is used to
>>     forward the original packet and the associated metadata to the start
>>     of a service chain.  The encapsulation serves two purposes:
>> 
>>     1.  Creates a topologically independent services plane.  Packets are
>>         forwarded to the required services without changing the
>> !        underlying network topology
>> 
>> !    2.  Transit network nodes simply forward the encapsulated packets 
>>as
>> !        is.
>> 
>>     The service header is independent of the encapsulation used and is
>>     encapsulated in existing transports.  The presence of NSH is
>> --- 763,778 ----
>> 
>>  4.  NSH Transport Encapsulation
>> 
>> !    Once a NSH is added to a packet, an outer encapsulation is used to
>>     forward the original packet and the associated metadata to the start
>>     of a service chain.  The encapsulation serves two purposes:
>> 
>>     1.  Creates a topologically independent services plane.  Packets are
>>         forwarded to the required services without changing the
>> !        underlying network topology.
>> 
>> !    2.  Transit network nodes simply forward the encapsulated packets 
>> !        without modification.
>> 
>>     The service header is independent of the encapsulation used and is
>>     encapsulated in existing transports.  The presence of NSH is
>> ***************
>> *** 788,794 ****
>> 
>>  5.  Fragmentation Considerations
>> 
>> !    NSH and the associated transport header are "added" to the
>>     encapsulated packet/frame.  This additional information increases 
>>the
>>     size of the packet.
>> 
>> --- 788,794 ----
>> 
>>  5.  Fragmentation Considerations
>> 
>> !    The NSH and the associated transport header are "added" to the
>>     encapsulated packet/frame.  This additional information increases 
>>the
>>     size of the packet.
>> 
>> ***************
>> *** 806,812 ****
>> 
>>  6.1.  SFFs and Overlay Selection
>> 
>> !    As described above, NSH contains a Service Path Identifier (SPI) 
>>and
>>     a Service Index (SI).  The SPI is, as per its name, an identifier.
>>     The SPI alone cannot be used to forward packets along a service 
>>path.
>>     Rather the SPI provides a level of indirection between the service
>> --- 806,812 ----
>> 
>>  6.1.  SFFs and Overlay Selection
>> 
>> !    As described above, an NSH contains a Service Path Identifier 
>>(SPI) and
>>     a Service Index (SI).  The SPI is, as per its name, an identifier.
>>     The SPI alone cannot be used to forward packets along a service 
>>path.
>>     Rather the SPI provides a level of indirection between the service
>> ***************
>> *** 827,839 ****
>>     is incorrect and the packet must be discarded.
>> 
>>     This indirection -- SPI to overlay -- creates a true service plane.
>> !    That is the SFF/SF topology is constructed without impacting the
>> !    network topology but more importantly service plane only 
>>participants
>>     (i.e., most SFs) need not be part of the network overlay topology 
>>and
>>     its associated infrastructure (e.g., control plane, routing tables,
>> !    etc.)  SFs need to be able to return a packet to an appropriate SFF
>> !    (i.e., has the requisite NSH information) when service processing 
>>is
>> !    complete.  This can be via the over or underlay and in some case
>> 
>> 
>> 
>> --- 827,839 ----
>>     is incorrect and the packet must be discarded.
>> 
>>     This indirection -- SPI to overlay -- creates a true service plane.
>> !    That is, the SFF/SF topology is constructed without impacting the
>> !    network topology but more importantly, service plane only 
>>participants
>>     (i.e., most SFs) need not be part of the network overlay topology 
>>and
>>     its associated infrastructure (e.g., control plane, routing tables,
>> !    etc).  SFs need to be able to return a packet to an appropriate SFF
>> !    (i.e., one that has the requisite NSH information) when service 
>>processing is
>> !    complete.  This can be via the overlay or underlay and, in some 
>>case
>> 
>> 
>> 
>> ***************
>> *** 847,853 ****
>>     requisite connectivity.
>> 
>>     The mapping of SPI to transport occurs on an SFF (as discussed 
>>above,
>> !    the first SFF in the path gets a NSH encapsulated packet from the
>>     Classifier).  The SFF consults the SPI/ID values to determine the
>>     appropriate overlay transport protocol (several may be used within a
>>     given network) and next hop for the requisite SF.  Table 1 below
>> --- 847,853 ----
>>     requisite connectivity.
>> 
>>     The mapping of SPI to transport occurs on an SFF (as discussed 
>>above,
>> !    the first SFF in the path gets an NSH encapsulated packet from the
>>     Classifier).  The SFF consults the SPI/ID values to determine the
>>     appropriate overlay transport protocol (several may be used within a
>>     given network) and next hop for the requisite SF.  Table 1 below
>> ***************
>> *** 874,880 ****
>> 
>>     Additionally, further indirection is possible: the resolution of the
>>     required SF network locator may be a localized resolution on an SFF,
>> !    rather than a service function chain control plane responsibility, 
>>as
>>     per Table 2 and Table 3 below.
>> 
>>     Please note: VXLAN-gpe and GRE in the above table refer to
>> --- 874,880 ----
>> 
>>     Additionally, further indirection is possible: the resolution of the
>>     required SF network locator may be a localized resolution on an SFF,
>> !    rather than a service function chain control-plane responsibility, 
>>as
>>     per Table 2 and Table 3 below.
>> 
>>     Please note: VXLAN-gpe and GRE in the above table refer to
>> ***************
>> *** 925,934 ****
>>     Since the SPI is a representation of the service path, the lookup 
>>may
>>     return more than one possible next-hop within a service path for a
>>     given SF, essentially a series of weighted (equally or otherwise)
>> !    paths to be used (for load distribution, redundancy or policy), see
>>     Table 4.  The metric depicted in Table 4 is an example to help
>>     illustrated weighing SFs.  In a real network, the metric will range
>> !    from a simple preference (similar to routing next- hop), to a true
>>     dynamic composite metric based on some service function-centric 
>>state
>>     (including load, sessions state, capacity, etc.)
>> 
>> --- 925,934 ----
>>     Since the SPI is a representation of the service path, the lookup 
>>may
>>     return more than one possible next-hop within a service path for a
>>     given SF, essentially a series of weighted (equally or otherwise)
>> !    paths to be used (for load distribution, redundancy, or policy), 
>>see
>>     Table 4.  The metric depicted in Table 4 is an example to help
>>     illustrated weighing SFs.  In a real network, the metric will range
>> !    from a simple preference (similar to routing next-hop), to a true
>>     dynamic composite metric based on some service function-centric 
>>state
>>     (including load, sessions state, capacity, etc.)
>> 
>> ***************
>> *** 981,987 ****
>>     Furthermore, the SPI to overlay mapping occurs at each SFF
>>     independently.  Any combination of topology selection is possible.
>>     Please note, there is no requirement to create a new overlay 
>>topology
>> !    if a suitable one already existing.  NSH packets can use any (new 
>>or
>>     existing) overlay provided the requisite connectivity requirements
>>     are satisfied.
>> 
>> --- 981,987 ----
>>     Furthermore, the SPI to overlay mapping occurs at each SFF
>>     independently.  Any combination of topology selection is possible.
>>     Please note, there is no requirement to create a new overlay 
>>topology
>> !    if a suitable one already exists.  NSH packets can use any (new or
>>     existing) overlay provided the requisite connectivity requirements
>>     are satisfied.
>> 
>> ***************
>> *** 1025,1032 ****
>>     The SPI and SI serve an important function for visibility into the
>>     service topology.  An operator can determine what service path a
>>     packet is "on", and its location within that path simply by viewing
>> !    NSH information (packet capture, IPFIX, etc.)  The information can 
>>be
>> !    used for service scheduling and placement decisions, 
>>troubleshooting
>>     and compliance verification.
>> 
>>  6.4.  Service Graphs
>> --- 1025,1032 ----
>>     The SPI and SI serve an important function for visibility into the
>>     service topology.  An operator can determine what service path a
>>     packet is "on", and its location within that path simply by viewing
>> !    NSH information (packet capture, IPFIX, etc).  The information can 
>>be
>> !    used for service scheduling and placement decisions, 
>>troubleshooting,
>>     and compliance verification.
>> 
>>  6.4.  Service Graphs
>> ***************
>> *** 1092,1098 ****
>> 
>>                  +-------+        +-------+        +-------+
>>                  |  SFF  )------->(  SFF  |------->|  SFF  |
>> !                 +---^---+        +---|---+        +---|---+
>>                    ,-|-.            ,-|-.            ,-|-.
>>                   /     \          /     \          /     \
>>                  ( Class )        (  SF1  )        (  SF2  )
>> --- 1092,1099 ----
>> 
>>                  +-------+        +-------+        +-------+
>>                  |  SFF  )------->(  SFF  |------->|  SFF  |
>> !                 +---+---+        +---+---+        +---+---+
>> !                     ^                |                | 
>>                    ,-|-.            ,-|-.            ,-|-.
>>                   /     \          /     \          /     \
>>                  ( Class )        (  SF1  )        (  SF2  )
>> ***************
>> *** 1135,1141 ****
>>                +---+---+          employees
>>                |       |
>>                +-------+
>> !               external
>>                system:
>>                Employee
>>                AppZ
>> --- 1136,1142 ----
>>                +---+---+          employees
>>                |       |
>>                +-------+
>> !               External
>>                system:
>>                Employee
>>                AppZ
>> ***************
>> *** 1151,1157 ****
>>     considerations may need to be considered.  For example, if the
>>     metadata conveys tenant information, that information may need to be
>>     authenticated and/or encrypted between the originator and the
>> !    intended recipients (which may include intended SFs only) .  NSH
>>     itself does not provide privacy functions, rather it relies on the
>>     transport/overlay layer.  An operator can select the appropriate
>>     transport to ensure confidentially (and other security)
>> --- 1152,1158 ----
>>     considerations may need to be considered.  For example, if the
>>     metadata conveys tenant information, that information may need to be
>>     authenticated and/or encrypted between the originator and the
>> !    intended recipients (which may include intended SFs only).  The NSH
>>     itself does not provide privacy functions, rather it relies on the
>>     transport/overlay layer.  An operator can select the appropriate
>>     transport to ensure confidentially (and other security)
>> ***************
>> *** 1161,1169 ****
>>  7.2.  Updating/Augmenting Metadata
>> 
>>     Post-initial metadata imposition (typically performed during initial
>> !    service path determination), metadata may be augmented or updated:
>> 
>> !    1.  Metadata Augmentation: Information may be added to NSH's 
>>existing
>>         metadata, as depicted in Figure 10.  For example, if the initial
>>         classification returns the tenant information, a secondary
>>         classification (perhaps co-resident with DPI or SLB) may augment
>> --- 1162,1170 ----
>>  7.2.  Updating/Augmenting Metadata
>> 
>>     Post-initial metadata imposition (typically performed during initial
>> !    service path determination) of metadata may be augmented or 
>>updated:
>> 
>> !    1.  Metadata Augmentation: Information may be added to an NSH's 
>>existing
>>         metadata, as depicted in Figure 10.  For example, if the initial
>>         classification returns the tenant information, a secondary
>>         classification (perhaps co-resident with DPI or SLB) may augment
>> ***************
>> *** 1184,1190 ****
>>     2.  Metadata Update: Subsequent classifiers may update the initial
>>         classification if it is determined to be incorrect or not
>>         descriptive enough.  For example, the initial classifier adds
>> !        metadata that describes the traffic as "internet" but a 
>>security
>>         service function determines that the traffic is really "attack".
>>         Figure 11 illustrates an example of updating metadata.
>> 
>> --- 1185,1191 ----
>>     2.  Metadata Update: Subsequent classifiers may update the initial
>>         classification if it is determined to be incorrect or not
>>         descriptive enough.  For example, the initial classifier adds
>> !        metadata that describes the traffic as "Internet" but a 
>>security
>>         service function determines that the traffic is really "attack".
>>         Figure 11 illustrates an example of updating metadata.
>> 
>> ***************
>> *** 1201,1207 ****
>>                +---+---+          employees         employee+
>>                |       |          Class=AppZ        appZ
>>                +-------+
>> !               external
>>                system:
>>                Employee
>> 
>> --- 1202,1208 ----
>>                +---+---+          employees         employee+
>>                |       |          Class=AppZ        appZ
>>                +-------+
>> !               External
>>                system:
>>                Employee
>> 
>> ***************
>> *** 1290,1296 ****
>>  Internet-Draft        Network Service Header (NSH)             July 
>>2017
>> 
>> 
>> !    NSH is always encapsulated in a transport protocol and therefore,
>>     when required, existing security protocols that provide authenticity
>>     (e.g., [RFC6071]) can be used.  Similarly, if confidentiality is
>>     required, existing encryption protocols can be used in conjunction
>> --- 1291,1297 ----
>>  Internet-Draft        Network Service Header (NSH)             July 
>>2017
>> 
>> 
>> !    An NSH is always encapsulated in a transport protocol and 
>>therefore,
>>     when required, existing security protocols that provide authenticity
>>     (e.g., [RFC6071]) can be used.  Similarly, if confidentiality is
>>     required, existing encryption protocols can be used in conjunction
>> ***************
>> *** 1303,1314 ****
>> 
>>     NSH metadata authenticity and confidentiality must be considered as
>>     well.  In order to protect the metadata, an operator can leverage 
>>the
>> !    aforementioned mechanisms provided the transport layer, 
>>authenticity
>>     and/or confidentiality.  An operator MUST carefully select the
>> !    transport/underlay services to ensure end to end security services,
>> !    when those are sought after.  For example, if [RFC6071] is used, 
>>the
>>     operator MUST ensure it can be supported by the transport/underlay 
>>of
>> !    all relevant network segments as well as SFF and SFs.  Further, as
>>     described in Section 8.1, operators can and should use indirect
>>     identification for personally identifying information, thus
>>     significantly mitigating the risk of privacy violation.  Means to
>> --- 1304,1316 ----
>> 
>>     NSH metadata authenticity and confidentiality must be considered as
>>     well.  In order to protect the metadata, an operator can leverage 
>>the
>> !    aforementioned mechanisms provided by the transport layer 
>>including authenticity
>>     and/or confidentiality.  An operator MUST carefully select the
>> !    transport/underlay services to ensure end-to-end security services,
>> !    when those are sought.  For example, if [RFC6071] is used, the
>>     operator MUST ensure it can be supported by the transport/underlay 
>>of
>> !    all relevant network segments as well as SFF and SFs in the 
>>service path.  
>> !    Further, as
>>     described in Section 8.1, operators can and should use indirect
>>     identification for personally identifying information, thus
>>     significantly mitigating the risk of privacy violation.  Means to
>> ***************
>> *** 1318,1324 ****
>>     packet upstream.
>> 
>>     Lastly, SF security, although out of scope of this document, should
>> !    be considered, particularly if an SF needs to access, authenticate 
>>or
>>     update NSH metadata.
>> 
>>  9.  Contributors
>> --- 1320,1326 ----
>>     packet upstream.
>> 
>>     Lastly, SF security, although out of scope of this document, should
>> !    be considered, particularly if an SF needs to access, 
>>authenticate, or
>>     update NSH metadata.
>> 
>>  9.  Contributors
>> ***************
>> *** 1466,1472 ****
>>     design.
>> 
>>     The editors also acknowledge comprehensive reviews and respective
>> !    suggestions by Med Boucadair and Adrian Farrel.
>> 
>>     Lastly, David Dolson has provides significant review, feedback and
>>     suggestions throughout the evolution of this document.  His
>> --- 1468,1474 ----
>>     design.
>> 
>>     The editors also acknowledge comprehensive reviews and respective
>> !    suggestions by Med Boucadair, Adrian Farrel, and Acee Lindem.
>> 
>>     Lastly, David Dolson has provides significant review, feedback and
>>     suggestions throughout the evolution of this document.  His
>> 
>> Thanks,
>> Acee 
>
>—
>Carlos Pignataro, carlos@cisco.com
>
>“Sometimes I use big words that I do not fully understand, to make myself 
>sound more photosynthesis."
>