Elwyn,
Some missing background that really is just an amplification of
part of Huub's reply below:
There is no clear use-case, or any indication that there will be any
use-case for any subset of the capabilities (bits) currently used to represent
the two defined modes. However, we cannot know the future, so we did
not (and do not) want to exclude the possibility that there may eventually
be just such a use-case.
A reasonable analysis of the state-machine logic in this draft will
show that a lot of additional states and transitions, and a lot more complex
"mode negotiation" would be involved in supporting arbitrary sub-setting
of the capabilities that currently make up a mode.
Based on the lack of a real use-case for it, I think we have to view
any attempt to force us to explain exactly how such sub-setting would be
supported as an effort to guide the work toward a rat-hole we can all see.
If it does become clear at some point that other combinations of
the bits are needed, then someone will take up the task to write one or
more drafts as needed to explain how that will work (and interwork with
any then-existing combinations).
I really can't imagine why it is necessary to explicitly say this. The
ability to do "additional work" is always there, except where some specific
class of work seems a really bad idea (to folks with a crystal ball, to tell
them
when this is the case).
If it was necessary to say this explicitly, we have a lot of work cut
out for us in re-writing a ton of RFCs. :-)
--
Eric
-----Original Message-----
From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Elwyn Davies
Sent: Wednesday, February 26, 2014 1:24 PM
To: Huub Van Helvoort
Cc: General Area Review Team; draft-ietf-mpls-tp-psc-itu....@tools.ietf.org
Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
Hi, Huub.
Thanks for the responses: Agreed bits snipped again.
On Wed, 2014-02-26 at 16:39 +0000, Huub Van Helvoort wrote:
> Hello Elwyn,
>
> Please find my response in-line [Huub2]
>
> To avoid any confusion I have snipped the parts that do not need
> further expanation.
>
> > Minor issues:
> > s1, next to last para:
> >
> > > This document describes the behavior of the PSC protocol
> > including
> > > the priority logic and the state machine when all the
> > capabilities
> > > associated with the APS mode are enabled. The PSC protocol
> > behavior
> > > for the PSC mode is as defined in RFC 6378.
> >
> > APS mode involves five capabilities which can, apparently, be
> > implemented and advertised indpendently, so presumably there might be
> > reasons for either implementing or turning on just a subset.
> >
> > [Huub] There were originally separate drafts for each of the
> > capabilities.
> > However, it was very complex to define the effect on the state
> > transition tables for each capability or combination of capabilities.
> >
> > [Huub] to resolve this issue it was decided that for any permitation
> > of the possible combinations of capabilities a separate draft should
> > be
> > developed. RFC6378 is the one where none of the capabilities is
> > used, and this draft is the one where all capabiliies are used. So far
> > none of the other possible drafts is written.
> >
> > [Huub] This draft provides the behavior similar to APS used in ITU-T
> > for other technologies.
> >
> > Are there
> > any implications for the PSC protocol if only some subset of the the
> > capabilities are available in a given node? (This may be a dumb
> > question and I haven't tried to work out what might go wrong if you
> > did have any of the available subsets.)
> >
> > [Huub] both nodes MUST support the same subset, if they don't the
> > result will be unpredictable because the state machines are different.
> >
> > s9.1.1/s9.2: Following on from the previous point, s9.1.1 implies that
> > the system can operate happily with some subset of the five
> > capabilities
> > turned on provided that both ends concur. However there is no mode
> > name that would cover such a subset.
> >
> > [Huub] as indicated above, the mode name does not exist because the
> > draft that describes that mode does not (yet) exist.
> >
> > Does this actually mean that turning on
> > a subset doesn't really work?
> >
> > [Huub] indeed, not until there is a draft that describes it.
> >
> > And if it doesn't work why bother with
> > five flag bits?
> >
> > [Huub] to give others the opportunity to write the missing draft(s),
> > this was the agreed by the WG chairs.
> >
> > Also the phraseology used here could lead to future
> > problems if more capabilities are defined: suppose some future new
> > mode
> > (FOO) adds <n> more capabilities but the two 'modes' can be turned on
> > independently - as currently expressed you would have to define three
> > mode names for APS only, FOO only and APS + FOO.. and so on with more
> > capability sets. Unintended consequence? Oh, and what if a capability
> > is used in more than one mode?
> >
> > [Huub] it is up to the authors of additional drafts to come up with a
> > name for the mode described in their draft.
>
> To be absolutely honest, my initial reaction to the above (i.e., right
> back to the beginning of Minor Issues) went something like
> "******** ARRRGGGGHHH! Choke!! Splutter!!!".
>
> Be that as it may, if that is what is agreed then please could there be
> some explanation in the document. Please!
>
> [Huub2] the probability that there may be several "solutions" is IMHO
> very small.
> Personally I do not expect any other solution because RFC6378 is
> what IETF wants, and this draft is what ITU-T wants and will
> document in recommendation G.8131.
> Any other "solution" would be non-standard.
> Adding an explanation to this draft will give the impression that
> other solutions will be acceptable. Something neither IETF nor
> ITU-t would admit to.
Politics! OK - How about we add to either s9.1.1 or s9.2 something like:
Only combinations of capabilities specified by a mode are allowed.
Capability TLVs with other combinations will be treated as invalid
PSC messages.
>
> > s13: The addition of the Capabilities TLV and the requirement that it
> > is
> > carried accurately and repeatedly in every PSC message introduces a
> > new
> > aspect to the DoS/random corruption problem mentioned in s6 of RFC
> > 6378.
> > A single bit corruption in a PSC message will lead to disablement of
> > protection switching and requirement of operator intervention. I am
> > not
> > sure if this is a serious issue, but it probably merits a comment in
> > s13
> > and verification that it does match with the words in RFC 6378 as
> > regards 'converging on a stable state'.
> >
> > [Huub] a bit error will occur in one message, RFC6378 s4.1 addresses
> > that issue.
>
> I don't think this covers the problem:
> The last para of s6 of RFC 6378 says:
>
> > However, a new concern for this document is the accidental corruption
> > of messages (through faulty implementations or random corruption).
> > The main concern is around the Request, FPath, and Path fields as a
> > change to these fields would change the behavior of the peer end
> > point. Although this document does not define a way to avoid a
> > change in network behavior upon receipt of a message indicating a
> > change in protection status, the transition between states will
> > converge on a known and stable behavior in the face of messages that
> > do not match reality.
>
> This appears to imply that random bit errors can percolate up to the
> protocol engine. If the bit error affects the capability flag bits in the
> Capability TLV then the behaviour specified in s9.1.1 would come into play:
>
> > When a node receives a Capabilities TLV it MUST compare it to its
> > most recent transmitted Capabilities TLV. If the two are equal, the
> > protected domain is said to be running in the mode indicated by that
> > set of capabilities (see Section 9.2). If the sent and received
> > Capabilities TLVs are not equal, this indicates a capabilities
> > mismatch. When this happens, the node MUST alert the operator and
> > MUST NOT perform any protection switching until the operator resolves
> > the mismatch in the Capabilities TLV.
>
> The result of such a corrupted bit would a.s. be a mismatch that should
> be followed by a turn off of protection switching and operator alerting.
>
> [Huub2]
> A received PSC message with a bit error is a not valid PSC message.
>
> If a received PSC message is unexpected (due to a bit error, or a corrupt
> far end protocol engone) in a particular state it is considered a not valid
> message and is ignored
>
> The capability of a protected link is provisioned at initiation and cannot
> be changed during operation, so a PSC message with a capability bit
> changed (e.g. due to a bit error) is considered not valid PSC message
> and is ignored.
>
> I think this is covered by the last paragraph in s4.1 of RFC6378.
> ====
> If no valid PSC message is received, over a period of several
> continual messages intervals, the last valid received message remains
> applicable.
> ===
Sorry to harp on about this... I think we are trying to distinguish
between invalid messages and protocol errors. If a PSC message with the
wrong set of Capability bits set is (always?) considered not a valid PSC
message then you need to change the wording of the piece of s9.1.1
quoted above. The text in [Huub2} implies:
either:
that there is a distinction between the first PSC message and
subsequent ones, in which case the comparison is against the
internally configured value of the capability bits, since nothing
has been sent or received yet, and that means that the
specified action only happens on the first PSC message - it
isn't clear to me that the specified action makes sense in that case.
or:
that *any* PSC message with the wrong set of capability bits set
(again tested against the internally configured value) is
flagged up as invalid and discarded *without any action being
taken*. In this case the text in s9.1.1 is never actioned.
For my peace of mind.. Can you confirm whether my interprestation of RFC
6378 s6 is correct, i.e., bit errors in transmission are *not* detected
by the layers below the PSC protocol and corrupted PSC messages will be
passed to the PSC state machine.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
