Skip to main content

Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)
draft-ietf-pwe3-sonet-14

Yes

(Mark Townsley)

No Objection

(Bill Fenner)
(Cullen Jennings)
(David Kessens)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Ross Callon)
(Russ Housley)

Abstain


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

Mark Townsley Former IESG member
Yes
Yes () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Brian Carpenter Former IESG member
No Objection
No Objection (2006-10-12) Unknown
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.
Cullen Jennings Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection (2006-10-06) Unknown
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.
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection (2006-10-11) Unknown
  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."
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Sam Hartman Former IESG member
Abstain
Abstain (2006-10-09) Unknown
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?