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

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

Dimitri....see if this helps...in-line

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of PAPADIMITRIOU Dimitri
> Sent: 25 January 2008 11:36
> To: Niven-jenkins,B,Ben,DMF R; Lou Berger
> Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> 
> 
> ben 
> 
> > -----Original Message-----
> > From: Ben Niven-Jenkins [mailto:benjamin.niven-jenkins@bt.com]
> > Sent: Thursday, January 24, 2008 3:40 PM
> > To: PAPADIMITRIOU Dimitri; Lou Berger
> > Cc: Don Fedyk; BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org
> > Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
> > 
> > Dimitri,
> > 
> > I find your mail somewhat puzzling.
> > 
> > You appear to be saying that GMPLS as per RFC 3945 is set 
> in stone and 
> > nothing should modify/enhance the behaviour as specified in RFC3945 
> > which implies that when RFC3945 was produced the crystal ball was 
> > working extremely well and all possible future applications of the
> > technology had
> > been correctly envisaged.  I don't believe that was the case.
> 
> 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)?  If so then looking at the work on
unified modelling in SG15/Q12 may help you.  But to give a more specific
example here:  We can take an Ethernet traffic unit and create either a
cl-ps and co-ps layer network based on this...in fact one can image 3
different layer network cases here:
-	traditional Etherent which does not have a directed routing
function, ie uses MAC learning, broadcast unknown, STP...this is a cl-ps
layer network
-	Ethernet with an IGP providing a directed routing
function....this is also a cl-ps layer network, but it is different to
the one above
-	Ethernet with a directed routing component (centralised or
distributed, ie IGP) and a signalling component that can create
connections....this would be a co-ps layer network.

These are all based on a similar traffic unit, however they form 3 quite
different layer networks (and in functional architecture terms we would
say 'the Characteristic Information is different in the 3 cases').

Now GMPLS is applying a reusable set of CP components (which is a very
good thing, as Ben points out below) for any co-cs or co-ps mode layer
network.  So we are setting up *connections* in either a space, freq or
time dimension of resource, and it is these 3 resource dimensions that
create the differences in parameters...however, the notion of a
connection is common across all these resource dimensions.  GMPLS does
not apply to the cl-ps mode, as it plainly does not have connections.

That is at least how I look at this issue.

regards, Neil
> 
> > > the question triggered by this poll is the following: if 
> GMPLS for 
> > > Ethernet is not inline with the existing stacks what is 
> the value of 
> > > GMPLS re-use ? what's the value to borrow the term GMPLS 
> without its 
> > > substance ? and in practice, the issue is, if it is not
> > GMPLS per RFC
> > > 3945, what's the value compared to any other native control
> > stack that
> > > would be developed at IEEE for inst. for these techno's.
> > 
> > If we ignore the peer model (which is unworkable in reality
> > IMO), the value
> > is obvious - significant reuse of existing code, techniques, 
> > knowledge,
> > skills, etc.
> > 
> > So, we should develop the control plane from scratch 
> because Ethernet 
> > requires a few modifications/enhancements (which I believe are 
> > backwards
> > compatible) to RFC3945 - that IMO is ridiculous.
> 
> so you seem to agree with me. departing from RFC 3945 makes 
> little sense. it would have been interesting to see the doc 
> delivering a FIT of the GMPLS protocol arch. blocks and, in 
> particular, label allocation and distribution for Ethernet.
> 
> thanks,
> -dimitri.
> > Ben
> > 
> > 
> 
>