Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)
draft-ietf-pwe3-sonet-14
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
14 | (System) | post-migration administrative database adjustment to the No Objection position for Cullen Jennings |
2012-08-22
|
14 | (System) | post-migration administrative database adjustment to the No Objection position for Magnus Westerlund |
2012-08-22
|
14 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2007-01-22
|
14 | (System) | IANA Action state changed to No IC from In Progress |
2007-01-22
|
14 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2007-01-21
|
14 | (System) | IANA Action state changed to In Progress |
2007-01-17
|
14 | Amy Vezza | IESG state changed to Approved-announcement sent |
2007-01-17
|
14 | Amy Vezza | IESG has approved the document |
2007-01-17
|
14 | Amy Vezza | Closed "Approve" ballot |
2007-01-17
|
14 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2007-01-15
|
14 | Mark Townsley | [Note]: 'Email to authors/chairs about new wording referring to "PW Layer Security" - should be resolvable with RFC Editor''s note, and is last remaining issue … [Note]: 'Email to authors/chairs about new wording referring to "PW Layer Security" - should be resolvable with RFC Editor''s note, and is last remaining issue before approval.' added by Mark Townsley |
2006-12-29
|
14 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2006-12-28
|
14 | (System) | New version available: draft-ietf-pwe3-sonet-14.txt |
2006-11-08
|
14 | (System) | Request for Early review by SECDIR is assigned to Love Astrand |
2006-11-08
|
14 | (System) | Request for Early review by SECDIR is assigned to Love Astrand |
2006-10-31
|
14 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings |
2006-10-31
|
14 | Russ Housley | [Ballot discuss] I expected the security considerations to suggest IPsec as a possible security solution whin IP is used. Why is it omitted? |
2006-10-31
|
14 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund |
2006-10-30
|
14 | Cullen Jennings | [Ballot discuss] Please update on how RTP is used for timing only and why this makes any extension for RTP (including SRTP) not allowed. (Like … [Ballot discuss] Please update on how RTP is used for timing only and why this makes any extension for RTP (including SRTP) not allowed. (Like the RFC ed note for draft-ietf-pwe3-cesopsn) |
2006-10-12
|
14 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2006-10-12
|
14 | Amy Vezza | State Changes to IESG Evaluation from DNP-waiting for AD note by Amy Vezza |
2006-10-12
|
14 | Amy Vezza | State Changes to DNP-waiting for AD note from IESG Evaluation by Amy Vezza |
2006-10-12
|
14 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2006-10-12
|
14 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2006-10-12
|
14 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded by Bill Fenner |
2006-10-12
|
14 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2006-10-12
|
14 | Brian Carpenter | [Ballot comment] 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 … [Ballot comment] 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. |
2006-10-12
|
14 | Brian Carpenter | [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter |
2006-10-12
|
14 | David Kessens | [Ballot Position Update] New position, No Objection, has been recorded by David Kessens |
2006-10-11
|
14 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2006-10-11
|
14 | Cullen Jennings | [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 … [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. |
2006-10-11
|
14 | Cullen Jennings | [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings |
2006-10-11
|
14 | Magnus Westerlund | [Ballot discuss] Section 4.3: This specification redefines RTP header behavior. Just two examples of this: P : Padding. No padding is required. … [Ballot discuss] Section 4.3: This specification redefines RTP header behavior. Just two examples of this: P : Padding. No padding is required. The P bit MUST be set to 0 by sender and ignored by receiver. X : Header extension. No extensions are defined. The X bit MUST be set to 0 by sender and ignored by receiver. The P and X bit are not allowed to be ignored. The whole issue with this section is that it do not really use RTP, but something that looks like RTP but not quite are it. This is not acceptable. The specification must be rewritten to be using the defined behaviors of RTP. Because if one are going to be using RTP in the stack defined here the CEP 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 example only three fields of the RTP header needs to be really defined on how they use them by the RTP payload format, the marker bit, the timestamp field and the sequence number. 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 I are also not clear what multiple SSRCs would mean in your context. Section 5.1: " The CEP sequence numbers provide a mechanism to detect lost and/or miss-ordered packets. The sequence number in the CEP header MUST be used when transmission of the RTP header is suppressed. The CEP de- packetizer MUST detect lost or miss-ordered packets. The CEP de- packetizer SHOULD play out an all ones pattern (AIS) in place of any dropped packets. The CEP de-packetizer SHOULD re-order packets received out of order. If the CEP de-packetizer does not support re- ordering, it MUST drop miss-ordered packets." Shouldn't this section also discuss duplicated packets? Or are you simply consider them miss-ordered? Section 11.3: As I understand the only way of inidcating the usage of RTP is in the CEP option. However I don't understand how this fullfil at all the signalling requirement of RTP and the CEP as RTP payload. 1. There is no indication of which RTP profile is used and this should be dynamically negotiable. 2. No dynamic binding of RTP payload type values to the CEP RTP payload and its parameters. 3. There is also a question of further signalling related to RTP session would be needed for this usage. This to enable the usage of other RTP mechanisms to enhance the flow behavior, such as redundancy, FEC, retransmission, congestion control, monitoring, usage of RTCP etc. In fact this doesn't seem to fullfil the requirement of section 4.3. Please explain if this is done somewhere else. Section 16.1: The following reference contains errors: [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3005, July 2003. It should be: [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. ^^^ |
2006-10-11
|
14 | Magnus Westerlund | [Ballot discuss] Section 4.3: This specification redefines RTP header behavior. Just two examples of this: P : Padding. No padding is required. … [Ballot discuss] Section 4.3: This specification redefines RTP header behavior. Just two examples of this: P : Padding. No padding is required. The P bit MUST be set to 0 by sender and ignored by receiver. X : Header extension. No extensions are defined. The X bit MUST be set to 0 by sender and ignored by receiver. The P and X bit are not allowed to be ignored. The whole issue with this section is that it do not really use RTP, but something that looks like RTP but not quite are it. This is not acceptable. The specification must be rewritten to be using the defined behaviors of RTP. Because if one are going to be using RTP in the stack defined here the CEP 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 example only three fields of the RTP header needs to be really defined on how they use them by the RTP payload format, the marker bit, the timestamp field and the sequence number. 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 I are also not clear what multiple SSRCs would mean in your context. Section 5.1: " The CEP sequence numbers provide a mechanism to detect lost and/or miss-ordered packets. The sequence number in the CEP header MUST be used when transmission of the RTP header is suppressed. The CEP de- packetizer MUST detect lost or miss-ordered packets. The CEP de- packetizer SHOULD play out an all ones pattern (AIS) in place of any dropped packets. The CEP de-packetizer SHOULD re-order packets received out of order. If the CEP de-packetizer does not support re- ordering, it MUST drop miss-ordered packets." Shouldn't this section also discuss duplicated packets? Or are you simply consider them miss-ordered? Section 11.3: As I understand the only way of inidcating the usage of RTP is in the CEP option. However I don't understand how this fullfil at all the signalling requirement of RTP and the CEP as RTP payload. 1. There is no indication of which RTP profile is used and this should be dynamically negotiable. 2. No dynamic binding of RTP payload type values to the CEP RTP payload and its parameters. 3. There is also a question of further signalling related to RTP session would be needed for this usage. This to enable the usage of other RTP mechanisms to enhance the flow behavior, such as redundancy, FEC, retransmission, congestion control, monitoring, usage of RTCP etc. In fact this doesn't seem to fullfil the requirement of section 4.3. Please explain if this is done somewhere else. |
2006-10-11
|
14 | Magnus Westerlund | [Ballot discuss] Section 4.3: This specification redefines RTP header behavior. Just two examples of this: P : Padding. No padding is required. … [Ballot discuss] Section 4.3: This specification redefines RTP header behavior. Just two examples of this: P : Padding. No padding is required. The P bit MUST be set to 0 by sender and ignored by receiver. X : Header extension. No extensions are defined. The X bit MUST be set to 0 by sender and ignored by receiver. The P and X bit are not allowed to be ignored. The whole issue with this section is that it do not really use RTP, but something that looks like RTP but not quite are it. This is not acceptable. The specification must be rewritten to be using the defined behaviors of RTP. Because if one are going to be using RTP in the stack defined here the CEP 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 example only three fields of the RTP header needs to be really defined on how they use them by the RTP payload format, the marker bit, the timestamp field and the sequence number. 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 I are also not clear what multiple SSRCs would mean in your context. I assume that PWE uses another signalling layer than the most common one based on SDP to establish the dynamic information, however that still requires one to define that information in a structured way. I would like to know how RTP profiles and other configuration information is established for this pseudowire. Please provide a pointer for discussion. Section 5.1: " The CEP sequence numbers provide a mechanism to detect lost and/or miss-ordered packets. The sequence number in the CEP header MUST be used when transmission of the RTP header is suppressed. The CEP de- packetizer MUST detect lost or miss-ordered packets. The CEP de- packetizer SHOULD play out an all ones pattern (AIS) in place of any dropped packets. The CEP de-packetizer SHOULD re-order packets received out of order. If the CEP de-packetizer does not support re- ordering, it MUST drop miss-ordered packets." Shouldn't this section also discuss duplicated packets? Or are you simply consider them miss-ordered? |
2006-10-11
|
14 | Lars Eggert | [Ballot comment] The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears … [Ballot comment] 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." |
2006-10-11
|
14 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2006-10-11
|
14 | Magnus Westerlund | [Ballot discuss] Section 4.3: This specification redefines RTP header behavior. Just two examples of this: P : Padding. No padding is required. … [Ballot discuss] Section 4.3: This specification redefines RTP header behavior. Just two examples of this: P : Padding. No padding is required. The P bit MUST be set to 0 by sender and ignored by receiver. X : Header extension. No extensions are defined. The X bit MUST be set to 0 by sender and ignored by receiver. The P and X bit are not allowed to be ignored. The whole issue with this section is that it do not really use RTP, but something that looks like RTP but not quite are it. This is not acceptable. The specification must be rewritten to be using the defined behaviors of RTP. Because if one are going to be using RTP in the stack defined here the CEP 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 example only three fields of the RTP header needs to be really defined on how they use them by the RTP payload format, the marker bit, the timestamp field and the sequence number. 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 I do understand that PWE uses another signalling layer to establish the dynamic information, however that still requires one to define that information in a structured way. I like raised by other would like to know how profiles and other configuration information is established for this pseudowire. |
2006-10-11
|
14 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund |
2006-10-10
|
14 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2006-10-09
|
14 | Amy Vezza | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Amy Vezza |
2006-10-09
|
14 | Russ Housley | [Ballot discuss] RTP is an option. So, why isn't SRTP an option for providing security? Similarly, I expected the security considerations to suggest … [Ballot discuss] RTP is an option. So, why isn't SRTP an option for providing security? Similarly, I expected the security considerations to suggest IPsec as a possible security solution whin IP is used. |
2006-10-09
|
14 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2006-10-09
|
14 | Sam Hartman | [Ballot comment] I'm abstaining because while I think the document is rather incomplete, I am not sure of any harm done. Things I would fix: … [Ballot comment] 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? |
2006-10-09
|
14 | Sam Hartman | [Ballot Position Update] New position, Abstain, has been recorded by Sam Hartman |
2006-10-06
|
14 | Dan Romascanu | [Ballot comment] This document follows the requirements and architecture defined in RFC3916 and RFC4197. RFC3916 includes in Section 6 a statement that 'Each PWE3 … [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. |
2006-09-26
|
14 | Mark Townsley | Telechat date was changed to 2006-10-12 from by Mark Townsley |
2006-09-26
|
14 | Mark Townsley | Placed on agenda for telechat - 2006-10-12 by Mark Townsley |
2006-09-26
|
14 | Mark Townsley | [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley |
2006-09-26
|
14 | Mark Townsley | Ballot has been issued by Mark Townsley |
2006-09-26
|
14 | Mark Townsley | Created "Approve" ballot |
2006-09-15
|
14 | Yoshiko Fong | IANA Last Call Comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2006-09-04
|
14 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2006-08-21
|
14 | Amy Vezza | Last call sent |
2006-08-21
|
14 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2006-08-21
|
14 | Mark Townsley | Last Call was requested by Mark Townsley |
2006-08-21
|
14 | Mark Townsley | State Changes to Last Call Requested from Publication Requested by Mark Townsley |
2006-08-21
|
14 | (System) | Ballot writeup text was added |
2006-08-21
|
14 | (System) | Last call text was added |
2006-08-21
|
14 | (System) | Ballot approval text was added |
2006-07-07
|
14 | Dinara Suleymanova | 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 … 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. 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 There is a minor boilerplate issue, but nothing that should stop the draft going for AD review 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 document provides encapsulation formats and semantics for emulating SONET/SDH circuits and services over packet-switched networks, and MPLS networks in particular. * Working Group Summary This draft has been extensively reviewed by the PWE3 WG and there is consensus for it. It was recently revised with modifications to the control word to bring it into line with the other PWE3 specifications. * Protocol Quality There are no known issues with this protocol. |
2006-07-07
|
14 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
2006-06-05
|
13 | (System) | New version available: draft-ietf-pwe3-sonet-13.txt |
2006-01-09
|
12 | (System) | New version available: draft-ietf-pwe3-sonet-12.txt |
2005-05-18
|
11 | (System) | New version available: draft-ietf-pwe3-sonet-11.txt |
2005-02-25
|
(System) | Posted related IPR disclosure: Level 3 Communications, Inc.'s statement about IPR claimed in draft-ietf-pwe3-sonet-10.txt | |
2005-02-21
|
10 | (System) | New version available: draft-ietf-pwe3-sonet-10.txt |
2004-09-07
|
09 | (System) | New version available: draft-ietf-pwe3-sonet-09.txt |
2004-06-22
|
08 | (System) | New version available: draft-ietf-pwe3-sonet-08.txt |
2004-06-07
|
07 | (System) | New version available: draft-ietf-pwe3-sonet-07.txt |
2004-05-26
|
(System) | Posted related IPR disclosure: Lycium Networks Statement about IPR Claimed in draft-ietf-pwe3-sonet | |
2004-05-25
|
06 | (System) | New version available: draft-ietf-pwe3-sonet-06.txt |
2004-04-26
|
05 | (System) | New version available: draft-ietf-pwe3-sonet-05.txt |
2004-03-31
|
04 | (System) | New version available: draft-ietf-pwe3-sonet-04.txt |
2003-10-24
|
03 | (System) | New version available: draft-ietf-pwe3-sonet-03.txt |
2003-07-02
|
02 | (System) | New version available: draft-ietf-pwe3-sonet-02.txt |
2003-05-05
|
(System) | Posted related IPR disclosure: Vivace Networks Patent Statement Pertaining to draft-malis-sonet-ces-mpls-xx.txt and draft-ietf-pwe3-sonet-xx.txt | |
2003-02-03
|
01 | (System) | New version available: draft-ietf-pwe3-sonet-01.txt |
2002-07-25
|
00 | (System) | New version available: draft-ietf-pwe3-sonet-00.txt |