Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: AW: [EFM] PON Optics Telephone Conference, December 5th





Richard,

OK, we agree that the CIOs and network architects purchse/select offerings
from the options that are provided by providers who are heavily influenced
by their CTOs, as to what options they put forth, who in at least part of
the market are sensitive to their customers desires.

So I would agree with Jonathan that there are quite a number of CIOs and
network architects who are fundamentally looking for the option of using
their MAN/WAN access link in exactly the same way as their LAN technologies.
Interestingly I found that the (high bandwidth) market split between those
who were architecting from the point of view of connecting servers and LAN
based apps (heavily focused on "this has got to be Ethernet" to the point
they will wrap up T-1s to look like Ethernet) and those who were
architecting from the point of view of interconnecting routers (focused on
cost per bit and just being able to get at the service at all).

Significantly though, and I took this to be his main point, is that from the
provider CTO point of view you cannot get there for either of these
customers unless you get the one L2 technology with the Ethernet
characteristic. [Unfortunately for you all, IMHO, the support OpEx runs
right through the way that most carrier OSS's are put together, so the
benefit of bolting Ethernet on to an existing offering portfolio without the
opportunity of redoing the OSS on much simpler lines is dubious at best.
Further the demise (or radical shrinkage) of the high bandwidth server
connect space is eroding what use to be the most marvellous aspect of
selling into this space - that you could sell pure high bandwidth data
without having to convert or converge any of the existing services onto the
new link, and indeed that's what the customer wanted.]

I cannot see the need for 802.3 to compete with the MEF and the ITU by
attempting to adopt the prejudices and predilictions that these groups
already have. If 802.3 stops being a LAN group and starts being a something
else there is absolutely no reason why it should be better at the job than
anyone else. Jonathan makes the case for equipping the provider with a
LAN-like L2 solution, and from an overall perspective I believe it would be
a good thing if 802.3 took its very best shot at developing that solution
unless it wants to cede that space to someone else **!! instead of chasing
some uncertain money from the incumbents who already have their own tame
standards groups.

Mick




> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Richard
> Brand
> Sent: Sunday, December 22, 2002 11:58 PM
> To: mick_seaman@ieee.org
> Cc: stds-802-3-efm@ieee.org
> Subject: Re: AW: [EFM] PON Optics Telephone Conference, December 5th
>
>
> Mick:
> 'Tis the season to be jolly so Ho Ho Ho, this is what
> Jonathan said and he and I
> will discuss it in Vancouver.  You are welcome to join if you
> are so inclined or
> stop me when we run into each other again at Whole Foods
> whenever you are in
> Palo Alto.  JT's words,  "I know CIOs and network architects
> that plan to make
> it so" referring to .3ah as a "LAN product technology".  The
> term "number of
> provider CTO's" appears in a differnet context much further
> down in his note.
> Big difference.
> Happy holidays,
> Richard
> > >
>
> Mick Seaman wrote:
>
> > Richard,
> >
> > Jonathan didn't say CIOs and enterprise network architects,
> he said provider
> > CTOs. There is a big difference, and it makes a big
> difference to your
> > reply.
> >
> > Mick
> >
> > > -----Original Message-----
> > > From: owner-stds-802-3-efm@majordomo.ieee.org
> > > [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf
> Of Richard
> > > Brand
> > > Sent: Friday, December 13, 2002 11:47 PM
> > > To: Jonathan Thatcher
> > > Cc: stds-802-3-efm@ieee.org; Bottorff, Paul [SC2:470:EXCH]; Geoff
> > > Thompson; Rodney Wilson; John Watkins; Milan Vlajnic
> > > Subject: Re: AW: [EFM] PON Optics Telephone Conference,
> December 5th
> > >
> > >
> > > Jonathan:
> > > I am surprised at your response to Roy's challenge,
> > > especially in your position as the Pres. of the EFMA.  Our
> > > documented charter for 802.3ah is "subscriber access
> > > networks" and I definitely don't see that as a LAN solution
> > > or anywhere in the "LAN" domain.  Metro edge, carrier
> > > extension or even LAN extension, but definitely this is not a LAN
> > > as we have defined it for all of these years in our work
> > > within the 802.3 scope.  (Do you want me to mention the
> > > motivation for the MEF?)  Whether or not you agree (I
> > > presuppose), the (802.3ah TF) is now definitely in the
> > > carrier/service provider space and we must consider different
> > > options than we would in the old premise LAN network
> > > segment days.  I would even argue that our larger .3 work
> > > group should take on the issue of something that I am
> > > considering as a future 802.3 concept I will only identify
> > > now as Carrier Ethernet (native 802.3 transport).  Fits with
> > > my history, but more on that later.
> > > Back to Roy's comments, I don't see how CIO's or even network
> > > architects as you so state in your reply will be involved in
> > > this decision about the protocol or selection of "subscriber
> > > access networks" (read EFM).  CIO's and network architects
> > > have a handful of standardized access option choices to chose
> > > from for their large enterprise
> > > businesses.  Roy's comments as I see them pertain to the
> > > subscribers that are the target or focus of our
> > > specifications within 802.3ah so his comments are germane.
> > > What we have to do is, to quote my neighbor Steve, "Think
> > > Differently."  Otherwise, we are inside of the "subscriber
> > > access" space, i.e. back inside the demarc of the enterprise
> > > and we already have plenty of 802.3 specifications at 25
> > > degrees C for this environment.  That leaves the
> > > carrier/service providers with an untenable solution from
> > > 802.3 for their customer requirements and will force them to
> > > migrate to FSAN and other standards bodies for an access solution.
> > > I feel that we face a larger issue which is, are we willing
> > > to secede this standards space to MEF or the ITU?.  So I
> > > recommend that we consider Roy's' issues as a positive input
> > > rather than to dismiss them as irrelevant.  Ethernet as we
> > > know it, whether we like it, is changing.  Let's manage that
> > > migration to our mutual benefit.
> > > Sincerely,
> > > Richard Brand
> > >
> > >
> > >
> > >
> > > Jonathan Thatcher wrote:
> > >
> > > > Roy,
> > > >
> > > > | "802.3ah is not a LAN product technology."
> > > >
> > > > I see no reason why it can't be. I know CIOs and network
> > > architects that plan to make it so.
> > > >
> > > > | "The inherent characteristics of Ethernet as people have
> > > gotten used to them may no longer be there.
> > > >
> > > > Please be specific.
> > > >
> > > > | "It may turn out that Ethernet does not perform any
> > > better than any other protocol.
> > > >
> > > > According to what metrics? Please be specific.
> > > >
> > > > | "It may not save any costs to the service providers in
> > > its implementation, except perhaps to the end customer.
> > > >
> > > > I have quotes from a number of provider CTOs, who would
> > > disagree. The biggest problem they face is OpEx of supporting
> > > 10's of different technologies. They can't wait to get to one
> > > L2 technology, even at the loss of those overpriced legacy
> > > services, which they know will be unaffordable to continue to
> > > service in the not-too-distant future.
> > > >
> > > > Even if this were not true, even if it did cost more to
> > > service providers, as long as the total cost to the customer
> > > declines while "service" improves (even if this means paying
> > > more for services over EFM), isn't that a net win?
> > > >
> > > > I'm sorry. I simply cannot understand what you are talking
> > > about here. I need to know the specifics. Talking in gross
> > > generalities is not helpful.
> > > >
> > > > jonathan
> > > >
> > > > | -----Original Message-----
> > > > | From: Roy Bynum [mailto:rabynum@mindspring.com]
> > > > | Sent: Friday, December 13, 2002 9:38 AM
> > > > | To: Jonathan Thatcher; stds-802-3-efm@ieee.org
> > > > | Subject: RE: AW: [EFM] PON Optics Telephone Conference,
> > > December 5th
> > > > |
> > > > |
> > > > | Jonathan,
> > > > |
> > > > | 802.3ah is not a LAN product technology.  The inherent
> > > > | characteristics of
> > > > | Ethernet as people have gotten used to them may no longer be
> > > > | there.  It may
> > > > | turn out that Ethernet does not perform any better
> than any other
> > > > | protocol.  It may not save any costs to the service
> > > providers in its
> > > > | implementation, except perhaps to the end customer.
> > > > |
> > > > | Thank you,
> > > > | Roy Bynum
> > > > |
> > > > | At 09:23 AM 12/13/2002 -0800, Jonathan Thatcher wrote:
> > > > |
> > > > | >Roy,
> > > > | >
> > > > | >What does "How 802.3ah will perform relative to the "jitter"
> > > > | issue has yet
> > > > | >to be seen.  It is most likely that the data stability that
> > > > | LAN people are
> > > > | >used to will no longer be there" mean?
> > > > | >
> > > > | >Does extending the 5km to 10km impact jitter / data
> stability?
> > > > | >Does adding OAM frames impact jitter / data stability?
> > > > | >Does support of bidirectional rather than dual fiber
> > > > | transceivers impact
> > > > | >jitter / data stability?
> > > > | >Does EDSL solution impact jitter / data stability?
> > > > | >
> > > > | >What, exactly, are you trying to say? That because of EFM,
> > > > | Ethernet is no
> > > > | >longer Ethernet?
> > > > | >
> > > > | >jonathan
> > > > | >
> > > > | >
> > > > | >| -----Original Message-----
> > > > | >| From: Roy Bynum [mailto:rabynum@mindspring.com]
> > > > | >| Sent: Friday, December 13, 2002 8:24 AM
> > > > | >| To: Mccammon, Kent G.; 'Richard Brand'
> > > > | >| Cc: Mccammon, Kent G.; stds-802-3-efm@ieee.org
> > > > | >| Subject: RE: AW: [EFM] PON Optics Telephone Conference,
> > > > | December 5th
> > > > | >|
> > > > | >|
> > > > | >|
> > > > | >| Kent,
> > > > | >|
> > > > | >| Until 802.3ah, Ethernet does not induce any jitter in the
> > > > | >| transmission of
> > > > | >| application data.  I spent over a year in the lab
> looking at
> > > > | >| this.  The
> > > > | >| 802.3 stack, up until now was a pure streaming environment
> > > > | >| without any
> > > > | >| store and forward queues.
> > > > | >|
> > > > | >| This may sound like a bit of heresy as I am the
> original host
> > > > | >| master for
> > > > | >| MCI.  The worst culprit in inducing jitter in the
> > > transmission of
> > > > | >| application data in today's environment is
> Internet Protocol.
> > > > | >|  This occurs
> > > > | >| across all vendor lines using IP stack code from multiple
> > > > | vendors.  I
> > > > | >| believe that it is because the IP stack is fairly
> "deep" and
> > > > | >| there are
> > > > | >| several locations in the stack where some form of
> "store and
> > > > | >| forward" is
> > > > | >| required.  (Even forward looking code does not solve
> > > this problem.)
> > > > | >|
> > > > | >| You can have your lab people verify this.  Testing
> > > applications in
> > > > | >| non-routing environments will change the level of
> jitter that
> > > > | >| introduced in
> > > > | >| the communications infrastructure.  This effect of
> streaming
> > > > | >| switching was
> > > > | >| one of the main reasons that the "legacy free service
> > > > | >| providers" were able
> > > > | >| to deliver packet voice that had better clarity and sound
> > > > | >| quality than the
> > > > | >| local RBOC.  Testing using a non-routing stack such as
> > > > | >| NetBEUI will change
> > > > | >| the amount of jitter that is introduced at the end systems
> > > > | >| supporting the
> > > > | >| applications.  Interactive video becomes very "tight" in a
> > > > | >| non-IP environment.
> > > > | >|
> > > > | >| How 802.3ah will perform relative to the "jitter" issue
> > > > | has yet to be
> > > > | >| seen.  It is most likely that the data stability that LAN
> > > > | >| people are used
> > > > | >| to will no longer be there.
> > > > | >|
> > > > | >| Thank you,
> > > > | >| Roy Bynum
> > > > | >|
> > > > | >|
> > > > | >|
> > > > | >| At 09:30 PM 12/8/2002 -0800, Mccammon, Kent G. wrote:
> > > > | >|
> > > > | >|
> > > > | >| >Richard,
> > > > | >| >Controlling jitter over an Ethernet network is a project
> > > > | >| that we support in
> > > > | >| >other forums than 802.3ah.  My comment and question was
> > > > | >| attempting to
> > > > | >| >gather more information in the debate over common
> PMD timing
> > > > | >| specifications.
> > > > | >| >If the Options A-D in the debate of PON timing have
> > > > | >| different possible
> > > > | >| >services enabled, I think that is a fair question
> to ask on
> > > > | >| this exploder.
> > > > | >| >I don't  support multiple Gigabit PON timing
> specifications
> > > > | >| each one for a
> > > > | >| >only subset of potential service applications.
> > > > | >| >Thanks,
> > > > | >| >-Kent
> > > > | >| >
> > > > | >| > > -----Original Message-----
> > > > | >| > > From: Richard Brand [mailto:rbrand@nortelnetworks.com]
> > > > | >| > > Sent: Friday, December 06, 2002 12:34 PM
> > > > | >| > > To: Roy Bynum
> > > > | >| > > Cc: kmccammon@tri.sbc.com; stds-802-3-efm@ieee.org
> > > > | >| > > Subject: Re: AW: [EFM] PON Optics Telephone Conference,
> > > > | >| December 5th
> > > > | >| > >
> > > > | >| > >
> > > > | >| > > Roy:
> > > > | >| > > So here we go.  I agree with everything you state
> > > except that
> > > > | >| > > Kent did not ask about "Leased Circuit Private
> > > Line services
> > > > | >| > > " or "Ethernet Private Line" but about T1
> services over a
> > > > | >| > > draft 802.3 P2MP network. In addition Ethernet
> private line
> > > > | >| > > or leased line services are just as much out
> of scope for
> > > > | >| > > 802.3 as is TDM based T1 services. That's why
> we have taken
> > > > | >| > > on that work in the MEF with a close liaison to
> > > the ITU work
> > > > | >| > > to which you make reference.  That also gets into
> > > > | >| > > encapsulation, but that is surely out of scope for .3.
> > > > | >| > > Therefore, I am correct in saying that your
> message did not
> > > > | >| > > answer his question.  I do believe Arial's
> note makes an
> > > > | >| > > attempt to address the efficiency question, but I
> > > > | >| > > believe that the potential for added jitter is
> > > real.   It is
> > > > | >| > > however, out of scope
> > > > | >| > > for .3.  Kent, any comments?
> > > > | >| > > Regards,
> > > > | >| > > Richard
> > > > | >| > >
> > > > | >| > >
> > > > | >| > > Roy Bynum wrote:
> > > > | >| > >
> > > > | >| > > > Richard,
> > > > | >| > > >
> > > > | >| > > > You are incorrect. 802.3 in and of itself
> can NOT be used
> > > > | >| > > to provide
> > > > | >| > > > Leased Circuit Private Line services. I am
> the author of
> > > > | >| > > the term and
> > > > | >| > > > definition of "Ethernet Private Line"
> services. Ethernet
> > > > | >| > > Private Line
> > > > | >| > > > is based on SONET/SDH, not 802.3
> > > > | >| > > >
> > > > | >| > > > ITU standards for leased circuit private
> line services
> > > > | >| specifically
> > > > | >| > > > states that the customer of the leased circuit has
> > > > | >| exclusive use of
> > > > | >| > > > the circuit facility. This is in contrast to "packet"
> > > > | >| > > services that do
> > > > | >| > > > emulation via a "virtual" circuit. Since
> 802.3ah PON does
> > > > | >| > > not provides
> > > > | >| > > > virtual circuit emulation via the frame
> > > "header", called a
> > > > | >| > > "preamble"
> > > > | >| > > > by 802.3 and not any type of physical or time based
> > > > | facilities
> > > > | >| > > > segregation, it falls under the category of a
> > > > | >| > > "packet/frame" service
> > > > | >| > > > technology, not a leased circuit service technology.
> > > > | >| > > >
> > > > | >| > > > The existing ITU standards already provides for
> > > > | >| permanent virtual
> > > > | >| > > > circuit emulation at fixed bandwidths over
> packet/cell
> > > > | >| > > based services.
> > > > | >| > > > These can be at T1 or any other fixed bandwidth.  The
> > > > | >| ITU standards
> > > > | >| > > > makes a specific distinction between the
> "leased circuit"
> > > > | >| > > services and
> > > > | >| > > > the emulated circuit services over packet/cell/frame
> > > > | transport
> > > > | >| > > > protocols.
> > > > | >| > > >
> > > > | >| > > > I didn't write the ITU standards. I just
> spent the last
> > > > | >| year that I
> > > > | >| > > > was at Worldcom researching the specifics of defined
> > > > | >| standards for
> > > > | >| > > > different types of data communications services.
> > > > | >| > > >
> > > > | >| > > > 802.3 in and of itself does not provide
> leased circuit
> > > > | >| private line
> > > > | >| > > > services. The fact that a single customer using
> > > 802.3 can be
> > > > | >| > > > provisioned as the only customer on a "dark" fiber,
> > > > | >| makes the dark
> > > > | >| > > > fiber, a leased circuit private line service, not the
> > > > | >| 802.3. This
> > > > | >| > > > format would also hold for 802.3ah copper
> facilities that
> > > > | >| > > are used by
> > > > | >| > > > a single customer.
> > > > | >| > > >
> > > > | >| > > > The service "Ethernet Private Line" is not
> based on an
> > > > | >| > > 802.3 standard,
> > > > | >| > > > other than it provides a "mapping" for Ethernet
> > > frames. The
> > > > | >| > > ITU x.86
> > > > | >| > > > "Ethernet over LAPS" provides for "mapping"
> of Ethernet
> > > > | >| frames into
> > > > | >| > > > SONET/SDH by replacing the IFG/Preamble with
> LAPS, a HDLC
> > > > | >| > > derivative
> > > > | >| > > > and then using TDM nature of SONET/SDH to
> provision the
> > > > | >| > > service as a
> > > > | >| > > > standard leased circuit facility.  This
> would also hold
> > > > | >| for g.GFP.
> > > > | >| > > >
> > > > | >| > > > Thank you,
> > > > | >| > > > Roy Bynum
> > > > | >| > > >
> > > > | >| > > > At 02:40 PM 12/5/2002 -0800, Richard Brand wrote:
> > > > | >| > > > >Thomas:
> > > > | >| > > > >I would offer that Roy's note does not
> answer question 1
> > > > | >| > > and I have
> > > > | >| > > > >sent a note to Roy to detail.  As Kent is
> > > aware, there is
> > > > | >| > > an ongoing
> > > > | >| > > > >project in the MEF right now to specify circuit
> > > > | >| services (read TDM
> > > > | >| > > > >including T1) over Ethernet including 802.3
> networks.
> > > > | >| > > > >The timing issue could be critical to some
> > > implementations
> > > > | >| > > and is one of the
> > > > | >| > > > >reasons I voted "no" in Kauai.  Vipal, do
> you want to
> > > > | >| take it on?
> > > > | >| > > > >Regards,
> > > > | >| > > > >Richard Brand
> > > > | >| > > > >
> > > > | >| > > > >
> > > > | >| > > > >
> > > > | >| > > > >Thomas.Murphy@infineon.com wrote:
> > > > | >| > > > >
> > > > | >| > > > > > Hi Kent,
> > > > | >| > > > > >
> > > > | >| > > > > > Thanks for your input on this topic. I
> believe that
> > > > | >| question 1)
> > > > | >| > > > > > has already been addressed by Roy Bynum;
> there are
> > > > | >| > > others who are
> > > > | >| > > > > > in a better position to answer this than me.
> > > > | >| > > > > >
> > > > | >| > > > > > Regarding testing I see two different
> levels/types
> > > > | >| of testing.
> > > > | >| > > > > > Firstly there is module testing where different
> > > > | >| response times
> > > > | >| > > > > > will not present a problem (the response time is
> > > > | >| > > probably one of
> > > > | >| > > > > > the parameters that would be determined). Beyond
> > > > | >| this there is
> > > > | >| > > > > > then system/interoperability testing. When
> > > testing with
> > > > | >| > > > > 'non-intelligent'
> > > > | >| > > > > > equipment, the guardband between bursts would be
> > > > | set to the
> > > > | >| > > > > > Upper-Bound values agreed upon. By guardband
> > > I mean the
> > > > | >| > > time delay
> > > > | >| > > > > > between the Tx_On signal and the time when the Rx
> > > > | >| > > starts examining
> > > > | >| > > > > > bit to determine the BER. With an intelligent
> > > > | system, i.e.
> > > > | >| > > > > > protocol implementation with negotiated
> parameters,
> > > > | >| > > > > > interoperability is not a problem as the optimal
> > > > | >| > > guardband is calculated.
> > > > | >| > > > > >
> > > > | >| > > > > > The above tests determine if one Tx communicates
> > > > | >| optically with
> > > > | >| > > > > > the
> > > > | >| > > > > expected
> > > > | >| > > > > > BER
> > > > | >| > > > > > with another Rx. Setting the guardband
> equal to the
> > > > | >| upper limit
> > > > | >| > > > > > determines that the timing requirements of
> > > the combined
> > > > | >| > > link are
> > > > | >| > > > > > met. Direct module testing delivers the
> > > > | individual Rx and Tx
> > > > | >| > > > > > times.  Hence, I don't see a problem with testing
> > > > | >| > > depending on the
> > > > | >| > > > > > option choice for the timing parameters.
> > > > | >| > > > > >
> > > > | >| > > > > > Regards
> > > > | >| > > > > >
> > > > | >| > > > > > Tom
> > > > | >| > > > > >
> > > > | >| > > > > > -----Ursprüngliche Nachricht-----
> > > > | >| > > > > > Von: Mccammon, Kent G.
> [mailto:kmccammon@tri.sbc.com]
> > > > | >| > > Gesendet am:
> > > > | >| > > > > > Donnerstag, 5. Dezember 2002 02:45
> > > > | >| > > > > > An: Murphy Thomas (COM FO D O);
> > > stds-802-3-efm@ieee.org;
> > > > | >| > > > > > Vipul_Bhatt@ieee.org; wdiab@cisco.com
> > > > | >| > > > > > Betreff: RE: [EFM] PON Optics Telephone
> Conference,
> > > > | >| December 5th
> > > > | >| > > > > >
> > > > | >| > > > > > Tom,
> > > > | >| > > > > > Since I have a conflict with the call
> > > tomorrow and I am
> > > > | >| > > interested
> > > > | >| > > > > > in this decision, here are some questions.
> > > > | >| > > > > >
> > > > | >| > > > > > 1)Do any of the options for PON timing impact the
> > > > | >| delivery of
> > > > | >| > > > > > services such as toll quality voice, a T1,
> > > or multicast
> > > > | >| > > video? We
> > > > | >| > > > > > had this concern previously and the
> answer previously
> > > > | >| > > was claimed
> > > > | >| > > > > > to be only an efficiency hit for loose
> timing. Are
> > > > | >| the modeling
> > > > | >| > > > > > assumptions to compare efficiency valid for TDM
> > > > | >| services or is
> > > > | >| > > > > > that not a consideration in this debate to
> > > date? 2)The
> > > > | >| > > negotiation
> > > > | >| > > > > > of timing parameters rather than a tight
> > > > | >| specification have any
> > > > | >| > > > > > impact on future interoperability testing?
> > > If we ever
> > > > | >| > > decide to
> > > > | >| > > > > > test interoperability of EPON OLT and ONT, can a
> > > > | lab testing
> > > > | >| > > > > > system be reasonably built to test
> compliance to a
> > > > | >| > > specification
> > > > | >| > > > > > for OLT/ONT timing for the various options under
> > > > | >| debate? 3)Do
> > > > | >| > > > > > operating temperature swings have an
> impact on timing
> > > > | >| > > options. Is
> > > > | >| > > > > their
> > > > | >| > > > > > reason to add extra margin or extra negotiation
> > > > | >| time of timing
> > > > | >| > > > > > parameters due to temperature
> variations? What about
> > > > | >| > > cold start in
> > > > | >| > > > > > cold temperatures, that was an issue for power
> > > > | >| levels, does it
> > > > | >| > > > > > also impact the electronics of the PMD?
> > > > | >| > > > > >
> > > > | >| > > > > > Comment: As an advocate of PON
> technologies I echo
> > > > | >| my earlier
> > > > | >| > > > > > comments
> > > > | >| > > > > about
> > > > | >| > > > > > striving for common PON PMD to get the volume
> > > > | >| started in today's
> > > > | >| > > > > economy.  I
> > > > | >| > > > > > am optimistic a compromise can be found in
> > > > | January. Thanks,
> > > > | >| > > > > > -Kent
> > > > | >| > > > > >
> > > > | >| > > > > > > -----Original Message-----
> > > > | >| > > > > > > From: Thomas.Murphy@infineon.com
> > > > | >| > > > > > > [mailto:Thomas.Murphy@infineon.com]
> > > > | >| > > > > > > Sent: Wednesday, December 04, 2002 10:12 AM
> > > > | >| > > > > > > To: stds-802-3-efm@ieee.org;
> Vipul_Bhatt@ieee.org;
> > > > | >| > > wdiab@cisco.com
> > > > | >| > > > > > > Subject: [EFM] PON Optics Telephone Conference,
> > > > | >| December 5th
> > > > | >| > > > > > >
> > > > | >| > > > > > >
> > > > | >| > > > > > > Hello Again,
> > > > | >| > > > > > >
> > > > | >| > > > > > > Attacted two possible approaches to
> this discussion
> > > > | >| > > forming two
> > > > | >| > > > > > > decision trees. Glen and I worked on these I I
> > > > | >| did not have a
> > > > | >| > > > > > > chance to co-ordinate with him and
> refine to one
> > > > | >| slide.  The
> > > > | >| > > > > > > first slide is mine and I would like to
> > > start here as
> > > > | >| > > it allows
> > > > | >| > > > > > > us to generate values without having to make
> > > > | >| > > decisions. When the
> > > > | >| > > > > > > values are agreed upon, we can work towards the
> > > > | >| decision and
> > > > | >| > > > > > > perhaps this is simpler with the
> values we have.
> > > > | >| > > > > > >
> > > > | >| > > > > > > If this does not work, we can try the seconf
> > > > | slide, Glen's
> > > > | >| > > > > > > approach, which is a more top-down attack.
> > > > | >| > > > > > >
> > > > | >| > > > > > > Talk to you tomorrow
> > > > | >| > > > > > >
> > > > | >| > > > > > > Tom
> > > > | >| > > > > > >
> > > > | >| > > > > > >  <<PON Timing Decision Tree.ppt>>
> > > > | >| > > > > > >
> > > > | >| > > > > > > Hello All,
> > > > | >| > > > > > >
> > > > | >| > > > > > > Items to Be Covered
> > > > | >| > > > > > >
> > > > | >| > > > > > > 1)  Determine the exact meaning of the
> terms "Fixed
> > > > | >| > > Value" and
> > > > | >| > > > > > > 'Upper Bound" in terms
> > > > | >| > > > > > >     of their use for PMD timing parameters.
> > > > | >| > > > > > >
> > > > | >| > > > > > > 2)  Try assign placeholder values for all of
> > > > | the options
> > > > | >| > > > > > >
> > > > | >| > > > > > > 3)  Are these values fixed or bounded for the
> > > > | >| > > different options.
> > > > | >| > > > > > >
> > > > | >| > > > > > > 4)  Other items
> > > > | >| > > > > > >
> > > > | >| > > > > > > Regards
> > > > | >| > > > > > >
> > > > | >| > > > > > > Tom
> > > > | >| > > > > > >
> > > > | >| > > > > > >
> > > > | >| > > > > > >
> > > > | >| > > > > > >
> > > > | >| > > > > > >
> > > > | >| > > > > > >
> > > > | >| > > > > > >
> > > > | >| > > > > > >
> > > > | >| > > > > > >
> > > > | >| > > > > > >
> > > > | >| > > > > > >
> > > > | >| > > > > > >
> > > > | >| > > > > > >
> > > > | >| > >
> > > > | >|
> > > > | >|
> > > > |
> > > > |
> > >
>