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

RE: [EFM] OAM - Faye's seven points




Andrew,

There is a time for everything.  Right now is not the time.  There are 
other, more fundamental issues that need to be addressed.  As I have time, 
I will be doing presentations on various OAM functions that need to be 
covered.  There also needs to be an opportunity for others to use their 
imaginations.

Thank you,
Roy Bynum


At 05:48 PM 9/24/01 -0700, Andrew Smith wrote:

>Roy,
>
>I think you misunderstand my intent. You know far more than I do about the
>services that you want to deploy and their OAM requirements. I am trying to
>goad you into sharing your experience but you do not seem to want to do so.
>I guess that's the end of this thread then.
>
>Respectfully,
>
>Andrew Smith
>
>-----Original Message-----
>From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
>Sent: Monday, September 24, 2001 5:13 PM
>To: ah_smith@xxxxxxxxxxx
>Cc: stds-802-3-efm
>Subject: RE: [EFM] OAM - Faye's seven points
>
>
>Andrew,
>
>By your attitude, I take it that you do not want be able to support a wide
>diversity of applications.  I suppose that you want to limit the service
>deployment of EFM and the market that it might achieve.  I guess that you
>want limited Ethernet services that can only support IP services and do not
>want to see an expansion of the service models that can be achieved with
>Ethernet.   In stead of trying to goad me, why don't you start to enumerate
>all of the services, from "Private Line" to interactive Video calling that
>you can think of, and define the service/operations overhead that each
>would need.  Perhaps then, something productive will come of this thread.
>
>Thank you,
>Roy Bynum
>
>At 03:47 PM 9/24/01 -0700, Andrew Smith wrote:
> >Roy,
> >
> >Well, if you won't take the time to quantify the requirement, I think
>you'll
> >have a hard time convincing this committee to adopt what you propose.
> >
> >Andrew Smith
> >
> >
> >-----Original Message-----
> >From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> >Sent: Monday, September 24, 2001 2:19 PM
> >To: ah_smith@xxxxxxxxxxx
> >Cc: stds-802-3-efm
> >Subject: RE: [EFM] OAM - Faye's seven points
> >
> >
> >Andrew,
> >
> >What amount of OAM bandwidth per user would a copper local loop at 2mbps
> >revenue bandwidth rate need?  How would having different services models
> >change that OAM bandwidth?  These are questions that can be "nit-picked" to
> >death.  This is very early in this process to trying to get to this level
> >of detail for each and every potential type of service and deployment
> >architecture model that can be imagined.  I can think of quite a few
> >variations myself, that I will not take time to enumerate here,  one, I
> >don't have the time, secondly, because I think the different vendors will
> >want to do that themselves.  I am attempting to find a reasonable answer
> >that will cover as many of the variations of services and topologies as
> >possible.  I am sorry that you do not seem to agree with that approach.
> >
> >Thank you,
> >Roy Bynum
> >
> >At 01:57 PM 9/24/01 -0700, Andrew Smith wrote:
> > >Roy,
> > >
> > >I'm still not clear whether you are arguing that the OAM rate should be
> > >proportional to the line rate (I think you said 0.1% in your slides) or
> > >whether you propose an absolute value(you write 1 Mbps below). I haven't
> > >seen any argument in support of the OAM needs increasing in proportion to
> > >the line rate. Terms like "very low" and "reasonable" are hard to judge
>and
> > >"tends to provide for a wide diversity of services and infrastructure
> > >topologies" sounds very nebulous: how about some hard data?
> > >
> > >Andrew Smith
> > >
> > >-----Original Message-----
> > >From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> > >Sent: Monday, September 24, 2001 12:36 PM
> > >To: ah_smith@xxxxxxxxxxx
> > >Cc: stds-802-3-efm
> > >Subject: RE: [EFM] OAM - Faye's seven points
> > >
> > >
> > >Andrew,
> > >
> > >OAM bandwidth can be very low for simple, single treaded services such as
> > >Internet access.  For diverse multiple services the OAM bandwidth needs
>to
> > >be relatively high.  If history is any guide, whatever we do, it will not
> > >be enough long term.  At present, what we should be looking for is a
> > >reasonable balance of OAM overhead to revenue bandwidth.  In my
> > >presentation http://www.ieee802.org/3/efm/public/sep01/bynum_2_0901.pdf,
>I
> > >suggested an overhead bandwidth of about 1 Mbps for a revenue bandwidth
>of
> > >1Gbps.  I believe that to be a reasonable amount of OAM bandwidth.  It
> > >tends to provide for a wide diversity of services and infrastructure
> > >topologies.  Does it need to more than that?
> > >
> > >Thank you,
> > >Roy Bynum
> > >
> > >At 06:59 PM 9/21/01 -0700, Andrew Smith wrote:
> > >
> > > >Roy,
> > > >
> > > >Well, you can't choose "all of the above": what do you think is the
>right
> > > >interval for your OAM needs and why? It wasn't meant as a rhetorical
> > > >question.
> > > >
> > > >Andrew Smith
> > > >
> > > >
> > > >-----Original Message-----
> > > >From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> > > >Sent: Friday, September 21, 2001 6:18 PM
> > > >To: ah_smith@xxxxxxxxxxx
> > > >Cc: stds-802-3-efm
> > > >Subject: RE: [EFM] OAM - Faye's seven points
> > > >
> > > >
> > > >Andrew,
> > > >
> > > >Yes to all of the below.  If by a "scheduler" you are referring to
>"every
> >x
> > > >'revenue whatever' an 'OAM whatever' is inserted regardless of whatever
> >is
> > > >happening and without effecting whatever is happening in the 'revenue
> > > >whatever' and the 'OAM whatever' is not effected by the 'revenue
> > >whatever'".
> > > >
> > > >Thank you,
> > > >Roy Bynum
> > > >
> > > >At 06:31 PM 9/21/01 -0700, Andrew Smith wrote:
> > > > >Roy,
> > > > >
> > > > >You're not being clear: when you say "constant", over what interval
>do
> > >you
> > > > >measure: one Frame? one Byte? one Bit? the time it takes for an
> >electron
> > >to
> > > > >jump from one atomic orbit to another? It doesn't matter which one of
> > >these
> > > > >you choose, you still need a *scheduler* to put the bits of your
> >message
> > >(I
> > > > >assume that your OAM messages are more than one bit long) onto the
> > >medium.
> > > > >
> > > > >Andrew Smith
> > > > >
> > > > >P.S. Please let me buy you lunch someday.
> > > > >
> > > > >-----Original Message-----
> > > > >From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> > > > >Sent: Friday, September 21, 2001 5:46 PM
> > > > >To: ah_smith@xxxxxxxxxxx
> > > > >Cc: stds-802-3-efm
> > > > >Subject: RE: [EFM] OAM - Faye's seven points
> > > > >
> > > > >
> > > > >Andrew,
> > > > >
> > > > >A "side band" is a constant bandwidth facility.  Most of what you are
> > > > >referring to only would apply to an in-band, "frame" based OAM.  It
> >does
> > > > >not apply to a "side band" OAM channel.
> > > > >
> > > > >Thank you,
> > > > >Roy Bynum
> > > > >
> > > > >At 05:53 PM 9/21/01 -0700, Andrew Smith wrote:
> > > > > >Roy,
> > > > > >
> > > > > >I think we're talking past each other here (see Tony's lunchtime
> > > >comment).
> > > > > >
> > > > > >Implementation of a "side-band" channel *requires* a scheduler and
> > > >queueing
> > > > > >of its own. The side-band method is the one that adds the unneeded
> > > > > >complexity by mandating an additional scheduler on top of the ones
> >used
> > > >by
> > > > > >higher layers that (in any reasonably designed piece of EFM gear)
> >will
> > > > > >already be present.
> > > > > >
> > > > > >I challenge this group to come up with appropriate dimensions for
> >such
> > >a
> > > > > >side-band channel - what peak or sustained bandwidth? what burst
> > >size? -
> > > > > >that does not cause EFM to become an evolutionary dead-end.
> > > > > >
> > > > > >Andrew Smith
> > > > > >
> > > > > >
> > > > > >
> > > > > >-----Original Message-----
> > > > > >From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> > > > > >Sent: Friday, September 21, 2001 3:53 PM
> > > > > >To: ah_smith@xxxxxxxxxxx; Tony Jeffree
> > > > > >Cc: stds-802-3-efm
> > > > > >Subject: RE: [EFM] OAM - Faye's seven points
> > > > > >
> > > > > >
> > > > > >Andrew,
> > > > > >
> > > > > >What you are referring to in the need for "sort of token bucket
> > > > > >scheduler",  and "...want to allow the OAM "channel" an unfair
> > >advantage
> > > >in
> > > > > >the use of spare bandwidth too, implying some sort of priority in
>the
> > > > > >scheduler" would only apply if the OAM were "frame" based.  If the
> >OAM
> > > >were
> > > > > >a "side band", or "out-of-band" to the revenue traffic, the all of
> >that
> > > > > >complexity is unneeded.
> > > > > >
> > > > > >With an OAM "out-of-band" channel, the OAM bandwidth is
>predetermined
> > >by
> > > > > >the bandwidth of the "side band" data.  It would also not interfere
> > >with
> > > > > >the revenue bandwidth.
> > > > > >
> > > > > >Thank you,
> > > > > >Roy Bynum