Re: [sfc] Figures in draft-quinn-sfc-arch-05

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Fri, 30 May 2014 17:55 UTC

Return-Path: <jheitz@cisco.com>
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD971A09D3 for <sfc@ietfa.amsl.com>; Fri, 30 May 2014 10:55:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level:
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXNGi7JDFVoC for <sfc@ietfa.amsl.com>; Fri, 30 May 2014 10:55:14 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65A21A036A for <sfc@ietf.org>; Fri, 30 May 2014 10:55:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=54450; q=dns/txt; s=iport; t=1401472509; x=1402682109; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=a64SyB+NI+TNDEWRY2HHfcHVF4HP5BjNmdDGRH2Ukrw=; b=ju3ZkG+owrzV+IqWpSLnsBCj5BgzcbCgItokB/tVnkxe8uvD/Zo0PyPD oX5kZGg/SP1pE/tiAhOo7lO/e2t78z05SiOx9oLeCNEnLpQ9iEFq6rSrE ngPx2eKKdh2aPz/8laSTTIcyZiVRvk3t+mw7vhBCali90dO+5ScdfR6Xr o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhcIAEPFiFOtJV2U/2dsb2JhbABZgkJFUlUDvhsBhCABgQkWdIIlAQEBAgInBkwQAgEIEQQBAQsWAQYHMhQJCAIEAQ0FCIg6DdZ8F4kzhDwyMQYBgyuBFQSVepcxgzhsgUM
X-IronPort-AV: E=Sophos;i="4.98,942,1392163200"; d="scan'208,217";a="329257945"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP; 30 May 2014 17:55:01 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s4UHt15D003173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 17:55:01 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.121]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 30 May 2014 12:55:01 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Eric Gray <eric.gray@ericsson.com>, Linda Dunbar <linda.dunbar@huawei.com>, Lucy yong <lucy.yong@huawei.com>, Joel Halpern <joel.halpern@ericsson.com>, "Paul Quinn (paulq)" <paulq@cisco.com>
Thread-Topic: Figures in draft-quinn-sfc-arch-05
Thread-Index: Ac97S9R6mfocA+1iTpKXBfVlibSBggAGJh5AAACjtcAAAHRWQAAFiSTQAAEryZAAAFNDAAAjvoJwAAcI2MA=
Date: Fri, 30 May 2014 17:55:00 +0000
Message-ID: <075DE01702BBC249BE1357EFD20DCFE556F732@xmb-aln-x02.cisco.com>
References: <48E1A67CB9CA044EADFEAB87D814BFF632AD0443@eusaamb107.ericsson.se> <075DE01702BBC249BE1357EFD20DCFE556E2EC@xmb-aln-x02.cisco.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD07D6@eusaamb107.ericsson.se> <2691CE0099834E4A9C5044EEC662BB9D45389B2C@dfweml701-chm.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D290DA@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD0B1B@eusaamb107.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645D29193@dfweml701-chm.china.huawei.com> <48E1A67CB9CA044EADFEAB87D814BFF632AD1504@eusaamb107.ericsson.se>
In-Reply-To: <48E1A67CB9CA044EADFEAB87D814BFF632AD1504@eusaamb107.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [128.107.165.107]
Content-Type: multipart/alternative; boundary="_000_075DE01702BBC249BE1357EFD20DCFE556F732xmbalnx02ciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/3TDcRBTe-h9Dp2Bx0M1ncCYZTe8
Cc: "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 May 2014 17:55:20 -0000

Here is a good example of an RFC with readable diagrams
http://www.rfc-editor.org/rfc/rfc1131.pdf

How did he upload that?

--Jakob

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Eric Gray
Sent: Friday, May 30, 2014 8:03 AM
To: Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
Cc: sfc@ietf.org
Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

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:linda.dunbar@huawei.com]<mailto:[mailto:linda.dunbar@huawei.com]>
Sent: Thursday, May 29, 2014 5:42 PM
To: Eric Gray; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
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:eric.gray@ericsson.com]
Sent: Thursday, May 29, 2014 4:23 PM
To: Linda Dunbar; Lucy yong; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
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:linda.dunbar@huawei.com]
Sent: Thursday, May 29, 2014 4:49 PM
To: Lucy yong; Eric Gray; Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
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:sfc-bounces@ietf.org] 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: sfc@ietf.org<mailto:sfc@ietf.org>
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:sfc-bounces@ietf.org] On Behalf Of Eric Gray
Sent: Thursday, May 29, 2014 12:54 PM
To: Jakob Heitz (jheitz); Joel Halpern; Paul Quinn (paulq)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
Subject: Re: [sfc] Figures in draft-quinn-sfc-arch-05

HaHa, funny man.  :)

From: Jakob Heitz (jheitz) [mailto:jheitz@cisco.com]
Sent: Thursday, May 29, 2014 1:43 PM
To: Eric Gray; Joel Halpern; Paul Quinn (paulq)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
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:sfc-bounces@ietf.org] On Behalf Of Eric Gray
Sent: Thursday, May 29, 2014 8:31 AM
To: Joel Halpern; Paul Quinn (paulq)
Cc: sfc@ietf.org<mailto:sfc@ietf.org>
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?

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