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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Acee,

> On Aug 11, 2017, at 11:58 AM, Acee Lindem (acee) <[e-mail]> wrote:
> 
> Hi Carlos, 
> 
> On 8/11/17, 12:06 AM, "Carlos Pignataro on behalf of Carlos Pignataro
> (cpignata)" <[e-mail] on behalf of [e-mail]> 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) <[e-mail]> 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.

Great.

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

Sure, I added: “NSH MD Type 1 and MD Type 2 are described in detail in Sections 2.4 and 2.5, respectively."

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

Thanks!

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

I missed it here, but I did capitalize it in the working copy (and diffs I sent).

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

Ack.

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

Thanks.

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

Yes, the architecture is RFC 7665. See the last sentence of the Abstract.

Thanks, Acee! All covered in our working copy.

— Carlos.

> 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, [e-mail]
>> 
>> “Sometimes I use big words that I do not fully understand, to make myself 
>> sound more photosynthesis."
>> 
> 

—
Carlos Pignataro, [e-mail]

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."