Subject: [sfc] comments on sfc-arch-04

From: Lucy yong <[email-masked]>
Date: Sat, 22 Feb 2014 00:03:38 +0000

Hi Paul, et al,

I have some concerns on the service function chaining architecture illustrated in Figure 3.

The numbered circle notation is used in figure 1 where it represents a SF node in a SF graph.
Figure 1 gives very abstract view of SFC without any assumption how it is be realized.

Figure 3 is the reference architecture for service function chaining. It is important for it to illustrate the key functional components and their relationship.  Section 3.2 describes fundamental components in SFC, but they are not shown in the figure 3 at all, and I don't see we can simply replace each numbered circle in figure 3 with the draw in figure 2.

One clarification question for SF, SFF, and SNF in figure 2: what is cardinality in between? Can one SNF have one or more SFFs? can one SFF have one or more SFs? I can't tell from their description and think that is important for the architecture as well.

Do we have one control plane to work with SF, SFF, SNF components or more than one? IMO: it is important to clarify them in the arch doc.

Regards,
Lucy

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 24 Feb 2014 17:38:22 +0000

Hi Lucy,

Thanks for your comments!  Please see inline.

Paul

On Feb 21, 2014, at 7:03 PM, Lucy yong <[email-masked]<mailto:[email-masked]>> wrote:

Hi Paul, et al,

The goal of figure 1 is simply to introduce the concept that what we call a "chain" is really a graph.  It isn't intended to depict any architectural component.

Figure 3 is the reference architecture for service function chaining. It is important for it to illustrate the key functional components and their relationship.  Section 3.2 describes fundamental components in SFC, but they are not shown in the figure 3 at all, and I don’t see we can simply replace each numbered circle in figure 3 with the draw in figure 2.

I will update figure 3 to depict each component in more detail so avoid any confusion between 2 and 3.  Thank you.

One clarification question for SF, SFF, and SNF in figure 2: what is cardinality in between? Can one SNF have one or more SFFs? can one SFF have one or more SFs? I can’t tell from their description and think that is important for the architecture as well.

Yes, in general it is a n:m relationship.  Version -05 of the document will include this required specificity.

We generalize control and policy plane into an abstraction given the possible breadth of control/policy planes that might be in use.   Having said that, we plan to bolster the control and policy plane discussion going forward.  Do you have suggested text or concepts you'd like to convey?

---

From: Lucy yong <[email-masked]>
Date: Mon, 24 Feb 2014 20:30:27 +0000

Please see in-line below.

From: Paul Quinn (paulq) [mailto:[email-masked]]
Sent: Monday, February 24, 2014 11:38 AM
To: Lucy yong
Cc: [email-masked]; [email-masked]
Subject: Re: [sfc] comments on sfc-arch-04

Hi Lucy,

Paul

Hi Paul, et al,

The goal of figure 1 is simply to introduce the concept that what we call a "chain" is really a graph.  It isn't intended to depict any architectural component.
[Lucy] The goal is achieved well in figure 1. But please not use the same numbered circle notation in other architecture draw. It causes confusion easily.

[Lucy] good.

Yes, in general it is a n:m relationship.  Version -05 of the document will include this required specificity.
[Lucy] Do we need that general relationship? Can one SFF work with more than one SNF in a SFC? IMO: We should architect what is reasonable and valuable to do.

We generalize control and policy plane into an abstraction given the possible breadth of control/policy planes that might be in use.   Having said that, we plan to bolster the control and policy plane discussion going forward.  Do you have suggested text or concepts you'd like to convey?
[Lucy] the architecture doc is to facilitate the possible solution development. We have several key components in the architecture and each key element serves different purpose. If SFC WG does not want to work on any control/policy plane related protocol, it is fine to model it as one abstracted piece. If SFC WG also want to work on control plane requirements and protocol between some interfaces in control/policy plane, such abstraction model can't serve the purpose. We need further break it down. Could you clarify what is the goal on the control/policy plane in SFC WG? (this may be question to chair too).

Regards,
Lucy