Subject: RE: Guiding Principles

From: [email-masked]
Date: Wed, 3 Apr 2002 12:00:21 +0100

Lloyd Wood wrote 30 March 2002 14:26:

> On Sat, 30 Mar 2002 [email-masked] wrote:
> 
> > Dale...I absolutely agree with your observations.  There is 
> a further
> > observation on the whole of this space which complicates things even
> > further, viz:
> >
> > There are no network rules for XoverY.....both in terms of 
> (i) what_X is
> > allowed over what_Y or (ii) how many times it can be 
> allowed.  If you start
> > to think about this then:
> > -	any client/server relationship seems allowed (even when 
> some make
> > little arch sense)
> > -	if the client/server relationships and number of 
> instances of such
> > mappings are unbounded then (i) there is no assurance that end-end
> > performance objectives can be met and (ii) there is no network
> > design/apportionment principles that can be devised for 
> when network domains
> > are connected together in tandem, ie what is the fair/right 
> allocation to
> > domain D say?
> 
> Those are deliberate design features of the internet.
NH=> Not sure I'd agree with the word 'deliberate'....and I assume you mean
Internet (big I)?  Deliberate to me implies a conscious decision based on a
good understanding of the consequences/risks of a given course of action.  I
don't believe the carriage of co cct-sw and co pkt-sw technologies was
considered at the outset of the Internet.  The only conscious decision I am
aware of is that the network transfer mode of the Internet should be
cnls.....and for the initial design goals of the Internet this was, and
still is, the right choice.  However, you can't do everything most
efficiently in a cnls mode....you need to marry the best of cnls and co, and
we will be so much richer if we can.  

> Learn to deal with it.
NH=> Taken literally this can only mean 'ignore it because one can't deal
with it', ie its not possible to address the problem because the problem is
no longer tractable.  Speaking as an operator, we have various
networks/services to provide that require certain behaviours.....be these
demanded by my operations people, my management (eg demanding to see network
efficiency/utilisation stats) or the expectations of my customers.  So, in a
time when many of those who are ignoring fundamental networking behaviour
requirements are filing for chapter 11, I'm afraid I simply can't afford to
take such an 'ignore it' stance as you advocate.
> 
> PWE3's biggest problem is that everyone want to cast their
> pre-existing design paradigms onto packet-switched networks, throwing
> away all the benefits and characteristics of the packet-switched
> network in order to specify and enforce rigid and inflexible
> requirements to get a poor approximation of the pre-existing design
> paradigm instead.
NH=> I don't think so....the biggest problem (if you will excuse a UK
proverb) is that 'we can't make a silk-purse out of a sow's ear'.  If one is
being strictly honest with oneself, when we look at what MPLS is providing
it is adding a co pkt-sw behaviour to a cnls network....and I know some try
and pretend this is not the case, but being in denial will not change this
fact.  However, I see this as good news, since it brings the potential to
provide enhanced functionality (NB this co/cnls unification failed with ATM
due, in essence, to IP/ATM coming from different address spaces).  Now just
how far we exploit the possibilities of co/cnls unification is determined by
how close to the end applications we allow MPLS to get....and currently its
being kept well in the network (though the MPLSF Voice_over_MPLS IA does
start to challenge this).  GMPLS takes this a step further (albeit in a
different direction) by recognising the need for a bulk-BW admin layer
network and accepts technologies like OTN/SDH for what they are, ie co
cct-sw....and here the attempt to bring greater unification is by re-using a
common control-plane paradigm.  Now whether one agrees with the actual
choice of control-plane components for a given function is only a matter of
BCP, IMO one cannot really argue with the basic desire to gain benefits from
greater unification.  I see the biggest problem we face as an industry as an
attitude problem, viz 'only my network creed is acceptable'.  This is really
sad because you are closing your eyes to the wealth of experience that
exists elsewhere...and its there for a good reason, it not simply an 'I'm
right and you're wrong' issue.
> 
> In short, PWE3's biggest problem is reification.
> 
> The question you should be asking yourself is 'how much of my
> favourite paradigm did we ever need, anyway?'
NH=> I agree one should always ask this sort of question and not simply keep
doing things one way because 'that is how it has always been done around
here'.....so I could just as easily turn this question back at yourself if
you think about it! There are essentially 3 basic network types:
-	cnls
-	co pkt-sw
-	co cct-sw
There are generic/bcp networking solutions for each of these basic network
types across:
* the data-plane (ie traffic-type, OAM, perf, etc);
* the control-plane (ie addressing, signalling, routing, and the
control-plane's own data-plane ....*except* for cnls where there is no
signalling facet, and the traffic and control data-planes are congruent by
necessity);
* and the management-plane. 
Trying to force all applications to use a single mode is tantamount to
stupidity IMO, which I can only assume arises from blindness brought on by
being too technology religious.  We need to bring these basic network types
more closer together where we can see benefit, but always be prepared to
accept that each has a use for a certain network problem/service. I'd like
to think most rational people could actually understand this.
<snipped to end NH>