Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-checksum-trailer-01.txt (Was: WGLC on draft-mizrahi-ntp-checksum-trailer-02.txt)

"Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com> Wed, 01 July 2015 04:00 UTC

Return-Path: <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4637C1A8F46 for <ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com>; Tue, 30 Jun 2015 21:00:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAqUFbt7kTyK for <ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com>; Tue, 30 Jun 2015 21:00:15 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEFE1A88FA for <ntp-archives-ahFae6za@lists.ietf.org>; Tue, 30 Jun 2015 21:00:15 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id 8295A86DAD5 for <ntp-archives-ahFae6za@lists.ietf.org>; Wed, 1 Jul 2015 04:00:15 +0000 (UTC)
X-Original-To: ntpwg@lists.ntp.org
Delivered-To: ntpwg@lists.ntp.org
Received: from mail1.ntp.org (mail1.ntp.org [IPv6:2001:4f8:fff7:1::5]) by lists.ntp.org (Postfix) with ESMTP id 7F24586D48C for <ntpwg@lists.ntp.org>; Wed, 1 Jul 2015 03:57:55 +0000 (UTC)
Received: from [58.251.152.64] (helo=szxga01-in.huawei.com) by mail1.ntp.org with esmtps (TLSv1:RC4-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from <anil.sn@huawei.com>) id 1ZA99f-0004DV-9M; Wed, 01 Jul 2015 03:57:55 +0000
Received: from 172.24.2.119 (EHLO nkgeml408-hub.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CQK32372; Wed, 01 Jul 2015 11:57:18 +0800 (CST)
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.155]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Wed, 1 Jul 2015 11:57:13 +0800
From: "Anil Kumar S N (VRP Network BL)" <anil.sn@huawei.com>
To: "mayer@ntp.org" <mayer@ntp.org>, Anil Kumar <anil.ietf@gmail.com>, Tal Mizrahi <talmi@marvell.com>, Karen O'Donoghue <odonoghue@isoc.org>, "ntpwg@lists.ntp.org" <ntpwg@lists.ntp.org>, "tictoc@ietf.org" <tictoc@ietf.org>
Thread-Topic: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-checksum-trailer-01.txt (Was: WGLC on draft-mizrahi-ntp-checksum-trailer-02.txt)
Thread-Index: AdCzNT97wwMopLF7SfaglIyzNlo4Z///w4MAgAAAdoCAAKL2gP//c3CA
Date: Wed, 01 Jul 2015 03:57:12 +0000
Message-ID: <327562D94EA7BF428CD805F338C31EF06B5AEB6D@nkgeml512-mbx.china.huawei.com>
References: <a55c427404b444bf93d4f9bff62f513f@IL-EXCH01.marvell.com> <5592D18A.7030901@ntp.org> <CAC38=VGf0EmcvGAaJ6X-goq-H0jFNhiNMvx40c0H4mJaotvQCQ@mail.gmail.com> <55935AA1.6050108@ntp.org>
In-Reply-To: <55935AA1.6050108@ntp.org>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.212.150]
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-SA-Exim-Connect-IP: 58.251.152.64
X-SA-Exim-Rcpt-To: ntpwg@lists.ntp.org, mayer@ntp.org
X-SA-Exim-Mail-From: anil.sn@huawei.com
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on mail1.ntp.org)
Subject: Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-checksum-trailer-01.txt (Was: WGLC on draft-mizrahi-ntp-checksum-trailer-02.txt)
X-BeenThere: ntpwg@lists.ntp.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: IETF Working Group for Network Time Protocol <ntpwg.lists.ntp.org>
List-Unsubscribe: <http://lists.ntp.org/options/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=unsubscribe>
List-Archive: <http://lists.ntp.org/pipermail/ntpwg/>
List-Post: <mailto:ntpwg@lists.ntp.org>
List-Help: <mailto:ntpwg-request@lists.ntp.org?subject=help>
List-Subscribe: <http://lists.ntp.org/listinfo/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org
Sender: ntpwg <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>

I believe RFC is not specific to ntpd, sntp, ntpdate, ntimed, Windows, Time, chrony etc...
All above has to follow RFC, So if conformance is with RFC is ultimate reasoning.

