Subject: [sfc] clarification on SFC and Overlay interaction

From: "Elzur, Uri" <[email-masked]>
Date: Mon, 16 Feb 2015 21:32:45 +0000

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 16 Feb 2015 16:35:52 -0500

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
>

---

From: "Elzur, Uri" <[email-masked]>
Date: Mon, 16 Feb 2015 22:36:11 +0000

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
> inner payload for performing these forwarding.", there is no reason to 
> exclude the following private case, I'd assume. This is the case where 
> 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.
>
> 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
>
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 16 Feb 2015 18:23:38 -0500

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

---

From: "Elzur, Uri" <[email-masked]>
Date: Mon, 16 Feb 2015 23:36:57 +0000

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

---

From: Joel Halpern Direct <[email-masked]>
Date: Mon, 16 Feb 2015 18:43:01 -0500

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