Re: [TICTOC] Enterprise profile update

[Kevin Gross <[e-mail]>]

The common asymmetric scenario is with PIM-SM. Under PIM-SM, multicasts are
at least initially routed through a rendezvous point which would likely be
a detour compared to a unicast path. My understanding is that most
implementations then go on to build a more reasonable distribution tree for
multicasts but there is nothing in the PIM RFCs that require or even
encourage this.

The objection I've heard to 16.1 is that it imposes arguably unnecessary
overhead in setting up unicast delay request/response. It is simpler for a
master just to know (based on profile) that when it receives a unicast
delay request, it should simply generate a unicast response to the sender.
If the enterprise profile is defined to work in this way, a slave can
switch mode on the fly and quickly compare results between unicast and
multicast and determine the best mode of operation.

Kevin Gross - AVA Networks


On Tue, Apr 8, 2014 at 8:45 AM, Richard Cochran <[e-mail]>wrote:

> On Tue, Apr 08, 2014 at 03:31:58PM +0200, Wojciech Owczarek wrote:
>
> > 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.
>
> But why not simply do what it says to do in 1588-2008 Section 16.1 ?
>
> [ This question is directed at both ptpd and the new profile. ]
>
> If the profile and the implementations follow the standard, then it
> makes it far easier for different products to inter-operate.
>
> I am willing to bet that some stacks already implement 16.1, and
> following the standard in the enterprise profile will make it simple
> for such stacks to support the new profile. In contrast, mandating new
> behavior makes more work for everyone.
>
> Sometimes you cannot avoid having special behavior in a profile, but
> in this case I don't think the departure from 1588 brings any tangible
> benefit.
>
> Thanks,
> Richard
>