Subject: Re: [PWE3] [mpls] Comment onhttp://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt

From: George Swallow <[email-masked]>
Date: Wed, 10 Mar 2010 16:36:34 -0500

Maarten -

See inline:

On 12/17/09 2:45 AM, "Maarten Vissers" <[email-masked]> wrote:

> 
> 
> Some comments on the content of this draft:
> 
> In section 2.1 it is stated:
> "  <..>
>    For example an AIS message may be sent during a protection switching
>    event and would cease being sent if the protection switch was
>    successful in restoring the link.
> 
>    Its primary purpose is to suppress alarms in the MPLS-TP layer
>    network above the level at which the defect occurs.  The AIS message
>    MAY be used to trigger recovery mechanisms.  It should be noted that
>    such use would be subject to false positives, e.g. unnecessary
>    protection switching events in the client layer."
> 
> It is not correct to state that AIS sending is stopped if the protection
> switch was succesful. The reason is that the AIS insertion is done by a MEP
> Sink function that is upstream of the protection switch selector process,
> and this MEP Sink function is as such unaware of the presence of a
> protection switch process and of the state of the protection switch process.
> 
GS:  For better or worse, there is a significant difference in how the ITU
and IETF write specifications.  While the ITU defines detailed equipment
specifications, the IETF almost always speaks only about the behavior of the
³node² and what is seen ³on the wire².  So from a IETF perspective, if a MEP
generates AIS and then a selector process causes that AIS to be dropped,
then the node has stopped sending AIS and is fully compliant with the text
above.
> 
> AIS in packet transport networks must **not** used to trigger recovery
> mechanisms. Reason is that AIS OAM messages in packet transport network are
> to be generated within 1 second after the detection of the signal fail type
> defect detection and be generated with a periodicity of 1 second. These
> times are much too long to trigger any recovery mechanism.
> 
GS:  For a pure transport application, I totally agree.  If the CC function
is function is running fast enough to detect the failure in << 1 second then
AIS nor LDI should be used to do protection switching.
> 
> The 1 second time requirement to generate the first AIS message is derived
> from the 2.5 +/- 0.5 second fault cause to failure integration timer as
> specified in G.7710. Generation of the first AIS message within a period of
> 1 second will leave enough time to reach the downstream MEP Sink function
> and suppress the fault cause that report the interruption of the connection.
> 
> Protection switching in packet transport networks is triggered by e.g. loss
> of continuity and misconnection defects.
> 
> In section 2.2 it is stated:
> "  The LDI message is generated in response to detecting a fatal failure
>    in the server layer.  The LDI message MUST NOT be sent until the
>    defect has been determined to be fatal.  For example during a
>    protection switching event LDI messages are not sent.  However if the
>    protection switch was unsuccessful in restoring the link within the
>    expected repair time, an LDI message MUST be sent."
> and in section 2.1 it is stated:
> "  The MPLS-TP Alarm Indication Signal (AIS) message is generated in
>    response to detecting defects in the server layer.  The AIS message
>    SHOULD be sent as soon is the condition is detected, that is before
>    any determination has been made as to whether the condition is fatal."
> 
> This draft suggest that it is possible for a MEP Sink function to determine
> if the fault is *fatal* or *not fatal*. This is not possible for a MEP Sink
> function. The reason is that a MEP Sink function has no knowledge of the
> presence or state of a protection switch process associated with the
> connection. E.g. the protection switch process may be in a downstream node.
> 
GS: The assumption is that something in the box is capable of knowing if the
facility is unprotected or if protection is currently unavailable.
> 
> It is also not necessary to make AIS generation conditional on e.g.
> protection switch actions. Reason is that a protection switch process will
> select traffic from either a working connection input port, or a protection
> connection input port. Any traffic present on the not selected input port
> will drop at this input port and not be forwarded to the protection switch
> process output port. At the output port AIS messages will be present as long
> as the protection switch process selects its traffic from the failed
> connection; once the protection switch process selects its traffic from the
> non-failed connection AIS messages will not longer be forwarded to the
> output port.
> 
GS:  Consider the following:

A client signal is cross-connected over a server layer connection at NodeA.
The server layer connection has 1:1 protection.

The server layer protection LSP fails, MEP-P starts sending AIS towards the
client MEP.  These are dropped as the selector is forwarding traffic from
the server layer working LSP.  Now working fails.

The desired behavior is that "something" causes LDI to be inserted in the
client signal at NodeA.

This could be implemented in any number of ways, e.g.:

