RE: [EFM] OAM - link sharing (was Faye's seven points)
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.
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.
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.
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.
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.
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
>