Manav Then we basically agree.
Y(J)S -----Original Message----- From: Bhatia, Manav (Manav) [mailto:[email protected]] Sent: Tuesday, February 01, 2011 17:52 To: Yaakov Stein; Jack Kohn; Shahram Davari Cc: [email protected] Subject: RE: [TICTOC] Transporting PTP messages (1588) over MPLS Networks Hi Yakov, And I still stand by what I said earlier that I don't think NTP needs to be included here. I'd rather that we keep NTP and 1588 separate and only merge them if we think its absolutely essential that a common uniform solution is developed for the two protocols. I responded to a comment on the list that the method described in this document cannot be applied to NTP. I think it can with a few tweaks here and there as you also suggest in your email (and had alluded to in the call last time). Cheers, Manav > -----Original Message----- > From: Yaakov Stein [mailto:[email protected]] > Sent: Tuesday, February 01, 2011 9.09 PM > To: Bhatia, Manav (Manav); Jack Kohn; Shahram Davari > Cc: [email protected] > Subject: RE: [TICTOC] Transporting PTP messages (1588) over > MPLS Networks > > 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
