Subject: RE: [TICTOC] TICTOC BOF Proposal

From: "Sasha Vainshtein" <[email-masked]>
Date: Thu, 18 Jan 2007 15:17:19 +0200

Stewart, Ron and all,
Please see a couple of brief comments below.

Regards,
                 Sasha
-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Thursday, January 18, 2007 3:02 PM
To: Ron Cohen
Cc: [email-masked]
Subject: Re: [TICTOC] TICTOC BOF Proposal

Ron

Ron Cohen wrote:

> Stewart,
> 
> I'll be happy to give IEEE1588 talk in the BOF.

Thanks

> 
> What I believe should be clarified is what we want to achieve as WG:
> 
> 1) Develop Requirements/Architecture

Yes

> 
> 2) Develop a protocol to transfer timing

See below

> 
> 3) Develop the timing distribution solution.
> 

Yes

> I think the WG should focus on 1 and 3, and NOT on 2. I suggest that 
> this would be clarified in the BOF as well.

Well it will be discussed as part of th charter section

> 
> The requirement and architecture (part 1) should provide a problem 
> scope and focus the WG work. We should decide whether we are solving a

> telecom provider network timing distribution problem or not. Whether 
> we can assume MPLS transport or not, Whether we need time transfer or
not, etc.

Well I think that we (the IETF) have a much wider problem to solve thna
just timing (frequency) distribution, and just in the telco environment.

One way packet timing is a good example that exists at all levels in the
network, and for which the current generation of NTP 
implementations are inadequate.

[Sasha] I think that frequency and time distribution are sufficiently
different (including the difference
in complexity mentioned already on this list) to justify separate
approaches.
There are quite a few applications (including but probably not limited
to the Telco ones)
that require only frequency distribution.
> 
> The timing distribution solution (part 3) would answer the questions 
> of such solution works, that is, how clocks are discovered, how is the

> solution managed, is there interactions with routing/qos/signaling
etc.
> This would probably require developing extensions to various protocols

> (BGP, LDP, etc) as well as (hopefully minor) extensions to the timing 
> protocol itself.

At to protocol. There are two approaches that have been discussed in
various circles - 
use 1588 in some mode, or enhance NTP, for example by adding followup
messages.
It would be the job of the WG to look at both approaches as descide.

[Sasha] I believe that at this stage it would be improper to strike out
other approaches 
including approaches with limited functionality (e.g., just frequency
distribution).

- Stewart

> 
> Best
> Ron
> 
> 
> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Wednesday, January 17, 2007 7:33 PM
> To: [email-masked]
> Subject: [TICTOC] TICTOC BOF Proposal
> 
> 
> The the usual structure of a BOF is three phases:
> 
> 1) Problem Statement
> 2) Possible solutions
> 3) Charter
> 
> Yaakov Stein and I are working an a draft that puts forward the 
> problem statement. We will post a pointer to this to the list in the 
> next few days. We need to have this ready by the 25th (next tuesday) 
> so that the IESG can read it before they discuss whether to hold the 
> BOF.
> That discussion takes place on 1st Feb.
> 
> I will also put together a draft charter and share that with the list 
> tomorrow.
> 
> Does anyone want to talk about possible solutions at the BOF? For 
> those not familiar with the IETF such slots are typically between 10 
> and 20 mins, and there may well be several proposals, for example one 
> or more starting from an NTP perspective and one or more starting from

> a 1588 perspective.
> Note that NTP and 1588 are suggestions and there may be other 
> approaches.
> 
> Does anyone think that we need to cover anything else at a BOF?
> 
> Stewart
> 
> _______________________________________________
> TICTOC mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tictoc
> 

_______________________________________________
TICTOC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tictoc

_______________________________________________
TICTOC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tictoc

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 18 Jan 2007 13:31:24 +0000

> including approaches with limited functionality (e.g., just frequency

I agree - it was not my intention to suggest ruling out ANY approach.
Indeed if there are other approaches I would encourage folks
to draw our attention to them. I think that the approach(s) would
be for the WG to decide.

- Stewart

---

From: "Ron Cohen" <[email-masked]>
Date: Thu, 18 Jan 2007 16:19:44 +0200

Sasha,

[Sasha] I think that frequency and time distribution are sufficiently
different (including the difference in complexity mentioned already on 
this list) to justify separate approaches.
There are quite a few applications (including but probably not limited
to the Telco ones) that require only frequency distribution.

It goes back to the problem scope and how we look at it.

One approach (which I don't support) says the following: Lets gather all
requirements for time and frequency delivery and then build a protocol
for timing that will answer these requirements. 

The approach I prefer is the opposite. Lets choose a problem and then
find the right solution for it. The problem we want to address in not
delivering time of day over the internet (this is NTP). The problem we
want to solve in my mind is how to solve the move from SDH based
networks to MPLS based networks. Lets have a narrow scope of the problem
and find the right solution for it. 

Last example. In PWE3 we said up front: we are not going to solve any
service over any packet network with 100% accuracy. We said up front
that we are solving a PE to PE solution. Once we have a stable solution
we can go to the next step and figure out whether this solution works
for enterprises, or for any other environment which has its own
considerations. Some of the solutions turned up to standardize the
service only over MPLS, etc. 

Once we define the scope, we can then argue if for this specific
problem, i.e. telecom applications, we indeed need only frequency. I'm
in the opinion that phase my help in keeping the frequency tracking
better. But this is the discussion we should do once the scope is
decided.

Best
Ron

-----Original Message-----
From: Sasha Vainshtein [mailto:[email-masked]] 
Sent: Thursday, January 18, 2007 3:17 PM
To: Stewart Bryant; Ron Cohen
Cc: [email-masked]
Subject: RE: [TICTOC] TICTOC BOF Proposal

Stewart, Ron and all,

Regards,
                 Sasha
-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Thursday, January 18, 2007 3:02 PM
To: Ron Cohen
Cc: [email-masked]
Subject: Re: [TICTOC] TICTOC BOF Proposal

Ron

Thanks

Yes

See below

Yes

not, etc.

etc.

- Stewart

-- 
This message has been scanned for viruses and
dangerous content by ESVA, and is
believed to be clean.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 18 Jan 2007 15:47:37 +0000

Ron Cohen wrote:

> delivering time of day over the internet (this is NTP).

For some value of "we".

I have some groups asking me how to solve the frequency problem
and indeed that is what got me interested in this problem, but I
have other groups telling me that they don't so much care about
frequency, they need time better than they are getting from NTP.

Now maybe we need two approaches, although I note that Ron is
proposing the use of 1588 - which was designed as a time transfer
protocol - to address frequency, or maybe we do not. Maybe we
need not one but two new WGs - which would be very regretable -
and maybe we do not. BUT we do need to solve both the time and
the frequency problems.

  The problem we
> better. But this is the discussion we should do once the scope is

Regards

Stewart