See below…
From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Ryoo, Jeong-dong
Sent: Wednesday, March 05, 2014 7:00 AM
To: Huub Van Helvoort; Elwyn Davies
Cc: General Area Review Team; draft-ietf-mpls-tp-psc-itu....@tools.ietf.org
Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-mpls-tp-psc-itu-02.txt
Hi,
In order to find correct text to reflect the comments that are agreed so far, I
am suggesting the text below.
Please, see inlines starting with [JR]
I erased the parts that do not need further discussion.
> s8, definition of Exercise (EXER): Describing EXER as 'replacing' one
> of
> NR, RR or DNR seems a bit odd. Mentioning RR is particularly
> problematic since it makes the definitions sort of circular as RR is
> the response to EXER.
Any thoughts here?...
[Huub2] see below.
> I guess what is probably appropriate is to say that
> it is built in the same way as an NR message would be built.
>
> [Huub] the "replacing" means that in case an operator wants to verify
> the operation of PSC, the excersise commend is issued and the
> transmission of RR (or NR, or DNR) is stopped and EXER is sent
> instead.
I think I see what is going on noew
Perhaps adding something like the phrase "that would normally be sent
periodically in the IDLE state"
I think you would not want to send EXER periodically in the IDLE state.
Also, wouldn't you have to stop sending RR at both ends before using
EXER in order to avoid getting a false indication of success? In a way,
what you would be doing is sending EXER on demand, instead of RR
periodically, correct?
[Huub2] if it helps readability we will do as suggested.
[JR] Since the draft does not have "IDLE" state and the phrase with quotation
marks above does not quite fit into current text,
I suggest the following modifications:
OLD:
(3) Exercise - indicates that the transmitting end point is
exercising the protection channel and mechanism. FPath and Path
are set to the same value of the No Request (NR), RR or DNR
request that EXER replaces
NEW:
(3) Exercise - indicates that the transmitting end point is
exercising the protection channel and mechanism. FPath and Path
are set to the same value of the No Request (NR), RR or DNR
message whose transmission is stopped by EXER.
Similarly,
OLD:
(2) Reverse Request - indicates that the transmitting end point is
responding to an EXER command from the remote node. FPath and
request that RR replaces.
NEW:
(2) Reverse Request - indicates that the transmitting end point is
responding to an EXER command from the remote node. FPath and
Path are set to the same value of the NR or DNR
message whose transmission is stopped by RR.
I like it.
> s9.1: RFC 6378 doesn't define the encoding of the TLV type and TLV
> length fields, so it needs to be done here (Unsigned integers). (It
> also
> doesn't define encoding of the (unnecessary) overall TLV length field
> in the PSC header.
>
> [Huub] IANA asigned the TLV type value. By not giving exact values
> we leave the possibility open that there are more than 32 flags.
That's not the issue. The problem is that the protocol does not specify
how the type and length numbers should be represented on the wire. The
standard answer is unsigned integer in network bit order.
[Huub2] OK, I now understand your point. This can be addressed.
[JR]
OLD:
A Capability is an individual behavior whose use is signaled in a
Capabilities TLV, which is placed in Optional TLVs field inside the
PSC message shown in Figure 2 of [RFC6378]. The format of the
Capabilities TLV is:
NEW:
A Capability is an individual behavior whose use is signaled in a
Capabilities TLV, which is placed in Optional TLVs field inside the
PSC message shown in Figure 2 of [RFC6378].
TLV Length field in Figure 2 of [RFC6378] indicates the number of
bytes included in Optional TLVs field. For capability sets supported
in this document, this value MUST be set to 8.
The format of the Capabilities TLV is:
It's a bit hard to figure out who said what in the text above. I assume
that the bit between [Huub] IANA assigned … - and [Huub2] OK … is a
response to "[Huub] …" that we responded to in "[Huub2] …"
If that is correct, then the text changes above don't address the intent
of the comment.
The way I read the exchange, we're not being asked to explain what the
Length field means and what value we expect in this specification, just
how it would be sent on the wire.
I don't think many RFCs actually include this (though I believe that the
suggestion of "unsigned integer in network bit order" is correct). The
ordering is usually assumed to be in the "standard" order whenever
the typical ASCII text format specification used in RFCs is used.
Because of this, I wonder if we might not be better off following the
usual practice and leaving this "to the imagination of the reader."
There are many reasons for doing this. One is that few people know
what "network bit order" really means in terms of how the bits are
ordered "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?"
> 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.
I agree.
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
