Subject: Re: [mpls-tp] AIS/FDI (was Associatedbidirectionaltransportpathrequirements)

From: Maarten Vissers <[email-masked]>
Date: Mon, 04 May 2009 10:21:16 +0200

Malcolm,

The atomic functions include a so called "Defect Correlation" specification
in which a set of "Fault Causes (cXXX)" is determined on the basis of a set
of "Defects (dXXX)". The generic defect correlation specifications are
defined in G.806 9see clause 6 and figures 6-1 and 6-2/G.806), and the
technology specific defect correlation specifications are defined in the
technology specific equipment recommendations.

The Fault Causes are presented to the Equipment Management Function (EMF)
via the MI_cXXX signals. The EMF provides the post processing including
determination of "Failures (fXXX)" and various reportings. This post
processing is generically specified in G.7710 (see clause 7 and figure
7/G.7710).

The main requirement underlying the Defect Correlation specification is the
requirement to 
- determine the primary fault underlying the (set of) defect(s) that are
detected. 

Very often, a single fault will result in the detection of a primary defect
plus the detection of one or more (sometimes a large number of) secondary
defects. Those secondary defects are a consequence of the primary fault.
Table 1/G.7710 provides an overview of Primary failures and
Secondary/consequential failures.

There are a number of primary fault/failure types:
1) continuity fault/failure (LOS, UNEQ, OCI, LOC)
2) connectivity fault/failure (TIM, MMG)
3) payload type fault/failure (PLM)
4) payload structure fault/failure (MSIM)
5) alignment/framing fault/failure (LOF, LOM, LOP)
6) signal quality/degradation fault/failure (DEG)
7) protocol fault/failure (FOP)
8) connection monitoring source fault/failure (LTC).

There are two secondary fault/failure types:
1) forward fault/failure (AIS, FDI, SSF)
2) backward fault/failure (RDI, BDI, ODI).

The Fault Management objective is to report on the primary fault/failure and
suppress all other faults/failures.

Service Management is another application using the above failures. Service
management has to be aware of or must be able to retrieve immediately the
status of a service layer connection which exists between two or more UNI-N
ports. 

Service Management has to know if the connection is Up or Down and if there
is a performance degradation when the service connection is Up. 

Service Management is as such not interested if there is a primary fault
detected at the endpoint of a service connection. Service management needs
to know if there is a fault that either interrupts or degrades the service.

To support the needs of service management, the Server Signal Fail (SSF)
fault cause and failure were introduced many years ago. SSF failure
reporting is controlled by network management. Default is not autonomously
reported; but the SSF failure status can always be requested by NMS. 

Section and path/tunnel connections aren't service connections, so this
default is applicable. Service/channel layer connections without pro-active
connection monitoring will also be supported by this default mode. For
service/channel layer connections with pro-active monitoring, autonomous SSF
failure reporting can be enabled.

Primary fault causes 1, 2 and 6 are faults of which the fault location is
typically not in the node detecting this fault. Those faults require a fault
localization procedure to be run to locate the faulty node or faulty link.

Primary fault causes 3,4 and 5 are faults of which the fault location is
typically in the trail terminating far end node, specifically in the
interlayer adaptation function connected to the trail.

Primary fault cause 8 is a fault of which the fault location is the port
card on which the TCM MEP Source function should be located.

I hope that the above helps you to understand that the key information
elements you list are not covering the objectives of fault management.

Regards,
Maarten

-----Original Message-----
From: Malcolm Betts [mailto:[email-masked]] 
Sent: woensdag 29 april 2009 17:11
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was
Associatedbidirectionaltransportpathrequirements)

Andy, Maarten,

Without going into all of the details, I think that you are describing a
function that should be performed by the element management alarm reporting
and control function. 

i.e. does a certain condition, or combination of conditions, result in an
autonomous notification to a management system, or is it simply a condition
that is reported "on demand".

>From the perspective of this discussion we should focus on the primitives
that are delivered to the alarm reporting and control function.

