Hi Shahram,
I think another topic that would be good to progress was discussed on the exploder in March -- how to handle packets that do not flow through the network element, but are generated & terminated each node (e.g. peer-delay messages). These packets (similar to point 3 below) may be event or general messages. Refer to last e-mail of chain on March 22, subject "[TICTOC] Updated 1588 over MPLS draf-03". Regards, Peter From: [email protected] [mailto:[email protected]] On Behalf Of Yaakov Stein Sent: August 1, 2012 5:11 PM To: Shahram Davari; [email protected] Subject: Re: [TICTOC] Questions regaridng 1588 over MPLS During today's TICTOC meeting I raised the following questions. We need your feedback on these questions in order to progress this draft. 1. Should CW be mandatory? a. If not, then a PTP-LSP needs to carry only one type of PW (either with CW or without CW) but not mix so that LSRs can correctly parse the packet b. c. Without PW the job of LSRs becomes more complex to identify the OAM packets [YJS] I believe that it is fine to require a CW. RFC 5994 makes the CW mandatory for Ethernet PWs over MPLS-TP, I believe that TP will be the main use case. 2. Should ECMP/Entropy be disallowed? a. The current consensus is yes, no ECMP or Entropy shall be used. [YJS] entropy labels should be disallowed. Obviously timing flows should in general should not be shifted from one path to another path with different delay, if undetected the delay jump will cause an accumulating phase error. I understand that with TC this point is less important, but this draft explicitly speaks of only partial on-path support. Should PHP (Penultimate Hop Popping) be allowed? [YJS] Once again, if the main use case is MPLS-TP, then this may be automatic 3. How to transport 1588 messages that don't need TS or CF update? a. Send them over non-PTP LSP? b. Let the LSRs do the parsing and perform TS or CF updated based on message type? [YJS] They should be sent over the same PW. Since the setup specifies the timing flow type, the regular 1588 parser will be called anyway. 4. Should P2MP LSP & P2MP PW be supported? [YJS] No strong opinion. 5. Should protection be supported for PTP-LSP? a. FRR, 1:1 and 1+1 [YJS] Similar to my response above, protection should NOT be supported, as a change of path means a change in delay, which if undetected can be worse than losing the timing flow and going into holdover. 6. How does LSP/PW connectivity failure interact with 1588? a. Does the Slave select another master when a failure happens? b. Can the protection make the failure invisible to Salve clock? [YJS] b. should never be allowed. a. is a configuration option. 7. Should only VCCV1 and VCCV4 be allowed? a. If not then the VCCV type needs to be the same for all PW in the PTP-LSP so that LSRs can correctly parse the packet [YJS] We are presently in the process of obsoleting type 2 anyway. So we are left with the issue of type 3, which is mostly for MS-PWs. Do you see this being used for the MS case ?
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
