RE: TDM over L2TPv3

Carlos,
Thank you for a very detailed review.

Please see some tentative answers inline below.

Hopefully they will be helpful.

Sharon,
I would appreciate your feedback as well.

Regards,
                      Sasha
-----Original Message-----
From: Carlos Pignataro [mailto:[email protected]] 
Sent: Thursday, August 02, 2007 11:45 PM
To: Sasha Vainshtein; Sharon Galtzur
Cc: l2tpext mailing list
Subject: TDM over L2TPv3

Please find some review comments on draft-ieft-l2tpext-tdm-03

All, please note that there was a typo in the filename of early versions
of this draft, as draft-ieft-l2tpext-tdm. We had this fixed through the
Secretariat, and the current version -03 has been corrected
(s/ieft/ietf/). Please use the second filename/link onwards (the first
one for the rev history):
http://tools.ietf.org/wg/l2tpext/draft-ieft-l2tpext-tdm/
http://tools.ietf.org/wg/l2tpext/draft-ietf-l2tpext-tdm/
                                         ^^

More substantive:
================

2. L2TP Extension
...
   [PWE3-CESoPSN] and [RFC4553] describe how to transfer the End Point
   status via the data plane. This is therefore RECOMMENDED to not use
   the Set-Link-Info (SLI) described in [RFC3931].

