[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
I personally think you are making a mountain out of a molehill here
Dimitri. And I thought I had explained why there are differences in the
treatment of layer networks depending on their mode...I clearly did a
bad job. Sure GMPLS is a generic OOB CP suite of protocols, but the
details of the parameters used used to describe the layer network being
considered will depend on:
- for the co-cs mode whether we are dealing with resources which
are either regular time-slices, freq or space
- for the co-ps mode there is only irregular time-slices.
And the labelling of such resource partitions is different in each case
too...so just like it is impossible to have a common (ie single instance
of) CP running 'IP to Optics' (or any functional component for that
matter) it is impossible to have an identical set of parameters
describing each mode....this is just the physics and the way it is. The
co-ps mode has the richest scope for 'variation' in the DP labelling of
traffic units (this is more than simply a destination proxy label
BTW....this was a point I saw Adrian alluding to)....and one can even
violate the rules of connections here and really screw-up any notion of
deterministic resource management anyway.
regards, Neil
> -----Original Message-----
> From: PAPADIMITRIOU Dimitri
> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]
> Sent: 30 January 2008 17:23
> To: Howard Green; Loa Andersson
> Cc: Harrison,N,Neil,DMF R; Niven-jenkins,B,Ben,DMF R;
> lberger@labn.net; dwfedyk@nortel.com; dbrungard@att.com;
> ccamp@ops.ietf.org
> Subject: RE: Proposed WG Draft - draft-gmpls-ethernet-arch-00.txt
>
>
>
>
> > -----Original Message-----
> > From: Howard Green [mailto:howard.green@ericsson.com]
> > Sent: Wednesday, January 30, 2008 12:09 PM
> > To: PAPADIMITRIOU Dimitri; 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
> >
> > Hi
> > Dimitri seems to me to be making a very abstract and
> legalistic point.
>
> receive my total disagreement. an individual submission that
> asks to change an existing RFC requires discussion and
> particular attention (in part., when it is the protocol arch.
> document) - if this not possible then probably you have to
> write also a doc. asking for changing the IETF proces - and
> then you come back with your individual submission.
>
> > 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.
>
> no one i think question this. and i don't think the poll is
> on this specific point. CCAMP or even IETF at large is not an
> authority to decide upon IEEE technos.
>
> > 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.
>
> indeed, and your colleague has already received a list of
> comments to be addressed before seeing any way forward w/ the
> proposed approach.
>
> > 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.
>
> the exact problem, i mentionned a couple of times. your own
> comment shows that one may use GMPLS differently but may i
> ask WHY ? and what's the implications ?
>
> > Therefore the suggestion in the draft seems to make sense.
>
> why ?
>
> > 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.
>
> THE reason is that an interface SC or a related functionality
> has never resulted in a specific change in the base protocol
> building blocks. GMPLS is a generalized approach not a
> differentiated approach per interface.
>
> actually your last statement is not correct (L2SC is well
> specified in RFC 3945) AND by the way yours does not at all
> better specify it.
>
> > 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.
>
> -d.
> > 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
> > >
> >
> >
>