The key "information elements" that must be provided are:
1) Has the trail failed
2) Has the failure been caused by i) a "local" fault i.e. in the equipment
or on an incoming link:  or ii) by a "remote" fault i.e. in another node or
on an incoming link that terminates on a remote node.

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Wednesday, April 29, 2009 10:46 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was
Associatedbidirectionaltransportpathrequirements)

Maarten,

>From this, you are agreeing the basic operational model. I was trying to be
both concise and reasonably general to different maintenance scenarios (and
the posting was still pretty long). In the detailed scenario you describe,
the distinction between 'proactive' and 'reactive' maintenance is whether
the guy wants the alarm raised to him immediately and he will deal with it
ahead of any trouble ticket raised by a customer or whether the guy only
wants to know the alarm status in front of him at the time the customer
raises the trouble ticket. In both cases the 'suppressed' alarm is still
needed in the higher level management system.

Exact procedures for fault locations will vary, I'm sure, as do the systems
available to help. Importantly, there will inevitably be a variety of
residual faults which occur which do also sit neatly into prior assumptions
of what can go wrong. So fault localisation *must* include procedures to
deal with things which do not say 'I am broken, fix me'. What is damaging to
the fault localisation process is if there is false information around.

Andy

Andy Reid
Chief Network Services Strategist
BT Innovate

Office:	+44 (0)1277 322038
Mobile:	+44 (0)7917 025451
Fax :       +44 (0)1277 324015
Email:	[email-masked]

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ Registered in England
no. 1800000 This electronic message contains information from British
Telecommunications plc which may be privileged or confidential.
The information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this information
is prohibited. If you have received this electronic message in error, please
notify us by telephone or email (to the numbers or address above)
immediately.
Activity and use of the British Telecommunications plc email system is
monitored to secure its effective operation and for other lawful business
purposes. Communications using this system will also be monitored and may be
recorded to secure effective operation and for other lawful business
purposes.

> -----Original Message-----
> From: Maarten Vissers [mailto:[email-masked]]
> Sent: 29 April 2009 08:18
> To: Reid,ABD,Andy,CXM R; [email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls-tp] AIS/FDI (was Associated
> bidirectionaltransportpathrequirements)
> 
> Andy,
> 
> You speak about "local" and "remote" alarms. I had to read the rest of

> the sentence three times before I understood that you meant "primary" 
> and "secondary/consequential" alarms.
> A primary alarm is an alarm that reports a fault cause that needs 
> fixing, whereas a secondary/consequential alarm is a report from a 
> client that it's connection is interrupted due to a server fault.
> Do I understand your use of "local" and "remote" correct?
> 
> I agree with you that the main task of fault management is to know if 
> there is a fault that they can repair, what the fault is, where the 
> location of this fault is and then who to send to repair the fault.
> 
> I agree with you that service management needs to know about the 
> status of the service when the customer calls. I do not agree with you

> that in general "these guys wants to know that the service is 'down' 
> **before** the customer is on the phone!".
> 
> I have very explicit information of a few operators that a large 
> number of service contracts will not be as you describe. Values given 
> to me are 90% of service contracts (representing 70% of service
> connections) are without pro-active monitoring. In those contracts the

> repair time starts after the report of the customer and verification 
> by the operator. What is important in those cases is that the service 
> manager can simply retrieve status information when the customer is on

> the phone.
> 
> The other 10% of service contracts (representing 30% of service
> connections) are with pro-active monitoring. In those contracts the 
> repair time starts after the defect is detected. I assume that "these 
> guys wants to know that the service is 'down' **before** the customer 
> is on the phone!"
> is applicable for a subset of those service connections. For the other

> subset I have understood that it is sufficient when the 
> status/performance information of the service connection can be 
> retrieved instantaneously when the customer is on the phone. Is this 
> also the case in BT?
> 
> Besides the service connections, we have tunnel/path connections, 
> section connections and physical media connections. Those connections 
> have no direct "service"
> associated with it; i.e. those connections are part of the network's 
> infrastructure. There is as such no "service manager" interested in 
> the status of those infrastructure connections. The only people 
> interested in alarms from those infrastructure connections are the 
> fault management people.
> Do I understand this correct?
> 
> > The service maintenance guys *have* got an alarm - the customer has 
> > not got their service! They also notice that it is not
> fixing itself. 
> > So they investigate, ie start localising.
> 
> I do not understand why a service maintenance guy will have to do the 
> fault localization... I have always been told that fault management is