Is the recommendation not to use "Set-Link-Info (SLI)" message, or not
to use the "Circuit Status AVP in Set-Link-Info (SLI)"?
[Sasha] The former (i.e. not to use the SLI message to avoid possible
contention between the AC status conveyed inband (using L bit in
the CW) and via the control plane.

Please note that the Circuit Status AVP is a MUST for ICRQ/ICRP in
RFC3931, and that should probably be clarified as well 
(i.e., what does the Circuit Status mean in ICRQ/ICRP for TDM PWs). 
[Sasha] It should be always sent as "New/Active"in and ignored upon
reception.

Additionally, the RFC2119 keyword is "NOT RECOMMENDED" instead of
"RECOMMENDED to not"
[Sasha] Will change.
---

2.1 TDM PW AVP (ICRQ, OCRQ)
...
   Bit Rate is defined in [RFC4446]. Its usage for all types of TDM PWs
...
   CEP/TDM Payload Bytes has been defined in [RFC4446]. It can be used

Are the "TDM Payload Bytes" and "TDM Bit-Rate" defined in RFC4446?
RFC4446 seems to assign their parameter id number for the Interface
Parameters Sub-TLV, 
but not define them. Are these two actually defined in
draft-ietf-pwe3-tdm-control-protocol-extensi-03, 
Sections 3.1 and 3.2 (and in rfc4842 Sections 12.1 and 12.2 for CEP)?


---

2.1 TDM PW AVP (ICRQ, OCRQ)
...
   Bit Rate is defined in [RFC4446]. Its usage for all types of TDM PWs

I think it would help with clarity to explicitly mention that the Bit
Rate is specified in units of 64kbps/DS0s, 
even if the definition is a pointer to a normative reference. Also, the
place where they are actually defined (which appears to be
draft-ietf-pwe3-tdm-control-protocol-extensi-03) should likely be
normatively referenced, since it defines the syntax and semantics of the
fields.

[Sasha] l can use draft-ietf-pwe3-tdm-control-protocol-extensi-03 as a
reference both for Bit-rate and Payload Bytes.
But may be it is worth copying the relevant text (with all the
clarifications) and hence making this draft an informative reference?
---

2.4 Changes in the Session Connection AVPs ...
   TDM pseudowires use their own control word.  Therefore the L2-
   Specific Sublayer AVP MUST either be omitted or set to zero.

Does this imply that TDM PWs cannot use PW Frag and VCCV, which use bits
in the L2-Specific Sublayer? It seems not:
Frag: The SAToP CW and the CESoPSN CW both seem to contain the two "FRG"
bits, so this could be clarified in this paragraph.
[Sasha] There is no PW fragmentation for TDM PWs in the usual sense
(i.e. fragmentation due to insufficient Path MTU).
SAToP always keeps the FRG bits set to 0. CESoPSN uses these bits for
one CESoPSN mode only, and their usage
is not exactly traditional also.

VCCV: Both rfc4553 and draft-ietf-pwe3-cesopsn say something like:
   An ACH is needed if the state of
   the SAToP PW is being monitored using Virtual Circuit Connectivity
   Verification [PWE3-VCCV].
So basically the SAToP/CESoPSN CW is used as the L2SS. I think it would
help to mention this. 
[Sasha] Shall mention it.
Or alternatively, would it be an option to define the SAToP/CESoPSN CW
as the L2SS (with a new L2SS enumeration value for the L2SS AVP), and
have a MUST be signaled? Maybe it's too late for this?
[Sasha] I think it is too late for that...

---

3. Creation of the TDM Pseudowire Session ...
   5. If one side can send RTP header but not with the requested
      timestamp clock frequency, the connection will be rejected with
      return code RC-TBD-1 and error code EC-TBD-5.

What happens when the two sides differ in the timestamping mode
(absolute or differential)
[Sasha] Will add a new error code.
---

Security Considerations

   There are no additional security considerations on top of the ones
   discussed in [RFC3931]

Do the additional security considerations listed in rfc4553 and CESoPSN
apply?
[Sasha] An interesting point. This draft only defines the control plane
of the TDM PWs, not their data plane.
And 3931 provides sufficient security for that.

IMHO security considerations of the SAToP and CESoPSN drafts deal with
the data plane.
E.g.,  SAToP mentions that TDM PWs
<quote>
	share susceptibility to a number of pseudowire-layer
	attacks and will use whatever mechanisms for confidentiality,
	integrity, and authentication are developed for general PWs
<end quote>

But it seems to be out of context of THIS draft... 
Maybe we should ask Mark?

---

Informative references

   [PWE3-CESoPSN] A. Vainshtein et al, Structure-aware TDM Circuit
                  Emulation Service over Packet Switched Network
                  (CESoPSN), Work in progress, May 2006, draft-ietf-
                  pwe3-cesopsn-07.txt

   [RFC4553]   A. Vainshtein, Y. Stein, Structure-Agnostic TDM over
                  Packet (SAToP), RFC 4553, June 2006

and
2. L2TP Extension
...
   [PWE3-CESoPSN] and [RFC4553] describe how to transfer the End Point
   status via the data plane.
...
2.2 RTP AVP (ICRQ, OCRQ, ICRP, OCRP)
...
   This AVP MUST appear if and only if the RTP header is used in the TDM
   pseudowire encapsulation. This AVP MAY be hidden (the H bit MAY be 0
...
   The C bit indicates the ordering of the RTP header and the control
   word as following:
...
2.4 Changes in the Session Connection AVPs ...
   TDM pseudowires use their own control word.  Therefore the L2-
   Specific Sublayer AVP MUST either be omitted or set to zero.

   TDM pseudowires use their own sequencing.  Therefore the Data
   Sequencing AVP MUST either be omitted or set to zero.


This document (draft-ietf-l2tpext-tdm-03) does not define or explicitly
depicts the dataplane encapsulation for TDM PWs over L2TPv3. 
Instead, it relies on the definition of RFC4553 (for SAToP) and
draft-ietf-pwe3-cesopsn (for CESoPSN), and cites those two. 
Since the SAToP/CESoPSN references are needed to implement TDM PWs (as
they define the PW encapsulation), 
it seems to me that they should be Normative references rather than
Informative references.
http://www.ietf.org/IESG/STATEMENTS/iesg-statement-normative-informative
-references.txt
One issue here however is that the Intended Status of "TDM over L2TPv3"
is Proposed Standard, and that of CESoPSN is Informational, resulting in
a downref. 
But are those defining the PW encapsulation that TDM PWs need to use?

[Sasha] It is because of the perceived downref problem that we've set
SAToP and CESoPSN Documents to
Informative references. I would appreciate any advice in this regard.

Further, I think it would help significantly with clarity if the "TDM
over L2TPv3" document points 
to the specific sections and figures in those citations 
(e.g., Figure 2b, Section 4.3 and Appendix A of RFC4553; Figure 1c., 
Section 4.1 and Appendix C of [PWE3-CESoPSN]) where the encapsulation
is depicted/defined.

[Sasha] Will do.

More editorial:
==============

Abstract

   This document defines extensions to the Layer Two Tunneling Protocol
   (L2TP) for support of structure-agnostic [RFC4553] and structure-
   aware [PWE3-CESoPSN] pseudowires.

There shouldn't be citations in the Abstract.
http://www.ietf.org/ID-Checklist.html#anchor6
[Sasha] Will do.
---

2.1 TDM PW AVP (ICRQ, OCRQ)
...
  1) For Structure-agnostic emulation any value of the payload bytes can
     be specified.
  2) For CESoPSN PWs:
     a) The specified value MUST be an integer multiple of number of
         DS0 channels in the corresponding attachment circuit.

