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

From: Maarten Vissers <[email-masked]>
Date: Mon, 04 May 2009 14:42:11 +0200

Please be aware that in order to support AIS in any of the circuit transport
network technologies (PDH, SDH, OTN) it is required to provide an AIS clock
generator circuit at the point of AIS insertion. The AIS signal must comply
with the frequency requirements of the signal being replaced. 

In a number of cases the AIS clock frequency can be created via a two step
process; i.e. by using the clock of the server layer signal plus a nominal
justification control pattern.

Generating a once-per-second fixed AIS OAM message in MPLS-TP will be less
complex then generating AIS in e.g. OTN.

Regards,
Maarten

---

From: George Newsome <[email-masked]>
Date: Mon, 04 May 2009 09:33:40 -0400

> complex then generating AIS in e.g. OTN.

But as Andy showed, in the packet layer, we seem to be able to have the 
alarm suppression behaviour without any AIS/FDI replacement signal 
insertion at all.

We all know that the most reliable component is the one that is not 
there, so discussing the complexity of something that is unnecessary 
doesn't seem very useful.

Regards,

	George

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 04 May 2009 18:18:40 +0200

George,

We don't have the alarm suppression behaviour without any AIS/FDI
replacement signal insertion in packet layer. 

Andy states that alarm suppression is not necessary. 

I.e. he suggests that equipment just generate all alarms and let the NMS
figure out which of those alarms are primary faults that require action to
restore connectivity, and which are consequential faults that should be
ignored. I.e. it is going back in time about 20-25 years when equipment did
not filter any of the defects detected and was just sending it all to the
NMS. You will get very nice alarm storms in this case.

Regards,
Maarten

-----Original Message-----
From: George Newsome [mailto:[email-masked]] 
Sent: maandag 4 mei 2009 15:34
To: Maarten Vissers; [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was
Associatedbidirectionaltransportpathrequirements)

Maarten Vissers wrote:
>  
> Please be aware that in order to support AIS in any of the circuit 
> transport network technologies (PDH, SDH, OTN) it is required to 
> provide an AIS clock generator circuit at the point of AIS insertion. 
> The AIS signal must comply with the frequency requirements of the signal
being replaced.
> 
> In a number of cases the AIS clock frequency can be created via a two 
> step process; i.e. by using the clock of the server layer signal plus 
> a nominal justification control pattern.
> 
> Generating a once-per-second fixed AIS OAM message in MPLS-TP will be 
> less complex then generating AIS in e.g. OTN.
>

But as Andy showed, in the packet layer, we seem to be able to have the
alarm suppression behaviour without any AIS/FDI replacement signal insertion
at all.

We all know that the most reliable component is the one that is not there,
so discussing the complexity of something that is unnecessary doesn't seem
very useful.

Regards,

	George

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 05 May 2009 08:29:44 +0200

George,

If station alarms are still in use, then the absence of alarm suppression
will also activate in many offices the audible and visible indicators (bells
and lamps) to draw attention to the detected loss of CC conditions.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: maandag 4 mei 2009 18:19
To: 'George Newsome'; [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was
Associatedbidirectionaltransportpathrequirements)

George,

Regards,
Maarten

-----Original Message-----
From: George Newsome [mailto:[email-masked]]
Sent: maandag 4 mei 2009 15:34
To: Maarten Vissers; [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was

being replaced.

Regards,

	George

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: George Newsome <[email-masked]>
Date: Tue, 05 May 2009 09:21:56 -0400

> Andy states that alarm suppression is not necessary. 
Andy will have to address that himself, however I read Andy as saying 
that the AIS inserted signal does not add any information over and above 
what a node already has.

He is right about that; alarm suppression can be driven by the 
information that the node already has. This is why is is critical to 
separate the behaviour from the mechanism.

Only the behaviour is required.

Regards,

	George

---

From: George Newsome <[email-masked]>
Date: Tue, 05 May 2009 10:26:42 -0400

> and lamps) to draw attention to the detected loss of CC conditions.
This is reason why we need alarm suppression, but this is stating the 
obvious. We all agree with that need.

Strictly speaking, alarm suppression is what we do with the information 
that a fault is upstream, so a root cause analysis shows that alarm 
suppression is not the most primitive information requirement.

What some of us are trying to achieve is the separation of the 
requirements from the mechanisms available to implement those requirements.

There is no more need to argue why we need to suppress alarms, and this 
is not the right time to argue about how to achieve that end.

Regards,

	George

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 05 May 2009 18:23:18 +0200

George,

> alarm suppression can be driven by the information that the node already
has.

This is what I do not believe is correct. The "node" does not have the
necessary information to perform alarm suppression if there is no alarm
suppression maintenance signal (e.g. AIS) inserted at the location that
detects the signal fail type defect. 

As you seem to have a different understanding then I have, I would be
pleased if you could describe the information that a node has to perform
alarm suppression. Please use the following example:

CEa -- TPE1 -- SPE2 -- P3 -- SPE4 -- P5 -X- P6 -- P7 -- SPE8 -- P9 -- SPE10
-- TPE11 -- CEb
                                           P-LOS        P-LOC
C-LOC
                                           S-LOC

1) a MPLS-TP network with access, metro and core domains
2) a MPLS-TP T-PE node is located at the edge of this network (TPE1, TPE11)
3) MPLS-TP S-PE nodes are located at the boundary of access and metro
domains (SPE2, SPE10) and at the boundary of metro and core domains (SPE4,
SPE8)
4) MPLS-TP P nodes are located inside the metro domains (interconnecting
S-PE nodes at edge of metro domain; P3, P9) and inside the core domain
(interconnecting the S-PE nodes at edge of core domain; P5,P6,P7)
5) cable break fault condition between two adjacent P nodes in the core
domain (between P5 and P6), with unprotected LSPs.

I expect that the following will happen in those nodes:

A) NNI input port on P6 will detect a PHY Loss Of Signal (P-LOS) defect and
must alarm this as primary fault cause/failure.

B) NNI input port on P6 will detect a Section Loss Of CC (S-LOC) defect.
Without alarm suppression this S-LOC will also be alarmed as primary fault
cause/failure.

C) NNI input port on SPE8 will detect one or more LSP Path Loss Of CC
(P-LOC) defects. Without alarm suppression maintenance signal (e.g. LSP-AIS)
the node SPE8 will not be able to determine if this P-LOC is a primary fault
cause (i.e. open matrix in e.g. P7), or if it is a secondary (server layer)
fault cause. SPE8 will thus alarm P-LOC as a primary fault cause/failure.

D) UNI-N output port on TPE11 will detect one or more PW or EVC Channel Loss
Of CC (C-LOC) defects. Without alarm suppression maintenance signal (e.g.
PW-AIS/ETH-AIS) the node TPE11 will not be able to determine if this C-LOC
is a primary fault cause (i.e. open matrix in e.g. SPE8), or if it is a
secondary (server layer) fault cause. TPE11 will thus alarm C-LOC as a
primary fault cause/failure.

Regards,
Maarten

-----Original Message-----
From: George Newsome [mailto:[email-masked]] 
Sent: dinsdag 5 mei 2009 15:22
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was

> Andy states that alarm suppression is not necessary. 
Andy will have to address that himself, however I read Andy as saying that
the AIS inserted signal does not add any information over and above what a
node already has.

He is right about that; alarm suppression can be driven by the information
that the node already has. This is why is is critical to separate the
behaviour from the mechanism.

Regards,

	George

> I.e. he suggests that equipment just generate all alarms and let the 
> NMS figure out which of those alarms are primary faults that require 
> action to restore connectivity, and which are consequential faults 
> that should be ignored. I.e. it is going back in time about 20-25 
> years when equipment did not filter any of the defects detected and 
> was just sending it all to the NMS. You will get very nice alarm storms in
this case.
> But as Andy showed, in the packet layer, we seem to be able to have 
> the alarm suppression behaviour without any AIS/FDI replacement signal 
> insertion at all.
>

---

From: <[email-masked]>
Date: Tue, 5 May 2009 18:27:09 +0100

Observation:

How come X.25, FR and MPLS (all co-ps mode...if we exclude MPLS LDP/PHP)
seemed to work just fine without DP AIS?

How come IPv4 and IPv6 work fine without DP AIS?

How come IEEE threw DP AIS out of Ethernet OAM in 802.1ag?

