Subject: Re: [mpls] [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

From: George Swallow <[email-masked]>
Date: Fri, 01 Jul 2011 18:15:39 -0400

Xinchun -

This restriction was not intended.  The draft has been updated to make it
clear that it is applicable to both.

,,,George

On 2/13/11 11:09 PM, "Xinchun Guo" <[email-masked]> wrote:

> Hi authors and all
> 
> About this document, I have another question expect to be clarification. I
> am not very clear about the specific application of Fault management
> message.
> 
> In section 2 of this document, it said " Fault OAM messages are generated by
> intermediate nodes where an LSP is switched".  Does it mean that the fault
> message can only be used for alarm suppress of LSP layer?  Could not this
> fault management function be used for PW layer, especially for the MS-PW
> conditions.  Take the following hiberarchy scenario for example, PW1 and PW2
> are two segments of the MS-PW which is client of the LSP layer.  if the
> server layer of LSP fails, such as Link1, node2 will initiate AIS message
> and sent it to LSP1 end point node3.  As MS-PW is client of LSP1, for this
> condition, whether Node3 will further initiate Fault management message to
> MS-PW end point Node4 to notify the failure of LSP1 to suppress alarm of the
> end to end pw service.  IMO, Fault management function should cover these PW
> conditions.
> 
> -                        MS-PW                   -
> -                           +---------AIS/LKR-------------->>-
> -<-----------------PW1-------------------->|-----------------PW2------------
>> >-
> -              +----AIS/LKR---->>                     -
> -<-------LSP1---------+-------------------><--------------LSP2--------------
> ->-
> -              |AIS/LKR                            -
> -<--- Link1---------->|<---
> Link2------><--------Link3--------------------->-
> Node1       Node2       Node3                Node4
> 
> 
> Hope authors could clarify this point and detail the Fault function process
> about PW scenarios in this document.
> 
> Best Regards
> Xinchun
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Xinchun Guo
> Sent: Friday, February 11, 2011 5:52 PM
> To: 'Loa Andersson'; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03
> 
> Other 3 edit comments, see below.
> 
> 1.section 2.2, there is overlapping between the last sentence of the first
> paragraph and the first sentence of the second paragraph about " The purpose
> of the LKR message is to suppress alarms in the MPLS-TP layer network above
> the level at which the defect occurs" . Simplify it will be more smart.
> 
> 2.section 4.1.2, the first sentence" This TLV carries the Interface
> Identifier as defined ......", "the Interface Identifier" should be "the
> Global Identifier". right?
> 
> 3. section 5.3, there are two "that" in the first sentence, one is
> redundancy.
> 
> Regards
> Xinchun
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Xinchun Guo
> Sent: Friday, February 11, 2011 9:39 AM
> To: 'Loa Andersson'; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03
> 
> Dear authors
> 
> After read the document, I have a question about the FM massage procedure.
> 
> In the section 5.1, the third paragraph, it said "The message is then sent.
> The message MUST be refreshed two more times at an interval of one second.
> Further refreshes are sent according to the value of the refresh timer."  I
> don't know why the refreshing massage must be first sent two more times in
> one second and then sent as the refresh timer interval.  Is it ok if the
> refreshing massage is sent only according to the value of the refresh timer?
> If it is not, what problem may be introduced? Hope authors could explain it
> for me.
> 
> In addition, figure 2 is about the fault management massage format, so I
> think naming the figure" MPLS-TP fault Management Message Format " other
> than" MPLS-TP OAM Message Format " is more suitable.
> 
> Best Regards
> Xinchun
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Loa Andersson
> Sent: Thursday, February 03, 2011 7:37 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03
> 
> Working Group,
> 
> this is to start a four week working group last call
> on "MPLS Fault Management OAM" (draft-ietf-mpls-tp-fault-03).
> 
> Please send comments to the [email-masked] mailing list.
> 
> This working group last call ends on February 28, 2011.
> 
> 
> 
> Loa, George and Ross
> 
> MPLS wg co-chairs
> 
> --
> 
> Loa Andersson                         email: [email-masked]
> Sr Strategy and Standards Manager            [email-masked]
> Ericsson Inc                          phone: +46 10 717 52 13
>                                               +46 767 72 92 13
> 
> 
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 
> 
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 
> 
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> 
> 
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: George Swallow <[email-masked]>
Date: Mon, 11 Jul 2011 16:49:06 -0400

Yugi -

Thanks for the comments.

See inline

On 2/28/11 5:59 AM, "Yuji Tochio" <[email-masked]> wrote:

> Hi,
> 
> Some comments
> 
> * Section 2.1 (, 2.1.1)
> There are some use of fatal. Please clarify what fatal means.
> And it is better to have the definition of this both for AIS
> and for LDI

fault is defined in the document - changed all occurrances of fatal to fault
 
> * Section 2.1.1
> Use of protection seems to relate to the usage for LDI, differentiated
> from AIS.
> And "The setting of the LDI flag can be predetermined based
> on the protection state If the Server Layer is protected...."means
> that there is server layer protection scheme and this prederminnes
> the usage of LDI.
> This server layer protection scheme should be more clarified.
> Is the server layer supposed to have 1:1?
> How about 1+1?

Either form of protection is fine. But, I don't think this needs to be
called out in the draft.

> And active MEP should be active Server MEP

Fixed.

> This had been already pointed out in general by
> http://www.ietf.org/mail-archive/web/mpls-tp/current/msg02793.html
> (last part in that mail)
> 
> * Section 4
> Please clarify the reception behavior when
> - Msg type= reserved

added message type = reserved as a condition for dropping

> - Msg type = LCK & L-flag set
> (should be ignored and this should be described in 5.3)

updated description of L-flag with "The L-flag only has significance in the
AIS message.  For the LKR message the L-flag MUST be set to zero and ignored
on receipt."

> * Section 5.1
> Following sentence is unclear
> "The message MUST be refreshed two more times at an interval
> of one second."
> I guess this implies that messages should be more than specified
> at first second. Is this right? Does this apply to refresh timer is 1?

updated beginning of sentence, "Assuming the condition persists, the message
MUST be retransmitted"

> And in early review from ITU-T, it is proposed to remove the refresh timer
> but it still remains. It is better to have the clear reason why it is needed.

Y.1731 allows for 1 sec or 1 minute refreshed.  The point is that the
messaging can be expensive on some existing platforms.

> Section 5.3
> It says:
> A message is considered a refresh if the message type and IF_ID match
> an existing condition and the R-Flag is set to zero.
> 
> How about this case?
> A-->B-->C-->D
> D is receiving AIS or LDI with IF_ID = B. But another failure at C
> happens D starts to receive LDI with IF_ID = C.
> In this case, does D have to have two timers for B and C

This is an implementation issue.  If an operator has configured nodes with
varying refresh timers, then to be completely safe about alarm suppression I
would say the answer is yes.  But if the fault at C persists you will not
see the AISes from B and that could time-out anyway.  So you could have the
same issue with a gap in alarm suppression.

Note that this issue also exists in Y.1731 as well.

> ...And it is confused that is "refresh(ed)"
> It seems that following cases are used in common, but different places
> - the receiver, MEP that refresh timer is in for reception process
> - the transmitter (as fault detection by refresh timer)
> - the transmitter (as message generation makes format refresh by over-written)

Rewrote much of this section.  Hope you like the new text better.

...George

> Regards,
> Yuji
> 
> (2011/02/03 20:36), Loa Andersson wrote:
>> Working Group,
>>

---

From: Maarten vissers <[email-masked]>
Date: Mon, 18 Jul 2011 00:34:26 +0000

Resend..

-----Original Message-----
From: Maarten vissers 
Sent: 18 July 2011 00:38
To: 'George Swallow'; 'Maarten vissers'; [email-masked]'
Subject: RE: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

George,

Your response below made me aware of an unnoticed terminology issue in the draft. I.e.

>  Within the Defect class, a further category, Fault is identified.  A
>  fault is the inability of a function to perform a required action.  A
>  fault is a persistent defect.

The above text from the draft puts the things upside down... in the ITU-T recommendations, a fault is the actual problem which results in the detection of anomalies and when those anomalies are persistent into a defect. I.e. fault => anomaly detection => defect detection (persistent anomalies).

In your draft you extend the above with a "second type of fault"; i.e.
fault => anomaly detection => defect detection (persistent anomalies) => fault (persistent defect).
This is not a good approach in my opinion. In the LDI text in section 2.1.1 you talk about a "fatal defect", and it would be better to use this term instead. The text would then become as follows:

	"Within the Defect class, a further category, Fatal Defect is identified. A fatal defect is a defect for which there is no recovery function available locally (after defect detector) or upstream (before defect detector)."

Regards,
Maarten

> From: George Swallow [mailto:[email-masked]]
> Sent: 11 July 2011 23:56
> To: Maarten vissers; [email-masked]
> Maarten -
> You seem to be extrapolating behavior of higher level entities based on
> text
> that is about server MEPs.  The important text for MEP4 and MEP2 is
> "The
> L-flag MUST NOT be set until the defect has been determined to be a
> fault."
> 
> I updated the next paragraph to make it clear that it is an example and
> also
> made the should(s) in that paragraph lowercase to make it clear that it
> is
> not normative text.
> 
> You also cause me to release that I should have a few words on fault
> propagation.  I added a small section.
> 
> ...George
> 
> 
> On 2/28/11 7:48 AM, "Maarten Vissers" <[email-masked]>
> wrote:
> 
> > Comment on LDI operation:
> >
> > LSPs can be nested, and it is possible to have an LSP stack with e.g.
> five
> > LSPs (A,B,C,D,E) as follows:
> >
> > MEP1-----------------------(A)--------------------------MEP2
> >        MEP3----------(B)----------MEP4   MEP5--(C)---MEP6
> >              W.MEP7--(D)--W.MEP8
> >              P.MEP9--(E)--P.MEP10
> >
> > When LSP(D) fails, LSP(B) and LSP(A) fail as well.
> > W.MEP8, MEP4 and MEP2 will detect this failure and will insert AIS.
> >   - W.MEP8 can send AIS(L-flag=0).
> >   - MEP4 and MEP2 have no immediate knowledge of the
> >     server layer/sublayer protection, and send AIS(L-flag=1).
> >
> > As there is protection present at a server (sub)layer and both
> working and
> > protection paths are available before the fault occurs, MEP4 and MEP2
> should
> > have send AIS(L-flag=0) instead of AIS(L-flag=1).
> >
> > How to control that MEP4 and MEP2 set the LDI flag to "clear" when
> working and
> > protection paths are both available in this case?
> >
> > Regards,
> > Maarten
> >
> >

---

From: Maarten vissers <[email-masked]>
Date: Mon, 18 Jul 2011 00:37:10 +0000

Resend..

-----Original Message-----
From: Maarten vissers 
Sent: 18 July 2011 00:38
To: 'George Swallow'; [email-masked]'
Subject: RE: [mpls-tp] wg last call on draft-ietf-mpls-tp-fault-03

George,

MEP2 is in a network of e.g. operator Y and W.MEP8 is in a network of e.g. operator X. How does operator Y know that operator X has protected a part of LSP B? If Y has not told X, then MEP2 will be in a node not supporting any protection, and thus must generate AIS with LDI set to 1 as per specification; i.e. based on: 
   The setting of the LDI flag can be predetermined based on the
   protection state.  If the Server Layer is protected and both the
   working and protection paths are available, both the active and
   standby MEPs should be programmed to send AIS with LDI clear upon
   detecting a defect condition.  If the Server Layer is unprotected or
   the Server Layer is protected but only the active path is available,
   the active MEP should be programmed to send AIS with LDI set upon
   detecting a defect condition.
MEP2's LDI configuration is based on unprotected server layer in network Y and has its LDI thus set to 1.

Similarly, if MEP4 is in a different node in network X than W.MEP8/P.MEP10, then LDI should be set to 1 in MEP4 as there is no communication channel from the node with W.MEP8/10 and the protection switching function and the node with MEP4 to control the setting of the LDI bit in MEP4 (and also in MEP2).

In this example, MEP4 and MEP2 have either 
1) configured the value of LDI by NMS to 1 (LDI set), or have 
2) a communication channel from W.MEP8/P.MEP10 to MEP4 and MEP2 to control the LDI value (expensive!), or have
3) a timer which on expiry changes the LDI value from LDI=0 (clear) to LDI=1 (set). 

Regards,
Maarten
PS. The timer value should be standardized, and have e.g. a value of 100 ms; i.e. AIS is initially generated with LDI=0 (clear) and after 100 ms either the defect condition in MEP4/2 was cleared and AIS insertion stopped, or AIS is now generated with LDI=1. The defect condition in W.MEP8 is still present and AIS is now generated with LDI=1 after 100 ms (get dropped if protection switch selected signal from P.MEP9).

If we would use a timer with fixed value, then LDI indication can be dropped, and the AIS receiver can interpret the first 100 ms of AIS as potentially protected connection upstream, and after 100ms as unprotected or unable to protect connection; i.e. LDI detection is ">100 ms AIS" detection.