[L2tpext] RE: [PWE3] CEP IESG comments

["Ron Cohen" <[e-mail]>]

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:[e-mail]] 
Sent: Monday, November 13, 2006 4:52 AM
To: Ron Cohen
Cc: [e-mail]
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
> [e-mail]
> 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.


_______________________________________________
L2tpext mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l2tpext