RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt

[<neil.2.harrison@bt.com>]

Thanks Dimitri...I think I am understanding your concern/point a little
better now......please see further comments below (I've snipped the mail
to the salient bits):

> > DP=> this is not what i say. i am concerned in stating beforehand
> > > RFC 3945 (GMPLS Arch.) is not applicable to Ethernet. Why the 
> > > doc. does not deliver any tangible explanation.
> > 
> > NH=> Is your problem that you cannot differentiate between
> > the 3 network modes (of co-cs, co-ps and cl-ps)?  
> 
> my concern wrt specific point you bring is that the today 
> definition in RFC 3945 for L2SC,
NH=> I really don't think you should get too hung-up on what folks have
called things here, ie L2SC.  Stick with the physics.  Much of the
misunderstandings I've encountered over many years stem from the OSI Ref
Model, and the wrong impression it gives that there is only one/single
'L3 network'....it's a myth.  ALL networks (any mode) are 'L3' in the
OSI sense.  Folks also tend to make the wrong association IP=L3 and
since IP is cl-ps then cl-ps=L3.....then they come to Ethernet and
because this is often used as a server to IP they call it 'L2' (OSI
sense).  But since native Ethernet is cl-ps then surely this must also
be L3?  Of course it is L3...all networks are!

The only thing that truly matters is whether the resource you are
partitioning and labelling is time, freq or space in nature....and it's
then up to us as engineers how well we go about functionally
specifying/equipping the layer networks we create in each of the 3
modes.  And most critically here one can ONLY get deterministic resource
assignment across a network if one creates a connection object.  I could
carry on here and go into great detail of exactly how all this works and
why we have the 3 network modes, but I'll refer you to the work on
unified modelling under Q12 of SG15.  

Bottom-line:  Look to the real world of networking and ask yourself why
it is we see the 3 network modes....it really is not chance, but simply
comes down to the physics of partitioning/labelling a finite resource
(time/freq/space) domain....don't get hung-up on names for things
without such a scientific basis.


> GMPLS for Ethernet (with local labels or domain-wide labels 
> or any other equivalent to "co-ps") does not result into a 
> different definition than what's in. on the other side, i do 
> not see how would apply GMPLS for connectionless/bridged Ethernet.
NH=> I agree with you.  GMPLS is a suite of CP functional components for
use in co mode layer networks.

But my position is one based on an understanding of the physics at play
here.  This is why I tried to point out in my prior mail the importance
of understanding that we can take an Ethernet traffic unit (packet) and
apply either a cl-ps or co-ps mode behaviour to it (as a network).  This
is our choice.  This does however require that specific functional
fields of the traffic unit are present....in essence one can take
short-cuts with labelling (ie remove information) in the co modes (eg
omit SA, use link-local DA proxy labels that get swapped per hop)
because we have a connection as a network object, but one can't take
these short-cuts in the cl-ps mode because we don't have a connection.
I'll assume this is obvious to everyone.....but it does require (from
information considerations) that folks properly understand what a
connection is (and also what it is not).

But be very clear on this point:  If we use a common traffic unit to
create a cl-ps mode layer network and a co-ps mode layer network then
these are 2 quite distinct layer networks, ie they do not operate in the
same layer network space.....put more simply, we have to be careful not
to mix-up their traffic units.  The key points here are all to do with
what we call 'characteristic information' in func arch terminology, and
specifically how one assigns/manages resource.  This is perhaps less
clear to see in the co-ps mode than the co-cs mode when compared to the
cl-ps mode.  That is:  In the co-cs mode labelling and resource
assignment are fixed/deterministic actions, but in the co-ps mode they
are decoupled actions....and whilst this flexibility has some
advantages, it also carries a responsibility that lies with those
designing co-ps mode layer networks not to screw things up, eg one can
create merging constructs which result in complex resource and
fault/perf management problems for network operators...actually the
resource problem is intractable, and the only practical solution is to
throw BW at the problem.

regards, Neil