[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PWE3] [mpls] Comment onhttp://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt
Title: Re: [mpls] Comment onhttp://www.ietf.org/id/draft-sfv-mpls-tp-fault-01.txt
Maarten -
See inline:
On 12/17/09 2:45 AM, "Maarten Vissers" <maarten.vissers at huawei.com> 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.:
- 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.
- 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.
- The “control function” on determining that both the server layer working and protection have failed, de-select both and send LDI itself.
- 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.
- (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: mpls-tp-bounces at ietf.org [mailto:mpls-tp-bounces at ietf.org] On Behalf
Of Loa Andersson
Sent: donderdag 17 december 2009 5:36
To: mpls-tp at ietf.org; mpls at ietf.org; ccamp at ietf.org; pwe3 at ietf.org
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 mpls-tp at ietf.org 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: loa.andersson at ericsson.com
Sr Strategy and Standards Manager loa at pi.nu
Ericsson Inc phone: +46 10 717 52 13
+46 767 72 92 13
_______________________________________________
mpls-tp mailing list
mpls-tp at ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls mailing list
mpls at ietf.org
https://www.ietf.org/mailman/listinfo/mpls