[L2tpext] Re: [PWE3] CEP IESG comments

[Stewart Bryant <[e-mail]>]

I have seen no comments to this list on this topic, so I assume
that the WG has left the final decision to the authors.

The most conservative approach seems to me to remove the L2TPv3
text from the draft and write the L2TPv3 specific text in a
separate draft at a later time.

However I leave the final decision to the authors.

- Stewart




Ron Cohen wrote:

> 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.
> 
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

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