Subject: [mpls-tp] LDI generation during slow CC

From: "Vijayanand C - ERS, HCL Tech" <[email-masked]>
Date: Fri, 18 Jun 2010 11:59:17 +0530

Hello all,
In draft-ietf-mpls-tp-fault, section 2.3 says that when CC is slow LDI enables faster switchover

"In more general MPLS environments the CC function may
   be running at a much slower rate.  In this environment, LDI enables
   faster switch-over upon a failure occurring along the LSP."

It is not clear in the spec how LDI will be generated when CC is slow and has not detected failure.
Is it implicit that the LSPs own detection mechanism ( refresh timeout, path tear etc..) will trigger the LDI ?
Can anyone clarify this ?

Regards
Vijay

DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. 
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. 
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of 
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have 
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

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

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 18 Jun 2010 11:55:57 +0200

Vijay,
 
The current draft draft-ietf-mpls-tp-fault-01 does include an MPLS-TP LDI
OAM frame. This LDI frame must be removed from the MPLS-TP OAM set as it
will unnecessary complicate MPLS-TP. I have discussed this with George
Swallow some weeks ago and we agreed that for this undocumented application
the AIS OAM frame could be extended with a "protection
possible/not-possible" flag bit.
 
To understand the need for such protection possible/not-possible flag bit it
is required that the application is described first. After a description of
the application, we will be able to identify if the proposed solution can
work, or if it is incomplete and not worth adding.
 
The application is the following:
 
1) A Transport Service (TS) or a Transport Path (TP) layer connection is
protected multiple times, e.g. 2 times. There is an inner TS [or TP]
protection span and there is an outer TS [or TP] protection span (see figure
below)
 
 MEP ---- oPROT -- Wo.MEP ------------ iPROT -- Wi.MEP ---------------
Wi.MEP -- iPROT --------- Wo.MEP -- oPROT ------- MEP
                        \                                         \-- Pi.MEP
---------------- Pi.MEP --/                                      /
                         \-- Po.MEP
----------------------------------------------------------------------------
------------------Po.MEP --/
 
2) The outer protection is in some older equipment which is unable to
support fast MPLS-TP CC/CV OAM generation and reception; e.g. this equipment
is able to generate and receive CC/CV type OAM at once per 10 seconds.
 
3) The inner protection is in newer equipment which is able to support fast
CC/CV OAM generation and reception; e.g. once per 3.3 ms.
 
4) when there is a fault in the inner working connection, then the Wi.MEP
function will detect Loss of Continuity defect (dLOC) in about 10 ms and
this dLOC will trigger the insertion of AIS OAM within 1 second after
detection of dLOC. Because the Wi.MEP function is part of a TS [or TP] SNC/S
protection scheme, the protection engine is able to set the ProtPossible
parameter in the Wi.MEP function to "1". When an AIS packet is generated,
the ProtPossible flag is set to "1". Then this AIS packet is received by the
Wo.MEP function in the older node, then the TS [or TP] SNC/S protection
process will inspect the AIS frame and checks the ProtPossible flag; if set
to 1 it will don't take any action.

AIS(ProtPossible=1)
 
dLOC  |----------------------------->
 MEP ---- oPROT -- Wo.MEP ------------ iPROT -- Wi.MEP ------XX----- Wi.MEP
-- iPROT --------- Wo.MEP -- oPROT ------- MEP
                        \                                         \-- Pi.MEP
--------------- Pi.MEP --/                                       /
                         \-- Po.MEP
----------------------------------------------------------------------------
------------------Po.MEP --/
 
5) when there was already a fault in the inner protection connection (see
figure below), then the inner protection engine would have set the
ProtPossible parameter in the Wi.MEP to "0". As soon as the working
connection fails, the Wi.MEP function will detect dLOC and will insert
within 1 second an AIS packet of which the ProtPossible flag is set to "0".
The Wo.EMP function in the older node will again inspect the AIS packet for
the ProtPossible flag value and will now trigger its own protection
switching action (ProtPossible=0 indicates that inner protection can not
restore the connection).

