Hierarchical Service Function Chaining (hSFC)
RFC 8459

Note: This ballot was opened for revision 08 and is now closed.

Martin Vigoureux Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2018-06-19 for -09)
No email
send info
§10: "This document describes systems that may be managed by distinct teams of a single administrative entity."

I had to re-read this a few times to realize you meant distinct teams that are all part of the same entity, not distinct teams each made up of one entity.

(Suresh Krishnan) No Objection

Comment (2018-06-20 for -09)
No email
send info
I am balloting No Objection but I share Alvaro's concern that the document needs to do further work on analyzing (and potentially narrowing down) the options in order to be useful.

(Mirja Kühlewind) No Objection

(Adam Roach) No Objection

Alissa Cooper Abstain

Comment (2018-06-21 for -09)
No email
send info
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.

Benjamin Kaduk (was Discuss) Abstain

Comment (2018-06-22 for -10)
No email
send info
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.

Alvaro Retana Abstain

Comment (2018-06-19 for -09)
No email
send info
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.