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
