neil,
-----Original Message-----
From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]
Sent: Friday, January 25, 2008 2:27 PM
To: PAPADIMITRIOU Dimitri; benjamin.niven-jenkins@bt.com;
lberger@labn.net
Cc: dwfedyk@nortel.com; dbrungard@att.com; ccamp@ops.ietf.org
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
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)?
my concern wrt specific point you bring is that the today definition in
RFC 3945 for L2SC, and in the present case 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.
note also that GMPLS induces label from the interface and link
characteristic (i.e. there is no "label type" in the label/label request
object.
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.
well indeed, and this is the reason why i do not see any reason to
open the space for a different set of mechanisms that would result
from this new interface switching definition.
thanks,
-d.
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