Hi Yaakov, I agree that we need co-routed LSPs, but I don't understand why we need a complete new method of carrying CF. I think we have to reuse what exists today and our draft really doesn't change the encapsulation, and therefore Min HW change is required to support it. On the other hand defining a new CW and PW is going to be very painful since it has major HW impact.
So I don't support such change. I think if needed we could accommodate the NTP as well, we just need a requirements document to evaluate. Thx Shahram -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Yaakov Stein Sent: Monday, January 31, 2011 5:13 AM To: [email protected] Subject: Re: [TICTOC] Transporting PTP messages (1588) over MPLS Networks Hi all, The issue of ensuring a bidirectional co-routed path is what I wanted to explain regarding NTP. I was discussing this last week with the routing ADs, and was told that co-routing is a standard feature of GMPLS (RFC 3471 section 4). Since the control plane of MPLS-TP will be GMPLS, this is a good fit. I looked up some experiments I performed a few years ago using NTP with HW timestamps. For Internet paths, the fraction of the inaccuracy resulting from asymmetry was about three times that resulting from PDV. Thus asymmetry reduction is often a more important goal than TC. Of course if we are speaking of full peer-to-peer TC asymmetry doesn't matter, but if we had that we don't need 1588 either - just sending a timestamp is enough. I realize that this is not relevant for a well-engineered network where one could use management to configure a co-routed bidirectional path. Setting up a co-routed bidirectional path using standard RSVP-TE is equally useful for NTP and 1588, and leads me to return to my original request for a single mechanism for both. I am thus led to reiterate my proposal for completely generic MPLS mechanism for TC, a method that eliminates all the FCS and UDP checksum problems that we have recently discussed. We need only to define a new PW type with an extended control word that carries a CF. The payload could be anything - NTP, 1588, RFC-868, one-way delay OAM, etc. We can use the label-range idea from the present draft, and similar routing extensions to signal the TC capability. Y(J)S _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
