Subject: Re: [sfc] clarification on SFC and Overlay interaction

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 9 Jul 2015 17:27:51 +0000

Hi, Uri, (WG,)

I was re-reading these set of comments from you, and realized that we could add some more clarity as you mentioned.

What do you think of these set of proposed diffs?

—>8—
@@ -511,38 +511,43 @@
    7.  Heterogeneous control/policy points: The architecture allows SFs
        to use independent mechanisms (out of scope for this document) to
        populate and resolve local policy and (if needed) local
        classification criteria.

 4.  Core SFC Architecture Components

    The SFC Architecture is built out of architectural building blocks
    which are logical components; these logical components are
    classifiers, service function forwarders (SFF), the service functions
-   themselves (SF), and SFC-proxies.  They are interconnected using the
-   SFC Encapsulation.  This results in a high level logical architecture
-   of an SFC-enabled Domain which comprises:
+   themselves (SF), and SFC-proxies.  While this architecture describes
+   functionally distinct logical components and promotes transport
+   indepencence, they could be realized and combined in various ways in
+   deployed products, and could be combined with an overlay.
+
+   They are interconnected using the SFC Encapsulation.  This results in
+   a high level logical architecture of an SFC-enabled Domain which
+   comprises:

       o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
       .  +--------------+                  +------------------~~~
       .  |   Service    |       SFC        |  Service  +---+   +---+
       .  |Classification|  Encapsulation   | Function  |sf1|...|sfn|
    +---->|   Function   |+---------------->|   Path    +---+   +---+
       .  +--------------+                  +------------------~~~
       . SFC-enabled Domain
       o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

                Figure 2: Service Function Chain Architecture

    The following sub-sections provide details on each logical component
    that form the basis of the SFC architecture.  A detailed overview of
-   how each of these architectural components interact is provided in
+   how some of these architectural components interact is provided in
    Figure 3:

          +----------------+                        +----------------+
          |   SFC-aware    |                        |  SFC-unaware   |
          |Service Function|                        |Service Function|
          +-------+--------+                        +-------+--------+
                  |                                         |
            SFC Encapsulation                       No SFC Encapsulation
                  |                  SFC                    |
     +---------+  +----------------+ Encapsulation     +---------+
