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

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Tue, 4 Mar 2014 17:37:56 +0000

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" <[email-masked]>
Sent : 2014-02-27 04:58:09 ( +09:00 )
To : Elwyn Davies <[email-masked]>
Cc : General Area Review Team <[email-masked]>, [email-masked] <[email-masked]>
Subject : RE: Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt

Hello Elwyn,

Thanks for your reply.
See my responses in-line [Huub3].

=====
On Wed, 2014-02-26 at 16:39 +0000, Huub Van Helvoort wrote:
> Hello Elwyn,
>
> Please find my response in-line [Huub2]
>
> To avoid any confusion I have snipped the parts that do not need
> further expanation.
>
> > Minor issues:
> > s1, next to last para:
> >
> > > This document describes the behavior of the PSC protocol
> > including
> > > the priority logic and the state machine when all the
> > capabilities
> > > associated with the APS mode are enabled. The PSC protocol
> > behavior
> > > for the PSC mode is as defined in RFC 6378.
> >
> > APS mode involves five capabilities which can, apparently, be
> > implemented and advertised indpendently, so presumably there might be
> > reasons for either implementing or turning on just a subset.
> >
> > [Huub] There were originally separate drafts for each of the
> > capabilities.
> > However, it was very complex to define the effect on the state
> > transition tables for each capability or combination of capabilities.
> >
> > [Huub] to resolve this issue it was decided that for any permitation
> > of the possible combinations of capabilities a separate draft should
> > be
> > developed. RFC6378 is the one where none of the capabilities is
> > used, and this draft is the one where all capabiliies are used. So far
> > none of the other possible drafts is written.
> >
> > [Huub] This draft provides the behavior similar to APS used in ITU-T
> > for other technologies.
> >
> > Are there
> > any implications for the PSC protocol if only some subset of the the
> > capabilities are available in a given node? (This may be a dumb
> > question and I haven't tried to work out what might go wrong if you
> > did have any of the available subsets.)
> >
> > [Huub] both nodes MUST support the same subset, if they don't the
> > result will be unpredictable because the state machines are different.
> >
> > s9.1.1/s9.2: Following on from the previous point, s9.1.1 implies that
> > the system can operate happily with some subset of the five
> > capabilities
> > turned on provided that both ends concur. However there is no mode
> > name that would cover such a subset.
> >
> > [Huub] as indicated above, the mode name does not exist because the
> > draft that describes that mode does not (yet) exist.
> >
> > Does this actually mean that turning on
> > a subset doesn't really work?
> >
> > [Huub] indeed, not until there is a draft that describes it.
> >
> > And if it doesn't work why bother with
> > five flag bits?
> >
> > [Huub] to give others the opportunity to write the missing draft(s),
> > this was the agreed by the WG chairs.
> >
> > Also the phraseology used here could lead to future
> > problems if more capabilities are defined: suppose some future new
> > mode
> > (FOO) adds more capabilities but the two 'modes' can be turned on
> > independently - as currently expressed you would have to define three
> > mode names for APS only, FOO only and APS + FOO.. and so on with more
> > capability sets. Unintended consequence? Oh, and what if a capability
> > is used in more than one mode?
> >
> > [Huub] it is up to the authors of additional drafts to come up with a
> > name for the mode described in their draft.
>
> To be absolutely honest, my initial reaction to the above (i.e., right
> back to the beginning of Minor Issues) went something like
> "******** ARRRGGGGHHH! Choke!! Splutter!!!".
>
> Be that as it may, if that is what is agreed then please could there be
> some explanation in the document. Please!
>
> [Huub2] the probability that there may be several "solutions" is IMHO
> very small.
> Personally I do not expect any other solution because RFC6378 is
> what IETF wants, and this draft is what ITU-T wants and will
> document in recommendation G.8131.
> Any other "solution" would be non-standard.
> Adding an explanation to this draft will give the impression that
> other solutions will be acceptable. Something neither IETF nor
> ITU-t would admit to.

Politics! OK - How about we add to either s9.1.1 or s9.2 something like:

Only combinations of capabilities specified by a mode are allowed.
Capability TLVs with other combinations will be treated as invalid
PSC messages.

[Huub3] that works for me. Eric, Jeong-dong can you address this?

