Regards,
Joe
-----Original Message-----
From: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] 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
pwe3 at ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3
_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3