RE: [EFM] OAM - link sharing (was Faye's seven points)
At 12:24 21/09/2001 +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.
True.
A separate OAM channel in a well designed
system is immune from a
catastrophic event (attack) on the subscriber port.
This sounds like a circular definition to me. Presumably, for the system
to be considered well-designed, its OAM channel would have to be immune
from attack? In which case, nobody could possibly disagree with your
statement. However, I'm not terribly sure that this gets us any further
forward ;-)
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.
The fact that well-designed Bridges can still manage to get BPDUs
transmitted and received in the face of catastrophic events (for example,
when breaking a temporary loop) is actually a pretty clear demonstration
that management mechanisms can be constructed without the
necessity for creating a separate management channel at the PHY
level.
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.
And (as pointed out above) it is also a good example of the fact that
mixing payload and control traffic can be done successfully. It wasn't
addressed by prioritization in the sense of adding an explicit priority
value (for example, as provided by the 802.1 VLAN/priority tag - that
came much later), but by Bridges being designed and built such that,
whatever other traffic was hitting the port, any incoming BPDUs would
actually be delivered to the Bridge state machines.
Regards,
Tony
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
>