Subject: RE: [arch-d] Defining terms

From: "Bound, Jim" <[email-masked]>
Date: Thu, 23 Mar 2006 14:52:15 -0500

Valid point but I took the BGP more as abstraction to define a layer
called routing for discussion. IP model don't call out a routing layer.
Forwarding is different than extraplation of routes and discovery
clearly.

More important to your mail yes we need to find consensus but only rough
consensus to keep moving once that is achieved.  But then we get to the
running code part :--)

/jim 

> -----Original Message-----
> From: John Leslie [mailto:[email-masked]] 
> Sent: Thursday, March 23, 2006 12:45 PM
> To: Bound, Jim
> Cc: [email-masked]; Noel Chiappa; John Day
> Subject: Re: [arch-d] Defining terms
> 
> Bound, Jim <[email-masked]> wrote:
> > To: "John Day" <[email-masked]>,
> > 
> > John, all opinions are important and there is no gospel for 
> layers or
> > architecture. I hear you but several of us who have lived this too
> > simply don't agree.
> 
>    We need to put _some_ effort into seeking consensus...
> 
> > Noel is spot on.
> 
>    Umm... Noel really _isn't_ spot-on in his BGP example...
> 
> >> At 21:15 -0500 2006/03/21, Noel Chiappa wrote:
> >> 
> >>> As one example, look at BGP. It's used for passing around
> >>> routing info - so it's part of the inter-network layer, right?
> 
>    That really doesn't follow.
> 
>    BGP is a "routing" protocol, in the Routing Area sense.
> 
>    To Routing Area folks, "routing" is generating path information and
> passing _some_ of that path information toward forwarding engines.
> 
>    I don't mean to insult folks familiar with Routing Area 
> terminology,
> but I expect some folks on this list aren't familiar with it.
> 
>    Recall, John Day sees three pieces called "routing":
> ] 
> ] Actually, I would say routing is 3 distinct tasks:
> ]   exchanging information about connectivity and other information,
> ]   calculating connectivity based on what you have collected,
> ]   and then choosing a next hop/path based on the calculation and
> ]     the other info.
> 
> and I don't think he even referred to the function I mentioned which
> many folks call "routing" but Routing Area folks call "forwarding":
> ] 
> ]> passing packets to another router "closer" to the destination.
> 
>    (It doesn't help that even Routing Area folks use the term "router"
> to refer to a box which does "forwarding".)
> 
>    Of all of these, only the last, "forwarding", one in any sense
> deserves to be called "part of the inter-network layer". The others
> may or may not deserve to be called "necessary to" the inter-
> network area, but that would not make them "part of" it.
> 
>    Noel certainly knows that BGP is not "forwarding", even if every
> box he may have seen it implemented in also does forwarding ( I
> venture no guess as to whether that condition is true).
> 
>    What functions go in a box is engineering, not architecture.
> What functions are implemented in a box _cannot_ determine their
> architectural purpose.
> 
> >>> Yes, but, it uses TCP. So it's above the transport layer, right?
> 
>    This statement at least makes sense. The BGP routing function
> can be considered "above" the transport layer.
> 
>    But we have no need to enter that argument. From an architectural
> standpoint, we should see "exchanging information about connectivity"
> as a network function which is out-of-band to the inter-network layer,
> and the rest of "routing" (in the Routing Area usage) as not network
> functions at all.
> 
> >>> "Does not compute! Does not compute!"
> 
>    Repeating a statement doesn't make it true. John Day is right:
> 
> >> No.  There is no rule that says a protocol and the layer 
> it is used 
> >> in are fixed.  Protocols are means to providing certain kinds of 
> >> coordination.  I can use any protocol in any layer where 
> it does what 
> >> I need done.  Sure it computes.
> 
>    John Day and I are perhaps thinking from an academic standpoint.
> Noel may be thinking from an engineering standpoint (or not, YMMV).
> But all of us should be _trying_ to think from an architectural
> standpoint.
> 
> --
> John Leslie <[email-masked]>
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/architecture-discuss
> 

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Scott W Brim <[email-masked]>
Date: Thu, 23 Mar 2006 14:17:04 -0600

> Forwarding is different than extraplation of routes and discovery

Planes are your friend.

---

From: John Day <[email-masked]>
Date: Fri, 24 Mar 2006 10:22:38 -0500

>>  Forwarding is different than extraplation of routes and discovery

;-)  Good one.

You know, I have to admit that planes make me uncomfortable.  Perhaps 
it is just a knee-jerk reaction because they come from the telephony 
"beads-on-a-string" model of the world.  They do describe where this 
stuff sits in one sense.  But I have to admit adopting 
"beads-on-a-string" concepts makes me nervous, given the models that 
have come out of that tradition.  Perhaps it is just too many years 
in the debate over connection and connectionless.  It does have more 
the feel of natural history than science.  (Robert MacArther, a 
biologist, contrasted natural history as describing what is there, 
whereas science makes predictions.)  I get the feeling that planes 
have the same property.

Some of us who were involved in the old ARPANet always felt that part 
of the reason it was so successful was because it was done by OS guys 
not telecom guys.  And I have to admit, I have had more success 
working through problems by going back to OS ideas and metaphors than 
anything else.

Is it more than just different ways to draw the same picture? 
Probably not.  But the OS model tends to make predictions that I 
don't find with planes or "beads-on-a-string."  Perhaps we should 
give that some consideration.  It certainly has served us well over 
the years.

Take care,
John

A postscript on CO/CL.  I do believe that both are necessary.  My own 
characterization is that connectionless is preferred when traffic 
density is low and more stochastic.  Connections when traffic density 
is high and more deterministic.  This would seem to imply that 
traffic is more connectionless toward the edge and more connection 
like toward the backbone.  (This is assuming all other things being 
equal, i.e. error and flow control are not a concern.  When would you 
choose co vs cl purely for its own properties.  And of course, this 
is not an iron-clad rule just a general characterization.)

---

From: John Day <[email-masked]>
Date: Fri, 24 Mar 2006 10:22:38 -0500

;-)  Good one.

Take care,
John

---

From: John Day <[email-masked]>
Date: Thu, 23 Mar 2006 15:07:41 -0500

>Forwarding is different than extraplation of routes and discovery

But we are trying to *find* the right model.  We can't let the fact 
that the IP model doesn't call out a routing layer affect our view. 
The IP model may be wrong, or not quite right.  It was assuming that 
it was right that got us where we are. We have to find what is really 
going on. Once we understand that, then we can worry about how to 
engineer it.

As you tell kids when they are doing their math homework:  Don't skip 
steps. It will only get you in trouble. ;-) (Always hated it when my 
father told me that.)

>consensus to keep moving once that is achieved.  But then we get to the

Ahh, yes science by popularity.  Wonder how often that has been the case.

rough consensus applies to electro-political engineering.  I didn't 
realize that was the domain of this discussion.  I thought this was a 
more scientific inquiry. Science must follow the data regardless of 
how unpopular it may be.

Take care,
John

---

From: John Leslie <[email-masked]>
Date: Fri, 24 Mar 2006 19:23:43 -0500

> At 14:17 -0600 2006/03/23, Scott W Brim wrote:

   Could one of the folks who is saying layers are the wrong approach
please try describing internetworking architecture in terms of planes?

   (I've been trying this exercise myself, and I'm afraid I'm failing
kinda spectacularly...)