[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Generalized Signalling - LSP Encoding Type expansion
Shehzad,
> Yakov,
>
> The percentage of carriers that have all of their requirements met by the
> current GMPLS drafts is an unknown. However the following points still
> need to be addressed.
>
> 1. Why would an operator adopt GMPLS infrastructure if it only carried a
> subset of the transport services that they are already offer to customers?
> In effect spending more and getting less.
It depends on the percentage of the total profit that could be generated by
the subset.
> 2. Why is there a problem reserving a code-point for a service that some
> vendors may wish to implement on their GMPLS equipment? Presumably they
> would not implement capability for which there is no demand.
If all you ask is a code-point, this code point is relevant only
to the LSPs' end-points, and not every GMPLS vendor is *required* to support
this code-point, then I don't think there is a problem with doing
this.
> 3. What is the process by which certain transport services are decided
> suitable for inclusion into the GMPLS specifications/drafts? It seems that
> inclusion of additional services fraught with difficulties, this is likely
> to get worse when the drafts turn into specifications.
The types of services that would be suitable for inclusion are the services
that (a) would *not* require changes/upgrades to the GMPLS core, and (b) would
not require every GMPLS vendor to implement every service.
Yakov.
>
>
>
> Shehzad
>
>
>
> > -----Original Message-----
> > From: Yakov Rekhter [SMTP:yakov@juniper.net]
> > Sent: 23 October 2001 16:17
> > To: Lazer, Monica A, NNAD
> > Cc: 'shehzad.mirza@bt.com'; ccamp@ops.ietf.org
> > Subject: Re: Generalized Signaling - LSP Encoding Type expansion
> >
> > Monica,
> >
> > > All,
> > > I am in full agreement with Shehzad. From a carrier's perspective, the
> > value
> > > of the control plane is in taking over specific functions which
> > currently
> > > reside in OSSs outside of the network itself. Having only some
> > applications,
> > > but not others of the given function move into the network greatly
> > > diminishes the value of having that function supported in the control
> > plane.
> > > To be more specific, if out of n services supported by the transport
> > > network, the control plane supports automated provisioning of 1/2n
> > services
> > > and the other 1/2n need support in the OSS, we still need to do the OSS
> > work
> > > for the given transport technology. So from a cost perspective, now we
> > have
> > > to ask ourselves whether we should pay for the provisioning function
> > twice.
> >
> > While what you said makes sense from a given carrier's perspective,
> > we need to take a broader view, as producing a "perfect solution"
> > that meets *all* the requirements of *all* the carriers is an
> > explicit non-goal of GMPLS. With this in mind, if the 1/2n services
> > that aren't supported by the control plane are the services that
> > are required by 90% of the carriers market, then indeed this is a
> > problem. On the other hand, if these 1/2n services that aren't
> > supported are the services required by only 10% of the carriers
> > market, then this is quite acceptable. Understandably, the carriers
> > who would fall into this 10% category could be quite unhappy about,
> > and could even be quite vocal in expressing their dissatisfaction...
> >
> > Yakov.
> >
> > > Regards,
> > >
> > > Monica A. Lazer
> > > Advanced Transport Technology and Architecture Planning
> > >
> > > 908 234 8462
> > > mlazer@att.com
> > >
> > >
> > > -----Original Message-----
> > > From: shehzad.mirza@bt.com [mailto:shehzad.mirza@bt.com]
> > > Sent: Tuesday, October 23, 2001 6:25 AM
> > > To: yakov@juniper.net
> > > Cc: Lazer, Monica A, NNAD; ccamp@ops.ietf.org
> > > Subject: 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
> > > > >
> > >
> > > ------_=_NextPart_001_01C15BCA.5A2A5650
> > > Content-Type: text/html;
> > > charset="iso-8859-1"
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> > > <HTML>
> > > <HEAD>
> > > <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> > > charset=3Diso-8859-1">
> > > <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> > > 5.5.2654.19">
> > > <TITLE>RE: Generalized Signaling - LSP Encoding Type expansion </TITLE>
> > > </HEAD>
> > > <BODY>
> > >
> > > <P><FONT SIZE=3D2>All,</FONT>
> > > <BR><FONT SIZE=3D2>I am in full agreement with Shehzad. From a =
> > > carrier's perspective, the value of the control plane is in taking over
> > =
> > > specific functions which currently reside in OSSs outside of the =
> > > network itself. Having only some applications, but not others of the =
> > > given function move into the network greatly diminishes the value of =
> > > having that function supported in the control plane. To be more =
> > > specific, if out of n services supported by the transport network, the =
> > > control plane supports automated provisioning of 1/2n services =
> > and the other 1/2n need support in the OSS, we still need to do the OSS =
> > > work for the given transport technology. So from a cost perspective, =
> > > now we have to ask ourselves whether we should pay for the provisioning
> > =
> > > function twice.</FONT></P>
> > >
> > > <P><FONT SIZE=3D2>Regards,</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=3D2>Monica A. Lazer</FONT>
> > > <BR><FONT SIZE=3D2>Advanced Transport Technology and Architecture =
> > > Planning</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=3D2>908 234 8462</FONT>
> > > <BR><FONT SIZE=3D2>mlazer@att.com</FONT>
> > > </P>
> > > <BR>
> > >
> > > <P><FONT SIZE=3D2> -----Original Message-----</FONT>
> > > <BR><FONT SIZE=3D2>From: shehzad.mirza@bt.com [<A =
> > > HREF=3D"mailto:shehzad.mirza@bt.com";>mailto:shehzad.mirza@bt.com</A>] =
> > > </FONT>
> > > <BR><FONT SIZE=3D2>Sent: Tuesday, October 23, 2001 6:25 =
> > > AM</FONT>
> > > <BR><FONT SIZE=3D2>To: yakov@juniper.net</FONT>
> > > <BR><FONT SIZE=3D2>Cc: Lazer, Monica A, NNAD; =
> > > ccamp@ops.ietf.org</FONT>
> > > <BR><FONT SIZE=3D2>Subject: =
> > > RE: Generalized Signaling - LSP Encoding Type expansion </FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=3D2>Yakov,</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=3D2>See comments in-line</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=3D2>> -----Original Message-----</FONT>
> > > <BR><FONT SIZE=3D2>> From: Yakov Rekhter =
> > > [SMTP:yakov@juniper.net]</FONT>
> > > <BR><FONT SIZE=3D2>> Sent: 22 October 2001 21:12</FONT>
> > > <BR><FONT SIZE=3D2>> To: Lazer, Monica A, NNAD</FONT>
> > > <BR><FONT SIZE=3D2>> Cc: ccamp@ops.ietf.org</FONT>
> > > <BR><FONT SIZE=3D2>> Subject: Re: =
> > > Generalized Signaling - LSP Encoding Type expansion </FONT>
> > > <BR><FONT SIZE=3D2>> </FONT>
> > > <BR><FONT SIZE=3D2>> Monica,</FONT>
> > > <BR><FONT SIZE=3D2>> </FONT>
> > > <BR><FONT SIZE=3D2>> > Dimitri,</FONT>
> > > <BR><FONT SIZE=3D2>> > Actually, it may be more accurate to put =
> > > it differently - if GMPLS</FONT>
> > > <BR><FONT SIZE=3D2>> supports</FONT>
> > > <BR><FONT SIZE=3D2>> > only a handful of the services running on =
> > > a given transport network,</FONT>
> > > <BR><FONT SIZE=3D2>> than</FONT>
> > > <BR><FONT SIZE=3D2>> > its value as a network's control plane =
> > > component is diminished. </FONT>
> > > <BR><FONT SIZE=3D2>> </FONT>
> > > <BR><FONT SIZE=3D2>> To be even more accurate, GMPLS value is =
> > > diminished *in the context*</FONT>
> > > <BR><FONT SIZE=3D2>> of that particular transport network. And =
> > > unless *all* providers</FONT>
> > > <BR><FONT SIZE=3D2>> are going to run *all possible services* on =
> > > their transport networks</FONT>
> > > <BR><FONT SIZE=3D2>> (which is a somewhat unrealistic scenario), =
> > > that means that the</FONT>
> > > <BR><FONT SIZE=3D2>> value of GMPLS as a network's control plane =
> > > component would be</FONT>
> > > <BR><FONT SIZE=3D2>> diminished for *some*, but not *all* service =
> > > providers.</FONT>
> > > <BR><FONT SIZE=3D2>> </FONT>
> > > <BR><FONT SIZE=3D2>> </FONT>
> > > <BR><FONT SIZE=3D2>> </FONT>
> > > <BR> <FONT =
> > > SIZE=3D2>[shehzad] </FONT>
> > > <BR><FONT SIZE=3D2>For a control plane not to support all the transport
> > =
> > > services capable of</FONT>
> > > <BR><FONT SIZE=3D2>being carried over an operator's network diminishes =
> > > the value of that</FONT>
> > > <BR><FONT SIZE=3D2>particular control plane. What is the point of
> > =
> > > having transparent/optical</FONT>
> > > <BR><FONT SIZE=3D2>equipment capable of transporting both Gigabit =
> > > Ethernet and Fiber Channel</FONT>
> > > <BR><FONT SIZE=3D2>(as an example), if provisioning was based on =
> > > signalling that could only</FONT>
> > > <BR><FONT SIZE=3D2>support Gigabit Ethernet?</FONT>
> > > </P>
> > >
> > > <P><FONT SIZE=3D2>This is a restriction for every provider regardless =
> > > of whether a network is</FONT>
> > > <BR><FONT SIZE=3D2>a standalone one built for a large customer or a =
> > > national network serving</FONT>
> > > <BR><FONT SIZE=3D2>multiple customers. The effective 'banning' of =
> > > certain services that are</FONT>
> > > <BR><FONT SIZE=3D2>currently being offered by providers will =
> > > unnecessarily damage the business</FONT>
> > > <BR><FONT SIZE=3D2>case for the adoption of GMPLS.</FONT>
> > > </P>
> > > <BR>
> > > <BR>
> > >
> > > <P><FONT SIZE=3D2>> At the same time, it is important to keep in =
> > > mind that being "all</FONT>
> > > <BR><FONT SIZE=3D2>> things for all people" (aka as =
> > > "perfect solution") is one of the</FONT>
> > > <BR><FONT SIZE=3D2>> *non-goals* of GMPLS. So, it shouldn't come as =
> > > a surprise if for a</FONT>
> > > <BR><FONT SIZE=3D2>> *particular* provider GMPLS would *not* support
> > =
> > > *all* the services</FONT>
> > > <BR><FONT SIZE=3D2>> that this provider runs on its transport =
> > > network.</FONT>
> > > <BR><FONT SIZE=3D2>> </FONT>
> > > <BR><FONT SIZE=3D2>> Yakov.</FONT>
> > > <BR><FONT SIZE=3D2>> </FONT>
> > > <BR><FONT SIZE=3D2>> </FONT>
> > > <BR> <FONT =
> > > SIZE=3D2>[Shehzad]</FONT>
> > > <BR> <FONT SIZE=3D2>There is =
> > > no technical reason why a GMPLS encoding type could not be</FONT>
> > > <BR><FONT SIZE=3D2>adopted for a recognised format such as Fiber =
> > > Channel, as far as I am aware</FONT>
> > > <BR><FONT SIZE=3D2>the adoption of Fiber Channel is not likely to =
> > > destroy the foundations of</FONT>
> > > <BR><FONT SIZE=3D2>GMPLS.</FONT>
> > > </P>
> > >
> > > <P> <FONT SIZE=3D2>On a more =
> > > general point, is the support of transport technologies</FONT>
> > > <BR><FONT SIZE=3D2>within GMPLS signalling restricted to those that the
> > =
> > > authors of the GMPLS</FONT>
> > > <BR><FONT SIZE=3D2>drafts will allow? </FONT>
> > > <BR> <FONT SIZE=3D2> =
> > > </FONT>
> > > </P>
> > > <BR>
> > > <BR>
> > > <BR>
> > > <BR>
> > >
> > > <P><FONT SIZE=3D2>> > Monica A. Lazer</FONT>
> > > <BR><FONT SIZE=3D2>> > Advanced Transport Technology and =
> > > Architecture Planning</FONT>
> > > <BR><FONT SIZE=3D2>> > </FONT>
> > > <BR><FONT SIZE=3D2>> > 908 234 8462</FONT>
> > > <BR><FONT SIZE=3D2>> > mlazer@att.com</FONT>
> > > <BR><FONT SIZE=3D2>> > </FONT>
> > > <BR><FONT SIZE=3D2>> > </FONT>
> > > <BR><FONT SIZE=3D2>> > -----Original Message-----</FONT>
> > > <BR><FONT SIZE=3D2>> > From: =
> > > Dimitri Papadimitriou</FONT>
> > > <BR><FONT SIZE=3D2>> [<A =
> > >
> > HREF=3D"mailto:dimitri.papadimitriou@alcatel.be";>mailto:dimitri.papadimi=
> > > triou@alcatel.be</A>]</FONT>
> > > <BR><FONT SIZE=3D2>> </FONT>
> > > <BR><FONT SIZE=3D2>> > Sent: =
> > > Monday, October 22, 2001 3:15 PM</FONT>
> > > <BR><FONT SIZE=3D2>> > To: Lazer, Monica A, NNAD</FONT>
> > > <BR><FONT SIZE=3D2>> > Cc: Ewart Tempest; lberger@movaz.com; =
> > > ccamp@ops.ietf.org</FONT>
> > > <BR><FONT SIZE=3D2>> > Subject: Re: Generalized
> > =
> > > Signaling - LSP Encoding Type expansion</FONT>
> > > <BR><FONT SIZE=3D2>> > </FONT>
> > > <BR><FONT SIZE=3D2>> > << File: Card for Dimitri =
> > > Papadimitriou >> Hi Monica,</FONT>
> > > <BR><FONT SIZE=3D2>> > </FONT>
> > > <BR><FONT SIZE=3D2>> > Fine. Now we know the following: GMPLS is =
> > > really attractive for </FONT>
> > > <BR><FONT SIZE=3D2>> > carriers when it supports all transport =
> > > technologies so it has </FONT>
> > > <BR><FONT SIZE=3D2>> > to support Fiber Channel as well.</FONT>
> > > <BR><FONT SIZE=3D2>> > </FONT>
> > > <BR><FONT SIZE=3D2>> > I wasn't aware that Ewart was capable to =
> > > read in your mind ;-)</FONT>
> > > <BR><FONT SIZE=3D2>> > </FONT>
> > > <BR><FONT SIZE=3D2>> > Regards,</FONT>
> > > <BR><FONT SIZE=3D2>> > Dimitri.</FONT>
> > > <BR><FONT SIZE=3D2>> > </FONT>
> > > <BR><FONT SIZE=3D2>> > "Lazer, Monica A, NNAD" =
> > > wrote:</FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > Dimitri,</FONT>
> > > <BR><FONT SIZE=3D2>> > > I am just answering the PS question =
> > > with this message.</FONT>
> > > <BR><FONT SIZE=3D2>> > > The short answer is yes. The =
> > > long answer is that the GMPLS control</FONT>
> > > <BR><FONT SIZE=3D2>> plane</FONT>
> > > <BR><FONT SIZE=3D2>> > is</FONT>
> > > <BR><FONT SIZE=3D2>> > > really useful if it can support =
> > > connection management for all the</FONT>
> > > <BR><FONT SIZE=3D2>> > transport</FONT>
> > > <BR><FONT SIZE=3D2>> > > services supported by the transport =
> > > network using GMPLS. Therefore,</FONT>
> > > <BR><FONT SIZE=3D2>> the</FONT>
> > > <BR><FONT SIZE=3D2>> > > carrier services section for the NNI =
> > > document to be posted on the OIF</FONT>
> > > <BR><FONT SIZE=3D2>> site</FONT>
> > > <BR><FONT SIZE=3D2>> > > within a few minutes and the next =
> > > draft of the carrier requirements</FONT>
> > > <BR><FONT SIZE=3D2>> IETF</FONT>
> > > <BR><FONT SIZE=3D2>> > > draft will both contain references to
> > =
> > > support of Fiber Channel.</FONT>
> > > <BR><FONT SIZE=3D2>> > > Regards,</FONT>
> > > <BR><FONT SIZE=3D2>> > > Monica A. Lazer</FONT>
> > > <BR><FONT SIZE=3D2>> > > Advanced Transport Technology and =
> > > Architecture Planning</FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > 908 234 8462</FONT>
> > > <BR><FONT SIZE=3D2>> > > mlazer@att.com</FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > -----Original =
> > > Message-----</FONT>
> > > <BR><FONT SIZE=3D2>> > > From: Dimitri =
> > > Papadimitriou</FONT>
> > > <BR><FONT SIZE=3D2>> [<A =
> > >
> > HREF=3D"mailto:dimitri.papadimitriou@alcatel.be";>mailto:dimitri.papadimi=
> > > triou@alcatel.be</A>]</FONT>
> > > <BR><FONT SIZE=3D2>> > > Sent: Monday, October 22,
> > =
> > > 2001 2:47 PM</FONT>
> > > <BR><FONT SIZE=3D2>> > > To: Ewart =
> > > Tempest</FONT>
> > > <BR><FONT SIZE=3D2>> > > Cc: =
> > > lberger@movaz.com; ccamp@ops.ietf.org</FONT>
> > > <BR><FONT SIZE=3D2>> > > =
> > > Subject: Re: Generalized =
> > > Signaling - LSP Encoding Type</FONT>
> > > <BR><FONT SIZE=3D2>> expansion</FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > << File: Card for Dimitri
> > =
> > > Papadimitriou >> Hi Ewart,</FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > If you take a look on the IEEE =
> > > Standards you will see</FONT>
> > > <BR><FONT SIZE=3D2>> > > that GE is referred to as</FONT>
> > > <BR><FONT SIZE=3D2>> > > - 802.3z for 1Gbps (see below [1]) =
> > > same exists for copper 802.3ab</FONT>
> > > <BR><FONT SIZE=3D2>> > > - 802.3ae for 10Gbps (see below =
> > > [2])</FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > So my question is what do you have in
> > =
> > > mind ? to separate</FONT>
> > > <BR><FONT SIZE=3D2>> > > these values ?</FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > Thanks,</FONT>
> > > <BR><FONT SIZE=3D2>> > > Dimitri.</FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > PS: for FiberChannel sorry i am not =
> > > an expert but is someone</FONT>
> > > <BR><FONT SIZE=3D2>> > > targeting to =
> > > use GMPLS for FiberChannel LSP ?</FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > -------</FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > [1] From - <A =
> > > HREF=3D"http://standards.ieee.org"; =
> > > TARGET=3D"_blank">http://standards.ieee.org</A></FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > Project scope: Define Carrier Sense =
> > > Multiple Access with Collision</FONT>
> > > <BR><FONT SIZE=3D2>> > > Detection (CSMA/CD) Media Access =
> > > Control (MAC) parameters and minimal</FONT>
> > > <BR><FONT SIZE=3D2>> > > augmentation of its operation, =
> > > physical layer characteristics,</FONT>
> > > <BR><FONT SIZE=3D2>> repeater</FONT>
> > > <BR><FONT SIZE=3D2>> > > functions and management parameters =
> > > for transfer of 802.3 and Ethernet</FONT>
> > > <BR><FONT SIZE=3D2>> > > format frames at 1,000 Mb/s.</FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > Project purpose: The purpose of this =
> > > project is to extend the 802.3</FONT>
> > > <BR><FONT SIZE=3D2>> > > protocol to an operating speed of =
> > > 1,000 Mb/s in order to provide a</FONT>
> > > <BR><FONT SIZE=3D2>> > > significant increase in bandwidth =
> > > while maintaining maximum</FONT>
> > > <BR><FONT SIZE=3D2>> > > compatibility</FONT>
> > > <BR><FONT SIZE=3D2>> > > with the installed base of CSMA/CD =
> > > nodes, previous investment in</FONT>
> > > <BR><FONT SIZE=3D2>> > > research</FONT>
> > > <BR><FONT SIZE=3D2>> > > and development, and principles of =
> > > network operation and management.</FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > [2] From - <A =
> > > HREF=3D"http://standards.ieee.org"; =
> > > TARGET=3D"_blank">http://standards.ieee.org</A></FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > Project scope: Define 802.3 Media =
> > > Access Control (MAC) parameters and</FONT>
> > > <BR><FONT SIZE=3D2>> > > minimal augmentation of its =
> > > operation, physical layer characteristics</FONT>
> > > <BR><FONT SIZE=3D2>> > > and management parameters for =
> > > transfer of LLC and Ethernet format</FONT>
> > > <BR><FONT SIZE=3D2>> > > frames at 10 Gb/s using full duplex =
> > > operation as defined in the 802.3</FONT>
> > > <BR><FONT SIZE=3D2>> > > standard. In addition to the =
> > > traditional LAN space, add parameters and</FONT>
> > > <BR><FONT SIZE=3D2>> > > mechanisms that enable deployment of =
> > > Ethernet over the Wide Area</FONT>
> > > <BR><FONT SIZE=3D2>> Network</FONT>
> > > <BR><FONT SIZE=3D2>> > > operating at a data rate compatible =
> > > with OC-192c and SDH VC-4-64c</FONT>
> > > <BR><FONT SIZE=3D2>> > > payload</FONT>
> > > <BR><FONT SIZE=3D2>> > > rate.</FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > Project purpose: The purpose of this =
> > > project is to extend the 802.3</FONT>
> > > <BR><FONT SIZE=3D2>> > > protocol to an operating speed of 10 =
> > > Gb/s and to expand the Ethernet</FONT>
> > > <BR><FONT SIZE=3D2>> > > application space to include Wide =
> > > Area Network links in order to</FONT>
> > > <BR><FONT SIZE=3D2>> provide</FONT>
> > > <BR><FONT SIZE=3D2>> > > a significant increase in bandwidth =
> > > while maintaining maximum</FONT>
> > > <BR><FONT SIZE=3D2>> > > compatibility</FONT>
> > > <BR><FONT SIZE=3D2>> > > with the installed base of 802.3 =
> > > interfaces, previous investment in</FONT>
> > > <BR><FONT SIZE=3D2>> > > research</FONT>
> > > <BR><FONT SIZE=3D2>> > > and development, and principles of =
> > > network operation and management.</FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > -------</FONT>
> > > <BR><FONT SIZE=3D2>> > > </FONT>
> > > <BR><FONT SIZE=3D2>> > > > Ewart Tempest wrote:</FONT>
> > > <BR><FONT SIZE=3D2>> > > ></FONT>
> > > <BR><FONT SIZE=3D2>> > > > Lou,</FONT>
> > > <BR><FONT SIZE=3D2>> > > ></FONT>
> > > <BR><FONT SIZE=3D2>> > > > Within section 3.1.1 of =
> > > draft-ietf-mpls-generalized-signaling-06 can</FONT>
> > > <BR><FONT SIZE=3D2>> > > > you please add additonal LSP =
> > > Encoding Types for GE and FiberChannel.</FONT>
> > > <BR><FONT SIZE=3D2>> > > > GE is not really covered by the =
> > > existing Ethernet related encoding</FONT>
> > > <BR><FONT SIZE=3D2>> > > > types, and FiberChannel is not =
> > > covered at all. Thanks.</FONT>
> > > <BR><FONT SIZE=3D2>> > > ></FONT>
> > > <BR><FONT SIZE=3D2>> > > > Ewart</FONT>
> > > <BR><FONT SIZE=3D2>> > </FONT>
> > > </P>
> > >
> > > </BODY>
> > > </HTML>
> > > ------_=_NextPart_001_01C15BCA.5A2A5650--