> > s13: The addition of the Capabilities TLV and the requirement that it
> > is
> > carried accurately and repeatedly in every PSC message introduces a
> > new
> > aspect to the DoS/random corruption problem mentioned in s6 of RFC
> > 6378.
> > A single bit corruption in a PSC message will lead to disablement of
> > protection switching and requirement of operator intervention. I am
> > not
> > sure if this is a serious issue, but it probably merits a comment in
> > s13
> > and verification that it does match with the words in RFC 6378 as
> > regards 'converging on a stable state'.
> >
> > [Huub] a bit error will occur in one message, RFC6378 s4.1 addresses
> > that issue.
>
> I don't think this covers the problem:
> The last para of s6 of RFC 6378 says:
>
> > However, a new concern for this document is the accidental corruption
> > of messages (through faulty implementations or random corruption).
> > The main concern is around the Request, FPath, and Path fields as a
> > change to these fields would change the behavior of the peer end
> > point. Although this document does not define a way to avoid a
> > change in network behavior upon receipt of a message indicating a
> > change in protection status, the transition between states will
> > converge on a known and stable behavior in the face of messages that
> > do not match reality.
>
> This appears to imply that random bit errors can percolate up to the
> protocol engine. If the bit error affects the capability flag bits in the
> Capability TLV then the behaviour specified in s9.1.1 would come into play:
>
> > When a node receives a Capabilities TLV it MUST compare it to its
> > most recent transmitted Capabilities TLV. If the two are equal, the
> > protected domain is said to be running in the mode indicated by that
> > set of capabilities (see Section 9.2). If the sent and received
> > Capabilities TLVs are not equal, this indicates a capabilities
> > mismatch. When this happens, the node MUST alert the operator and
> > MUST NOT perform any protection switching until the operator resolves
> > the mismatch in the Capabilities TLV.
>
> The result of such a corrupted bit would a.s. be a mismatch that should
> be followed by a turn off of protection switching and operator alerting.
>
> [Huub2]
> A received PSC message with a bit error is a not valid PSC message.
>
> If a received PSC message is unexpected (due to a bit error, or a corrupt
> far end protocol engone) in a particular state it is considered a not valid
> message and is ignored
>
> The capability of a protected link is provisioned at initiation and cannot
> be changed during operation, so a PSC message with a capability bit
> changed (e.g. due to a bit error) is considered not valid PSC message
> and is ignored.
>
> I think this is covered by the last paragraph in s4.1 of RFC6378.
> ====
> If no valid PSC message is received, over a period of several
> continual messages intervals, the last valid received message remains
> applicable.
> ===

Sorry to harp on about this...

[Huub3] no problem, clarity is key

I think we are trying to distinguish
between invalid messages and protocol errors. If a PSC message with the
wrong set of Capability bits set is (always?) considered not a valid PSC
message then you need to change the wording of the piece of s9.1.1
quoted above.

[Huub3] I agree, I will check with the other authors if they agree too.
If they disagree I will inform you.

The text in [Huub2} implies:
either:
that there is a distinction between the first PSC message and
subsequent ones, in which case the comparison is against the
internally configured value of the capability bits, since nothing
has been sent or received yet, and that means that the
specified action only happens on the first PSC message - it
isn't clear to me that the specified action makes sense in that case.

[Huub3] it is a bit different. When a new/changed PSC message
is sent, it is sent three times very fast. A majority decision is taken
to determine the correct value, so it is possible that the first is
discarded because it is not the same as the second and third.
The capability bits are always compared to the provisioned mode.

or:
that *any* PSC message with the wrong set of capability bits set
(again tested against the internally configured value) is
flagged up as invalid and discarded *without any action being
taken*. In this case the text in s9.1.1 is never actioned.

[Huub3] according to s9.1.1 the capability TLV MUST be added
always to every PSC message sent. The capability bits are set to
the provisioned mode. There is one exception: the original PSC as
described in RFC6378, because that does not use capability TLV.

For my peace of mind.. Can you confirm whether my interprestation of RFC
6378 s6 is correct, i.e., bit errors in transmission are *not* detected
by the layers below the PSC protocol and corrupted PSC messages will be
passed to the PSC state machine.

[Huub3] If the (lower) server layer is Ethernet, the Ethernet frame can
use the FCS to detect bit errors and discard the Ethernet/MPLS frame.
If FCS is not used bit errors are undetected.
If the (lower) server layer is SDH/SONET/OTN the FEC (forward
error correction) will correct bit errors that occur in the physical layer.
If FEC is not used bit errors are counted, if the error rate is excessive
AIS will be inserted, in a packet (higher) client layer this will result in
discarding all frames.

