Indeed. In particular Capability 3 - MS to working will be useful for anyone who wants to support non-revertive.
George On 3/4/14 12:54 PM, "Eric Gray" <eric.g...@ericsson.com> wrote: >Huub, > >Unfortunately, I agree with Adrian in terms of why we would not claim >that any other combination of bits is "invalid" generally, so I do not >agree >that the change suggested by Elwyn is a good idea. > >I also agree that the reasoning that the bit-combination match criteria >makes it clear how any implementation of this specification would handle >anything other than all-clear or all-set. The implementation will not >try to >perform OAM between two implementations that do not have a matching >bit-set that is either one or the other. > >I am not sure where we indicate that any other set of bits is an error, >so I >do not really understand that part of Adrian's reply. > >At this point, I do not see any clear need for changes to the draft based >on >this particular comment-set. > >-- >Eric > >-----Original Message----- >From: Huub Van Helvoort [mailto:huub.van.helvo...@huawei.com] >Sent: Wednesday, February 26, 2014 2:58 PM >To: Elwyn Davies >Cc: General Area Review Team; >draft-ietf-mpls-tp-psc-itu....@tools.ietf.org >Subject: RE: Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt > >Hello Elwyn, > >Thanks for your reply. >See my responses in-line [Huub3]. > >===== >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. > >[Huub3] that works for me. Eric, Jeong-dong can you address this? > >> > 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... > >[Huub3] no problem, clarity is key > >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. > >[Huub3] I agree, I will check with the other authors if they agree too. >If they disagree I will inform you. > >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. > >[Huub3] it is a bit different. When a new/changed PSC message >is sent, it is sent three times very fast. A majority decision is taken >to determine the correct value, so it is possible that the first is >discarded because it is not the same as the second and third. >The capability bits are always compared to the provisioned mode. > >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. > >[Huub3] according to s9.1.1 the capability TLV MUST be added >always to every PSC message sent. The capability bits are set to >the provisioned mode. There is one exception: the original PSC as >described in RFC6378, because that does not use capability TLV. > >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. > >[Huub3] If the (lower) server layer is Ethernet, the Ethernet frame can >use the FCS to detect bit errors and discard the Ethernet/MPLS frame. >If FCS is not used bit errors are undetected. >If the (lower) server layer is SDH/SONET/OTN the FEC (forward >error correction) will correct bit errors that occur in the physical >layer. >If FEC is not used bit errors are counted, if the error rate is excessive >AIS will be inserted, in a packet (higher) client layer this will result >in >discarding all frames. > >Cheers, Huub. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
