RE: AW: [EFM] PON Optics Telephone Conference, December 5th
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@xxxxxxxxxxxxxx]
> > | 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@xxxxxxxxxxxxxx]
> > | >| 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@xxxxxxxxxxxxxxxxxx]
> > | >| > > 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@xxxxxxxxxxxx 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@xxxxxxxxxxx]
> > | >| > > Gesendet am:
> > | >| > > > > > Donnerstag, 5. Dezember 2002 02:45
> > | >| > > > > > An: Murphy Thomas (COM FO D O);
> stds-802-3-efm@ieee.org;
> > | >| > > > > > Vipul_Bhatt@xxxxxxxx; wdiab@xxxxxxxxx
> > | >| > > > > > 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@xxxxxxxxxxxx
> > | >| > > > > > > [mailto:Thomas.Murphy@xxxxxxxxxxxx]
> > | >| > > > > > > Sent: Wednesday, December 04, 2002 10:12 AM
> > | >| > > > > > > To: stds-802-3-efm@ieee.org; Vipul_Bhatt@ieee.org;
> > | >| > > wdiab@xxxxxxxxx
> > | >| > > > > > > 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
> > | >| > > > > > >
> > | >| > > > > > >
> > | >| > > > > > >
> > | >| > > > > > >
> > | >| > > > > > >
> > | >| > > > > > >
> > | >| > > > > > >
> > | >| > > > > > >
> > | >| > > > > > >
> > | >| > > > > > >
> > | >| > > > > > >
> > | >| > > > > > >
> > | >| > > > > > >
> > | >| > >
> > | >|
> > | >|
> > |
> > |
>