AIS(ProtPossible=0)
 
dLOC  |----------------------------->
 MEP ---- oPROT -- Wo.MEP ------------ iPROT -- Wi.MEP ------XX----- Wi.MEP
-- iPROT --------- Wo.MEP -- oPROT ------- MEP
                        \                                         \-- Pi.MEP
---XX--------- Pi.MEP --/                                       /
                         \-- Po.MEP
----------------------------------------------------------------------------
------------------Po.MEP --/
 
6) important to notice is that the ProtPossible parameter in a MEP has to be
set to "0" under all conditions that disable the inner protection swithcing
process to restore the traffic; this includes a signal fail condition in
either working or protection connection, a lockout of protection command and
a forced switch command.
 
7) when the fault occurs at an intermediate node before the node with the
inner protection switching function, this inner node will have set the
ProtPossible parameter to the default value "0" (protection not possible).
 
8) Note that TS [or TP] SNC/S protection switching is normally not using AIS
defect as a trigger condition for protection switching. Reason is that AIS
insertion is slow compared CC/CV and consequently dLOC is detected much
faster (ie. 10 ms) then dAIS (1 second).
 
9) older equipment which is required to provide some restricted form of
protection switching can be upgraded such that it can detect incoming AIS
packets. Those incoming AIS packets will cause the detection of an AIS
defect (dAIS) and of a LDI defect (dLDI); dLDI is true if the AIS packets
have their ProtPossible flag set to "0" and dLDI is false is there is no AIS
incoming  or if there is AIS incoming and the ProtPossible flag is set to
"1".
 
10) newer equipment does not have to detect the LDI defect (dLDI).
 
11) note that AIS packets are inserted at the ingress ports, before the
switch fabric with the protection switch process. AIS insertion in e.g.
working input port is not stopped when the protection switch selects the
traffic from the protection input port. But as traffic is not longer
selected from the working input port, the AIS packets generated on this
working input port will not longer be forwarded to the output port.
 
12) the above does not address the presence and configuration of the Hold
off timers. Hold-off timers are required in nested protection switching
cases as an inner fault will always trigger the signal fail detection at
inner and outer protection switching levels. The detection of dLDI should
also overrule the hold off timer in the outer protection process.
 
13) There are more conditions (than the once mentioned in the above
consideration/description) that are to be considered before we know if this
slow CC/CV OAM work around will function as required... one of those
conditions is if there is another MEG level between with its own MEPs
between the inner and outer protection switching levels.If it would be a
requirement to support this slow CC/CV work around also in case of such
intermediate MEG level, then complexity of this work around will be much
higher... and msot likely it will become too complex...
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Vijayanand C - ERS, HCL Tech
Sent: vrijdag 18 juni 2010 8:29
To: MPLS TP
Subject: [mpls-tp] LDI generation during slow CC

Hello all,

In draft-ietf-mpls-tp-fault, section 2.3 says that when CC is slow LDI
enables faster switchover

 

It is not clear in the spec how LDI will be generated when CC is slow and
has not detected failure.

Is it implicit that the LSPs own detection mechanism ( refresh timeout, path
tear etc..) will trigger the LDI ?

 

Regards

Vijay

DISCLAIMER:

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

The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. 

It shall not attach any liability on the originator or HCL or its
affiliates. Any views or opinions presented in 

this email are solely those of the author and may not necessarily reflect
the opinions of HCL or its affiliates. 

Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of 

this message without the prior written consent of the author of this e-mail
is strictly prohibited. If you have 

received this email in error please delete it and notify the sender
immediately. Before opening any mail and 

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

---

From: [email-masked]
Date: Sat, 19 Jun 2010 10:16:14 +0800

Hi, Maarten.
Thanks for your explanations in details. But I still have some questions 
that wish you can clarify. Please see inline...

[email-masked] 写于 2010-06-18 17:55:57:

