Hi all, Below are draft minutes of the conference call. I don't have the complete list of participants since
1) at least one person called in and thus was listed without a name, 2) I wrote the notes from memory a day later. Please fill me in if you were there and I left you out. I also missed a few minutes of the conference. If I missed anything critical I would appreciate someone filling me in. Other corrections and comments welcomed as well. Y(J)S On Monday, 20 Sept 2010, a TICTOC WebEx conference took place. The call started 45 minutes late due to problems in getting the WebEx system up (thanks to Alexa for help in getting the system to work). Several people did not manage to get into the conference. Participants : Karen, Yaakov, Stewart, Luca, Antti, Stefano, Michael, Michel, Laurent, Gaby, <can anyone I missed send me a note?> 1) The first question (raised by Antti) that was raised was whether we are talking about frequency or time (uncalibrated or calibrated) distribution. Most of those on the call felt that frequency is handled well enough today, and that we should be focusing on time. This feeling was reinforced by three facts : a) one of the main problems in networking is how to ensure symmetry, and this is irrelevant to frequency distribution b) highly precise frequency distribution is probably going to be carried out at the physical layer (e.g., SyncE) c) moderately precise frequency distribution is handled today using packet methods without MPLS-layer intervention 2) The second question (raised by Luca) was whether we are talking about a network or an over-the-top service. After discussion, it was agreed by all participants that we should initially focus on a network service. The main reasoning was : a) user time distribution packets can be quite complex to recognize, e.g., UDP/IP in Ethernet in a PW in MPLS, or 1588 over Ethernet over EoS over a CEP PW over MPLS, etc. b) if the network operator can provide an inexpensive time delivery service, it could potentially change the modus operandi of those who presently use their own time systems c) a certain trust level is required by the customer for the network operator, so the enhancement of the trust to full proventication is not a major step (although it will require protocol development) 3) The third issue (raised by Antti) was whether an MPLS encapsulation is needed at all. If the problem is solved or going to be solved at all the server layers of MPLS (Ethernet, OTN, SDH), and in general lower layers are better at time delivery than higher ones, then it does not make sense to re-solve the problem at the MPLS layer. There was discussion as to what happens when the MPLS end-to-end path is supported by a concatenation of several disparate transport technologies, but since one of the trends is hop-by-hop clock stabilization, this problem may be automatically solved by the developing architecture. We did not reach full agreement on this point. Stewart warned that the service provider may not have access or even know what the underlying layer is, and warned participants not to focus solely on the mobile backhauling problem. 4) Yaakov started discussion of the encapsulation options, but there was not enough time to present the topic. 5) The chairs proposed to hold a conference call every third Tuesday of the month at 8 AM Pacific time (which corresponds to 11 AM East Coast time, 4 PM UK, and usually 6 PM Israel time). This proposal will be made on the list. Y(J)S
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
