[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Generalized Signaling - LSP Encoding Type expansion



Yakov,
Thank you for your reply. I appreciate your comments, but we may have some
differences of opinion. For convenience, I am inserting my opinions in line.

Monica A. Lazer
Advanced Transport Technology and Architecture Planning

908 234 8462
mlazer@att.com


 -----Original Message-----
From: 	Yakov Rekhter [mailto:yakov@juniper.net] 
Sent:	Monday, October 22, 2001 4:12 PM
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.

[[Lazer, AT&T]]  I think that we may have somewhat diverging opinions. For
me a control plane of value for a given transport technology needs to
support control for all the services supported in the data plane. To be more
specific, if a transport technology supports transport for SONET, GbE, and
SAN, its associated control plane must support signaling and routing for
same. It does not need to encumber itself for support of services not
implemented in the hardware, but I see no good reason to support a service
in the data plane, but not in the control plane.

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.

[[Lazer, AT&T]]  I am not looking at "all things for all people". I am
looking, as I mentioned in an earlier message at the control plane of a
given subnetwork supporting all the services of the data plane it controls.
If some services using a given network elements use the control plane, while
others need an outside OS, resource allocation and coordination becomes are
real issue.
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
>