[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
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
> > >
> > >
> >
> >
>