Subject: FW: [[email-masked]: [Fwd: Question about APS MIB]]

From: "Alexander Lindeijer(ETO)" <[email-masked]>
Date: Thu, 8 Feb 2001 12:10:10 +0100

Hi
Can I raise the question described below? I don't think Jim's solotion works. Some where the higherLayer interfaces of the protected interface have to meet. You also want one interface where performance data of the resulting protected interface is hold (a combination of performance of the working and protecting interface). It has to be more clear how the ASP MIB relates to the ifTable and ifSTackTable.

Best Regards
Alex Lindeijer
Ericsson Norway AS,
BL XC&IP,
PO Box 34,
N-1361 Billingstad
Norway.
Tel: +47 6684 2609
Email:[email-masked]

-----Original Message-----
From: Jim Kuhfeld [mailto:[email-masked]] 
Sent: 29. januar 2001 19:43
To: [email-masked]
Cc: Michael Thatcher
Subject: [[email-masked]: [Fwd: Question about APS MIB]]

The subject hasn't been addressed by the working group before. Feel free to address 
this issue to [email-masked] if you would like to see this clarified.

My personal opinion is that the sonetPath and sonetVT interfaces stacked above a 
working channel sonet interface should not be moved in the ifStackTable to a position 
above the protection sonet interface when a protection switch occurs. With the 
example of a working channel switched to protection because of a signal failure 
condition, I expected the working channel sonet interface ifOperStatus to report 
down and any sonetPath or sonetVT interfaces configured on that channel to 
report lowerLayerDown. I imagined that the protection channel interface stack would 
have the same arrangement of sonetPath and sonetVT interfaces as the working 
channel that has been switched to protection, but they would be a separate set of 
interfaces with different InterfaceIndex values.

----------------

Hi
My name is Alex Lindeijer, working at Ericsson in Norway, and I'm interested in the SONET APS MIB that is in draft status at the moment. I have one question:
What happens when a protection switch happens. Do things only change in this APS MIB or things also meant to change in the ifStackTable in the interface MIB. What I mean is whether the SONET path that uses the working section interface(that is part of an APS group) will be moved in the ifStackTable over the protection LTE interface. Or that the ifSTackTable remains unchanged and that the actual connectivity is only indicated by the apsChanStatus?
Thanks in advance and best regards
Alex Lindeijer
Ericsson Norway AS,
BL XC&IP,
PO Box 34,
N-1361 Billingstad
Norway.
Tel: +47 6684 2609
Email:[email-masked]

----- End forwarded message -----

---

From: Jim Kuhfeld <[email-masked]>
Date: Thu, 8 Feb 2001 22:05:02 -0800

A higher layer may well be represented in the ifStackTable that does in some sense
combine the performance of the working and protection interfaces. A simple example
is atm over sonet. An atm interface could be stacked over a working channel
sonetPath interface. I initially responded to the question of whether the
sonetPath interface stacked over the working channel is subsequently stacked
over the protection channel when a protection switch occurs. I don't think it
does. For that matter I don't think there is any particular advantage in
moving the atm interface in the ifStackTable because of a protection switch.
I think the the state of an APS group is better represented by the APS MIB 
than the ifStackTable. My thought was to stack a higher layer interface above 
a working channel only, rather than attempt to demonstrate APS group state
changes with dynamic changes to the ifStackTable, especially in something as
complicated as a 1:n configuration with extra traffic.

A simple stack:

atm   
working sonetPath     protection sonetPath
working sonet         protection sonet

           ifIndex  Description
           1        working sonet 
           2        working sonetPath 
           3        atm 
           4        protection sonet
           5        protection sonetPath

ifStackTable Entries

           HigherLayer   LowerLayer
           0             3
           0             5
           1             0
           2             1
           3             2
           4             0
           5             4