Mention MPLS in the title and abstract to match exclusion of L2TPv3.
Accepted.
Control Protocol Extensions for Setup of TDM Pseudowires in MPLS Networks
This document defines extension to the PWE3 control protocol [RFC4447]
and PWE3 IANA allocations [RFC4446] required for setup of
TDM pseudo wires in MPLS networks.
Usage of the PW Status messages for carrying the status of Attachment Circuits of TDM PWs is NOT RECOMMENDED. This may end in conflict with known proposals to use these messages for PW protection.
Leave the text "as is".
The status of the ACs is adequately carried across the PSN by the flags in the TDM PW Control Word. Having two different mechanisms to carry this across can only result in racing.At the same time, the PW protection mechanisms proposed in draft-muley-dutta-pwe3-redundancy-bit-01.txt and/ or draft-muley-pwe3-redundancy-01.txt require some dual-homing protocol on Attachment Circuits. There is no such protocol for TDM ACs.
TDM PW type values are explicitly listed in the text in spite of being already listed in the appropriate IANA registry. Looks like an opportunity for errors.
Leave the text "as is".
Simplifies reading of the document by the implementers. And the check vs. the registry must be only done once.
CEP/TDM Payload Bytes parameter is described as being used with all SAToP and CESoPSN PWs. Suggestion to say "for all except TDMoIP".
Leave the text "as is".
There are two different TDMoIP PW types; and positive thinking looks preferable to the authors.
Presence of some interface parameters is defined as OPTIONAL, and default values of these parameters (as defined in the appropriate encapsulation documents) must be assumed if they are omitted. While this definitely would work, it looks like more complicated code vs. less bytes sent during setup...
Leave the text "as is".
A clearer way to say that "a TDM PW encapsulation MUST either use or not use RTP in both directions" is required.
Accepted.
Use or non-use of RTP MUST match in the two directions.
Add a reference to RFC 4446 in the Security Considerations section to say that it is the same
Accepted. But it probably should 4447.
This draft does not have any additional impact on security of PWs above
that of basic LDP setup of PWs as defined in [RFC4447].
Add (and use) an Informative Reference to draft-ietf-l2tpext-tdm-xx
Leave the references "as is" in this draft, but include a reference to this draft in draft-ietf-l2tpext-tdm-xx
If possible, explain the reasons for skipping some values in the enumerations for such parameters as TDMoIP AAL1 mode and TDMoIP AAL2 Option.
Leave "as is" (no special reasons, this is how it has been implemented).
Is it the need to specify AAL2 encoding types and, in the case of G.711 encoding, A-law or mu-law?
No need to specify A-law or mu-law, and specific encoding are out of scope; the two sides MUST agree on them.
Encoding specifies native signal processing performed on the payload. When no native signal processing is performed (i.e. G.711 encoding) this field MUST be zero. Other specific values that can be used in this field are beyond the scope of this specification, but the two directions MUST match for the PW setup to succeed.
Different names for different unused/reserved bit fields in the TDM Options structure (F and X). One name would suffice.
Leave the text "as is". It is convenient for some implementations to treat these fields differently.
The suggested Interface Parameter ID value for AAL1 options overlaps with a value already assigned in the IANA registry.
Shift the suggested Interface Parameter ID values for AAL1 and AAL2 options to avoid the overlap.
Length of some of the new Interface Parameters has not been defined.
Add a new sub-section at the beginning of Section 3 listing all the relevant Interface Parameters with their IDs (assigned or suggested) and length. Remove the IDs from the sections describing the syntax and semantics of these parameters.
_______________________________________________ pwe3 mailing list pwe3 at ietf.org https://www1.ietf.org/mailman/listinfo/pwe3