AIS in the DP is something we got from the co-cs world.  You have to put
some signal in here when there is a failure so having a DP AIS signal
makes sense here.  But this does not mean it makes sense for cl/co
packet-switched networks.

The 3 network modes are different.  We all know this
intuitively/empirically from practical experience, and we now know the
scientific reasons for this as G.800 explains.

It is not sensible Maarten to try and make all network
modes/technologies look alike in all DP/CP/MP facets.

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: 05 May 2009 17:23
> To: 'George Newsome'
> Cc: [email-masked]

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 05 May 2009 19:34:05 +0200

George,

See inline... 

-----Original Message-----
From: George Newsome [mailto:[email-masked]] 
Sent: dinsdag 5 mei 2009 16:27
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was

Maarten Vissers wrote:
>  
> George,
> 
> If station alarms are still in use, then the absence of alarm 
> suppression will also activate in many offices the audible and visible 
> indicators (bells and lamps) to draw attention to the detected loss of CC
conditions.

[mv] Thank you for agreeing with the need for alarm suppression.

Strictly speaking, alarm suppression is what we do with the information that
a fault is upstream, so a root cause analysis shows that alarm suppression
is not the most primitive information requirement.

What some of us are trying to achieve is the separation of the requirements
from the mechanisms available to implement those requirements.

There is no more need to argue why we need to suppress alarms, and this is
not the right time to argue about how to achieve that end.

[mv] If I understand you, then there is agreement about the need for alarm
suppression. But it is too early to discuss the method to implement this
alarm suppression.

[mv] With other words, we should postpone the remainder of this discussion
until a later point in time.

{mv] In parallel to the requirement work there is work on OAM analysis and
OAM specifications ongoing. As such it seems the right time to discuss the
alarm suppression method as part of this OAM work.

Regards,
Maarten

Regards,

	George

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Maarten Vissers
this case.

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 05 May 2009 19:54:30 +0200

Neil,

As George stated in his response, there is agreement on the need for alarm
suppression.

I have presented an example to George to describe how he thinks such alarm
suppression would be realized without the presence of an alarm suppression
maintenance signal (like AIS/FDI).

I ask the same question now to you. Please describe how you think we can
support such alarm suppression.

Looking forward to your alarm suppression method. 
Note that if you can't find such alarm suppression method without the use of
a maintenance signal (e.g. AIS), then not answering this question is
considered by me as a confirmation that MPLS-TP needs AIS.

Thanks,
Maarten 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 5 mei 2009 19:27
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was

Observation:

AIS in the DP is something we got from the co-cs world.  You have to put
some signal in here when there is a failure so having a DP AIS signal makes
sense here.  But this does not mean it makes sense for cl/co packet-switched
networks.

The 3 network modes are different.  We all know this intuitively/empirically
from practical experience, and we now know the scientific reasons for this
as G.800 explains.

It is not sensible Maarten to try and make all network modes/technologies
look alike in all DP/CP/MP facets.

regards, Neil

> necessary information to perform alarm suppression if there is no 
> alarm suppression maintenance signal (e.g. AIS) inserted at the 
> location that detects the signal fail type defect.
> 
> pleased if you could describe the information that a node has to 
> perform alarm suppression. Please use the following example:
> 
> 4) MPLS-TP P nodes are located inside the metro domains 
> (interconnecting S-PE nodes at edge of metro domain; P3, P9) and 
> inside the core domain (interconnecting the S-PE nodes at edge of core 
> domain; P5,P6,P7)
> 5) cable break fault condition between two adjacent P nodes in the 
> core domain (between P5 and P6), with unprotected LSPs.
> 
> Without alarm suppression this S-LOC will also be alarmed as primary 
> fault cause/failure.
> 
> (P-LOC) defects. Without alarm suppression maintenance signal (e.g. 
> LSP-AIS) the node SPE8 will not be able to determine if this P-LOC is 
> a primary fault cause (i.e. open matrix in e.g. P7), or if it is a 
> secondary (server layer) fault cause. SPE8 will thus alarm P-LOC as a 
> D) UNI-N output port on TPE11 will detect one or more PW or EVC 
> Channel Loss Of CC (C-LOC) defects. Without alarm suppression 
> maintenance signal (e.g.
> PW-AIS/ETH-AIS) the node TPE11 will not be able to determine if this 
> C-LOC is a primary fault cause (i.e. open matrix in e.g. SPE8), or if 
> it is a secondary (server layer) fault cause. TPE11 will thus alarm 
> C-LOC as a primary fault cause/failure.
> 
> Regards,
> Maarten
> 
> 
> that the AIS inserted signal does not add any information over and 
> above what a node already has.
>

---

From: <[email-masked]>
Date: Tue, 5 May 2009 19:35:12 +0100

> How come IEEE threw DP AIS out of Ethernet OAM in 802.1ag?

It is not a good idea IMO to insist some feature being essential when
many there are many networks that work quite happily without that
feature.  This is an irrefutable proof-by-existence that such an
assertion is wrong.

There are also similar assertiosn of the need for TCM and peer-partition
I/W of different modes/technologies.....but a moments throught shows
these are not good ideas either. 

But to answer your question:
(i) I think the alarm storm problem is grossly overplayed....if you
trawl the mail archives you will find at least 2 previous occasions
where I made this remark....but see the above comments to observe this
is not merely 'my opinion' it is a plain fact of many networks already!
(ii) If I own all the layer networks to the duct then I can seek
cross-layer correlation in the NMS/OSS....if I don't then too bad....but
hey as noted above we seemed to do OK before.  Moreover, if I don't own
all the layers I can't rely on the owner of the lower layers fixing the
problem.....I need to be able act in my own layer to problems that
affect it however they are created....and the 'alarm supression' feature
is hardly top of my priorioties in such a case.
(iii) I do not want to introduce a 'feature' in the DP of a network mode
where it is not native and that might impact scalability and
reliability.

regards, Neil

> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: 05 May 2009 18:55
> To: Harrison,N,Neil,CXM R; [email-masked]
> Cc: [email-masked]
> intuitively/empirically
> > 2) a MPLS-TP T-PE node is located at the edge of this 
> network (TPE1, 
> > TPE11)
> > >> The AIS signal must comply with the frequency 
> requirements of the 
> > >> signal
> > > being replaced.

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 05 May 2009 21:26:01 +0200

Neil,

As indicated in previous responses to your questions, let me answer once
more:

> How come X.25, FR and MPLS (all co-ps mode...if we exclude MPLS 
> LDP/PHP) seemed to work just fine without DP AIS?

AIS (alarm suppression) is necessary when there is continuity checking (CC)
performed. X.25, FR and MPLS don't have that. So there is no application for
AIS in those technologies.

> How come IPv4 and IPv6 work fine without DP AIS?

AIS (alarm suppression) is necessary when there is continuity checking (CC)
performed. IP VPNs (i.e. the IP transport entities) don't have that. So
there is no application for AIS in this technology.

> How come IEEE threw DP AIS out of Ethernet OAM in 802.1ag?

FYI, I was involved in that decision process. 802.1ag has as mandatory
pre-condition the presence of spanning three protocol and xVRP. After
detection of a signal fail condition, those control plane processes remove
the registration of the VLANs from the ETH link ends; i.e. remove the ETH
Flow Point bindings. As a result the ETH transport entities don't exist
anylonger and it is not possible to insert ETH-AIS. 

In Ethernet transport networks spanning tree and xVRP protocols are not
deployed. In those networks the ETH flow points are not removed when e.g. a
link breaks. As a consequence it is necessary and possible to insert ETH-AIS
from the link end connected to a failed server trail.

Having provided answers to your questions, I look forward to a true answer
to my question; i.e. how to suppress the consequential alarms in this case
without the presence of AIS.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 5 mei 2009 20:35
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was

Please be so gracious as to answer my initial mail too .....I repeat:

> How come X.25, FR and MPLS (all co-ps mode...if we exclude MPLS 
> LDP/PHP) seemed to work just fine without DP AIS?
> 

It is not a good idea IMO to insist some feature being essential when many
there are many networks that work quite happily without that feature.  This
is an irrefutable proof-by-existence that such an assertion is wrong.

There are also similar assertiosn of the need for TCM and peer-partition I/W
of different modes/technologies.....but a moments throught shows these are
not good ideas either. 

