Subject: [sfc] Benoit Claise's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 28 May 2015 06:11:30 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-sfc-architecture-08: Discuss

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-architecture/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

DISCUSS-DISCUSS: no action from the authors is expected at this point.
This will be discussed during the telechat.

- Can you explain this disconnect:
>From the charter:

    It will produce an architecture for service function
    chaining that includes the necessary protocols or protocol extensions
to
    convey the Service Function Chain and Service Function Path
information
    to nodes that are involved in the implementation of service
functions
    and Service Function Chains, as well as mechanisms for steering
traffic
    through service functions.

>From the abstract:

    This document does not propose solutions, protocols, or
       extensions to existing protocols.

While I'm on the charter, I'm always available for this milestone:

    Apr 2014 Consult with OPS area on possible SFC charter modifications
for management and configuration of SFC components related to the support
of Service Function Chaining

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

- Section 1.1
What does "minimum requirements on the physical topology"mean in:

   This document defines the architecture for Service Function Chaining
   (SFC) with minimum requirements on the physical topology of the
   network, as standardized in the IETF. 

It seems to me that "independent" is what you're after, like in:
   "it describes a method for deploying SFs in a way that enables
   dynamic ordering and topological independence of those SFs as well as
   the exchange of metadata between participating entities."

or
   "This SFC architecture is predicated on topological independence from
   the underlying forwarding topology." 

- Service Function Path definition: I'm confused. you don't explain what
it is, but only explain why you need it.
Later on, I see "As an example of such an intermediate specificity, there
may be two
SFPs associated with a given SFC". I'm confused.
Not too clear on how the SFP and RSP relate to each others.
Is the Service Function Path the ordered list of SFs, while the RSP is
the ordered list of SFFs?

-
"Traffic from SFs eventually returns to the same SFF, which is
responsible for injecting traffic back onto the network. 

Am I correct that it only applies in case of a SFC proxy?
Related question, along the same lines:

       1.  SFP forwarding : Traffic arrives at an SFF from the network. 
The
       SFF determines the appropriate SF the traffic should be forwarded
       to via information contained in the SFC encapsulation.  Post-SF,
       the traffic is returned to the SFF, and, if needed, is forwarded
       to another SF associated with that SFF.  If there is another non-
       local (i.e., different SFF) hop in the SFP, the SFF further
       encapsulates the traffic in the appropriate network transport
       protocol and delivers it to the network for delivery to the next
       SFF along the path. 

Returned to the initial SFF, or to the next SFF in the RSP?
I guess the next SFF in the chain (again, unless we speak about a proxy)

This would be consistent with section 5.4:
   "Due to the overlay constraints, the packet-forwarding path may
   need to visit the same SFF multiple times, and in some less common
   cases may even need to visit the same SF more than once."

- Section 4.4 and 4.6: what about SFC-enabled domain and SFC proxy.
In figure 3, the SFC proxy is inside the domain, right?
But what about the SFC-unaware Service Function? Inside or outside?

- 
6.  Service function chain independence: The creation, modification,
       or deletion of an SFC has no impact on other SFCs.  The same is
       true for SFPs.

Except if one SF depends on the shared metadata from a previous SF in the
chain, right?

Editorial.

- 
OLD:
   SFC Proxy:  Removes and inserts SFC encapsulation on behalf of an
NEW:
   SFC Proxy:  Removes and inserts SFC Encapsulation on behalf of an

---

From: Alia Atlas <[email-masked]>
Date: Thu, 28 May 2015 10:20:43 -0400

Hi Benoit,

> https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/

If you read further down in the charter, it specifically describes the
architecture
deliverable as:

"2. Architecture: This document will provide a description of the SFC
architectural building blocks and their relationships including
interconnection, placement of SFC specific capabilities, management,
diagnostics, design analysis, and security models, as well as
requirements on the protocol mechanisms. The initial scope is
restricted to a single administrative domain, keeping in mind that
architectural decisions made for the intra-domain case may have
implications for the inter-domain case. "

The architecture isn't specifying what protocols or extensions to use.   I
agree that
the architecture doesn't clearly define the requirements on the protocol(s)
but there
is also another deliverable in the charter:

"4. Control Plane Mechanisms: A document will be developed to describe
requirements for conveying information between control or management
elements and SFC implementation points. All protocol extension work
resulting from these requirements should be carried out in the
working group responsible for the protocol being modified in
coordination with this working group, but may be done in this working
group under a revised charter after agreement with all the relevant
WG chairs and responsible ADs."

and that is where I'd expect to see this work handled.

> of Service Function Chaining

I've certainly seen drafts and discussion about OAM work.  Agreed that it'd
be
useful for that conversation to happen.

Regards,
Alia