Subject: [sfc] Specifying chains of network functions [Re: Figures in draft-quinn-sfc-arch-05]

From: Sevil Mehraghdam <[email-masked]>
Date: Thu, 05 Jun 2014 09:13:14 +0200

Hello,

I am new to this mailing list, and regarding the discussion about 
representing the chained functions, I would like to draw your attention 
to our work:

"Specifying and Placing Chains of Virtual Network Functions" 
(http://arxiv.org/abs/1406.1058)

We have defined a language for specifying the chaining among network 
functions. We use it for describing an optimization problem for 
placement of chained functions in a geographically distributed network 
based on given deployment requests. The paper is currently under review, 
and we are working on extending our model and language as new 
requirements and details about virtual network functions and the chains 
become available. Comments and suggestions are welcome!

Best regards,
Sevil Mehraghdam

On 05/30/2014 05:03 PM, Eric Gray wrote:
>
> Linda,
>
> It may be a mathematically correct expression (depending on interpretation
>
> of the notation used), but networking is not necessarily (possibly 
> even usually) a
>
> mathematical operation.
>
> There is nothing "intuitively obvious" in this expression that makes 
> it clear
>
> that "load sharing" is taking place between the sets of sf2 and sf4 
> instances, or how
>
> the "or" operation takes place.
>
> One literal way to interpret this notation (as a mathematical 
> expression) is
>
> that each the functions sf2, sf2' and sf2" are "visited" sequentially 
> and passed on
>
> to sf3 */as soon as it succeeds in any of the functions/*. With this 
> interpretation, since
>
> the service function performed at each sf2 instance is presumed to be 
> identical,
>
> what the expression means is that either the service function will 
> succeed at sf2
>
> (and always skip sf2' and sf2"), or that it will fail at each sf2 
> instance.
>
> An equally legitimate "parallel computing" (not exactly mathematical, but
>
> possibly viewed as more closely analogous to networking) 
> interpretation would
>
> be that processing passes (on success at sf1) to */each/* of sf2, sf2' 
> and sf2" in parallel
>
> and then proceeds to sf3 on success at any of the sf2 instances.
>
> None of these interpretations corresponds to  "load sharing" -- yet 
> all are
>
> perfectly legitimate interpretation of your suggested expression/notation.
>
> And yet, these are actually more common interpretation of the usage of
>
> an "or" operation to computing folks (which many of us are), depending 
> on their
>
> specific background in computing.
>
> As I said before, I have no objection to the suggested notation you and
>
> Lucy proposed -- provided that the notation is explained.  I am 
> unclear as to what
>
> value this usage -- and included explanation may have -- but this is 
> largely a style
>
> issue, and best left up to the draft editors at this point.
>
> And, as I also said, there may be others who would prefer not to have too
>
> much textual explanation necessary in order to understand a figure.
>
> Finally, you must realize that there are a fairly large number of 
> folks who
>
> read-over mathematical expressions as if they were written in a 
> foreign language.
>
> For this reason, even if it were a perfectly useful/correct 
> mathematical expression,
>
> a number of folks would */still/* need a picture.
>
> --
>
> Eric
>
> *From:*Linda Dunbar [mailto:[email-masked]]
> *Sent:* Thursday, May 29, 2014 5:42 PM
> *To:* Eric Gray; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul 
> Quinn (paulq)
> *Cc:* [email-masked]
> *Subject:* RE: Figures in draft-quinn-sfc-arch-05
> *Importance:* High
>
> Eric,
>
> How about this shorter one?
>
> ->{sf1}->{sf2|sf2'|sf2''}->{sf3}->{sf4|sf4'|sf4''}->{sf5}->
>
> The intent is pretty simple: If a service function on a chain has 
> multiple instances, one of the service function's instances is 
> selected to treat packets belonging to the service chain.
>
> This is a correct mathematics expression.
>
> There is really no need draw all those boxes.
>
> Linda
>
> *From:*Eric Gray [mailto:[email-masked]]
> *Sent:* Thursday, May 29, 2014 4:23 PM
> *To:* Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; 
> Paul Quinn (paulq)
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: Figures in draft-quinn-sfc-arch-05
>
> Linda,
>
> By the way, your proposal for Figure 5 would require a column width of 
> at least 80
>
> characters (more than you are supposed to have in an ID), and the 
> situation would
>
> be worse if it were applied to figure 6.
>
> For figure 5, you can improve the width slightly by fixing up a few of 
> your arrows,
>
> and even more by wrapping the figure.  Wrapping  might detract from 
> simplicity,
>
> however.
>
> --
>
> Eric
>
> *From:*Linda Dunbar [mailto:[email-masked]]
> *Sent:* Thursday, May 29, 2014 4:49 PM
> *To:* Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul 
> Quinn (paulq)
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: Figures in draft-quinn-sfc-arch-05
> *Importance:* High
>
> I like the Figures drawn by Lucy.
>
> Actually why can't Figure 5 be simplified as
>
> enter 
> -->{sf1}-->-{sf2|sf2'|sf2''}->--{sf3}-->-{sf4|sf4'|sf4''}->--{sf5}--> exit
>
> ??
>
> Linda
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Lucy yong
> *Sent:* Thursday, May 29, 2014 1:12 PM
> *To:* Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sfc] Figures in draft-quinn-sfc-arch-05
>
> For readability on these figures, propose:
>
> Figure 5:
>
> +-sf2-+       +-sf4-+
>
> |     |       |     |
>
> enter -->sf1-->-sf2->--sf3-->-sf4->--sf5--> exit
>
> |     |       |     |
>
> +-sf2-+       +-sf4-+
>
> Figure 6:
>
> +-sf2-+              +-sf4-+
>
> |     |              |     |
>
> enter -->{sf1|sf1'}-->-sf2->--{sf3|sf3'}-->-sf4->--{sf5}--> exit
>
> |     |              |     |
>
> +-sf2-+              +-sf4-+
>
> lucy
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Eric Gray
> *Sent:* Thursday, May 29, 2014 12:54 PM
> *To:* Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sfc] Figures in draft-quinn-sfc-arch-05
>
> HaHa, funny man. J
>
> *From:*Jakob Heitz (jheitz) [mailto:[email-masked]]
> *Sent:* Thursday, May 29, 2014 1:43 PM
> *To:* Eric Gray; Joel Halpern; Paul Quinn (paulq)
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: Figures in draft-quinn-sfc-arch-05
> *Importance:* High
>
> You could turn the whole picture right by 90 degrees.
>
> If you don't like top to bottom instead of left to right, make a note 
> that it's in landscape.
>
> --Jakob
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Eric Gray
> *Sent:* Thursday, May 29, 2014 8:31 AM
> *To:* Joel Halpern; Paul Quinn (paulq)
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* [sfc] Figures in draft-quinn-sfc-arch-05
>
> Paul/Joel,
>
>                 Pretty sure that Figures 5 and 6 don't actually fit 
> the width expected for an
>
> Internet Draft (Figure 5 is more than 80 characters wide and Figure 6 
> is wider still).
>
>                 Depending on how a reader tries to read the draft, 
> this can turn complicated
>
> illustrations into a _/real/_ fun time. J
>
>                 Also, I am unsure what the figures are trying to 
> convey with some of "dotted
>
> lines" crossing the service functions.  If the intent is to show that 
> a service function is
>
> a virtual instance hosted by some network device, perhaps this will be 
> better shown
>
> in a separate figure and this aspect of Figures 5 and 6 can be eliminated?
>
> I would suggest replacing Figure 5 with a figure along the lines of:
>
> source             +-----+       +-----+
>
>   |            +-->| sf2 +--+   +-->| sf4 +--+
>
>   |            |   |     |  |            |   | |  |
>
>   |  +------+--+   +-----+  +-->+-----+--+ +-----+  +->+-----+
>
>   |  | sf1  |      +-----+      | sf3 | +-----+     | sf5 |
>
>   +->|      +----->| sf2 +----->| |----->| sf4 +---->|     |-+
>
>      |      |      |     |      |     |      | |     |     | |
>
>      +------+--+   +-----+  +-->+-----+--+ +-----+  +->+-----+ |
>
>                |   +-----+  |            | +-----+  |          |
>
>                +-->| sf2 +--+   +-->| sf4 +--+     +----+
>
>                    |     |                   | |        |
>
>                    +-----+       +-----+        V
>
>                                           destination
>
>                    Figure 5: Load Balancing
>
> (67 characters?)
>
>                 Similarly, I would suggest replacing Figure 6 with a 
> figure along the
>
> lines of:
>
>     source
>       |               +-----+-+                   +-----+-+
>   +---+           +-->| sf2 |-|+              +-->| sf4 |-|+
>   |           +---|-->|     | ||          +------>|     | ||
>   |   +------+|---+   +-----+ |+-->+-----+|---+   +-----+ |+-->+-----+
>   |   | sf1  ||       +-----+ +--->| sf3 ||       +-----+ +--->| sf5 |
>   +-->|      +|------>| sf2 |+---->|     ||------>| sf4 |+---->|     |--+
>   |   |      || +---->|     |-+    |     || +---->|     |-+    |     |  |
>   |   +------+|-|-+   +-----+ |+-->+-----+|-|-+   +-----+ |+-->+-----+  |
>   |           | | |   +-----+ ||          | | |   +-----+ ||            |
>   |   +------++ | +-->| sf2 |-|+   +-----++ | +-->| sf4 |-|+   +-----+  |
>   |   | sf1' |  | +-->|     | +--->| sf3'|  | +-->|     | +--->| sf5'|  |
>   +-->|      +--+ |   +-----+----->|     |--+ |   +-----+----->|     |--+
>       |      |    |                |     |    |                |     |  |
>       +------+----+                +-----+----+                +-----+  |
>                                                                         |
>                                                                +--------+
>                                                                |
>                                                                V
>                                                           destination
>   
>                      Figure 6: Load Balancing and HA
>
> (72 characters?)
>
>                 In both cases, the figure has all the same connection 
> complexity (fixed up in a few
>
> places), but seems to be less busy.
>
> --
>
> Eric
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

-- 
Sevil Mehraghdam
University of Paderborn
Computer Networks group -- http://wwwcs.upb.de/cs/ag-karl
Tel.: +49 5251 / 601755
Room: O3.161

---

From: Dave Dolson <[email-masked]>
Date: Thu, 5 Jun 2014 13:49:03 +0000

Sevil,
I only skimmed your work, so apologies if I've missed the point. I believe you are providing algorithms for converting high-level service requests into concrete service chains, without using any specific implementation.

It seems to me this work is favorably complementary to the IETF's SFC work of determining the protocols of service chaining.
(IETF determines implementation of services chains, and your work decides which chains *should* be created.)

My question to you is, what assumptions do you need to make about the implementation of the chains that the SFC working group needs to consider in forming requirements?

For example, it looks like your algorithm requires some inputs about maximum numbers of functions and chains supported by each VNF.
Therefore we might see a need for a VNF to be able to expose that information in the protocol.

Looked at another way, which of the proposals (e.g., in http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02) work with your approach and which do not?

Something else you could look at, is the orchestration template proposal of http://tools.ietf.org/html/draft-cao-sfc-control-orchestration-00 rigorous enough to be solved?

David Dolson
Senior Software Architect, Sandvine Inc.

From: sfc [mailto:[email-masked]] On Behalf Of Sevil Mehraghdam
Sent: Thursday, June 05, 2014 3:13 AM
To: [email-masked]
Subject: [sfc] Specifying chains of network functions [Re: Figures in draft-quinn-sfc-arch-05]

Hello,

I am new to this mailing list, and regarding the discussion about representing the chained functions, I would like to draw your attention to our work:

"Specifying and Placing Chains of Virtual Network Functions" (http://arxiv.org/abs/1406.1058)

We have defined a language for specifying the chaining among network functions. We use it for describing an optimization problem for placement of chained functions in a geographically distributed network based on given deployment requests. The paper is currently under review, and we are working on extending our model and language as new requirements and details about virtual network functions and the chains become available. Comments and suggestions are welcome!

Best regards,
Sevil Mehraghdam

                It may be a mathematically correct expression (depending on interpretation
of the notation used), but networking is not necessarily (possibly even usually) a
mathematical operation.

                There is nothing "intuitively obvious" in this expression that makes it clear
that "load sharing" is taking place between the sets of sf2 and sf4 instances, or how
the "or" operation takes place.

                One literal way to interpret this notation (as a mathematical expression) is
that each the functions sf2, sf2' and sf2" are "visited" sequentially and passed on
to sf3 as soon as it succeeds in any of the functions.  With this interpretation, since
the service function performed at each sf2 instance is presumed to be identical,
what the expression means is that either the service function will succeed at sf2
(and always skip sf2' and sf2"), or that it will fail at each sf2 instance.

                An equally legitimate "parallel computing" (not exactly mathematical, but
possibly viewed as more closely analogous to networking) interpretation would
be that processing passes (on success at sf1) to each of sf2, sf2' and sf2" in parallel
and then proceeds to sf3 on success at any of the sf2 instances.

                None of these interpretations corresponds to  "load sharing" - yet all are
perfectly legitimate interpretation of your suggested expression/notation.

                And yet, these are actually more common interpretation of the usage of
an "or" operation to computing folks (which many of us are), depending on their
specific background in computing.

                As I said before, I have no objection to the suggested notation you and
Lucy proposed - provided that the notation is explained.  I am unclear as to what
value this usage - and included explanation may have - but this is largely a style
issue, and best left up to the draft editors at this point.

                Finally, you must realize that there are a fairly large number of folks who
read-over mathematical expressions as if they were written in a foreign language.
For this reason, even if it were a perfectly useful/correct mathematical expression,
a number of folks would still need a picture.

--
Eric

From: Linda Dunbar [mailto:[email-masked]]
Sent: Thursday, May 29, 2014 5:42 PM
To: Eric Gray; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Figures in draft-quinn-sfc-arch-05
Importance: High

Eric,

The intent is pretty simple: If a service function on a chain has multiple instances, one of the service function's instances is selected to treat packets belonging to the service chain.

Linda

From: Eric Gray [mailto:[email-masked]]
Sent: Thursday, May 29, 2014 4:23 PM
To: Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Figures in draft-quinn-sfc-arch-05

Linda,

By the way, your proposal for Figure 5 would require a column width of at least 80
characters (more than you are supposed to have in an ID), and the situation would
be worse if it were applied to figure 6.

For figure 5, you can improve the width slightly by fixing up a few of your arrows,
and even more by wrapping the figure.  Wrapping  might detract from simplicity,
however.

--
Eric

From: Linda Dunbar [mailto:[email-masked]]
Sent: Thursday, May 29, 2014 4:49 PM
To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Figures in draft-quinn-sfc-arch-05
Importance: High

    enter -->{sf1}-->-{sf2|sf2'|sf2''}->--{sf3}-->-{sf4|sf4'|sf4''}->--{sf5}--> exit

??

Linda

From: sfc [mailto:[email-masked]] On Behalf Of Lucy yong
Sent: Thursday, May 29, 2014 1:12 PM
To: Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

Figure 5:
                     +-sf2-+       +-sf4-+
                     |     |       |     |

                         +-sf2-+              +-sf4-+
                         |     |              |     |

lucy
From: sfc [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Thursday, May 29, 2014 12:54 PM
To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

HaHa, funny man.  :)

From: Jakob Heitz (jheitz) [mailto:[email-masked]]
Sent: Thursday, May 29, 2014 1:43 PM
To: Eric Gray; Joel Halpern; Paul Quinn (paulq)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Figures in draft-quinn-sfc-arch-05
Importance: High

You could turn the whole picture right by 90 degrees.
If you don't like top to bottom instead of left to right, make a note that it's in landscape.

--Jakob

From: sfc [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Thursday, May 29, 2014 8:31 AM
To: Joel Halpern; Paul Quinn (paulq)
Cc: [email-masked]<mailto:[email-masked]>
Subject: [sfc] Figures in draft-quinn-sfc-arch-05

Paul/Joel,

                Pretty sure that Figures 5 and 6 don't actually fit the width expected for an
Internet Draft (Figure 5 is more than 80 characters wide and Figure 6 is wider still).

                Depending on how a reader tries to read the draft, this can turn complicated
illustrations into a _real_ fun time.  :)

                Also, I am unsure what the figures are trying to convey with some of "dotted
lines" crossing the service functions.  If the intent is to show that a service function is
a virtual instance hosted by some network device, perhaps this will be better shown
in a separate figure and this aspect of Figures 5 and 6 can be eliminated?

source             +-----+                   +-----+

                   Figure 5: Load Balancing

(67 characters?)

                Similarly, I would suggest replacing Figure 6 with a figure along the
lines of:

   source

     |               +-----+-+                   +-----+-+

     |      |    |                |     |    |                |     |  |

                                                                       |

                                                              +--------+

                                                              |

                                                              V

                                                         destination

(72 characters?)

                In both cases, the figure has all the same connection complexity (fixed up in a few
places), but seems to be less busy.

--
Eric

sfc mailing list

[email-masked]<mailto:[email-masked]>

--

Sevil Mehraghdam

University of Paderborn

Computer Networks group - http://wwwcs.upb.de/cs/ag-karl

Tel.: +49 5251 / 601755

Room: O3.161

---

From: Sevil Mehraghdam <[email-masked]>
Date: Fri, 06 Jun 2014 09:48:39 +0200

David,

you are right, currently our model does not make any assumptions about 
the implementation of the chains. What we provide is a context-free 
language for compact representation of different ways a set of functions 
can be chained together and letting the network operator decide about 
the most desirable chaining based on requests for using a set of chained 
functions, and eventually deploying these chains in the network.

We assume the operator maintains some information about the network 
functions that it "offers", e.g., how many licenses it has to implement 
different instances of a certain function, and computational 
requirements of the functions. We also need the chaining/deployment 
request to include some information like the desired order of traversing 
the requested functions.

The documents you pointed to are good examples of what we are trying to 
integrate in our work: how the chains can actually be implemented and 
what assumptions about the available information is realistic and so on. 
We are trying to keep track of the work in SFC working group and keep 
our work in line with the approaches that are likely to be standardized. 
Therefore, in the current state it doesn't make too much sense for me to 
say which approach does or does not work with our model.

Best regards,
Sevil

On 06/05/2014 03:49 PM, Dave Dolson wrote:
>
> Sevil,
>
> I only skimmed your work, so apologies if I've missed the point. I 
> believe you are providing algorithms for converting high-level service 
> requests into concrete service chains, without using any specific 
> implementation.
>
> It seems to me this work is favorably complementary to the IETF's SFC 
> work of determining the protocols of service chaining.
>
> (IETF determines implementation of services chains, and your work 
> decides which chains **should** be created.)
>
> My question to you is, what assumptions do you need to make about the 
> implementation of the chains that the SFC working group needs to 
> consider in forming requirements?
>
> For example, it looks like your algorithm requires some inputs about 
> maximum numbers of functions and chains supported by each VNF.
>
> Looked at another way, which of the proposals (e.g., in 
> http://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-02) 
> work with your approach and which do not?
>
> Something else you could look at, is the orchestration template 
> proposal of 
> http://tools.ietf.org/html/draft-cao-sfc-control-orchestration-00 
> rigorous enough to be solved?
>
> David Dolson
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of *Sevil Mehraghdam
> *Sent:* Thursday, June 05, 2014 3:13 AM
> *To:* [email-masked]
> *Subject:* [sfc] Specifying chains of network functions [Re: Figures 
> in draft-quinn-sfc-arch-05]
>
> Hello,
>
> representing the chained functions, I would like to draw your 
> attention to our work:
>
> based on given deployment requests. The paper is currently under 
> review, and we are working on extending our model and language as new 
> requirements and details about virtual network functions and the 
> chains become available. Comments and suggestions are welcome!
>
> Best regards,
> Sevil Mehraghdam
>
>
>     to sf3 */as soon as it succeeds in any of the functions/*. With
>     this interpretation, since
>
>     be that processing passes (on success at sf1) to */each/* of sf2,
>     sf2' and sf2" in parallel
>
>     None of these interpretations corresponds to  "load sharing" --
>     yet all are
>
>     value this usage -- and included explanation may have -- but this
>     is largely a style
>
>     *To:* Eric Gray; Lucy yong; Jakob Heitz (jheitz); Joel Halpern;
>     Paul Quinn (paulq)
>     *To:* Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern;
>     Paul Quinn (paulq)
>     [email-masked]  <mailto:[email-masked]>
>
> Computer Networks group --http://wwwcs.upb.de/cs/ag-karl
> Tel.: +49 5251 / 601755
> Room: O3.161