Re: [Detnet-dp-dt] [EXT] Re: Data Plane Approach - Synchronization Traffic

[Norman Finn <[e-mail]>]

Networks that have but one application can run some profile of IEEE 1588.  IMO, that's running 1588, not time as a service.  I'm not sure if that is your 2, below, or not.

You can tailor some networks to treat PTP preferentially, presumably as extremely high priority, perhaps allowing it to do preemption.  (Your 1, below, I think)  This gets problematical as the rate of PTP traffic grows, perhaps because many applications or many users want their own independent PTP instances, and of course, the individual instances are not cheap to supply with masters and maintain.  Jumps in time happen when a netquake alters path lengths.

A better approach for a great many networks will be for the network to synchronize all its components in a secure and robust manner, so that there is a "good clock" in or near every PE. That "good clock" serves as a master clock to its attached users, using most any PTP profile, perhaps one that hasn't been created, supplying time as a service.  I'm not sure if that is your 2, below, or not.  This way, there is only one good, managed, stable, PTP instance (or multiple instances, for redundancy -- that's up to the network administration).  Time is hard.  The end-to-end model may be great for lots of things, but not necessarily for time.

-- Norm

###############
 On Feb 6, 2017, at 04:22, Jiangyuanlong <[e-mail]> wrote:

Synchronization traffic can be categorized into two cases:
1. Synchronization as a service, high availability can be an advantage for this kind of service
Synchronization service is transported from an ingress PE to an egress PE, replication/elimination can optionally be applied between two PEs (i.e., on S-PEs), while all network nodes including PEs and S-PEs are not aware of the sync message themselves (that is, they don't need to process the PTP messages in the service). And the egress PE will terminate and provide a single copy of each sync packet to a destination CE.

2. Synchronization as an infrastructure
Since existing technology including SyncE and IEEE 1588 rely heavily on a tree topology to work properly, replication/elimination must not be used in this case.

My 2 cents,
Yuanlong

-----Original Message-----
From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of
Jouni Korhonen
Sent: Wednesday, February 01, 2017 4:25 AM
To: Balázs Varga A
Cc: Loa Andersson; Tal Mizrahi; [e-mail]
Subject: Re: [Detnet-dp-dt] [EXT] Re: Data Plane Approach - Synchronization
Traffic

Indeed. Not all traffic will receive the replication/elimination service. That is
based on the configuration.

- Jouni


--
Jouni Korhonen, Broadcom Ltd.
M: [phone]

On Jan 31, 2017, at 12:13 PM, Balázs Varga A
<[e-mail]> wrote:

Hi,
For sync usually we need hop-by-hop forwarding.
So it is not clear why to consider replication (and elimination) at all?
Cheers
Bala'zs

-----Original Message-----
From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of
Tal Mizrahi
Sent: Friday, January 27, 2017 8:37 AM
To: Jouni Korhonen <[e-mail]>
Cc: [e-mail]; Loa Andersson <[e-mail]>
Subject: Re: [Detnet-dp-dt] [EXT] Re: Data Plane Approach -
Synchronization Traffic

In a path redundancy case would the PTP messages on multiple paths be
exact copies a single origin PTP message or different PTP messages?

They would be two different PTP messages.
This implies that we would not like PTP packets to be subject to replication
and elimination.

Tal.


-----Original Message-----
From: Jouni Korhonen [mailto:[e-mail]]
Sent: Thursday, January 26, 2017 8:40 PM
To: Tal Mizrahi
Cc: Loa Andersson; [e-mail]
Subject: Re: [Detnet-dp-dt] [EXT] Re: Data Plane Approach -
Synchronization Traffic



On Jan 25, 2017, at 11:10 PM, Tal Mizrahi <[e-mail]> wrote:

Hi Loa,


- If the answer is yes: not sure replication and elimination makes
sense for
PTP.

Why is that?

In order for PTP to work well, PTP packets have to be consistently
sent over the
same path. If packets are intermittently sent through two different
paths (with two different delays) the PTP slave will not be able to
synchronize in a stable way.
However, it *does* make sense for PTP to be sent through two
different paths
*without* elimination at the end. Such path redundancy allows the
slave to always receive the sync information through both paths,
which actually allows more robust synchronization than over a single
path.

So path redundancy is good for PTP, but elimination - not so good.

In a path redundancy case would the PTP messages on multiple paths be
exact copies a single origin PTP message or different PTP messages?

- JOuni



Cheers,
Tal.


-----Original Message-----
From: Loa Andersson [mailto:[e-mail]]
Sent: Thursday, January 26, 2017 9:01 AM
To: Tal Mizrahi; [e-mail]
Subject: [EXT] Re: [Detnet-dp-dt] Data Plane Approach -
Synchronization Traffic

External Email

-------------------------------------------------------------------
-
-
-
Tal,

On 2017-01-26 14:44, Tal Mizrahi wrote:
Hi,

I realize this is a bit off-topic, but one of the things I am
wondering about is how
synchronization traffic (PTP) is forwarded in the context of the
data plane approaches we have been considering.
Is PTP transported as a DETNET flow?
- If the answer is no: does that mean we are assuming that
synchronization is
achieved at a different layer, possibly requiring dedicated
communication between the customer and provider?
- If the answer is yes: not sure replication and elimination makes
sense for
PTP.

Why is that?

/Loa

Will be happy to hear your thoughts, and apologies if this has
already been
discussed elsewhere and I am not aware.

Cheers,
Tal.
_______________________________________________
Detnet-dp-dt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/detnet-dp-dt


--


Loa Andersson                        email:
[e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]

_______________________________________________
Detnet-dp-dt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/detnet-dp-dt

_______________________________________________
Detnet-dp-dt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/detnet-dp-dt

_______________________________________________
Detnet-dp-dt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/detnet-dp-dt
_______________________________________________
Detnet-dp-dt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/detnet-dp-dt