[11:23:07] --- ron.cohen has joined
[11:38:12] --- ron.cohen has left
[11:38:28] --- ron.cohen has joined
[11:53:43] --- stbryant@jabber.org has joined
[11:55:45] --- shane has joined
[11:55:49] <shane> Hey all.
[11:55:59] <shane> I'll go ahead and Jabber scribe for the BoF.
[11:58:07] <stbryant@jabber.org> Thanks
[11:58:41] <shane> The web site is all up to date, so you can have a look here:
[11:58:42] <shane> http://www3.ietf.org/proceedings/07dec/agenda/tictoc.html
[12:00:12] <stbryant@jabber.org> is the audio OK
[12:00:20] --- fenton has joined
[12:00:21] --- marshall has joined
[12:00:35] <marshall> hello
[12:00:38] --- pellepolis@gmail.com has joined
[12:00:50] --- Jim has joined
[12:01:15] <shane> Was a BoF at Prague, no BoF at last IETF.
[12:01:29] <shane> Agenda is on the IETF and the unofficial web site.
[12:01:35] --- shikob has joined
[12:01:39] <shane> Goal for the meeting: Approve the charter.
[12:02:36] <shane> Comments on agenda?
[12:02:42] <shane> None.
[12:02:55] <shane> http://www.dspcsp.com/tictoc/TICTOC70-intro.ppt
[12:05:11] <ron.cohen> How many people are there in the conference room?
[12:05:23] <marshall> ~ 50
[12:05:40] --- kenichi has joined
[12:08:17] <shane> http://www.dspcsp.com/tictoc/TICTOC70-silvana.ppt
[12:08:25] <marshall> 1588 profiles
[12:12:07] --- skostecke has joined
[12:20:28] --- stbryant@jabber.org has left: Replaced by new connection
[12:24:57] <shane> Questions?
[12:24:57] <shane> Questions?
[12:24:57] --- shane has left
[12:25:25] --- shane has joined
[12:25:49] <shane> (Sorry missed a question due to network failing.) :(
[12:26:06] <shane> No problem here that we are fighting with the IEEE.
[12:26:17] <shane> We have the blessing of the IEEE to do this.
[12:26:41] <shane> If anyone is worried that we are going to cause a fight between standards orgs, this is not the case.
[12:26:53] <shane> Peter Lothberg: Will the IEEE standard be available to the IETF? Right now I can't see it.
[12:27:22] <shane> Karen: Can make a draft for discussion purposes...
[12:27:45] <shane> Silvana: Can send an official request from the IETF to the IEEE, and make it available. Needs to be an official request.
[12:27:59] <shane> Plenty of precedent for this.
[12:28:30] <shane> What happens with the standard when it's approved?
[12:29:00] <shane> Karen: Relationships have not been established, but 1588 community is eager to help.
[12:29:20] --- florent.parent@gmail.com has joined
[12:29:23] <shane> Room: will fix it
[12:29:36] <shane> http://www.dspcsp.com/tictoc/TICTOC70-karen.ppt
[12:29:57] <marshall> The relationship between tictoc and NTP
[12:30:19] --- xiaohunhun has joined
[12:34:25] <shane> Discussion?
[12:35:06] <shane> Mark: No implication that if the NTP wg shuts down that NTP work in the IETF stops.
[12:35:28] <shane> Mark Townsley.
[12:35:45] <shane> TICTOC under charter would have a next-generation NTP.
[12:36:09] <shane> Independent work here is talking about progression & tweaks to NTPv4, right?
[12:36:12] <shane> Karen: Right.
[12:37:00] <shane> Kurtis Lindqvist: TICTOC would put up requirements to NTPv4, or no changes at all?
[12:37:29] <shane> Mark: TICTOC will talk about requirements for next generation time, not NTPv4 per se. If it is NTPv4 and you don't need to change it - great! If you need a substantive change, that's NTPv5 and it's here.
[12:38:21] <shane> http://www.dspcsp.com/tictoc/TICTOC70-stewart.ppt
[12:38:40] <shane> TICTOC-Topology-Discoveery and Clock-Discovery by Stewart Bryant
[12:47:48] <shane> Steve: Is there any communications between the master to the slave, or is it as in NTP, we have this many strata.
[12:47:55] <shane> Stewart: Yes.
[12:48:20] <shane> Silvana: In telecom we use much better ocilators so we may not see the same problem.
[12:48:31] <shane> Stewart: Drive is always towards cheaper oscillators.
[12:49:03] <shane> Jean-Luc: We have to to send high quality to large networks, which is why we do it by filtering (???)
[12:49:21] <shane> (Sorry - stumbling on jargon - someone should correct this.)
[12:50:22] <shane> Peter: If you're trying to push your timing packets as payload on the wire (not another layer 2), if there are more packets on the wire you have to wait.
[12:50:48] <shane> If you take this entire forumlas and stick the functions in the end node and you get the same as if you put it across the network.
[12:51:00] <shane> Stewart: I invite drafts that explain how to do this.
[12:51:21] <shane> (Regarding "Transparent Clock Mechanisms" slide with lots of delta-T's)
[12:58:46] <shane> Questions?
[12:59:04] <shane> Jean-Luc: Presentation is interesting, points that have never been addressed in synchronization.
[12:59:46] <shane> Jean-Luc: At the opposite, from traditional synchronization, the opinion is that the network is very stable. Very difficult to control them, otherwise you interfere with the quality of the performance.
[13:00:48] <shane> Stewart: Moving into a world where operators are using packet network technology. Now relying completely on IETF protocols. If these protocols don't work, they are in trouble. From our side, we are making relatively minor modifications to technologies that are fundamental in these networks.
[13:01:05] <shane> Jean-Luc: What about requirements? The requirements for time in these systems are very strict, several microseconds.
[13:01:21] <shane> Stewart: Trying to move on from the millisecond-class that we traditionally get in the IETF.
[13:01:34] <shane> Yaakov: There is a draft about this.
[13:02:03] <shane> Gabriel: Curious of economics of routers that include clocks, rather than deploying GPS. Maybe should concentrate on discovery rather than this.
[13:02:33] <shane> Stewart: Huge amount of discussion about this. Providing GPS may not be possible in some environments, and may be more expensive. Several thousand dollars per cell site, for example.
[13:03:06] <shane> Stewart: Been stealing sync from the network until now, looking to get it for free. Sync ethernet is a way to do this, but you may not be able to do this, and need a packet based model.
[13:03:17] <shane> Gabriel: Thrown out 20-hop models.
[13:03:27] <shane> Stewart: 20 hops is only the theoretical maximum.
[13:03:50] <shane> Yaakov: Some places will not use GPS for policy (GPS is a US system). Question has been discussed at length.
[13:03:57] <shane> Stewart: Also questions of jamming.
[13:03:58] --- fenton has left
[13:04:37] <shane> Yaakov: In general telecom users want an SLA. GPS provides no promises. Galileo provides this, but does not exist.
[13:05:25] <shane> Kurtis: The network scenarios look nice, but in my experience this does not look like real networks. Mostly traffic isn't symmetrical or nicely ordered. You have load balancers, and so on.
[13:05:43] <shane> Kurtis: An enterprise network is not a smaller version of an enterprise network.
[13:06:10] <shane> Stewart: That surely implies that you need to set up time paths, rather than use data paths.
[13:06:16] <shane> Kurtis: There is no alternative path!
[13:07:44] <shane> Peter: Need to improve way of disseminating time of day to users. No good way better than NTP. With packet networks we have build a network that does not require synchronization. Trying to support a bunch of old legacy stuff which is probably less than 10% of the traffic today, and we are spending a lot of energy on this. We have to support hundreds of millions of users and we're spending effort on the telcos instead!
[13:08:03] <shane> Yaakov: A lot of customers are willing to pay a lot to get highly accurate time.
[13:08:15] <shane> Peter: If you want to use TICTOC to generate clock for your SONET network...
[13:08:20] <shane> Chairs: nobody is saying that.
[13:08:48] <shane> Ted Seely: Can you give examples relative to the work here that don't work?
[13:08:59] <shane> Applications that require higher accuracy frequency/time...
[13:09:09] <shane> Yaakov: We want to be able to get rid of GPS to do this.
[13:09:29] <marshall> SDH
[13:10:06] <shane> Yaakov: Refer everyone to the problem statement - been discussed at great length already.
[13:11:07] <shane> Ted: We're boiling the ocean for 10% of the end users.
[13:11:48] <shane> Tim Shepard: Cell sites are not "applications".
[13:12:21] <shane> Stewart: Lots of things we would like to do... one-way packet delay measurements for example.
[13:12:43] <shane> Stewart: Financial guys want orders of magnitude improvement in timestamping. We have an applications draft, but we don't propose going through it today.
[13:13:04] <shane> Yaakov: Plenty of people who have asked us to work on this item. This is not a problem space where noone is interested.
[13:13:41] <shane> http://www.dspcsp.com/tictoc/TICTOC70-yjs.ppt
[13:13:48] <marshall> use cases
[13:16:51] <shane> Question about Use Case 1: (service provider network)
[13:16:55] <shane> How secure is 1588?
[13:17:05] <shane> Stewart: Not well secured in its current incarnation.
[13:17:19] <shane> In other IETF protocols, even for walled gardens we did not accept protocols that were not secure.
[13:17:28] <shane> Yaakov: Security is something to work on, but not in phase 1.
[13:17:41] <shane> IEEE has no problem with us enhancing 1588 to add security?
[13:17:48] <shane> Stewart: Nope. It is currently experimental.
[13:18:08] <shane> Stewart: This is IEEE test & measurement, not 802 which has far more experience with packet networks.
[13:19:53] <shane> Mark: Principle here is that any protocol that can be run over IP *MUST* implement security as if those packets were on the big-I Internet.
[13:20:11] <shane> Mark: Our responsibility is that we have a MUST implement security defined, and it should be in phase 1.
[13:20:25] <shane> Yaakov: That's fine, but we have to look into possible degradation of time when security is added.
[13:20:28] <shane> Mark: Exactly.
[13:23:47] <shane> Stewart: Much more important to look at spectrum of delay...
[13:24:11] <shane> Al: Sounds like you mean inter-packet delay variation and packet delay variation...
[13:24:16] <shane> Stewart: Yes.
[13:25:45] <shane> Unnamed person: Why did you label this as interworking rather than making 1588 as one hop in an NTP topology.
[13:25:54] <shane> Yaakov: That is one of the possibilities.
[13:26:48] <shane> Person: You can use 1588 as a way of constructing an NTP hop. If you don't have 1588 you run NTP directly.
[13:27:05] <shane> Yaakov: Assumption is on the right side you have someone not running NTP.
[13:27:20] <shane> (This is all about slide #5, "Internetworking Case")
[13:27:24] <marshall> Dave Orans
[13:27:27] <shane> thx
[13:27:33] <shane> Dave: Do people understand what I said?
[13:27:38] <shane> (Some agreement)
[13:27:39] <marshall> I did
[13:28:02] <shane> Stewart: We didn't set this randomly! When you go to forums, service providers are speaking exclusively 1588.
[13:28:19] <shane> Tony Li: Would like to propse another use case - NTP embedded between 2 NTP peers.
[13:28:41] <shane> Karen: When we were talking in Prague, one of the possibilities was 1588 at the lower level and NTP at the higher level.
[13:29:00] <shane> Karen: The other thing is that the more logical deployment scenerio is NTP at the core and 1588 at the edges.
[13:29:17] --- pellepolis@gmail.com has left
[13:29:26] <shane> Karen: NTP and 1588 have roughly similar semantics. Need to think about the 1588 master/slave paradigm and the NTP client/server paradigm.
[13:30:29] <shane> Questions?
[13:30:39] <shane> Dave: Object to the term "internetworking".
[13:31:04] <marshall> who is speaking ?
[13:31:07] <shane> Donald: Not an expert at the timing stuff. Have seen requirements from providers regarding what Peter called legacy equipmant.
[13:31:34] <shane> Need the folks who are using this stuff to say what their requirements are.
[13:31:44] <shane> Need to distinguish between practical and theoretical use cases.
[13:32:11] <shane> Not convinced that boundary clock solution applies - need to make that sort of call early on.
[13:32:23] <shane> Has a big implication on Stewart's slide on clock discovery.
[13:32:29] <shane> Yaakov: Agree about requirements.
[13:33:12] <shane> Yaakov: Not sure about issue of boundary clocks - literature is about people using these mechanisms.
[13:33:27] <shane> Yaakov: If SDH works this can work as well.
[13:33:52] <shane> Donald (?): If this WG does get formed, charter has to be precise. See ambiguity regarding problem.
[13:33:58] <shane> Yaakov: What? Too many questions?
[13:34:11] <shane> Donald (?): Yes. Service provider case is well stated, others not.
[13:34:51] <shane> Stewart: Elements of the network will wish to use 1588, others wish to use NTP.
[13:35:24] <shane> Stewart: Need to distribute high quality time from one domain to the other. WG should investigate whether there are any technical problems to solve in this area. If not, will sign off as no problem to solve.
[13:35:33] <shane> Discussion portion of BoF begins.
[13:37:19] <shane> Mark: Lot of questions!
[13:38:11] <shane> Mark: Last TICTOC BoF it was clear there was interest and applications. Would like to get to "how do we charter this work?". Has been challenging: we have two protocols for time.
[13:39:27] <shane> Mark: By putting these two groups of people into one WG, I hope the common aspects can be solved once for both. One of the issues has always been: Everybody is interested in it, not a lot of people willing or able to do the hard work. That was the whole purpose behind the modularity draft, and separate out the common aspects. Not for a moment are we saying that if NTP works on the global Internet that it doesn't work on a small network!
[13:39:50] <shane> Mark: Think charter is workable - not perfect. Internetworking case PTP + NTP is something group will have to fight with.
[13:40:26] <shane> Mark: Need to do requirements and gap analysis for existing protocols.
[13:40:45] <shane> Yaakov: Putting up new charter. It's on the unofficial site.
[13:41:16] <shane> Peter: Would like to simplify the world. Someone invented the new term, "legacy product". Want to plug box who needs TDM into a packet network.
[13:41:26] <shane> Peter: Another group who wants to trust time.
[13:41:32] <shane> Peter: Another group with new applications of time.
[13:42:11] <shane> Peter: One way is PTP another is NTP. Different people in different networks. Why don't we say, "these are the requirements for one group", and look at IEEE or NTP way of doing it, and it's up to the consumer to pick the technology.
[13:42:37] <shane> Stewart: 1588 uses a contiguous timestamp, but it includes information on when to do the leap second.
[13:42:50] <shane> Peter: If one has a sliding time scale and the other doesn't in the same chain...
[13:43:02] <shane> Stewart: Don't be under an illusion that 1588 does not tell you what the wall time is.
[13:43:18] <shane> Steve: Question is, what timeframe is this achievable?
[13:43:36] <shane> Steve: The requirement comes from supporting legacy application, there will be less...
[13:43:45] <shane> Chairs: There are legacy applications, but that is not the focus...
[13:43:56] <shane> Peter: There are some networks in the future that have no synchronization.
[13:44:04] <shane> Yaakov: But that is not what people are building.
[13:44:17] <shane> Steve: Depends on whether people will change the way they are building things.
[13:44:44] <shane> Stewart: Unless someone figures out new coding scheme to maximize the bandwidth, you will need synchronization methods...
[13:45:01] <shane> Peter: We are steering at today's technology, if they figure out a better way to do it they will!
[13:45:16] <shane> Anything else to the mic?
[13:45:21] <ron.cohen> On a different topic: I have a remark on the statement in the charter: "TICTOC will not assume the availability of on-path support for time distribution, but will be able to exploit such support where it is available." I think that availability of on-path support may be required in order to achieve the needed performance in some of the scenarios of interest. TICTOC needs to point out for which scenarios on-path support is mandatory and for which it is only provides a benefit.
[13:45:42] <shane> Tony Li: Would not like to participate in 2 working groups. 1 is better.
[13:45:52] <shane> Yaakov: Hands... how many think 2 separate WGs.
[13:45:54] <shane> 1 hand.
[13:46:22] <shane> Mark: NTP wg *will* finish it's work.
[13:47:08] <shane> Greg: Currently there are charters for 2 WG - large gap right now. Whether there should be 2 WGs moving forward... there are applications that have requirements that are not being met by existing protocols. Can define how to meet those requirements, or create new material to meet those requirements.
[13:47:19] <xiaohunhun> I am not in the workinggroup, just wondering know the result, only 1 people support 2 seperate WGs?
[13:47:21] <shane> Greg: Quite likely to need to be discrete working groups.
[13:47:35] <shane> Yes, only 1 person supported 2 separate WGs.
[13:47:39] <xiaohunhun> thanks
[13:48:14] <shane> Greg: Simply an opinion, more because nobody else raised their hand. There *are* 2 separate problem spaces. Haven't seen too many people participating in the current working group (myself included).
[13:48:42] <shane> Greg: Most of the work is based on configuration, control, trust, building up groups of elements that need timing. Very different from current focus in TICTOC.
[13:49:04] <shane> Greg: Many problem spaces. Should they be under 1? If big enough, well enough chartered, enough resources, yeah.
[13:50:23] <shane> Mark: Kind of the idea. Items you mentioned should not be lost. Just because 40 people are on control network and only 10 on the larger Internet issues, does not mean that one is more important than the other. Charter is very clear that both cases are within scope. Don't think it's whether there is 1 or 2 WGs. Hoping that within 1 WG people like Tony Li will continue to show up and not get frustrated, and that we will do work the same in both protocols.
[13:51:26] <shane> Domald (?): First thing to figure out is what is the problem the WG is going to solve. Do people want 2 WGs? Do people want 1? I think you won't see too many hands for that! What is the problem we are going to solve. The two groups do similar stuff, but there is a clear demarcation.
[13:51:45] <shane> Stewart: Fundamental task is producing a step-function improvement on accuracy and consistency in time across the network.
[13:52:17] <shane> Mark: Point is that 1 vs. 2 WG is something we don't need to spend a lot of time.
[13:53:12] <shane> Mark: Have a variety of startup material (draft charter, problem statement, and so on). How many people think the IETF should take on this work, and create a TICTOC WG?
[13:53:21] <shane> (About 20 hands.)
[13:53:24] <shane> How many opposed?
[13:53:27] <shane> (About 5 hands.)
[13:53:49] <shane> Kurtis: Normally at the IETF when we form working groups, there is no protocol already in existance.
[13:54:01] <shane> Mark: Every WG I formed there was a protocol in existance!
[13:54:25] <shane> Kurtis: Normally we do problem statement, requirements, engineering work. Worried about 2 vs. 1 WG.
[13:55:21] <shane> Tony: Think we should do the work, but not in a working group. Recharter NTP, but definitely one WG.
[13:55:57] <shane> Mark: Overlap of 1 meeting or so with 2 WGs.
[13:56:09] <shane> Tony: We are horrible at closing WGs. This could easily drift into 2 years!
[13:56:21] <shane> Mark: Lets hope not, and take it as motivation to get work done.
[13:56:34] <shane> ???: Are you going to use NTP or 1588 for wireless networks?
[13:56:41] <shane> Stewart: Depends on the requirements and specifications.
[13:56:48] <shane> ???: None of them are quite good for that.
[13:57:20] <shane> Stewart: Then we'll say we can't do it. If we can address it with existing protocols we'll do it, otherwise we'll go to Mark and ask if we should recharter or if it is something we shouldn't do.
[13:58:04] <shane> Mark: Existing charter has requirements, 1588 profile (if needed), NTPv4 extensions (if needed), various MIBS, ...
[13:58:46] <shane> Mark: Could put in autodiscovery / topology discovery work, ... Is this sufficient for now, or should we add more items right away? One of the problems last time was doing too much. Every item you add increases your entropy, and likelyhood of failure.
[13:59:18] <shane> Jean-Luc: Would like to ask first step, policy statement. Will you list requirements from applications?
[13:59:21] <shane> Mark: Yes.
[13:59:46] <shane> Kurtis: Want to nit. We said either NTP extensions or NTPv5.
[14:01:18] <shane> (Discussion of how to carry information without OAM protocols.)
[14:01:39] <shane> Mark: How many people think this is a reasonable set of goals?
[14:01:49] <shane> Kurtis: Aggressive time scale.
[14:02:02] <shane> Yaakov: Wasn't ours! Was our AD!
[14:02:16] <shane> (Comment from room: "add a year")
[14:02:37] <shane> Stewart: Probably not realistic.
[14:02:51] <shane> Yaakov: First 2 are in March because we already have a rev1 and rev2 of these.
[14:03:31] <shane> Karen: Lot of material that can be pulled from the NTPv5 requirements effort.
[14:55:52] --- LOGGING STARTED