[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
>