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

[Ryoo, Jeong-dong]

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" 
Sent : 2014-03-06 02:48:38 ( +09:00 )
To : Ryoo, Jeong-dong , 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

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 

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

[Eric Gray]

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 followin

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

[George Swallow (swallow)]

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"  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  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 th

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

[Ryoo, Jeong-dong]

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

[Ryoo, Jeong-dong]

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" 
Sent : 2014-03-05 03:15:24 ( +09:00 )
To : Ryoo, Jeong-dong , 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

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" 
mailto:huub.van.helvo...@huawei.com>>
Sent : 2014-02-27 04:58:09 ( +09:00 )
To : Elwyn Davies mailto:elw...@dial.pipex.com>>
Cc : General Area Review Team mailto:gen-art@ietf.org>>, 
draft-ietf-mpls-tp-psc-itu@tools.ietf.org
 
mailto: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 

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

[Eric Gray]

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" 
mailto:huub.van.helvo...@huawei.com>>
Sent : 2014-02-27 04:58:09 ( +09:00 )
To : Elwyn Davies mailto:elw...@dial.pipex.com>>
Cc : General Area Review Team mailto:gen-art@ietf.org>>, 
draft-ietf-mpls-tp-psc-itu@tools.ietf.org
 
mailto: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

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

[Eric Gray]

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),
> >

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

[Eric Gray]

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

[Eric Gray]

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  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

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

[Ryoo, Jeong-dong]

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" 
Sent : 2014-02-27 04:58:09 ( +09:00 )
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 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

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

[Huub van Helvoort]

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

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

[Huub Van Helvoort]

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 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, RFC

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

[Adrian Farrel]

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

[Elwyn Davies]

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  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 cove

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

[Huub Van Helvoort]

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.

> 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

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

[Elwyn Davies]

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
> 
> .
> 
> 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  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

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

[Huub Van Helvoort]

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

.

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  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 

[Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt

[Elwyn Davies]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

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.

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.  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.) 

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.  Does this actually mean that turning on
a subset doesn't really work? And if it doesn't work why bother with
five flag bits?  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?

s8: EXER appears to test the PSC channel but nothing else.  I am not
clear that this fully satisfies R84 in RFC 5654.. 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)?

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'.

Nits/editorial comments:
s4.4, title: s/Capability 1/Priority Modifications/ (Ok, its accurate
but bald)

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.

s7.4, para 1: 

> the rules to resolve the equal priority requests are
>required.
Should this be s/the rules/some rules/?

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.  I guess what is probably appropriate is to say that
it is built in the same way as an NR message would be built. 

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.

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.

s10.3, para 2: s/they SHALL be disappeared./they SHALL be discarded./




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art