> Vijay,
> 
> The current draft draft-ietf-mpls-tp-fault-01 does include an MPLS-
> TP LDI OAM frame. This LDI frame must be removed from the MPLS-TP 
> OAM set as it will unnecessary complicate MPLS-TP. I have discussed 
> this with George Swallow some weeks ago and we agreed that for this 
> undocumented application the AIS OAM frame could be extended with a 
> "protection possible/not-possible" flag bit.
> 
> To understand the need for such protection possible/not-possible 
> flag bit it is required that the application is described first. 
> After a description of the application, we will be able to identify 
> if the proposed solution can work, or if it is incomplete and not 
> worth adding.
> 
> 1) A Transport Service (TS) or a Transport Path (TP) layer 
> connection is protected multiple times, e.g. 2 times. There is an 
> inner TS [or TP] protection span and there is an outer TS [or TP] 
> protection span (see figure below)
> 
>  MEP ---- oPROT -- Wo.MEP ------------ iPROT -- Wi.MEP 
> --------------- Wi.MEP -- iPROT --------- Wo.MEP -- oPROT ------- MEP
>                         \ 
> \-- Pi.MEP ---------------- Pi.MEP --/    /
>                          \-- Po.MEP 
> 
----------------------------------------------------------------------------------------------
> Po.MEP --/
> 
> 2) The outer protection is in some older equipment which is unable 
> to support fast MPLS-TP CC/CV OAM generation and reception; e.g. 
> this equipment is able to generate and receive CC/CV type OAM at 
> once per 10 seconds.
> 

xia: If the outer protection is in newer equipment, and the inner 
protection is in some older equipment. So the outer protection support 
more fast MPLS-TP CC/CV OAM generation than inner protection. In this 
application, does that mean that the outer protection finishes the 
protction switch fast before it receives the AIS from Wi.MEP? Do you agree 
with my understanding or you have another explanation? If my understanding 
is right, what is the reaction when the Wo.MEP receive the slow AIS from 
Wi.MEP?

> 3) The inner protection is in newer equipment which is able to 
> support fast CC/CV OAM generation and reception; e.g. once per 3.3 ms.
> 
> 4) when there is a fault in the inner working connection, then the 
> Wi.MEP function will detect Loss of Continuity defect (dLOC) in 
> about 10 ms and this dLOC will trigger the insertion of AIS OAM 
> within 1 second after detection of dLOC. Because the Wi.MEP function
> is part of a TS [or TP] SNC/S protection scheme, the protection 
> engine is able to set the ProtPossible parameter in the Wi.MEP 
> function to "1". When an AIS packet is generated, the ProtPossible 
> flag is set to "1". Then this AIS packet is received by the Wo.MEP 
> function in the older node, then the TS [or TP] SNC/S protection 
> process will inspect the AIS frame and checks the ProtPossible flag;
> if set to 1 it will don't take any action.
> 
> 
> AIS(ProtPossible=1)
> 
>  MEP ---- oPROT -- Wo.MEP ------------ iPROT -- Wi.MEP ------XX-----
>                         \ 
> \-- Pi.MEP --------------- Pi.MEP --/    /
>                          \-- Po.MEP 
> 
----------------------------------------------------------------------------------------------
> Po.MEP --/
> 
> 5) when there was already a fault in the inner protection connection
> (see figure below), then the inner protection engine would have set 
> the ProtPossible parameter in the Wi.MEP to "0". As soon as the 
> working connection fails, the Wi.MEP function will detect dLOC and 
> will insert within 1 second an AIS packet of which the ProtPossible 
> flag is set to "0". The Wo.EMP function in the older node will again
> inspect the AIS packet for the ProtPossible flag value and will now 
> trigger its own protection switching action (ProtPossible=0 
> indicates that inner protection can not restore the connection).
> 
> 
> AIS(ProtPossible=0)
> 
>  MEP ---- oPROT -- Wo.MEP ------------ iPROT -- Wi.MEP ------XX-----
>                         \ 
> \-- Pi.MEP ---XX--------- Pi.MEP --/   /
>                          \-- Po.MEP 
> 
----------------------------------------------------------------------------------------------
> Po.MEP --/
> 
> 6) important to notice is that the ProtPossible parameter in a MEP 
> has to be set to "0" under all conditions that disable the inner 
> protection swithcing process to restore the traffic; this includes a
> signal fail condition in either working or protection connection, a 
> lockout of protection command and a forced switch command.
> 
> 7) when the fault occurs at an intermediate node before the node 
> with the inner protection switching function, this inner node will 
> have set the ProtPossible parameter to the default value "0" 
> (protection not possible).

