Hi Shahram, >11. FCS Recalculation >"FCS retention described in [RFC4720] MUST not be used" >- that makes sense, but seems to contradict the first half of the sentence >>"Ethernet FCS MUST be recalculated at every LSR". In my understanding if >>retention is not used, only the LERs have to recompute the FCS. LSRs may >>alter the CF, but do not need to bother with the FCS. > >SD> I think your understanding is not correct.
I guess I am missing something - I will appreciate if you can elaborate why an intermediate LSR must recalculate the FCS in the absence of FCS retention. In the absence of FCS retention, we would have according to RFC4448: "The ingress Native Service Processing (NSP) function strips the preamble and frame check sequence (FCS) from the Ethernet frame and transports the frame in its entirety across the PW. This is done regardless of the presence of the 802.1Q tag in the frame. The egress NSP function receives the Ethernet frame from the PW and regenerates the preamble or FCS" Thanks. Tal. -----Original Message----- From: Shahram Davari [mailto:[email protected]] Sent: Wednesday, January 26, 2011 6:49 PM To: Tal Mizrahi; Bhatia, Manav (Manav); [email protected] Subject: RE: Transporting PTP messages (1588) over MPLS Networks Hi Tal, Please find my comments inline. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tal Mizrahi Sent: Tuesday, January 18, 2011 6:04 AM To: Bhatia, Manav (Manav); [email protected] Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks Hi Manav, A few comments below. Section 3. Problem Statement says that "The defined method is applicable to both MPLS and MPLS-TP networks." - however, Section 9. OAM, Control and Management does not mention MPLS-TP OAM. Furthermore, section 5.1. 1588 over LSP Encapsulation shows an encapsulation with a single label, and does not show that an optional GAL is possible. SD> We could add the MPLS-TP OAM to the text. Regarding GAL, this is explicitly not allowed to be in the stack when the encapsulated data is PTP message. So GAL is not optional. 6. 1588 Message Transport "If Two Step Transparent clocks are present, then the FOLLOW_UP and DELAY_RESP messages must also be transported over the PTP LSPs." - for P2P TCs you also need the PDelay_Resp_Follow_Up. SD> AFAIK These messages don't require time stamping and therefore don't have to be transported over PTP LSP. 10. QoS Considerations - I am not sure I understand why this is a MUST. This draft defines an encapsulation, while the QoS requirements are typically be derived from the application, which is defined elsewhere. SD> The application is PTP, which requires low delay. Are you suggesting we make it a should? 11. FCS Recalculation "FCS retention described in [RFC4720] MUST not be used" - that makes sense, but seems to contradict the first half of the sentence "Ethernet FCS MUST be recalculated at every LSR". In my understanding if retention is not used, only the LERs have to recompute the FCS. LSRs may alter the CF, but do not need to bother with the FCS. SD> I think your understanding is not correct. Tal. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bhatia, Manav (Manav) Sent: Saturday, January 15, 2011 12:56 PM To: [email protected] Subject: [TICTOC] Transporting PTP messages (1588) over MPLS Networks Hi, We have posted a revised version of draft-davari-tictoc-1588overmpls-01 and would appreciate a feedback from the WG. The draft is available here: http://www.ietf.org/id/draft-davari-tictoc-1588overmpls-01.txt Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
