[L2tpext] Re: TDM over L2TPv3

[Carlos Pignataro <[e-mail]>]

Sasha,

Many thanks for the prompt reply, your answers are helpful. Please see
inline some follow-ups.

On 8/5/2007 11:01 AM, Sasha Vainshtein said the following:
> 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:[e-mail]] 
> 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.

In that case, isn't the latter? The AC status is conveyed in the
"Circuit Status AVP" (Active bit) sent in an SLI, and the SLI message
might (potentially) include other AVPs (and not the Circuit Status).

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

OK. Thanks. Could that be clarified?

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

I'd prefer to not duplicate text and keep a single source for the info
if possible. However, if draft-ietf-pwe3-tdm-control-protocol-extensi-03
is too LDP/RFC4447-specific, then I think that copying the text would be
a good alternative.


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

OK.

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

Thanks.

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

I see your point. However, would it make sense to include some of the
L2TPv3-specific mechanisms? For example, should there be recommendations
whether to signal a Cookie or not, and if so what size?

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

I would think that the category of the reference should be based on the
normative vs. informative definition. If there is a downref when the
document progresses, it should be mentioned in IETF Last Call (as per
RFC 3967). One thing that I was wondering is what category those
reference should actually be since you said "This draft only defines the
control plane of the TDM PWs, not their data plane", but some of those
dataplane characteristics are signaled, so might still be normative.

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

Thanks.

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

OK.

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

So should then the previous bullet:

  2) For all kinds of structure-aware emulation, this parameter MUST be

say "For CESoPSN"?

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

Thanks. I'll skip some of the items that are in agreement.

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

Thanks.

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

OK. Could that please be explicitly stated? It might be already and I
may have missed it.

> ---
> 
> 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 again for your comments !

--Carlos.

> 
> Thanks,
> 
> --
> --Carlos Pignataro.
> Escalation RTP - cisco Systems
> 

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



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