[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
Hi
Dimitri seems to me to be making a very abstract and legalistic point.
The reason why this work is important is that the IEEE has been evolving
Ethernet to give it carrier class features, in respect of scalability,
OAM, and (with 802.1Qay) the possibility to use an external control
plane. Some of these features will very likely require or enable added
value from extensions to the functionality of GMPLS - for example, as
has already been suggested, the addition of functionality for creating
the OAM associations. Therefore this will likely not be the same as the
possible use suggested in RFC3945, which may (at least in theory) have
been implemented somewhere. Therefore the suggestion in the draft seems
to make sense. I can't really see what important principle is being
defended by the insistence upon L2SC, which, as Don Fedyk stated, was
always somewhat underspecified.
This is not something to be debated in the abstract. The work in ccamp
should allow sensible extension of functionality where it adds value,
and this needs to be discussed on a case by case basis. Therefore we
should make it a working group document and get on with it.
regards Howard Green
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of PAPADIMITRIOU Dimitri
Sent: 30 January 2008 10:15
To: Loa Andersson
Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;
lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;
ccamp@ops.ietf.org
Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
loa,
i think the main point as ccamp is whether or not we poll for a change
or a continuation inline with RFC3945 -- when the present doc. states:
"It is expected that there will be no
case where an Eth-LSP will be signaled, or an Eth-LSP supporting
interface will be represented, using the L2SC switching
type/capability. A new switching type/capability is required to
avoid any potential current usage of the L2SC switching
type/capability in support of Ethernet.
[...]
"The L2SC Interface Switching Capabilities MUST
NOT be used to represent interfaces capable of supporting Eth-LSPs."
it raises three issues:
a) what was the previous L2SC def. per RFC 3945 meant for if not for use
also in GMPLS Ethernet context ?
b) why a "new one" ?
this is not explained.
c) what is the "new one" implying in terms of GMPLS ?
for inst. in the intro "The intent of this document is to reuse and
align with as much of the GMPLS protocols as possible." leaves open the
issue of what as much as possible means.
and on the other "Additions are made only to accommodate features of
Ethernet that are not already supported by GMPLS." so, how shall i
interpreet the first sentence now ? inline with point a) and b) ?
the doc. in WG I-D status or not is not going to provide an answer to
these questions. sentences and statements in the doc. contradict each
other.
thanks,
-d.
> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.se]
> Sent: Tuesday, January 29, 2008 2:04 PM
> To: PAPADIMITRIOU Dimitri
> Cc: neil.2.harrison@bt.com; benjamin.niven-jenkins@bt.com;
> lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;
> ccamp@ops.ietf.org
> Subject: Re: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>
> Dimitri,
>
> it is possible that you have a point that needs to be discussed, but
> is this really something that should stop us from adopting the doc as
> a working group document.
>
> /Loa
>
> PAPADIMITRIOU Dimitri wrote:
> > 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
> >>>>
> >>>>
> >>>
> >
> >
> >
>
>
> --
> Loa Andersson
>
> Principal Networking Architect
> Acreo AB phone: +46 8 632 77 14
> Isafjordsgatan 22 mobile: +46 739 81 21 64
> Kista, Sweden email: loa.andersson@acreo.se
> loa@pi.se
>