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

From: Alvaro Retana <[email-masked]>
Date: Tue, 19 Jun 2018 14:43:41 -0700

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.

---

From: <[email-masked]>
Date: Wed, 20 Jun 2018 06:04:47 +0000

Hi Alvaro, 

Thank you for the review. 

Please see inline. 

Cheers,
Med 

> -----Message d'origine-----
> De : Alvaro Retana [mailto:[email-masked]]
> Envoyé : mardi 19 juin 2018 23:44
> À : The IESG
> Cc : [email-masked]; Behcet Sarikaya; sfc-
> [email-masked]; [email-masked]
> Objet : Alvaro Retana's Abstain on draft-ietf-sfc-hierarchical-09: (with
> COMMENT)
> 

[Med] The mandate we had for this document is to discuss options without making any recommendation. This is why the document is an Informational one and no normative language is used. 

> including, for example, state synchronization between IBNs (§4.1.1)

[Med] This is not a speculation but a valid statement:

" If the packet is returned to a different egress IBN,
   state must be synchronized between the IBNs."

The state to glue between layers is created at the ingress IBN. If a distinct IBN is used when existing the sub-domain, then the required state must be instantiated in that IBN.  

 without
> specific proposals...

[Med] The purpose of the above statement is to call out a deployment issue under such mode, not to specific how to solve (this is deployment-specific). An operator which follows the option §4.1.1 can force that the same IBN is used as ingress/egress.  

or, my favorite, the nesting of NSH headers (§4.1.4).  I
> transport encapsulations...

[Med] Not sure to understand what you meant by "add/remove NSH Headers within specific transport encapsulations". 

but that is not discussed.  Again, I think that
> was
> hSFC may help.

[Med] The document already includes examples of how hSFC helps (e.g., reduce the number of service paths as discussed in the appendix). 

  But I didn't find related work in the datatracker.
> further analysis and evaluation before eventual publication reflecting *the*

[Med] The document defines an hSFC architecture that is common to all options: 
- Hierarchy layers
- Glue between layers: IBN

As I mentioned above, the intent is not to mandate ONE option for achieving that architecture, but to identify and discuss options for achieving it.