Cheers, Huub.

---

From: Eric Gray <[email-masked]>
Date: Tue, 4 Mar 2014 17:54:13 +0000

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:[email-masked]] 
Sent: Wednesday, February 26, 2014 2:58 PM
To: Elwyn Davies
Cc: General Area Review Team; [email-masked]
Subject: RE: Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt

Hello Elwyn,

Thanks for your reply.

=====
On Wed, 2014-02-26 at 16:39 +0000, Huub Van Helvoort wrote:
> > (FOO) adds <n> more capabilities but the two 'modes' can be turned on

or:

Cheers, Huub.

---

From: Eric Gray <[email-masked]>
Date: Tue, 4 Mar 2014 17:55:23 +0000

It looks like we have convergence - in theory.  The question is what text,
if any, needs to change?

-----Original Message-----
From: Gen-art [mailto:[email-masked]] On Behalf Of Huub van Helvoort
Sent: Wednesday, February 26, 2014 3:22 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt

Shwmae Adrian,

You wrote:

> [snip]
> 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.

> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Eric Gray <[email-masked]>
Date: Tue, 4 Mar 2014 18:13:23 +0000

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:[email-masked]] On Behalf Of Elwyn Davies
Sent: Wednesday, February 26, 2014 1:24 PM
To: Huub Van Helvoort
Cc: General Area Review Team; [email-masked]
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.

>     continual messages intervals, the last valid received message remains

Sorry to harp on about this... I think we are trying to distinguish
quoted above.  The text in [Huub2} implies:

---

From: Eric Gray <[email-masked]>
Date: Tue, 4 Mar 2014 18:15:19 +0000

Jeong-dong,

                If you change "not allowed" to "not supported in this specification" – I think
we have it.

--
Eric

From: Ryoo, Jeong-dong [mailto:[email-masked]]
Sent: Tuesday, March 04, 2014 12:38 PM
To: Huub Van Helvoort; Elwyn Davies
Cc: General Area Review Team; [email-masked]
Subject: RE: Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt

Hi,

Section 9.2
OLD:

Best regards,

Jeong-dong

________________________________
From : "Huub Van Helvoort" <[email-masked]<mailto:[email-masked]>>
Sent : 2014-02-27 04:58:09 ( +09:00 )
To : Elwyn Davies <[email-masked]<mailto:[email-masked]>>
Cc : General Area Review Team <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject : RE: Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt

Hello Elwyn,

Thanks for your reply.

=====

or:

Cheers, Huub.

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Wed, 5 Mar 2014 10:24:57 +0000

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" <[email-masked]>
Sent : 2014-03-05 03:15:24 ( +09:00 )
To : Ryoo, Jeong-dong <[email-masked]>, Huub Van Helvoort <[email-masked]>, Elwyn Davies <[email-masked]>
Cc : General Area Review Team <[email-masked]>, [email-masked] <[email-masked]>
Subject : RE: Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt

Jeong-dong,

--
Eric

Hi,

Section 9.2
OLD:

Best regards,

Jeong-dong

Hello Elwyn,

Thanks for your reply.

=====

or:

Cheers, Huub.

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Wed, 5 Mar 2014 12:00:10 +0000

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.

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Wed, 5 Mar 2014 16:05:39 +0000

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" <[email-masked]> wrote:

>Cc: General Area Review Team;
>[email-masked]

---

From: Eric Gray <[email-masked]>
Date: Wed, 5 Mar 2014 17:48:32 +0000

See below…

From: Gen-art [mailto:[email-masked]] 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; [email-masked]
Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt

Hi,

Any thoughts here?...

[Huub2] see below.

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?

Similarly,
OLD:

 I like it.

 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 "on the wire."  Software folks simply use a POSIX macro to
take integers (of various sizes) in machine native format and put them
in "network bit order."  And hardware folks will tell you that – these
days – network bit order is a meaningless phrase anyway as it only
has any meaning what-so-ever when bits are sent serially and a lot
of sending media do not actually do this anymore.

I imagine it's only a question of time before the answer you get when
you ask "what is the order to bits on the wire?" will be "what's a wire?"

This should be stated.

I agree.

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Wed, 5 Mar 2014 18:07:56 +0000

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

Sent : 2014-03-06 02:48:38 ( +09:00 )

See below…

Hi,

Any thoughts here?...

[Huub2] see below.

Similarly,
OLD:

 I like it.

This should be stated.

I agree.