But to answer your question:
(i) I think the alarm storm problem is grossly overplayed....if you trawl
the mail archives you will find at least 2 previous occasions where I made
this remark....but see the above comments to observe this is not merely 'my
opinion' it is a plain fact of many networks already!
(ii) If I own all the layer networks to the duct then I can seek cross-layer
correlation in the NMS/OSS....if I don't then too bad....but hey as noted
above we seemed to do OK before.  Moreover, if I don't own all the layers I
can't rely on the owner of the lower layers fixing the problem.....I need to
be able act in my own layer to problems that affect it however they are
created....and the 'alarm supression' feature is hardly top of my
priorioties in such a case.
(iii) I do not want to introduce a 'feature' in the DP of a network mode
where it is not native and that might impact scalability and reliability.

regards, Neil

> As George stated in his response, there is agreement on the need for 
> alarm suppression.
> 
> I have presented an example to George to describe how he thinks such 
> alarm suppression would be realized without the presence of an alarm 
> suppression maintenance signal (like AIS/FDI).
> 
> I ask the same question now to you. Please describe how you think we 
> can support such alarm suppression.
> 
> Note that if you can't find such alarm suppression method without the 
> use of a maintenance signal (e.g. AIS), then not answering this 
> question is considered by me as a confirmation that MPLS-TP needs AIS.
> 
> Thanks,
> Maarten
> 
> How come X.25, FR and MPLS (all co-ps mode...if we exclude MPLS 
> LDP/PHP) seemed to work just fine without DP AIS?
> 
> AIS in the DP is something we got from the co-cs world.  You have to 
> put some signal in here when there is a failure so having a DP AIS 
> signal makes sense here.  But this does not mean it makes sense for 
> cl/co packet-switched networks.
>

---

From: George Newsome <[email-masked]>
Date: Thu, 07 May 2009 10:59:10 -0400

Hi Maarten,

You asked for more explanation of why we can live without an AIS 
replacement signal in mpls-tp - see below.

> alarm suppression. Please use the following example:
Adding a complicated example degenerates into specification by 
exhaustive list, and I am not going to do that. Instead I am going to 
try to get though something very simple in the hope that you can see 
what the AIS signal is actually doing, and why it is not needed at any 
layer above the fiber.

Consider a simple regen section. This has an outgoing monitor at the 
output of the upstream regen and an outgoing monitor at the output of 
"this regen."

The way fault monitoring works is that a process in the regen compares
the state of the incoming server (the fiber) with the state of the
outgoing client signal.

When the regen sees a bad output signal it does not know if the problem
is local or is associated with an upstream regen section: it needs to
know about the state of the fiber between itself and the upstream regen,
and this is where the AIS replacement signal comes in. If the regen is 
receiving the AIS replacement signal, then it knows that there is no 
fiber fault, and concludes that the bad output signal is not being 
caused by this regen section, but by one further upstream.

The AIS replacement signal is monitoring the fiber between the upstream
regen and this regen, and it is essential for this purpose because the
fiber has no OAM of its own. (This is may clearer when we think of SDH 
over ODU - the SDH AIS replacement signal is doing the same thing as the 
ODU monitoring).

This is further generalized by noting that if there is nothing wrong 
with any of the servers that are holding up the monitored client, then 
the client observed fault is not in this section. It can be further
generalized to the observation that as long as the server has its own
OAM, there is no need for an AIS replacement signal at this layer. This 
is certainly true for mpls-tp, which does not run directly over fiber. 
Its server certainly has its own OAM, so an mpls-tp AIS replacement 
signal is unnecessary. (It is also true for ODU's, but we didn't notice 
that then).

This is all obvious once we get out of the notion that AIS is about
carrying the results of a server/client correlation to all points of the
network. We can have the same effect by making the correlation
independently at every NE instead.

Hopefully this explains Andy's observations and shows how we can have 
our cake (the required alarm behavior) and eat it too (avoid replacement 
signal injection along the trail).

Regards,

	George

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 08 May 2009 11:36:04 +0200

Hi George,

> replacement signal in mpls-tp - see below.

I fail to see how a regenerator behaviour compares to a router
behaviour. A router is more like an ADM or DXC.

Your example applies only to 1R and 2R regens not to 3R regens.
The AIS replacement signal may have been an oversimplification
by cost aware engineers.
The replacement signal should have been a framed signal with the
payload replaced by a fixed pattern, this would have served the
two purposes now covered by a single signal:
- show conductivity for the section
- the fixed pattern in the payload can be used by the users (clients)
   to detect a *remote* defect.
(this is actually what a 3R regen does).

In MPLS-TP the CC provides the conductivity.
If a server layer fails, there are no packets transited, including
the CC, so isn't there a need to show conductivity?

Regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: George Newsome <[email-masked]>
Date: Fri, 08 May 2009 13:05:03 -0400

> behaviour. A router is more like an ADM or DXC.
Now that surprises me!

What I described is a pair of monitors with "structured stuff" in 
between. Any equipment can be described as a set of these structures. As 
you know, describing every equipment known does not elucidate a 
principle which can be applied to both todays equipment as well a to new 
equipment. Because this principle works at the bottom of the layer stack 
and over intervening layers, it is generally applicable.

> Your example applies only to 1R and 2R regens not to 3R regens.
Not true.
It is true that a single section implementation lumps the regen hardware 
with the fiber, so if you want to distinguish between the regen and the 
fiber, you must create two sections by adding an input monitor. One 
section for each purpose. This of course does not invalidate the 
principle. It merely applies it.

> (this is actually what a 3R regen does).
There is no doubt that a replacement signal is needed at the fiber 
layer, nor that it could be made horrendously complicated. However there 
is equally no doubt that it is not needed at any other layer, nor is it 
needed for any other purpose than continuity checking of a non monitored 
server layer.

> the CC, so isn't there a need to show conductivity?
The servers that mpls-tp is to run on already provide monitoring, and it 
is that OAM which shows the server conductivity. mpls-tp will not run 
natively over a fiber, so does not need to carry its own baggage for 
server conductivity checking.

Regards,

	George

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 08 May 2009 19:53:41 +0100

George,

> server conductivity checking.

This is a key point IMO. A piece of MPLS-TP equipment can determine whether
a failure is local/remote by correlating information acquired from the
various layer networks which terminate on it. It doesn't need to have all
the information it requires be present in the MPLS-TP layer network.

Ben

---

From: "Heiles, Juergen (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 15 May 2009 14:08:27 +0200

Hi colleagues,

I have been quiet for a long time, but now I think I have to add my 2
cents to this discussion.

Different purposes of the AIS signal are mixed in the discussion.
1. In a TDM circuit switched network the resources for a certain
connection (the time slots) are fixed assigned and have to be filled
even if the connection is interrupted due to an upstream server layer
failure. This replacement signal has to fulfill certain criteria like
for timing in order to prevent strange behavior and failure conditions
downstream like buffer overflow/underflow. One may generate a random
pattern or just send what is in the buffer. Such patterns however may
result in some strange defect detections downstream (at non-intrusive
monitors or path termination) which could have a negative impact on
protection switching. Therefore it makes sense to generate a well
defined replacement signal. 
-> AIS purpose: a well behaving signal to prevent strange and unwanted
behaviors downstream of the failure with the layer network

2. One transport network paradigm is to have layer networks decoupled so
that each layer network can be operated on its own. When we move to the
physical layers or close to them this is however no longer 100%
fulfilled. The SDH Regenerator section depends on the clock from the
Multiplex section (the same applies for OTU and ODU). If a MS fails a
replacement at least of the clock is required in order to have a correct
behavior at the downstream RS and other server layers. The Optical and
electrical layer require a certain pattern from their digital client
layers like RS or OTU in order to work correctly
-> AIS purpose: ensure correct operation of downstream server layers in
cases where server and client layers are not 100% decoupled (this is the
example from George).

3. A failure of a server layer connection may effect a large number of
client layer connections that are transported via this connection.
These client layer connections are terminated and monitored at network
elements that are far way from the actual failure location. They might
be even in a different management or operator domain. Without AIS all of
them would raise a primary failure alarm (loss of connectivity). While a
network element can differentiate between local and remote failures
based on local information, it cannot differentiate between a failure at
the monitored layer network or some server layer networks upstream. With
AIS it is possible.
-> AIS purpose: alarm correlation to prevent alarm storms and
differentiate between failures at the layer network and at server layer
networks.

As a side effect, AIS detection is often much faster as loss of
connectivity detection (e.g. SDH VC-4 TTI mismatch vs. AU-AIS detection)
and can trigger protection switching therefore faster. So this might not
be the case for MPLS-TP depending on the specific methods that will be
used.

