Re: [mpls-tp] Alarm Reporting (aka AIS)

[George Newsome <[e-mail]>]

Deborah,

Your caveat's (particularly "no future plans ........") sound quite 
unsafe to me.

Surely, if AIS is optional and large networks can be operated quite 
happily without it, the prudent thing to do is bite the bullet and live 
without it in all cases?

Regards,

	George

On 12/8/2010 10:47 AM, BRUNGARD, DEBORAH A (ATTLABS) wrote:
> Agree with Neil and Andy - we discussed this at great length during
> Y1731 development (and in IEEE which did not include it). If AIS is
> supported for MPLS-TP, it should be optional and the document should
> contain similar warnings on its use as in Y1731. Its use is for very
> constrained (1:1 client/server) architectures (where the operator has
> total visibility/control of the e-2-e transport/equipment to ensure it
> is constrained and they no future plans for introducing more flexible
> packet transport for the client transport anywhere along the e-2-e
> path). If one has a mixture of transport alternatives in their network,
> one will have to evaluate each MEP's application before putting into
> service and while in-service (possible on small networks, impossible for
> large networks). The danger is, if wrongly configured, one could have an
> AIS indication to a customer while the customer is still receiving
> traffic. So the customer will be able to claim service unavailability.
> This is not the SDH/PDH AIS use/mechanism (as Andy and Neil say). And
> other mechanisms exist which are much more reliable.
>
> Deborah
>
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of [e-mail]
> Sent: Wednesday, December 08, 2010 7:49 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)
>
> Nurit,
>
> I know Neil has replied. I will try and say the same thing in my own
> words.
>
> The server does not and must not know the nature of the client traffic.
> If it does, this creates a dependency between the server layer
> functionality and its clients which mean that either (1) all future
> clients must conform to the same dependency or (2) the server needs to
> be changed to accommodate new clients. Personally, I prefer to take
> independency as defining of client/server.
>
> The server can and should know about failures which interrupt or
> otherwise affect the transport of the client information across the
> server network (a MEP which is part of the termination function). So the
> server can pass up to the client layer an alarm condition, however, the
> server cannot know how to forward on this information to downstream
> nodes in the client layer. This is a truism arising out of the
> independency between client and server.
>
>
>
> However, as Maarten correctly pointed out, an adaptation function can
> know this information. The adaptation is not part of the server layer
> and can be specific to each client. It is the client layer's "stub" to
> interface to the server layer.
>
>
>
> Within the TDM world, the destination of each timeslot is
> *preconfigured* as an inherent part of the connection set up process and
> the forwarding of each timeslot is predetermined by this
> preconfiguration. As such, each timeslot does not carry any forwarding
> information. This means that the adaptation function can fill each
> timeslot with the alarm condition (AIS) without any knowledge of
> downstream forwarding - the adaptation function has no dependency on any
> forwarding information. This makes the implementation of AIS in TDM
> simple and highly reliable.
>
>
>
> However, as Neil points out, this is not the case with packets. With
> packets, forwarding information is carried in the header of each packet
> with downstream forwarding is fundamentally based on this information.
> This information is lost whenever there is a server layer failure.
> **Therefore the adaptation function cannot insert the alarm condition
> without itself having a prior knowledge of this forwarding
> information.** This is fundamentally different to the TDM case and
> arises from the very definition of packets.
>
>
>
> So how can this be achieved. There are three alternatives, none
> attractive. Nor do I believe there is total clarity between two of
> these, what is actually proposed for MPLS-TP.
>
>
>
> 1) The direct analogy with TDM would be for the adaptation function to
> systematically send an AIS packet to every possible label value. Given
> the size of the MPLS label space, this is not remotely practical.
>
>
>
> 2) Implement the AIS as an integral and required part of each and every
> packet forwarding engine. As the forwarding engine is configured with
> the forwarding information as part of any connection set process
> (signalled or NMS), this requires no more configuration than the TDM
> case. However, there are two immediate drawbacks to this. First, as I'm
> aware the current installed based of MPLS switches are neither designed
> nor configured to automatically add an AIS packet flow to each
> configured LSP passing through an input port to the switch. Moreover, it
> requires that the forwarding semantics carry input (server sink) port
> information.
>
>
>
> 3) Implement the AIS as an additional capability within the adaptation
> function. However, this now needs to be configured with the correct
> forwarding information (ie a set of active label values). If the AIS is
> not an integral part of the connection set up process, this
> configuration information will need to be separately calculated and
> configured (for example by snooping) which means that the tie back of
> this information to the connection set up information can itself now be
> error/fault prone. Moreover, errors in the configuration data are
> unlikely to become apparent until there is a server layer failure and
> the AIS insertion is exercised. This means that inevitably, at the time
> of a failure downstream cannot have full confidence in the AIS
> information. Moreover, some adaptation may not be configured at all, and
> so a client path failure with a lack of AIS will be an especially
> untrustworthy condition. This is fundamentally different to the highly
> reliable AIS of the TDM world.
>
>
>
> In practice, I'm sure we are talking about the third of these, which as
> I point out, from the practical operational point of view, is
> fundamentally different to TDM AIS as it is trustworthy in the same way.
> Sometimes, especially when talking with Maarten, I think he is referring
> to the second of these (and I may be wrong), which while operationally
> more reliable, I don't think is realistic.
>
>
>
> Hope this clarifies.
>
>
>
> Andy
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Andy Reid
> Chief Network Services Strategist
> BT Innovate
>
>
> Office: [phone]
> Mobile: [phone]
> Fax :       [phone]
> Email:  [e-mail]<mailto:[e-mail]>
> WWW:    http://www.bt.com/
>
> This email contains BT information, which may be privileged or
> confidential.
> It's meant only for the individual(s) or entity named above. If you're
> not the intended
> recipient, note that disclosing, copying, distributing or using this
> information
> is prohibited. If you've received this email in error, please let me
> know immediately
> on the email address above. Thank you.
> We monitor our email system, and may record your emails.
>
> British Telecommunications plc
> Registered office: 81 Newgate Street London EC1A 7AJ
> Registered in England no: 1800000
>
>
>
> 	
>
> 	
> ________________________________
>
>
> 	From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
> 	Sent: 08 December 2010 02:06
> 	To: [e-mail]
> 	Cc: Zhao, Peng (NSN - CN/Shanghai)
> 	Subject: [mpls-tp] Alarm Reporting (aka AIS)
>
> 	Hi,
>
> 	I have a question about the functionality of Alarm Reporting....
>
> 	Assuming that there is a failure at a server layer somewhere
> across the network....and the MEP of the server layer identifies it and
> needs to ensure that Alarm Reporting is sent to all of the MEPs of the
> client services that transmit over the failed server...but it may be
> that some of the client services do not have MEPs....how does the node
> detecting the server failure knows which client services have MEPs and
> an Alarm Reporting message needs to be sent to their MEPs and which do
> not have MEPs and an Alarm Reporting message must not be sent for these
> client services....(as we would not like to flood the network with
> unnecessary traffic)....
>
> 	I hope someone can clarify it to me.
>
> 	Best regards,
>
> 	Nurit
>
>
>
>
>
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp