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

[Loa Andersson <[e-mail]>]

Tal,

On 2017-02-08 00:05, Tal Mizrahi wrote:
> Hi Loa,
>
> Here is my understanding:
>
>> The reason why we not want to use a DetNet network that do replication and
>> elimination is that the intermediate nodes "fiddle" with the synchronization
>> packets, and when doing so they leave traces, so the target node will have a hard
>> time (or can't) coordinate the packet flow and the synchronization is lost.
>
> The reason we do not want replication/elimination is that if PTP packets are intermittently sent through two different paths, they would intermittently have two delay values.

This may be self-evident, but I don't really follow.

Any network will give you some delay variation, the PTP packet might 
sometime fall behind a larger packet, sometimes be forwarded ahead of
the large packet.

Now in the DetNet scenario (the slides we had before) where A
replicate the packet to B and C, which forward to D, and where D
eliminate the late packet.

There is only one packet coming through, the one that had the least 
delay of a replicated pair. I don't immediately see why this is a
problem.

Is it obvious that the DetNEt scenario causes larger delay variation 
than a network without DetNet cpabilities?

Looking forward to the discussion.

/Loa


Having a non-constant delay makes it hard for the PTP slave algorithm to 
accurately synchronize.
>
> There are other issues that have been discussed on this thread, and I will try to summarize these in the DETNET DT meeting tomorrow (or today, depending on the time zone :).
>
> Cheers,
> Tal.
>
>> -----Original Message-----
>> From: Detnet-dp-dt [mailto:[e-mail]] On Behalf Of Loa
>> Andersson
>> Sent: Tuesday, February 07, 2017 5:06 PM
>> To: [e-mail]
>> Subject: Re: [Detnet-dp-dt] [EXT] Re: Data Plane Approach - Synchronization
>> Traffic
>>
>> Folks,
>>
>> Let me re-iterate the PTP and replication/elimination discussion from my
>> understanding of synchronization (which is close to zero).
>>
>> The reason why we not want to use a DetNet network that do replication and
>> elimination is that the intermediate nodes "fiddle" with the synchronization
>> packets, and when doing so they leave traces, so the target node will have a hard
>> time (or can't) coordinate the packet flow and the synchronization is lost.
>>
>> On the other hadnd this needs not be  problem since not all DetN, traffic will b e
>> replicated/eliminated, just send the traffic on a path that is true hop-by-hop.
>>
>> /Loa
>>
>> On 2017-02-07 14:50, Balázs Varga A wrote:
>>> 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
>>>
>>> _______________________________________________
>>> 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
>

-- 


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