Eric
You are missing the point.
I was picking an example out of thin air, but it is the type of construct
that we use all the time in fast-reroute.
The example was four routers connected together in a square with some
randomly chosen asymetric costs. Such a network is trivial, but FRR
need to cope with arbitary network fragments with arbitary costs,
so there are lots of fragments that we have created for study the
properties of.
One of the ways to operate on the fragment is to draw it and
then to figure out the packet flows, consequences of failure etc
etc.
Now the question is why should the examples in our drafts be forced
by our ability to describe them, rather than being the example that
most clearly illustrates the problem and its solution?
- Stewart
Gray, Eric wrote:
Stewart,
You realize that the text "example" you gave is meaningless -
without making some (potentially non-obvious) assumptions, right?
--> -----Original Message-----
--> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx]
--> On Behalf Of Stewart Bryant
--> Sent: Monday, January 09, 2006 2:47 PM
--> To: Sam Hartman
--> Cc: Harald Tveit Alvestrand; ietf@xxxxxxxx
--> Subject: Re: Normative figures
-->
--> Sam Hartman wrote:
-->
--> >Hi. With the exception of packet diagrams, I think all
--> the examples
--> >you bring up benefit significantly from clear textual description.
--> >
--> Sam
-->
--> I am not saying that clear text is not needed to accompany
--> a diagram.
--> However a diagram allows a lot less text to be written producing a
--> shorter clearer draft with less clutter.
-->
--> For example you could say the following in text : router A connects to
--> router B and D, the cost from A to B is 2, and the cost from A to D is
4.
A --(2)--> B
|
+---(4)--> D
--> Router B connects to router C. The cost to router A is 6, and
--> the cost to router C is 10.
+ A <--(6)--+
| | |
| +--(2)--> B --(10)--> C
|
+--(4)--> D
(Assumes "cost" is from router B in both cases)
--> Router C connects to router D. The cost to router B is 9
--> and the cost to router D is 8.
+ A <--(6)--+
| | |
| +--(2)--> B <--(9)---+
| | |
| +--(10)--> C
| |
+--(4)--> D <----(8)---+
(Assumes "cost" is from router C in both cases)
--> The cost from router D to router A is 16 and ...
+------+
| |
| +-> A <--(6)--+
| | | |
| | +--(2)--> B <--(9)---+
| | | |
| +--(16)----+ +--(10)--> C
| | |
+------(4)--> D <----(8)----+
-->
--> ... the cost to router A is 99.
?
(Assuming you meant the cost from D to C - not A)
+------+
| |
| +-> A <--(6)--+
| | | |
| | +--(2)--> B <--(9)---+
| | | |
| +--(16)----+ +--(10)--> C <-+
| | | |
+------(4)--> D <----(8)----+ |
| |
+-----(99)--------+
(Figure foo?)
-->
--> In fact you would probably need a table to make sure that
--> you did not make a mistake. In either case it is hard for
--> most people to figure out the what the topology is much
--> less imagine packet actions.
Actually, you need a figure to make sure that you did not
make a mistake, and a second set of eyes to compare what
you said to what you apparently meant.
-->
--> Now compare this to:
-->
--> "The network and costs are as shown in figure foo."
-->
Is the above actually figure foo?
The reality is that it would be better to break it this way:
"In the network in figure foo, the link costs are as follows:
A -> B = 2
B -> A = 6 +-> A <----> B <-+
A -> D = 4 | |
D -> A = 16 +-> D <----> C <-+
B -> C = 10
C -> B = 9 Figure foo
C -> D = 8
D -> C = 99 "
--> Simple text and the visualisation is already done for you
--> so you can focus on the problem.
-->
The reality is that putting things entirely in pictures means
that less validation of the intent of the picture is possible.
Keeping pictures as simple as possible is, therefore, a goal
since it is far easier to make mistakes in complex figures and
far more difficult to determine that a mistake has been made.
Using a mixture of text and figure(s), tables or - possibly -
equations makes it both more understandable and easier to be
certain of conveying the idea(s).
For example, in the above, I could verify that I understand
your intent by asking:
"From this it is apparent that the link cost (D->C) is 99,
but the actual minimum cost of getting from D to C given by
the formula:
(D->A) + (A->B) + (B->C) = 16 + 2 + 10 = 28
Is that correct?"
If we choose to use a simple combination of representations,
rather than strictly expecting a figure to explain it all,
the figure is likely to be far simpler. For example, using
an approach similar to the above, you could probably describe
a much more complex network than 13, or 20 or maybe even 30
nodes using ASCII art. The purpose of the picture is to be
a simplified referent.
-->
--> Now I realise the above could be done in ascii art, but we
--> have problems that need 13 or more nodes to set up.
-->
--> > I believe I'd think that even if I could see the diagrams
--> > and I believe I have enough experience with visualization
--> > (although not sight) to be confident in that belief.
--> >
--> >
--> >
--> >As such, I don't believe these diagrams should be normative.
--> >
--> >
--> >I actually thin that many of the tunnel overlay network documents
--> >(PWE3, L2VPN, L3VPN) could benefit significantly from more focus on
--> >the text of the descriptions of situations being described.
--> >
--> >
--> It is probably a question of how we work and the tools that we
--> find most effective.
-->
--> >If you believe that normative documents are required, I'd
--> like you to
--> >explain why the diagrams cannot be described in the text,
--> why doing so
--> >would decrease the quality of the specification, or why
--> doing so would
--> >not be a useful investment in our time.
--> >
--> >
--> >
--> >
--> One reason is that it takes a lot of text to describe what
--> can be drawn
--> with a few lines and symbols. Many people will get lost in
--> the text and
--> in any case would have to transcribe the text into a diagram for
--> themselves before they could understand what is happening.
-->
--> - Stewart
-->
-->
-->
-->
-->
--> _______________________________________________
--> Ietf mailing list
--> Ietf@xxxxxxxx
--> https://www1.ietf.org/mailman/listinfo/ietf
-->
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf