Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)
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 value found for 'p.get_dochistory.rev' **)
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 value found for 'p.get_dochistory.rev' **)
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 keywords. 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 10.2.3.4., 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 fragmentation? 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 value found for 'p.get_dochistory.rev' **)
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 value found for 'p.get_dochistory.rev' **)
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?