[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Generalized Signaling - LSP Encoding Type expansion
Yakov,
To be completely fair, it is NOT necessary for any provider to run
"*all possible services*" for the introduction of a new control plane
which supports only a subset of those services to be costly. It is
only necessary for a provider to need to provide some services from
that subset and some services from the universe-less-that-subset for
it to be necessary to either support multiple control planes, or avoid
use of the new control plane.
This is probably what Monica means by diminished value.
On the other hand, GMPLS is intended to be optimized for IP which
- in some people's model of *the future of networking* - might mean
that it will likely be adopted in spite of a perceived diminished value
in the general sense. Hence, I think part of your point might be better
expressed as:
*Extending GMPLS to support all possible applications in an effort
to reduce a perception of diminished value, would actually diminish
the value of GMPLS for its target application(s).*
What do you think?
You wrote:
> Monica,
>
> > Dimitri,
> > Actually, it may be more accurate to put it differently - if GMPLS supports
> > only a handful of the services running on a given transport network, than
> > its value as a network's control plane component is diminished.
>
> To be even more accurate, GMPLS value is diminished *in the context*
> of that particular transport network. And unless *all* providers
> are going to run *all possible services* on their transport networks
> (which is a somewhat unrealistic scenario), that means that the
> value of GMPLS as a network's control plane component would be
> diminished for *some*, but not *all* service providers.
>
> At the same time, it is important to keep in mind that being "all
> things for all people" (aka as "perfect solution") is one of the
> *non-goals* of GMPLS. So, it shouldn't come as a surprise if for a
> *particular* provider GMPLS would *not* support *all* the services
> that this provider runs on its transport network.
>
> Yakov.
>
> >
> > Monica A. Lazer
> > Advanced Transport Technology and Architecture Planning
> >
> > 908 234 8462
> > mlazer@att.com
> >
> >
> > -----Original Message-----
> > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be]
>
> > Sent: Monday, October 22, 2001 3:15 PM
> > To: Lazer, Monica A, NNAD
> > Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org
> > Subject: Re: Generalized Signaling - LSP Encoding Type expansion
> >
> > << File: Card for Dimitri Papadimitriou >> Hi Monica,
> >
> > Fine. Now we know the following: GMPLS is really attractive for
> > carriers when it supports all transport technologies so it has
> > to support Fiber Channel as well.
> >
> > I wasn't aware that Ewart was capable to read in your mind ;-)
> >
> > Regards,
> > Dimitri.
> >
> > "Lazer, Monica A, NNAD" wrote:
> > >
> > > Dimitri,
> > > I am just answering the PS question with this message.
> > > The short answer is yes. The long answer is that the GMPLS control plane
> > is
> > > really useful if it can support connection management for all the
> > transport
> > > services supported by the transport network using GMPLS. Therefore, the
> > > carrier services section for the NNI document to be posted on the OIF site
> > > within a few minutes and the next draft of the carrier requirements IETF
> > > draft will both contain references to support of Fiber Channel.
> > > Regards,
> > > Monica A. Lazer
> > > Advanced Transport Technology and Architecture Planning
> > >
> > > 908 234 8462
> > > mlazer@att.com
> > >
> > > -----Original Message-----
> > > From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be]
> > > Sent: Monday, October 22, 2001 2:47 PM
> > > To: Ewart Tempest
> > > Cc: lberger@movaz.com; ccamp@ops.ietf.org
> > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion
> > >
> > > << File: Card for Dimitri Papadimitriou >> Hi Ewart,
> > >
> > > If you take a look on the IEEE Standards you will see
> > > that GE is referred to as
> > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab
> > > - 802.3ae for 10Gbps (see below [2])
> > >
> > > So my question is what do you have in mind ? to separate
> > > these values ?
> > >
> > > Thanks,
> > > Dimitri.
> > >
> > > PS: for FiberChannel sorry i am not an expert but is someone
> > > targeting to use GMPLS for FiberChannel LSP ?
> > >
> > > -------
> > >
> > > [1] From - http://standards.ieee.org
> > >
> > > Project scope: Define Carrier Sense Multiple Access with Collision
> > > Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal
> > > augmentation of its operation, physical layer characteristics, repeater
> > > functions and management parameters for transfer of 802.3 and Ethernet
> > > format frames at 1,000 Mb/s.
> > >
> > > Project purpose: The purpose of this project is to extend the 802.3
> > > protocol to an operating speed of 1,000 Mb/s in order to provide a
> > > significant increase in bandwidth while maintaining maximum
> > > compatibility
> > > with the installed base of CSMA/CD nodes, previous investment in
> > > research
> > > and development, and principles of network operation and management.
> > >
> > > [2] From - http://standards.ieee.org
> > >
> > > Project scope: Define 802.3 Media Access Control (MAC) parameters and
> > > minimal augmentation of its operation, physical layer characteristics
> > > and management parameters for transfer of LLC and Ethernet format
> > > frames at 10 Gb/s using full duplex operation as defined in the 802.3
> > > standard. In addition to the traditional LAN space, add parameters and
> > > mechanisms that enable deployment of Ethernet over the Wide Area Network
> > > operating at a data rate compatible with OC-192c and SDH VC-4-64c
> > > payload
> > > rate.
> > >
> > > Project purpose: The purpose of this project is to extend the 802.3
> > > protocol to an operating speed of 10 Gb/s and to expand the Ethernet
> > > application space to include Wide Area Network links in order to provide
> > > a significant increase in bandwidth while maintaining maximum
> > > compatibility
> > > with the installed base of 802.3 interfaces, previous investment in
> > > research
> > > and development, and principles of network operation and management.
> > >
> > > -------
> > >
> > > > Ewart Tempest wrote:
> > > >
> > > > Lou,
> > > >
> > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can
> > > > you please add additonal LSP Encoding Types for GE and FiberChannel.
> > > > GE is not really covered by the existing Ethernet related encoding
> > > > types, and FiberChannel is not covered at all. Thanks.
> > > >
> > > > Ewart
> >
--
Eric Gray (mailto:eric.gray@sandburst.com)
http://www.mindspring.com/~ewgray