For MPLS-TP item 1 doesn't apply as it is a packet layer network which
doesn't require that packets are constantly sent for a certain
connection.
Item 2 does also not apply as the MPLS-TP layer network is decoupled
from other layer networks concerning its operation (I assume so;-).
This leaves us with item 3 which applies to any kind of transport
network technology. So it is not a must have I see it as very useful.
Some operators might not be interested in it at all or do alarm
correlation in the network management. Still they can do that. They have
to enable AIS alarm reporting and treat AIS alarms in the same way as
loss of connectivity alarms.

Regards

Juergen

>[mailto:[email-masked]] On Behalf Of ext Ben Niven-Jenkins
>Sent: Friday, May 08, 2009 8:54 PM
>To: George Newsome; [email-masked]
>Cc: [email-masked]

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 15 May 2009 16:23:17 -0400

Dear Jurgen,
your analysis is very helpful to me and I thank you. I believe that your
conclusion only strengthens to point expressed many times on the list - we
need to decouple requirements from specific solutions. I think that we have
requirement for case #3 in place and that solution to it might not
necessarily be AIS.

Regards,
Greg

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 16 May 2009 09:58:31 +0300

Juergen,

You've presented a very clear-cut analysis of the mixed implicit requirements which are addressed by AIS in TDM-based networks.

You've also demonstrated that some of these requirements are not applicable to packet-based networks restricting potential usefulness of AIS to a single use case - an "alarm correlation helper" in the hierarchy of MPLS-TP layers.

The point that remains yet unclear to me is, can this use case be addressed within the framework of MPLS data plane architecture?

To the best of my understanding, in order to achieve the required functionality, the termination point of a lower-layer LSP in MPLS-TP MUST be aware of each individual client LSP.

Please note that such awareness was not required in TDM networks, since it was possible to spread the AIS pattern ("all ones") across all potential clients. This kind of behavior is clearly not applicable to MPLS-TP.

In the case of ATM, awareness of the server layer (VPC) termination point of every specific client (VCC) is an integral part of the data plane since VPI values have only meaning within the scope defined by the containing VPC. In other words, regardless of the AIS, the server layer had to be aware of each specific client since otherwise traffic could not be forwarded correctly. AIS propagation in this case was more complicated than in the TDM case, but still free.

On the other hand the MPLS data plane architecture as described in RFC 3031 (Section 3.14) recognizes just two types of label scope:

 *   Per-platform
 *   Per interface.

And it also defines (in Sections 3.10, 3.11 and 3.13) that forwarding is done by looking up the label at the top of the label stack. (Multiple label look-ups, regardless of implementation, mean popping the top label and forwarding the still labeled packet to the "loopback interface").

IMHO and FWIW this means that MPLS data plane does not, per se, require the server termination point awareness of each and every specific client within the terminated server LSP.

Hence MPLS-TP actually presents two choices:

 1.  Explicitly require such an awareness. This would enable (among other things) AIS but would be probably costly in the terms of look-ups
 2.  Preserve existing flexibility of the MPLS data plane, and drop the AIS-related requirement.

Did I miss something?

Regards,

     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Heiles, Juergen (NSN - DE/Munich) [[email-masked]]
Sent: Friday, May 15, 2009 3:08 PM
To: ext Ben Niven-Jenkins; George Newsome; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was     Associatedbidirectionaltransportpathrequirements)

Hi colleagues,

Regards

---

From: "Heiles, Juergen (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 26 May 2009 11:50:42 +0200

Hi Sasha,
 
see my comments below.
 
Regards
 
Juergen

________________________________

	From: ext Alexander Vainshtein
[mailto:[email-masked]] 
	Sent: Saturday, May 16, 2009 8:59 AM
	To: Heiles, Juergen (NSN - DE/Munich)
	Cc: [email-masked]; George Newsome; ext Ben Niven-Jenkins;
[email-masked]
	Subject: RE: [mpls-tp] AIS/FDI
(wasAssociatedbidirectionaltransportpathrequirements)

	Juergen, 

	You've presented a very clear-cut analysis of the mixed implicit
requirements which are addressed by AIS in TDM-based networks.

	You've also demonstrated that some of these requirements are not
applicable to packet-based networks restricting potential usefulness of
AIS to a single use case - an "alarm correlation helper" in the
hierarchy of MPLS-TP layers.

	The point that remains yet unclear to me is, can this use case
be addressed within the framework of MPLS data plane architecture?

	To the best of my understanding, in order to achieve the
required functionality, the termination point of a lower-layer LSP in
MPLS-TP MUST be aware of each individual client LSP. 

	[JH] Yes, or the other way the client adaptation has to be aware
over which server layer trail the client was transported.

	Please note that such awareness was not required in TDM
networks, since it was possible to spread the AIS pattern ("all ones")
across all potential clients. 
	[JH] This is not really true as the (PDH) AIS pattern also has
to be with the correct bit rate which is client specific. In SDH the
AU/TU AIS in the pointer takes care of the timing, but as the pointer is
not passed thru the buffer you have to know the AU/TU structure. A TDM
network element is always aware about the client signals transported in
a server layer trail (implicitly or by configuration).

	 This kind of behavior is clearly not applicable to MPLS-TP.

	In the case of ATM, awareness of the server layer (VPC)
termination point of every specific client (VCC) is an integral part of
the data plane since VPI values have only meaning within the scope
defined by the containing VPC. In other words, regardless of the AIS,
the server layer had to be aware of each specific client since otherwise
traffic could not be forwarded correctly. AIS propagation in this case
was more complicated than in the TDM case, but still free.

	On the other hand the MPLS data plane architecture as described
in RFC 3031 (Section 3.14) recognizes just two types of label scope:

	*	Per-platform 
	*	Per interface.

	And it also defines (in Sections 3.10, 3.11 and 3.13) that
forwarding is done by looking up the label at the top of the label
stack. (Multiple label look-ups, regardless of implementation, mean
popping the top label and forwarding the still labeled packet to the
"loopback interface").

	IMHO and FWIW this means that MPLS data plane does not, per se,
require the server termination point awareness of each and every
specific client within the terminated server LSP. 

	1.	Explicitly require such an awareness. This would enable
(among other things) AIS but would be probably costly in the terms of
look-ups 
	2.	Preserve existing flexibility of the MPLS data plane,
and drop the AIS-related requirement.

	Did I miss something?
	[JH]  If per platform label space means that the label can be
from any interface (=server layer trail) and the network element doesn't
know from which interface it comes, yes we have a problem. However it is
a more general problem. If can for example result in unintended merging
if the same label is received via more than one interface due to a
configuration error or a problem in an upstream LSR. 

	Regards   

	     Sasha

	________________________________________
	From: [email-masked] [[email-masked]] On
Behalf Of Heiles, Juergen (NSN - DE/Munich) [[email-masked]]
	Sent: Friday, May 15, 2009 3:08 PM
	To: ext Ben Niven-Jenkins; George Newsome; [email-masked]
	Cc: [email-masked]
	Subject: Re: [mpls-tp] AIS/FDI (was
Associatedbidirectionaltransportpathrequirements)
	
	Hi colleagues,
	
	I have been quiet for a long time, but now I think I have to add
my 2
	cents to this discussion.
	
	Different purposes of the AIS signal are mixed in the
discussion.
	1. In a TDM circuit switched network the resources for a certain
	connection (the time slots) are fixed assigned and have to be
filled
	even if the connection is interrupted due to an upstream server
layer
	failure. This replacement signal has to fulfill certain criteria
like
	for timing in order to prevent strange behavior and failure
conditions
	downstream like buffer overflow/underflow. One may generate a
random
	pattern or just send what is in the buffer. Such patterns
however may
	result in some strange defect detections downstream (at
non-intrusive
	monitors or path termination) which could have a negative impact
on
	protection switching. Therefore it makes sense to generate a
well
	defined replacement signal.
	-> AIS purpose: a well behaving signal to prevent strange and
unwanted
	behaviors downstream of the failure with the layer network
	
	2. One transport network paradigm is to have layer networks
decoupled so
	that each layer network can be operated on its own. When we move
to the
	physical layers or close to them this is however no longer 100%
	fulfilled. The SDH Regenerator section depends on the clock from
the
	Multiplex section (the same applies for OTU and ODU). If a MS
