[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Generalized Signaling - LSP Encoding Type expansion
Yakov,
See comments in-line
> -----Original Message-----
> From: Yakov Rekhter [SMTP:yakov@juniper.net]
> Sent: 22 October 2001 21:12
> To: Lazer, Monica A, NNAD
> Cc: ccamp@ops.ietf.org
> Subject: Re: Generalized Signaling - LSP Encoding Type expansion
>
> 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.
>
>
>
[shehzad]
For a control plane not to support all the transport services capable of
being carried over an operator's network diminishes the value of that
particular control plane. What is the point of having transparent/optical
equipment capable of transporting both Gigabit Ethernet and Fiber Channel
(as an example), if provisioning was based on signalling that could only
support Gigabit Ethernet?
This is a restriction for every provider regardless of whether a network is
a standalone one built for a large customer or a national network serving
multiple customers. The effective 'banning' of certain services that are
currently being offered by providers will unnecessarily damage the business
case for the adoption of GMPLS.
> 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.
>
>
[Shehzad]
There is no technical reason why a GMPLS encoding type could not be
adopted for a recognised format such as Fiber Channel, as far as I am aware
the adoption of Fiber Channel is not likely to destroy the foundations of
GMPLS.
On a more general point, is the support of transport technologies
within GMPLS signalling restricted to those that the authors of the GMPLS
drafts will allow?
> > 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
> >