RE: [EFM] OAM - Faye's seven points - pings
Bob,
Thank you and
Yes, what I meant subscriber port is the port that sits
on CPE and connects to the subscriber network.
Plug and play is a very reasonable requirement but
I was asking for the scenario where sometimes a
connectivity check is required to answer subscriber's
complaint about losing connection/slowness ...
I am not a SP so I was merely guessing that customer
support engineer might need to start a ping command
from the CPE subscriber port and go upstream to the
SP's router to check connectivity. I guess this steps
into the OAM discussion?
Taking OAM discussion to MEF is a good idea. I
agree.
-faye
-----Original Message-----
From: Bob Barrett
Sent: Wed 9/19/2001 1:03 PM
To: Faye Ly; fkittred@xxxxxxx
Cc: stds-802-3-efm@ieee.org
Subject: RE: [EFM] OAM - Faye's seven points - pings
Faye
I think somebody already made the point that a service provider
would not
want the 'customer/subscriber' being able to send pings into the
service
providers infrastructure. If the service is end to end VPN then
the
subscriber can be enabled to ping through the service providers
'cloud' to
the subscribers equipment at the far end.
There may be a case for including a ping test within the EFM CPE
that is
only accessible to the service providers engineer for use at
installation
time. However, I think the target is to make the CPE plug and
play and do
all the set-up / initialisation / config. from a central NOC or
at worst
from the POP. You don't necessarily need that much intelligence
on the
service provider side of the demarc (in the CPE) to do this.
On the other OAM thread: the MEF is probably a 'better place' to
discuss the
broader, higher layer issues of management between NOC NMS,
proxies and CPEs
in the context of Ethernet Subscriber Access (ESA). The ietf is
probably
where the 'standards' will be written up as rfcs. There is an
MEF technical
group starting work on this I understand.
Best regards
Bob Barrett
> -----Original Message-----
> From: Faye Ly [mailto:faye@xxxxxxxxxx]
> Sent: 18 September 2001 19:06
> To: bob.barrett@xxxxxxxxxxxxxxx; Geoff Thompson;
fkittred@xxxxxxx
> Cc: stds-802-3-efm@ieee.org
> Subject: RE: [EFM] OAM - Faye's seven points
>
>
> Bob,
>
> Thank you for the response. Please see my comments
> embedded in <FL> below:
>
> >> 4. Connectivity diagnose (ping etc) - This is divided into
link
> >> connectivity which
> >> can be covered by 2 and subscriber line connectivity.
>
> >Mandatory for the link, up to a point as close to the
subscriber
> interface
> >as possible e.g. copper loop back on the connector side of
the IC, in
> the
> >last output stage of the IC (most PHY ICs support this
already).
>
> >Tests to the subscriber equipment are outside of the scope of
EFM, but
> in
> >real terms the service provider will probably PING something
on the
> >subscriber network, given access rights.
>
> <FL> Very good point. I always thought what they need is
> ping-ing from subscriber side to the upstream router to
> test the connectivity. Not the other way around.
> So when subscriber calls and complains about a problem
> with his/her connectivity, I guess you need to:
>
> 1. First find out from your network map to see if you
> have gotten a report somewhere stating a box fault or
> line card fault. Either one is in the way of this
> subscriber. You also validate this by ping-ing the
> CPE from the head-end?
>
> 2. If 1 is not true, you ping the subscriber's PC or
> CPE port from the router? Note that the requirements
> on the OAM is quite different from having to be able
> to ping from the CPE port to the router. The later
> requires the CPE to accept such a 'ping' request
> from the NOC.
>
> Your thoughts?
>
> -faye
>
winmail.dat