> responsible for locating a fault. If the fault is an open matrix 
> connection (which either interrupts a tunnel/path connection or a 
> service/channel connection), then the fault management people 
> responsible for the layer network will be triggered by the loss of CC 
> alarm and start the localization procedure.
> 
> When a network deploys AIS, it is possible to trigger this open matrix

> fault localization procedure without any complex network correlation 
> procedure.
> Seems to be advantages...
> 
> Regards,
> Maarten
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: woensdag 29 april 2009 0:26
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls-tp] AIS/FDI (was Associated
> bidirectionaltransportpathrequirements)
> 
> Maarten, Igor,
> 
> Before dealing with the specific scenarios, let me go through again 
> what I said in an earlier posting about the way alarm 'suppression'
> actually works.
> 
> There are two sides to maintenance - the faulty kit guys who fix 
> faulty cards, mend cable breaks, etc, etc, and end service guys who 
> deal with customer service. 'Suppressed'
> alarms are only suppressed to the faulty kit guys who fix cards, etc. 
> The distinction between 'local' and 'remote'
> alarms is very important to ensure that these faulty kit guys are 
> directed to the place where the actual fault lies and not to places 
> affected by, but remote from the actual fault.
> 
> However, these 'suppressed' alarms are still forwarded to the service 
> maintenance guys. So when SONET/SDH is carrying an E1 or a T3, they 
> want to know whether the end service is 'up' or 'down' irrespective of

> the cause and irrespective of the presence of AIS. AIS most 
> emphatically does not suppress this alarm! These guys wants to know 
> that the service is 'down'
> before the customer is on the phone!
> 
> So to go to Maarten's first example, the faulty kit guys are not 
> getting any alarms telling them to fix broken kit - which is correct.
> 
> The service maintenance guys *have* got an alarm - the customer has 
> not got their service! They also notice that it is not fixing itself.
> So they investigate, ie start localising. In practice, the first thing

> they will do (and most management systems will do it automatically by 
> some form of correlation engine) is check for any corresponding faulty

> kit alarms. In this case, they will find no faulty kit alarms and 
> suspect a misconfiguration, localise it, and fix it.
> 
> To go to Maarten's second example, the faulty kit guys are getting an 
> alarm telling them to fix the link between A and B.
> 
> The service maintenance guys have also got an alarm - again the 
> customer has not got their service. They also notice that it is not 
> fixing itself. So they investigate, ie start localising. Again, the 
> first thing they will do (and most management systems will do it 
> automatically by some form of correlation engine) is check for any 
> corresponding faulty kit alarms. In this case, they will find the 
> corresponding faulty kit alarm and can check of the repair plan and 
> status should the customer call and ask.
> 
> As these particular scenarios illustrate, the right alarms have been 
> directed to the right maintenance guys. The service guys deal with the

> service configurations, the faulty kit guys deal with faulty kit.
> 
> Occasionally, there will be faulty kit which is not reporting itself 
> despite the best design efforts in the equipment. In this case, the 
> service maintenance guys are likely to have a series of alarms which 
> can be correlated to help localise the fault and the diagnosed fault 
> can then be passed to the faulty kit guys for fixing.
> 
> Another important point. There is little room here for
> *false* information coming to either set of maintenance guys. 
> When trying to localise a fault, no additional information is better 
> than wrong additional information.
> 
> That is my concern with the trying to inject packet based AIS. There 
> is significant room for creating false information. As I've already 
> indicted there is AIS specific configuration to do which will be prone

> to misconfiguration.
> We should then note that the thing that the AIS is supposed to be 
> identifying is the present of misconfiguration - but achieving this 
> requires configuration. So why should one configuration be more 
> reliable than the other?
> 
> But there are other scenarios. For example, consider port mapping (or 
> in ITU-T speak, a degenerate subnetwork) where we terminate the 
> section layer on one interface and blindly ship all the packets out on

> an other interface in a new section.
> If we assume AIS is being used, a fault in the incoming section should

