[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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
pwe3 at ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3