Re: [Pals] My comment about draft-shmutzer-pals-ple

[Erik van Veelen <[e-mail]>]

Hi Christian, 

see inline (marked [HCvV]) 

Regards, 
Erik 

Van: "cschmutz" <[e-mail]> 
Aan: "Erik van Veelen" <[e-mail]> 
Cc: "cschmutz" <[e-mail]>, "pals" <[e-mail]> 
Verzonden: Donderdag 4 mei 2023 15:58:31 
Onderwerp: Re: [Pals] My comment about draft-shmutzer-pals-ple 

Hi Erik, 

Thank you for spending time in reviewing the PLE draft! Let me try to comment as appropriate inline via [cs] 




On 28.04.2023, at 11:21, Erik van Veelen < [ mailto:[e-mail] | [e-mail] ] > wrote: 

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. 




[cs] Backward/remote defect indication (BDI/RDI) at the PLE (server) layer is the responsibility of the IWF by setting the R bit in the PLE control word. Bullet [ https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-03#section-7.2.1-2.6 | https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-03#section-7.2.1-2.6 ] in the section “PSN-bound encapsulation behaviour” is trying to cover the expected operation. 

For backward/remote defect indication (BDI/RDI) at the ethernet (client) layer PLE is transparent/agnostic per design, similar to RFC4553 SAToP for PDH interfaces. Ethernet remote fault signalling using RF is a function of IEEEs reconciliation sublayer between PHY and MAC layer (see 802.3 clause 46.3.4), PLE operates below that and will simply pass along respective control code blocks. 

[HCvV] understood. 

BQ_BEGIN

similar for LPI. I believe this rfc could safely state that LPI is not supported by NSP and thus not supported over PLE links. 

BQ_END


[cs] Good catch on EEE/LPI, we indeed should add some text to clarify this aspect. Per 802.3 clause 78 I agree that we say “LPI (deep sleep only) is not supported for 1GE and 10GE”. For 25GE and above (BASE-R) where only LPI fast wake mode applies PLE is again agnostic because /LI/ control code blocks are sent and PLE will simply pass them along. 
[HCvV] agreed. 


BQ_BEGIN

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

BQ_END


[cs] Not sure I understand your concerns with regards to the 0xAA pattern. Let me explain in other words what is covered in the draft so far: 



    * For ethernet services the replacement pattern of 0xAA inserted by the IWF is a sequence of alternating 0s and 1s and hence we maintain PCS code sync in the NSP. You are right this will lead to invalid PCS code blocks, but as per [ https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-03#section-4.2.1-7 | https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-03#section-4.2.1-7 ] the CE-bound NSP function will insert /E/ code blocks honouring boundaries before scrambling. 
    * For ODUk and SONET/SDH the pattern of 0xAA will simply lead to bit errors (as expected) and not interfere with clock synchronization. 
[HCvV] I think you got my concern. I overlooked the CE-bound NSPs responsibility to interpret the data received from IWF 

BQ_BEGIN

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) 

BQ_END


[cs] Good point about the text for the native fault signal insertion in [ https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-03#section-5.2.1-5.1 | https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-03#section-5.2.1-5.1 ] being somewhat vague and agree on this being service specific. 


    * For ethernet and fibre channel for example the fault indication signal being a PCS code block is always smaller than the PLE packet, so nothing to worry about. 
    * For SONET/SDH and OTN indeed the client frame is larger than a single PLE packet. 

We could adjust the below sentences to say something like “… the CE-bound NSP function is responsible for generating / stop generating the maintenance signal at the next client frame boundary" 
[ https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-03#name-sonet-sdh-services | https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-03#name-sonet-sdh-services ] 
[ https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-03#name-oduk-otn-services | https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple-03#name-oduk-otn-services ] 

[HCvV] my concern here was somewhat academic about the repetition interval of an NFS-pattern being larger than a single packets payload. When stating that this is service specific, the concern is limited to specific NFS-patterns. 
Your remark remains a valid point for SONET/SDH, OTN. Your proposed solution (start/stop at next frame boundary) is a good suggestion when the word 'next' is omitted. When a packet is lost (or has the L-bit set) the IWF must insert something regardless. Relying on the NSP to do so on the next frame-boundary is not possible. 
Awaiting the frame boundary to resume normal traffic is in my opinion 'not done': if there is customer data you forward it to the best of you ability. 
Personally I would think the best approach would be to accept that the first and last frame are errored (and may even be rejected further on due to these errors) but make the NSP align the NFS on the frame boundary (to avoid OOFs downstream), in case the NSP chooses (it's a MAY) to insert NFS: 
“… the CE-bound NSP function is responsible for generating / stop generating the maintenance signal at client frame boundaries" 

BQ_BEGIN

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

BQ_END


[cs] PLE is trying to satisfy expectations from the optical transport network world. ITU G.1563 defined SES(ETH) for ethernet networks and ITU G.1561 defined Severe Loss Block (SLB) for connection oriented services over MPLS. PLE does align with that but we defined the PM function using SHOULD. So it is an optional function, to give freedom to implementers to omit this if deemed to be unnecessary. 
[HCvV] understood. 

I am looking forward to working with you on exact wording where changes are needed relative to this discussion. 
[HCvV] see the suggestion above. 

But as of now, would you agree that those points are not preventing a WG adoption of this draft? 
[HCvV] in my opinion this draft (version 3) is mature enough to be adopted by the WG 

Regards 
Christian 


BQ_BEGIN

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: [phone] 
AimValley certificate [ http://www.aimvalley.com/aimvalley-ca-certificate-2007.crt | 
http://www.aimvalley.com/aimvalley-ca-certificate-2007.crt ] 
_______________________________________________ 
Pals mailing list 
[ mailto:[e-mail] | [e-mail] ] 
https://www.ietf.org/mailman/listinfo/pals 

BQ_END