xia: In this situation, if the intermediate node is not between the two 
Wi.MEP. The Wi.MEP will not detect the dLOC and will not send AIS to the 
Wo.MEP. What do you mean "the inner node will have set the ProtPossible 
parameter..."? Or it's just my understanding question. Can you clarify to 
me?

> 
> 8) Note that TS [or TP] SNC/S protection switching is normally not 
> using AIS defect as a trigger condition for protection switching. 
> Reason is that AIS insertion is slow compared CC/CV and consequently
> dLOC is detected much faster (ie. 10 ms) then dAIS (1 second).
> 
> 9) older equipment which is required to provide some restricted form
> of protection switching can be upgraded such that it can detect 
> incoming AIS packets. Those incoming AIS packets will cause the 
> detection of an AIS defect (dAIS) and of a LDI defect (dLDI); dLDI 
> is true if the AIS packets have their ProtPossible flag set to "0" 
> and dLDI is false is there is no AIS incoming  or if there is AIS 
> incoming and the ProtPossible flag is set to "1".
> 

xia: Why? Does newer equipment need not dLDI to trigger its protection? I 
think it is still possible, e.g. when outer newer equipment has more slow 
CC/CV period than inner newer equipment.

> 
> 11) note that AIS packets are inserted at the ingress ports, before 
> the switch fabric with the protection switch process. AIS insertion 
> in e.g. working input port is not stopped when the protection switch
> selects the traffic from the protection input port. But as traffic 
> is not longer selected from the working input port, the AIS packets 
> generated on this working input port will not longer be forwarded to
> the output port.
> 
> 12) the above does not address the presence and configuration of the
> Hold off timers. Hold-off timers are required in nested protection 
> switching cases as an inner fault will always trigger the signal 
> fail detection at inner and outer protection switching levels. The 
> detection of dLDI should also overrule the hold off timer in the 
> outer protection process.
> 
> consideration/description) that are to be considered before we know 
> if this slow CC/CV OAM work around will function as required... one 
> of those conditions is if there is another MEG level between with 
> its own MEPs between the inner and outer protection switching 
> levels.If it would be a requirement to support this slow CC/CV work 
> around also in case of such intermediate MEG level, then complexity 
> of this work around will be much higher... and msot likely it will 
> become too complex...
> 
> Regards,
> Maarten
> 
> From: [email-masked] [mailto:[email-masked]] On 
Behalf Of 
> Vijayanand C - ERS, HCL Tech

> “In more general MPLS environments the CC function may
>    faster switch-over upon a failure occurring along the LSP.”
> 
> 
> Is it implicit that the LSPs own detection mechanism ( refresh 
> timeout, path tear etc..) will trigger the LDI ?
> 
> The contents of this e-mail and any attachment(s) are confidential 
> and intended for the named recipient(s) only. 
> this email are solely those of the author and may not necessarily 
> reflect the opinions of HCL or its affiliates. 
> Any form of reproduction, dissemination, copying, disclosure, 
> modification, distribution and / or publication of 
> this message without the prior written consent of the author of this
> e-mail is strictly prohibited. If you have 
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: George Swallow <[email-masked]>
Date: Mon, 21 Jun 2010 10:35:55 -0400

Xia -

