Re: My comment about draft-shmutzer-pals-ple
Alexander Vainshtein <[email protected]> Tue, 4 Apr 2023 05:54:07 +0000
| Newsgroups | gmane.ietf.pwe3 |
|---|---|
| Message-ID | <CO6PR03MB6290D63EE522B456A01BA17BF6939@CO6PR03MB6290.namprd03.prod.outlook.com> |
Christian, Lots of thanks for a prompt and encouraging response. Regards, Sasha From: Christian Schmutzer (cschmutz) <[email protected]> Sent: Monday, April 3, 2023 7:35 PM To: Alexander Vainshtein <[email protected]> Cc: Christian Schmutzer (cschmutz) <[email protected]>; [email protected]; Nitsan Dolev <[email protected]>; Rotem Cohen <[email protected]>; Jun Ye <[email protected]>; Luca Della Chiesa (ldellach) <[email protected]> Subject: [EXTERNAL] Re: My comment about draft-shmutzer-pals-ple Hi Alexander, No you are not missing anything, I see now where you are coming from and I agree more text explaining what is meant by “common clock” and its characteristics is needed to improve the clarity of our draft … we will take care of that in future versions of the document. Many thanks for taking the time (again) to read and commenting on our draft ! regards Christian On 31.03.2023, at 02:59, Alexander Vainshtein <[email protected]<mailto:[email protected]>> wrote: Christian hi! I have looked up the draft again, and I have not found any mention of the egress PE being “connected to a (common) clock in sync to the clock of the ingress PE without wander”. The relative network scenario described in Section 4.3.2 of RFC 4197<https://clicktime.symantec.com/15siFA6gAq8KUH5hQn9W8?h=scmB94bKEN_Xyb02FOojbRwiXAFi0DP_1gZEddU60xM=&u=https://www.rfc-editor.org/rfc/rfc4197%23section-4.3.2> to which the draft refers does not say anything about quality of the common clock available to the pair of PEs. The only mention of wander in the draft I have found is a (generic) requirement in Section 7.2.2 for the recovered clock to comply with the jitter and wander requirements that are applicable to the specific service type. But, AFAIK, these requirements always admit existence of several levels of clock quality. What, if anything, do I miss? Regards, Sasha From: Christian Schmutzer (cschmutz) <[email protected]<mailto:[email protected]>> Sent: Thursday, March 30, 2023 6:33 PM To: Alexander Vainshtein <[email protected]<mailto:[email protected]>> Cc: Christian Schmutzer (cschmutz) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Nitsan Dolev <[email protected]<mailto:[email protected]>>; Rotem Cohen <[email protected]<mailto:[email protected]>>; Jun Ye <[email protected]<mailto:[email protected]>> Subject: [EXTERNAL] Re: My comment about draft-shmutzer-pals-ple Hi Sasha, The quality of the recovered clock will never be impacted by a PLE VPWS under the assumption that the egress PE is connected to a (common) clock in sync to the clock of the ingress PE without wander (ref. Section 3.2). Is your concern about better documenting a case where this assumption is not valid? Or do you have any other clock distribution scenario in mind? We are happy to discuss in more detail with you and where needed add more clarifying text in future revisions of the draft regards Christian On 28.03.2023, at 02:59, Alexander Vainshtein <[email protected]<mailto:[email protected]>> wrote: Christian and all, My comment about the Private Line Emulation over Packet Switched Network draft<https://clicktime.symantec.com/15sLvSGdHvL3JADQDADz4?h=fvz4ppwDgbz1vuUIl-18QYiQBOcTy4vC6uzVRGJ4_5w=&u=https://datatracker.ietf.org/doc/html/draft-schmutzer-pals-ple> at the PALS WG session this morning was about possibility of misleading d clock quality information that, IMH, is inherent for this proposal. E.g., Section 1 of the draft discusses a use case about “two ethernet connected CEs and the need for synchronous ethernet operation between them without the intermediate PEs interfering or addressing concerns about ethernet control protocol transparency for carrier ethernet services”. With Synchronous Ethernet, the information about the clock quality is carried in dedicated Layer 2 Control Protocol messages. If these messages are passed transparently they would potentially mis-represent the actual quality of the recovered clock. I think that these considerations should be explicitly discussed in the draft, probably in the (currently missing) Applicability Statement section. My comment should not be considered as preventing adoption of the draft as a WG document. Regards, Sasha Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates 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. Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates 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. Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates 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. _______________________________________________ Pals mailing list [email protected] https://www.ietf.org/mailman/listinfo/pals