RE: [EFM] OAM - Faye's seven points
Roy -
Not twisting them, merely trying to understand what you are actually
saying, and checking whether my understanding of your words is faulty or
not. I clearly misunderstood your words in this case. Thanks for the
clarification.
Regards,
Tony
At 11:31 26/09/2001 -0500, Roy Bynum wrote:
>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
>