With WG chair hat off, I don't agree with the statement
d) 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)
There is a huge gap between believing that a service provider prioritorizes
timing traffic or provides TC,
and trusting that SP to block malicious timing traffic or MiM attacks.
Regarding the question as to whether we need an MPLS encap at all,
I think we should hear from SPs.
Y(J)S
From: [email protected] [mailto:[email protected]] On Behalf Of
Yaakov Stein
Sent: Friday, September 24, 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
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