fails a
	replacement at least of the clock is required in order to have a
correct
	behavior at the downstream RS and other server layers. The
Optical and
	electrical layer require a certain pattern from their digital
client
	layers like RS or OTU in order to work correctly
	-> AIS purpose: ensure correct operation of downstream server
layers in
	cases where server and client layers are not 100% decoupled
(this is the
	example from George).
	
	3. A failure of a server layer connection may effect a large
number of
	client layer connections that are transported via this
connection.
	These client layer connections are terminated and monitored at
network
	elements that are far way from the actual failure location. They
might
	be even in a different management or operator domain. Without
AIS all of
	them would raise a primary failure alarm (loss of connectivity).
While a
	network element can differentiate between local and remote
failures
	based on local information, it cannot differentiate between a
failure at
	the monitored layer network or some server layer networks
upstream. With
	AIS it is possible.
	-> AIS purpose: alarm correlation to prevent alarm storms and
	differentiate between failures at the layer network and at
server layer
	networks.
	
	As a side effect, AIS detection is often much faster as loss of
	connectivity detection (e.g. SDH VC-4 TTI mismatch vs. AU-AIS
detection)
	and can trigger protection switching therefore faster. So this
might not
	be the case for MPLS-TP depending on the specific methods that
will be
	used.
	
	For MPLS-TP item 1 doesn't apply as it is a packet layer network
which
	doesn't require that packets are constantly sent for a certain
	connection.
	Item 2 does also not apply as the MPLS-TP layer network is
decoupled
	from other layer networks concerning its operation (I assume
so;-).
	This leaves us with item 3 which applies to any kind of
transport
	network technology. So it is not a must have I see it as very
useful.
	Some operators might not be interested in it at all or do alarm
	correlation in the network management. Still they can do that.
They have
	to enable AIS alarm reporting and treat AIS alarms in the same
way as
	loss of connectivity alarms.
	
	Regards

---

From: Loa Andersson <[email-masked]>
Date: Tue, 26 May 2009 16:50:31 +0200

All,

I have what might be a naive question.

Consider a network configured this way, between two LSRs with
multiple hops between them we run two 40G LSPs, inside each such LSPs
we have 400 100Mbit/s LSPs

At each end we have of the tunnels we have a MEP for each tunnel, and
MIPs for the 100 Mbit/s LSPs.

Assume that we have failure somewhere else than at the endpoints of the
tunnel.

At both ends of the tunnel the tunnel MEP will detect the failure, if
both directions are effected, as the OAM flow stops. The same will
happen end points of the tunneled LSPs.

If only one direction is effected the end point (tunnel or tunneled LSP)
will stop the OAM flow, and the other end (tunnel and tunneled LSP)
will (also) detect the failure.

Now what will happen at the tunnel end-points?

I assume that the tunnel end-point MEPs will tell the corresponding MIPs
(one for each tunneled LSP) about the failure. It will also tell the NMS
about the failure.

What will the MIPs at the tunnel end-point do?

What will the MEPs at the LSP end-points do? It is quite obvious that
they will tell the NMS and their own client MIPs.

Anything more?

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager    phone:  +46 10 717 52 13
Ericsson ///                                 +46 767 72 92 13

                                       email:  [email-masked]
                                               [email-masked]

---

From: "Heiles, Juergen (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 27 May 2009 11:35:29 +0200

Hi Loa,

see my response below based on the behavior we have for example in SDH
networks.

Regards

Juergen

>From: ext Loa Andersson [mailto:[email-masked]] 
>Sent: Tuesday, May 26, 2009 4:51 PM
>Cc: ext Ben Niven-Jenkins; George Newsome; 
>[email-masked]; [email-masked]
>Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional 
>transport path requirements)
>
>All,
>
Actually it is not relevant where the failue occurs.

>will (also) detect the failure.
I am not sure if it is required to shut down both direction in case of a
unidirectional failure. But it is not relevant.

>(one for each tunneled LSP) about the failure. It will also 
The MEP will tell the NMS if it is a primary failure condition. For
secondardy failure conditions see below.

>What will the MIPs at the tunnel end-point do?
They should notify the downstream MEPs at the LSP end-points that the
LSP is interrupted due to a failure condition at a server layer.

>they will tell the NMS and their own client MIPs.
They MEPs may tell the NMS about the interruption due to a failure at
the server layer. It is a secondary falure condition for which the fault
management reporting can be disabled.

---

From: Loa Andersson <[email-masked]>
Date: Wed, 27 May 2009 12:16:56 +0200

Juergen,

see in line please.

> see my response below based on the behavior we have for example in SDH

part of this is discussion (at lest on my part) is that we need to
recognize that in certain respects SDH and packet networks are
different, and how also understand how this effects what we are
discussing
> Actually it is not relevant where the failure occurs.

maybe not, I just wanted to look at a situation where the failure
were detected through the (lack of) OAM flow.
> unidirectional failure. But it is not relevant.

may be not - but we have had a lot of ITU-T people telling us that if
you want to re-route a bidirectional LSP you need re-route both
directions, so that was the scenario I was looking at

> secondardy failure conditions see below.

how do we define "primary failure condition" in the packet network?
Is that a failure detected by the lack of OAM flow?

> LSP is interrupted due to a failure condition at a server layer.

Is this breaking the definition of a MIP, "a MIP is passive and won't
volunteer information unless told to do so" (my words, but this is how I
understand how a MIP work).

point here is that the MEP at the end-point will know about the failure,
but not that it is a server layer failure, to understand that the MEP
will have to ask its upstream MIPs one by one until any of those are
able to tell whether it is a failure of the server layer (or the client
layer itself)

> the server layer. It is a secondary failure condition for which the fault

See above.

/Loa

-- 

Loa Andersson

---

From: "Heiles, Juergen (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 27 May 2009 15:24:15 +0200

Hi Loa,

see below.

Regards

Juergen

>Sent: Wednesday, May 27, 2009 12:17 PM
I agree and already indicated some difference in my initial email on the
topic. In the context of the Ethernet OAM work and even before in the
ATM days discussions on that issue took place, but also packet
technologies are different and have their history. Just saying we have
to do it because we always did it this way is not the way to go. We have
to have good reasons for a requirement.

>were detected through the (lack of) OAM flow.

The failure could be anywhere along the serve layer connection between
the increase and egress server MEPs. We may have also failures with OAM
and data flows, for example a miss-connection to the wrong LSP. In this
case the packets should no longer be forwarded to the client layer.
The behavior should be independent of the specific failure and type of
server layer.

>directions, so that was the scenario I was looking at
yes, but that does not mean that you stop the OAM flow. You should still
send OAM packets from the increase MEP along the LSP in order to detect
the actual state of it and see if it has recovered from the failure
condition.

>Is that a failure detected by the lack of OAM flow?
Primary failure is a failure where we assume that the cause of the
failure is at that layer network, for example when we detect a
miss-connection.
A secondary failure is a failure where we assume that the cause is at a
server layer.

>understand how a MIP work).

Using the term MIP in this context might be a too loose language. The
function responsible for the insertion of the server layer failure
indication notification is the adaptation function. The MIP is a point
and located at the output of the adaptation sink or input of the
adaptation source. So how we can see the functionality.
The server layer is terminated at the trail termination sink and
forwards the data to the adaptation sink which extracts the client
signals. In case of a server layer failure the trail termination sink no
longer provides data to the adaptation but instead it indicates to the
adaptation "Sorry no data packets available due to a failure condition"
(in the equipment functional model we use a Signal Fail signal going
from the termination to the adaptation). The adaptation generates the
"in-band" notification which basically says the same (no data packets
available due to a server layer failure).
A adaptation function does the mapping between client and server layer
which can include recoding, stuffing and other things. In this case it
is a recoding of the message "Sorry no data packets available due to a
failure condition" in a form that is understood by the client layer.
The actual MIP follows after the adaptation and a non-intrusive monitor
at this MIP would already detect the server layer failure notification.

