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

[Jiangyuanlong <[e-mail]>]

Norm, please see my inline comments prefixed with [YJ].

Thanks,
Yuanlong

From: Norman Finn [mailto:[e-mail]] 
Sent: Tuesday, February 07, 2017 6:22 AM
To: Jiangyuanlong
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Detnet-dp-dt] [EXT] Re: Data Plane Approach - Synchronization Traffic

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.
[YJ] Yes, I think this is case 2. DetNet network needs a high precision synchronization itself, and IEEE 1588 seems to be the appropriate technology.

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.
[YJ] Yes, this is case 1. Synchronization service can also be differentiated, for example, to 3 classes: gold, silver, bronze. Only the critical users need the gold sync service (DetNet can be the very underlying technology), but the cost will be high. Some other business only need a moderate sync service, but more reliable or more accurate than the time service available over the Internet (totally free of charge;).

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. 
[YJ] I think this scenario is more or less aligned with Figure 4 & Figure 5 in ITU-T G.8275, that is, the PRTC (Primary Reference Time Clock) is distributed to the edge of the backhaul network. Since the sync processing is local and there is no need of network transport, this case seems out of scope of DetNet. 
[YJ] BTW, we happened to come across the same problem (synchronization in DetNet) last year, please see more details in https://mailarchive.ietf.org/arch/msg/scsn/HmC7hoCxO1TabhZdGHhFY_VOnbg

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