BGP Control Plane for the Network Service Header in Service Function Chaining
draft-ietf-bess-nsh-bgp-control-plane-18

Thank you for addressing my DISCUSS and COMMENT points.

Thanks for the work on this document. I have only two comments, both
minor and editorial.

---------------------------------------------------------------------------

Please expand the following acronyms upon first use, in the abstract, and in
the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for
guidance.

 - NSH
 - SFC
 - AFI
 - SAFI
 - AF
 - NLRI
 - L3VPN
 - EVPN

---------------------------------------------------------------------------

§8, §8.1, §8.2, §8.3, §8.4, §8.5, §8.6, §8.7, §8.7, §8.9.1, §8.9.2, §8.9.3,
§8.9.4, §8.9.1, §8.9.2:

All of the examples in these sections use IPv4 addresses exclusively. Please
update them to use IPv6 exclusively, or to use a mix of IPv4 and IPv6. See
https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for further details.

I trust my ART co-ADs on this one, as I only skimmed the document.

[Thanks for addressing my DISCUSS.]

— Section 1.2 —

   o  Service Function Overlay Network.  The logical network comprised
      of Classifiers, SFFs, and SFIs that are connected by paths or
      tunnels through underlay transport networks.

You use “comprises” correctly four other times in the document, but this one is incorrect: “comprised of” should instead be either “comprising” or “composed of”.  I only bother mentioning it because it’s right the four other times.

— Section 3.1 —

   The Service Function Type identifies the functions/features of
   service function can offer, e.g., classifier, firewall, load
   balancer, etc.

Should this be “a service function”, rather than “of service function”?  And a nit: you don’t need both “e.g.” and “etc.” together: either one will do on its own.

— Section 3.2.1 —

   o  The errors listed above are treated as follows:

      1., 2., 6., 7.:  The attribute MUST be treated as malformed and
         the "treat-as-withdraw" approach used as per [RFC7606].

      3.:  Unknown TLVs SHOULD be ignored, and message processing SHOULD
         continue.

      4.:  Treated as a malformed message and the "treat-as-withdraw"
         approach used as per [RFC7606]

Why is 4 not included in the 1,2,6,7 group?  It seems odd to separate it and not to make it “MUST”, like the others.

— Section 9 —

   Service Function Chaining provides a significant attack opportunity:
   packets can be diverted from their normal paths through the network,
   can be made to execute unexpected functions, and the functions that
   are instantiated in software can be subverted.

The second item in the list appears to lack a subject: <what?> can be made to execute unexpected functions.

Thank you for addressing my discuss (and comment!) points!