[TICTOC] R: [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Hi
Please note that the performance is heavily dependent on the actual traffic load as it can create asymmetries.
Under certain conditions 7 hops might lead to quite bad performance

Study is still ongoing to understand the partial timing support scenarios

Best regards
Stefano
________________________________________
Da: tictoc-bounces@ietf.org [tictoc-bounces@ietf.org] per conto di Shahram Davari [davari@broadcom.com]
Inviato: venerdì 19 luglio 2013 19.12
A: stbryant@cisco.com
Cc: mpls@ietf.org; tictoc@ietf.org; S. Davari
Oggetto: Re: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Hi Stewart,

Good question. It depends on the Servo algorithms used. The more hops the more complex algorithms with longer convergence time. Any queuing point is potentially one hop that can introduce PDV. The 5-7 hops I mentioned is the best proprietory servo algorithm I have seen, but the convergence time is very long (many minutes).

Thanks
Shahram

-----Original Message-----
From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Friday, July 19, 2013 9:08 AM
To: Shahram Davari
Cc: Bhatia, Manav (Manav); mpls@ietf.org; tictoc@ietf.org; S. Davari
Subject: Re: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls

Shahram

That then poses two interesting question:

1) Do you ever need to go more than 7 hops? In the work we did on
IPFRR the core was normally 8 hops across so most of the traffic
in a single routing domain went less that 8 hops.

2) What happens when there is an underlying packet transport
network which will introduce hidden hops?

Stewart

On 19/07/2013 14:19, Shahram Davari wrote:
> Hi Stewart,
>
> Not necessarily. It is ok if some of the routers in the path are not timing aware. That is the whole idea. We have tested cases in which 5-7 hops are not   1588 aware and still we can recover the time correctly.
>
> Regards,
> Shahram
>
>
> On Jul 19, 2013, at 3:33 AM, "Stewart Bryant" <stbryant@cisco.com> wrote:
>
>> On 19/07/2013 09:11, Bhatia, Manav (Manav) wrote:
>>> Hi Sasha,
>>>
>>>> 1) reserved label is not backward compatible with existing routers. One
>>>> of the requirements is that routers that are not PTP aware can just
>>>> switch the packet normally.  Using a reserved label can't achieve this
>>>> requirement, since routers that don't understand it will drop it or
>>>> sent it to CPU.
>>>> [[Sasha]]  Is not this concern  applicable to any new reserved label?
>>>> And routers that use network processors as forwarding engines could
>>>> easily overcome this issue by upgrading their microcode.
>>>> But I agree that this is a valid concern.
>>> This is a huge concern because not all routers use network processors that can be reprogrammed.
>>>
>>> The current solution works with any router that can set up an MPLS path.
>> Really?
>>
>> Surely the LSR needs to know that on seeing a label in the FEC it needs
>> to timestamp the packet.
>>
>> Stewart
>> _______________________________________________
>> TICTOC mailing list
>> TICTOC@ietf.org
>> https://www.ietf.org/mailman/listinfo/tictoc
>>
> .
>

--
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

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