@@ -561,21 +566,26 @@
                           Network Overlay Transport
                                       |
                                   _,....._
                                ,-'        `-.
                               /              `.
                              |     Network    |
                              `.              /
                                `.__     __,-'
                                    `''''

-         Figure 3: Service Function Chain Architecture Components
+     Figure 3: SFC Architecture Components Post Initial Classification
+
+   Please note that the depiction in Figure 3 shows packets post initial
+   classification, and therefore including the SFC encapsulation.
+   Although not included in Figure 3, the classifier is an SFC
+   architectural component.

 4.1.  SFC Encapsulation
 —>8—

Thanks!

— Carlos.

> On Jun 30, 2015, at 11:32 AM, Elzur, Uri <[email-masked]> wrote:
> 
> Hi Carlos
> 
> Pls see below [UE]
> 
> Thx
> 
> Uri (“Oo-Ree”)
> C: 949-378-7568
> 
> -----Original Message-----
> From: Carlos Pignataro (cpignata) [mailto:[email-masked] <mailto:[email-masked]>]
> Sent: Tuesday, June 30, 2015 7:56 AM
> To: Elzur, Uri
> Cc: Joel Halpern Direct; [email-masked] <mailto:[email-masked]>
> Subject: Re: [sfc] clarification on SFC and Overlay interaction
> 
> Hi, Uri,
> 
> Thanks for the comments, please see inline.
> 
>> On Jun 30, 2015, at 2:08 AM, Elzur, Uri <[email-masked]> wrote:
>> 
>> Hi Carlos
>> 
>> Thanks for following up. Few comments
>> 
>> 1) There is an impression (by some) that SFC REQUIRES an independent
>> layer EVEN if one has an overlay deployed. Without pointing out ANY
>> technology, a sentence like “While this architecture describes
>> functionally distinct logical components and promotes transport
>> independence, the service chaining layer can be combined in various
>> ways with an overlay” can explain that point. BTW: In the NSH draft,
>> we do make the assumption that there is an Overlay on top of which SFC
>> (NSH) is deployed. This Overlay can be dedicated to NSH  or shared
>> with an overlay for network virtualization…
>> 
> 
> If I read this correctly, you are proposing to add “promotes transport independence”. I think that the document already covers this point in detail. Also, it is not the service layer that is combined, but rather the components, so part of this re-write could be a bit confusing.
> 
> I am happy to try to rewrite and sharpen this sentence, but I really think that nothing you say is precluded.
> [UE] the point is about building SFC into an existing NetVirt Overlay. To sharpen that point, I'm adding albeit that SFC promotes/assumes/mandates Transport independence, merging SFC into an exisiting overlay is possible. I think it takes clear statement for folks to see as it comes across to me and others as if this is not possible
> 
>> 2) Classifier vs SFF – have looked into rev 9 of the arch draft, assume the Classifier is the entity that inserts the NSH header i.e. encapsulates (see figure 2), we may want to update the architectural diagram (fig 3) to clearly show the Service Classifier as part of the architecture.
> 
> Figure 2 already shows the classifier as part of the architecture. I am not sure how to update Figure 3 without making it unreadable. Remember fig 3 is not showing and end-to-end view of the SFP.
> [UE] without a classifier Fig 3 is incomplete IMHO, it is the Classifier that is located at the boundary of the non encapsulated and SFC-encapsulated world. And this is also why I was proposing to update the definition. The suggestion is to make it clear it is not theSFF that is encapsulating the first SFC packet
> 
>> Also may want to update the Classifier definition to that end (like in
>> the above, a classifier can be integrated into the SFF, then we may
>> want to mention that. In any case, the SFF performs the NSH
>> decapsulation)
> 
> I am hesitant to add a very specific example to the general sentence above. Otherwise, we might end up implying that other combinations are not possible. Since the role of classification and use of the SFC encapsulation is covered in detail in full sections of the doc, I’d recommend we do not try to summarize here.
> [UE] not suggesting to limit the generality of the architecture and for me there is no need to include the example of a classifier integrated into SFF. On the contrary I much prefer to see the above clarification of the Classifier independent role
> 
> We welcome other comments on this of course,
> 
> Thanks,
> 
> — Carlos.
> 
>> 
>> Thx
>> 
>> Uri (“Oo-Ree”)
>> C: 949-378-7568
>> 
>> -----Original Message-----
>> From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
>> Sent: Monday, June 29, 2015 12:51 PM
>> To: Elzur, Uri
>> Cc: Joel Halpern Direct; [email-masked]
>> Subject: Re: [sfc] clarification on SFC and Overlay interaction
>> 
>> Hi, Uri,
>> 
>> I added the following text at the beginning of Section 4: “While this architecture describes functionally distinct logical components, they could combined in various ways in deployed products.”
>> 
>> I think this covers all potential cases, instead of singling out one example.
>> 
>> The Section now starts like this:
>> 
>> --->8---
>>  The SFC Architecture is built out of architectural building blocks
>>  which are logical components; these logical components are
>>  classifiers, service function forwarders (SFF), the service functions
>>  themselves (SF), and SFC-proxies.  While this architecture describes
>>  functionally distinct logical components, they could combined in
>>  various ways in deployed products.
>> 
>>  They are interconnected using the SFC Encapsulation.  This results in
>>  a high level logical architecture of an SFC-enabled Domain which
>>  comprises:
>> --->8---
>> 
>> Does this help?
>> 
>> Thanks,
>> 
>> — Carlos.
>> 
>>> On Jun 22, 2015, at 10:20 AM, Elzur, Uri <[email-masked]> wrote:
>>> 
>>> Hi Joel
>>> 
>>> I've recently reviewed the latest draft v 09. I still miss such a clarification. Pls point me in the right direction if it does exist somewhere in chapter 4.
>>> 
>>> I'd like to suggest we add language referring to the specific example
>>> outlined below of SFF integrated with an overlay manager as a way to
>>> show how the logical elements can be implemented as part of an
>>> overlay and to clarify we are not talking ONLY about  a completely
>>> independent new Service overlay
>>> 
>>> Thx
>>> 
>>> Uri ("Oo-Ree")
>>> C: 949-378-7568
>>> 
>>> -----Original Message-----
>>> From: Joel Halpern Direct [mailto:[email-masked]]
>>> Sent: Monday, February 16, 2015 3:43 PM
>>> To: Elzur, Uri; [email-masked]
>>> Subject: Re: [sfc] clarification on SFC and Overlay interaction
>>> 
>>> It seems like we can (and unless I am very confused, should) add such a statement in the base portion of section 4.  Carlos and I will work on this.  Thank you for calling our attention to the omission.
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 2/16/15 6:36 PM, Elzur, Uri wrote:
>>>> Agree. I do not recall however any such statement. I do recall many
>>>> statement like section 4.5, indicating the separation and referring
>>>> to topological and transport independence. Pls point me to the
>>>> paragraph or we may want to add such clarification in the next rev
>>>> 
>>>> Thx
>>>> 
>>>> Uri ("Oo-Ree")
>>>> C: 949-378-7568
>>>> 
>>>> -----Original Message-----
>>>> From: Joel M. Halpern [mailto:[email-masked]]
>>>> Sent: Monday, February 16, 2015 3:24 PM
>>>> To: Elzur, Uri; [email-masked]
>>>> Subject: Re: [sfc] clarification on SFC and Overlay interaction
>>>> 
>>>> If we do not have text in there that says that these logical components may be combined in real world implementations or deployments with each other or with components from outside the architecture, I could see adding that.  I thought we already said it.
>>>> 
>>>> I would prefer not to add comments on any specific deployments, because there are so many ways to do so, and as far as I can tell, most of us think the one in our head is the most likely / common / useful.
>>>> 
>>>> Yours,
>>>> Joel
>>>> 
>>>> On 2/16/15 5:36 PM, Elzur, Uri wrote:
>>>>> Joel
>>>>> 
>>>>> Sounds good to me. However a clarification, maybe in the format of
>>>>> a comment or example (as I suspect this may be a very common case,
>>>>> for
>>>>> some) in the draft will be of value
>>>>> 
>>>>> Thx
>>>>> 
>>>>> Uri ("Oo-Ree")
>>>>> C: 949-378-7568
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Joel M. Halpern [mailto:[email-masked]]
>>>>> Sent: Monday, February 16, 2015 1:36 PM
>>>>> To: Elzur, Uri; [email-masked]
>>>>> Subject: Re: [sfc] clarification on SFC and Overlay interaction
>>>>> 
>>>>> One of the key reasons for identifying the logical components is that there are a broad range of ways that they can be composed.  That does sound like one possible composition.
>>>>> 
>>>>> Yours,
>>>>> Joel
>>>>> 
>>>>> On 2/16/15 4:32 PM, Elzur, Uri wrote:
>>>>>> While section 4.5 of draft-ietf-sfc-architecture-04, states
>>>>>> "underneath the SFF there are components responsible for
>>>>>> performing the transport
>>>>>> (overlay) forwarding. They do not consults the SFC encapsulation
>>>>>> or inner payload for performing these forwarding.", there is no
>>>>>> reason to exclude the following private case, I'd assume. This is
>>>>>> the case where the SFF is effectively integrated with the Overlay
>>>>>> manager, or instantiated in other overlay network elements (e.g.
>>>>>> vSwitch), enabling in essence SFC within an Overlay network, with
>>>>>> no need for a separate SFC domain.
>>>>>> 
>>>>>> To be clear (or clearer), this is not to suggest that transport or
>>>>>> topological independence can be or should be bend, but simply to
>>>>>> suggest a deployment scenario that may be popular for limited
>>>>>> scale SFC
>>>>>> 
>>>>>> Thx
>>>>>> 
>>>>>> Uri ("Oo-Ree")
>>>>>> 
>>>>>> C: 949-378-7568
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> sfc mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/sfc
>>>>>> 
>>>>> 
>>> 
>>> _______________________________________________
>>> sfc mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sfc