>able to tell whether it is a failure of the server layer (or the client
The MEP shall not ask its upstream MIPs one by one which could get
complex and take some time. The adaptation automatically inserts the
notification.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 27 May 2009 17:36:21 +0200

Loa,
You are absolutely right. Packet and SDH are different, BUT... 
If we want MPLS-TP to enable the migration of SONET/SDH networks to a
packet-based network we may need in some aspects to provide similar
operational concepts to which carriers are accustomed....
The suppression of alarms that are generated as a result of the failure
condition in the server layer may be one of these aspects (and I do NOT
refer to any implementation of this requirement, just to the
functionality).
Best regards,
Nurit
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Loa Andersson
Sent: Wednesday, May 27, 2009 1:17 PM
To: Heiles, Juergen (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport
path requirements)

Juergen,

see in line please.

See above.

/Loa
layer
like
non-intrusive
useful.

-- 

Loa Andersson

                                       email:
[email-masked]
                                               [email-masked]

---

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 28 May 2009 08:26:41 +0300

Juergen,
Lots of thanks for a detailed response, and my apologies for late reaction.

Just a few short comments:

 1.
RFC 3031 does not make it clear if a server layer LSP could be considered an "interface" with a separate per-interface label space. But taking into account unlimited depth of label stacking in MPLS, this would hardly be feasible as the number of "label spaces" a LER has to maintain would grow exponentially.
 2.
AFAIK, per-platform label space is highly popular in MPLS and (as noted earlier on this list), its usage is MANDATED for PW labels.
 3.
IMHO and FWIW, ability of MPLS-TP to coexist with per-platform label space is one of the key unresolved issues of the MPLS-TP project, because it would mean lack of backward compatibility with the already deployed equipment.

Regards,

     Sasha

________________________________
From: Heiles, Juergen (NSN - DE/Munich) [[email-masked]]
Sent: Tuesday, May 26, 2009 12:50 PM
To: Alexander Vainshtein
Cc: [email-masked]; George Newsome; ext Ben Niven-Jenkins; [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements)

Hi Sasha,

see my comments below.

Regards

Juergen

________________________________
From: ext Alexander Vainshtein [mailto:[email-masked]]
Sent: Saturday, May 16, 2009 8:59 AM
To: Heiles, Juergen (NSN - DE/Munich)
Cc: [email-masked]; George Newsome; ext Ben Niven-Jenkins; [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements)

Juergen,

[JH] Yes, or the other way the client adaptation has to be aware over which server layer trail the client was transported.

Please note that such awareness was not required in TDM networks, since it was possible to spread the AIS pattern ("all ones") across all potential clients.
[JH] This is not really true as the (PDH) AIS pattern also has to be with the correct bit rate which is client specific. In SDH the AU/TU AIS in the pointer takes care of the timing, but as the pointer is not passed thru the buffer you have to know the AU/TU structure. A TDM network element is always aware about the client signals transported in a server layer trail (implicitly or by configuration).

 *   Per-platform
 *   Per interface.

Did I miss something?
[JH]  If per platform label space means that the label can be from any interface (=server layer trail) and the network element doesn't know from which interface it comes, yes we have a problem. However it is a more general problem. If can for example result in unintended merging if the same label is received via more than one interface due to a configuration error or a problem in an upstream LSR.

Regards

     Sasha

Hi colleagues,

Regards

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 28 May 2009 08:41:58 +0200

There are differences between packet and SDH, and there are commonalities.
One of the commonalities is the fact that both packet and SDH technologies
deploy "Transport Entities" to transport information applied at an input
port to an output port. OAM is used to monitor the status and performance of
such transport entities. Alarm suppression OAM acts as such on such
transport entities, and packet transport entity alarm suppression is as such
equivalent to SDH transport entity alarm suppression.

Regards,
Maarten 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: woensdag 27 mei 2009 17:36
To: ext Loa Andersson; Heiles, Juergen (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport
pathrequirements)

Loa,
refer to any implementation of this requirement, just to the functionality).
Best regards,
Nurit
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Loa Andersson
Sent: Wednesday, May 27, 2009 1:17 PM
To: Heiles, Juergen (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path
requirements)

Juergen,

see in line please.

> see my response below based on the behavior we have for example in SDH 

part of this is discussion (at lest on my part) is that we need to recognize
that in certain respects SDH and packet networks are different, and how also
understand how this effects what we are discussing
>> Cc: ext Ben Niven-Jenkins; George Newsome; [email-masked]; 
>> [email-masked]

maybe not, I just wanted to look at a situation where the failure were
detected through the (lack of) OAM flow.
>> If only one direction is effected the end point (tunnel or tunneled 
>> LSP) will stop the OAM flow, and the other end (tunnel and tunneled 
>> LSP) will (also) detect the failure.
>>

may be not - but we have had a lot of ITU-T people telling us that if you
want to re-route a bidirectional LSP you need re-route both directions, so
that was the scenario I was looking at
>> I assume that the tunnel end-point MEPs will tell the corresponding 
>> MIPs (one for each tunneled LSP) about the failure. It will also tell 
>> the NMS about the failure.

point here is that the MEP at the end-point will know about the failure, but
not that it is a server layer failure, to understand that the MEP will have
to ask its upstream MIPs one by one until any of those are able to tell
whether it is a failure of the server layer (or the client layer itself)

See above.

/Loa
layer
like
non-intrusive
useful.
>>>> This is a key point IMO. A piece of MPLS-TP equipment can determine 
>>>> whether a failure is local/remote by correlating information
>> acquired from the
>>>> various layer networks which terminate on it. It doesn't need to 
>>>> have all the information it requires be present in the MPLS-TP 
>>>> layer
network.

-- 

Loa Andersson

                                       email:

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 28 May 2009 15:08:28 +0200

Hi Sasha,

I would like to refer you to
draft-martinotti-mpls-tp-interworking-01.txt which addresses the
interworking scenarios between MPLS-TP and MPLS.
Do you see any scenario in which there may be an issue as a result of
using per-i/f label space in MPLS-TP?
Best regards,
Nurit
 
P.S. as the MPLS protocol allows both per-platform and per-interface
label spaces for LSPs and does not mandate both (for LSP case), an
implementation may support per interface only for LSPs. How do you
guarantee interoperability between MPLS NEs that one supports per-i/f
and one supports per-platform? How MPLS handles this case? 

I think that at least for MPLS-TE the per-i/f case is very popular.

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Alexander Vainshtein
Sent: Thursday, May 28, 2009 8:27 AM
To: Heiles, Juergen (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI
(wasAssociatedbidirectionaltransportpathrequirements)

Juergen,

Lots of thanks for a detailed response, and my apologies for late
reaction.

1.	RFC 3031 does not make it clear if a server layer LSP could be
considered an "interface" with a separate per-interface label space. But
taking into account unlimited depth of label stacking in MPLS, this
would hardly be feasible as the number of "label spaces" a LER has to
maintain would grow exponentially.
2.	AFAIK, per-platform label space is highly popular in MPLS and
(as noted earlier on this list), its usage is MANDATED for PW labels. 
3.	IMHO and FWIW, ability of MPLS-TP to coexist with per-platform
label space is one of the key unresolved issues of the MPLS-TP project,
because it would mean lack of backward compatibility with the already
deployed equipment.

Regards,

     Sasha

Hi Sasha,

see my comments below.

Regards

Juergen

	Juergen, 

	 

	*	Per-platform 
	*	Per interface.

	Did I miss something?

	Regards   

	     Sasha

	
	Hi colleagues,

	

	
	
	Regards

---

From: Loa Andersson <[email-masked]>
Date: Thu, 28 May 2009 15:10:53 +0200

Juergen,

top post only.

This is possibly right, but it rocks some of the "fundamental truths"
that I've been trying to understand since the start MPLS-TP project.

What has been said is that OAM is done by groups of functions at the
end-points of LSPs (connections)- MEPs, and at intermediary points
of those LSPs - MIPs.

Now there is a suddenly (at least for me) a new entity - an adaptation
function - that starts injecting OAM packets on LSPs.

I think I understands this, but it still leaves me with the problem I
had to start with. These messages has to direct to packets to all the
MEPs at the at the endpoints of the tunneled LSPs, so there is a unique
packet going to each MEP.

The time this will take is probably something like 50ms (fault
detection) + 800 x 5 ms ~ 4s (and consuming all the cycles of the
nodes at the end of the tunnel. Is this significantly better than
send information to the NMS.

/Loa

-- 

Loa Andersson

---

From: Loa Andersson <[email-masked]>
Date: Thu, 28 May 2009 15:33:41 +0200

Nurit,

I guess it is possible to get around the ban on only having the MEPs
inserting OAM flows is to define what comes from the adaptation
function is not OAM flows :)

I just want to know where I'm standing :)

/Loa

Sprecher, Nurit (NSN - IL/Hod HaSharon) wrote:
> Hi,
> Good point Loa regarding the adaptation function, and it came just when
> I have started writing a new proposal to the WG.
> As defined in the OAM framework, it is only the MEPs that are allowed to
> initiate messages flow across the maintenance entity. The MIPs only acts
> as a response to such messages. 
> If we look at SNMP for example (and also at the CP), the manager entity
> is the one that initiates commands ("set") and retrieval messages
> ("get", "get bulk"). The agent entity only responds to these messages,
> but is allowed also to send traps/notifications to the management
> entity. 
> I would like to propose to enhance the functionality of the MIPs and
> allow the MIPs initiating and sending error-notifications to the MEPs.
> In such a case, when a MIP detects a fault it can send an error
> notification to its MEPs. 
> I think that by doing this we keep the architecture clean and do not
> break the layering models but add an important functionality which can
> enhance the general behavior and provide better functionality.
> Best regards,
> Nurit
> 
> 
> Sent: Thursday, May 28, 2009 4:11 PM

-- 

Loa Andersson

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 28 May 2009 15:40:40 +0200

Loa,
So what is it if not OAM? Data traffic that a transport node
initiates??? CP traffic? :-)
I think that architecturally it is correct to have such a functionally
in the MIP (i.e. initiating notifications/traps). 
I am very serious about the proposal. 
The fact that the ITU-T did not define it so far should not prevent us
enhancing the functionality and the behavior of the NW. 
Best regards,
Nurit

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]] 
Sent: Thursday, May 28, 2009 4:34 PM
To: Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: Heiles, Juergen (NSN - DE/Munich); [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport
path requirements)

