RE: [EFM] OAM - Faye's seven points
Roy -
So let me be clear about what you are saying here - the requirement for
side-band management is purely a marketing issue, and not based on any
technical argument? or am I misinterpreting your words?
Regards,
Tony
At 13:34 25/09/2001 -0500, Roy Bynum wrote:
>Tony,
>
>As to a market potential issue, in the high margin business service
>environment, private line, which does require a "side-band" management, is
>about a 4 to 1 market over "shared" services. In the cost of deployment,
>some economic models are showing that new technology "side band" managed
>TDM is less expensive per megabit and per port than new statistical
>multiplexing technology that is trying to service the same customers. The
>first market for EFM are where the profits are to be made by the existing
>service providers.
>
>Please take a look at my presentation that I had ready for the September
>meeting. I had hoped to have a discussion about every function that I had
>in the overhead. I had asked Howard for the extra time in the question
>and answer portion of that presentation.
>
>Thank you,
>Roy Bynum
>
>At 12:14 PM 9/25/01 +0100, Tony Jeffree wrote:
>
>>Roy -
>>
>>I have a great deal of sympathy with Andrew's questions.
>>
>>Apparently, now is the time to agree that a "side band" OAM channel
>>should be a fundamental part of the EFM standard, but now is not the time
>>to look in detail at the requirements that might lead us to choose that
>>solution over the other alternatives, including a frame-based OAM
>>mechanism using the existing MAC service. This seems to me to be a bad
>>case of inappropriate ordering of carts and horses - in the design
>>processes that I have been used to hitherto, the starting point was not
>>to define the solution & then retrofit the justification, but to start by
>>identifying the requirements that will drive out the characteristics of
>>the solution.
>>
>>As far as I can tell from the thread so far, the "requirements" that have
>>been identified for this side-band are no more than a statement that it
>>should utilize some arbitrary but fixed (in a given application)
>>proportion of the bandwidth available on the medium concerned, and that
>>it should display deterministic properties with respect to its
>>transmission characteristics (i.e., it should be a "synchronous" channel
>>rather than "asynchronous"). However, I have yet to see:
>>
>>- A clear statement of what proportion of the bandwidth will be required
>>for OAM, or whether it is a proportion of the available bandwidth or just
>>a fixed overhead (e.g., X Kbit/s, regardless of the size of the pipe), or
>>even a clear statement that it will not be possible ever to make any hard
>>and fast statements about this, and why;
>>
>>- A clear statement of why there is a need for deterministic
>>characteristics in the OAM "channel", other than oblique hints to as yet
>>unexplored and unspecified aspects of performance management.
>>
>>I suspect that the short answer to this first question is that there are
>>no hard-and-fast answers; therefore, if the side channel approach is
>>adopted, it will presumably either be based on a finger-in-the-air
>>choice, which will later prove to be broken or over-provisioned depending
>>on the application, or will have to be configurable to suit the
>>application. (I will leave it to others to comment on whether offering an
>>OAM side band at the PHY level, and making the available bandwidth of the
>>side band configurable, is desirable/feasible/practical/economically
>>viable. To paraphrase Bob Donnan, who once famously commented that he
>>gets nose-bleeds when he ventures above the data link layer, I get the
>>bends if I spend too much time down in the PHY).
>>
>>The second question seems to me to be particularly pertinent, as, from
>>what I have gleaned from your response to my "free lunches" Email, this
>>seems to have the potential to be a pivotal reason for choosing of a side
>>band rather than simply using MAC frames (MAC control or otherwise) for
>>OAM traffic. It also reminds me very much of the religious wars of the
>>early '80s between the supporters of 802.4 on the one hand, arguing that
>>determinism was an essential characteristic of LAN communication,
>>particularly for the requirements of process control and other critical
>>"real time" applications, and the supporters of 802.3 on the other hand,
>>arguing that this was not so, and that all you needed was
>>Ethernet. Suffice it to say that today, 802.4 is a little-known blind
>>alley in the progress of LAN technology, while 802.3/Ethernet networks
>>are now widely deployed in all aspects of industry and commerce,
>>including process control (and other critical real time) applications.
>>
>>For me, arguments of the form that we've got to do it this way be able
>>"...to support a wide diversity of applications" really don't cut it,
>>unless they can be backed up. And I don't believe that it is necessary to
>>enumerate all the possible OAM applications that might ever be imagined
>>in order to reach a conclusion here, even if it were possible to do such
>>a thing; it is simply necessary to identify the "killer app(s)", if there
>>are any, that because of their characteristics, mean that we have to go a
>>particular way. If there are no such killer apps, then I would question
>>the need to spend any further cycles on the "side band" discussion, and
>>would suggest that we move on to more fruitful discussion areas.
>>
>>Right now, I am personally left with the strong impression that the major
>>reason why a side band is being proposed is that this is what the Telcos
>>expect, and that, given they are a significant part of the target market,
>>there is a marketing obstacle (rather than a technical obstacle) in the
>>way of doing it by some other means. If I am wrong, please convince me
>>otherwise.
>>
>>Regards,
>>Tony
>>
>>
>>
>>At 19:35 24/09/2001 -0500, Roy Bynum wrote:
>>
>>>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
>
>
>