RE: [RPRWG] OAM Proposal (ib_oamp_02)
Siamack,
The OAM defined at this points includes flows to discover fails between
nodes, it was not the intention to describe the whole maintenance issue. The
Loopback flow will help in finding the failed segment. In future releases
local MAC loops may be considered, but I had the impression that steering
people don't like loops.
Regarding what you call the "second failure mode", the CC does provide the
right indication since the destination node will not receive its CC frames,
and will declare LOC.
Leon
-----Original Message-----
From: Siamack Ayandeh [mailto:sayandeh@xxxxxxxxxx]
Sent: Thursday, January 03, 2002 4:57 PM
To: stds-802-17@xxxxxxxx
Cc: Italo.Busi@xxxxxxxxxx
Subject: [RPRWG] OAM Proposal (ib_oamp_02)
Folks,
Looking at RPR OAM proposal and fault management there seems to be a
couple of issues. I appreciate it if the points below are clarified.
Thanks, Siamack
In "ib_oamp_02" the purpose of introducing MAC layer ping and continuity
check seems to be twofold:
- to detect problems between the Phy and the MAC layer
- to deal with an station which may "steal" packets addressed to some
other station e.g. a station with dual identity
Now since each station has an east and a west facing Phy, the ping test
can not pin-point the Phy-MAC interface failure. This failure may be
due to the west facing Phy-MAC of this station or the East facing
Phy-MAC of the next station on the ring. I believe the common practice
for detecting such problems is a set of local loop back tests.
In the second failure mode a dual identity station would simply reply to
a ping whether its is destined to it or its dual identity. I guess the
reason behind this packet "stealing" is not clear as one can figure a
number of plausible response scenarios where the ping is not successful.