Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [EFM] OAM - Faye's seven points - pings

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

	-----Original Message----- 
	From: Bob Barrett 
	Sent: Wed 9/19/2001 1:03 PM 
	To: Faye Ly; fkittred@xxxxxxx 
	Subject: RE: [EFM] OAM - Faye's seven points - pings

	I think somebody already made the point that a service provider
would not
	want the 'customer/subscriber' being able to send pings into the
	providers infrastructure. If the service is end to end VPN then
	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
	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
	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;
	> Cc:
	> 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
	> >> connectivity which
	> >> can be covered by 2 and subscriber line connectivity.
	> >Mandatory for the link, up to a point as close to the
	> 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
	> >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