RE: [PWE3] CEP IESG comments
"Ron Cohen" <ronc@resolutenetworks.com> Wed, 22 November 2006 08:40 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmnel-0004FW-66; Wed, 22 Nov 2006 03:40:35 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmnek-0004FK-Aw; Wed, 22 Nov 2006 03:40:34 -0500
Received: from webmail.resolutenetworks.com ([80.179.15.67] helo=mail.resolutenetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmnef-0004h4-L3; Wed, 22 Nov 2006 03:40:34 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PWE3] CEP IESG comments
Date: Wed, 22 Nov 2006 10:41:19 +0200
Message-ID: <0606D918CE9CEA4E9835D2CDAA001A95AA9206@ilmail1.il.reduxcom.com>
In-Reply-To: <4557DDE2.6010809@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PWE3] CEP IESG comments
Thread-Index: AccGzvFh5fk4ocrGRHST1P/5NHNiGAHP3CQg
From: Ron Cohen <ronc@resolutenetworks.com>
To: Carlos Pignataro <cpignata@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92
Cc: pwe3@ietf.org, l2tpext@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
Errors-To: pwe3-bounces@ietf.org
Carlos, Apologies for the late response. You are correct and the draft does not state either an IANA requirement nor specify the LT2Pv3 PW type. The draft does not address L2TP signaling details as well. It only defines the on-the-wire format of CEP PW data over L2TP. The current text reads: L2TPv3 [L2TPv3] session ID is used to multiplex individual CEP channels over an L2TPv3 tunnel. Detailed specification of CEP behavior over L2TPv3 tunnels are beyond the scope of this document. We (CEP authors) are not aware of full CEP over L2TPv3 implementations. The implementations and deployments of CEP are over MPLS. The thinking was that a separate draft will specify the additional L2TP details. We have two options here: 1. Limit the scope of the CEP draft to CEP over MPLS. Leave CEP over L2TPv3 for further study. 2. Add a clarification to the IANA section and CEP signaling sections of the form "L2TPv3 signaling/IANA considerations are out of scope of this document" We are quite happy with one approach or the other. Comments from the WG appreciated. Feedback on CEP over L2TPv3 implementation is also welcomed. Best Ron (on behalf of CEP authors) -----Original Message----- From: Carlos Pignataro [mailto:cpignata@cisco.com] Sent: Monday, November 13, 2006 4:52 AM To: Ron Cohen Cc: pwe3@ietf.org Subject: Re: [PWE3] CEP IESG comments Ron, One quick question: The IANA Considerations section (Section 14) reads: 14. IANA Considerations IANA considerations for pseudo-wires are covered in [PWE3-IANA]. CEP does not introduce additional requirements from IANA. However, [PWE3-IANA] defines the "MPLS Pseudowire Type" [RFC4446] of "SONET/SDH Circuit Emulation over Packet (CEP)", but not the corresponding "L2TPv3 Pseudowire Type": http://www.iana.org/assignments/l2tp-parameters Also, in the signaling sections 11.X, I was wondering if the "CEP/TDM Payload Bytes" and "CEP/TDM Bit Rate" interface parameter sub-TLVs defined in [RFC4446] correspond to the "TDM PW AVP" definitions in Section 2.1 of draft-ieft-l2tpext-tdm-02 when used over L2TPv3 (and therefore a reference and brief description would be needed) http://tools.ietf.org/html/draft-ieft-l2tpext-tdm-02#section-2.1 and the "CEP Options" interface parameter sub-TLV does not have an equivalent L2TPv3 AVP. Thanks, --Carlos. On 11/10/2006 12:21 PM, Ron Cohen allegedly said the following: > Hi, > > Please find below resolutions to several comments raised during the > IESG review of the SONET PW draft (draft-ietf-pwe3-sonet-13.txt). > Please let us know of any objections or comments to these resolutions. > > The modifications are: > > 1. Limiting the draft scope to transport of CEP over MPLS and L2TP. > Transport over UDP/IP will be left out of scope of this draft. > > One comment concerned the security mechanims needed to support UDP/IP. > To address this we need to include a detailed description of the use > of IPsec, including the mechanisms needed to exchange keys. As far as > the authors have been able to determine, there is no planned use of > CEP over UDP/IP. The authors therefore recommend limiting the draft > scope to transport of CEP over MPLS and L2TP. Transport over UDP/IP > will be left out of scope of this draft and the associated sections > removed from the text. > > 2. Clarification on the use of RTP for CEP. Clarifications include > > - Add the following sentence: > > Although CEP MAY employ an RTP > header when explicit transfer of timing information is > required, this is purely formal reuse of the header format. > RTP mechanisms, such as header extensions, CSRC list, padding, > RTCP, RTP header compression, SRTP, etc. are not applicable to > pseudowires. > > - Change Figure 1 to indicate RTP header location between CEP header > and SONET fragement. > This is consistent with L2TP and MPLS PSN encapsulation of other TDM > drafts. > > +-----------------------------------+ > | PSN and Multiplexing Layer | > | Headers | > +-----------------------------------+ > | CEP Header | > +-----------------------------------+ > | RTP Header | > | (RFC3550) | > +-----------------------------------+ | > | > | | > | SONET/SDH | > | Fragment | > | | > | | > +-----------------------------------+ > > Figure 1: Basic CEP Packet > > > 3. Clarifications on security section that include adding the > following > sentences: > > Although CEP MAY employ an RTP header when explicit transfer of > timing information > is required, SRTP [RFC3711] mechanisms are not a substitute for PW > layer security. > > CEP transport over L2TPv3 is subject to the security > considerations discussed in > section 4.1.3 of [LT2Pv3]. In particular, CEP over L2TP may be > secured using IPsec > as described in [RFC3193]. > > > If this approach is acceptable to the working group we will forward > the changes to the RFC editor. > > Best > Ron (on behalf of CEP Authors) > > Ron Cohen > Resolute Networks > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > -- --Carlos Pignataro. Escalation RTP - cisco Systems -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3
- [PWE3] CEP IESG comments Ron Cohen
- Re: [PWE3] CEP IESG comments Carlos Pignataro
- RE: [PWE3] CEP IESG comments Ron Cohen
- Re: [PWE3] CEP IESG comments Stewart Bryant
- Re: [PWE3] CEP IESG comments Andrew G. Malis