Hi all, Interesting how everyone is changing their minds so quickly ...
When I brought up the question of NTP I was told that NTP is not interesting / not possible since the ONLY question here is TC. I tried pushing the issue of prioritization, and hinted at the asymmetry issue (but wanted to discuss with the RSVP-TE experts first to see that it could be done) and was told that I needed to explain why there is anything at all to do in this regards. Well, let's assume that I have become convinced by your arguments and really want TC. Not just for 1588, but for the timing protocol that presently runs over the Internet. In that case your proposal falls somewhat short, but can be easily retrofitted to accomplish everything for both timing protocols. If, in addition, I can get time correction for other protocols, and measurement of one-way delay for PM, that sounds like a major advantage from my point of view. I fully understand the advantage of re-using existing hardware, and am not suggesting that we not advance the present proposal. However, I think the generic mechanism can easily be implemented based on existing building blocks, and should be investigated as well. Y(J)S -----Original Message----- From: Bhatia, Manav (Manav) [mailto:[email protected]] Sent: Tuesday, February 01, 2011 02:10 To: Yaakov Stein; Jack Kohn Cc: [email protected] Subject: RE: [TICTOC] Transporting PTP messages (1588) over MPLS Networks Hi Yaakov, I am not sure if I understand why you think that the method described in this draft will not work for NTP? I agree that we have been concentrating on 1588, but that's ok for a draft that's called "Transporting PTP messages (1588) over MPLS Networks". We would require some very minimal changes to also accommodate NTP. The draft states that a subset of PTP messages MUST be transported over some dedicated LSPs, lets call them timing LSPs for now. When setting up the RSVP tunnel we had also given a pointer to the start of the packet, thus it is trivial for implementations to note whether the incoming packet is 1588 or some other. If its 1588 event messages then they may want to compensate for residence time by updating the PTP packet Correction Field. At the very least such packets should be given some sort of priority over the others. Now this draft can be easily extended to carry NTP as well. All we need to say is that NTP packets MUST be transported over the timing LSPs. We will need to change section 13 where we have described routing extensions to now indicate the protocol (1588 or NTP) that the router supports. Additionally, it can also indicate that if its 1588, then is it capable of updating the CF. Similarly, we may need some minor changes in the RSVP section as well. The section on ECMP and QoS will remain as is without any changes. There can be a subsection for 1588 where we discuss the UDP checksum, etc. So I don't see why you think that this draft precludes the possibility of supporting NTP. Cheers, Manav > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Yaakov Stein > Sent: Monday, January 31, 2011 10.50 PM > To: Jack Kohn > Cc: [email protected] > Subject: Re: [TICTOC] Transporting PTP messages (1588) over > MPLS Networks > > Jack > > There was a long discussion at the conference call and on the list, > with the draft authors and others maintaining that this method > is not applicable to NTP (mainly because its sole purpose is > to identify LSRs that can perform TC correction to 1588 packets). > > By label range I mean the method used to identify the timing packets > in transit, whatever that method is. > > Y(J)S > > -----Original Message----- > From: Jack Kohn [mailto:[email protected]] > Sent: Monday, January 31, 2011 15:26 > To: Yaakov Stein > Cc: [email protected] > Subject: Re: [TICTOC] Transporting PTP messages (1588) over > MPLS Networks > > Yakov, > > > 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 > > What label range are you referring to? AFAIK there isnt any label > range defined in this document. The label that 1588 uses is signalled > by RSVP to all the other nodes. > > Also, what prevents the same mechanism to be used for NTP? If its NTP > that we are supporting then one does not need to provide the offset in > the RSVP object. The routing extensions remain the same and it NTP > also works. Thus the mechanism defined in this draft will work for NTP > as well. > > Jack > > > 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 > _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
