[PWE3] comments on draft-ietf-pwe3-tdm-control-protocol-extensi-04.txt

[Stewart Bryant <[e-mail]>]

I have a number of LC comments on

draft-ietf-pwe3-tdm-control-protocol-extensi-04.txt

 
Regards

Stewart

 

   
 Abstract  
   
 This document defines extension to the PWE3 control protocol [RFC4447]
 and PWE3 IANA allocations [RFC4446] required for setup of  
 TDM pseudo wires.
 
SB> Title and abstract need to have MPLS in them since you later
SB> set the scope to exclude L2TPv3
 
 
 1. Introduction  
   
 Status of attachment circuits of TDM PWs can be exchanged between the  
 terminating PEs using the mechanism defined in [RFC4447] without any
 changes. However, usage of these mechanisms with TDM PWs is NOT
 RECOMMENDED since indication of status of the TDM attachment circuits
 is carried in-band in the data plane.

SB> I am not sure what we need to say here, but RFC4447 signaling
SB> is a proposal for PW protection. In those circumstances we
SB> then have a potential need for two mechanisms.
SB>
SB> Does anyone have any thoughts on whether we end up with
SB> some sort of conflict?
          
 
 2. PW FEC for Setup of TDM PWs  

     
 The PW Types for TDM PWs are allocated in [RFC4446] as follows:  
   
 o  0x0011  Structure-agnostic E1 over Packet [RFC4553]   
 o  0x0012  Structure-agnostic T1 (DS1) over Packet [RFC4553]  
 o  0x0013  Structure-agnostic E3 over Packet [RFC4553]  
 o  0x0014  Structure-agnostic T3 (DS3) over Packet [RFC4553]  
 o  0x0015  CESoPSN basic mode [PWE3-CESoPSN]  
 o  0x0016  TDMoIP AAL1 mode [PWE3-TDMoIP]  
 o  0x0017  CESoPSN TDM with CAS [PWE3-CESoPSN]  
 o  0x0018  TDMoIP AAL2 mode [PWE3-TDMoIP]  

SB> Does it add value to copy the registry entries here?
SB> If not - then this is really just an opportunity to make a mistake.
   
 
 3. Interface Parameters for TDM PWs
    3.1. CEP/TDM Payload Bytes (0x04)
 
 This parameter is used for setup of all SAToP and CESoPSN PWs (i.e. 
PW            
 types 0x0011, 0x0012, 0x0013, 0x0014, 0x0015 and 0x0017) and employs
 the following semantics:  

SB> Would it have been to say - in all cases except TDMoIP?
   
 
 2. Presence of this parameter in the PWId FEC or in the Interface
     Parameters Field TLV is OPTIONAL. If this parameter is omitted,
     default payload size defined for the corresponding service (see
     [RFC4553], [PWE3-CESoPSN]) MUST be assumed  

SB> This will clearly work, but I wonder if it is better to always
SB> signal the parameter. Having default increase rather than
SB> reduces the number of lines of code, and apart from saving
SB> a tiny number of bytes of signalling msg, does not seem
SB> to add much value.


SB> I think that you need some text between 3.0 main title
SB> and 3.1 in particular to explain the significance of the
SB> hex in the title.
 
    3.2. CEP/TDM Bit-Rate (0x07)
 
 This interface parameter represents the bit-rate of the TDM service in  
 multiples of the "basic" 64 Kbit/s rate. Its usage for all types of TDM  
 PWs assumes the following semantics:  
   
 1. This interface parameter MAY be omitted if the attachment circuit  
     bit-rate can be unambiguously derived from the PW Type (i.e. for  
     structure-agnostic emulation of E1, E3 and T3 circuits). If this  
     value is omitted for the structure-agnostic emulation of T1 PW  
     Type, the basic emulation mode MUST be assumed.  

SB> Again I wonder if it is better to always send?
SB> Code vs bytes during setup?
SB>
SB> Can we take this is a generic question for all default cases in
SB> the rest of the document?
 
 
  4. A TDM PW encapsulation MUST either use or not use RTP in both
     directions.  

SB> There must be some clearer way to say the above.
 
     
 8. Security Considerations
 
 This draft does not have any additional impact on security of PWs above
 that of basic LDP setup of PWs.

SB> Should reference RFC4446 to say it's the same.


_______________________________________________
pwe3 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pwe3