RE: [EFM] OAM - link sharing (was Faye's seven points)
Bob,
See my comments inter spaced.
At 12:24 PM 9/21/01 +0100, Bob Barrett wrote:
>The hair is able to be split .....
>
>..... unless there is a back-hoe event ('politically incorrect JCB driver
>event' for the Europeans), then we are into alternate paths and restoration,
>which sounds more like fast spanning tree or RPR territory to me.
Or perhaps 802.3ad? This might provide a method for alternate link service
protection. The individual links would still have to their own OAM.
>A separate OAM channel in a well designed system is immune from a
>catastrophic event (attack) on the subscriber port. It is much more
>difficult to write a water-tight proof that a system using multiple queues
>over a statistically shared pipe, with a common MAC and PHY, can offer the
>same immunity. If you can offer such a proof (or denigrate the immunity
>claim for the separate OAM channel) then you may win some converts. The
>802.1 group may be the place to look for the proof as the basis for priority
>and VLANs is within their remit.
Please define by what you mean by "a catastrophic event(attack) on the
subscriber port." Physical "attacks" on any physical "port" will effect
anything that is resident through that port. Physical layer issues can
only be dealt with by alternate Physical links. "Hacker" attacks become
more difficult to initiate, the lower into the OSI stack that you go,
making lower layer processes more secure than upper layer processes. Event
Ethernet MAC addresses have been known to be "spoofed" with the right
knowledge and equipment.
>On Matt's point - user port 802.3 rates are 100M, 1G etc. by definition.
>Commercial (volume) optics tend to be specified at sonet rates, so there is
>a mis-match between the user data rate and the available bandwidth at the
>very raw physical level. If one is carrying 100M Ethernet over 155M capable
>optics there is a bucket-load of surplus bandwidth to carry other payload
>such as OAM and TDM. Ditto 1GE to OC24 optics, or even the standard 1GE
>GBICs.
Given the cost of existing transmission optics, using OC3 optics for 100mb
service, or OC24 for 1GbE services would be cost prohibitive from an
capital equipment cost to a return on investment from available revenue
basis. Better to examine optics that are more closely alined to the
service revenue bandwidths with a very slight additional signal rate to
compensate for the OAM overhead.
>Reality check: I do not think that winning converts will be required to get
>a 75% vote on specifying an in-band OAM channel as most of the 802.3 voters
>are, by definition and history of interest, from the LAN / packet centric
>community. The chance of getting 75% to support side-band with the current
>profile of 802.3 voting members is pretty slim (imho), as side-band is a
>carrier community lead requirement.
I seriously hope that you are wrong. I do not believe that all of the
people in the group/TF have had an opportunity to see all of the pros and
cons of the different alternatives. There are reasons why the service
provider community have maintained the "side-band" type of management for
the service links, even under other types of data services with different
types of service models.
>BTW - Who remembers the problems caused by delayed BPDUs in spanning tree
>protocol? There is a good example of the problems that can arise when
>control traffic is mixed with payload if ever there was one :-). It was
>addressed by some form of prioritisation I seem to recall. I stopped
>following 802.1 in 1992, so others may care to expand on the detail.
These sort of "side effects" from one or the other of the alternatives have
to be evaluated as part of the process of deciding which way to implement
the OAM before the final group decisions should be made. I realize that
there is a pressure on the group/TF to quickly come to a conclusion about
this issue. Being hasty here could be a mistake.
>Best regards
>
>Bob Barrett
>
> > -----Original Message-----
> > From: owner-stds-802-3-efm@majordomo.ieee.org
> > [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Andrew
> > Smith
> > Sent: 21 September 2001 03:17
> > To: Roy Bynum
> > Cc: stds-802-3-efm
> > Subject: [EFM] OAM - link sharing (was Faye's seven points)
> >
> >
> >
> > Roy,
> >
> > I think you are splitting hairs here: if the OAM traffic goes
> > down the same
> > wire/fibre/whatever link as the customer's traffic then it is, by
> > definition, "sharing the same bandwidth". If you run them over
> > separate TDM
> > channels on the same link then you are using a (time-based) link-sharing
> > scheduler to place the different types of traffic onto the link.
> > If you mix
> > them into the same channel (what you call "frame"-based) then
> > you'll likely
> > still use a link-sharing scheduler to place the different traffic onto the
> > link - it might be priority-based, it might be some sort of
> > weighted-round-robin (or you might even choose to use just "best effort"
> > with a single traffic class/queue), whatever you want to choose.
> > There is no
> > fundamental difference - you're still scheduling frames from one or more
> > queues onto the link. Not wanting to "share the customer's bandwidth" is
> > *not* a valid argument in favour of a "separate" TDM channel for OAM.
> >
> > I'll let others deal with your "paranoid" security argument, although that
> > just seems like an addressing (and maybe authentication) issue to me.
> >
> > Andrew Smith
> >
> >
> > -----Original Message-----
> > From: owner-stds-802-3-efm@majordomo.ieee.org
> > [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Roy Bynum
> > Sent: Thursday, September 20, 2001 3:10 PM
> > To: Harry Hvostov; 'Faye Ly'; Harry Hvostov; Roy Bynum
> > Cc: stds-802-3-efm
> > Subject: RE: [EFM] OAM - Faye's seven points
> >
> > Harry,
> >
> > I think that Faye is correct. If the OAM is "frame" based, then it will
> > share the same bandwidth with the customer traffic. Only if the OAM is
> > "side band" will it not share the same bandwidth as the customer traffic.
> >
> > Thank you,
> > Roy Bynum
> >
> > >Sent: Thursday, September 20, 2001 8:15 AM
> > >To: Harry Hvostov; 'Faye Ly'
> > >Cc: stds-802-3-efm
> > >Subject: RE: [EFM] OAM - Faye's seven points
> > ...
> > >Harry,
> > >
> > >I do not like the idea of inserting frames into the customer traffic. I
> > >am
> > >not sure how it would work such that, for security reasons, only the
> > >intended physical interface on a P2MP deployment would receive the OAM
> > >Ethernet frames. Call me paranoid.
> > >
> > >Thank you,
> > >Roy Bynum
> >