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

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
This does seem like an interesting and potentially useful idea -- thanks
for doing the work!  However, I am not sure that the document as-is is
suitable for publication.

In Section 4.1.5 we hear that preserving metadata and applying metadata to
injected packets is not special and is "usual" functionality, but
section 4.1.2 calls out that the 4.1.2 approach requires the SFs in the
path to be capable of forwarding metadata and attaching metadata to
injected packets as if it is a nontrivial requirement.  This apparent
internal inconsistency needs to be resolved before publication.

Why does Section 4.1 offer five different choices with no guidance on how
to make a cost/benefit analysis amongst them?  Is the full spread of five
choices really necessary?  Complexity breeds implementation bugs which
breed security issues, so I feel that this breadth of choice needs to be
justified.  This also ties into some confusion I have as to the goal of
this document (which currently targets Informational status), akin to what
is stated in Alvaro's ballot position: is it just providing information on
how to assemble existing pieces in a novel way, or presenting a new
protocol specification that is not yet fit for Proposed Standard status, or
is it listing out potential solutions to a problem so that they can be
implemented and experience gained as to which are useful in practice and
which are not?  Accordingly, I would be interested to hear about what
deployment experience exists already and whether this abstraction proves to
be as useful as the use cases seem to promise; if there is little
implementation experience, perhaps Experimental status is more appropriate.

I further am uncertain as to whether the approach described in Section
4.1.3 even merits consideration at all; the technique it describes seems to
have a very leaky abstraction barrier (e.g., w.r.t TTL modifications).
This seems especially poignant given the already large size of candidate
approaches.

The approach described in Section 4.1.5 also seems to be incompletely
specified, in that the hSFC Flow ID semantics are not covered at all.  On
my initial reading I assumed that this field's encoding and semantics were
intended to be left as entirely local matters to the lower domain, avoiding
a need to specify them in this document.  However, I'm not sure that it's
actually true, since we generally want multiple vendors to be able to
interoperate, and this scheme does not appear to require that the node
applying the hSFC Flow ID (and saving state) is the same node that removes
it (and restores state).  That is, these two nodes could potentially be
implemented by different vendors.

Even once the above issues are resolved, I will only be able to move to an
Abstain position, since this document proposes additional usage of
(meta)data in the NSH headers that is not subject to mandatory integrity
protection, as was discussed at length for RFC 8300 and is mandated to be
available by RFC 7665.

[Ballot comment]
Section 4

  To achieve the benefits of hierarchy, the IBN should be applying more
  granular traffic classification rules at the lower level than the
  traffic passed to it.  This means that the number of SFPs within the
  lower level is greater than the number of SFPs arriving to the IBN.

"more granular" and "less granular" are unfortunately ambiguous in
practical usage; I suggest "fine-grained" as an alternative for this usage.

Section 4.1.5

Figure 4's caption should indicate where the base NSH fixed-length context
header is originally defined.

Section 4.4 presents another operational choice that contributes to
exponential complexity growth, and further highlights unique properties of
the Section 4.1.3 approach that may render it unsuitable for inclusion.

Section 7.2

  Other fundamental functions required as IBN (e.g., maintaining
  metadata of upper level or decrementing Service Index) are same as
  normal usage.

nit: "the same as in normal usage"

Also, I think the two occurrences of "to permit specific metadata types"
should be "to *only* permit specific metadata types".


Section 10.1

  Security considerations related to the control plane should be
  discussed in the corresponding control specification documents (e.g.,
  [I-D.ietf-bess-nsh-bgp-control-plane],
  [I-D.wu-pce-traffic-steering-sfc], or [I-D.maglione-sfc-nsh-radius]).

I'm going to call this a nit, but "should be discussed" sounds as if this
document is trying to direct the behavior of the other listed documents;
maybe "are discussed" is better.

Section A.1 could perhaps note the potential drawback that the
classification functionality is now distributed across the domains instead
of being totally centralized at the initial entry, which requires greater
coordination between the different classifers.  (This is, of course,
not necessarily a drawback for all deployments, but could be for some.)

[Ballot comment]
§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.

[Ballot 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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-sfc-hierarchical-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-05-21):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sfc-hierarchical@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, Behcet Sarikaya , sarikaya@ieee.org, martin.vigoureux@nokia.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Hierarchical Service Function Chaining (hSFC)) to Informational RFC


The IESG has received a request from the Service Function Chaining WG (sfc)
to consider the following document: - 'Hierarchical Service Function Chaining
(hSFC)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-05-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Hierarchical Service Function Chaining (hSFC) is a network
  architecture allowing an organization to decompose a large-scale
  network into multiple domains of administration.

  The goals of hSFC are to make a large-scale network easier to reason
  about, simpler to control and to support independent functional
  groups within large network operators.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sfc-hierarchical/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

  The document shepherd is Behcet Sarikaya. The responsible Area Director is Alia Atlas.

  Instead of considering a single SFC control plane that can manage
  complete service paths from one end of the network
  to the other, the document adopts an approach that decomposes
  large networks into smaller domains operated
  by as many SFC sub-domains (under the same administrative entity).

  This approach is called: Hierarchical Service Function Chaining (hSFC)

  hSFC is a network architecture allowing an organization to decompose a large-scale
  network into multiple domains of administration.

  The goals of hSFC are to make a large-scale network easier to reason
  about, simpler to control and to support independent functional
  groups within large network operators.

  Another goal of the hierarchical approach is to simplify the
  mechanisms of scaling in and scaling out service functions (SFs).  All of the
  complexities of load-balancing among multiple SFs can be handled
  within a sub-domain, under control of the classifier, allowing the
  higher-level domain to be oblivious to the existence of multiple SF
  instances.

  The document is informational. It formulates the problem and identifies
  viable options to achieve hSFC. For example, this document describes how
  nesting NSH headers, i.e. NSH-in-NSH functionality hinted in RFC8300 is used.


2. Review and Consensus

 
  Two WGLCs were made for this document. The second one was mainly to confirm that the comments
  raised during the first call are well addressed.
 
  There seems to be consensus in the working group that the document is ready for publication.

3. Intellectual Property

  There are no known IPR disclosures on the document.

  Each of the authors has confirmed that they are not familiar with any IPR that applies
  to this document, in conformance with BCPs 78 and 79.

4. Other Points

  No IANA action is requested by the document.

Request for posting confirmation emailed to previous authors: Vu Vu , sfc-chairs@ietf.org, Ting Ao , Mohamed Boucadair , Diego Lopez , Dapeng Liu , David Dolson , Shunsuke Homma

Request for posting confirmation emailed to previous authors: Ting Ao , Vu Vu , Mohamed Boucadair , Diego Lopez , Dapeng Liu , David Dolson , Shunsuke Homma

Request for posting confirmation emailed to previous authors: Ting Ao , Vu Vu , Mohamed Boucadair , Diego Lopez , Dapeng Liu , David Dolson , Shunsuke Homma

Request for posting confirmation emailed to previous authors: "Shunsuke Homma" , "Vu Vu" , "Diego Lopez" , "Ting Ao" , "David Dolson" , sfc-chairs@ietf.org, "Mohamed Boucadair" , "Dapeng Liu"

Request for posting confirmation emailed to previous authors: "Shunsuke Homma" , "Diego Lopez" , "Vu Anh Vu" , "Ting Ao" , "David Dolson" , sfc-chairs@ietf.org, "Mohamed Boucadair" , "Dapeng Liu"