Subject: [sfc] Benoit Claise's No Objection on draft-ietf-sfc-architecture-08: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 28 May 2015 07:44:54 -0700

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

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/

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

THIS TEXT BELOW IS DOCUMENTED FOR THE RECORD  (AND THIS DISCUSS-DISCUSS
HAS BEEN DISCUSSED)

- 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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 28 May 2015 15:11:30 +0000

Thanks, Benoit. I believe we’ve addressed all these comments in our working version, which we will submit when Alia says “Go!”

Thanks,

— Carlos.

> On May 28, 2015, at 10:44 AM, Benoit Claise (bclaise) <[email-masked]> wrote:
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 28 May 2015 18:05:17 +0000

Hi Benoit,

Many thanks again for your review — let me also reply to your COMMENTs point-by-point below, to make sure we are on the same page.

> On May 28, 2015, at 11:11 AM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
> 
>>  the underlying forwarding topology.”
>> 

I agree, “independent” is the right word here — as it is also used elsewhere in the document. I like your suggestion immediately above, thanks for catching.

>> it is, but only explain why you need it.

The definition of SFP took quite significant crafting and wording, and WG cycles. It is correct, yet a bit complex.

You can see some of the background at:
https://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf#page=8 <https://tools.ietf.org/agenda/90/slides/slides-90-sfc-3.pdf#page=8>
https://tools.ietf.org/agenda/91/slides/slides-91-sfc-2.pdf#page=3 <https://tools.ietf.org/agenda/91/slides/slides-91-sfc-2.pdf#page=3>

>> the ordered list of SFFs?

The SFC is an ordered set of abstract functions — e.g., “a firewall”. An SFP applies (policy, service function, etc) constrains as e.g., “this firewall”, or “this firewall via this SFF …”; as detailed in Section 2.3, SFPs do not have a requirement of full specificity. SFPs can have varying degrees of specificity (from fully specified SFFs and SFs to reach that SF and there’s degree of freedom over which SFFs to use). Lastly, an RSP is the fully specified set of SFFs and SFs actually visited. In other words, from less specified to fully specified: SFC -> SFP -> RSP.

>> Am I correct that it only applies in case of a SFC proxy?

Please note also that SFFs and SFs are architectural functional blocks, and an IPS might include both functions.

>> I guess the next SFF in the chain (again, unless we speak about a proxy)

Not about proxy. Traffic returns from the SF to the SFF that sent it to that SF. From that SFF, it can go to another SF or to another SFF -> SF.

To exemplify (what I believe might be the confusion), if a classifier sends traffic to a firewall, traffic does not return to the classifier. After the firewall SF is applied, it returns to the functional SFF.

>> But what about the SFC-unaware Service Function? Inside or outside?

Good point again. Added this sentence at the end of S4.4:

“An SFC Proxy and corresponding SFC-unaware Service Function (see
Figure 3) are inside the SFC-enabled domain."

>> Except if one SF depends on the shared metadata from a previous SF in the

No. If one SF depends on shared metadata from a previous SF, that would be within a chain. The statement above is about SFC independence, not SF independence. Removing a chain would not affect another chain (which includes the two SFs from your example).

>>  SFC Proxy:  Removes and inserts SFC Encapsulation on behalf of an

Done.

Thanks again, please let us know if there are comments that need further clarification or fixes.

Thanks,

— Carlos.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 29 May 2015 16:20:10 +0200

Thanks Carlos for the detailed answer.
I remove all points we agree with.
See in line.
> Hi Benoit,
>
> Many thanks again for your review — let me also reply to your COMMENTs 
> point-by-point below, to make sure we are on the same page.
>
>
>>>
>>>
> The definition of SFP took quite significant crafting and wording, and 
> WG cycles. It is correct, yet a bit complex.
I didn't assert the definition was not correct. I wrote "I'm confused", 
because, even after reading it multiple times, I can't make the link 
between the different concepts: SFP, SFC, RSP.
> The SFC is an ordered set of abstract functions — e.g., “a firewall”. 
> An SFP applies (policy, service function, etc) constrains as e.g., 
> “this firewall”, or “this firewall via this SFF …”; as detailed in 
> Section 2.3, SFPs do not have a requirement of full specificity. SFPs 
> can have varying degrees of specificity (from fully specified SFFs and 
> SFs to reach that SF and there’s degree of freedom over which SFFs to 
> use). Lastly, an RSP is the fully specified set of SFFs and SFs 
> actually visited. In other words, from less specified to fully 
> specified: SFC -> SFP -> RSP.
Ah, now that makes sense (at least to me)
With that in mind, I reviewed the definitions and section 2.3, and here 
are my conclusions.

1. I found the Service Function Path definition in the RSP definition:

	"The Service Function Path is a
         constrained specification of where packets assigned to a certain
         service function path must go.  While it may be so constrained
         as to identify the exact locations, it can also be less
         specific.

These sentences should be the first sentences of the Service Function 
Path definition.

2. This example below must be mentioned in the draft

    The SFC is an ordered set of abstract functions — e.g., “a
    firewall”. An SFP applies (policy, service function, etc) constrains
    as e.g., “this firewall”, or “this firewall via this SFF …”; as
    detailed in Section 2.3, SFPs do not have a requirement of full
    specificity. SFPs can have varying degrees of specificity (from
    fully specified SFFs and SFs to reach that SF and there’s degree of
    freedom over which SFFs to use). Lastly, an RSP is the fully
    specified set of SFFs and SFs actually visited. In other words, from
    less specified to fully specified: SFC -> SFP -> RSP.

Potentially in Section 2.3. If yes, section 2.3 should be called 
"Service Function Paths and RSP"
Alternatively in a section 2.4