1. When the server layer protection LSP fails, the ³control function²
proactively instructs (programs) MEP-W to change its OP-CODE from AIS to
LDI.  Thus if the server layer working LSP fails, LDI is sent.
2. If the box is built such that the selector will switch to protection even
if protection has already failed, then the ³control function² proactively
instructs (programs) MEP-W to change its OP-CODE from AIS to LDI.  The when
the selector moves to protection, LDI will begin to be sent.
3. The ³control function² on determining that both the server layer working
and protection have failed, de-select both and send LDI itself.
4. The ³control function² on determining that both the server layer working
and protection have failed, reactively instructs the MEP of the currently
selected server layer LSP to change its OP-CODE from AIS to LDI.
5. (My favorite) Given that a modern box should be able to effect a
switch-over in a few milliseconds, implement in every MEP a hold-off timer
equal to the fail-over budget.  Then send LDI (AIS is never produced).

...George
> 
> This draft should as such not become a WG document.
> 
> Regards,
> Maarten
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Loa Andersson
> Sent: donderdag 17 december 2009 5:36
> To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: [mpls-tp] Poll om making
> http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt a working group
> document
> 
> All,
> 
> this is to start a two week poll on making
> 
> http://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt
> 
> an MPLS working group document.
> 
> Send a mail to the [email-masked] mailing list, indicating "yes/support"
> or "no/do not support".
> 
> Comments on the content of the draft should be sent to the same mailing list
> with a different subject line.
> 
> The poll ends Friday 15 Jan, 2010.
> 
> /Loa
> --
> 
> 
> 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 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: George Swallow <[email-masked]>
Date: Thu, 11 Mar 2010 09:28:23 -0500

Maarten -

See Inline -

On 12/18/09 6:29 AM, "Maarten Vissers" <[email-masked]> wrote:

> I would like to raise three additional issues in this draft.
> 
> 1) in section 3 it is stated "The FM Channel uses ACH TLVs and MUST include
> the ACH TLV header." and "The ACH TLVs may include (but are not limited to)
> IF-ID, Global-ID, and ICC." AIS and LCK OAM messages should not carry any
> identifiers, as such identifiers are not read by the receiving MEP. Those
> identifiers are not providing any useful information to network management
> or detector circuits. Addition of such identifiers to the AIS and LCK frames
> adds unnecessary complexities to the designs.
> 
GS: Hummm...  I got the idea for Global-ID / ICC from Y.1711.  Sounded
pretty useful in the inter-domain case  where the NMS would not be able to
correlate alarms across domain boundaries.
> 
> 2) In section 4 it is stated "R-flag   The R-flag is normally set to zero.
> A setting of one indicates the removal of a previously sent FM condition."
> This R-flag is not a helpful feature in AIS and LCK messages. Addition of
> such flag only increases complexity of the solution and designs. It is a
> classical item, discussed in previous OAM developments as well. The idea is
> that the receiver can be explicitly informed about the end of the AIS or LCK
> condition. Unfortunately it is necessary to take into account that a packet
> may be dropped due to congestion or bit errors. As such, the AIS and LCK
> detector circuits in the MEP Sink fucntions must be able to clear the AIS
> and LCK defects also when such packet with R-flag was lost (which is
> foreseen in the specification in section 5.3). It is therefore less complex
> to have the absence of three AIS or LCK packets being used as clearing
> condition for the AIS and LCK defects.
> 
GS:  If you don¹t want to complicate you logic, you can just ignore packets
that have the R-bit set.
> 
> 3) In section 4 it is stated "Refresh Timer   The maximum time between
> successive FM messages specified in seconds.  The range is 1 to 65535.  The
> value 0 is not permitted. The default value is 60." The default AIS and LCK
> repetition period is generically 1-second, not 60-seconds. There is no need
> 
GS:  Changed the default, when not using the optional clearing, to 1 second.
> 
> for a range of AIS and LCK repetition periods. The first AIS packet for each
> LSP/PW impacted by the fault has to be generated within 1 second after a
> signal fail type defect is detected and the next one has to be generated
> 1-second later. This 1 second period is necessary in order to prevent that
> 
GS: Why does Y.1731 allow for 1 second or 1 minute?

...George
> 
> downstream the alarms are raised (which happens after 2.5 +/- 0.5 seconds).
> If the first AIS packet was lost (due to congestion or bit errors) then
> there is a second AIS packet that will be received by the MEP Sink fucntion
> before the 2.5 +/- 0.5 second fault cause to failure filter will expire.
> Either the first or second AIS packet will clear the fault cause and prevent
> the alarm from being raised.
> 
> 
> 
> MPLS-TP AIS and LCK OAM packets should be very simple OAM packets including
> only a Version number and OAM Type (MsgType or OpCode). AIS and LCK OAM
> packets should be inserted within 1 second after the condition to generate
> those packets became active and these OAM packets must be send with a 1
> second repetition rate.
> 
> Regards,
> Maarten
> 
> 
> 
>   
> 
> Of Maarten Vissers
> Sent: donderdag 17 december 2009 8:45
> To: 'Loa Andersson'; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: [mpls-tp] Comment
> onhttp://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt
> 
>