Subject: RE: [TICTOC] TICTOC BOF Proposal

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

Ron (and all),
Please see some comments inline below.

Regards,
                   Sasha 

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

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. 

[Sasha] I think that the "One protocol to rule them all..." approach
simply will not fly (i.e. agree with you). 
[Sasha] But there seem to be different opinions on this subject... One
of the ruling principles of the IETF is 
[Sasha] "rough consensus" and it has been explained that most of
meanings of the adjective "rough"
[Sasha] (see below ) are equally relevant for understanding this rule.
=====================================================
Quoting from the Merriam-Webster dictionary:

Main Entry: rough (adj.):

1 a : marked by inequalities, ridges, or projections on the surface :
COARSE 
   b : covered with or made up of coarse and often shaggy hair
<rough-coated collie> -- compare SMOOTH, WIREHAIRED 
   c (1) : having a broken, uneven, or bumpy surface <rough terrain> 
      (2) : difficult to travel through or penetrate : WILD <into the
rough woods -- P. B. Shelley>
2 a : TURBULENT, TEMPESTUOUS <rough seas> 
   b (1) : characterized by harshness, violence, or force 
      (2) : presenting a challenge : DIFFICULT <rough to deal with -- R.
M. McAlmon>
3 : coarse or rugged in character or appearance: as 
   a : harsh to the ear 
   b : crude in style or expression  
   c : INDELICATE d : marked by a lack of refinement or grace : UNCOUTH
4 a : CRUDE, UNFINISHED <rough carpentry> 
   b : executed or ventured hastily, tentatively, or imperfectly <a
rough draft> <rough estimate>; also : APPROXIMATE <a rough idea> 
=====================================================

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). 

[Sasha] I think this depends on the specific interests of the specific
BOF/WG participants.
[Sasha] My impression so far has been that there are quite a few people
that are interested 
[Sasha] in solving the high-precision time of day distribution and are
not satisfied with the accuracy
[Sasha] that the existing NTP provides. (One of the NTP problems is that
the rate of polling the server
[Sasha] is quite low.) 

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. 

[Sasha] Well, there are at least two of us sharing this specific
interest. I hope that there will be more 

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. 

[Sasha] IMHO this depends on what counts as a Telecom application. If we
are speaking about
[Sasha] replacing SONET with MPLS, this statement is probably correct
because SONET does not, AFAIK,
[Sasha] distribute time of day. On the other hand if you count a CDMA
BTS receiving its timing from GPS
[Sasha] as a Telecom application, it can use (and possibly requires)
both frequency and time of day... 

I'm in the opinion that phase may 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,
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

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

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

---

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

Stewart (and all),
Please see one brief comment inline below.

I've snipped out the parts of the original message that are not relevant
to this comment.

Regards,
                Sasha

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Thursday, January 18, 2007 5:48 PM
To: Ron Cohen
... snipped ...

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. 
[Sasha] Based on the current experience I would strongly prefer ONE WG
working TWO solutions for TWO 
[Sasha] separate problems. This is mainly because of the overhead
involved with setting up a new WG.
[Sasha] (The fact that we have not yet succeeded to do so is IMHO a good
indicator of the inherent 
[Sasha] complexity of THIS problem:-)

... snipped to the end ...