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

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

Alia,

On Aug 10, 2017, at 10:24 PM, Alia Atlas <[e-mail]<mailto:[e-mail]>> wrote:

Acee,

Thank you for your review.  I look forward to the editors & WG discussing
how to improve
the draft.

Seems all these minor review items are fairly localized, clear, and non-contentious.

We have provided responses and diffs on the list, and a new revision is ready to be submitted when Joel / you wants us to pull the trigger (addressing Ops and RTG Dirs).

Thanks,

— Carlos.


Regards,
Alia

On Thu, Aug 10, 2017 at 9:10 PM, Acee Lindem (acee) <[e-mail]<mailto:[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. It needs to be consumed along with the Service
Function Chaining architecture.

Comments:
   The document is an important piece of the Service Function Chaining
work. I think the readability could be greatly improved with the editorial
changes I have suggested. For example, using articles, e.g. “the”, when
referring to the NSH.

Major Issues: N/A

Minor Issues:

     Section 1: Run-on sentense that makes up the entire third paragraph
           is too hard to parse. Please split it up and avoid
           cascading so many dependent clauses.


     Section 2.2: The discussion of meta-data support for MD types 0x1 or
                            0x3 is out of context.

     Section 2.4: The MUST's are contradictory. First it says the context
                           header MUST be 16 bytes than it says it MUST
be 0 bytes if
                           it contains no meta-data. This is hardly
"fixed".

     Section 2.5.1: Mandating that the unassigned bit MUST NOT be set will
                              without saying it MUST be ignored on
receipt is
                              not be backward compatible.

    Section 11.2.1: List the bits that are assigned.

    Section 11.2.6: MD types 1 and 2 are assigned by the document yet
                                this section states that no values are
assigned.

Nits:

ACEE-M-G2HR:Desktop acee$ diff -c draft-ietf-sfc-nsh-18.txt.orig
draft-ietf-sfc-nsh-18.txt
*** draft-ietf-sfc-nsh-18.txt.orig 2017-08-04 07:27:08.000000000 -0400
--- draft-ietf-sfc-nsh-18.txt 2017-08-10 20:50:45.000000000 -0400
***************
*** 18,24 ****

    This document describes a Network Service Header (NSH) inserted onto
    packets or frames to realize service function paths.  NSH also
!    provides a mechanism for metadata exchange along the instantiated
    service paths.  NSH is the SFC encapsulation required to support the
    Service Function Chaining (SFC) architecture (defined in RFC7665).

--- 18,24 ----

    This document describes a Network Service Header (NSH) inserted onto
    packets or frames to realize service function paths.  NSH also
!    provides a mechanism for metadata exchange along instantiated
    service paths.  NSH is the SFC encapsulation required to support the
    Service Function Chaining (SFC) architecture (defined in RFC7665).

***************
*** 181,187 ****

    Metadata:  Defined in [RFC7665].

!    Network Locator:  dataplane address, typically IPv4 or IPv6, used to
       send and receive network traffic.

    Network Node/Element:  Device that forwards packets or frames based
--- 181,187 ----

    Metadata:  Defined in [RFC7665].

!    Network Locator:  Dataplane address, typically IPv4 or IPv6, used to
       send and receive network traffic.

    Network Node/Element:  Device that forwards packets or frames based
***************
*** 191,204 ****
       (the underlay).  Packets are encapsulated or tunneled to create
       the overlay network topology.

!    NSH-aware  SFC-encapsulation-aware, or SFC-aware [RFC7665].

!    Service Classifier:  Logical entity providing classification
       function.  Since they are logical, classifiers may be co-resident
       with SFC elements such as SFs or SFFs.  Service classifiers
       perform classification and impose NSH.  The initial classifier
       imposes the initial NSH and sends the NSH packet to the first SFF
!       in the path.  Non-initial (i.e.  subsequent) classification can
       occur as needed and can alter, or create a new service path.

    Service Function (SF):  Defined in [RFC7665].
--- 191,204 ----
       (the underlay).  Packets are encapsulated or tunneled to create
       the overlay network topology.

!    NSH-aware: SFC-encapsulation-aware, or SFC-aware [RFC7665].

!    Service Classifier:  Logical entity providing the classification
       function.  Since they are logical, classifiers may be co-resident
       with SFC elements such as SFs or SFFs.  Service classifiers
       perform classification and impose NSH.  The initial classifier
       imposes the initial NSH and sends the NSH packet to the first SFF
!       in the path.  Non-initial (i.e., subsequent) classification can
       occur as needed and can alter, or create a new service path.

    Service Function (SF):  Defined in [RFC7665].
***************
*** 269,277 ****

 2.  Network Service Header

!    NSH contains service path information and optionally metadata that
    are added to a packet or frame and used to create a service plane.
!    An outer transport header is imposed, on NSH and the original packet/
    frame, for network forwarding.


--- 269,277 ----

 2.  Network Service Header

!    The NSH contains service path information and optionally metadata that
    are added to a packet or frame and used to create a service plane.
!    An outer transport header is imposed on the NSH and the original
packet/
    frame, for network forwarding.


***************
*** 282,293 ****
 Internet-Draft        Network Service Header (NSH)             July 2017


!    A Service Classifier adds NSH.  NSH is removed by the last SFF in the
    service chain or by an SF that consumes the packet.

 2.1.  Network Service Header Format

!    NSH is composed of a 4-byte Base Header, a 4-byte Service Path Header
    and optional Context Headers, as shown in Figure 1 below.

       0                   1                   2                   3
--- 282,293 ----
 Internet-Draft        Network Service Header (NSH)             July 2017


!    A Service Classifier adds the NSH. The  NSH is removed by the last
SFF in the
    service chain or by an SF that consumes the packet.

 2.1.  Network Service Header Format

!    The NSH is composed of a 4-byte Base Header, a 4-byte Service Path
Header
    and optional Context Headers, as shown in Figure 1 below.

       0                   1                   2                   3
***************
*** 304,316 ****

                      Figure 1: Network Service Header

!    Base header: provides information about the service header and the
    payload protocol.

!    Service Path Header: provides path identification and location within
    a service path.

!    Context header: carries metadata (i.e., context data) along a service
    path.

 2.2.  NSH Base Header
--- 304,316 ----

                      Figure 1: Network Service Header

!    Base header: Provides information about the service header and the
    payload protocol.

!    Service Path Header: Provides path identification and location within
    a service path.

!    Context header: Carries metadata (i.e., context data) along a service
    path.

 2.2.  NSH Base Header
***************
*** 368,374 ****
    for service plane loop detection.  The initial TTL value SHOULD be
    configurable via the control plane; the configured initial value can
    be specific to one or more SFPs.  If no initial value is explicitly
!    provided, the default initial TTL value 63 MUST be used.  Each SFF
    involved in forwarding an NSH packet MUST decrement the TTL value by
    1 prior to NSH forwarding lookup.  Decrementing by 1 from an incoming
    value of 0 shall result in a TTL value of 63.  The packet MUST NOT be
--- 368,374 ----
    for service plane loop detection.  The initial TTL value SHOULD be
    configurable via the control plane; the configured initial value can
    be specific to one or more SFPs.  If no initial value is explicitly
!    provided, the default initial TTL value of 63 MUST be used.  Each SFF
    involved in forwarding an NSH packet MUST decrement the TTL value by
    1 prior to NSH forwarding lookup.  Decrementing by 1 from an incoming
    value of 0 shall result in a TTL value of 63.  The packet MUST NOT be
***************
*** 380,389 ****
    elements.  Elements which do not understand the meaning of any of
    these bits MUST NOT modify their actions based on those unknown bits

—
Carlos Pignataro, [e-mail]<mailto:[e-mail]>

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