I will publish detailed analysis on behavior NTPv3/NTPv4 with respect to M-Bit. 
The problem is that while designing extension addition padding issue should have been taken care, 
We are trying to solve it. This is an honest attempt. 

I discussed with our network solution team, in real network most of devices use only NTPv3 and 
they are not even willing to move into NTPv4 as NTPv3 is serving their purpose. 
Moving into New version is not the only solution to all the issues. 
We need some improvements in current NTPv4 too.

Core network is easy to upgrade as there will be less device using NTP, if we move towards 
Access ring the number of devices are huge. 

The point is coustmer is willing to move NTPv5 if we can provide them only with very attractive/convincing 
features with integrated diagnostic tools, Since each server at the access ring is handling 
huge number of clients, if there is a flapping in server. Server receives burst of client 
requests. One of the requirements came for solution team is to find as many servers as possible 
dynamically (with out multicast) and narrow down to stable servers. Administrator should be able
select one of the best server.

Selecting server : histroy of stability, challenge is trustability & current load.

So I feel we need to solve issue by issue. Lets not differintiate small or big.

Thanks & Regards
Anil S N

"Be liberal in what you accept, and conservative in what you send" - Jon Postel



> -----Original Message-----
> From: Danny Mayer [mailto:mayer@ntp.org]
> Sent: 01 July 2015 08:43
> To: Anil Kumar; Tal Mizrahi; Anil Kumar S N (VRP Network BL); Karen
> O'Donoghue; ntpwg@lists.ntp.org; tictoc@ietf.org
> Subject: Re: [ntpwg] [TICTOC] WGLC on draft-ietf-ntp-checksum-trailer-
> 01.txt (Was: WGLC on draft-mizrahi-ntp-checksum-trailer-02.txt)
> 
> On 6/30/2015 1:29 PM, Anil Kumar wrote:
> > If issue is backward compatibility I will prove it, if new extensions
> > Field type is not conflicting with autokey. It has no issues.
> >
> 
> How are you intending to check ntpd, sntp, ntpdate, ntimed, Windows
> Time, chrony, and a vast number of clients?
> 
> Let us solve the real problem rather than coming up with hacks that
> will be almost impossible to do right.
> 
> Danny
> >
> > On Tue, Jun 30, 2015, 10:55 PMÂ Danny Mayer <mayer@ntp.org
> > <mailto:mayer@ntp.org>> wrote:
> >
> >     On 6/30/2015 9:15 AM, Tal Mizrahi wrote:
> >     > Hi Anil,
> >     >
> >     > Thanks for the prompt response.
> >     >
> >     >> I support this draft, But how about more Bit incorporating in
> >     field type, Tal let me know your view.
> >     >
> >     > The checksum trailer draft requests IANA to allocate an
> extension
> >     field type.
> >     > Note that:
> >     > (1) In unauthenticated mode, the checksum trailer extension
> field
> >     is the last one.
> >     > (2) In authenticated mode, the checksum trailer extension field
> is
> >     followed by the MAC / Autokey extension field.
> >     >
> >     > The suggested M-bit in
> >     draft-choudharykumar-ntp-ntpv4-extended-extensions indicates
> whether
> >     the current extension field is the last or not.
> >     > So once the checksum trailer draft has an allocated extension
> >     field type, its most significant bit will be fixed to either 0 or
> 1,
> >     but cannot cover both case (1) and case (2) above.
> >     >
> >     > A possible way to resolve this is to have two types allocated
> in
> >     the checksum trailer draft, one for case (1), and another for
> case
> >     (2). The two types would be identical, except for the most
> >     significant bit. This would allow future compatibility with the
> >     M-bit, if adopted.
> >     >
> >     > A question to the WG: do we want to provision for the potential
> >     adoption of the M-bit?
> >     >
> >
> >     No. It doesn't solve the problem for which they want it in a
> backward
> >     compatible way.
> >
> >     Danny
> >
> >
> >     _______________________________________________
> >     ntpwg mailing list
> >     ntpwg@lists.ntp.org <mailto:ntpwg@lists.ntp.org>
> >     http://lists.ntp.org/listinfo/ntpwg
> >

_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg