[Gen-art] RE: Gen-Art LC Review: draft-ietf-pwe3-tdmoip-05.txt

["Yaakov Stein" <[e-mail]>]

Joel, thanks for the review.

My comments on your findings are interleaved below.

Y(J)S
 

-----Original Message-----
From: Joel M. Halpern [mailto:[e-mail]] 
Sent: Monday, September 04, 2006 02:48
To: Mary Barnes; [e-mail]
Cc: Mark Townsley; Stewart Bryant; Danny McPherson; Yaakov Stein;
[e-mail]
Subject: Gen-Art LC Review: draft-ietf-pwe3-tdmoip-05.txt

I am the assigned Gen-ART reviewer for draft-ietf-pwe3-tdmoip-05.txt.
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

(Minor note: I am copying only the first of the authors as otherwise
filters may complain about the number of adressees.  I will send a
separate copy to the other authors, as I expect the copy to the WG list
to be delayed.)

Please resolve these comments along with any other Last Call comments
you may receive.


This document is nearly ready for publication as an RFC.  There are some
items which warrant attention.


Question: Section 3 appears to define specific bits on the wire.  It 
defines the order of RTP vs other headers, and defines the setting of 
specific bits in the RTP header.  Later sections define wire formats 
for other headers.  Given such definitions, I would expect the 
document to be either Experimental or Standards track, rather than 
Informational.  I presume that this has been addressed, but since the 
tracker does not show anything, I am raising the question.
(I suspect that the WGs view is that the formats are all normatively 
defined elsewhere, and are just being collected here for 
reference.  Collecting packet formats by value, rather than by 
reference, is nice for books, but not usually a good idea for 
RFCs.  And at least the RTP header order and header field settings 
appear to be defined normatively here.)
Further, the presence of distinctly marked "informative" appendix 
indicates that the document is defining expected behavior and is 
itself more than informational.

[YJS] The designation of SAToP as standards track,
and of TDMoIP and CESoPSN as informative, 
was the result of a 3-year long battle in the PWE3 WG.
Although I quite agree that the document defines a specific
protocol (and one that has been widely deployed),
I suggest not bringing that question up again.

moderate: The introduction does not tell me what this document is 
about.  A few sentences along the lines of the technical summary in 
the tracker would help.

[YJS] The description is in the Abstract and hinted at in the first
paragraph
of the Introducton. I will add a few sentences to the first paragraph
to make this more clear.

moderate: The paragraph on SAToP in section 2.seems to characterize a 
loss rate of one fifth of one percent as an "extremely reliable and 
overprovisioned PSN."  While I do not want to get in to an argument 
about what is acceptable, it is to be noted that even TCP will have 
performance problems with a link with a 0.2% loss rate.  ISPs with 
loss rates much lower than that are still not usually referred to as 
"extremely reliable."  I would recommend simply removing the sentence.

[YJS] This number come up from two sources.
1) documents presented to the ITU question that worked in parallel
to PWE3 showing that this is indeed a kind of dividing line between
well-engineered networks and best-effort ones.
2) empirical results that the user experience of circuit emulation
with AIS substitiution drops at this level (see
draft-stein-pwe3-tdm-packetloss-01.txt
now expired).
In any case, we are continually asked to characterize when to
stop using SAToP and go over to one of the structure-aware methods.
This is as good a break-point as any.
For these reasons I would suggest keeping this sentence.

moderate: following the discussion of severly errored seconds (in the 
SAToP context in section 2), there is text indicating that the use of 
structure aware transport may allow one "to effectively conceal 
packet loss events."  This concealment is not actually described as 
a feature of the protocol anywhere else.  The erorr handling in 
section 6 quite nicely describes what to do with lost packets, and it 
is not to conceal the error.  It does generate the error indication 
so errors are associated with the right place.

[YJS] This was discussed in draft-stein-pwe3-tdm-packetloss-01.txt
but the WG decided NOT to accept this as a BCP.
I offered to detail the algorithms involved,
but gave up trying to write the equations in ASCII.

moderate: Is the entire control word description after figure 2 
copied from RFC 4385, or does this text probide more specific 
meanings / settings / usage  in the structured TDM context?  (I 
suspect it is just a copy of 4385.  If so, I would suggest a shorter 
description, maybe just the field name, and text saying that one 
should see 4385 for the full format.  Copying text between RFCs is 
not a good idea.)  Whatever the case is, the text needs to be clear
about it.

[YJS] The text here pre-dated 4385, and indeed is now compliant
with 4385. The only difference is the allowance of a pre-4385 usage
of a FORMID (which was fully specified in earlier versions of the
draft, but now as a comment for implementers).

moderate: After reading section 5.3 several times, I am still left 
guessing as to what the actual payload format will be when 
transporting HDLC data using TDMoIP.  I presume it is described here 
somehwere, but I can't find it.

[YJS] It is compliant with draft-ietf-pwe3-hdlc-ppp-encap-mpls-09.txt.
If this becomes an RFC before publication of TDMoIP, I will quote it.

minor: The Introduction uses the abbreviation PSN without ever 
expanding it.  The first use should be "Packet Switch Network (PSN)"
minor: I find the characterization of UDP over IPv4 as being a 
distinct type of packet switch network from L2TPv3 over IP an odd 
distinction.  They are different protocols (UDP vs L2TPv3), but they 
are not different networks.  This may be conventional usage in some 
context, but is not a common IETF usage.

[YJS] OK. PSN is of course very common in PWE
and described in RFCs 3916 and 2985.
I will fix.

minor:  The paragraph (3rd paragraph in section 2) defining the 
number of 64Kbit channels carried in a T1 / E1, and the chunk size 
for those channels appears to be too concise.  A few more words would 
clear up what number is the number of channels, and what number is 
the chunk size used to carry a block for a single channel.  As 
written the reader must stop and study the text to figure out what 
was intended.

[YJS] I will add a few words.

minor: The first usage of "SAToP" (in section 2) should have the 
acronym expanded. I should not have to go to the references to 
determine the name of the protocol.

[YJS] OK
----
INT TDM over IP
	draft-ietf-pwe3-tdmoip-05.txt

AD: Mark Townsley
Reviewer: Joel Halpern


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art