Peter M., Peter R. I wonder if there is really a need (use case) for section 5.3 (pure MPLS mapping) ?
Best Regards Stefano ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: mercoledì 9 febbraio 2011 16.06 To: Roberts, Peter (Peter) Cc: [email protected]; [email protected] Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC Thanks. Yes, a poor choice of words on the Annexes being "profiles". We would still need to fill out the Annex info though re: port addresses and the like to ensure inter-operability. I am fine to be neutral on performance aspects -- I would recommend to indicate they are not within scope of the document. ZARLINK Semiconductor Peter Meyer Timing & Synchronization Communication Products Group Office: +1-613-270-7203 | Fax: +1-613-592-1010 [email protected]<mailto:[email protected]> | www.zarlink.com<http://www.zarlink.com/> "Roberts, Peter (Peter)" <[email protected]> Sent by: <[email protected]> 09/02/2011 08:52 AM To "Bhatia, Manav (Manav)" <[email protected]>, "[email protected]" <[email protected]> cc "[email protected]" <[email protected]> Subject Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC Peter, With respect to your comments on the profile, the Annexes are not profiles. They are the portions of the standard that define the rules for running PTP over specific lower layer protocols. These can then be included or excluded from specific profiles that are defined. This draft is defining these rules for the MPLS environment. The draft covers all the clock types but as you point out this is not all that clear. This can be added. In addition, I don't believe the ITU-T has concluded anything about performance of BC vs TC. They have just started studying the issue. But this draft is not making any claims about performance and as stated earlier should be applicable for any of the clock types. We can review it to remove any contentious wording in respect to performance. Peter R. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bhatia, Manav (Manav) Sent: February 9, 2011 8:20 AM To: [email protected] Cc: [email protected] Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC Hi Peter, Very valid comments. This draft covers all clock types - TC, BC and OC. The reason it seems we've been concentrating on TC is because that's the clock type that requires special MPLS processing. For BC's and OC's there is no special processing involved. One just needs an MPLS LSP that terminates on a BC and OC and things will just work. However, I get the drift of what youre saying and we can update the draft to explicitly state this. I will let someone more knowledgeable respond to your question on whether a separate profile for MPLS is required or not. To my untrained eye it looks that we might. Cheers, Manav > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Wednesday, February 09, 2011 2.00 PM > To: Bhatia, Manav (Manav) > Cc: [email protected] > Subject: Re: [TICTOC] 1588overmpls-00 / MPLS profile & BC > > > Hi Manav, > > > A high level point is that for the pure MPLS mapping (section 5.3) , I > wonder if what is really needed is a PTP profile for MPLS -- > similar to > Annex D/E/F for IPv4/IPv6/Ethernet, respectively. For > example the IP & > Ethernet profiles include other information such as the port > addressing for > the unicast master table and acceptable master table. Without a full > profile, although the intermediate notes may operate in TC, > the server, > client and boundary nodes may not operate successfully. > > Its not clear if this draft is intended to cover all clock > types (OC, BC & > TC) or only TC. There are many sections that talk only about > TC without > considering OC and BC behaviour or impact. Is BC intended to > be covered as > a Client-side OC + Server-side OC model, or is BC excluded from > consideration in this draft? Perhaps this draft should be either > cleaned-up to consider all clock types or should be > restricted to only TC > clock type with OC & BC out of scope. > > > Some specific comments > > + The abstract could be clarified to indicate there are three > mappings, not > two (pure MPLS, UDP/IP over MPLS and Ethernet over MPLS). I think the > third mapping may be under discussion, so perhaps this is premature. > > + A few places in the text the phrase "proper handling of > these packets" or > "properly handle PTP messages" or "perform proper > processing" is used to > mean transparent clock. I would propose to remove such > language as from > the ITU-T studies of timing performances of PTP one could argue the > "proper" way is to implement a boundary clock. Where the > intention is to > aid the designer of a TC that is fine to describe the implementation > recommendation, but not to suggest this is the way to acheive the best > performance or even the desired way to deploy PTP over MPLS. > > + I would like to see a statement added in the document that the > performance aspects (e.g. the phase or frequency alignment) > are outside the > scope of the document. > > + Section 6, 7, 8, 10 and 13 seems to focus only on the TC > case between > OC's and does not consider BC situation. > > + Section 12 text on checksums could be improved to indicate this only > applies to TC and not to OC & BC. > > + Section 16 seems to address only TC clocks and not OC or BC clocks. > > + Section 16.3 implies that the only possible way to handle PTP is TC, > excluding BC --- "don't have the capability to process 1588 > packets (e.g. > TC processing)" and " Non-1588-aware LSRs ignore the RSVP > 1588_PTP_LSP > object and just switch the MPLS packets carrying 1588 messages as data > packets and don't perform any TC processing." > > > Regards, > > > ZARLINK Semiconductor > Peter Meyer > Timing & Synchronization > Communication Products Group > Office: +1-613-270-7203 | Fax: +1-613-592-1010 > [email protected] | www.zarlink.com > > > > > > "Bhatia, Manav > > (Manav)" > > <manav.bhatia@alc > To > atel-lucent.com> "[email protected]" > <[email protected]> > Sent by: > cc > <tictoc-bounces@i > > etf.org> > Subject > [TICTOC] > > > draft-ietf-tictoc-1588overmpls-00.t > 26/01/2011 11:22 xt > > AM > > > > > > > > > > > > > > > > Hi, > > We've tried incorporating most of the comments that we received on the > list. Please ping me if you think we have missed some. > > Would be great if the WG can go through this and provide > feedback on the > same. > > The draft is available here: > http://www.ietf.org/internet-drafts/draft-ietf-tictoc-1588over > mpls-00.txt > > Cheers, Manav > > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of > [email protected] > > Sent: Wednesday, January 26, 2011 9.30 PM > > To: [email protected] > > Cc: [email protected] > > Subject: [TICTOC] I-D Action:draft-ietf-tictoc-1588overmpls-00.txt > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. > > This draft is a work item of the Timing over IP Connection > > and Transfer of Clock Working Group of the IETF. > > > > > > Title : Transporting PTP messages (1588) over > > MPLS Networks > > Author(s) : S. Davari, et al. > > Filename : draft-ietf-tictoc-1588overmpls-00.txt > > Pages : 35 > > Date : 2011-01-26 > > > > This document defines the method for transporting PTP > messages (PDUs) > > over an MPLS network to enable a proper handling of these packets > > (e.g. implementation of Transparent Clocks (TC)) in LSRs. > > > > Cheers, Manav > > -- > Manav Bhatia, > IP Division, Alcatel-Lucent, > Bangalore - India > > > _______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc > > > > ---------- > This email is confidential and may contain information that > is privileged and > exempt from disclosure by law. If you have received it in > error, please contact > the sender immediately by return email and then delete it > from your system; you > should not copy it or disclose its contents to anyone. > Emails are not secure > and cannot be guaranteed to be error free as they can be > intercepted, amended, > lost or destroyed, or contain viruses. Anyone who > communicates with us by email > is taken to accept these risks. > _______________________________________________ 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
