Re: [TICTOC] Enterprise profile update

I would say that with the latest generations of network kit, the unicast vs. multicast latency differences start to dither and those asymmetries will eventually be a thing of the past - yet perhaps it might be very worthwhile to add some advisory wording.

As a very general comment I will add that you cannot substitute standards for good network design and architecture practices - and I think that all those issues such as asymmetric paths, routing layout etc., are a matter of network design more than anything else. When you deploy the enterprise profile, it's under the assumption that you know how your network is designed and you are aware of the caveats resulting from it. To me, multicast distribution and routing is easy to manage, but I work in a multicast-centric environment.

Nevertheless, I do support the call for allowing the mixed unicast/multicast operation, but not exclusively - also allowing to use pure multicast operation. From the implementation perspective this is simple: if the PTP_UNICAST flag of the incoming delayReq was true, you reply to the source. If not, you reply to the common multicast group. We have been doing that in ptpd for quite a while now.

Regards,
Wojciech

-
Wojciech Owczarek

On 8 Apr 2014, at 14:40, "Laurent Montini (lmontini)" <lmontini@cisco.com> wrote:

> 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>
> Date: Monday 7 April 2014 07:59
> To: Richard Cochran <richardcochran@gmail.com>
> Cc: "tictoc@ietf.org" <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> 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
> https://www.ietf.org/mailman/listinfo/tictoc
> 
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc