[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [IP-Optical] RE: Dead of GMPLS ?
Bala,
>
> Eric:
>
> I understand your frustration, but the current
> state of affairs was waiting to happen given the
> speed and zeal with which all sorts of features
> were being proposed as candidates for GMPLS control.
I'm not sure what you mean here. The GMPLS work has been going on since
late 1999. There have been relatively few new features added since we met
in Adelaide. In fact, much of (what I would call) zealous material in the
first version has actually been removed.
> I think the best way to move forward is to
> get some consensus on the set of well-defined
> features/capabilities that
> people agree have *current relevance*.
I thought that's what we had done in Paris. Eric, Greg, Heiles, Dimitri,
Eve, Dimitirios, myself, and others were in this meeting. What I find
strange is that some of these same people are now arguing against what we
all agreed to back then.
> Other features, drop them/move to different drafts/what not.
> It doesn't seem sensible to stop progress
> on the most general aspects of gmpls for the
> sake of supporting features whose
> near-to-intermediate term
> significance is dubious.
I'm not sure about your assessment of the significance, but I agree that we
shouldn't stop progress on the general aspects of gmpls.
Thanks,
Jonathan
>
> Regards,
>
>
>
> Bala Rajagopalan
> Tellium, Inc.
> 2 Crescent Place
> P.O. Box 901
> Oceanport, NJ 07757-0901
> Tel: (732) 923-4237
> Fax: (732) 923-9804
> Email: braja@tellium.com
>
> > -----Original Message-----
> > From: Mannie, Eric [mailto:Eric.Mannie@ebone.com]
> > Sent: Monday, May 28, 2001 11:37 AM
> > To: 'Guo-Qiang Wang'
> > Cc: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com;
> > tsg15q11@itu.int; t1x15@t1.org; q16/15; John Drake
> > Subject: RE: Dead of GMPLS ?
> >
> >
> > Hello Guo-Qiang,
> >
> > > If one non-SONET/SDH-standard feature could decide the
> death or the
> > liveness
> > of GMPLS, it is the reason I strongly suggest you guys remove
> > this feature
> > to a separate document to keep GMPLS alive. Up to now, all
> > the arguments we
> > have
> > seen are focusing on non-SONET/SDH-standard issue, not on
> > lambda switching
> > and fiber switching.
> >
> > No, please read the included e-mails and the e-mails that I
> > was referred to,
> > they are talking about waveband switching, etc..
> >
> > We are now speaking about removing waveband switching, about
> > where to put
> > protection/restoration, and about scanning all the GMPLS
> > drafts to see what
> > should be removed (see the three e-mails from Maarten).
> >
> > I am discussing the general principle of moving all
> > non-standard related
> > features to separate documents. If you want to do it for
> > technology A, to
> > stay consistent you have to do it also for technology B, C, etc.
> >
> > Of course you have to remove lambda switching since this is
> > proprietary
> > (what are the parameters to control, to signal, etc... we
> > don't know yet) -
> > It is too early in this draft to speak about that before
> > knowing how exactly
> > the transmission plane will look like. There is no value of having a
> > standardized control plane to control proprietary networks (as I
> > understood).
> >
> > My list of features to remove contains at least:
> >
> > - SDH/SONET transparency.
> > - SDH/SONET arbitrary concatenation, flexible concatenation.
> > - AUG-X, TUG, STS Groups signal types and LSP capabilities.
> > - All kinds of end-to-end protection/restoration for any
> > layer, except the
> > IP layer.
> > - The Waveband switching object and its concept.
> > - The concept of LSC and FSC layers, i.e. concept of lambda
> and fiber
> > switching.
> > - The label set object (only used for lambda issues).
> > - LSP encoding type, bandwidth encoding and GPID have to be
> simplified
> > accordingly.
> > - MPLS extensions to control G.709 (since multiplexing, etc
> is not yet
> > defined).
> > - etc...
> >
> > Something else to add to this list ?
> >
> > Rgds,
> >
> > Eric
> >
> >
> >
> > -----Original Message-----
> > From: Guo-Qiang Wang [mailto:guoqiang@nortelnetworks.com]
> > Sent: Monday, May 28, 2001 4:24 PM
> > To: Mannie, Eric; 'Maarten Vissers'
> > Cc: 'Yuri Landry'; ccamp@ops.ietf.org;
> ip-optical@lists.bell-labs.com;
> > tsg15q11@itu.int; t1x15@t1.org; q16/15; John Drake
> > Subject: RE: Dead of GMPLS ?
> >
> >
> > Hi,
> > If one non-SONET/SDH-standard feature could decide the
> death or the
> > liveness
> > of GMPLS, it is the reason I strongly suggest you guys remove
> > this feature
> > to a separate document to keep GMPLS alive. Up to now, all
> > the arguments we
> > have
> > seen are focusing on non-SONET/SDH-standard issue, not on
> > lambda switching
> > and fiber switching.
> > Regards,
> > G.Q Wang
> > Technical Manager
> > Emerging Network Technology
> > Nortel Networks
> > Tel: (613)765-4195 (ESN 395-4195)
> > Fax: (613)768-1140
> > guoqiang@nortelnetworks.com
> > -----Original Message-----
> > From: Mannie, Eric [SMTP:Eric.Mannie@ebone.com]
> > Sent: Monday, May 28, 2001 9:08 AM
> > To: 'Maarten Vissers'
> > Cc: 'Yuri Landry'; ccamp@ops.ietf.org;
> > ip-optical@lists.bell-labs.com;
> > tsg15q11@itu.int; t1x15@t1.org; q16/15; John Drake
> > Subject: Dead of GMPLS ?
> > Hello Maarten,
> > E-mail 1:
> > >Let's review the series of GMPLS
> > ^^^^^^
> > >draft documents to identify the non/pre-standard items and
> then move
> > >those items into separate Informational documents.
> > ^ ^^^^^^^^^^^^^^^^^^^^^^^
> > E-mail 2:
> > > Yuri started the discussion on wavebands some days ago.
> > Wavebands are
> > > yet undefined in the transport plane.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > E-mail 3:
> > >Triggered by Yuri's email, I would like to offer another
> > area for closer
> > >look: protection switching. The standardised SDH protection
> > switching
> > >schemes are specified in G.841 with further support in G.783.
> > >
> > >When reading the protection switching text some time ago in
> > the GMPLs
> > >draft I noticed several extensions to be described beyond those in
> > >G.841.
> > >
> > >My request is to review the latest text against G.841/G.783,
> > identify
> > >the extensions and (as now proposed by several of us) move those
> > >extensions into a separate Informational document.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > The transmission plane for optical networks is not
> standardized: DWDM
> > systems are proprietary and don't interoperate.
> > So I guess that we have to remove the concept of optical
> > switching (lambda
> > switching, fiber switching, waveband switching) from GMPLS if
> > we want to
> > follow your model of thinking. We also have to remove any
> end-to-end
> > protection/restoration and all non standardized SDH/SONET
> > behaviors (even if
> >
> > they don't change the standards) as you said.
> > Everything will become informational, except may be a very
> small root
> > specification (that will not be allowed to speak about any optical
> > switching).
> > Since the IETF will not have any standard (track) RFC, ITU-T
> > will have to
> > claim that there is no existing standard and do one...
> > What is the benefit of moving all the interesting signaling
> > features to
> > informational RFC's ? If we don't have signaling standards
> > why should we
> > continue to work on GMPLS ? Why should we spend so much energy of
> > informational documents that have no standard value ? That
> > will be an easy
> > marketing message "GMPLS: don't pay attention to it, it is only
> > informational, you need a standard".
> > Either GMPLS is dead, or we accept that GMPLS ALLOWS TO
> > CONTROL STANDARDIZED
> >
> > AND NON STANDARDIZED DATA/TRANSMISSION PLANES.
> > Regards,
> > Eric
> > -----Original Message-----
> > From: Maarten Vissers [mailto:mvissers@lucent.com]
> > Sent: Monday, May 28, 2001 11:03 AM
> > To: John Drake
> > Cc: 'Yuri Landry'; ccamp@ops.ietf.org;
> > ip-optical@lists.bell-labs.com;
> > tsg15q11@itu.int; t1x15@t1.org; q16/15
> > Subject: [IP-Optical] GMPLS: waveband switching
> >
> >
> > John,
> > Yuri started the discussion on wavebands some days ago.
> Wavebands are
> > yet undefined in the transport plane. Looking into it a few
> > days ago, I
> > tried to provide a definition of waveband and got immediately
> > corrected
> > by an optical expert, resulting in an adapted definition of
> waveband
> > (see email below).
> > At this point in time, a waveband seems to be a group of
> > Optical Channel
> > (OCh) signals. It represents a partition, not a new layer
> network. As
> > such a waveband should be represented as a "group of OCh
> > signals" within
> > the OCh layer network.
> > Regards,
> > Maarten
> >
> >
> >
> > Maarten Vissers wrote:
> > >
> > > Manoj, Yuri,
> > >
> > > I received a message that my definition of waveband is too
> > restricted.
> > >
> > > A waveband should be an optical multiplex, administered
> as a single
> > > bundle, not necessary contiguous in frequency slot.
> > >
> > > E.g. there may be good technical reasons to consider a
> > > 'waveband' created at an OADM formed by taking every 2nd
> > > wavelength in a 50GHz-spaced transmission band.
> > >
> > > In first instance the above definition may not be
> > considered this as a
> > > "band"; it
> > > looks more like a "gapped-band" :-). Nevertheless, due to
> technical
> > > reasons we should consider a waveband as just another name for a
> > > particular group of wavelengths, which may best be viewed
> > as a group of
> > > identified/listed wavelengths.
> > >
> > > Regards,
> > >
> > > Maarten
> > >
> > > Maarten Vissers wrote:
> > > >
> > > > Manoj, Yuri,
> > > >
> > > > In my current understanding, a waveband is a group of OCh
> > (optical
> > > > channel) signals located in a contiguous set of tributary (i.e.
> > > > frequency) slots.
> > > >
> > > > A waveband is therefore related to partitioning, rather
> > than a layering.
> >
> > > > A waveband shouldn't have an LSP encoding type itself,
> > but instead be
> > > > part of the OCh layer network. E.g. a specific RGT
> > (requested groupting
> > > > type) of "contiguous waveband" can be defined for this
> > purpose with the
> > > > RNC (requested number of components) indicating the size of the
> > > > waveband.
> > > >
> > > > The above is simply a first shot; in general the issue
> > can be more
> > > > complex due to the fact that the frequency slot for a
> > 2G5, a 10G and a
> > > > 40G signal may have differnet bandwidths: e.g. 2G5 freq.
> > slot width e.g.
> >
> > > > 25 GHz, 10G freq. slot width e.g. 50 GHz and 40G freq.
> > slot width e.g.
> > > > 100 GHz. For the case of (future?) mixed rate WDM signals
> > with bit rate
> > > > optimized freq. slot widths, a waveband might need a
> > start-of-waveband
> > > > and end-of-waveband (SOW-EOW) indication, instead of RNC.
> > > >
> > > > Regards,
> > > >
> > > > Maarten
> > > >
> > > > Yuri Landry wrote:
> > > > >
> > > > > Mano,
> > > > >
> > > > > > Can someone tell me the message
> structure of Label
> > Request and
> > > > > >Label Mapping in GMPLS ?
> > > > > >I am confused about the presence of LightPath Id in
> > O-UNI messages
> > and LSP
> > > > > >Id in GMPLS messages ? Is there one-to-one mapping
> > between these Ids
> > or Is
> > > > > >it like that both lightPath Id and LSP Id will be
> > carried in GMPLS
> > messages
> > > > > >? LSP Id is not present in O-UNI messages. Can one
> > LightPath Id be
> > mapped
> > > > > >to
> > > > > >multiple LSP Ids or vice versa ?
> > > > >
> > > > > I think you mean Connection ID and LSP ID. A connection
> > ID is an ID
> > for
> > > > > network connection, which may consist many LSPs. For
> > example, the
> > virtual
> > > > > concatenation case.
> > > > >
> > > > > A LSP may tunnel through multiple pre-established
> connections.
> > > > >
> > > > > >Also, for waveband switching, the genralized label has
> > the format
> > > > > >(wavebandId - start label - end label).
> > > > > >When the label request message is received on incoming
> > interface, how
> >
> > to
> > > > > >identify that the waveband label is requested ?
> > > > > >Is it the LSP encoding type or some other parameter in
> > label request
> > > > > >message
> > > > > >? If it is the Lambda encoding type then how to
> > identify that whether
> >
> > a
> > > > > >lambda or waveband label is requested ?
> > > > > >
> > > > > >Also, it is mentioned that wavebandId (32 bits) is
> > selected by the
> > sender
> > > > > >and reused in all the subsequent messages. What all
> subsequent
> > > > > >messages is it mentioning to ?
> > > > > >
> > > > > >Can wavebandId be present in Label Withdraw/Release
> messages ?
> > > > > >
> > > > > >I am not able to workout the message structures for GMPLS.
> > > > > >
> > > > >
> > > > > To me waveband label defined in GMPLS drafts is a joke.
> > The reason to
> > have
> > > > > the waveband label is that someone claimed that the
> > waveband's order
> > might
> > > > > flip when going through a switch. My suggestion is
> > don't take it
> > seriously.
> > > > >
> > > > > >I am not sure how these drafts are at last call.
> > Atleast it should
> > mention
> > > > > >the message structures of various messages.
> > > > > >
> > > > >
> > > > > Agree.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Yuri
> > > > >
> > _________________________________________________________________
> > > > > Get your FREE download of MSN Explorer at
> > http://explorer.msn.com
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > John Drake wrote:
> > >
> > > Yuri,
> > >
> > > I've attached a private note I sent to Dimitri regarding waveband
> > switching.
> > > It was originally put in at the suggestion of NorTel. For
> > both waveband
> > > switching and fiber switching, you are dealing with a
> > situation in which
> > you
> > > are using a standardized control plane to establish a
> > multi-hop LSP with
> > > proprietary encoding of data. As I mentioned, this would
> > be accomplished
> > > using link coloring.
> > >
> > > Personally, I have no problem removing either waveband
> > switching or fiber
> > > switching, but we know have to accomodate them wrt the
> > control plane, and
> > I
> > > seriously doubt that there will ever be a completely
> > non-proprietary of
> > > encoding the data for these types of LSPs.
> > >
> > > Note that I am using 'proprietary' in the exclusive sense.
> > >
> > > Thanks,
> > >
> > > John
> > > -----Original Message-----
> > > From: John Drake
> > > Sent: Wednesday, March 28, 2001 11:15 AM
> > > To: 'Papadimitriou Dimitri'; John Drake; Lou Berger
> > > Cc: 'Mannie, Eric'; 'Bala Rajagopalan'; fubar@labn.net
> > > Subject: RE: Waveband Switching (was Re: GMPLS signaling)
> > >
> > > Dimitri.
> > >
> > > It's probably better to think of waveband switching as a
> > special form of
> > > fiber switching; i.e., it has nothing to do with the
> > SONET/SDH stuff at
> > all.
> > > Suppose the trunk side of a DWDM system is attached to a
> > PXC. In the
> > fiber
> > > switching case, the fiber between the DWDM system and a
> > port on the PXC
> > > contains the entire set of lambdas, while in the waveband
> > switching case
> > > there is a set of fibers between the DWDM system and a set
> > of ports on the
> >
> > > PXC, each of which contains a separate waveband.
> > >
> > > In either case, the encoding of the signal on the fibers is
> > completely
> > > proprietary, and it's the job of routing to ensure that a
> > correct path
> > > through the network is obtained, such that the proprietary
> > encoding is
> > > maintained end-end. This would probably be done through
> > link coloring, so
> >
> > > that you only route across links that support NorTel
> > waveband switching or
> >
> > > Tellabs waveband switching.
> > >
> > > So I think the signalling stuff is fine.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Yuri Landry [mailto:yurilandry@hotmail.com]
> > > Sent: Friday, May 25, 2001 7:02 AM
> > > To: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com;
> > > tsg15q11@itu.int; t1x15@t1.org
> > > Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > > concatena tion
> > >
> > > Hello All,
> > >
> > > So far, our discussions are focusing on the SONET/SDH
> > draft. I'd like to
> > > re-direct your attention to other drafts. Rob's suggestion
> > should apply to
> >
> > > other drafts too.
> > >
> > > One example, is the waveband switching and waveband label a
> > standard or
> > > proprietary? Can author explain to me what exactly they
> > means? How do they
> >
> > > work? Any other standard reference? There are questions
> > about it but no
> > > answer yet.
> > >
> > > Regards,
> > >
> > > Yuri.
> > >
> > > >From: "Lazer, Monica A, NNAD" <mlazer@att.com>
> > > >To: "'Rob Coltun'" <rcoltun@redback.com>, ccamp@ops.ietf.org,
> > > >ip-optical@lists.bell-labs.com, q11/15 <tsg15q11@itu.int>,
> > "t1x1.5"
> > > ><t1x15@t1.org>
> > > >Subject: RE: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > concatena
> > > >tion
> > > >Date: Thu, 24 May 2001 18:11:36 -0400
> > > >
> > > >
> > > >Rob, You proposal makes a lot of sense. Having the
> > signaling standard
> > > >support proprietary transport may jeopardize
> > interoperability. The issue
> > is
> > > >not about GMPLS supporting non-standard rates, the issue
> > is about putting
> >
> > > >in
> > > >formal and very specific support for a proprietary
> > transport solution in
> > a
> > > >standard document for signaling without taking the
> > transport portion to a
> >
> > > >standards body. Having formal signaling support for a
> proprietary
> > > >concatenation may cause interoperability issues when other
> > vendors have a
> >
> > > >different solution to the concatenation and while the
> > signaling would
> > > >indicate the concatenation, the actual transport may not
> > work. On the
> > > >other hand we recognize that there may be a need for some
> > interim support
> >
> > > >for proprietary solutions.
> > > >
> > > >
> > > >Eric,
> > > >Below I have some additional specific comments for the
> > document GMPLS
> > > >Extensions for SONET and SDH Control
> > > >
> > > >
> > > >CCT field (3 bits)
> > > >Since arbitrary contiguous concatenation is not a standard
> > concatenation,
> >
> > > >it
> > > >falls within the vendor proprietary set of solutions.
> > > >
> > > >So the CCT bits may be used as follows:
> > > >000 No contiguous concatenation requested
> > > >001 Standard contiguous concatenation
> > > >others Vendor specific contiguous concatenation
> > > >
> > > >Alternatively, a better solution is to use only 2 bits for
> > this field and
> >
> > > >use one bit to show whether contiguous concatenation is
> > requested and the
> >
> > > >second bit to show whether it is standard or non-standard
> > contiguous
> > > >concatenation.
> > > >
> > > >
> > > >NCC field (16 bits)
> > > >This information is not sufficient.
> > > >NCC needs better description than a zero or non-zero number.
> > > >
> > > >SDH and SONET Labels
> > > >
> > > >Text in this section (Section 3, paragraphs 5 and 6)
> > indicates that the
> > > >GMPLS proposal limits virtual concatenation to remain
> > within a single
> > > >(component) link. If I understand this correctly, it means
> > that GMPLS
> > will
> > > >not allow inverse multiplexing (virtual concatenation) in
> > the transport
> > > >plane if it requires different component links. This is
> > too limiting.
> > > >
> > > >Annex 1 (sent out by Eric Mannie on 5/22)
> > > >Defines another type of concatenation - Flexible arbitrary
> > contiguous
> > > >concatenation without describing precisely how it affects
> > the OH bits.
> > This
> > > >means that it will be impossible to have this type of
> > concatenation in a
> > > >multi vendor environment based only on the GMPLS
> signaling. If the
> > > >transport
> > > >plane is proprietary, having the option in the signaling
> > message will not
> >
> > > >fix the interoperability problem between two different
> > vendors supporting
> >
> > > >their proprietary versions of arbitrary concatenation.
> > > >
> > > >Annex 2 (sent out by Eric Mannie on 5/22)
> > > >Arbitrary contiguous concatenation needs definition work for
> > > >interoperability.
> > > >Flexible arbitrary contiguous concatenation may be
> > available today to
> > > >support contiguous signals, but it is not defined in the current
> > standards.
> > > >Clear agreements on OH usage are needed between supporting
> > vendors.
> > > >Maintenance and tracking of the signal needs to be well
> > understood.
> > > >
> > > >
> > > >
> > > >Monica A. Lazer
> > > >Advanced Transport Technology and Architecture Planning
> > > >
> > > >908 234 8462
> > > >mlazer@att.com
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: Rob Coltun [mailto:rcoltun@redback.com]
> > > >Sent: Thursday, May 24, 2001 7:24 PM
> > > >To: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com;
> > q11/15; t1x1.5
> > > >Subject: Re: [T1X1.5] RE: [IP-Optical] Re: Proposed text for the
> > > >concatenation
> > > >
> > > >All,
> > > > despite the heated arguments I think the discussion
> > is important to
> > > >have.
> > > >
> > > >I suggest that instead of tagging non/pre-standard items
> > in the current
> > > >drafts
> > > >that they be put into a separate Informational document -
> > this is the
> > > >cleanest thing to do.
> > > >We (the IETF) do have a tradition of publishing company
> > proprietary
> > > >protocols
> > > >but not as standard track documents.
> > > >
> > > >thanks,
> > > >---rob
> > > >
> > > >
> > > >
> > > >_______________________________________________
> > > >IP-Optical mailing list
> > > >IP-Optical@lists.bell-labs.com
> > > >http://lists.bell-labs.com/mailman/listinfo/ip-optical
> > > >
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com
> > >
> > > _______________________________________________
> > > IP-Optical mailing list
> > > IP-Optical@lists.bell-labs.com
> > > http://lists.bell-labs.com/mailman/listinfo/ip-optical
> >
>
> _______________________________________________
> IP-Optical mailing list
> IP-Optical@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/ip-optical
>