[L2tpext] 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)"? 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). Additionally, the RFC2119 keyword is
"NOT RECOMMENDED" instead of "RECOMMENDED to not"

---

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.

---

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.
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. 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?

---

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)

---

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?

---

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?

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.

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

---

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".

---

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".

---

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., ".

---

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/.
Also, this Section 2.2 does not define the "Reserved" field (e.g., MBZ
sending, ignored receiving)

---

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.

---

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?

---

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

---
4. IANA Considerations
...
   New return codes and error codes:

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

Thanks,

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

_______________________________________________
L2tpext mailing list
L2tpext@ietf.org
https://www1.ietf.org/mailman/listinfo/l2tpext