Re: [mpls-tp] [mpls] mpls WG last call on draft on draft-ietf-mpls-tp-linear-protection-04: Major comments (part 1)

["LASSERRE, MARC (MARC)" <[e-mail]>]

I am forwarding this message again (in 2 parts) as the original message bounced. Sorry for the extra delay.

Marc

________________________________
From: LASSERRE, MARC (MARC)
Sent: mardi 1 mars 2011 01:27
To: '[e-mail]'; '[e-mail]'
Subject: Re: [mpls] mpls WG last call on draft on draft-ietf-mpls-tp-linear-protection-04

Below is a list of major comments to draft on draft-ietf-mpls-tp-linear-protection-04:

1.   General: A definition of Failure of Protocol defects is missing. There is only a mention in 4.2.3 (Protection type field) or in 4.2.4 (Revertive field) that inconsistency in the value between both end points leads to an alarm SHALL be sent to the management system, but this is not sufficient; there are other protocol and configuration mismatches which should be alarmed.
2.   General: the Exercise operator command is missing. Exercise is used to test, while in idle situation, that a protection path is available and that the protection mechanism works properly without actually switching the traffic itself. Exercise is a requirement in RFC 5654 MPLS-TP Requirements (Reqt #84).
3.   General: The current document misses a specification for a Hold-off timer. It is only shortly mentioned in section 3.1.1 (page 9) and is only a MAY. An explicit description is needed.
4.   General: Neither this document nor the MPLS-TP Survivability Framework document mention the protection switching time performance objective of 50ms as requirement.  In the MPLS-TP Survivability Framework document, there is only one mention on pgae 30 "For 50-ms protection switching, ...".  In this document, there is only indirect mention in "For protection switching within 50ms, it is RECOMMENDED that the default interval of the first three PSC messages SHOULD be no larger than 3.3ms."
It needs to be explicitly mentioned

5.   Section 1.1 (page 4) and Section 4.2.3 (page 17): IETF defines both 1+1 and 1:1 unidirectional and 1+1 and 1:1 bidirectional. ITU-T G.8031 (Ethernet) and G.8131 defined 1+1 unidirectional, 1:1 and 1+1 bidirectional but not 1:1 unidirectional. What's the rationale behind the inclusion of 1:1 unidirectional? There is no known application for it, neither in legacy transport networks nor in Ethernet Transport networks.
What are the applications for it?

6.   Section 3.1.5 (page 12): the WtR timer can be stopped by the PSC Control Logic. The text is not clear if the operator also has possibility to override the WtR timer and its PSC Control logic by clearing manually the WtR timer. Clear of WtR is a capability in transport network. Two solutions: either introduce a Clear WtR command or use the same Clear command as used for clearing LO/FS/MS operator command to stop the WtR timer.
7.   Section 3.1.5 (page 12): Is it possible to list the range of values, steps and default for the WtR timer? (In ITU-T, WtR values are explicitly provided: 1 minute steps between 5 and 12 minutes; the default value is 5 minutes.)
8.   General about Section 4.2: PSC signaling: the LER always signals (in Request field) the local highest priority request and, consistently, signals in FPath field, either the signal 1 (when protection is required) or signal 0 (when the protection is unavailable). Then it matches the possible far end highest priority request, by signaling (in Path field) the same value of Path field in PSC packet received.
With this behavior, a command locally applied at one end, with a lower priority than far end requests, seems to be kept as "pending" (there is no evidence of a different behavior in the draft).  "pending" commands are not allowed to co-exist.
9.   Section 4.1 (page 15): Wrt paragraph "The frequency of the three rapid messages and the separate frequency of the continual transmission SHOULD be configurable by the operator. For protection switching within 50ms, the default interval of the first three PSC messages is RECOMMENDED to be no larger than 3.3ms. The continuous transmission interval is RECOMMENDED to be 5 seconds".
Replace the "SHOULD" by a "MAY" in the first sentence.
 Rationale: There is no strong requirement to make them configurable by the operator. All packet transport network operators want it to switch in 50ms and have as little configuration as possible. In current practice such rates are not configurable; neither are they in ITU-T G.8031. Therefore the proposal is to replace the "SHOULD" by a "MAY" in the first sentence.
10. Section 4.1 (page 15): The following requirement "If no valid PSC specific information is received, the last valid received information remains applicable. In the event a signal fail condition is detected on the protection path, the received PSC specific information should be evaluated." should be revised:
o  Proposal to remove the second sentence "In the event a signal fail condition is detected on the protection transport entity, the received PSC specific information should be evaluated" as it is is either incorrect or misleading. When SF is detected on a protection MPLS-TP LSP, the data is meaningless so evaluating it is not meaningful.

11. Section 4.1 (page 15): The last paragraph should also add "If a protection end point receives PSC-specific information from the working entity, it should ignore this information. This will also lead to detection of a Failure of Protocol defect" (see comment #1 for FOP)."
12.       Appendix A (page 31): The sentence "In the event of a mismatch between these tables and the text in section 4.3.3, the text is authoritative."
Proposal to align text and table instead

13. Section 4.3.3.4 (page27) When in remote protection state failure and suddenly an NR is received , LER need to go to normal, if not a lock condition exist where one end is in remote protection failure state waiting for WTR and the other end is in normal.
The test following text should be added to Section 4.3.3.4 (page27)
"If in remote Protecting failure state, a remote NR message SHALL cause the LER to go into the Normal state and SHALL transmit a NR(0,0) message."
Page 34 table part2 should also be corrected as follow (replace i by N):
PF:W:R  |UA:LO:R|UA:P:R|PA:F:R| i    | i    | [14] | [15] | i(N)

14. Section 4.3.3.5 (page29) Remote Wait-to-restore state is not addressed properly.
It is mentioned on page 27, but later on page 32 only WR state is mentioned.
In order not to get stuck in remote wait-to-restore state on both end sending NR(0,1) in a recovery of a simultaneous Signal Fail on working, the following need to be added on (page29)
"If in remote wait-to-restore state then a remote NR message SHALL cause the LER to go into Normal state and begin transmitting a NR(0,0) message."
The table on page 34 Part 2 line WTR addresses the issue.