Hi Yaakov and all, Unfortunately, I have not attend this meeting. From the minutes below, is it possible, a boundary clock (not in every node) might require MPLS to support multicast with co-routed reverse path which has been presented at IETF78 on TICTOC? Actually this is the only thing I can see now.
BR Lizhong ---------------------------------------------------------------------- Message: 1 Date: Mon, 27 Sep 2010 09:38:15 +0200 From: Stefano Ruffini <[email protected]> Subject: Re: [TICTOC] draft minutes of TICTOC WebEx conference To: Yaakov Stein <[email protected]>, "[email protected]" <[email protected]> Message-ID: <28c9b1cd4d27844e9cd8f02bfeb7056402a5d...@esesscms0360.eemea.ericsson.se> Content-Type: text/plain; charset="iso-8859-1" Hi Yaakov, I think on eimportnat aspect that was also mentioned is : - It was noted that when there is a Boundary Clock in every node (i.e. PTPpackets are terminated in each node), there might not be the need for specific MPLS support (e.g. encapsulation options). This assumption is true also in case of MPLS-TP assuming multicast is used. Best Regards Stefano ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Yaakov Stein Sent: venerd? 24 settembre 2010 11.18 To: [email protected] Subject: [TICTOC] draft minutes of TICTOC WebEx conference 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://www.ietf.org/mail-archive/web/tictoc/attachments/20100927/eb38920d/attachment.htm > ------------------------------ -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
