Subject: RE: [PWE3] draft-ietf-pwe3-tdmoip-04.txt - comments

From: "Joe Merritt" <[email-masked]>
Date: Fri, 24 Mar 2006 11:03:27 -0500

PWE3 WG et al,

In looking at page 6 section 2 of draft-ietf-pwe3-tdmoip-04.txt it
states:

  " RES The first nibble of the control word MUST be set to zero when
the
      PSN is MPLS, in order to ensure that the packet does not alias an
      IP packet when forwarding devices perform deep packet inspection."

In looking at Appendix D it states:

"D.2  OAM Packet Format

   When using inband performance monitoring, additional packets are sent
   using the same PW label.  These packets are identified by having
   their first nibble equal to 0001, and must be separated from TDM data
   packets before further processing of the control word."

Based on the text it forces any implementation that uses MPLS as the PSN
must setup a separate Pseudowire for each TDMoIP Pseudowire to
communicate OAM information. 

Can someone please explain why this has been allowed? For MPLS
implementations why isn't the requirement to either disable the optional
deep packet inspection feature for LSPs that carry Pseudowire traffic
using inband OAM or allow the optional deep packet inspection feature
provided that OAM is done out-of-band.

Regards,
Joe

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stewart Bryant
Sent: Friday, November 04, 2005 3:00 PM
To: Yaakov Stein
Cc: pwe3
Subject: [PWE3] draft-ietf-pwe3-tdmoip-04.txt - comments

Yaakov

I was taking a final look at draft-ietf-pwe3-tdmoip-04.txt to see if it
was ready to send to the IESG, and had a number of comments that I think
need a look at first.

- Stewart

-----------

Abstract

    This document describes methods for structure-aware transport of TDM
    traffic over packet switched networks using pseudowires.

SB - Need to expand TDM in the abstract on the next pass same
      in the intro.

==============

SB - Should probably move to using RFC number as the reference
      identifiers where available to make it easier for the reader.

==============

    The 32-bit control word MUST appear in every TDMoIP packet.  Its
    format is depicted in the following figure.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  RES  |L|R| M |RES|  Length   |         Sequence Number       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    RES The first nibble of the control word MUST be set to zero when
the
       PSN is MPLS, in order to ensure that the packet does not alias an
       IP packet when forwarding devices perform deep packet inspection.
       For other PSNs the first nibble SHOULD be set to zero.

       In earlier
       versions of TDMoIP this field contained a format identifier that
       was optionally used to specify the payload format.

SB - Does this add value or confusion?

=============

       When L is set (indicating invalid TDM data) the M field is used
as
       follows:

        0 0  indicates a TDM defect that should trigger conditioning
             or AIS generation by the TDM-bound gateway.
        0 1  indicates idle TDM data that should not trigger any alarm.
             If the payload has been suppressed then the preconfigured
             idle code should be generated at egress.
        1 0  indicates corrupted but potentially recoverable TDM data.
        1 1  reserved.

SB - do we need to inidate the mapping of these M bits to the CW above?
      it's implicit rather than explicit?

===============

SB - The definitions is section 3.1 are absolutely fine - but I wonder
      what review comments we will get as a result of the detailed
      definition of the IP (an UDP) headers rather than just a simple
      pointer to RFC791 etc?

      Same comment really applies to MPLS and L2TPv3.

      It's really a matter of clutter and maybe review questions
      about whether we really need to define all this stuff that
      is the currency of the IETF. Maybe we - the PWE3 WG don't
      really understand IP etc etc.

===============

    TTL (8 bits) MPLS Time to live.  Should be set to 2 for the PW
label.

SB - That restriction was removed a long time ago because it
      caused problems with some equipments.

================

3.4  Ethernet

SB - I am not convinced about the need for the detail in this section
      IP and MPLS over Ethernet are well known.

===============

    Since native TDM is always constant bit-rate, why is a variable rate
    adaptation needed?

SB - This is the first question I have ever seen in a protocol
definition :)

===============

    order to retain TDM timing.  Packets with incorrect serial numbers
or
    other detectable header errors MUST be discarded.  Packets arriving
    in incorrect order SHOULD be swapped.  Processing of filler packets

SB - What do you mean by incorrect serial numbers - out of order
      pkts have incorrect serial numbers - also I think that you
      mean re-ordered rather than swapped - or can there only be
      two packets in flight at any time?

=============

7.  Security Considerations

    TDMoIP does not enhance or detract from the security performance of
    the underlying PSN, rather it relies upon the PSN's mechanisms for
    encryption, integrity, and authentication whenever required.  The
    level of security provided may be less than that of a native TDM
    service.

    TDMoIP does not provide protection against malicious users utilizing
    snooping or packet injection during setup or operation.  However,
    random initialization of sequence numbers makes known-plaintext
    attacks on link encryption methods more difficult.

    PW labels SHOULD be selected in an unpredictable manner rather than
    sequentially or otherwise in order to deter session hijacking.  When
    using L2TPv3, randomly selected cookies MAY be used to validate
    circuit origin.  Sequence numbers SHOULD be randomly initialized in
    order to increase the difficulty of decrypting based on packet
    headers.

SB - I suspect that the Security AD will want more discussion. You
      might be able to prevent some of that by making a reference to
      RFC-3985.

8.  IANA Considerations

    When used with UDP/IP the destination port number MUST be set to
    0x085E (2142), the user port number which has been assigned by IANA
    to TDMoIP.

SB - This is not an IANA action - they have already done it.

    When inband TDMoIP OAM is used (see Appendix D.2), a value will need
    to be allocated by IANA from the PW Associated Channel Type registry
    for inband TDMoIP OAM.

SB - Might want to put in a cross ref to CW, as that causes the
      registry to get created - just to make sure everyone is on the
      same page.

================

Appendix B.  AAL1 Review

SB - Is this text normative?
      Same for Appendix C
==========

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 24 Mar 2006 13:15:16 -0500

> provided that OAM is done out-of-band.

	I don't see how the text above forces you
to set up a VCCV channel for every PW.  You are allowed
to setup as many as you see fit. It might help to add
some text clarifying this in this context, but I believe
that the VCCV draft itself makes this clear.

	One suggestion I might make to simplify this, might
be to simply remove this section, or to just refer to the
VCCV draft therein.  There isn't anything new specified in
that paragraph other than "Use VCCV [ref] for OAM on
TDM PWs."  The packet formats that are legal for using
VCCV are defined in VCCV draft and the new PW CW RFC.

	--Tom