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

"LASSERRE, MARC (MARC)" <marc.lasserre@alcatel-lucent.com> Thu, 03 March 2011 09:13 UTC

Return-Path: <marc.lasserre@alcatel-lucent.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28D173A6964; Thu, 3 Mar 2011 01:13:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.581
X-Spam-Level:
X-Spam-Status: No, score=-5.581 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alikdwQKti5y; Thu, 3 Mar 2011 01:12:58 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 87EA13A695F; Thu, 3 Mar 2011 01:12:57 -0800 (PST)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p239CcHN018916 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 3 Mar 2011 10:14:02 +0100
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 3 Mar 2011 10:13:49 +0100
From: "LASSERRE, MARC (MARC)" <marc.lasserre@alcatel-lucent.com>
To: "LASSERRE, MARC (MARC)" <marc.lasserre@alcatel-lucent.com>, "mpls-tp@ietf.org" <mpls-tp@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Date: Thu, 03 Mar 2011 10:13:46 +0100
Thread-Topic: Re: [mpls] mpls WG last call on draft on draft-ietf-mpls-tp-linear-protection-04: Minor comments (part 2)
Thread-Index: AcvXp1+R2FxKFrhcTxK2hQuKpBDsQQB2JyOgAADGK/A=
Message-ID: <E6E66922099CFB4391FAA7A7D3238F9F214DB50D@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: fr-FR, en-US
Content-Type: multipart/alternative; boundary="_000_E6E66922099CFB4391FAA7A7D3238F9F214DB50DFRMRSSXCHMBSC3d_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83
Subject: Re: [mpls-tp] [mpls] mpls WG last call on draft on draft-ietf-mpls-tp-linear-protection-04: Minor comments (part 2)
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Mar 2011 09:13:05 -0000

Here is the second part of the message with minor comments.

Marc

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

Below is a list of minor comments to draft on draft-ietf-mpls-tp-linear-protection-04:
- The document uses consistently the term working path but inconsistently either recovery or protection path. The term "protection path" is more commonly used.
- Section 3.1 (page 7): In "e.g. switching the Selector Bridge to select the working or protection path, and transmit different protocol messages." It is not only the selector bridge which selects the working and protection paths: to be precise, it can be the Selector Bridge at the source or the Selective Selector at the sink of the protection domain.
- Section 3.1 (page 8): Figure 1 is not complete. It could be enhanced with additional text and blocks as for example in ITU-T G.8031: the output of the PSC Control Logic is not only action to generate PSC message to far-end, it should also show the local action to set the local bridge/selector. The Remote PSC Request should first go through a PSC message Validity Check
- Section 3.1.1 (page 9) - 1st bullet: in "Operator command - the network operator may issue commands that trigger protection switching.  The supported commands are Forced Switch, Manual Switch, Clear, Lockout of Protection, (see definitions in [RFC4427])" the local request logic only processes operator commands issued locally on this LER, while the operator commands on remote LER are received via PSC messages and handled in the PSC Control logic, therefore, the sentence could be improved to "Operator command - the network operator may issue local administrative commands on the LER that trigger protection switching.  The supported commands are Forced Switch, Manual Switch, Clear, Lockout of Protection, (see definitions in [RFC4427])"
- Section 31.1 (page 9) - 2nd bullet:  It should also be clarified, which is the signal generated at server layer (or at its adaptation layer) expected to be used as "server layer alarm indication". In ITU-T Equipment specification this would be defined in unambiguous terms by referring to the CI_SSF contribution from the server layer. But this contribution is unclear wrt current IETF OAM specification. Does it include for example AIS w/LDI indication? Description of an application scenario could also contribute in clarifying the function.
- Section 3.1.1 (page 9) - 4th bullet: in "OAM indication - OAM fault management or performance measurement tools may detect a failure or degrade condition on the MPLS-TP transport path and this SHOULD input an indication to the Local Request Logic." Suggest to rephrase "failure and degrade conditions on either working and protection transport paths"
- Section 3.1.1 (pages 9 & 10): the text should indicate which local request is global versus per transport path (working or protection): for example, SF condition is in reality SF-Working or SF-Protection
- Section 3.1.3 (page 11): In "b.  the remote request message from the remote end point of the transport path," add reference (see section 3.1.2) as done in the item #a.
- Section 3.1.6.1 (page 14): "If, however, the LER has local and remote indicators that would cause the PSC Control logic to enter different states, e.g. a Local SF on working and a Remote Lockout message, then the state with the higher importance will be the deciding factor and the source of that indicator will determine whether it is local or remote." It is not clear what is the "state of higher importance". There is a definition of priority between different inputs in section 4.3.2, which I suppose is what is referred to, but there is no definition of priority/importance of PSC control state in the document. Clarification needed.
- Section 4.1: transmission of PSC packets over the protection path also increases availability
- Section 4.2.2 (page 16): why choose code points different from those already used in ITU-T G.8031?
- Section 4.2.2 (page 16): Typo: Signal Defect -> Signal Degrade
- Section 4.3.2 (page 20): "7. Clear Signal Fail/Degrade (OAM/Control Plane/Server Indication)" is listed as part of the priority list. In ITU-T linear protection specification, clearance of SF/SD is not listed explicitly in the priority list and is taken into account different in the priority logic and state machine.
It is not a functional issue, but is it possible to add a note to clarify the need to keep this in the priority list?
-     Appendix 1 (page 31), end of first paragraph: typo "implementation" -> "implementation"
-     Appendix A (page 33): The abbreviation CSF for Clear Signal Fail" is misleading as CSF is an already used term for Client Signal Fail indication in OAM. The following syntax is preferable: SFc (SF Clear)


- Section 4.1 page 15 , first paragraph:
"When the PSC information changes due to a remote
message there is no need for the aforementioned rapid transmission of
three messages.  The exception ..."
why not make it simple and always require a rapid transmission of
three messages on any PSC change of messages.


- Section 4.3.3.2 page 22:
"A local Lockout of protection input SHALL cause the LER to remain
in local Unavailable State and transmit a LO(0,0) message to the
far-end LER (LER-Z)."
While it is clear that no change is state is desired here, is the local Lockout command rejected or accepted when a local Lockout already exist, that is not clear or specified here or on page 32.

- Section 4.3.3.3 page 24:
"A local Forced switch input SHALL cause the LER to remain in local
Protecting administrative state and transmit a FS(1,1) message"
While it is clear that no change is state is desired here, is the local Forced switched command rejected or accepted when a local FS already exist, that is not clear or specified here or on page 32.

- Section 4.3.3.3 page 24:
"A local Signal Fail indication on the protection path SHALL cause
the LER to go into local Unavailable state (i.e. overriding the MS
related Protection administrative state) and begin transmission of
a SF(0,0) message."

The FS should also be added to the MS in the example "(i.e. overriding the MS or FS...)

- Section 4.3.3.3 page 25:
"A local Manual switch input SHALL be ignored if in remote
Protecting administrative state is due to a remote Forced switch
command.  If the current state is due to a (local or remote)
Manual switch operator command, it SHALL cause the LER to remain
in local Protecting administrative state and transmit a MS(1,1)
message."
While it is clear that no change is state is desired here, is the MS switched command rejected or accepted when a local MS already exist, that is not clear or specified here or on page 32.