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

[<[e-mail]>]

Hi Alvaro, 

Thank you for the review. 

Please see inline. 

Cheers,
Med 

> -----Message d'origine-----
> De : Alvaro Retana [mailto:[e-mail]]
> Envoyé : mardi 19 juin 2018 23:44
> À : The IESG
> Cc : [e-mail]; Behcet Sarikaya; sfc-
> [e-mail]; [e-mail]
> Objet : Alvaro Retana's Abstain on draft-ietf-sfc-hierarchical-09: (with
> COMMENT)
> 
> 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.

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

> 
> The options themselves include speculation about how things could work;
> 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
> 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...

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

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

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

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