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

"Shahram Davari" <davari@broadcom.com> Fri, 19 July 2013 17:13 UTC

Return-Path: <davari@broadcom.com>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DEF11E8163; Fri, 19 Jul 2013 10:13:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id er0wRMhpXeb6; Fri, 19 Jul 2013 10:13:03 -0700 (PDT)
Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id C0F2C11E8185; Fri, 19 Jul 2013 10:13:03 -0700 (PDT)
Received: from [10.9.208.55] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Fri, 19 Jul 2013 10:03:10 -0700
X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF
Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS07.corp.ad.broadcom.com (10.9.208.55) with Microsoft SMTP Server (TLS) id 14.1.438.0; Fri, 19 Jul 2013 10:12:48 -0700
Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS04.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Fri, 19 Jul 2013 10:12:48 -0700
From: Shahram Davari <davari@broadcom.com>
To: "stbryant@cisco.com" <stbryant@cisco.com>
Thread-Topic: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls
Thread-Index: Ac54l9Qw6dji89r/Roeasf8MKqK32gLBHC6QABv2v4AAITEXAAAAV3iAAATsC4D//7lR14AApFaAgABkOfA=
Date: Fri, 19 Jul 2013 17:12:48 +0000
Message-ID: <4A6CE49E6084B141B15C0713B8993F281BE8F310@SJEXCHMB12.corp.ad.broadcom.com>
References: <07F7D7DED63154409F13298786A2ADC904E58E15@EXRAD5.ad.rad.co.il> <F9336571731ADE42A5397FC831CEAA02150E7717@ILPTWPVEXMB02.ecitele.com>, <E806627C-460A-4417-ABD1-929A4BAEC6D9@yahoo.com> <F9336571731ADE42A5397FC831CEAA02150E7CA1@ILPTWPVEXMB02.ecitele.com> <20211F91F544D247976D84C5D778A4C30845D4@SG70YWXCHMBA05.zap.alcatel-lucent.com>, <51E915BF.6020308@cisco.com> <1AB8A6CA-414A-4EFB-8704-47B41460CA90@broadcom.com> <51E9644F.8060100@cisco.com>
In-Reply-To: <51E9644F.8060100@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.16.203.100]
MIME-Version: 1.0
X-WSS-ID: 7DF7AEC42L850265045-01-01
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: "mpls@ietf.org" <mpls@ietf.org>, "tictoc@ietf.org" <tictoc@ietf.org>, "S. Davari" <davarish@yahoo.com>
Subject: Re: [TICTOC] [mpls] TICTOC WG LC for draft-ietf-tictoc-1588overmpls
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tictoc>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 17:13:07 -0000

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