Re: [TICTOC] Enterprise profile update

Hi Kevin,

Assuming that the IP mcast tree is still built on RPF check, in what scenarios are you considering the ucast path differing from mcast path?

I don’t say this can not happen (e.g. ECMP or LAG) but I’d like to get more precise use cases.

Moreover based on this RPF check, the mcast return path for delay_Req can still be different.
Delay_Resp should take the same path than Sync, Announce.

Thanks,
Laurent

From: Kevin Gross <kevin.gross@avanw.com<mailto:kevin.gross@avanw.com>>
Date: Monday 7 April 2014 07:59
To: Richard Cochran <richardcochran@gmail.com<mailto:richardcochran@gmail.com>>
Cc: "tictoc@ietf.org<mailto:tictoc@ietf.org>" <tictoc@ietf.org<mailto:tictoc@ietf.org>>
Subject: Re: [TICTOC] Enterprise profile update

I can't remember if this was discussed in TICTOCK yet. Apologies if I'm bringing up a settled point.

I appreciate the scalability of unicast delay request/response but I want to make sure everyone is aware of a hazard with hybrid mode. On some networks, unicasts and multicasts are delivered through separate network paths. On these networks, half the round trip delay of a delay request/response unicast exchange will not be a good estimate of sync multicast propagation time.

It may be best to leave a multicast delay request/response option for devices that need higher accuracy or want to have the option to compare unicast and multicast delay request/response performance to determine whether hybrid mode is viable on the network they are connected through.

Kevin Gross - AVA Networks

On Sat, Apr 5, 2014 at 7:37 AM, Richard Cochran <richardcochran@gmail.com<mailto:richardcochran@gmail.com>> wrote:
On Sat, Apr 05, 2014 at 01:20:35PM +0200, Richard Cochran wrote:
> Doug,
>
> On Wed, Mar 12, 2014 at 12:41:33PM -0700, Douglas Arnold wrote:
>
> > 1. Elimination of the Unicast only and Multicast only modes of operation.
> >  The only mode of operation is the hybrid multicast/unicast mode.  In this
> > mode the master sends sync and announce as multicast, and it responds to
> > delay request messages "in kind".  In other words a delay response is
> > unicast if the delay requests is unicast, and multicast if the delay
> > requests is multicast.
>
> Nice. This idea makes way more sense than the unicast option in 1588,
> IMHO.

On second thought, why doesn't this profile simply say that slaves may
use 1588 section 16.1 to negotiate unicast Delay_Resp messages?

As is, this profile mandates behavior WRT unicast that isn't really
allowed by 1588, unless you say that it falls under the very vague and
open ended 7.3.1 clause.

I would prefer the common sense unicast handling in your profile, but
unfortunately 1588 already specifies something else.

Thanks
Richard

_______________________________________________
TICTOC mailing list
TICTOC@ietf.org<mailto:TICTOC@ietf.org>
https://www.ietf.org/mailman/listinfo/tictoc