Nurit,

/Loa

connection.

-- 

Loa Andersson

                                       email:

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 28 May 2009 15:26:07 +0200

Hi,

-----Original Message-----

Juergen,

top post only.

/Loa

on
failures
so;-).

-- 

Loa Andersson

                                       email:

---

From: Loa Andersson <[email-masked]>
Date: Thu, 28 May 2009 15:56:26 +0200

> initiates??? CP traffic? :-)

no idea

/Loa

-- 

Loa Andersson

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 28 May 2009 15:04:01 +0100

I think this completes the loop, Nurit. Please decrement the TTL.

We started with "The definition of MIP we have seems to say cannot initiate 
an OAM packet?"

If the intention is to change the definition of MIP then we need to find out 
how many places we need to change that definition. Is it OK to say "MPLS-TP 
MIP" and mean something else than is meant for a generic ITU-T MIP? Should 
the ITU-T definition of MIP be changed?

A
----- Original Message ----- 
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "ext Loa Andersson" <[email-masked]>; "Heiles, Juergen (NSN - DE/Munich)" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, May 28, 2009 2:26 PM
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport 
pathrequirements)

---

From: "Heiles, Juergen (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 28 May 2009 16:41:32 +0200

In my view the term MIP is still correct as it is after the adaptation
function which inserts the failure notification. At this point only
monitoring of OAM is performed.
Looking again on the ITU definitions and the Rosetta stone document the
Server MEP is the one responsible for the insertion. The Rosetta stone
document says:

   The server MEP can run appropriate OAM functions for fault 
   detection, and notifies a fault indication to the MPLS-TP layer 
   network. 

Regards

Juergen

>From: ext Adrian Farrel [mailto:[email-masked]] 
>Sent: Thursday, May 28, 2009 4:04 PM
>To: Sprecher, Nurit (NSN - IL/Hod HaSharon); ext Loa 
>Andersson; Heiles, Juergen (NSN - DE/Munich)
>Cc: [email-masked]
>transport pathrequirements)
>
>>> A secondary failure is a failure where we assume that the 
>cause is at
>> a
>>> server layer.
>>>
>>> signals. In case of a server layer failure the trail 
>termination sink
>> no

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 28 May 2009 21:37:54 +0100

Do we need to change the definition? What do implementations of say Y1731
which has similar MEP/MIP do in this scenario? Is the definition in Y1731
(MIPs only process & react they don't initiate OAM frames) on which our
definition is based wrong, in which case ITU need to fix their definition.
If Y1731 can do it without having MIPs initiate OAM frames then our
understanding is wrong.

Ben

---

From: "Heiles, Juergen (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 29 May 2009 09:10:18 +0200

HI Ben,

as said in my previous email the ITU definitions are correct. The Server
MEP inserts the notification as the adaptation is part of the server
MEP. This is the way Y1731 defines it. 
Under normal conditions (no failure) the adaptation at the server MEP
extracts the client data (CI) from the server layer. Under server layer
failure conditions it generates the failure notification for the client
layer.
The MIP stays passive and can only monitor. 

Regards

Juergen

>From: ext Ben Niven-Jenkins [mailto:[email-masked]] 
>Sent: Thursday, May 28, 2009 10:38 PM
>To: Adrian Farrel; Sprecher, Nurit (NSN - IL/Hod HaSharon); 
>Loa Andersson; Heiles, Juergen (NSN - DE/Munich)
>Cc: [email-masked]
>>>> I agree and already indicated some difference in my 
>initial email on
>>> the
>>>>>> They MEPs may tell the NMS about the interruption due to 
>a failure
>>> at

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 29 May 2009 13:16:35 +0200

Ben,

>From an ITU-T point of view, AIS is generated by the adaptation
function.

I like this architectural solution because the adaptation function,
being at the boundary between the server (MEP) and client layer, is the
only functional component that is aware of which are the client-layer
transport paths that are affected by a server layer failure.

Based on this on-going discussion, I think that we need to update the
OAM framework draft splitting between the Server MEP functional
component, that monitors the server layer independently from the client
layer, and the adaptation between the server MEP and MPLS-TP, that
generates AIS packets when it is informed by Server MEP that ther is a
failure in the server layer.

We will update the OAM framework draft accordingly.

Italo

> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
> >>> to do it because we always did it this way is not the way 
> to go. We
> >> have
> >>> the increase and egress server MEPs. We may have also 
> failures with
> >> OAM
> >>>>> They should notify the downstream MEPs at the LSP 
> end-points that
> >> the
> >>>>> They MEPs may tell the NMS about the interruption due 
> to a failure
> >> at

---

From: Loa Andersson <[email-masked]>
Date: Fri, 29 May 2009 13:50:25 +0200

Italo,

> failure in the server layer.

are you saying that the adaptation function need to keep the next-hop
label + the address for each end of the client LSPs??

And that the adaptation function needs to generate unique client layer
OAM packets per client LSP?

/Loa

-- 

Loa Andersson

---

From: Francesco Fondelli <[email-masked]>
Date: Fri, 29 May 2009 15:58:48 +0200

Hi Alexander,

On Thu, May 28, 2009 at 7:26 AM, Alexander Vainshtein
<[email-masked]> wrote:
[cut]
> RFC 3031 does not make it clear if a server layer LSP could
> be considered an "interface" with a separate
> per-interface label space. But taking into

No, it's clear.  Don't you know the earth is flat :-)?  You may
represent a LSP end-point as an i/f [RFC3812, Section 8], but you
can't allocate a *new* per-interface label space for that
(virtual) i/f.  "In MPLS, there is no notion of having a
different label space for different levels of the hierarchy;
when interpreting a label, the level of the label is
irrelevant" [RFC3031, Section 3.14].

So there is no hierarchy form a label space view point and
silicon has been designed with this concept in mind.

> account unlimited depth of label stacking in MPLS, this would hardly be
> feasible as the number of "label spaces" a LER has to maintain would grow
> exponentially.
> AFAIK, per-platform label space is highly popular in MPLS and (as noted
> earlier on this list), its usage is MANDATED for PW labels.
> IMHO and FWIW, ability of MPLS-TP to coexist with per-platform label space
> is one of the key unresolved issues of the MPLS-TP project
[cut]

I agree, someone will realize it soon or later.

>      Sasha

Ciao
FF

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 29 May 2009 22:21:55 +0300

Francesco,
Lots of thanks for pointing to this statement in 3031.
I fully agree that "tunnel LSPs" cannot be used as "interfaces" for defining per-interface label spaces.

Regards,
     Sasha

________________________________________
From: Francesco Fondelli [[email-masked]]
Sent: Friday, May 29, 2009 4:58 PM
To: Alexander Vainshtein
Cc: Heiles, Juergen (NSN - DE/Munich); [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements)

Hi Alexander,

[cut]