> result in the injection of AIS. But how does it know what label values

> to use? Or does it not inject AIS?
> In which case we have the poor service maintenance guys actively 
> looking for a configuration error which does not exist. A similar 
> scenario would exist if we choose to use a sort of ADM where the 
> forwarding table was made up of exception (add/drop) label values and 
> a default outgoing port. Again, the same dilemma exists.
> 
> Andy
> 
> 
> 
> 
> Andy Reid
> Chief Network Services Strategist
> BT Innovate
>  
> 
> Office:	+44 (0)1277 322038
> Mobile:	+44 (0)7917 025451
> Fax :       +44 (0)1277 324015
> Email:	[email-masked]
> 
>  
> British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ Registered in 
> England no. 1800000 This electronic message contains information from 
> British Telecommunications plc which may be privileged or 
> confidential. The information is intended to be for the use of the
> individual(s) or entity named above. If you are not the intended 
> recipient be aware that any disclosure, copying, distribution or use 
> of the contents of this information is prohibited. If you have 
> received this electronic message in error, please notify us by 
> telephone or email (to the numbers or address above) immediately.
> Activity and use of the British Telecommunications plc email system is

> monitored to secure its effective operation and for other lawful 
> business purposes. Communications using this system will also be 
> monitored and may be recorded to secure effective operation and for 
> other lawful business purposes.
> 
>  
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Maarten Vissers
> > Sent: 28 April 2009 20:25
> > To: 'Igor Bryskin'
> > Cc: [email-masked]
> > Subject: Re: [mpls-tp] AIS/FDI (was Associated
> > bidirectionaltransportpathrequirements)
> > 
> > Igor,
> > 
> > > b) Is it beneficial if a server trail notifies its clients about
> >      a detected problem to suppress the OAM traffic
> > 
> > The suppression we have been talking about is alarm
> suppression, not
> > OAM traffic suppression.
> > 
> > Loss of CC is intended to detect an open connection fault
> in a matrix.
> > E.g. assume a connection that starts in node A, passes
> through nodes B
> > and C and ends in node D.
> > Nodes A, B, C and D have a connection function in which a matrix 
> > connection is to be set up to support this connection from A to D.
> > 
> > What is now possible is that the matrix connection in node B is 
> > unintentionally removed (i.e. a continuity fault).
> > Node D will now detect a loss of CC. Node D does not detect
> any other
> > faults.
> > Node C will not detect any fault.
> > Node B will not detect any fault.
> > Node A will not detect any fault if the matrix connection in B is 
> > removed in one direction only.
> > 
> > In order to detect this open matrix connection fault it is
> required to
> > report the loss of CC to the management system and to start a fault 
> > localization procedure to locate the faulty matrix (i.e. in node B).
> > If such reporting is not done, then there is a hidden fault, which 
> > keeps the connection interrupted much longer; i.e. until
> one or more
> > customers start to complain that their connections are lost.
> > Then you hae to find in a big network without any fault
> report which
> > node has the fault.
> > 
> > What happens now if the fault is not an open matrix
> connection but a
> > server layer fault (e.g. a link fault between nodes A and B).
> > Node D will now detect a loss of CC. Node D does not detect
> any other
> > faults.
> > Node C will not detect any fault.
> > Node B will detect a loss of signal fault.
> > Node A will not detect any fault if the link from A to B is
> broken in
> > one direction only.
> > 
> > If loss of CC is unconditionally reported, then node D will report 
> > loss of CC. Node B will report loss of signal.
> > - If node B and node D are managed by the same management
> system it is
> > possible to perform a fault correlation in this management
> system to
> > filter out the loss of CC from node D.
> > What is necessary is to know that connection A-D is
> supported by the
> > link A to B. In larger multi-layer networks such
> correlations become
> > complex. If such correlations are not performed, then the
> loss of CC
> > will trigger a fault localisation action, which of course will not 
> > find a matrix fault (i.e. waste of time).
> > - If node B is managed by another management system then
> node D, there
> > is no correlation possible. Node D's management system will
> see only
> > the loss of CC and will start fault localization, and will not find 
> > any fault in its part of the network.
> > 
> > Use of AIS will help in distinguishing between connection
> interruption
> > due to an open matrix connection fault and due to server fault. AIS 
> > provides the necessary filter for loss of CC.
> > 
> > What happens for the case a port detects a signal fail condition is 
> > the following; assume a 10G port that detects a signal fail
> condition.
> > This implies that all traffic is lost.
> > Assume that there are 1000 client connections active (e.g. 
> > with an average bandwidth of 5 Mbit/s). When AIS is to be generated 
> > for those 1000 client conenctions the port has to generate 1000 AIS 
> > frames/packets per second. Each AIS frame/packet is 64
> bytes/512 bits.
> > Those 1000 AIS frames/packets thus generate 512 kbit/s (i.e. 0.0005
> > Gbit/s) of traffic in a further empty 10G port. This isn't any real 
> > complexity.
> > 
> > ---------
> > 
> > The alternative is to declare that open matrix connections
> are never a
> > fault condition (i.e. are always intentional and thus known
> by network
> > management). Under such starting point it is not necessary
> to detect
> > an open matrix connection as a fault condition. Now it is
> not longer
> > necessary to distinguish between connection interruption
> due to open
> > matrix and server layer fault as the first condition isn't a fault 
> > anylonger. Under this condition it is not useful that a
> server trail
> > informs its clients about a detected server trail problem that 
> > interrupts the client connections.
> > 
> > If we go for this latter approach and if in future an open matrix 
> > connection would be a fault condition, then this is a
> hidden fault and
> > you need a lot more work to locate the fault (there are no
> alarms that
> > help you).
> > 
> > Regards,
> > Maarten
> > 
> > 
> > -----Original Message-----
> > From: Igor Bryskin [mailto:[email-masked]]
> > Sent: dinsdag 28 april 2009 18:20
> > To: [email-masked]; 'Maarten Vissers'; [email-masked]; 
> > [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [mpls-tp] AIS/FDI (was Associated
> > bidirectionaltransportpathrequirements)
> > 
> > Shahram,
> > 
> > I was addressing Neil's comments about the dynamic
> re-routing, which
> > is different from protection switchover onto pre-provisioned 
> > protection connection. True, in the latter case the server layer 
> > wouldn't notice that and will keep notifying the client
> that the trail
> > is broken. But this does not change anything. The big 2
> questions in
> > my mind are:
> > 
> > a) Is the OAM of a given layer is (i) self-sufficient and
> > (ii) scalable enough, so that operator can rely on it
> completely and
> > independently from what is happening in the lower layers?
> > 
> > b) Is it beneficial if a server trail notifies its clients about a 
> > detected problem to suppress the OAM traffic and possibly
> unnecessary
> > switchovers until the server trail corrects itself?
> > 
> > Cheers,
> > Igor
> > 
> > 
> > 
> > -----Original Message-----
> > From: Shahram Davari [mailto:[email-masked]]
> > Sent: Tuesday, April 28, 2009 11:57 AM
> > To: Igor Bryskin; 'Maarten Vissers'; [email-masked]; 
> > [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [mpls-tp] AIS/FDI (was Associated
> > bidirectionaltransportpathrequirements)
> > 
> > Igor,
> > 
> > Your assumption is that there is a control plane that sets up the 
> > binding between client and server layer and that such
> binding will be
> > removed via the control plane when a reroute happens. I think this 
> > assumption is not always true. For example in a linear 1:1 or 1+1 
> > protection, there is no signalling to withdraw the binding at 
> > intermediate nodes. In
> > 1:1 there is APS, but that is end-to-end and is sent on the backup 
> > path not working path.
> > 
> > -Shahram
> > 
> >  
> > 
> > -----Original Message-----
> > From: Igor Bryskin [mailto:[email-masked]]
> > Sent: April-28-09 11:27 AM
> > To: [email-masked]; 'Maarten Vissers'; [email-masked]; 
> > [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [mpls-tp] AIS/FDI (was Associated
> > bidirectionaltransportpathrequirements)
> > 
> > Shahram,
> > 
> > Let's assume that connection A-B-C-D-E is dynamically
> provisioned by a
> > control plane. As part of such provisioning a binding is created 
> > between this connection and network C at the two adaptation
> points on
> > either side of the link provided by network C. When the
> connection is
> > torn down, this binding is removed as a part of the cleanup process.
> > The re-routing of the connection onto A-F-G-E is indistinguishable 
> > from the connection tear down as far as link C is concerned.
> > 
> > Igor
> > 
> > -----Original Message-----
> > From: Shahram Davari [mailto:[email-masked]]
> > Sent: Tuesday, April 28, 2009 11:15 AM
> > To: Igor Bryskin; 'Maarten Vissers'; [email-masked]; 
> > [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [mpls-tp] AIS/FDI (was Associated
> > bidirectionaltransportpathrequirements)
> > 
> > Hi Igor,
> > 
> > How does the server know the client is rerouted? Assume the
> following
> > networks: A-B-C-D-E (working) and A-F-G-E (protection). 
> > Assume each has its own server layer such as MPLS, MPLS-TP, ATM, 
> > SONET, etc. Assume that network C uses MPLS-TP as server layer.
> > Network C will never know there was a protection switching done for 
> > the client layer.
> > 
> > -Shahram
> > 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Igor Bryskin
> > Sent: April-28-09 11:05 AM
> > To: Maarten Vissers; [email-masked];
> [email-masked];
> > [email-masked]; [email-masked];
> [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [mpls-tp] AIS/FDI (was Associated
> > bidirectionaltransportpathrequirements)
> > 
> > Neil.
> > 
> > I actually agree with Maarten on this. I don't quite
> understand why do
> > you keep talking about fixed client-server relationship. It
> is fixed
> > as long as the client layer connection configured this way
> (statically
> > or dynamically).
> > As soon as the connection is re-routed, this relationship is broken 
> > (because this is a part of the re-routing process) and hence the 
> > server trail termination points will know that the server trail now 
> > serves one connection less, whereas some other server trail(s) will 
> > learn that they serve from now on one connection more. These new 
> > client-server relationships are fixed until the next re-routing.
> > 
> > Cheers,
> > Igor
> > 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Maarten Vissers
> > Sent: Tuesday, April 28, 2009 8:48 AM
> > To: [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked];
> [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [mpls-tp] AIS/FDI (was Associated
> > bidirectionaltransportpathrequirements)
> > 
> > Neil,
> > 
> > > However, if the client can dynamically change its routing
> > in response
> > > to link failures in its topology (because some server
> layer network
> > > has failed....which may or may not belong to the same
> > operating party
> > > as the
> > > client) then there is no fixed client/server relationship. 
> > 
> > I believe there is a fixed client/server relationship also in this 
> > case in the network. This relationship is broken when the
> connection
> > is rerouted.
> > Such reroute will remove the CP/FP and as such will stop the AIS 
> > generation.
> > 
> > There is no difference with what we do today in SDH and OTN. 
> > A client/server relationship is fixed until the point in
> time that the
> > connection is either teardown or rerouted. When either of the two 
> > cases occur, the AIS generation is stopped.
> > Until such action is performed, AIS is generated during signal fail 
> > condition period and inserted into the connection.
> > 
> > In MPLS-TP we have the requirement that MPLS-TP must be able to 
> > operate without control plane. This implies that it will operate 
> > without restoration, and that there will not be frequent rerouteing 
> > ongoing. Result is that client/server relationships will last until 
> > the connection is teardown.
> > 
> > Regards,
> > Maarten
> > 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of
> [email-masked]
> > Sent: dinsdag 28 april 2009 10:07
> > To: [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [mpls-tp] AIS/FDI (was Associated
> > bidirectionaltransportpathrequirements)
> > 
> > Nurit,
> > 
> > I believe the reason we need this discussion is that there is an 
> > unstated assumption here that the client/server
> relationship is fixed.
> > However, if the client can dynamically change its routing
> in response
> > to link failures in its topology (because some server layer network 
> > has failed....which may or may not belong to the same
> operating party
> > as the
> > client) then there is no fixed client/server relationship.
> > 
> > Refer to my post earlier today and consider what this means in the 
> > case of a cl-ps IP client layer network or a some SVC-based 
> > co-ps/co-cs mode client layer network.  The key point here is the 
> > *routing process* in the client is independent of the server layer 
> > network....so there is not a fixed client/server relationship.
> > Further, there is also no requirement for the server to
> keep track of
> > where its client traffic routings are at any epoch.....indeed why 
> > should it in the general case where these are independent layer 
> > networks?
> > 
> > So the only OAM requirement that is critical is that the OAM of the 
> > client and server layer networks are independent.  It is thus not 
> > sensible to make client layer alarm supression a 'requirement'
> > here...in fact if this is in the OAM requirements then it is 
> > technically wrong and should be removed IMO.
> > 
> > regards, Neil
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Sprecher,
> > Nurit (NSN -
> > > IL/Hod HaSharon)
> > > Sent: 28 April 2009 08:46
> > > To: ext BUSI ITALO; [email-masked]; Adrian Farrel
> > > Cc: [email-masked]
> > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional
> > > transportpathrequirements)
> > > 
> > > If we agree that the requirement is included, so why do we
> > keep with
> > > the endless discussions on this requirement?
> > > 
> > > -----Original Message-----
> > > From: ext BUSI ITALO [mailto:[email-masked]]
> > > Sent: Tuesday, April 28, 2009 10:44 AM
> > > To: Sprecher, Nurit (NSN - IL/Hod HaSharon); [email-masked]; 
> > > Adrian Farrel
> > > Cc: [email-masked]
> > > Subject: RE: [mpls-tp] AIS/FDI (was Associated
> > bidirectional transport
> > > pathrequirements)
> > > 
> > > I think that the requirements are defined in section 2.2.8 of
> > > draft-ietf-mpls-tp-oam-requirements-01
> > > 
> > > Italo
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of Sprecher,
> > Nurit (NSN
> > > > - IL/Hod HaSharon)
> > > > Sent: Tuesday, April 28, 2009 6:56 AM
> > > > To: [email-masked]; Adrian Farrel
> > > > Cc: [email-masked]
> > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional 
> > > > transport pathrequirements)
> > > > 
> > > > Huub,
> > > > I think that the requirement is to provide a mechanism to
> > suppress
> > > > alarms in the networks, to ensure that alarms that may be
> > > generated by
> > > > client layers as a result of a failure condition in the
> > server layer
> > > > may be suppressed.
> > > > Every thing else is a solution, etc. 
> > > > I propose to phrase the requirement appropriately and
> > conclude the
> > > > discussion on this in the context of the requirements
> > (until we are
> > > > getting to the solution phase).
> > > > This requirement is included in the OAM requirement draft. 
> > > > Best regards,
> > > > NUrit
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: [email-masked]
> > [mailto:[email-masked]] On
> > > > Behalf Of ext Huub van Helvoort
> > > > Sent: Tuesday, April 28, 2009 12:27 AM
> > > > To: Adrian Farrel
> > > > Cc: [email-masked]
> > > > Subject: Re: [mpls-tp] AIS/FDI (was Associated
> > > bidirectional transport
> > > > path requirements)
> > > > 
> > > > Hi Adrian,
> > > > 
> > > > You wrote:
> > > > 
> > > > > Isn't the solution here the same as the one I proposed
> > for "TCM"?
> > > > 
> > > > Indeed, and that we do not have to around in circles about TCM.
> > > > 
> > > > How about:
> > > > the requirement is that a server layer shall inform its
> > clients that
> > > > it has detected a service interuption, this to ensure that the 
> > > > clients can inhibit (unnecessary) alarms.
> > > > 
> > > > Cheers, Huub.
> > > > 
> > > > --
> > > > ================================================================
> > > >                    http://www.van-helvoort.eu/ 
> > > > ================================================================
> > > > Always remember that you are unique...just like everyone else...
> > > > _______________________________________________
> > > > mpls-tp mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/mpls-tp
> > > > _______________________________________________
> > > > mpls-tp mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/mpls-tp
> > > > 
> > > _______________________________________________
> > > mpls-tp mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mpls-tp
> > > 
> > _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> > 
> > _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> > _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> > 
> > _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> > 
> 
> 
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp