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

[Elwyn Davies <[e-mail]>]

Hi,Jeong-dong.

The new version looks fine to me except that it didn't get the ref to
RFC 4427 next to the usage of selector bridge.

Glad this got approved!

Thanks,
Elwyn


On Mon, 2014-03-24 at 16:32 +0000, Ryoo, Jeong-dong wrote:
> Adrian, thanks for the reply to Elwyn's email.
>  
> "Selector bridge" is defined in RFC4427, and this draft has RFC4427 in
> the reference section.
>  
> As far as editing job is concerned, 
> I noted the following item for correction:
> > s4.4, para 1:
> > OLD:
> > When the modified priorities specified in this document is in use,..
> > NEW:
> > When the modified priority order specified in this document is in
> use,..
> 
> If there is anything that I missed, please let me know.
>  
> Thanks.
>  
> Jeong-dong
> 
>  
> 
> 
> 
> ______________________________________________________________________
> From : "Adrian Farrel" <[e-mail]>
> Sent : 2014-03-23 06:14:42 ( +09:00 )
> To : [e-mail] <[e-mail]>
> Cc : [e-mail]
> <[e-mail]>, 'General Area Review
> Team' <[e-mail]>
> Subject : RE: Gen-art telechat review of
> draft-ietf-mpls-tp-psc-itu-03.txt
> 
> Hi Elwyn,
> 
> Thanks for your pursuit of excellence.
> 
> I understand from the document editor that there is a revision in
> waiting to be
> posted that clears up some remaining nits from your review.
> 
> However, in line...
> 
> > 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.
> 
> While this is true, it is also not helpful!
> Any combination of capabilities (these five and any of the future
> nearly-infinite number of capabilities that can be represented in the
> bit field)
> could be specified as supported (i.e. as a mode) in the future.
> There are two points of note:
> 1. Only two modes are currently defined
> 2. Any future mode must be specified in combination with the state
> machines for
> the mode.
> 
> A message that is received containing a set of capabilities (i.e. a
> mode) not
> supported by the receiver would be rejected. See Section 9.1.1. That
> is, this is
> not a negotiation. This is a verification that both speakers are
> operating in
> the same mode.
> 
> For future compatibility, there is no distinction between a corrupted
> set of
> capability bits and an unknown mode.
> 
> > 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.
> 
> Yes, it is a piece of standard terminology in protection switching.
> I'm sure the
> authors can find a reference.
> 
> > 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.
> 
> This is being fixed in draft-ietf-mpls-psc-updates that updates 4368.
> New
> revision about to be posted before IETF last call.
> 
> > 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?
> 
> This should be included in draft-ietf-mpls-psc-updates as well.
> 
> > 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.
> 
> This is plain wrong!
> The receiving device is set to operate in a single mode.
> If the received message is not identical to that mode, it cannot
> operate. 
> Section 9.1.1 already explains how this is handled.
> To restate: this is not a negotiation.
> It is an announcement.
> 
> The possibility of a corrupt message does exist. Neutrinos are
> remarkably
> unpredictable beasts. And it is remotely possible that the error will
> arise
> without the underlying transport detecting it. And it is further
> possible that
> the error will take out a single bit in the capabilities. The result
> is
> indistinguishable from the sender deciding to tweak its capabilities.
> That would
> cause a mode mismatch and the process in 9.1.1 would be invoked. Given
> that it
> is indistinguishable, why would this be a cause for any different
> behaviour?
> 
> BTW, Stewart was asking some time back whether there was any record
> anywhere of
> an MPLS packet that had been misdelivered because the label had had a
> corruption
> event on the wire. We didn't come up with anything and the general
> feeling was
> that hardware memory was far more vulnerable.
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art