Subject: [PWE3] draft-ietf-pwe3-tdm-control-protocol-extensi-04: Summary issues raised during the WG LC

From: "Sasha Vainshtein" <[email-masked]>
Date: Wed, 7 Nov 2007 07:47:14 +0200

Hi all,
In the wake of the WG LC, Stewart and Carlos have sent their comments on
the -04 version of the draft in question to the list. 
No other comments have been received.
 
We've hold an off-the-list discussion of the issues raised that has
helped to clarify the issues and  agree on their resolution
in the -05 version of the draft. A (rather long) summary of this
discussion can be found below.
________________________________

ISSUE: 

	Mention MPLS in the title and abstract to match exclusion of
L2TPv3.

PROPOSED RESOLUTION:

	Accepted.

New title: 

	Control Protocol Extensions for Setup of TDM Pseudowires in MPLS
Networks

New abstract: 

	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.

________________________________

ISSUE:

	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.

PROPOSED RESOLUTION:

	Leave the text "as is".

AUTHORS' REASONING:

	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.

________________________________

ISSUE:

	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.

PROPOSED RESOLUTION:

	Leave the text "as is".

AUTHORS' REASONING:

	Simplifies reading of the document by the implementers. And the
check vs. the registry must be only done once.

________________________________

ISSUE:

	CEP/TDM Payload Bytes parameter is described as being used with
all SAToP and CESoPSN PWs. Suggestion to say "for all except TDMoIP".

PROPOSED RESOLUTION:

	Leave the text "as is".

AUTHORS' REASONING:

	There are two different TDMoIP PW types; and positive thinking
looks preferable to the authors.

________________________________

ISSUE:

	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...

PROPOSED RESOLUTION:

	Leave the text "as is".

AUTHORS' REASONING:

	1.	
		This is compatible with the existing implementations and
with the approved MFA 8.0.0 IA.
	2.	
		The PE that sends the PW label mapping message is not
prevented from including all the interface parameters, so there is no
additional complexity here. The PE that receives this message can
initialize all the interface parameters to defaults and then update them
from the actual values found in the received message (that you do not
find there, you do not update). This looks as a healthy approach in any
case and at least as simple as checking for presence of all the
parameters. 

________________________________

ISSUE:

	A clearer way to say that "a TDM PW encapsulation MUST either
use or not use RTP in both directions" is required.

PROPOSED RESOLUTION:

	Accepted.

Alternative text:

	Use or non-use of RTP MUST match in the two directions. 

________________________________

ISSUE:

	Add a reference to RFC 4446 in the Security Considerations
section to say that it is the same

PROPOSED RESOLUTION:

	Accepted. But it probably should 4447.

Modified text:

	This draft does not have any additional impact on security of
PWs above 
	 that of basic LDP setup of PWs as defined in [RFC4447].

________________________________

ISSUE: 

	Add (and use) an Informative Reference to
draft-ietf-l2tpext-tdm-xx

PROPOSED RESOLUTION:

	Leave the references "as is" in this draft, but include a
reference to this draft in draft-ietf-l2tpext-tdm-xx

________________________________

ISSUE:

	If possible, explain the reasons for skipping some values in the
enumerations for such parameters as  TDMoIP AAL1 mode and TDMoIP AAL2
Option.  

PROPOSED RESOLUTION:

	Leave "as is" (no special reasons, this is how it has been
implemented). 

________________________________

ISSUE:

	Is it the need to specify AAL2 encoding types and, in the case
of G.711 encoding, A-law or mu-law?

PROPOSED RESOLUTION:

	No need to specify A-law or mu-law, and specific encoding are
out of scope; the two sides MUST  agree on them. 

Modified text:

	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.

________________________________

ISSUE:

	Different names for different unused/reserved bit fields in the
TDM Options structure (F and X). One name would suffice.

PROPOSED RESOLUTION:

	Leave the text "as is".  It is convenient for some
implementations to treat these fields differently.

________________________________

ISSUE:

	The suggested Interface Parameter ID value for AAL1 options
overlaps with a value already assigned in the IANA registry.

PROPOSED RESOLUTION:

	Shift the suggested Interface Parameter ID values for AAL1 and
AAL2 options to avoid the overlap.

________________________________

ISSUE:

	Length of some of the new Interface Parameters has not been
defined.

PROPOSED RESOLUTION:

	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.

________________________________

The -05 version of the draft that resolves all these issues and fixes a
couple of typos will be submitted to the IETF later today.
Meanwhile it can be found at:
ftp://ftp.axerra.com/sasha/draft-ietf-pwe3-tdm-control-protocol-extensi-
05.txt

Regards,
              Yaakov and Sasha
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3