> Please note also that SFFs and SFs are architectural functional 
> blocks, and an IPS might include both functions.
I completely missed that from the draft. Where is it explained or how 
have you improved the draft?
I had in mind this use case : SFF = switch, SF = attached appliance.
> Not about proxy. Traffic returns from the SF to the SFF that sent it 
> to that SF. From that SFF, it can go to another SF or to another SFF 
> -> SF.
>
> To exemplify (what I believe might be the confusion), if a classifier 
> sends traffic to a firewall, traffic does not return to the 
> classifier. After the firewall SF is applied, it returns to the 
> functional SFF.
Understood now. I'll look at the diff. If you have them now, please forward.
Thanks and regards, Benoit

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 29 May 2015 17:24:42 +0000

Hi, Benoit,

Thanks for the follow-up and trimming down the set of comments. Please see inline.

> On May 29, 2015, at 10:20 AM, Benoit Claise (bclaise) <[email-masked]> wrote:
> 
> I didn't assert the definition was not correct. I wrote "I'm confused", because, even after reading it multiple times, I can't make the link between the different concepts: SFP, SFC, RSP.

Understood. I did not asset you asserted it was not correct :-) I was merely acknowledging that it was not an easy read, but stating that it was correct despite it being complex.

Regarding the link between SFC, SFP, and RSP, please see below.

> With that in mind, I reviewed the definitions and section 2.3, and here are my conclusions.
> 
> These sentences should be the first sentences of the Service Function Path definition.
> 

Sure — moved text around a bit.

> Potentially in Section 2.3. If yes, section 2.3 should be called "Service Function Paths and RSP"

Ack — instead, we are adding a Section 2.3.1 (since it is separate, but within context of S2.3).

Joel and I crafter some text, here’s the proposal (and see attached diffs).

<?xml version="1.0"?>
<section
title="Service Function Chains, Service Function Paths, and Rendered Service Path"
><t
>As an example of this progressive refinement, consider a service function chain (SFC) which states that packets using this chain should be delivered to a firewall and a caching engine.</t
><t
>A Service Function Path (SFP) could refine this, considering that this architecture does not mandate the degree of specificity an SFP has to have. It might specify that the firewall and caching engine are both to be in a specific Data Center (e.g., in DC1), or it might specify exactly which instance of each firewall and chaching engine is to be used.</t
><t
>The Rendered Service Path (RSP) is the actual sequence of SFFs and SFs that the packets will actually visit. So if the SFP picked the DC, the RSP would be more specific.</t
></section
>

> I completely missed that from the draft. Where is it explained or how have you improved the draft?

OK, clarifying text at the beginning of Section 4 — please see attached diffs FYI.

> Understood now. I'll look at the diff. If you have them now, please forward.

Sure — see attached, noting that these include all the edits thus far since -08, a super-set of the ones from your comments.

If you still believe there are issues unadressed, please provide a specific textual proposal to understand what might be missing.

Thanks,

— Carlos.

---

From: Benoit Claise <[email-masked]>
Date: Sun, 31 May 2015 15:15:56 +0200

Thanks Carlos for taking care of my comments.
The draft is now improved IMO. At least for someone like me who doesn't 
have all the SFC background

Regards, Benoit

>> On May 29, 2015, at 10:20 AM, Benoit Claise (bclaise) 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>> Many thanks again for your review — let me also reply to your 
>>> COMMENTs point-by-point below, to make sure we are on the same page.
>>>
>>>
>>>>>
>>>>>
>>> The definition of SFP took quite significant crafting and wording, 
>>> and WG cycles. It is correct, yet a bit complex.
>> I didn't assert the definition was not correct. I wrote "I'm 
>> confused", because, even after reading it multiple times, I can't 
>> make the link between the different concepts: SFP, SFC, RSP.
>
> Understood. I did not asset you asserted it was not correct :-) I was 
> merely acknowledging that it was not an easy read, but stating that it 
> was correct despite it being complex.
>
>>     firewall”. An SFP applies (policy, service function, etc)
>>     constrains as e.g., “this firewall”, or “this firewall via this
>>     SFF …”; as detailed in Section 2.3, SFPs do not have a
>>     requirement of full specificity. SFPs can have varying degrees of
>>     specificity (from fully specified SFFs and SFs to reach that SF
>>     and there’s degree of freedom over which SFFs to use). Lastly, an
>>     RSP is the fully specified set of SFFs and SFs actually visited.
>>     In other words, from less specified to fully specified: SFC ->
>>     SFP -> RSP.
>>
> >As an example of this progressive refinement, consider a service 
> function chain (SFC) which states that packets using this chain should 
> be delivered to a firewall and a caching engine.</t
> ><t
> >A Service Function Path (SFP) could refine this, considering that 
> this architecture does not mandate the degree of specificity an SFP 
> has to have. It might specify that the firewall and caching engine are 
> both to be in a specific Data Center (e.g., in DC1), or it might 
> specify exactly which instance of each firewall and chaching engine is 
> to be used.</t
> ><t
> >The Rendered Service Path (RSP) is the actual sequence of SFFs and 
> SFs that the packets will actually visit. So if the SFP picked the DC, 
> the RSP would be more specific.</t
> ></section
> >
>
>
>>
>>>
>>>
>>>>>
>>>>> -
>>> To exemplify (what I believe might be the confusion), if a 
>>> classifier sends traffic to a firewall, traffic does not return to 
>>> the classifier. After the firewall SF is applied, it returns to the 
>>> functional SFF.
> Sure — see attached, noting that these include all the edits thus far 
> since -08, a super-set of the ones from your comments.
>
> If you still believe there are issues unadressed, please provide a 
> specific textual proposal to understand what might be missing.
>
> Thanks,
>
> — Carlos.
>
>
>
>
>
>>>
>>>