My comment about draft-shmutzer-pals-ple

As discussed earlier with Christian Schmutzer herewith some of the findings/concerns on version 3 of the PLE draft: 

@4.2.1 10G/25G BASE-R 
the RDI behavior is not clearly defined. Is that also NSP responsibility? If so, this may require rate-adaptation. 
similar for LPI. I believe this rfc could safely state that LPI is not supported by NSP and thus not supported over PLE links. 

@7.2.2 CE-bound Decapsulation Behavior 
For some client types (e.g. 10GBase-R) the AA pattern is not the physical layer pattern since it is scrambled afterwards; this means that care must be taken that AA is not meaningful content. For 10GBase-R signals I think this will lead to false block-lock. 
S ome circuit types apply scrambling at the CE bound side to ensure clock recovery, relying on the scrambling for clock-recovery seems to make more sense? 
Instead of using 0xaa another option would be to use the OTN defined G-AIS which has the same benefits. 

The "native Fault Indication Sequence" may be larger than a single packet. To ensure interoperability a definition is needed how this is handled (startover with each packet, startover @ each transition from L==0 to L==1) 

@7.3 PLE Performance Monitoring 
This section introduces a second (configurable) level of degredation (7.2.2 has DEG:=PLR>15%) to identify SES. This appears to be an overcomplication. 

Regards, 

Erik van Veelen 
Network Consultant and Systems Architect 
AimValley B.V. 
[ https://www.linkedin.com/in/erikvanveelen/ | Erik van Veelen ] 
Utrechtseweg 38, 1213 TV Hilversum, The Netherlands 
Tel: +31 35 689 1929 
AimValley certificate [ http://www.aimvalley.com/aimvalley-ca-certificate-2007.crt | http://www.aimvalley.com/aimvalley-ca-certificate-2007.crt ]

_______________________________________________
Pals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pals