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

["t.petch" <[e-mail]>]

----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>om>; <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, December 08, 2010 9:37 AM
Subject: Re: [mpls-tp] Alarm Reporting (aka AIS)


Nurit....perhaps you don't read my posts or those of Andy Reid?  We have some
considerable expertise/experience in this whole area.  Let me have one more go
at repeating the salient points:

AIS comes from the regular time-slice (TDM) co-cs world of PDH.  However, it
also requires a permanent binding of a client to a server.  In this mode of
network one MUST fill the time-slices (==resource) with something on failure.
AIS happens be a binary all 1s signal because that is just how the original TTL
logic failed in the early PDH mux equipment (floated to +5V).

The moment you remove either of the above conditions (ie regular time-slice or
permanent client/server binding) then AIS is not only a waste of time but its
something else to configure (esp identifying who to send it to...also see below)
and go wrong.

AIS is most obviously wrong for the cl-ps mode.....here we don't have a parent
connection of child traffic units...the traffic units themselves MUST fully
self-formed/sustaining.  AIS would be plain daft here.  It's why IETF have never
seen the need for it in IP and IEEE had the good sense to throw it out of
Ethernet OAM in 802.1ag....ITU OTOH foolishly kept it in Y.731....but this was
largely to satisfy the TCM stuff (which is also a waste of time/money but that
is for a somewhat different reason).

I used to think AIS might be useful for the co-ps mode (though it still requires
the assumption of permanent client/server binding AND it now requires explicit
labelling of every AIS packet => hint not a good idea for reasons that should
become clear shortly), but many years ago Andy/I/others discussed this topic in
some detail and we reached a unanimous conclusion that AIS is technically
completely unnecessary.  Moreover, one is far better off without it for many
reasons consequential reasons, eg having to label each traffic unit, something
else to go wrong, etc.  All one needs technically in the co-ps mode is the OAM
pair CV and BDI functions (however one does these)...this is quite simple to
prove.  And this is 'per se'......that is, I am not even considering all the
horrors that accompany the TCM ideas.....which BTW is perhaps the
self-fulfilling reason to require AIS here (the notification arguments don't
hold water as I noted).

BTW - You are starting to discover below why one needs a permanent client/server
binding to make AIS viable (even in the co-cs mode), ie one needs a clear
knowledge of who to send it to and also require that they 'don't go away'.  If
not clear think of the PSTN and some SDH VC4 supporting a large number of 64k
link connections with live calls between a pair of PSTN nodes.  Suppose the SDH
VC4 path fails.....one can now send AIS towards the 64k access points of the 64k
PSTN paths that are affected.  But since users won't be able to communicate
anyway they will clear down, ie they will signal path tear-down...one can think
of this as the users providing their own 'CV detection' OAM of the DP....sending
AIS towards won't help them make that decision!  So after this which access
points of the 64k layer network will one send the SDH VC4 AIS to?   Would you
send to all the possible access points that might use that failed SDH VC4 path
in the future, eg every single PSTN access point in the world?

We should not have AIS in the co-ps mode and we should not have TCM in any
mode.....and using TCM as the reason to require AIS (which IMO is the case) is
literally quite barking mad.  I hope you can see this now.

<tp>

Neil

I notice that the recently liaised G.tpoam defines AIS as

"When the server layer trail termination sink asserts signal fail, it notifies
the server/MT_A_Sk
function that raises the aAIS consequent action.  "

Perhaps we should note that in a packet layer network, there is no signal and so

signal fail can never be asserted so AIS is a null condition.  In which case,
G.tpoam is spot on.

Tom Petch

</tp>
regards, Neil

________________________________
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
>