An MPLS-Based Forwarding Plane for Service Function Chaining
draft-ietf-mpls-sfc-07

Apologies, I intended to finish reviewing this, but ran out of time (and have an early flight tomorrow). What I read all seemed fine, and I'm balloting NoObj.

I do have 2 tiny nits:
Abstract:
 "Actions may include swapping or popping the labels as well, as using the labels" -- the comma seems superfluous / wrong.

I think perhaps "NSH MUST NOT assign SPI values greater than (1048575)  2^20 - 1 or less than 16." -- I'm concerned that people might be lazy and not everyone can do 2^20 -1 in their head.

Thanks for addressing my DISCUSS. Original COMMENT below.

= Section 4.5 =

OLD
The application of SR to SFC was considered in early versions of the
   SR architecture [RFC8402] and the MPLS-SR specification
   [I-D.ietf-spring-segment-routing-mpls], but has since been moved out
   of those documents.

NEW
The application of SR to SFC was considered in early versions of the
   SR architecture [RFC8402] and the MPLS-SR specification
   [I-D.ietf-spring-segment-routing-mpls], but was not ultimately adopted.

(I think this is about the ideas, not the organization of documents.)

Thank you for a very clear document!

I think that the only NSH functionality not included in this document is the O bit (OAM packet).  I know that, even in rfc8300, the operation (beyond setting the bit) is not defined...and that work is still in progress in the SFC WG.  However, given that this document describes a "logical representation of the NSH", I think it is necessary to point out why the coverage is not complete.  In looking through the mail archive, I like the thoughts posted by one of the authors [1] and would like to see something like that reflected in the document.

[1] https://mailarchive.ietf.org/arch/msg/mpls/b9Duw-9ShdCrIRyis3TOJWw-_pw


nits:

s/(as described in Section 4.1/(as described in Section 4.1)

s/(see [I-D.ietf-bess-nsh-bgp-control-plane]/(see [I-D.ietf-bess-nsh-bgp-control-plane])

s/TC:  The TC bits have no meaning./TC:  The TC bits have no meaning in this case.

s/to determine to which SFF or instance of an SF (an SFI) to deliver the packet./to determine which SFF or instance of an SF (an SFI) to deliver the packet to.

Thank you for resolving my DISCUSS points!

I have discussed appropriate text with the editors that will resolve my DISCUSS and trust them to submit a new draft.

One minor editorial comment:
The abstract is quite long (compared to usual RFC abstracts). I recommend to only have the last paragraph (or a slightly extended version of the last paragraph).