Re: [Pals] Questions regarding draft-schmutzer-bess-ple-00

["Christian Schmutzer (cschmutz)" <[e-mail]>]

Hi Alexander,

Thank you very much for your interest in our draft and your review!

Please find our comments inline with [cs]

Regards
Christian

On 12.07.2020, at 12:22, Alexander Vainshtein <[e-mail]<mailto:[e-mail]>> wrote:

Hi all,
I have a few questions regarding draft-schmutzer-bess-ple-00<https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-ple-00> .

Q1: Clock quality for Synchronous Ethernet (SyncE)
Section 1 of the draft mentions “two Ethernet connected CEs and the need for synchronous Ethernet operation between them” as one of the possible applications of the technology defined in the draft.
I have doubts regarding validity of this solution based on the following:

·         SyncE includes a mechanism for transfer of information about the quality of the clock carried as the bit-stream clock using Ethernet Synchronization Messages (ESMC)

·         My reading of the draft suggests that these messages will be transparently carried by the PLE service between the pair of CEs, so that each CE will receive ESMC messages transmitted by its remote peer without any changes, i.e. each of them will assume that the quality of the clock it receives from the recovered bit-stream is the same as the quality of the original bit-stream

·         However, even with the differential clock technique defined in the draft, preservation of the original clock quality is not guaranteed automatically.
Any comments on this point would be highly appreciated.

[cs] you have a fair point, that we should be more specific under which assumptions PLE can be used to transfer the synchronisation.

Two considerations:

  1.  We could mention that the common clock should be of higher or identical quality compared to the transported client clock quality
  2.  We could add specific quality targets as has been done in the past for TSoP (https://tools.ietf.org/html/draft-manhoudt-pwe3-tsop-08#section-6.2.2). For ethernet we would point to ITU G.8262


Q2: ODUk Frame Boundary Alignment
Section 5.2 of the draft says that, in the case of a PLE that carries ODUk frames, “The used payload size has to be a integer fraction of the full 15296 bytes to allow for ODUk frame alignment” and “The two FRG bits in the PLE control word MUST be used to indicate first, intermediate, and last fragment of the encapsulated ODUk frame”. However the draft does not explicitly state that the first octet of the of the ODUk frame MUST be the first octet of the first fragment.

[cs] agreed, we will add further clarification into the draft



Q3: Bit Order in PLE Encapsulation
I do not see any analog to the following statement copied below from Section 5.1 of RTV 4553 (SAtoP):
   SAToP uses the following ordering for packetization of the TDM data:

      o  The order of the payload bytes corresponds to their order on
         the attachment circuit.

      o  Consecutive bits coming from the attachment circuit fill each
         payload byte starting from most significant bit to least
         significant.
I think that an explicit statement regarding the bit order in the PLE encapsulation is mandatory in order to guarantee interoperability of different implementations.

[cs] also agree, we will add a similar statement to avoid interoperability issues of implementations


Hopefully these notes will be useful.

Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>



________________________________
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
________________________________