For consistency with previous paragraph in this section, I think that
numbered bullet "2)" could say "For Structure-aware" instead of "For
CESoPSN PWs".
[Sasha] Not sure: as you know the PWE3 WG has advanced two drafts for
Informational on structure-aware TDM PWs.
This draft deals only with CESoPSN since, AFASIK, the authors of the
alternative draft have not been interested in L2TPv3.
---

2.2 RTP AVP (ICRQ, OCRQ, ICRP, OCRP)
...
   This AVP MUST appear if and only if the RTP header is used in the TDM
   pseudowire encapsulation.

Nit: Shouldn't the logic in this sentence be inverse (the AVP signaling
what the dataplane needs to do)? Like "Presence of this AVP indicates
that the RTP header is used in the encapsulation".

[Sasha] OK.

---

2.2 RTP AVP (ICRQ, OCRQ, ICRP, OCRP)
...
   The D bit indicates the timestamping mode (absolute or differential)
   in the RTP header. These modes are described in, e.g., in [RFC4553],
   Section 4.3.2. If the D bit is set to 1 then the differential

There's an extraneous "e.g., ".

[Sasha] Will remove.
---

2.2 RTP AVP (ICRQ, OCRQ, ICRP, OCRP)
...
   misconnections. Since L2TP provides an alternative security mechanism
   via the cookies, if the cookie length is larger then zero the SSRC
   SHOULD be zero.

Typo: s/then/than/.
[Sasha] OK
Also, this Section 2.2 does not define the "Reserved" field (e.g., MBZ
sending, ignored receiving)

[Sasha] OK.
---

3. Creation of the TDM Pseudowire Session


   When LCCE wants to open a Session for TDM PW it MUST include the TDM

Would it be needed to narrow down when the LCCE actually wants to open
the session? e.g., when configured, When admin up or When out of alarm.

[Sasha] I'll check vs. already published RFCs and align the wording.

---

2.2 RTP AVP (ICRQ, OCRQ, ICRP, OCRP)
...
   used.  Differential mode can be used only if both sides use RTP and
   use differential time stamping.
...
3. Creation of the TDM Pseudowire Session ...
   PW AVP (in any case) and the RTP AVP (if RTP and only if the RTP
   header is used) in the ICRQ or OCRQ message.  The LCCE peer must ...
   derived from the RTP AVP (if it exist).  If the peer agrees with the
   TDM AVP it will send an appropriate ICRP or OCRP message with the
   matching RTP AVP (if needed). The Initiator need to validate that it
...
   4. If one side cannot send RTP header requested by the other side,
      the connection will be rejected with return code RC-TBD-1 and
      error code EC-TBD-4.

The four paragraphs listed above confused me a bit regarding two things:
Can the RTP usage be unidirectional, or does it need to match? 
Does the presence of the RTP AVP means that the sending of the AVP wants
to send the RTP header in the dataplane, 
or that it requests the peer sends the RTP header?
[Sasha] Both SAToP and CESoPSN define RTP usage as bi-directional. So
the presence of RTP AVP means 
that the sender both will transmit RTP and will expect it from the peer.
---

4. IANA Considerations
...
   PW types listed in Section 2.1 above. It is RECOMMENDED to use the
   same values as defined in [RFC4446].

Could you please list them here as well, with suggested values, and
clarifying that these are "L2TPv3 PW Types" 
from http://www.iana.org/assignments/l2tp-parameters
[Sasha] will do. Luckily these values have not been used yet.
---
4. IANA Considerations
...
   New return codes and error codes:

Could you please add/clarify that the "Result Code values" are "for the
CDN message"?
[Sasha] OK

Thanks,

--
--Carlos Pignataro.
Escalation RTP - cisco Systems