If you are running CC at a high rate, then the normal AIS processing occurs.
Even if a server MEP is using the slower procedures, it must send the AIS
three times (the draft says send (1 time) and then retransmit twice (2
times)) space at 1 second intervals before reverting to a slower rate.  This
is to make sure that the same level of effort as Y.1731 offers is made to
suppress the alarm before the 2 second hold-off expires.

...George

On 6/18/10 10:16 PM, "[email-masked]" <[email-masked]> wrote:

> 
> Hi, Maarten. 
> Thanks for your explanations in details. But I still have some questions that
> wish you can clarify. Please see inline...
> 
> 
> 
> xia: If the outer protection is in newer equipment, and the inner protection
> is in some older equipment. So the outer protection support more fast MPLS-TP
> CC/CV OAM generation than inner protection. In this application, does that
> mean that the outer protection finishes the protction switch fast before it
> receives the AIS from Wi.MEP? Do you agree with my understanding or you have
> another explanation? If my understanding is right, what is the reaction when
> the Wo.MEP receive the slow AIS from Wi.MEP?
> 
> parameter..."? Or it's just my understanding question. Can you clarify to me?
> 
>> >  
>> -----------------------------------------------------------------------------
>> ------------------------------------------
>> > 
>> -----------------------------------------------------------------------------
>> ------------------------------------------
>> > 
> ZTE Information Security Notice: The information contained in this mail is
> solely property of the sender's organization. This mail communication is
> confidential. Recipients named above are obligated to maintain secrecy and are
> not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed. If
> you have received this email in error please notify the originator of the
> message. Any views expressed in this message are those of the individual
> sender.

---

From: [email-masked]
Date: Tue, 22 Jun 2010 10:08:48 +0800

George:
  firstly, Thanks for your reply!
  I agree with you opinion. Sending AIS should be nothing to do with 
whether the server MEP is using faster or slower procedure. 
  Actually, I just have some doubts of the necessity of generating AIS in 
server MEP when it is using the slower procedure because the out fast 
protection switch has finished before it receives the AIS. And I am not 
sure if the out fast protection can always assure the faster switch before 
it receives the AIS. So, I made this question and hoped for the further 
explanation.

                      xia.liang
                     best regard

George Swallow <[email-masked]>  2010-06-21 22:35:55:

> Xia -
> 
> If you are running CC at a high rate, then the normal AIS processing
> occurs.   Even if a server MEP is using the slower procedures, it 
> must send the AIS three times (the draft says send (1 time) and then
> retransmit twice (2 times)) space at 1 second intervals before 
> reverting to a slower rate.  This is to make sure that the same 
> level of effort as Y.1731 offers is made to suppress the alarm 
> before the 2 second hold-off expires.
> 
> ...George
> 
> 

> 
> Hi, Maarten. 
> Thanks for your explanations in details. But I still have some 
> questions that wish you can clarify. Please see inline...
> 
> 
> 
> protection is in some older equipment. So the outer protection 
> support more fast MPLS-TP CC/CV OAM generation than inner 
> protection. In this application, does that mean that the outer 
> protection finishes the protction switch fast before it receives the
> AIS from Wi.MEP? Do you agree with my understanding or you have 
> another explanation? If my understanding is right, what is the 
> reaction when the Wo.MEP receive the slow AIS from Wi.MEP? 
> 

> xia: In this situation, if the intermediate node is not between the 
> two Wi.MEP. The Wi.MEP will not detect the dLOC and will not send 
> AIS to the Wo.MEP. What do you mean "the inner node will have set 
> the ProtPossible parameter..."? Or it's just my understanding 
> question. Can you clarify to me? 
> 
> > 
> xia: Why? Does newer equipment need not dLDI to trigger its 
> protection? I think it is still possible, e.g. when outer newer 
> equipment has more slow CC/CV period than inner newer equipment. 
> 
> > 

> ZTE Information Security Notice: The information contained in this 
> mail is solely property of the sender's organization. This mail 
> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.
> This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 
> notify the originator of the message. Any views expressed in this 
> message are those of the individual sender.