RE: [EFM] Re: OAM Transport Proposal
Folks,
The decisions made by the MEF should not be discussed on this reflector.
Thanks,
Brad
-----Original Message-----
From: Bob Barrett [mailto:bob.barrett@xxxxxxxxxxxxxxxxxx]
Sent: Monday, April 29, 2002 10:14 AM
To: Roy Bynum; mattsquire@xxxxxxx;
stds-802-3-efm@ieee.org; sergiu@nbase-xyplex.com
Subject: RE: [EFM] Re: OAM Transport Proposal
Roy
I get it (I think) - embedded overhead channel within the
payload therefore
cannot be defined as private line. Is that the deal?
On the MEF - I heard second hand that there was a motion at
MEF to support
only OAMiF, which did not get 75%. This is not the same as
you heard
(relayed to me), which implied that MEF had past a motion by
75% to support
OAMiP. BIG difference, as I am sure you appreciate. The
minutes should be
out soon, so I'll be able to check the exact wording of the
motion and the
numbers.
Best regards
Bob
-----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: 27 April 2002 14:03
To: bob.barrett@xxxxxxxxxxxxxxxxxx; mattsquire@xxxxxxx;
stds-802-3-efm@ieee.org; sergiu@nbase-xyplex.com
Subject: RE: [EFM] Re: OAM Transport Proposal
Bob,
Actually OAMiF does provide and equivalent to an embedded
overhead
channel. It is the 108 bytes of data in the frame payload.
What goes
into that 108 bytes has not even begun to be defined. As
part of that
on-going definition, a Management Control Channel can be
defined. That MCC
will act as an inband version of an EOC, providing the same
intermediate
system management that a standard EOC provides.
The fact that 802.3 does not define any functionality above
the MAC client
interface limits what can and can not be in scope. Within
the concept of
OAMiF however, provisions can be made that will allow other
organizations
to standardize on the use of what 802.3 does provide. This
will be the
case of the MCC/EOC, if it gets done.
Thank you,
Roy Bynum
At 04:57 AM 4/27/2002 +0100, Bob Barrett wrote:
>Sorry Roy, I can't follow the logic here.
>
> >Intermediate network elements are addressed/sub-addressed
through the
> >protocol on the embedded overhead channel, not in the
basic carrier
> >protocol.
>
>EFM OAM doesn't have an embedded overhead channel (I guess
that's one of
the
>points that you are trying to make).
>
>Your are correct that the management of intermediate
network elements are
>out of scope for EFM OAM.
>
>However, what I don't get is that whilst you are normally
very pro the real
>market need, (and management of intermediate network
elements is a real
>market need), you are against it here.
>
>Is the message that you actually support it, and see the
requirement as
>being met by the adoption of a proposal that includes an
embedded overhead
>channel, and furthermore see the need for a change in the
objectives of EFM
>OAM so that the subject is no longer out of scope. If that
is the message
>then I would support it, but I would also suggest that we
would be wasting
>our time to take it any further in EFM at this time,
without active support
>from at least three major ILEC or IXC customers.
>
>Best regards
>
>Bob
>
>-----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: 25 April 2002 14:13
>To: bob.barrett@xxxxxxxxxxxxxxxxxx; mattsquire@xxxxxxx;
>stds-802-3-efm@ieee.org; sergiu@nbase-xyplex.com
>Subject: RE: [EFM] Re: OAM Transport Proposal
>
>
>
>Bob,
>
>Intermediate network elements are addressed/sub-addressed
through the
>protocol on the embedded overhead channel, not in the basic
carrier
>protocol. Look at the support for "repeaters" in the xDSL
standards that
>ITU-T provided and have been put up on the EFM web page.
>
>EFM OAM, in providing the basic carrier protocol does not
need to address
>the issue of addressing/sub-addressing "multiple "full
duplex
>repeaters"". It is not a requirement that this Task Force
needs to get
>even close to.
>
>By use of the PHY ID was to provide channelized facilities
to support
>unbundled broad band leased circuit services. The MCC in
the out of band
>OAM overhead provided the management channel for the
intermediate network
>elements, just like what is done in the industry today.
>
>Thank you,
>Roy Bynum
>
>At 07:09 AM 4/25/2002 +0100, Bob Barrett wrote:
> >Roy
> >
> >There is a requirement to manage multiple "full duplex
repeaters" and
thus
>a
> >need for sub-addressing, hence the really useful nature
of leveraging the
> >PHY ID from EPON for this purpose, either that or there
would be a need
for
> >sub-addressing of the OAMiF frame in some standard way.
> >
> >Best regards
> >
> >Bob
> >
> >-----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: 25 April 2002 01:10
> >To: mattsquire@acm.org; stds-802-3-efm@ieee.org;
sergiu@xxxxxxxxxxxxxxxx
> >Subject: RE: [EFM] Re: OAM Transport Proposal
> >
> >
> >
> >Matt,
> >
> >If item 3 is correct, then OAMiF can be used to manage
"full duplex
> >repeaters" because of the ability to evaluate the
contents of the OAM
Frame
> >for the contents of the MCC. The MCC can be used as an
embedded overhead
> >channel (EOC). That will allow MAC addressing of the
repeater management
> >port through the EOC, or the use of HDLC, which is
currently standard in
> >the industry.
> >
> >Thank you,
> >Roy Bynum
> >
> >At 05:54 PM 4/24/2002 -0400, Matt Squire wrote:
> >
> >
> > >We've had many threads on repeaters, media converters,
regenerators,
and
> > >the like throughout the evolution of this work. The
following are my
> > >recollections as reported by others (Geoff, Tony,
etc.). Pls correct
> > >anything I misrepresent.
> > >
> > >1) 802.3 defines half-duplex repeaters.
> > >2) 802.3 does not define full-duplex repeaters.
> > >3) What some people commonly refer to as full duplex
repeaters are
> > >actually 2-port MAC frame forwarders (802.1D relays?).
> > >4) 802.3 does not define optical regenerators (ie
protocol agnostic
> > >signal regeneration).
> > >5) 802.3 does not define media converters.
> > >
> > >Since using the preamble to carry signaling is intended
as a
full-duplex
> > >function only, I short-cut to the conclusion that
preamble has no
> > >applicability to any repeater, regenerator, or media
converter as
> > >defined by 802.3. Before we could figure out how to
address this
> > >full-duplex repeater function that does not exist in
802.3, it would
> > >have to be properly defined. Thats all I was getting
at.
> > >
> > >People are concerned, people are thinking about it, but
it has been
> > >difficult to address because of the terminology
confusion and our
> > >scope.
> > >
> > >- Matt
> > >
> > > >
> > > >Hi Matt and all,
> > > >
> > > >I will address only the issues related to 5)
Regenerators and
> > > >converters.
> > > >First of all I want to assume that we consider all
the 802.3
> > > >interfaces,
> > > >including 100 Mbps and GbE.
> > > >
> > > >802,3 defines the above entities. Look at 27.
Repeater for 100
> > > >Mbps baseband
> > > >networks.
> > > >The devices that we address are two port full duplex
repeaters.
> > > >Also 802.3ab makes extensive references to repeater
implementations.
> > > >
> > > >And again, the moment that we defined any preamble
based
> > > >capability - see
> > > >page 9
> > > >of the baseline presentation - we decided to make the
> > > >appropraite changes
> > > >for preamble
> > > >support.
> > > >
> > > >I also had some questions, regarding packet based
functionality.
> > > >This functionality I assume is not fully contained in
the new
> > > >MAC (like the
> > > >packet based
> > > >flow control functionality). It requires an external
processing unit
> > > >(CPU+MAC, HW, or whatever).
> > > >What is the level of service in the case of a busy
link (even
> > > >malfunctioning
> > > >due to a broadcast
> > > >storm, etc.)? Do we lose the management capacity for
some time?
> > > >Wouldn't an out-of-band mechanism (like preamble) be
valuable
> > > >in order to
> > > >provide even the
> > > >basic management information as defined in the suzuki
proposal?
> > > >
> > > >I still think that the compromise should be a
functional
> > > >compromise, that
> > > >provide the
> > > >best of the two worlds meaning that the capabilities
> > > >negotiations should
> > > >include four
> > > >options, and should be done also at the lowest
level...
> > > >
> > > >Sergiu
> > > >
> > > >