Hi Michel, From: Michel Ouellette [mailto:[email protected]] Sent: Monday, July 12, 2010 11:23 AM To: Shahram Davari Cc: [email protected] Subject: RE: [TICTOC] FW: 1588 over MPLS draft
Hi Sharam, II have some initial comments and questions. Not sure yet if I will attend the meeting. I do tend to agree that there are cases where there is a need for LSRs to identify PTP messages. The draft is similar in some aspects to some of the proposals made by Ron Cohen back in 2007. The two differences I see is that your draft proposes to use the outer label to identify PTP messages and to use the standard PTP mappings (Annex D & F of IEEE1588), whereas in Cohen's draft, the outer label was not used (ie., the PW instead was proposed to distinguish the PTP LSP types) in addition to a proposal to have a direct mapping of PTP into MPLS, although that would require a new networkProtocol enumeration as defined in IEEE1588. SD> I know Ron had a nice draft, but the issue with that draft is that it required Deep packet inspection at line rate for all packets. Also it requires use of CW. The draft primarily discusses the use for Transparent Clock, but it is equally application to Boundary Clocks. Actually it should be useable for any types of clocks defined in IEEE1588. There are scenarios where you might have a time synchronization chain composed of only BC-LSRs or TC-LSRs or combination/mix. There is a need to clarify reference models as I think these might further add requirements to the "PTP LSP" definition. SD> Sure we can expand it more. In section1, you say "the accuracy of the recovered clock improves". Are you referring to the distribution of frequency or time in this specific paragraph? SD> Both. When intermediate nodes perform Transparent Clock, they remove most of the delay variation and help improve accuracy. In section 1, you also say "it should be possible to instead control the delay for these messages on both directions across the node". In theory this is possible, but practically very difficult because of the current QoS architecture (i.e., it is hard to control the per-hop behaviour (PBH) that determines the scheduling treatment of packets to produce such results) SD> Why? Can't you just assign these packets to EF-PHB? In section 8, can you clarify what is meant by "any PTP LSP failure will trigger the slave to switch to the Redundant Master, even if the LSP is protected at the MPLS layer". Why is that? SD> When a PTP LSP fails the Slave detects the failure very quickly and switches to the Redundant Master even before protection switching kicks in. So LSP protection kicks in way after the Slave has switched to redundant Master. Thx Shahram Thanks. Michel From: Shahram Davari Sent: Wednesday, July 07, 2010 12:12 PM To: '[email protected]'; '[email protected]'; '[email protected]'; '[email protected]' Subject: 1588 over MPLS draft Hi All, Please find attached our first draft of 1588 over MPLS. Since we have some technical issues converting the Word format to Txt we couldn't upload the draft before the cut-off date. However we will present the draft in the next IETF meeting and will upload the draft after the meeting. Note that the main WG is TicToc but may require consultation with MPLS and PWE3 WGs. Thanks, Shahram Davari
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
