RE: [EFM] OAM - link sharing (was Faye's seven points)
> 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
I think that the main problem using in-band (apart from security concerns at
the data level) is denial of service for the OAM data, for want of a better
expression, either because of a mal-function on the subscriber port or some
deliberate act. There are ways and means of dealing with this issue by
de-coupling the subscriber from the up-link (even with low latency). This
would prevent the mal-function on the subscriber port from affecting the
up-link and its OAM datalink, even if they ar both 1GE for example.
Best regards
Bob
> -----Original Message-----
> From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> Sent: 21 September 2001 16:10
> To: bob.barrett@xxxxxxxxxxxxxxx; ah_smith@xxxxxxxxxxx
> Cc: stds-802-3-efm
> Subject: 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:
>
> >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.
>