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

[Roy Bynum <rabynum@xxxxxxxxxxxxxx>]

Tony,

You are severely twisting my words.  I said that the market is for business 
market potential for Ethernet "Private Line" much greater than "Shred" 
Ethernet.  One of the technical requirements for "Private Line" is that the 
service provider OAM "overhead" does not invade the customer revenue 
traffic.  Another requirement is that it has a fixed bandwidth. Please see 
the attached paper that contains some of the characteristics and 
requirements for different type of data specific communications services.

There are a lot of other reasons to have the OAM ou-of-band to the MAC 
traffic, such as being able to support OAM on an intelligent "transparent" 
full duplex repeater in the future.  When this group took on the task of 
adding subscription network support for edge access infrastructure into 
Ethernet, they took on applying most all of the functionality that is being 
used today.  There is a long history of why the functionality for these 
types of services is what it is.  How many of the EFM Task Force people 
have looked at how the OAM overhead of T1 or T3 framing works today?  How 
many of the EFM Task Force people have looked into why the OAM overhead of 
T1 or T3 framing works the way that it does?

Thank you,
Roy Bynum


At 08:31 PM 9/25/01 +0100, Tony Jeffree wrote:
>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
>>
>>
>

Generic Data Communications Service Models.PDF