Re: 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 <[email protected]<mailto:[email protected]>> 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 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.

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

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

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

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

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)

[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 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-oduk-otn-services


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

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


I am looking forward to working with you on exact wording where changes are needed relative to this discussion. But as of now, would you agree that those points are not preventing a WG adoption of this draft?

Regards
Christian

Regards,

Erik van Veelen
Network Consultant and Systems Architect
AimValley B.V.
Erik van Veelen<https://www.linkedin.com/in/erikvanveelen/>
Utrechtseweg 38, 1213 TV Hilversum, The Netherlands
Tel: +31 35 689 1929
AimValley certificate http://www.aimvalley.com/aimvalley-ca-certificate-2007.crt
_______________________________________________
Pals mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/pals

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