[Gen-art] Gen-art telechat review of draft-ietf-mpls-tp-psc-itu-03.txt

[Elwyn Davies <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-mpls-tp-psc-itu-03.txt
Reviewer: Elwyn Davies
Review Date: 22 March 2014
IETF LC End Date: 2014-02-24
IESG Telechat date: 27 March 2014

Summary:
Almost ready.  There are a couple of points which I raised at Last Call
and discussed with the authors and others both by email and f2f in
London that are not resolved.  These point revolve around being rigorous
about wire encoding, clarifying error behaviour and being definite that
implementations support modes as specfic combinations of capabilities so
that arbitrary capability combinations are not allowed and result in
invalid protocol messages.

Major Issues:

Minor Issues:
s1: From my discussions with the authors and others associated with this
document, it is my understanding that the intention is that only
combinations of capabilities specified by modes should be legal and
hence that implementations would support modes rather than arbitrary
sets of capbilities. I think it would be worth being more explicit about
this.  This would answer my comments at Last Call that it was unclear
whether other combinations were allowed and would make it clear that a
message that arrived with a corrupted bit in the flags field was
definitely malformed.  I suggest adding the following text to para 16 of
s1 (starts "This document introduces capabilities and modes.") before
the last sentence:
   Only combinations of capabilities specified by modes will be 
   supported by implementations.

Nits/Editorial Comments:

s4.4, para 1:
OLD:
When the modified priorities specified in this document is in use,..
NEW:
When the modified priorities specified in this document are in use,..
(or maybe better:)
When the modified priority order specified in this document is in use,..

s7.3 et seq: The term "selector bridge" is introduced without
definition.  I suspect it is a piece of jargon I am supposed to know but
I think a reference would help.

s9.1: RFC 6378 doesn't define the encoding of the TLV type and TLV
length fields, so it needs to be done here (Unsigned integers). It also
doesn't define encoding of the overall TLV length field in
the PSC header.  This may be thought to be 'obvious' but there is no
default specified in IETF documents.

s9.1: Both RFC6378 and this document are incomplete as regards
specifying what constitutes an invalid protocol message.  In particular
there is no discussion of behaviour if correctly formed but unrecognized
TLVs are received.  Do these make the message invalid or should they be
ignored?

s9.1.1 and s12:
In s12 it is stated (similar wording in s9.1.1):
>    o  If the Capabilities TLV mismatches, the node MUST alert the
>       operator and MUST NOT perform any protection switching until the
>       operator resolves the mismatch in the Capabilities TLV.
Having discussed the situation with the authors and others, I understand
that there are circumstances, depending on the underlying transport,
that bit errors might not be detected and hence that there is a small
probability that corrupt PSC messages may be propagated up to the
protocol machine.  At present there is no explicit statement that a
corrupted flag word would be trapped as an invalid protocol message
(this seems to be the intention) rather than triggering this operator
alert.  I think that the best that can be done is specify that a PSC
protocol message MUST have the flags for a recognized mode set exactly
and otherwise it will be treated as an invalid message.  The wording in
s9.1.1 and s12 would then catch an inadvertent reconfiguration.  I
suggest adding the following to s9.1.1:
   Any PSC message that has a combination of capability bits set that 
   does not correspond to a defined mode will be treated as an invalid 
   message and ignored.