Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)
RFC 5086

[Ballot comment]
This document follows the requirements and architecture defined in RFC3916 and RFC4197. RFC3916 includes in Section 6 a statement that 'Each PWE3 approach SHOULD provide some mechanisms for network operators to manage the emulated service' and then goes into more detailed requirements about how such mechanisms could be implemented. I am surprised about the lack of any managemement or operational considerations section in this document in order to show how the requirements in Section 6 of RFC3916 are supposed to be addressed.

[Ballot discuss]
Section 4.4:

6. The SSRC (synchronization source) value in the RTP header MAY be
    used for detection of misconnections.

How, there seem to be a lack of explanation on how that is done.

Section 4.4:

This specification redefines RTP header behavior. That is only allowed by profiles. Thus if a redefined behavior is need a new profile need to be created. However I do suspect that this is not at all necessary and already defined profiels can be used. The specification must be rewritten to be using the defined behaviors of RTP or define a profile.

Because if one are going to be using RTP, the control word MUST be defined as an RTP payload format for RTP. That requires one to do a bit more than what is currently written into this specification. For instructions on what to think when defining RTP payload formats please reviw:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-howto-00.txt

section 5.3:

Here it seems that the control channel may need its own payload format, or at least a parameter to indicate that it is control rather than data. I also wonder why you mandate an SSRC change. If the control channel is tightly connected to the data channel, then they maybe should have the same. I can understand if there is some reason for this, like sequence number space. However this should be clarified and also some text on how to connect the control channel with the data channel should be done.

[Ballot discuss]
I don't think a specification should subset RTP in such a way that it eliminates every one of the RTP extensibility mechanism. I suggest making a slight change to the document to just allow RTP.

The document says that SRTP should not be used but I think this should change. Once of the key reasons for using SRTP existence is that it will achieve much better compression in cases exactly like this when coupled with an appropriate header compression mechanism.

[Ballot comment]
Why is this going for Informational not PS?


Section 0, paragraph 5:
>  [RFC3985] and [RFC3931 ] respectively.

  Missing Reference: 'RFC 3931' is mentioned on line 1065, but not
  defined


Section 13., paragraph 1:
>  [RFC 2401] Kent S., Atkinson, R., Security Architecture for the
>  Internet Protocol, RFC 2401, November 1998

  Unused Reference: 'RFC 2401' is defined on line 1230, but not
  referenced

[Ballot discuss]
From Gen-ART review by Joel Halpern:

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.

BC: it is not OK to leave a gap like that even in an Informational.
We need the reference.

[Ballot comment]
From discussion between Gen-ART reviewer Joel Halpern and Yakov Stein:

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.

-----------

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.

BC: I disagree. It's almost as though people working in the ITU
are wishing to characterize the Internet as horribly unreliable,
but that can't be true can it? Better to simply drop the
specific percentage, I think.

IANA Last Call Comment:

Based on the statement in the IANA Considerations section, the
IANA assumes that the existing registrations for CESoPSN basic
mode and CESoPSN TDM with CAS are the only needed registrations
for this document. Since these registrions were already made
with the approval of RFC 4446, the IANA understands that no
additional actions are required.

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication?

Yes

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

This document has been fully reviewed by the PWE3 WG.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

We have no concerns.

1.d) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

We have no concerns.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is firm consensus for the design described in this document.
This document also aligns with the work of ITU SG13 Y.1453

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email to the Responsible Area Director.

No

1.g) Have the chairs verified that the document adheres to all of the
ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes

1.h) Is the document split into normative and informative references?
Are there normative references to IDs, where the IDs are not
also ready for advancement or are otherwise in an unclear state?
(note here that the RFC editor will not publish an RFC with
normative references to IDs, it will delay publication until all
such IDs are also ready for publication as RFCs.)

Yes, it is correctly split into normative and informative references.
All normative references are either RFCs, or in the RFC-Editor
queue.


1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a write-up section with the following
sections:

* Technical Summary

This draft extends the work described in RFC4553 by describing one
method of encapsulating structured (NxDS0) Time Division Multiplexed
(TDM) signals as pseudo-wires over packet-switching networks (PSN).

The use of a structure aware method of emulating NxDS0 circuits provides
for saving PSN bandwidth, supports DS0-level grooming and distributed
cross-connect applications. It also enhances resilience of CE devices to
effects of loss of packets in the PSN.

The structured method described in this draft uses a structure locking
mechanism in which there is a constant relationship between a particular
DS0 circuit and the position in which the corresponding information
is carried in the PW payload. The method provides the ability to keep the
edge-to-edge delay of the emulated service independent of the service rate.

* Working Group Summary

Although the Working Group was able to reach consensus on the
unstructured TDM emulation method (SAToP/RFC4553), it could
not reach consensus on the best method of emulating a structured
service. The PWE3 WG therefore decided to pursue two methods as
informational RFCs(draft-ietf-pwe3-cesopsn-07.txt and
draft-ietf-pwe3-tdmoip-05.txt) and to gain operational experience
with the technology before recommending a standards track approach.

* Protocol Quality

There are many implementations of this protocol, and it is
in operational service.