[sfc] Alvaro Retana's Abstain on draft-ietf-sfc-hierarchical-09: (with COMMENT)

[Alvaro Retana <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-sfc-hierarchical-09: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.