Ciao
FF

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 29 May 2009 21:33:29 +0200

Sasha,
 
Per-platform label space makes transport entities unsecure as it turns e.g.
a p2p transport entity (e.g. a MS-PW) into a mp2p transport entity of which
idealy only one of the n-1 input ports is connected and the other n-2 input
ports not connected. 
 
This security problem can be resolved by introducing so called "Ingress
Filtering" (similar to the ingress filtering specified in 8.6.2/802.1Q for
VLANs). Such Enable Ingress Filtering parameter could be introduced into
MPLS(-TP). Per-platform label space combined with Enable Ingress Filtering
provides secure MPLS-TP transport entities. This Enable Ingress Filtering
parameter can be introduced in MPLS-TP capable equipment and this maintains
backward compatibility with existing MPLS equipment.
 
Regards,
Maarten

  _____  

Of Alexander Vainshtein
Sent: donderdag 28 mei 2009 7:27

Juergen,

1.	

	RFC 3031 does not make it clear if a server layer LSP could be
considered an "interface" with a separate per-interface label space. But
taking into account unlimited depth of label stacking in MPLS, this would
hardly be feasible as the number of "label spaces" a LER has to maintain
would grow exponentially.
2.	

	AFAIK, per-platform label space is highly popular in MPLS and (as
noted earlier on this list), its usage is MANDATED for PW labels. 
3.	

	IMHO and FWIW, ability of MPLS-TP to coexist with per-platform label
space is one of the key unresolved issues of the MPLS-TP project, because it
would mean lack of backward compatibility with the already deployed
equipment.

Regards,

     Sasha

  _____  

Hi Sasha,
 
see my comments below.
 
Regards
 
Juergen

  _____  

Juergen, 

You've also demonstrated that some of these requirements are not applicable
to packet-based networks restricting potential usefulness of AIS to a single
use case - an "alarm correlation helper" in the hierarchy of MPLS-TP layers.

The point that remains yet unclear to me is, can this use case be addressed
within the framework of MPLS data plane architecture?

To the best of my understanding, in order to achieve the required
functionality, the termination point of a lower-layer LSP in MPLS-TP MUST be
aware of each individual client LSP. 

[JH] Yes, or the other way the client adaptation has to be aware over which
server layer trail the client was transported.

Please note that such awareness was not required in TDM networks, since it
was possible to spread the AIS pattern ("all ones") across all potential
clients. 
[JH] This is not really true as the (PDH) AIS pattern also has to be with
the correct bit rate which is client specific. In SDH the AU/TU AIS in the
pointer takes care of the timing, but as the pointer is not passed thru the
buffer you have to know the AU/TU structure. A TDM network element is always
aware about the client signals transported in a server layer trail
(implicitly or by configuration).

 

In the case of ATM, awareness of the server layer (VPC) termination point of
every specific client (VCC) is an integral part of the data plane since VPI
values have only meaning within the scope defined by the containing VPC. In
other words, regardless of the AIS, the server layer had to be aware of each
specific client since otherwise traffic could not be forwarded correctly.
AIS propagation in this case was more complicated than in the TDM case, but
still free.

On the other hand the MPLS data plane architecture as described in RFC 3031
(Section 3.14) recognizes just two types of label scope:

*	Per-platform 

*	Per interface.

And it also defines (in Sections 3.10, 3.11 and 3.13) that forwarding is
done by looking up the label at the top of the label stack. (Multiple label
look-ups, regardless of implementation, mean popping the top label and
forwarding the still labeled packet to the "loopback interface").

IMHO and FWIW this means that MPLS data plane does not, per se, require the
server termination point awareness of each and every specific client within
the terminated server LSP. 

1.	Explicitly require such an awareness. This would enable (among other
things) AIS but would be probably costly in the terms of look-ups 

2.	Preserve existing flexibility of the MPLS data plane, and drop the
AIS-related requirement.

Did I miss something?
[JH]  If per platform label space means that the label can be from any
interface (=server layer trail) and the network element doesn't know from
which interface it comes, yes we have a problem. However it is a more
general problem. If can for example result in unintended merging if the same
label is received via more than one interface due to a configuration error
or a problem in an upstream LSR. 

Regards   

     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of
Heiles, Juergen (NSN - DE/Munich) [[email-masked]]
Sent: Friday, May 15, 2009 3:08 PM
To: ext Ben Niven-Jenkins; George Newsome; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was
Associatedbidirectionaltransportpathrequirements)

Hi colleagues,

Regards

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 30 May 2009 13:04:50 +0300

Maarten,
I do not argue advantages and disadvantages of per-platform vs. per-interface label spaces in MPLS-TP.
I am simply trying to understand whether MPLS architecture (as defined in 3031) is compatible with the "transport" requirements. The answer still is not clear to me, and some posts on this list (e.g., Loa's questions about "adaptation functions") seem to indicate that I am not alone there.

Regarding your example with ingress VLAN filtering in 802.1q, please note that:

 1.
VLAN filters in 802.1q are applicable per physical port of a VLAN-aware bridge, while MPLS-TP would require similar functionality per virtual interface represented by a terminated LSP. IMHO this makes quite a difference for the implementers
 2.
For better or worse, MPLS has its own architecture, and this architecture does not imply any per-interface label filters.

Regards,

     Sasha

________________________________
From: Maarten Vissers [[email-masked]]
Sent: Friday, May 29, 2009 10:33 PM
To: Alexander Vainshtein; 'Heiles, Juergen (NSN - DE/Munich)'
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (wasAssociatedbidirectionaltransportpathrequirements)

Sasha,

Per-platform label space makes transport entities unsecure as it turns e.g. a p2p transport entity (e.g. a MS-PW) into a mp2p transport entity of which idealy only one of the n-1 input ports is connected and the other n-2 input ports not connected.

This security problem can be resolved by introducing so called "Ingress Filtering" (similar to the ingress filtering specified in 8.6.2/802.1Q for VLANs). Such Enable Ingress Filtering parameter could be introduced into MPLS(-TP). Per-platform label space combined with Enable Ingress Filtering provides secure MPLS-TP transport entities. This Enable Ingress Filtering parameter can be introduced in MPLS-TP capable equipment and this maintains backward compatibility with existing MPLS equipment.

Regards,
Maarten

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexander Vainshtein

Juergen,

 1.

Regards,

     Sasha

Hi Sasha,

see my comments below.

Regards

Juergen

Juergen,

 *   Per-platform
 *   Per interface.

Did I miss something?

Regards

     Sasha

Hi colleagues,

Regards

---

From: Alexander Vainshtein <[email-masked]>
Date: Sat, 30 May 2009 19:21:24 +0300

Loa,

You have asked Italo:

<quote>

are you saying that the adaptation function need to keep the next-hop label + the address for each end of the client LSPs??

<end quote>
Of course it is up to Italo to answer this question, but my gut feeling (FWIW) is that this is exactly what he says.

One of the points that I have been trying to raise on this list was that, to the best of my understanding,  "adaptation functions" with this sort of knowledge are not required by the MPLS data plane architecture as described in RFC 3031.

Regards,

     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Loa Andersson [[email-masked]]
Sent: Friday, May 29, 2009 2:50 PM
To: BUSI ITALO
Cc: [email-masked]
Subject: Re: [mpls-tp] AIS/FDI (was Associated bidirectional transport path requirements)

Italo,

/Loa

--

Loa Andersson

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 31 May 2009 21:59:52 +0200

Hi,
In Y.1731, we have a message that is initiated by the server MEP to the
clients MEPs and is adapted by the clients located at the same NE as the
server that initiates the message. In a way this involves inter-layer
communication (or whatever). 
In the proposal below, the local clients (MIPs at the client layer) are
notified (locally) by the server layer of the fault and if
needed/required they may send a notification/alarm to their MEPs
(communication is initiated and terminated at the same layer). 
We have an "adaptation" function vs. a "notification" initiated by a MIP
and sent to the MEP at the same layer.
Best regards,
Nurit

-----Original Message-----
From: Heiles, Juergen (NSN - DE/Munich) 
Sent: Friday, May 29, 2009 10:10 AM
To: ext Ben Niven-Jenkins; Adrian Farrel; Sprecher, Nurit (NSN - IL/Hod
HaSharon); Loa Andersson
Cc: [email-masked]
Subject: RE: [mpls-tp] AIS/FDI (was Associated bidirectional transport
pathrequirements)

HI Ben,

Regards

Juergen