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

[Balázs Varga A <[e-mail]>]

Hi,

we do not have an use-case to transport "sync over DetNet" and in my view that is intentional.
DetNet functions may rely on "time sync" of network nodes. So the "better approach" as described 
by Norm is the preferred solution. Namely, the network synchronizes all its components in a secure 
and robust manner. That "infrastructure clock" serves as a master clock to its attached endpoints and 
used by the DetNet nodes. 

If "gold, silver, bronze" sync service have to be provided for endpoints, than gold requirements are 
needed in the transport network nodes and You can destroy the accuracy level (over the UNI interface)
to "bronze" if You intend to do so.

Cheers
Bala'zs

-----Original Message-----
From: Jiangyuanlong [mailto:[e-mail]] 
Sent: Tuesday, February 07, 2017 3:31 AM
To: Norman Finn 
Cc: [e-mail]; Balázs Varga A ; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [Detnet-dp-dt] [EXT] Re: Data Plane Approach - Synchronization Traffic

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