Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)
RFC 4842

Note: This ballot was opened for revision 14 and is now closed.

(Mark Townsley) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Brian Carpenter) No Objection

Comment (2006-10-12 for -)
No email
send info
I'm surprised that 5.2.1 doesn't discuss how long to wait at startup before
starting playout. It seems advisable to build up a short queue before
starting playout, to allow for subsequent jitter in the arrival rate.

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2006-10-11 for -)
No email
send info
  The document seems to lack a both a reference to RFC 2119 and the
  recommended RFC 2119 boilerplate, even if it appears to use RFC 2119

Section 10.1., paragraph 0:
>     10.1.  Dynamic Bandwidth Allocation

  Usage of this option may create bursty traffic with bursts of larger
  uncompressed packets followed by bursts of shorter compressed packets
  on potentially short cycles. From a congestion control standpoint,
  this can be worse than always-on CBR and requires discussion.

Section, paragraph 1:
>    The actual CEP payload size depends on the number of virtual
>    tributaries carried within the fractional SPE.  The contributions of
>    each tributary to the fractional VC-4 payload length as well as the
>    path overhead contribution are described below.

  If I understand this correctly, the resulting minimum packet size may
  be larger than the minimum PMTU in the Internet, leading to

Section 12., paragraph 2:
>    Forwarding [EF] provide examples of such PSNs.  It is expected that
>    PWs emulating high rate SONET STS-Nc or SDH virtual circuits will be
>    tunneled over traffic-engineered MPLS PSN.

  Recommend much stronger language than "it is expected."

(Bill Fenner) No Objection

(Russ Housley) (was Discuss) No Objection

(Cullen Jennings) (was Discuss) No Objection

(David Kessens) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

Comment (2006-10-06 for -)
No email
send info
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.

Magnus Westerlund (was Discuss) No Objection

(Sam Hartman) Abstain

Comment (2006-10-09 for -)
No email
send info
I'm abstaining because while I think the document is rather
incomplete, I am not sure of any harm done.
Things I would fix:
* Define a more clear interface between this and PW setup--what must two parties
agree to set up this encapsulation?  This is scattered all throughout the document
* How are various fields in the MPLS control word used when this is carried over MPLS
* Which RTP profile is used?
* How should security be handled?  SRTP?  IPsec? etc?