Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
Thanks, Eric. I have no problem with that, and I will make a change in the working copy unless I see a different opinion. Best regards, Jeong-dong From : Eric Gray eric.g...@ericsson.com Sent : 2014-03-05 03:15:24 ( +09:00 ) To : Ryoo, Jeong-dong r...@etri.re.kr, Huub Van Helvoort huub.van.helvo...@huawei.com, Elwyn Davies elw...@dial.pipex.com Cc : General Area Review Team gen-art@ietf.org, draft-ietf-mpls-tp-psc-itu@tools.ietf.org draft-ietf-mpls-tp-psc-itu@tools.ietf.org Subject : RE: Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt Jeong-dong, If you change not allowed to not supported in this specification – I think we have it. -- Eric From: Ryoo, Jeong-dong [mailto:r...@etri.re.kr] Sent: Tuesday, March 04, 2014 12:38 PM To: Huub Van Helvoort; 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 Hi, Regarding the mode and capability discussion, please see if the following change can resolve the issue: Section 9.2 OLD: A mode is a given set of Capabilities. Modes are shorthand; referring to a set of capabilities by their individual values or by the name of their mode does not change the protocol behavior. This document defines two modes - PSC and APS. New: A mode is a given set of Capabilities. Modes are shorthand; referring to a set of capabilities by their individual values or by the name of their mode does not change the protocol behavior. This document defines two modes - PSC and APS. Capability TLVs with other combinations than the one specified by a mode are not allowed. Best regards, Jeong-dong From : Huub Van Helvoort huub.van.helvo...@huawei.commailto:huub.van.helvo...@huawei.com Sent : 2014-02-27 04:58:09 ( +09:00 ) To : Elwyn Davies elw...@dial.pipex.commailto:elw...@dial.pipex.com Cc : General Area Review Team gen-art@ietf.orgmailto:gen-art@ietf.org, draft-ietf-mpls-tp-psc-itu@tools.ietf.orgmailto:draft-ietf-mpls-tp-psc-itu@tools.ietf.org draft-ietf-mpls-tp-psc-itu@tools.ietf.orgmailto: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 +, 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
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
Hi, In order to find correct text to reflect the comments that are agreed so far, I am suggesting the text below. Please, see inlines starting with [JR] I erased the parts that do not need further discussion. s8, definition of Exercise (EXER): Describing EXER as 'replacing' one of NR, RR or DNR seems a bit odd. Mentioning RR is particularly problematic since it makes the definitions sort of circular as RR is the response to EXER. Any thoughts here?... [Huub2] see below. I guess what is probably appropriate is to say that it is built in the same way as an NR message would be built. [Huub] the replacing means that in case an operator wants to verify the operation of PSC, the excersise commend is issued and the transmission of RR (or NR, or DNR) is stopped and EXER is sent instead. I think I see what is going on noew Perhaps adding something like the phrase that would normally be sent periodically in the IDLE state [Huub2] if it helps readability we will do as suggested. [JR] Since the draft does not have IDLE state and the phrase with quotation marks above does not quite fit into current text, I suggest the following modifications: OLD: (3) Exercise - indicates that the transmitting end point is exercising the protection channel and mechanism. FPath and Path are set to the same value of the No Request (NR), RR or DNR request that EXER replaces NEW: (3) Exercise - indicates that the transmitting end point is exercising the protection channel and mechanism. FPath and Path are set to the same value of the No Request (NR), RR or DNR message whose transmission is stopped by EXER. Similarly, OLD: (2) Reverse Request - indicates that the transmitting end point is responding to an EXER command from the remote node. FPath and request that RR replaces. NEW: (2) Reverse Request - indicates that the transmitting end point is responding to an EXER command from the remote node. FPath and Path are set to the same value of the NR or DNR message whose transmission is stopped by RR. 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 (unnecessary) overall TLV length field in the PSC header. [Huub] IANA asigned the TLV type value. By not giving exact values we leave the possibility open that there are more than 32 flags. That's not the issue. The problem is that the protocol does not specify how the type and length numbers should be represented on the wire. The standard answer is unsigned integer in network bit order. [Huub2] OK, I now understand your point. This can be addressed. [JR] OLD: A Capability is an individual behavior whose use is signaled in a Capabilities TLV, which is placed in Optional TLVs field inside the PSC message shown in Figure 2 of [RFC6378]. The format of the Capabilities TLV is: NEW: A Capability is an individual behavior whose use is signaled in a Capabilities TLV, which is placed in Optional TLVs field inside the PSC message shown in Figure 2 of [RFC6378]. TLV Length field in Figure 2 of [RFC6378] indicates the number of bytes included in Optional TLVs field. For capability sets supported in this document, this value MUST be set to 8. The format of the Capabilities TLV is: s9.1: What happens if the receiver gets a TLV with some a flags length that isn't a multiple of 4 (or indeed a TLV it deosn't recognize?) It might be cleaner to define the length in terms of units of 32 bits. [Huub] this can be treated the same as a bit error in a PSC message. This should be stated. [Huub2] OK, we will address this. [JR] I am not sure if we need to state what should be done in case that this length value is not correct. Then, we would need the same statements for almost all other fields, such as Ver field is not 1, PT value is not the one defined, Request value is not the one defined, so and so fouth. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
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 +, 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 ARRRHHH! 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
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
See below… From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Ryoo, Jeong-dong Sent: Wednesday, March 05, 2014 7:00 AM To: Huub Van Helvoort; Elwyn Davies 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, In order to find correct text to reflect the comments that are agreed so far, I am suggesting the text below. Please, see inlines starting with [JR] I erased the parts that do not need further discussion. s8, definition of Exercise (EXER): Describing EXER as 'replacing' one of NR, RR or DNR seems a bit odd. Mentioning RR is particularly problematic since it makes the definitions sort of circular as RR is the response to EXER. Any thoughts here?... [Huub2] see below. I guess what is probably appropriate is to say that it is built in the same way as an NR message would be built. [Huub] the replacing means that in case an operator wants to verify the operation of PSC, the excersise commend is issued and the transmission of RR (or NR, or DNR) is stopped and EXER is sent instead. I think I see what is going on noew Perhaps adding something like the phrase that would normally be sent periodically in the IDLE state I think you would not want to send EXER periodically in the IDLE state. Also, wouldn't you have to stop sending RR at both ends before using EXER in order to avoid getting a false indication of success? In a way, what you would be doing is sending EXER on demand, instead of RR periodically, correct? [Huub2] if it helps readability we will do as suggested. [JR] Since the draft does not have IDLE state and the phrase with quotation marks above does not quite fit into current text, I suggest the following modifications: OLD: (3) Exercise - indicates that the transmitting end point is exercising the protection channel and mechanism. FPath and Path are set to the same value of the No Request (NR), RR or DNR request that EXER replaces NEW: (3) Exercise - indicates that the transmitting end point is exercising the protection channel and mechanism. FPath and Path are set to the same value of the No Request (NR), RR or DNR message whose transmission is stopped by EXER. Similarly, OLD: (2) Reverse Request - indicates that the transmitting end point is responding to an EXER command from the remote node. FPath and request that RR replaces. NEW: (2) Reverse Request - indicates that the transmitting end point is responding to an EXER command from the remote node. FPath and Path are set to the same value of the NR or DNR message whose transmission is stopped by RR. I like it. 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 (unnecessary) overall TLV length field in the PSC header. [Huub] IANA asigned the TLV type value. By not giving exact values we leave the possibility open that there are more than 32 flags. That's not the issue. The problem is that the protocol does not specify how the type and length numbers should be represented on the wire. The standard answer is unsigned integer in network bit order. [Huub2] OK, I now understand your point. This can be addressed. [JR] OLD: A Capability is an individual behavior whose use is signaled in a Capabilities TLV, which is placed in Optional TLVs field inside the PSC message shown in Figure 2 of [RFC6378]. The format of the Capabilities TLV is: NEW: A Capability is an individual behavior whose use is signaled in a Capabilities TLV, which is placed in Optional TLVs field inside the PSC message shown in Figure 2 of [RFC6378]. TLV Length field in Figure 2 of [RFC6378] indicates the number of bytes included in Optional TLVs field. For capability sets supported in this document, this value MUST be set to 8. The format of the Capabilities TLV is: It's a bit hard to figure out who said what in the text above. I assume that the bit between [Huub] IANA assigned … - and [Huub2] OK … is a response to [Huub] … that we responded to in [Huub2] … If that is correct, then the text changes above don't address the intent of the comment. The way I read the exchange, we're not being asked to explain what the Length field means and what value we expect in this specification, just how it would be sent on the wire. I don't think many RFCs actually include this (though I believe that the suggestion of unsigned integer in network bit order is correct). The ordering is usually assumed to be in the standard order whenever the typical ASCII text format specification used in RFCs is used. Because of this, I wonder if we might not be better off following the usual practice and leaving this to the imagination of the reader. There are many reasons for doing this. One is that few people know what network bit order really means in terms of how the bits are ordered
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
Eric, thank you for confirming the first and third points. Regarding the second point on the bits on the wire, your assumption on the email exchange is correct. And, now I can understand the issue correctly. Jeong-dong From : Eric Gray eric.g...@ericsson.com Sent : 2014-03-06 02:48:38 ( +09:00 ) To : Ryoo, Jeong-dong r...@etri.re.kr, Huub Van Helvoort huub.van.helvo...@huawei.com, Elwyn Davies elw...@dial.pipex.com Cc : General Area Review Team gen-art@ietf.org, draft-ietf-mpls-tp-psc-itu@tools.ietf.org draft-ietf-mpls-tp-psc-itu@tools.ietf.org Subject : RE: Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt See below… From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Ryoo, Jeong-dong Sent: Wednesday, March 05, 2014 7:00 AM To: Huub Van Helvoort; Elwyn Davies 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, In order to find correct text to reflect the comments that are agreed so far, I am suggesting the text below. Please, see inlines starting with [JR] I erased the parts that do not need further discussion. s8, definition of Exercise (EXER): Describing EXER as 'replacing' one of NR, RR or DNR seems a bit odd. Mentioning RR is particularly problematic since it makes the definitions sort of circular as RR is the response to EXER. Any thoughts here?... [Huub2] see below. I guess what is probably appropriate is to say that it is built in the same way as an NR message would be built. [Huub] the replacing means that in case an operator wants to verify the operation of PSC, the excersise commend is issued and the transmission of RR (or NR, or DNR) is stopped and EXER is sent instead. I think I see what is going on noew Perhaps adding something like the phrase that would normally be sent periodically in the IDLE state I think you would not want to send EXER periodically in the IDLE state. Also, wouldn't you have to stop sending RR at both ends before using EXER in order to avoid getting a false indication of success? In a way, what you would be doing is sending EXER on demand, instead of RR periodically, correct? [Huub2] if it helps readability we will do as suggested. [JR] Since the draft does not have IDLE state and the phrase with quotation marks above does not quite fit into current text, I suggest the following modifications: OLD: (3) Exercise - indicates that the transmitting end point is exercising the protection channel and mechanism. FPath and Path are set to the same value of the No Request (NR), RR or DNR request that EXER replaces NEW: (3) Exercise - indicates that the transmitting end point is exercising the protection channel and mechanism. FPath and Path are set to the same value of the No Request (NR), RR or DNR message whose transmission is stopped by EXER. Similarly, OLD: (2) Reverse Request - indicates that the transmitting end point is responding to an EXER command from the remote node. FPath and request that RR replaces. NEW: (2) Reverse Request - indicates that the transmitting end point is responding to an EXER command from the remote node. FPath and Path are set to the same value of the NR or DNR message whose transmission is stopped by RR. I like it. 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 (unnecessary) overall TLV length field in the PSC header. [Huub] IANA asigned the TLV type value. By not giving exact values we leave the possibility open that there are more than 32 flags. That's not the issue. The problem is that the protocol does not specify how the type and length numbers should be represented on the wire. The standard answer is unsigned integer in network bit order. [Huub2] OK, I now understand your point. This can be addressed. [JR] OLD: A Capability is an individual behavior whose use is signaled in a Capabilities TLV, which is placed in Optional TLVs field inside the PSC message shown in Figure 2 of [RFC6378]. The format of the Capabilities TLV is: NEW: A Capability is an individual behavior whose use is signaled in a Capabilities TLV, which is placed in Optional TLVs field inside the PSC message shown in Figure 2 of [RFC6378]. TLV Length field in Figure 2 of [RFC6378] indicates the number of bytes included in Optional TLVs field. For capability sets supported in this document, this value MUST be set to 8. The format of the Capabilities TLV is: It's a bit hard to figure out who said what in the text above. I assume that the bit between [Huub] IANA assigned … - and [Huub2] OK … is a response to [Huub] … that we responded to in [Huub2] … If that is correct, then the text changes above don't address the intent of the comment. The way I read the exchange, we're not being asked to explain
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
Hi, Regarding the mode and capability discussion, please see if the following change can resolve the issue: Section 9.2 OLD: A mode is a given set of Capabilities. Modes are shorthand; referring to a set of capabilities by their individual values or by the name of their mode does not change the protocol behavior. This document defines two modes - PSC and APS. New: A mode is a given set of Capabilities. Modes are shorthand; referring to a set of capabilities by their individual values or by the name of their mode does not change the protocol behavior. This document defines two modes - PSC and APS. Capability TLVs with other combinations than the one specified by a mode are not allowed. Best regards, Jeong-dong From : Huub Van Helvoort huub.van.helvo...@huawei.com Sent : 2014-02-27 04:58:09 ( +09:00 ) To : Elwyn Davies elw...@dial.pipex.com Cc : General Area Review Team gen-art@ietf.org, draft-ietf-mpls-tp-psc-itu@tools.ietf.org 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 +, 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 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 ARRRHHH! 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
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
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 +, 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 ARRRHHH! 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
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
It looks like we have convergence - in theory. The question is what text, if any, needs to change? -Original Message- From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Huub van Helvoort Sent: Wednesday, February 26, 2014 3:22 PM To: adr...@olddog.co.uk; elw...@folly.org.uk Cc: gen-art@ietf.org; 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 Shwmae Adrian, You wrote: [snip] Politics! OK - How about we add to either s9.1.1 or s9.2 something like: I don't think it is politics at all, and I don't really like that Huub referenced this as IETF and ITU-T since both documents are IETF standards track work. Please excuse me for giving the impression that this draft is an ITU-T document. You are absolutely right that both are IETF documents. I should have used PSC in ITU-T mode to refer to this draft. There are some people who want to deploy one set of options (the empty set) and they have an RFC. There is another set of people who want to deploy a different set of options (all 5 of them) and they will have this RFC. Indeed. Only combinations of capabilities specified by a mode are allowed. Capability TLVs with other combinations will be treated as invalid PSC messages. But this is not true. What we have is: A node knows which options it supports, and those options are expressed as bundles (modes). A node that tries to communicate with you must offer a set of options (a mode). Either you support the mode or you don't. If you support it, off you go. If you don't support it, you reject the message saying unsupported as described in this document. Again: correct. I tried to simplify too much and used the wrong word (invalid, instead of unsupported). The message that offers a different set of options (i.e. a different mode) is not invalid, it is just that you don't understand it. You can't accept it because you don't know how to behave in that mode. Indeed (not supported). OTOH, when someone writes the new RFC describing that mode, you might enhance your implementation to support it as well. Yes, and initially advertise your own capabilities, compare to the capabilities received from the far-end and attempt to converge. (Hint: it really helps to think in modes. A mode is expressed as a bit-flag with plenty-bits of which five currently have meaning.) I agree with you that there is some distinction to be made between invalid message and protocol error. But no valid message does not mean protocol error or invalid message was received. It is a composite of possibilities that reflects the negation of receiving a message that was small and perfectly formed. OK. Cheers, Huub. -- * 请记住，你是独一无二的，就像其他每一个人一样 ___ 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
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
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 +, 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
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
Jeong-dong, If you change not allowed to not supported in this specification – I think we have it. -- Eric From: Ryoo, Jeong-dong [mailto:r...@etri.re.kr] Sent: Tuesday, March 04, 2014 12:38 PM To: Huub Van Helvoort; 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 Hi, Regarding the mode and capability discussion, please see if the following change can resolve the issue: Section 9.2 OLD: A mode is a given set of Capabilities. Modes are shorthand; referring to a set of capabilities by their individual values or by the name of their mode does not change the protocol behavior. This document defines two modes - PSC and APS. New: A mode is a given set of Capabilities. Modes are shorthand; referring to a set of capabilities by their individual values or by the name of their mode does not change the protocol behavior. This document defines two modes - PSC and APS. Capability TLVs with other combinations than the one specified by a mode are not allowed. Best regards, Jeong-dong From : Huub Van Helvoort huub.van.helvo...@huawei.commailto:huub.van.helvo...@huawei.com Sent : 2014-02-27 04:58:09 ( +09:00 ) To : Elwyn Davies elw...@dial.pipex.commailto:elw...@dial.pipex.com Cc : General Area Review Team gen-art@ietf.orgmailto:gen-art@ietf.org, draft-ietf-mpls-tp-psc-itu@tools.ietf.orgmailto:draft-ietf-mpls-tp-psc-itu@tools.ietf.org draft-ietf-mpls-tp-psc-itu@tools.ietf.orgmailto: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 +, 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 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 ARRRHHH! Choke!! Splutter
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
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 ARRRHHH! 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. 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
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 +, 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 ARRRHHH! 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).
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
Sut mae, Elwyn-gwas, [snip] Politics! OK - How about we add to either s9.1.1 or s9.2 something like: I don't think it is politics at all, and I don't really like that Huub referenced this as IETF and ITU-T since both documents are IETF standards track work. There are some people who want to deploy one set of options (the empty set) and they have an RFC. There is another set of people who want to deploy a different set of options (all 5 of them) and they will have this RFC. Only combinations of capabilities specified by a mode are allowed. Capability TLVs with other combinations will be treated as invalid PSC messages. But this is not true. What we have is: A node knows which options it supports, and those options are expressed as bundles (modes). A node that tries to communicate with you must offer a set of options (a mode). Either you support the mode or you don't. If you support it, off you go. If you don't support it, you reject the message saying unsupported as described in this document. The message that offers a different set of options (i.e. a different mode) is not invalid, it is just that you don't understand it. You can't accept it because you don't know how to behave in that mode. OTOH, when someone writes the new RFC describing that mode, you might enhance your implementation to support it as well. (Hint: it really helps to think in modes. A mode is expressed as a bit-flag with plenty-bits of which five currently have meaning.) I agree with you that there is some distinction to be made between invalid message and protocol error. But no valid message does not mean protocol error or invalid message was received. It is a composite of possibilities that reflects the negation of receiving a message that was small and perfectly formed. Ciao, Adrian ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
On Mon, 2014-02-24 at 21:50 +, Huub Van Helvoort wrote: Hello Elwyn, Thank you for your review. See my response in-line [Huub] 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 resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mpls-tp-psc-itu-02.txt Reviewer: Elwyn Davies Review Date: 24 Feb 2014 IETF LC End Date: 24 Feb 2014 IESG Telechat date: (if known) - Summary: Almost Ready for IESG. There is a statement in s1 that could indicate that the consequences of turning on a subset of the new capabilities has not been fully thought through. I am also not clear whether EXER fulfils the intentions of R84 in RFC 5654 as stated. The repeated transmission of the advertised capabilities adds to the scope for random bit errors to halt protection operation. A few minor nits noted below. [Huub] I have addressed these below. Major issues: None 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 deceided 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 ARRRHHH! Choke!! Splutter!!!. Be that as it may, if that is what is agreed then please could there be some explanation in the document. Please! s8: EXER appears to test the PSC channel but nothing else. I am not clear that this fully satisfies R84 in RFC 5654. [Huub] EXER verifies that the PSC engine at the far end is still running properly and not stuck at sending the same PSC message continuously. The PSC channel is tested by sending PSC messages regularly. (see RFC6378 s4.1) It may be that I don't know what information would go back in the RR response, but should the response say anything about the state in the remote node (like the remote end of the working path is not working in some way and/or what is the PSC state - RFC 6378 s3.6)? [Huub] the fact that RR is received after sending EXER is proof that the PSC engine
Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
Hello Elwyn, Thank you for your review. See my response in-line [Huub] 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 resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mpls-tp-psc-itu-02.txt Reviewer: Elwyn Davies Review Date: 24 Feb 2014 IETF LC End Date: 24 Feb 2014 IESG Telechat date: (if known) - Summary: Almost Ready for IESG. There is a statement in s1 that could indicate that the consequences of turning on a subset of the new capabilities has not been fully thought through. I am also not clear whether EXER fulfils the intentions of R84 in RFC 5654 as stated. The repeated transmission of the advertised capabilities adds to the scope for random bit errors to halt protection operation. A few minor nits noted below. [Huub] I have addressed these below. Major issues: None 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 deceided 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. s8: EXER appears to test the PSC channel but nothing else. I am not clear that this fully satisfies R84 in RFC 5654. [Huub] EXER verifies that the PSC engine at the far end is still running properly and not stuck at sending the same PSC message continuously. The PSC channel is tested by sending PSC messages regularly. (see RFC6378 s4.1) It may be that I don't know what information would go back in the RR response, but should the response say anything about the state in the remote node (like the remote end of the working path is not working in some way and/or what is the PSC state - RFC 6378 s3.6)? [Huub] the fact that RR is received after sending EXER is proof that the PSC engine is healthy. If it was not healty it would not have sent the RR. Because EXER has the lowest priority is can only be used in the IDLE state, so the far end could only send one state. 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
