[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PWE3] draft-ietf-pwe3-tdmoip-04.txt - comments
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: 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