Hierarchical Service Function Chaining (hSFC)
draft-ietf-sfc-hierarchical-11

I agree with Benjamin's DISCUSS. In particular, each of the options presented in Section 4.1 seem to have challenges that could render them unworkable, and no insights from deployment experience are provided to explain why they are in fact workable in practice. I think it would be preferable to do the further analysis suggested by Alvaro before publishing an informational document about hSFC. With that said, given that this is an informational document I wouldn't stand in the way of it being published.

The hSFC concept is indeed interesting -- thanks for doing the work!

Reading through the document, I found myself thinking about its usefulness.  The Introduction says that it "focuses on the difficult problem of implementing SFC across a large, geographically dispersed network, potentially comprised of millions of hosts and thousands of network forwarding elements, and which may involve multiple operational teams (with varying functional responsibilities)."  However, the content doesn't deal directly with the implementation/operational issues -- and offers instead a list of options around the IBN, with no clear or explicit recommendation.  Even though it is not explicitly mentioned anywhere, I think that is the intent of the document.

The options themselves include speculation about how things could work; including, for example, state synchronization between IBNs (§4.1.1) without specific proposals...or, my favorite, the nesting of NSH headers (§4.1.4).  I note that even though the NSH spec (rfc8300) offers a Next Protocol value of "NSH", and the architecture (rfc7665) is such that "the SFC encapsulation remain transport independent...[and]...any network transport protocol may be used", it may not be possible to add/remove NSH Headers within specific transport encapsulations...but that is not discussed.  Again, I think that was the intent.

The design of the document (present options, but don't dig deep into any of them) is ok.  It would be nicer if the WG would move this work forward by exploring the options, specifying them and having detailed operational considerations related to "the difficult problem of implementing SFC" and how hSFC may help.  But I didn't find related work in the datatracker.

In the end, I believe that this document is valuable as a discussion piece which may lead to future work...but, in my opinion, it doesn't need to be published as an RFC to serve that purpose...and it could in fact benefit from further analysis and evaluation before eventual publication reflecting *the* hSFC architecture.  

Given that we're at the IESG Evaluation point in the process, I won't stand in the way of publication and have chosen to ABSTAIN instead.

Thanks for the quick updates to the document.

As previously indicated, I am Abstaining, since this document includes a proposal for adding
a new category of NSH metadata contents, and as discussed during RFC 8300's evaluation there
is not a mandatory integrity protection option for such metadata.